그럼에도 불구하고, Pay it forward

'그럼에도 불구하고'라는 말은 참 신기한 말인 것 같아요.

"못생겼고, 키도 작고, 바보같아. 그럼에도 불구하고 얘라서 좋아."

그럼에도 불구하고, 이 말은 앞에 나온 만나지 말아야 할 이유들을
한번에 뒤집을 수 있는 마법의 말인 것 같습니다.

안녕하세요,

포항시 IT 협업 동아리 PARD 디자이너 김영채입니다.

PARD는 Pay it forward라는 정신을 바탕으로 자신이 배운 것을 남에게 대가 없이 나누어 주고, 도움을 받은 사람 또한 남을 주는 선순환을 추구합니다. 2023년에 첫 시작을 한 저희는 현재 16명의 운영진과 34명의 참여 기수들이 함께하께 네 번째 여정을 이어가고 있습니다.

메이커분들 각자의 자리에서 다들 잘 지내고 계신가요?

오늘은 요즘 제가 파드를 통해 경험하고 있는 마법 '그럼에도 불구하고'의 힘을 메이커분에게 나누고자 합니다.

스타트업 왜 가고 싶으세요?

많은 젊은이들이 스타트업 취업 희망사유로
자유'와 '수평적인 문화', '넓은 업무 스펙트럼'을 제시합니다.

PARD는 사실 스타트업과 닮은 점이 꽤 있습니다. 대표적으로 3가지 정도 말할 수 있겠네요.

1. 아무나 자유롭게 의견을 낼 수 있다.

2. 업무의 자율성이 있다. (= 하고 싶으면 할 수 있다.)

3. 활동기수들을 보며 성취감을 느낄 수 있다.

하지만 장점이 저를 버겁게 할 때가 있습니다.

파드는 정말 장점이 많은 동아리입니다. 위에 쓴 저 3가지만으로 퉁칠 수 없어요!

저도 파드의 수많은 장점과 강점을 목격했고, 해오고 있습니다. 하지만 가끔은 저 장점으로 작용하는 것들이 현실과 맞닿으며 부작용을 낳을 때도 있다는 것일 뿐입니다.

1. 아무나 자유롭게 의견을 낼 수 있다.

   = 진짜 아무나 낼 수 있다. 입이 많다보니 인내심을 가지고 다 들어야 한다.

   어떻게 보면 비효율적이고, 어떻게 보면 다양한 의견을 들을 수 있다.

2. 업무의 자유도가 있다.

   = 하고싶으면 할 수 있다. 누구나 할 수 있어서 인력난 발생시 누구든지.. 해야한다.

3. 활동기수들을 보며 성취감을 느낄 수 있다.

   = 활동기수들이 성장할 수 있도록, 파드에 잘 적응할 수 있도록 지속적으로 케어해야 한다.

네.. 이런 식으로 가끔 되더라구요..

함께 무언가를 "제대로" 한다는 것

함께 무언가를 제대로 한다는 것은 체력과 시간과 노력과 진심을 요구하는 일인 것 같아요.

저는 동아리에서 이것을 경험하고 있지만, 다양한 상황에 처해있는 모든 메이커분들도 동일하게 경험하고 있으리라 생각합니다.

파드는 늘 바쁘고, 제대로 해야 하고, 참여기수의 경험을 신경써야 하고, 다음을 위해 매번 회고해야 하고, 발전해야하고, 열정을 유지해야하고, 사람들을 피곤해도 챙겨야 합니다. 이 모든 것들에서 얻을 수 있는 것들은 분명히 있었습니다. 이 경험을 단지 힘들다는 말로 퉁친다면 저는 정말 오만한 사람이지 않을까 싶을 정도입니다😅 단지 그것과는 별개로 그 과정이 버겁고 피로하기도 했다는 말을 하고 싶었습니다.

그럼에도 불구하고

그럼에도 불구하고 저는 파드한 것을 후회하지 않습니다. 왜냐하면 제가 현실과 눈앞에 보이는 상황에 치여 열정이 식을 때마다 저를 도와주는 동료들이 있어거든요. 힘들 때 옆에서 응원해주고, 대신 업무도 덜어주고, 속상해하면 같이 욕해주고, 쉬고싶어하면 같이 놀아주고, 그래서 학업과 병행하며 4기를 이어올 수 있었네요. 그리고 저를 뒤집은 것도 사실은 다른 무엇도 아닌 사람이었던 것 같습니다. 너무 뻔한 이야기일까요?

세상의 모든 일은 하지 않아도 될, 하지 말아야 될 이유는 사실 수십가지잖아요.

다들 아무것도 안하고 노는게 꿈 아닌가요? 저도 그게 꿈이구요. 그럼에도 그럼에도 파드는 저에게 이 모든 것을 뒤집습니다. 그 이유는 동료였구요! 메이커분들도 눈앞에 보이는 현실과 상황에 치이고 계시겠지만, 한번쯤 고민을 해보면 좋을 것 같아요.

"나의 삶에서 나를 뒤집히게 하는 '그럼에도 불구하고'는 무엇일까"

글 읽어주셔서 감사합니다 모두들 화이팅!

[숏커톤 회고] 기념일? 선물? 다 필요 없다, 우리는 실패했다! (기념일 이머전시)

안녕하세요, 포항시 IT 협업 동아리 PARD에서 웹파트 부원으로 활동 중인 정민찬입니다! 😴

지난 11월 15일 오후 6시부터 11월 16일 정오까지 진행되는 숏커톤 행사에 참여했습니다.

숏커톤이란?

Short + Hackathon의 합성어로, 짧은 시간 내에 IT Product를 산출하는 데 목적을 둔 협업 프로젝트를 뜻합니다.

15시간이라는 타이트한 시간 동안

💡기획자(Product Manager),

🎨🎨디자이너(UI/UX Designer),

🧑‍💻🧑‍💻🧑‍💻프론트엔드 개발자(Front-End Developer),

🧑‍💻백엔드 개발자(Back-End Developer)가 협업하여 ⭐️MVP⭐️(Minimum Viable Product)를 만들어내는 도전입니다!

이번 숏커톤의 주제 . . .

이번 숏커톤의 주제는 Harmony [조화, 화합] 이었는데요~!

주제부터 한번 반하고, 포스터 디자인에서 한번 더 반했습니다 😳

이때부터 느껴지는 중압감과 함께 이 생각이 들었습니다.

'아, 나는 개발을 하러 온 것이 아니구나. 협업을 하러 온거다!''

라고 깨달았습니다~~

숏커톤 전우회

또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜 또 왜

숏커톤을 본격적으로 시작하기에 앞서, 저녁 식사를 했습니다~!

벌써부터 조화롭고 화합이 느껴지지 않나요? 🤥🫢

4기 숏커톤 : Harmony 시간표

이건 시간표고용

이건 최종 필수 결과물입니당

팀이름: 왜. 또. 왜.

의미: 끊임없이 질문하고, 또 질문하고 또 질문하는 과정에서 최고의 협업을 만들기 위한 의미가 담겨있습니다!

나오게 된 과정: 끊임없이 문제 정의에 대한 의견을 주고 받는 사이 5 why에 대해 무한 루프에 걸려서 "왜, 또, 왜?" 라는 말이 나오게 되어 팀 이름으로 정의하게 되었

서비스 명: 기머전시 (기념일 + 이머전시)

거두절미하고, 저희가 만든 프로덕트 자랑 좀 하는 시간 좀 가지겠습니다~~

통계적 자료나 관련 기사를 다 넣을려면 분량이 너무 많아질꺼 같아 약식으로 설명하겠습니다~!

===> (디자인 완전 기엽죠?!) <===

문제 발견: 어떻게 하면 특별한 기념일 날 내가 사랑하는 남자친구 혹은 여자친구와 더 화합 (harmony) 할 수 있을까?

-> 기념일에서 빠질 수 없는 중요한 요소 중 하나는 바로 선물입니다. 선물은 상대방의 마음을 표현하는 수단이자 특별한 날을 더욱 뜻깊게 만들어주는 요소로 여겨집니다. 하지만 기념일에 대한 긍정적인 인식과는 달리, 받은 선물에 대한 만족도는 의외로 낮은 편이라는 조사 결과가 있습니다.

문제정의: 나는 [커플들이] [기념일 선물에 대해 부담 없이 대화할 기회가 부족해서] [선물에 대한 만족도를 높이는 대화를 나누지 못하는 문제]를 겪는다고 생각한다.

서비스 설명: 기념일을 챙길 때 커플들이 자신이 원하는 선물을 부담 없이, 재미있게 전달할 수 있도록 도와주는 서비스

문제 : 기념일, 서운함, 문제, 해결

• 기념일을 어떻게 챙길지

• 선물의 가격을 정할지

• 선물을 어떤 걸 받을 지 정할지

타겟 : 커플

→ 그렇다면 부담스럽지 않게 어떻게 재밌게 솔직하게 표현해볼 수 있을까?

핵심기능 나열

• 입력받는 기능

• 문제로 변환되는 기능

• 변환된 것을 공유하는 기능

→ MVP

2. 사용자 플로우

1. 서비스 접근

   • 

     사용자는 서비스에 가입하거나 로그인합니다.

   • 기념일을 등록하거나 선물 맞추기 이벤트를 생성합니다.

2. 문항 생성 (문제 만들기)

   • 선물을 원하는 사용자가 "문항 만들기" 기능을 사용해 퀴즈를 작성합니다.

   • 예: "내가 가장 받고 싶은 선물은?", "선호하는 선물 가격대는?"

3. 문항 공유

   • 작성한 문항은 링크나 QR코드 형식으로 상대방에게 공유됩니다.

   • 상대방은 링크를 통해 별도 회원가입 없이 문항에 답변 가능.

4. 상대방의 퀴즈 풀이

   • 상대방은 문항을 풀면서, 선물을 유추하거나 재미있는 방식으로 선택합니다.

     • 8단계에 걸친 다양한 질문 제공.

     • 선택지를 클릭하거나 직접 답변을 입력 가능.

     • 현재 진행 상황을 시각적으로 표시하는 진행률 바 탑재.

5. 결과 확인 및 피드백

   • 문제 풀이가 완료되면, 결과를 생성한 사용자에게 전달합니다.

   • 퀴즈를 통해 상대방이 선택한 답변과 정답을 비교.

PRD(요구 사항 명세서)

분명 이때까지는 전부 구현할 수 있을 것이라 생각했습니다..

개발자의 난관

난관 1: 답지 공유 기능 및 결과 표시 기능 미구현

현재 중요한 MVP에서 두 가지 핵심 기능을 구현하지 못한 상황입니다. 첫째, 답지 공유 기능은 사용자가 자신이 설정한 문항을 상대방과 쉽게 공유할 수 있는 기능으로, 이를 통해 선물에 대한 대화가 시작될 수 있습니다. 둘째, 결과지에 상대방의 답변과 사용자가 선택한 정답을 표시하는 기능이 미완성인데, 이 기능은 서로의 선호를 비교하고 대화의 재미를 더할 중요한 요소입니다.

이 두 가지 기능을 구현하지 못한 이유는 서버와의 연결 작업이 부족했던 점으로, 빠른 개발이 요구되는 MVP에서 이 부분이 뒤쳐졌다는 점이 난관입니다.

--> 이랬으면 어땠을까?

1. API 연동은 서버와의 연결이 필요하지만, 프론트엔드에서 임시로 데이터를 저장하거나 로컬 저장소에 저장된 데이터를 기반으로 진행해도 초기에 구현이 가능.

2. 간단한 링크 또는 QR 코드로 답지 공유 기능을 우선적으로 구현.

난관 2: 문제를 제출하는 사람과 푸는 사람의 UI 분리 미비

문제를 제출하는 사람과 푸는 사람의 UI를 분리하지 못한 점도 현재 문제입니다. 두 사용자가 각각 다른 역할을 하므로, 그들의 경험이 혼합되지 않도록 UI를 명확하게 구분해야 합니다.

--> 이랬으면 어땠을까?

1. 플로우 분리: 문제 제출자는 템플릿 작성과 공유 버튼을 위주로, 문제 풀이자는 답을 선택하고 결과를 기다리는 UI 흐름으로 분리.

팀에서의 난관

난관 1.

프로젝트 계획 수립과 초기 설계 단계에서 시간이 예상보다 더 소요되었음.

-> 개발 시작 시간이 늦춰짐

난관 2.

소프트 언어 사용의 어려움

-> 자신의 전문분야 언어를 풀어서 설명하는 데 시간이 소요됨.

난관 3.

기능 구현의 범위 및 우선순위 설정의 어려움

-> 예상치 못한 오류가 발생하였을 때 구현에서의 압박감이 들었음.

💡 각자의 이야기

🧑‍💻 Front-end Developer 신엽

"기획? 재밌네?"
솔직히 처음엔 재미없을 줄 알았는데, 예상보다 몰입감이 있었다. 다른 조는 상황 공유도 하고 완급 조절을 잘했는데, 우리도 그런 방식으로 협업하면 좋았을 것 같아. 다만 개발 팀장 역할은 다시 하면 안 될 것 같다. 내가 메타인지 높은 개발자가 되어야겠다고 다짐했어. (3주면 네이버도 만들겠는데?) 그래도 우리 팀원들과 우당탕탕 조율하며 진행했던 경험은 너무 값졌다!

결론: 팀원의 중요성 ---> 협업이 이거구나!

🎨 UI / UX Designer 수빈

"밤샘 작업은 원래 이렇게 신나는 거야?"
웹 디자인이 익숙하지 않아서 초반에 어려움을 느꼈지만, 끝까지 에너지를 내며 즐길 수 있었다. 디자인이 기획과 개발과 맞물리는 느낌이 좋아서, 앞으로는 더 효율적으로 소통하며 일하고 싶어.
아쉬운 점이라면, 사람들이 투표할 때 디자인의 비주얼 요소가 중요한데, 이를 발표자료에서 강조하지 못한 점. 그래도 팀원들과의 소통과 시너지가 좋았고, 키컬러가 크리스마스 느낌으로 사랑받아서 뿌듯했어!

결론: 팀과의 협업 ---> 체력 소진 상태인 나를 각성하게 한다!

🧑‍💻 Front-end Developer 민찬

"폰트가 궁서체일 때... 진심 심장이 내려앉았어."
솔직히 번아웃 상태에서 시작했지만, 그래도 내 나름대로 최선을 다했어. 특히 다른 팀들과 비교했을 때, 우리 UI의 완성도가 높았던 점이 자부심으로 남았어. 다만 요즘 개발에 대한 실력 부족도 그렇고, 심리적 불안감이 있었는데, 이번 프로젝트를 계기로 심리적 안정감도 되찾았고, 내가 팀에게 심리적 안정감을 주기 위해서는 실력을 꾸준히 쌓아가야겠다고 다짐했다 (1day 1 commit!). 그리고 우리 팀이 완성한 결과물은 진짜 자랑스러워!

결론: 심리적 안정감 ---> 협업을 원활하게, 하드코딩 가능!

🧑‍💻 Front-end Developer 석영

"내가 할 수 있을까? 했는데, 했네!"
프로그레스 바부터 결과 화면까지, 어려운 순간마다 우당탕 해냈다. 코딩은 서툴지만, 소통 능력 하나로 팀의 윤활유 역할을 했다고 자부해. 우리 팀원들이 너무 열정적이라, 덩달아 나도 동기부여가 되더라. 그리고 모든 상황을 빠르게 캐치하면서 효율적으로 소통했던 게 큰 도움이 된 것 같아.

결론: 소프트언어와 소통의 결합 ---> 열정 열정 열정!

🧑‍💻 Back-end 하진

"새벽 2시의 나는 실수 머신."
백엔드에서 시행착오가 많았던 건 아쉽지만, 밤샘 작업 속에서도 끝까지 해결하려고 노력한 점은 칭찬하고 싶어. 특히 다른 파트를 좀 더 이해하고, 내가 할 수 있는 일에 도움을 주는 능력을 키워야겠다는 생각이 들었어. 그래도 열정적인 토론과 작업 분위기가 너무 좋았어!

결론: 건강한 토론 ---> 아이디어 홍수!

🎨 UI / UX Designer 서영

"분위기가 팀의 절반을 만든다."
처음 숏커톤에 참여하면서 긴장도 했지만, 우리 팀의 건강한 열정 덕분에 끝까지 즐길 수 있었어. 특히 아이디에이션 단계에서부터 방향성을 잘 잡고 간 게 큰 도움이 된 것 같아. 앞으로는 좀 더 다양한 레퍼런스를 찾아보고, 더 성장할 수 있는 디자인을 해보고 싶어.

결론: 편안한 분위기 ---> 하나의 목표에 집중!

💡 Product Manager 지안

"기획은 팀의 나침반, 부족하지만 방향을 잡으려 노력했습니다."

기획자로서 팀의 상황 체크와 컨디션 관리, 그리고 라포 형성에 힘쓰며 팀이 흔들리지 않고 끝까지 나아갈 수 있도록 돕고자 했어. 아이디에이션 과정에서 모든 파트원들이 적극적으로 아이디어를 내줘서 문제정의를 명확히 할 수 있어 좋았고, 디자인, 프론트, 백엔드의 소통이 너무 원활해서 수월했어! 하지만 아쉬운 점도 많았어. 더 넓은 시야로 팀의 진행 상황을 참고하며 방향성을 조율했다면, 우리 팀의 완성도나 협업 방식이 더욱 빛날 수도 있었겠다는 생각이 들어.

그래도 팀원들이 끝까지 열정을 다해주었기에 부족한 부분을 함께 채울 수 있었어!

결론: 방향을 같이 잡아준 팀원들 ---> 날카로워진 문제정의!

배운 것 & 느낀 것
저희는 단 15시간 동안, 아이디어부터 결과물까지 만들어내는 작은 기적을 경험했습니다! 기획, 디자인, 프론트엔드, 백엔드로 나뉘어 각자의 전문성을 발휘했지만, 결국 "팀워크"라는 한 단어로 모든 것을 관통했습니다 🏹

KPT (Keep, Problem, Try)

KEEP (유지할 점)

• 소통: 파트 간 끊임없이 소통하며 상황을 공유했던 점.

  • 디자인과 개발이 서로 이해하며 작업 방향을 명확히 설정.

  • 아이디어 실현에 팀원들이 적극적으로 협력.

• 열정적 분위기:

  • 팀원 간의 아이디어에 대한 건강한 열정과 토론이 좋은 결과를 이끌어냄.

• 책임감:

  • 각자 맡은 바를 끝까지 해내려는 태도. 특히 어려운 작업을 해결하려는 적극성이 돋보였음.

• PROBLEM (개선할 점)

  • 상황 공유 부족:

    • 작업 진행 과정을 좀 더 명확히 설명하여 시간에 쫓겨다니는 기획에 힘 보태기

    • 작업 중 실수나 문제 발생 시 더 빠르게 대처 가능하도록 조율이 필요.

  • 레퍼런스 부족:

    • 웹 기반 디자인에 대한 레퍼런스 탐색 부족으로 인해 다양한 시도를 하지 못해 아쉬움이 있었음.

  • 시간 관리

    • 실시간 데이터 동기화 문제나 UI 일관성 문제

    • 작업 진행 시간과 리소스 분배에서의 미흡함.

      • But, 시간적 여유가 넉넉한 프로젝트에서는 크게 문제되지 않음!

  ---

  TRY (시도할 점)

  • 파트별 상황 공유 체계 구축:

    • 정기적으로 작업 진행 상황을 공유하고, 발생 가능한 문제를 빠르게 해결할 수 있는 체계 도입.

  • 레퍼런스 탐색 시간 확보:

    • 기획 및 아이디에이션 초기 단계에서 다양한 레퍼런스를 적극적으로 수집.

    • 웹, 앱 모두를 고려한 레퍼런스 범위를 확장.

  • 소통 역량 강화:

    • 개발자는 디자인과 기획의 요구를 이해하려는 노력을 지속.

    • 디자인은 개발에 용이한 자료 제공 방식을 학습.

  • 발표 준비 강화:

    • 발표 전에 자신감을 가질 수 있도록 리허설 진행 및 팀원 간 피드백.

이상으로 길고 길었던 숏커톤 회고를 마치겠습니다.

끝까지 봐주셔서 감사합니다~!!

저희 성장해요~~~~!!!

그래서…좋은 백엔드 개발자가 뭐지.. 💻🤔

(글 시작 전에... 중간중간 글이 아닌 사진을 추가하였습니다... 이미지를 사용하고 싶었던 저의 욕심이랄까요.. ㅎㅎ 참고해서 읽어주세요! 감사합니다 🙂)

안녕하세요, 포항시 IT 협업 동아리 PARD 서버 파트 4기로 활동 중인 김나임이라고 합니다.

해커톤에서는 다양한 직군의 사람들이 모여 하나의 목표를 향해 달리는데요. 이번 11월 15일~16일 PARD에서 진행하는 숏커톤(short-hackaton 의 줄인말)에 참여하게 되었습니다. 기획자, 디자이너, iOS 스위프트 프론트엔드 개발자들과 팀을 이루었고, 저는 서버 파트로, 백엔드 시스템을 구축하는 역할을 맡았습니다.

이 회고에서는 숏컷톤에서 팀 전체의 아이디어 구상이나 디자인 과정, 해커톤 중 받은 피드백, 문제 등 에 대한 이야기가 아니라, 제가 맡았던 백엔드 서버 개발 경험과 '좋은 백엔드 개발자란 무엇인가'에 대한 생각을 초점에 두어 공유해보고자 합니다.

숏컷톤 전 😫

" 나 진짜 아무것도 모르는 감자인데 어카지... "

숏컷톤 중 🏃‍♂️💨

너무 많은 생각이 머리를 스쳐 지나가서 정리하기가 너무 어렵네요…. 그래서 시간 순서 제 생각의 흐름을 적어봤습니다. 하하 이 부분은 그냥 재미로 읽어주세요!

( --- 선으로 분리 했으니 넘어가셔도 좋습니다!)

아이디어 정하는것도 진짜 쉽지 않은거구나… (우당탕탕 주제정하고계획세우고개발시작)

-개발 본격 시작!!!-

타다닥… 배운거 적용해서 코드 짜기..

@Operation 써서 Swagger로 프론트 분들이 편하게 읽을 수 있도록 summary도 추가해야지지..

여기서 Swagger이란 : 개발한 Rest API를 자동으로 편리하게 문서화해주는 편리한 도구이다!

---

정신없이 숏컷톤을 시작하고 ERD (개체 관계도) 부터 그려보고 누구보다 빠르게 (남들과는다르게) API 명세서를 MVP 위주로 일단! 작성하여 프론트 분들과 함께 사용할 변수명을 정하고 백엔드 개발을 시작하였습니다.

개발하고자 하는 앱에서 간단한 ERD를 지니고 있었기에 예상 시간보다 빠르게 완료할 수 있었습니다. 이에 따라 API 명세서를 보다 깔끔하고 구체적으로 작성하고, 백엔드 기능을 정리한 마크다운 파일 작성에 더 많은 시간을 투자할 수 있었습니다. 아쉽게도 프론트와 백엔드 연결은 하지 못했지만, 숏커톤은 잘 마무리하였습니다.

숏컷톤 후 🛠️🫠

끝남과 동시에 보이는 부족함.. 반성의 시작...

반성을 길게 주저리 주저리 하지 않겠습니다. KPT 회고로 정리해보았습니다.

KPT란? Keep, Problem Try의 약자로 말 그대로 계속 이어갔으면 하는 부분, 개선이 필요한 부분과 앞으로 바꿔 나가야 할 부분(Problem의 해결책)을 뜻한다.)

Keep

✅ ERD 부터 그려보는 것

✅ 코드 설명 꼼꼼하게 추가하는 것 ( 프론트분들이 볼 때 이해가 되도록)

✅ 깔끔한 API 명세서

Problem

❌ 적절한 예외 처리 부족

❌ 응답 및 에러 처리 부족

❌ 간단한 ERD 라고 만들어놓고 코드를 다시 검수하지 않은 것.

Try

백엔드개발자로서..

🔥 API 설계의 기본 원칙 다지기 ( HTTP status code 적절하게 사용하기, endpoint 네이밍 신경 쓰기…. 일관성 있고 확장가능한 API 설계하기..)

🔥 에러 처리 및 유효성 검증 ( 무슨 문제가 있을지 모른다. 일단 찍어내)

🔥 더욱 효율적인 데이터 쿼리 모델링에 대해 더 고민할 것. ( 숏커톤이라고 확장성 +보안을 무시하고 코드를 짠 것에 대해 반성중이다..)

팀내에개발자로서..

🔥 소통을 더 할 것, 프론트 개발자들뿐만 아니라 기획자와 디자이너와 소통을 더 많이 할 것.

🔥 프론트 에 대해서도 조금이나마 공부하기. → 필수는 아니지만, 기본적인 부분을 알면 협업할 때 더욱 효과적인 백엔드 개발자가 될 수 있을 것 같다.

🔥 숏컷톤 중 “죄송해요 그거는 안 돼요” 를 다음 해커톤까지 다 공부해 가자. → 안 되는 것이 아니라 못하는 거다. 다양한 데이터를 다루고 좋은 코드가 무엇인지 고민 또 고민하자….

(🔥이모지는 열정 불태워보겠다는..)

결론 = 잘 돌아간다고 좋은 코드가 아니다.

이번 숏커톤처럼 빠르게 결과를 만들어야 하는 상황에서는 "돌아가는 코드"가 우선일 수 있지만, 그 외에는 문제가 될 수도 있다. 하지만 코드가 잘 작동한다는 것은 기본일 뿐, 진정으로 좋은 코드는 그 뒤에 숨겨진 구조, 확장성, 그리고 유지보수성까지 고려가 된 코드를 뜻합니다.

그래서…좋은 백엔드 개발자가 뭐지..? 🧐

좋은 백엔드 개발자는 단순히 서버 코드를 찍어내는 사람이 아닌, 효율적이고 확장 가능하며 안전하며 유지 관리가 쉬운 시스템을 만드는 “문제 해결사”입니다. 하지만 개발은 혼자서 하는것이 아니기에 거기에서 끝나지 않는다고 생각합니다. 진정으로 좋은 백엔드 개발자는 팀원들과의 소통, 사용자 경험에 대한 이해, 그리고 끊임없는 학습을 통해 더 나은 서비스를 제공하려는 자세를 갖춘 사람이라고 생각합니다.

이번 숏커톤을 통해 "잘 돌아가는 코드"와 "좋은 코드"의 차이에 대해 고민할 수 있었으며, 부족한 점을 발견하고 성장의 방향성을 잡을 수 있었습니다. 앞으로도 더 나은 개발자가 되기 위해 끊임없이 고민하고 도전할 것입니다. 여러분도 함께 성장해 나가길 바랍니다. 감사합니다!

절망해라, 모든 것이 처음인 범부여 (숏커톤 회고: 첫 협업, 첫 리드 개발자)

안녕하세요! 경북 IT 협업 동아리 PARD 4기 iOS 파트 김도경입니다.

이번에 파드에서 진행한 15시간 해커톤에 참여하게 되었습니다.

저는 펠리컨 팀 iOS 개발자이자 리드 개발자 역할을 맡아서 진행하게 되었는데요.

이번 해커톤을 통해서 느낀 점을 이야기하고자 합니다.

결론부터 말하자면 2등으로 뽑히긴 했지만, 개발자로서 그리고 개발 팀장으로서 실패와 분노 그리고 절망감을 느낀 해커톤이었습니다.

무엇을 만들고자 했나?

저희 펠리컨 팀은 '띠링'이라는 앱을 개발하고자 했습니다. 이 앱은 블루투스 통신을 활용하여 사용자가 서로 가까워질 때 매칭 기회를 통해 자만추의 접점을 만들어 주는 앱입니다.

더 쉽게 설명하면 본인이 연애 가치관, 취미를 설정하고 자신이 원하는 상대방의 가치관 취미를 설정하게 됩니다. 근처에 같은 앱의 사용자가 있고 가치관과 취미가 일정 수준 이상 일치하면 서로의 이상형이 나타났다고 알림을 보내고 상대방의 프로필을 확인 할 수 있습니다.

어쩌다가 이 아이디어가 나왔나?

이번 숏커톤의 주제 하모니에 맞춰서 처음에 저희 팀은 세 가지 정도의 아이디어를 가지고 아이디에이션을 하고 있었습니다. 그중 하나가 연애에 관련된 것이었습니다.

그러다 제가 “서로 가까이 가면 알림을 보내는 거 어떨까? 그 ‘좋아하면 울리는' 알아요?”라고 했고 팀원들이 마음에 들어 하면서 여러 아이디어를 더 붙이게 되었고 이 아이디어에 모두 꽂혀서 확정되게 되었습니다.

핵심기술구현

이 앱을 구현하기 위해서는 먼저 핵심 기능인 가까워졌을 때 알림 보내기가 가능한지 알아야 했습니다.

어떻게 구현해야 할지 처음에는 감이 잡히지 않았습니다, 서버 파트원과 얘기하면서 각자 사용자의 GPS 신호를 지속적으로 서버에 보내고 거리 계산을 실시간으로 하면서 가까워지면 알림을 보내는 방식을 생각했는데 이 방식은 기술적 난이도도 높고 비용 측면에서도 별로 였습니다.

그러다 대화를 듣고 있던 우리의 기획자가 한마디 하였습니다.

“토스에 보면 근처에 토스를 켠 사람이 있습니다 하고 알려주는데 이런 거 안되나요?”

이 말이 정말 큰 힌트가 되어 찾아 보게 되었고 이 기술이 블루투스를 이용한다는 사실을 알게 되었습니다.

“함께 자라기”라는 책에서 ‘삼투압적 의사소통’의 중요성을 말하는데 이를 직접 느끼게 되었습니다. 프로젝트에 관한 내용은 어느 사소한 것이라도 팀원 모두가 같이 공유하는 것이 좋겠다는 깨달음을 얻게 되었죠.

이후 Swift로 이 기능을 구현하기 위해서 여러 자료를 찾아도 보고 GPT에도 물어보았습니다. 먼저 이 기능이 되는지 확인이 되어야 하기 때문에 따로 프로젝트 파일을 만들어서 이 기능만 구현하는 앱을 만들어 보았습니다.

약 한 시간 후에 실제 기기에 연결해서 테스트를 해보는데 알림이 보내졌고 팀은 환호했습니다. 생각보다 굉장히 빠르게 핵심 기능이 구현이되었고 저희 팀은 할 수 있겠다는 생각을 가지게 되었습니다. 하지만 이때 나무만 보고 숲을 보지 못한 저의 판단이 독이 되었습니다. 이는 후에 설명하고 일단 계속 제가 구상한 내용을 설명해보겠습니다.

일단 처음에는 서로 다른 유저가 점점 가까워지다가 블루투스 통신 가능 거리에 들어오게 됩니다.

그러면 이때 서로의 유저 ID를 블루투스를 통해 전송하게 됩니다.

그리고 받은 상대방의 ID를 서버에 보내서 상대방의 프로필을 받아오게 됩니다.

그리고 마지막으로 상대방의 프로필을 자신의 프로필과 비교하여 비슷한 성향을 가지고 있을 때 알림을 띄워 좋아할 만한 사람이 나타났다고 알립니다.

사실 프로필을 비교하는 건 서버에서 하고 알림을 띄울지 말지 정보만 보내주는 게 더 효율적이지 않을까 생각했는데 아직 저희의 실력으로는 무리하고 판단하고 유저의 기기로 가져와 비교하도록 하였습니다.

제가 구상한 구조는 이러했고 완성만 하면 무조건 1등이라는 확신에 팀원 모두가 차있었습니다.

그러나 결과는 처참했습니다.

숏커톤 마감 전 필요한 페이지들이 완성되지도 않았고 서버와의 연결도 계속 문제를 일으켜 미완성인 상태로 제출하게 되었습니다.

무엇이 문제였나?

앱의 사이즈가 너무 컸다.

사실 저희 앱이 15시간 해커톤에서 완성하기에는 너무 크기가 컸습니다.

유저의 정보를 저장하기 위해서는 회원가입도 필요하고 유저의 프로필 작성도 필요했습니다. 그리고 자신의 회원 정보를 로컬에 저장할 필요도 있습니다. 나의 프로필과 상대방의 프로필을 보여줄 페이지 그리고 그것을 위한 서버 연결. 또한 알림을 띄우고 가까운 사람을 표시할 페이지 그것을 위한 서버 연결까지 앱의 사이즈가 너무나도 컸습니다. 거기다가 상대방과 매치가 되면 좋아요를 보낼 수 있도록 해야 했습니다. (심지어 이것도 채팅 기능을 빼고 대체 기능으로 넣은 것).

그리고 이 모든 것을 미리 파악하고 초반에 공유했어야 하는 개발 팀장인 저의 판단 잘못이었습니다.

혹은 개발 중간에 기획자와 디자이너에게 말해서 “이런저런 기능은 빼야 한다.”, “디자인 디테일이 너무 많은 것 같다 이러면 완성이 힘들 것 같다”라고 말했어야 했습니다. 이 모든 걸 너무 뒤늦게 깨달아 버렸습니다.

그렇다면 왜 미리 판단하지 못했나?

모든 것은 경험 부족

어쩌다 보니 제가 리드 개발자를 맡아서 진행하게 되었지만, 저도 이번 해커톤이 저의 첫 협업이었고 Swift를 통해 앱을 만드는 것도 처음, 게다가 리드 개발자를 맡는 것도 처음이었습니다. 그러다 보니 15시간이라는 주어진 시간 내에 어느 정도 크기의 앱을 만들 수 있는지 감각이 없었습니다. 게다가 핵심 기능은 정말 빠르게 구현했다 보니 “이거 해볼 만한데”라는 생각이 들었고, 이는 더 숲을 보지 못하게 만들었습니다.

미리 앱의 전체적인 구조를 생각해 보고 이것이 시간 내에 구현 가능한지를 파악 했어야 하는 문제점이 있었고 또 하나는 시간 내에 완성하지 못할 요청 사항들을 미리 말하지 못했다는 것입니다.

사실 저희 팀의 기획자와 디자이너분들은 본인 맡은 일에 최선을 다했습니다. 기획자가 생각하기에 필요한 기능들을 추가하고 디자이너가 생각하기에 시각적으로 뛰어난 디자인을 최선을 다해서 만들어 주었습니다. (퀄리티 보고 진짜 놀랐습니다)

하지만 개발자의 시각에서 이 모든 것을 다 수용하여 주어진 시간내에 만들기는 무리였습니다. 제가 미리 이것 눈치채고 말을 했어야 하는 부분이었지만 앞서 말했듯 경험 부족으로 이를 뒤늦게 알아버렸습니다.

해커톤 후반에는 어떻게든 완성 시켜야 한다는 생각에 사로잡혀 기획자에게 진행 사항도 제대로 전달 해 주지 못했고 같은 개발 팀원들을 신경 쓰지도 못했습니다. 특히나 리드 개발자로서 다른 개발자 팀원이 어려운 게 있진 않은지 도와줄 게 없는지 더 신경 써야 했는데 제 코가 석 자라 신경을 못 쓰고 제 일에 붙잡혀 있었던 게 미안했습니다.

분노 그리고 현타

이렇게 앱을 완성하지 못하게 되자 너무 분노와 절망감이 치솟아 올랐습니다. 하지만 또 다른 분노와 현타가 저를 사로잡았습니다.

내가 짠 코드가 한 줄 도 없다.

비교적 쉬운 부분인 UI 만드는 부분은 다른 iOS 팀원에게 맡기고 저는 조금 더 난이도가 있는 블루투스 통신, 서버 연결, 온보딩을 맡아서 했습니다. 하지만 이것들은 대부분 저도 처음 해보는 거라 GPT의 도움을 받아서 할수밖에 없었습니다.

그렇게 코딩을 하고 끝나고 보니 제가 직접 짠 코드가 몇 줄 되지 않는다는 사실을 알게 되었고 저 자신에 대한 무력감과 분노를 느꼈습니다. 역설적으로 GPT가 없었으면 핵심 기능을 만들지도 못하긴 했습니다. 하지만 알고 AI를 쓰는 것과 모르고 AI를 쓰는 것에는 많은 차이가 있습니다.

사실 파드 세미나에서 배우는 내용은 정말 기초적인 내용들입니다. 앱 다운 앱을 만들기 위해서는 제가 더 추가로 공부를 하고 토이 앱도 만들어 보면서 익혀나갔어야 하는 부분입니다.

나는 절망과 분노로 성장한다

이번 숏커톤을 통해서 제가 부족한 부분들이 어떤 것들인지 알게 되었고 저의 성장 방향도 뚜렸해졌습니다. 또 같은 일을 반복하지 않기 위해서 저는 이번 경험을 통해 나아갈 것입니다. 왜 흔히들 숏커톤이 예방 주사라고 하는지 알게 되었고 정말 값진 경험이었습니다.

나중에 이 글을 보는 후기 기수 파디들에게 전하고 싶은 말

1. 숏커톤에서는 정말 정말 간단한 앱을 만들어야 한다

2. 기획자, 디자이너, 개발자 모두 욕심과 완벽함은 조금씩 포기해야한다

3. 개발자들은 자신이 시간내에 완성이 가능한지 판단하기에는 경험이 없다. 기획자들은 이를 염두에 두어야 한다.

4. 개발자들은 세미나에 배우는 내용외에 추가적으로 공부를 해야 기획자와 디자이너가 원하는 앱을 만들 수 있다.

5. 클백 연결 공부 해라

PARD란 파도를 타는것

안녕하세요 포항시 IT 협업동아리 PARD에서 4기 iOS파트장을 맡고 있는 김현중이라고 합니다.

저는 2기 웹파트, 3기 iOS파트를 경험하고 4기에 운영진으로서 합류하게 되었는데요,

사실 파디 시절에 경험하지 못하고 중요시 하게 여기지 않았던 "pay it forward"란 가치에 대해서 이야기하고 싶었습니다.

Pay it foward란?
실리콘밸리의 문화로서 “누군가 나에게 도움을 청했을 때 댓가를 바라지 않고 기꺼이 도와주는 문화”라고 정리할 수 있습니다.

당연히 저는 개발자로서 기술 스택을 쌓고 싶었고 PARD의 Pay it forward 가치를 보고 경험하고자 지원하고 싶은 마음은 거의 없었습니다. 나도 살기 바빠 죽겠고 할일들이 산더미같이 쌓였는데 굳이 남들을 도와주자고? 제 마음에 그 여유 조차 없었고 하고 싶지도 않았습니다.

그럼 제가 왜 남들을 돕고자 하는 운영진의 자리에 있을까요??

PARD의 역대 운영진들을 보면 답이 나올 수 밖에 없었습니다. 그저 저는 대단해보였습니다. 누구보다 바쁘고 PARD를 이끌어 나가기 위한 회의들, 등등 삶의 여유가 없는 그들은 학교 뿐만 아니라 이곳저곳에서 남들을 돕고, 돕고, 또 돕고있는 모습들 밖에 보이지 않았습니다. 왜 저렇게 까지 할까? 많이 힘들거 같은데? 라는 생각이 들면서도 제가 직접 그들에게 도움을 장소 시간 불문하고 받으면 느끼는 것은 "내가 이렇게 받은 도움과 사랑을 다른 곳에서도 그들처럼 베푸는 사람이 되어야겠구나" 였습니다.

한 사람이 세 명을 도와주면, 그 세명이 각자 다른 사람들을 도와주겠죠? 이 연결고리가 계속 이어진다면 결국 저에게도 좋은 일, 세상이 돌아올것이라고 생각합니다.

중요한 것은 서로에게 Pay it forward를 이끌어 내기 위해서는 "도움을 청할 줄 아는 사람"이 되어야 한다고 생각합니다. 도움을 청하지 않고서 남들이 자신에게 와서 도움을 주기 바라는 것은 잘못된 생각인것 같습니다.

저는 지금 PARD란 파도를 타고 있는 파디, 운영진, OB 여러분 모두가 자신의 성장보다는 Pay it forward란 가치를 추구하며 살아가는 사람들이 되어 PARD 뿐만 아니라 세상에 도움이 되는 사람들이 되길 바랍니다!!
4기 화이팅!!!

(LDJ를 아세요?) 돌아본다는 것

서론

안녕하세요! 포항시 IT 협업 동아리 PARD에서 4기 웹파트원으로 활동 중인 정민찬이라고 합니다.

여러분들은 복습에 대해 어떻게 생각하시나요?

'했던 것을 또 하는 행위?'일까요, '좋은 성적이나 성과를 받기 위한 수단?'일까요? 사실 복습이라는 행위를 단순 반복이 아닌, 나 자신을 돌아보는 일로서 의미 있게 바라본 적은 많지 않을 겁니다.

우리 삶에서 복습은, 단순히 학습 내용을 되돌아보는 것뿐 아니라, 나 자신이 어떻게 성장하고 있는지, 어떤 방향으로 가고 있는지를 되짚어 보는 회고의 과정이 될 수 있습니다.

이번 글을 통해 복습의 의미를 조금 더 깊이 있게, ‘돌아본다’는 것의 진정한 가치를 함께 생각해보고자 합니다. 저도 처음 해봐요~ 이 글이, 단순한 반복을 넘어 '회고'와 '성장'의 기회로서 나를 돌아보는 시간이 되었으면 합니다.

본론

복습은 그저 학습에 국한되어 있지 않습니다. 복습을 통해 자신의 성장 과정, 방향, 나아가 삶의 목표를 점검하는 기회로 활용할 수 있습니다.

여기서는 복습과 회고를 통해 삶의 방향을 찾고, 한층 더 발전된 사람으로 성장하기 위한 몇 가지 방법을 나눠보겠습니다~

1. 반복을 통한 자신과의 대화
   복습은 과거의 자신과 대화하는 과정입니다. 그날 배운 것들을 되돌아보고, 이를 나의 언어로 풀어보는 것, 그리고 이것을 '왜' 배우고 있는지 되돌아보는 것이 중요합니다. 이 과정을 통해 단순히 정보를 반복하는 것을 넘어서, 자신만의 의미를 부여하는 힘이 길러지게 됩니다.

2. 삶에 적용하는 회고 습관
   복습뿐 아니라, 일상에서도 주기적으로 자신을 되돌아보는 회고 습관을 가져보세요. ‘내가 가고자 하는 방향이 맞는가?’, ‘지금 어떤 목표를 향해 나아가고 있는가?’ 같은 질문은 내가 진정으로 원하는 길을 찾도록 도와줍니다. 이러한 회고는 개발자나 디자이너로서 뿐 아니라 한 사람으로서 성장하는 데 큰 도움이 됩니다.

3. 10000시간의 법칙?

   김창준 저자의 함께자라기에서 언급되는 10000시간의 법칙을 들어보셨나요? 단순히 그 시간을 채운다는 것이 아니라, 이 시간을 통해 자신의 부족한 점, 어려운 부분들을 채워나가는 과정이라는 것입니다. 그렇게 하나씩 쌓아가다보면 어느덧 자신의 분야에서 빛나는 사람이 되어있을 것입니다.

4. 방향성을 찾는 개발자, 디자이너, PM이 되기
   복습과 회고는 단순히 지식을 쌓는 것 이상의 의미를 가집니다. 우리 삶을 더 나은 방향으로 이끌어줄 나침반 같은 역할을 하죠. 개발자나 디자이너, PM으로서도 이런 회고와 방향성은 필수입니다. 끊임없이 배워가고, 현재 위치를 점검하며 자신이 원하는 목표를 향해 꾸준히 나아가다 보면 더 나은 사람, 더 나은 직업인으로 성장할 것 입니다.

결론

복습은 학습을 넘어, 우리 삶을 돌아보고 성장의 방향을 찾는 중요한 과정입니다. 복습의 의미를 단순 반복이 아닌 삶의 회고로 확장시킬 때, 우리는 한층 더 넓은 시야와 확고한 목표를 가진 사람으로 나아갈 수 있습니다.

자신의 성장을 위한 꾸준한 복습과 회고를 통해 성장 방향성을 찾고, 나아가 목표를 이룰 수 있는 개발자, 디자이너, PM이 되기를 응원합니다~~!

추가적으로 오늘 진행한 세미나에 대해 간단히 복습해보려고 합니다~

오늘 복습한 내용 (돌아본 내용)

LDJ를 아시나요?

정의

• LDJ는 Lightning Decision Jam의 약자로, 의사결정을 위한 방법론 중 하나이다.

방법

• 문제 상황에 대하여 포스트잇에 각자의 의견 작성, 투표하여 최선의 방안을 도출한다.

• HMW(How Might We?)로 개방적이고 포괄적인 질문을 통해 다양한 가능성을 탐색, 솔루션 도출 및 투표

• Resource와 Impact (실행하는 것에 대한 필요한 시간 및 자원, 그에 따른 영향)를 고려하여 포스트잇에 적힌 솔루션을 배치

효과

• MVP (Minimum Viable Product)를 만들기에 최적화 된 방법이다.

• 빠른 시간 내에 의사 결정을 할 수 있다.

• KPT(Keep, Problem, Try)를 통해 팀 내의 목표를 돌아보고 피드백 하여 성장할 수 있다.

끝으로 저의 인생 MOTO를 말씀드리고 글을 마무리 하겠습니다.

급할수록, 도라에몽

언제나 여유를 가지고 있으면 기회는 옵니다!

조직에서 성장하고 싶으면 애사심을 가지세요?

안녕하세요 Pay it forward를 실천하는 IT 협업 동아리 PARD의 4기 디자인 부파트장 김예정입니다.

오늘은 제가 PARD라는 곳에서 운영진을 하며 가지게 된 <애사심>에 대한 글을 써보려 합니다.

'조직원이 애사심을 가지는 것'이 한 조직과 조직원 개인의 성장에 얼마나 큰 영향을 자치 하는지 배우게 되어 이를 짧게나마 나누어 보고 싶었습니다.

애사심이 뭔데?

이야기를 시작하기에 앞서 애사심이란, '몸담고 있는 회사를 아끼고 사랑하는 마음'입니다.

그렇다면 회사 즉, 조직을 사랑한다는 것이란 무엇이며 이러한 마음을 가지기 전과 후는 어떻게 달라지게 되는 걸까요?

좋아하는 것 그 이상의 감정을 가져야 한다고?

디자이너로서의 성장을 갈망하던 제게 PARD는 깨어 부셔지며 성장할 수 있는 모든 환경을 조성해주었고, 파트원이 수행해야 하는 모든 활동에 최선을 다하여 참여한 결과, 저는 성장했습니다. 정확히는, 시키는 대로 한 만큼만 성장 했습니다.

6주간 진행되는 세미나 - 매주 나오는 프로젝트 과제 - 18시간의 짧은 해커톤 - 3주 동안의 긴 해커톤 등, 파트원에게 제공되는 다양한 환경을 통해 PARD에서 얻을 수 있는 건 전부 얻었다는 생각이 듭니다. "이렇게 좋은 걸 나누어 주는 동아리라니!!" 저는 이 동아리가 좋아졌습니다.

성장을 갈망하는 사람들이 이를 누렸으면 좋겠고, 내가 이를 도와주고 싶다는 생각으로 운영진이 되었습니다. 내가 좋아했던 활동들을 그대로 준비하고, 내가 좋아했던 분위기를 조성하려 노력하고, 내가 운영진으로부터 느낀 좋았던 감정들을 똑같이 느끼게 해주려 하고...

그러다 운영진 활동 기간 중반이 되었을 때 즈음, 문득 한가지 생각이 들었습니다.

"난 그냥 이전 운영진의 복제본 같다..?"

애사심의 시작, 조직 안에서 '나'를 세우는 것

복제본의 역할을 할 수 있는 사람이 필요한 거라면, 이 조직에는 '나'라는 사람이 필요한가?

사기가 뚝 떨어졌습니다. 시키는 것만 했고, 무언가 의견을 내려고도 하지 않았습니다.

"제가 이 조직을 위해 뭘 할 수 있나요, 제가 필요한가요?"라고 말하는 제게 조직의 대장님이 하신 말은 "조직을 위해 너만이 할 수 있는 일이 있는데, 너의 이런 능력을 너 스스로가 모르는 게 조금 짜증날 뿐이야"

주어진 환경은 나만이 할 수 있는 다양한 일들을 할 수 있게 도와줄 다채로운 도구들이지, 그대로 따라야만 하는 틀이 아니라는 것이었습니다. 조직 내에서 나만이 할 수 있는 역할을 찾지 않았던 탓에, 이 조직에서 본인 스스로 효능감을 느끼기 어려워졌고, 이것이 조직과 저 스스로의 성장에서 큰 동기 저하로 이어졌던 원인이었습니다.

나를 필요로 하는 곳을 사랑한다는 것은

어쩌면 당연한 말입니다. 사람들은 누구나 자신의 쓸모를 입증하고 싶어 합니다. 그리고 이를 입증할 수 있는 곳은 자신에게 아주 소중한 곳으로 자리하게 됩니다. 조직에서 '나'를 세움으로, 조직을 사랑하게 되는 것입니다.

충성심과 애사심은 엄연히 다른 말입니다. 충성심 만으로는 성장할 수 없습니다. 시키는 것만을 잘하는 역할은 언제든 대체 가능한, 나만이 할 수 있는 역할이 아니라는 겁니다.

내가 잘 하는 것을 찾으세요. 그리고 이를 조직에서 증명하려 무엇이든 시도하세요.

조직에서 제공하는 환경을 도구 삼아 나만이 만들 수 있는 새로운 환경을 만든다면 이곳을 사랑할 수 있게 될 것이고, 결국 조직을 사랑하는 만큼 성장할 수 있게 되는 것입니다.

글을 마무리하며

조직을 사랑하게 된지 3주 남짓 된 사람이 주절댄 글이었는데요.

저는 제 스스로 할 수 있는 이것저것을 시도해보고 있습니다. 우선 저희 디자인 파트원들을 위한 디자인 교재를 제작하고 있는데요, 기회가 된다면 어디 내놓을 수 있을 만큼 잘 제작 하였다면.. 이 또한 나누어 보고 싶습니다.

조직에서 성장하는 데에 한계를 맞닥뜨렸다거나, 혹은 제대로 된 성장을 바라고 있는 분들에게 조금이나마 도움이 되었으면 하는 바람입니다.

내가 할 수 있는 것이라면 무엇이든 일단 시도해보세요 그러면 사랑하게 되고, 성장하게 됩니다.

감사합니다 :)

디자이너의 가장 강력한 힘

안녕하세요, 파드 4기 iOS파트로 활동중인 김도원입니다. 요즘 날씨가 많이 추워졌어요. 밤에는 쌀쌀한 바람이 불고, 새벽에는 찬 공기가 목을 간지럽힙니다. 저는 이런걸 느끼면서, 겨울이 오고 있음을 새삼 느끼는 것 같아요. 여러분은 어떠신가요? 저번의 지식재산권 이야기에서 개발자들의 보호 방법을 알려드렸어요. 오늘은 디자이너들의 보호 방법을 알려드릴게요! 오늘 할 이야기는 조금 어려운 이야기가 많아요. 하지만, 제가 최대한 이해하기 쉽게 풀어서 말씀드리도록 하겠습니다!

물건, 글자, 색, 그리고 디자인

여러분께서, 오랜시간 노력과 정성이 들어간 디자인을 완성했어요. 디자인을 드디어 완성해, 디자인 출원을 위해 특허청을 찾았으나, 특허청에서 출원을 거절한다면 어떨 것 같나요? 아마 참담하고, 노력이 부정당한 그런 안타까운 기분일 거예요. 여러분께 비슷한 사건을 하나 소개할게요.

"특허법원 2007. 10. 4. 선고 2007허5260 판결 [취소판결(디)]" 라는 사건인데, 이 사건을 정말 간단히 설명드릴게요. 이 사건은 한 사업자가 '한증막' 사우나 건물의 모습을 디자인하여 디자인 출원을 하려다 특허청의 출원거절로 법적 소송까지 간 사건이에요. 사우나 건물을 오랜시간 노력과 정성을 들여 디자인 했음에도 불구하고, 디자인 출원이 되지 않은 셈이죠. 사실 이 사건은 디자인을 디자인보호법으로 보호하기 위한 요소가 불충분했기 때문에 실패한 셈이에요. 그렇다면 어떻게 해야 디자인을 보호받을 수 있을까요?

디자인보호법이란?

디자인보호법은, 쉽게 말해서 디자이너들의 디자인을 보호하기 위한 법입니다. 이름만 보셔도 대충 아시겠죠? 그래서, 이 법이 어떻게 여러분의 디자인을 보호할 수 있을까요? 나아가, 디자인보호법으로 보호받으려면 어떻게 해야할까요?

디자인보호법은 여러분의 디자인을 여러분 자신이 아닌 다른 이들이 상업적으로 사용하지 못하게 보호해주는 법이에요. 보호 기간은 등록일로부터 20년간이나 보호해주죠. 이 법으로 보호를 받게 된다면 그 디자인은 여러분 허가가 있는 사람을 제외, 20년간 아무도 상업적으로 사용할 수 없어요. 만일, 내가 등록한 디자인과 똑같은 디자인을 사용하고 있는 사람을 본다면, 소송을 걸어 더 이상 사용하지 못하게 막을 수도 있어요. 여러분이 주인으로 인정받는 것과 같습니다. 정말 막강한 힘이죠. 그러면 어떻게 해야 등록함과 동시에 보호받을 수 있을까요?

디자인보호법을 밑에서 자세히 살펴볼게요.

디자인보호법의 정의 (1)

"제2조(정의)이 법에서 사용하는 용어의 뜻은 다음과 같다.

1. “디자인”이란 물품[물품의 부분, 글자체 및 화상을 포함한다. 이하 같다]의 형상, 모양, 색채 또는

이들을 결합한 것으로서 시각을 통하여 미감(美感)을 일으키게 하는 것을 말한다."

라고 정의하고 있어요. 이 조항은 정말 중요합니다. 여기서 디자인보호법상 디자인의 4요소가 들어가 있기 때문이에요. 바로 물품성, 형태성, 시각성, 심미성의 4요소인데요. 조금 어렵죠? 제가 좀 더 쉽게 풀어서 써 볼게요.

디자인보호법의 정의 (2)

위에서 설명한 디자인의 4요소는 디자인보호법상 디자인의 정의에요. 저 4요소를 모두 인정받아야 디자인보호법의 보호를 받을 수 있다는 말과 같죠. 물품성은 '독립성이 있는 구체적인 유체동산'이라는 말인데, 조금 어렵죠. 제가 쉽게 예시를 들어 써 볼게요.

물품성 : 공장에서 찍어낼 수 있을 정도의 물품이며, 물품은 거래가 가능할 정도의 독립적이어야 합니다.

형태성 : 물품의 형상, 색, 모양이 결합된 것으로, 물품의 형태와 같아요.

시각성 : 육안으로 식별할 수 있는 것, 즉 눈으로 볼 수 있어야 합니다. 눈으로 보이지 않는 것은 디자인으로 인정받을 수 없어요.

심미성 : 미적 처리가 되어 있는 것, 즉 눈으로 보았을 때 물품의 디자인이 조잡하지 않고, 완벽해야합니다. 여기서 미적 아름다움의 가치는 상관없으나, 조잡했을 때는 문제가 생기겠죠?

말씀드린 4가지의 요소를 모두 인정받아야 디자인으로 출원했을 때 문제없이 등록할 수 있는 가능성이 높아요. 제가 위에서 말씀드린 한증막 디자인 사건은, 위 4가지 요소 중 물품성이 인정되지 않았습니다. 디자인이 아닌, 부동산으로 인정받았기 때문이죠.

요약하자면, 디자인보호법상 디자인은 저 4요소를 모두 포함해야 합니다. 저 4요소 중 하나라도 포함되지 않으면 디자인보호법으로 보호받을 수 없어요.

어렵죠? 하지만 알고 계시면 좋아요

어려운 내용을 여러분께서 최대한 이해하기 쉽도록 풀어서 써 봤는데, 어떠셨으려나 모르겠네요. 모두 이해가 갔다면 정말 다행이지만, 아직은 모르셔도 괜찮아요. 그래도, 조금이나마 이해가 가셨으면 좋겠어요! 기술이 너무나 빠르게 발전하는 오늘날에는 알고 있는 만큼 힘이 되기 때문이고, 내 노력을 보호받을 수 있는 가장 강한 보호수단 중 하나이기 때문이에요.
감사합니다!

뉴닉을 아시나요~ (역기획)

안녕하세요, 한동대학교에서 IT 협업 동아리 PARD의 4기 서비스 기획파트 김희민입니다.
저번 주에 처음으로 역기획 스터디를 진행했는데, 시간이 없어 발표를 못해 여기 간단히 기록해보려 합니다. (사실은 이 서비스를 N년동안 이용하면서 너무 좋아 추천 & 공유하고 싶어서 가져왔습니다ㅎㅎ! )

서비스는 바로 뉴닉(NEWNEEK)입니다. 뉴닉은 바쁜 밀레니얼 세대를 위해 쉽고 재미있게 뉴스를 접할 수 있도록 만든 뉴스레터 서비스입니다.

제가 역기획 한 것을 간단히 정리해 보겠습니다.

뉴닉의 시작 배경 & 문제 정의

배경: 

• 밀레니얼 세대를 위한 시사 뉴스레터 서비스로, 2018년에 김소연 대표가 창업

• "젊은 애들은 뉴스 안 봐"라는 인식에 대한 문제 의식에서 출발

To be

세상 소식에 관심을 가지고 있는 젊은 세대가 쉽고 재미있게 뉴스를 접할 수 있는 환경 조성되어야 한다.

As is

기존 뉴스 매체의 접근성 및 흥미도 부족으로 인해 젊은 세대의 뉴스 소비율이 저조하다.

5 Whys

문제 의식: "젊은 세대들은 뉴스를 잘 보지 않는다"

왜 젊은 세대는 뉴스를 잘 안 볼까?

→ 뉴스를 읽고 이해하려면 사건의 배경과 전말을 담은 기사를 여러개 찾아 읽어야 하지만, 그럴 시간이 없으며, 막상 읽으면 어렵고 지루하기 때문

왜 뉴스가 어렵고 지루하다고 느끼는가?

→ 기성 세대에 맞춘 어젠다, 스토리 없는 팩트 위주의 기사들, 신문 시대에 맞춰진 신문 문법, 한자어/전문 용어와 딱딱한 말투 등을 주로 사용하기 때문

왜 주로 기성 세대에 맞춘 어젠다로 뉴스가 작성되는가?

→ 주 독자층이 중장년층에 집중되어 있어 젊은 세대의 니즈를 고려하지 않기 때문

왜 젊은 세대의 니즈를 고려한 새로운 뉴스 서비스가 필요할까?

→ 세상 소식에 관심은 있지만 기존 뉴스 매체로는 접근하기 어려운 밀레니얼 세대의 니즈를 충족시켜야 하기 때문

왜 젊은 세대에 맞춘 뉴스 전달 방식이 중요할까?

→ 바쁜 일상 속에서도 복잡한 사회 이슈를 이해하고 쉽고 편리하게 뉴스를 접할 수 있기 때문

Solution:

“뉴스를 통해 세상을 알아가고 싶은 사람들이 보다 쉽고 재미있게 이해할 수 있는 뉴스를 제공한다.”

1. 통통 튀는 대화체 방식: 복잡한 이슈를 쉽고 재미있는 문체로 설명하며, 이모티콘과 밈 등 젊은 세대의 문화 코드를 적극 활용해 흥미를 유발하고 거부감을 줄인다.

2. 맥락 제공 및 균형 잡힌 큐레이션: 사건의 맥락을 대화체로 소개하고, 독자들의 관심을 충족시키기 위해 "알아야 할 뉴스"와 "알고 싶은 뉴스"의 균형을 맞춘다.

3. 편리한 뉴스 소비 경험: 월~금 아침마다 뉴스레터를 발송하여 바쁜 밀레니얼 세대가 정기적으로 뉴스를 접할 수 있도록 한다.

4. 브랜딩: 뉴닉을 라이프스타일 브랜드로 포지셔닝하고, 고슴이 캐릭터를 통해 정서적 유대감과 충성도를 높인다.
   

Function:

1. 이메일 뉴스레터 

   • 발송 주기: 주 5회(월-금) 아침 7시에 이메일 발송.

   • 콘텐츠: 주요 뉴스 3-4개를 쉽고 재미있게 요약 제공.

   • 1분 뉴스: 바쁜 사람들을 위해 간단한 1분 뉴스 제공.

   • 톤: '고슴이' 캐릭터가 친구에게 편지를 쓰는 듯한 친근한 문체.

   • 접근성: 웹 앱을 통해 모바일에서도 동일한 콘텐츠 이용 가능.

   • 주제: 시사, 경제, 국제 등 다양한 분야의 뉴스 포함.
     

     

2. 뉴스 아카이브

   • 과거에 발행된 모든 뉴스레터를 검색하고 열람할 수 있는 기능

   • 주제별, 날짜별로 뉴스를 분류하여 원하는 정보를 쉽게 찾아볼 수 있음

3. 하이퍼링크

   • 각 뉴스 기사 내에 관련 용어 및 배경 정보에 대한 하이퍼링크 제공.

   • 링크 클릭 시 추가 설명이나 과거 관련 기사로 연결.

   • 독자들이 원하는 만큼 깊이 있는 정보 습득 가능.
     

성공 요인

1. 구독자 피드백: 설문지를 통해 사용자 피드백을 적극 반영하여 서비스 개선. 예를 들어, 구독자 의견에 따라 뉴스레터의 톤을 반말에서 존댓말로 변경.

2. 정확한 타겟팅: 밀레니얼 세대 직장인의 특성과 니즈를 파악해 기존 뉴스 매체가 놓친 요구사항을 충족시켜 차별화. (디커플링..?)

3. 차별화된 콘텐츠 (친근함): 쉽고 재미있는 문체로 독자들의 호응을 얻어, 딱딱한 뉴스에서 벗어난 친근한 뉴스 제공.

4. 브랜딩 (마스코트 고슴이): '고슴이' 마스코트를 활용해 긍정적인 뉴스 소비 경험을 만들고 브랜드 충성도 높임.

5. 플랫폼의 선택 (이메일): SNS 대신 이메일을 통해 루틴에 스며들기 쉽고 구독자와의 친밀한 관계 형성. 밀레니얼 세대가 사용하는 직접매체로, 사용자와의 소통을 강화해 평균 100~300건의 답장이 오가는 구조.

인사이트

뉴닉의 사례를 통해, 문제는 우리의 일상 속(가까이)에 있으며, 이를 파악하는 것이 얼마나 중요한지를 깨달았습니다. 만약 단순히 "젊은 사람들은 시간이 없어서 뉴스를 잘 읽지 않는다"라는 표면적인 문제 정의에서 그쳤다면, 뉴닉과 같이 많은 사용자들이 필요로 하는 서비스는 탄생하지 못했을 것입니다.

그러나 뉴닉은 문제의 본질을 파고들어 뉴스가 어렵고 지루하게 느껴지는 이유, 기성 세대 중심의 어젠다 설정, 젊은 세대의 니즈를 고려하지 않는 기존 매체의 한계 등을 발견할 수 있었습니다. 이렇게 문제의 근본 원인을 탐구하면서 진정으로 소비자가 원하는 것이 무엇인지, 그들의 니즈를 명확히 파악할 수 있었고, 이는 결과적으로 밀레니얼 세대의 특성과 요구사항에 맞춘 차별화된 뉴스 구독 서비스로 이어졌습니다.

뉴닉의 사례를 분석하면서, 이미 답이 나와있는 것들을 분석하는 것도 쉽지 않았습니다. 서비스의 시작점과 현재 상태는 알 수 있었지만, 그 사이에서 어떤 질문들로 5 whys를 던져 해결방안을 도출했는지, 그 과정을 역추적하는 것이 어려웠습니다. 정답과 결론을 알고 있음에도 불구하고, 이 과정은 생각보다 복잡하고 도전적이었습니다.

이를 통해 성공적인 서비스 기획을 위해서는 표면적인 문제 인식을 넘어, 끊임없이 "왜?"를 질문하며 문제의 본질을 파고드는 자세가 필수적이라는 것을 배웠습니다. 저번 포스트에서 언급했던 것처럼, 뾰족한 문제 정의를 위해서는 최소 5번의 "왜?"를 던져야 합니다. 이러한 접근 방식이 좋은 솔루션과 사용자들의 진정한 공감을 이끌어내는 핵심임을 다시 한번 느꼈습니다.

개발자들이 "1일 1커밋"으로 잔디를 심는 것처럼, 기획자 역시 지속적인 역기획이 필요하다는 점을 깨달았습니다. 앞으로 2번의 스터디가 남았지만, 스터디가 끝난 후에도 일주일에 하나씩 역기획을 스스로 해볼 계획입니다. 다양한 사례를 통해 기획 역량을 키우고, 더 나은 기획자가 되기 위해 노력하겠습니다!

그리고 여기 뉴닉 뉴스레터 구독 링크 첨부합니다~
할 일 많아도 세상 소식은 놓치기 싫은 사람들 구독 기리릿~

https://newneek.co/subscribe 

XCode 단축키

VSCode, IntelliJ 로 코딩하다가 Xcode로 코딩을 하면 참 안되는게 많다고 느껴요

그런 분들을 위해 준비했습니다. Xcode 단축키 모음집!!

노션 단축키가 궁금하신 분들은 링크 참고해주세요!

기본적인 ⌘(command) +C , ⌘(command) +V 같은 단축키는 생략하겠습니다.

빌드

• ⌘(command) + R : 프로젝트 실행

• ⌘(command) + . : 실행중인 앱 강제 종료

• ⌘(command) + ⇧(Shift) + K : 프로젝트 클린

• ⌘(command) + B : 프로젝트 빌드

네비게이션

여기 왼쪽 창입니다.

• ⌘(command) + 0 : 좌측 네비게이션 show/hide

• ⌘(command) + 1~9 : 좌측 네비게이션 이동 (순서대로)

• ⌘(command) + ⇧(Shift) + J : 현재 파일 좌측 네비게이션에 포인터

저는 ⌘(command) + 1로 파일을 찾은 뒤 ⌘(command) + 0으로 네비게이션 창을 닫습니다.

• ⌘(command) + ⇧(Shift) + Y : 하단 로그창 show/hide

  이 창도 은근 화면을 가려서 필요할때만 보고 닫습니다.

코드 관련

• ⌃(control) + I : 코드 정렬

• ⌘(command) + / : 해당 라인 주석

• ⌘(command) + ⌃(control) + E : 변수/함수명 한번에 바꾸기

• ⌘(command) + ⌥(option) + ←(→) : 코드 접기/펼치기

• ⌘(command) + ⌥(option) + [] : 행 단위 위/아래 이동

• ⌘(command) + D : 현재 줄 복사

• ⌃(control) + ⇧(Shift) + 클릭 : 멀티 커서

• ⌘(command) + ⇧(Shift) + [ ] : 열려있는 페이지 왼쪽, 오른쪽 방향으로 이동

검색

• ⌘(command) + F : 현재 창 검색

• ⌘(command) + ⇧(Shift) + F : 프로젝트 전체 검색

파일 관련

• ⌘(command) + ⇧(Shift) + N : 새 프로젝트 열기

• ⌘(command) + O : 기존의 프로젝트 찾아서 열기

• ⌘(command) + N : 새 파일 열기
  

여기까지 제가 자주 쓰는 단축키들입니다. Xcode의 다른 단축키나 나만의 꿀팁이 있다면 댓글 달아주세요! 👍🙂

매일매일의 중요성

어렸을 때부터 부모님께 항상 들었던 말씀이 있었다. "매일매일 하는 것은 매우 중요하단다!"

"1.01을 365승하면 38배 지만 0.99를 하면 0.03이란다." 이런 말을 들으며 꾸준히 하는 것은 너무 중요하다라는 말을 참 많이 들었어요.

100% P 성향인 저는 그것을 새겨듣지 않고 그날그날 제가 생각나는 대로 살았던 것 같습니다. 그래서 꾸준함이란 없이 손에 잡히는 대로 마구잡이로 살았어요.

처음엔 이렇게 사는 것이 즐거웠어요. 내가 하고 싶은 걸 하고, 매일 다른 일이 벌어지니까... 근데 이제 슬슬 취업을 준비할 시기가 되었는데 내 손에 보니 남는 것이 없다는 느낌이 많이 드는 것 같습니다.

개발자는 1일 1커밋이라고 위에 처럼 하루에 하나의 커밋을 올리는 것을 하여 매일 깃허브에 흔적을 남기는 습관을 쌓는다고 하는데....

제 깃허브를 보시면 아주 시원하게 뻥뻥 뚫려 있는 것을 볼 수 있습니다.

매일 개발을 하기도 어렵고, 그때마다 커밋을 채우는 것도 만만치 않다 보니 더 막막해졌습니다.

또한, 그저 빈 커밋만 채우는 것도 마음에 걸렸습니다. 정말 아무것도 안 했는데, 커밋을 위해 억지로 기록을 남기는 건 제 양심에 찔리더라고요. 매일같이 "아, 지금은 시험기간이니까 개발 안해도 되겠지..," 또는 "오늘은 이미 시간이 많이 지났으니 내일 하자…" 같은 핑계를 대면서 미루기 일쑤였습니다.

이런 제가 바뀌고 싶어, 책이나 유튜브를 통해 매일 꾸준히 하는 방법을 찾기 시작했고, 저에게 맞는 방법을 발견했습니다. 그래서 오늘 이 글을 통해 공유하고자 합니다.

1. 목표 설정하기 : 꾸준히 1일 1커밋과 백준 문제 풀기

   제가 설정한 목표는 간단합니다. 매일 1커밋을 유지하고, 백준에서 하루에 문제 하나씩 풀기. 이 목표는 그 자체로 크지 않지만, 중요한 것은 꾸준히 실천하는 것입니다. 백준 허브라는 좋은 도구가 있어 백준 문제를 풀면서 커밋도 함께 기록할 수 있다는 점이 큰 도움이 되었습니다.

1. 2분 이하로 정말 쉬운 시스템 만들기 : 브론즈 문제 하나로 시작하기

가장 중요하게 생각한 건 '쉬운 시스템을 만드는 것' 이었습니다. 아무리 피곤하고 시간이 없어도 부담 없이 접근할 수 있는 방법이 필요하다고 느꼈어요. 그래서 제가 정한 시스템은 ‘아무리 힘들어도 백준 브론즈 문제 하나 풀기’입니다. 브론즈 문제는 간단한 문제라면 10분 안에 해결할 수 있어서 부담 없이 실천할 수 있습니다. 이렇게 하면 그날의 목표를 이룬 것 같은 성취감도 느낄 수 있고, 무언가를 매일 해냈다는 기록도 남길 수 있더라고요.

이제 막 시작한 시스템이지만, 조금씩 매일의 힘을 알아가고 있습니다. 중요한 것은 거창한 목표가 아니라 작은 일이라도 꾸준히 해보는 것이라는 걸 배웠어요. 저처럼 매일의 꾸준함이 어려운 사람이라면, 부담 없는 목표부터 작게 시작해보는 건 어떨까요? 완벽하지 않아도, 매일 한 걸음씩 나아가며 나만의 발자국을 남기는 과정이 될 테니까요.

개발 배운 지 1년만에 1인 개발자로 대학교 온라인 졸업전시회 운영하기

안녕하세요, 포항시 IT연합동아리 PARD 2기로 작년 9월에 처음 프론트엔드 개발을 배웠던 박민지입니다.

이번에 한동대학교 콘텐츠융합디자인학부 제 26회 졸업식의 온라인 전시회를 혼자 개발하게 되었는데요.

어떤 부담감이 있었는지, 또한 어떤 성과를 내었는지 공유해보고자 합니다.

큰 부담이었던 개발 문의

올해 한동대학교에서는 종이도록을 없애고 제1회 콘텐츠융합디자인학부 온라인 졸업전시회를 기획하였고, 디자인학부는 PARD에 문의하였습니다.

당시 PARD 3기 WEB 파트장을 맡고 있었던 저였지만, 실력적으로 부족한 부분이 많았기에(성능개선이나 배포의 경험 등 부족함 투성이) 학부 측 문의에 주저함이 많았습니다.

또한 하게 된다면 감당해야 하는 요소들이 많아서 저는 불가능할 줄 알았습니다.

제1회 온라인 졸업전시회

전교생, 교수, 이해관계자, 산학협력관계자에게 쉽게 노출되는 웹사이트

높은 성능 보장

졸업전시 웹사이트에 걸맞는 인터렉션

개발 기간 : 한 달

PARD라는 동아리를 걸고..

위와 같은 부담감들을 느끼는 동시에 마음 한편에는 "내가 저걸 다 해내면 나는 정말 많이 성장해 있겠다."라는 확신이 있었습니다. 피하고 다른 것을 한다고 더 성장할 것이라는 자신감이 없었습니다.

따라서 저는 저 부담감을 기회로 여기고 1인 개발자로 온라인 졸업 전시팀에 합류하였습니다.

쉽지 않았던 1인 개발자의 시간들

이미지 최적화, AWS 배포, CI/CD

막상 하고 나니 자신감이 생겼지만, 시작하기 전에는 저를 두려움에 빠뜨렸던 세 가지 Tasks입니다.

1년 동안의 노력과 열정이 담긴 디자이너들의 작품을 긴 로딩 없이 빠르게 화면에 띄우기 위해선 이미지 최적화가 필요했고, CDN 구축을 위해 AWS 배포를 진행해야 했으며, 배포 이후 효율적인 개발을 위해 CI/CD 역시 구축해야 했습니다.

하지만 퍼블리싱 위주의 프로젝트만 했던 저는 위 내용들을 다룬 경험이 없었기 때문에 저에게 정말 도전적이었고, 매일 밤을 새우며 어떻게든 해내려고 노력했습니다.

(CI/CD 구축하다가 S3에 저장해놓은 디자이너들의 작품들이 다 날아갔던 그날은 기억하고 싶지 않네요..)

(배포 이후 생겼던 이슈를 해결하고 신나서 찍었던 사진입니다..ㅎㅎㅋㅋ)

못할 것만 같았던 일들을 하나씩 순차적으로 해결하니 자신감도 생기고, 더 열정적으로 개발했던 것 같습니다.

위의 내용 말고도 여러 트러블슈팅을 겪었습니다. 잘하시는 분들 앞에 내놓기 부끄럽긴 하지만 저의 고민의 목록들입니다. 모르거나 오류가 나는 부분들을 적어두고 -> 완료로 바꾸는 그 쾌감이 너무 좋아서 공유해봅니다 :)

(나름) 성공적으로 운영하기

10월 21일, 웹사이트 오픈 날이 다가왔고, 한동대학교에서는 콘텐츠융합디자인학부 제26회 졸업전시회가 10월 21일부터 28일까지 진행되었습니다.

제가 만든 웹사이트가 졸업전시회 한쪽 벽면에 쫙 깔렸는데, 실제 사용자들이 사용하는 웹사이트라 뿌듯하기도 하며 걱정도 되었습니다. 다행히 디자인학부 담당 교수님에게도 웹사이트에 대한 칭찬을 아끼지 않으셨습니다.

전시 기간에도 사용자들의 피드백을 받으며 리팩토링과 오류 또한 여러 번 고쳤던 것 같습니다. 확실히 피드백을 받고 개선하니 짧은 기간 동안 웹사이트가 더 나아지는 경험을 할 수 있었습니다.

또한 저 역시 후배들과 동기, 그리고 선배들의 졸업 전시를 축하하기 위해 포항에 방문하고 웹사이트 전시 공간도 다녀왔는데요, 거기서 웹사이트의 주소를 적어가시는 외부인 분들을 보며 더 뿌듯함을 느꼈습니다.

이번 경험을 통해

실전에 강한 사람

짧은 해커톤 프로젝트의 경우, 해커톤 기간에만 몰두하고 놔버리는 경우가 있는데요,

운영되어야 하는 서비스를 개발하다 보니 물러설 공간이 없다는 것을 깨닫고, 끝까지 노력하는 저 자신을 볼 수 있었습니다. 실전 경험을 통해 불가능이라 믿었던 저의 능력을 조금이나마 가능으로 증명해 냈던 기간이었습니다.

두려움은 잠시 뒤로..

저는 해당 프로젝트를 통해 약 1300명이 방문한 웹사이트 경험을 얻게 되었습니다. 두려움 때문에 제안을 거절했다면 얻지 못했을 경험이라고 생각하고, 그만큼 두려움은 선택의 상황에서는 잠시 뒤로 모셔두고(?) 그 이후에 생각해도 되는 것이라고 배웠습니다.

외주가 아닌 같은 팀

해당 프로젝트는 외주 프로젝트인데요. 하지만 저는 제가 더 오래 개발하고 밤을 새우더라도 1년 동안 노력한 디자이너들의 작품을 누구보다 빛나게 하고 싶었습니다. 그래서 개발 업무가 더 생기더라도 웹페이지가 사용자에게 편리하고 작품이 더 잘 드러난다면 어떠한 요구도 마다하지 않았습니다. 어떤 프로젝트이든 요구사항만 처리하는 개발자가 아닌 서비스를 더욱더 빛나게 하는 개발자가 되겠다고 다짐했습니다.

마무리

이번 웹사이트 운영 기회를 얻을 수 있었던 것은 제가 PARD에서 활동했기 때문입니다. 포항시 IT 협업동아리 PARD는 현재 4기까지 열심히 달려와, 이러한 기회들을 만들고 있습니다. PARD에 더 많은 관심과 응원 부탁드리며, 저 역시도 Pay it forward를 실천하기 위해 더 열심히 공부하고 성장하겠습니다.

또한 2024년 한동대학교 제26회 디그리 온라인 졸업 전시는 앞으로 쭉 오픈되어 있을 예정입니다. 웹사이트에 방문하셔서 디자이너들이 1년 동안 노력해서 만든 작품들을 감상하시고 많은 인사이트를 얻어가세요!

감사합니다 :)

UI 용어 'Modal'과 'Pop-up'의 차이를 아니?

UI 용어는 디자이너 뿐만 아니라 기획자도 알면 좋은데요

그러면 디자이너와의 소통이 원활해지고, 기획 의도를 명확히 전달하며 개발팀과의 협업 효율도 높아진답니다

오늘은 UI(User Interface)용어 중 Modal과 Pop-up에 대해 말아볼건데요

먼저 문제를 하나 내보겠습니다!

어떤 게 Modal일까요?

1.

출처 : 네이버 블로그

2.

출처 : EBS

* 정답은 1번 입니다 *

그렇다면 Modal과 Pop-up이 무엇인지 정확히 알아볼까요?

Modal은 사용자가 해당 창을 닫거나 조치를 취해야만 다른 작업을 진행할 수 있습니다

이 창에서 취소나 확인을 눌러야지만 다른 작업을 할 수 있다는 거예요

반면 Pop-up은 창이 뜨더라도 다른 작업을 진행할 수 있습니다

굳이 저 광고 창을 닫지 않아도 다른 작업을 할 수 있다는 거예요

이제 Modal과 Pop-up의 차이를 아셨나요?

모르셨다면 이 글을 읽고 꼭 도움이 되셨으면 합니다 ㅎㅎ

교수님께 들은 비밀 이야기

안녕하세요, 저는 파드 4기 iOS파트 김도원입니다. 다들 잘 지내시나요? 저는 시험이 끝났지만, 여전히 하루하루 바쁘게 뛰어다니며 살아가고 있답니다. 이번 글은, 제가 우연히 알게된 점인데요, 파드 사람들이 알아두었으면 참 좋겠다는 생각이 들어 글을 써봅니다. 시작할게요!

우리가 왜 알아야 해?

이 기사를 보셨는지 모르겠어요. 제 수업인 특허법 수업에서 크게 다루게 되었던 기사인데요,

조금 소개를 드리자면, SY폴라리스라는 기업은 국내 카드사에 카드결제 프로그램인 '안심클릭 솔루션' 이라는 프로그램을 제공하고, 수수료를 받는 중소기업이에요. 하지만 신한카드와 협업한 후, 신한카드에서 자사와 비슷한 프로그램을 개발하여 SY폴라리스 회사에 큰 손해를 입혔다고 주장하는 기사입니다.

우리는 여기서, 우리가 개발한 프로그램, 우리가 만든 디자인, 우리가 생각해 낸 아이디어를 보호하는 것의 중요성을 알아야 해요. 우리가 열심히 만들었는데 다른 이가 도용하면 슬프고 억울하잖아요? 하지만, 미리알고 대비하면 저렇게 될 일도 없겠죠? 또, 여러분이 창업을 하신다고 해도 문제에요. 창업한 회사 스스로 성장한다고 하면 가장 좋지만, 사실 대기업과의 합동 프로젝트가 회사를 성장시키는길의 왕도겠죠? 협업을 할 때, 우리가 만든 것들을 지켜낼 수 있는 방법을 알려드릴게요!

지식재산권이란?

우리는 모두 무언가를 만드는 일을 하고 있습니다. 기획파트면 자신만의 아이디어를 현실로 바꿀 수 있게 구체화하고, 디자인은 자신의 디자인을, 개발은 본인이 직접 개발한 코드를 만들죠. 만약, 우리가 피와 땀, 밤을 새워가며 열심히 만든 이 창작물을 누군가 도용하거나, 막 쓰고 있다는 사실을 보면 어떨까요? 분명 화가 나고, 속상할 것 같아요. 여기서, 우리를 보호해 주는 것이 바로 '지식재산권' 입니다! "엥 그건 저작권 아닌가요?" 라고 물어보시는 분도 있을 것 같아요. 엄밀히 말하자면, 지식재산권 속에 저작권이 속해있어요. 지식재산권이라는 포괄적인 권리 속 다양한 권리 중 하나가 저작권인 셈이죠. 그러면, "결론적으로 지식재산권과 저작권은 똑같은거 아닌가요?" 라고 물어보실 수 있어요.

맞아요! 결과로만 바라보게 된다면 지식재산권과 저작권은 똑같은 권리입니다. 하지만, 지식재산권 속에는 저작권, 산업재산권, 특허권, 디자인권, 상표권 등 다양한 권리가 내포되어 있어요. 저작권만 주장하게 된다면, 보호받을 수 있던 권리들도 보호받지 못하게 되겠죠?

따라서, 지식재산권이란, 우리가 창작한 모든 창작물의 디자인, 특허, 상표 등 상업적 권리와 더불어서 저작권도 포함하는 권리라고 아시면 될 것 같아요.

그러면 어떻게 보호할 수 있나요?

우리는 이제 지식재산권이 무엇인지 알았어요. 그렇다면 이 권리를 어떻게 부여받을 수 있을까요? 또, 저작권은 어떻게 부여받는 것일까요? 사실, 저작권은 내가 창작한 결과물이 생겨나는 즉시 생기는 권리에요. 내가 무언가를 만들었으면, 완성된 즉시 저작권이 부여되는 셈이죠.

그러면 지식재산권은 어떨까요? 반대로, 지식재산권은 조금 어렵습니다. 특허청에 특허, 상표, 디자인권을 신청해서 허가를 받아야 하죠. 맞아요. 비용과 시간이 많이 지출되죠. 하지만, 우리가 열심히 만든, 우리의 자식같은 것들을 그대로 뺏길 수는 없잖아요?

프로그램은 조금 달리 보호할 수 있어요.

제가 들은 이야기는 조금 더 있어요. 바로 디자인과 기획과는 달리, 개발자들은 조금 다르게 보호할 수 있다는 것이죠. 특허를 내는게 가장 좋은 방법이지만, 교수님께서 살짝 이야기해 주신 것들 중 하나는, 코드를 짠 자신만이 알아볼 수 있는 논리적 오류를 살짝 남겨두는, 마치 '이스터에그' 처럼 자기만 알아볼 수 있게 표시를 해 두는 거에요! 예를 들어, 프로그램을 실행시킬 때, 로그에 나만의 시그니처 사인을 남겨두는 식으로 말이죠.

대신, 남들이 모르게 잘 숨겨야겠죠? 다른 사람이 알면 그 부분을 그대로 삭제하고 사용할 수 있으니까 말이죠. 만약, 내가 열심히 개발한 프로그램을 다른 이가 사용하는 것을 보았고, 법적으로 소송이 붙었어요. 근데 본인이 만든 프로그램임을 확신하는 경우, 로그에 들어가 자신의 시그니처를 보여준다면 본인이 개발했다는 것을 증명할 수 있겠죠?

결론적으로, 우리는 모두 알아야해요!

결론적으로, 우리가 만든 창작물은 다른 사람이 대신 보호해 주지 않아요. 우리가 만들었으니 지키는 것도 우리가 지켜야만 해요. 오늘은 지킬 수 있는 방법 중 하나를 여러분께 말씀드렸어요. 감사합니다!

코딩에 ㅋ자도 모르는 사람이 코딩을 한다면?

안녕하세요 저는 IT 협업 동아리 PARD 4기 iOS 파트, 파디 현승훈입니다. 저는 원래 배드민턴 선수를 했었기 때문에 글쓰기에 매우 재능이 없습니다 ㅠㅠ 그래도 재미있게 읽어주세요!

처음에는 컴퓨터 공학과, 코딩과는 거리가 엄청나게 멀 수밖에 없는 그런 존재(?) 였습니다 ㅎㅎ. 학과를 컴퓨터공학과가 아닌 전자공학과로 가자! 라고 했지만 1학년때 전자공학과도 필수로 들어야하는 코딩과목을 접하자 마자, "어...음...음...하 쉽지않은데?" 이거를 달고 살았어요 ㅎㅎ.

그런데 이제 1시간, 2시간을 갈아 넣어서 처음 해내는 문제들에 도파민이 끓어오르면서 "이게.... 코.....딩?..... 맛있다....!" 이런 느낌을 가져서 아직도 코딩에

물론 초반에 제가 코드를 짤 때는 30줄~50줄로 끝내면 되는걸 굳이 굳이 100줄을 넘어가는 이런 노가다를 하고 있더라고요(아래 그림은 짤을 찾아보다가 저랑 너무 똑같아서 넣어봤어요 ㅎㅎ)

😂그땐 몰랐지 내가 개발자를 꿈꾸고 있을 줄은😂

서론이 길어졌지만

원래 할 줄 아는 프로그래밍 언어가 있었냐구여? - 절대 없었죠

그러면 개발자를 어떻게 꿈꾸게 되었나요? - 절대 없었죠

저한테는 프로그래머의 기본 중 기본인 C언어도 처음보는 새로운 언어였죠...

그래도 내가 이 수업을 따라가기 위해서는 많이 찾아봐야 되겠다! 이걸 보면서 코딩에 발을 서서히 담그기 시작했죠..

1. 가장 중요!

   a. 교수님 수업시간 잘 듣기(🖥️교수님께서는 최고의 GPT이다🖥️)

   b. 구글링 (교수님께서 저의 눈높이 교육을 안해주시는 경우가 多) - TCP school

   c. 문제 풀기 사이트(★백준★) --> 진짜 애용 많이 했던...

   d. 유튜브(옆에 뜨는 알고리즘 이악물고(?) 무시하기 약속)

이번에 iOS를 하면서 Swift라는 언어도 처음 배웠는데 하다보면 분명히 막히는 부분이 생기게 된다. 처음부터 무작정 쓸려고 하면 안된다. 파라미터의 유무 + 어떤상황에서 써야되는지 위에서 부터 아래로 내려오는 Flow chart를 머릿속에서 그려서 생각해야한다. 분명히 어렵고 이게 뭐지 싶고 하기 싫어하는 부분이 무조건 생기게 되는데 해보니까 엉덩이 무거운 사람이 이기게 된다.

하다보면 Logic이 이게 뭐고라고 생각할수 있는데

서버파트의 김나임 개발자분의 아티클을 읽었을때 너무 와닿은 문구라 살짝만 인용하면

👨 말하는 언어 vs. 🤖 프로그래밍 언어

사람은 이런 말을 하면 아 숟가락을 집어서 먹으면 되겠네? 라고 생각을 하지만 컴퓨터는 숟가락을 집어서 그릇이 있던 말던 볶음밥으로 이동하게 된다

이런 것처럼 컴퓨터는 생각보다 멍청하다, but 나 같은 개발자가 정확한 문법, 정확한 logic을 넣어주면 똑똑한 친구가 된다(그거를 못해서 문..읍읍)

⭐마무리 결론⭐

이렇게 장문을 처음 쓰다보니까 우당탕탕 끝내는 것 같지만(비밀!)
솔직하게 다른 언어를 시작 못하는 이유는 처음 접하는 언어의 두려움, 시작을 어디서 부터 해야되는지 모르는 것, 등등 이런 이유가 있는데 제가 PARD에 들어오기 전에는 이런 이유들 때문에 무서워서 시작을 못했는데, PARD를 하면서, 예비개발자를 준비하면서 이러한 것들은 결국에 내 자신감 문제구나를 깨달았습니다. 얼마나 어려울까? 를 얼마나 짜릿할까(?)! 로, 뭐부터 시작을 해야될까? 를 뭐라도 시작하자!로 바꾸면 어떻게든 시작을 하게 되더라고요!

Today's me is a stepping stone for tomorrow's improved me.

내일의 발전된 저를 위해서 공부하러 가보겠습니다 ㅎㅎ

긴 글 읽어주셔서 감사합니다!

해야한다면, 다 하게 되더라.

지난 3년간 내가 성장할 수 있었던 가장 큰 마음가짐 이었던 것 같다.

해야한다면, 다 하게 되더라.

전역 후 앱개발자가 되겠다고 다짐하고 난 후 개인, 팀 단위의 프로젝트를 시작할 때마다

사소한 부분부터 큰 부분까지 정말 막막하고 벅차보일 때가 많았다.

다 처음 해보는 일이기 때문이다.

매번 새로운 것을 경험하고 싶었다.

안드로이드, 크로스플랫폼, iOS 개발을 거쳐오면서,

하나만 팔걸, 후회가 되는 부분도 있고, 새로운 것에 지친 적도 있었지만,

그때마다 프로젝트를 완수하기 위해 나에게 많이 외쳤던 것 같다.

“해야한다면, 다 하게 되더라”

내가 벌린 일, 내가 결심한 일이기에 해야했다.

그런데, 돌이켜보면 “해야한다.” 라고 나에게 줬던 압박이

언제나 처럼 내가 생각한 나의 한계를 넘게 해주고,

“다 하게 되더라.” 라고 나에게 줬던 용기가

계속해서 나를 나아가게 했던 것 같다.

지금도 “PARD”라는 동아리의 운영팀으로 있으면서,

프로그램의 기획에 대해서 생각하고, 여러 서류를 작성하고,

아직 부족하지만, 해야할 일을 스스로 찾아야하고,

4년 내내 코딩만 했던 감자에게는 모든 것이 새로운 일이고 도전이다.

내게 맡겨진 일이 생전 처음해보고 겁도 나고, 때론 너무 많더라도

그것 때문에 스트레스 받으면 끝도 없다.

해보지도 않고 겁만 먹으면, 아무것도 못하기 때문이다.

내게 맡겨진 책임감을 위해, 나의 성장을 위해

해야하니까, 해보자. 어차피 다 하게 되니까.

[브랜딩] 나야, IT 협업 동아리 PARD

안녕하세요, 저는 포항시 IT 협업 동아리 PARD의 4기 부회장 이지은입니다.

PARD라는 동아리는 비수도권에서 IT 프로덕트를 만들어볼 수 있는 기회의 장이 부족하다는 문제를 해결하기 위해서 만들어졌습니다. 동아리가 생긴지 이제 2년 정도 되었는데요, 저희가 경험한 문제를 조금이나마 해결하기 위해 짧다면 짧은 시간 동안 여러가지를 시도해보며 저희만의 정체성을 다지고자 노력하는 과정에 있습니다.

이러한 PARD가 계속 지속되고 발전될 수 있으려면, 저희가 가지고 있는 핵심 가치에 공감하고 동참해줄 사람들이 필요합니다. 이름이나 로고에 가치를 녹여내는 것부터, 사람들과 함께 할 수 있는 행사를 진행하는 등 더 많은 사람들에게 가치를 알리고 공감하도록 만들기 위해 PARD가 지금까지 어떻게 시도해왔는지를 공유해보려고 합니다.

PARD

PARD는 PAy it Forward의 약자로, 대가 없이 배운 것을 나누고 나눔이 계속해서 선순환되기를 추구하는 실리콘 밸리의 가치에서 따온 이름입니다.

각각의 알파벳에는 PARD의 다음과 같은 세부 가치를 녹여냈습니다 :

• Passion : 성장을 위해 전진하고 도전하려는 열정

• Adaptability : 함께 일하기 위해 서로를 설득하고 수용

• Responsibility : 선택에 대한, 한 팀으로 기능하기 위한 책임감

• Dream : 실패를 두려워하지 않고 목표를 향해가는 꿈

Logo (Text & Symbol) + 브랜딩 이미지

파드는 텍스트와 심볼로 된 두가지 로고를 사용하고 있습니다.

두가지 로고 모두 PARD의 다양성을 잘 드러낼 수 있는 요소들을 활용하여 디자인 되었습니다.

텍스트 로고는 PARD에 있는 다양한 파트 (기획 / 디자인 / 개발 / 운영 파트)를 표현하고 있습니다. PARD에서는 각각의 파트에서 각자의 하드스킬을 배울 뿐 아니라 다양한 파트가 함께 모여 하나의 프로덕트를 만드는 협업을 할 수 있는데, 각 글자의 색과 폰트 스타일을 다양하게 조합하여 각 파트와 파트 간의 협업을 표현해보고자 하였습니다.

심볼 로고에서도 PARD가 가지고 있는 다양한 조합들을 표현하고자 했습니다. 기획 / 디자인 / 개발 3개의 파트와, 운영진 / 참여진 / 외부이해관계자들로 이루어진 조합을 3개의 마름모로 표현했습니다. 마름모라는 도형은 파드와 발음이 비슷한 파도를 형상화하였는데, 파도의 자유롭고 도전적인 이미지 또한 부여하고자 했습니다. 이러한 파도의 이미지는 PARD의 중요한 브랜딩 이미지로도 꾸준히 활용되고 있습니다.

👆🏻PARD 자체 제작 웹사이트(보러가기)👆🏻

👆🏻PARD 4기 리크루팅 포스터👆🏻

인스타그램

PARD에서 진행되는 모든 활동들은 위 가치들을 녹여낼 수 있도록 오랜 고민과 실무자분들의 피드백을 거쳐 만들어졌는데요, 각 프로그램이 가지고 있는 목적과 진행되는 사진들은 인스타그램 게시물을 통해 공유하고 있습니다. 각 기수 별로 달라지는 분위기와, 스토리로 올라오는 PARD의 실시간 현황들을 가장 빠르게 확인할 수 있는 채널입니다.

PARD가 어떤 프로그램들을 진행하는지, 또 어떤 분위기인지가 궁금하시다면 아래 링크로 방문해주세요 :)

인스타그램 바로가기

네트워크 형성

PARD에는 동아리 인원 뿐 아니라 아래 IT 씬의 다양한 사람들과 네트워크를 형성하고 지속적으로 소통하여 함께 성장할 수 있는 커뮤니티를 만들고자 노력하고 있습니다.

• PARD의 모든 활동에 참여하여 한 기수를 수료한 OB들

• PARD와 접점이 있었던 IT씬의 모든 실무자분들

• PARD와 같이 비수도권에서 IT 프로덕트 개발 경험을 제공하고 있는 경북 IT 동아리들

이를 위해 오픈채팅방을 운영하며 IT 씬에서 앞으로 만날 수도 있는 사람들과의 채팅방에서는 현재 트렌드, 행사 및 취업 정보 등 다양한 정보들을 서로 공유하며 지속적으로 소통하고 있습니다. 실제로 만날 수 있는 네트워킹 행사를 개최하기도 합니다.

올해 11월에도 대구·경북의 대학생 IT 프로덕트 메이커들과도 만날 수 있는 행사를 준비하고 있는데요, 앞으로도 더 많은 사람들과 함께 성장할 PARD를 기대해주세요 :)

PARD는 앞으로도 다양한 활동과 채널을 통해 저희만의 브랜드를 구축하고 알릴 예정입니다.

여러가지를 시도해보며 더욱 성장하는 모습을 Disquiet과 인스타그램에서 공유할테니 기대해주세요!

[역지사지]그래서 디자인이 뭐하는건데? 🤷🤷‍♀️🤷‍♂️

디자이너의 고충..

?: "이거 해주세요~"
디자이너: "네 알겠습니다!"

?: "아.. 이거 약간 별론데요? 수정해주세요~(레퍼런스를 N 장 보내며)"

디자이너: "아하! 알겠습니다~ 잠깐만 기다려주세요.."

(시안을 5개 보내줌)

?: "아.. 근데 제일 처음이 나은거 같네요! 그걸로 해주세요~"

디자이너: "알겠습니다..(울음을 참으며)"

디자이너란 무엇을 이루는 사람일까?

개발자라면 늘 코드와 씨름하고 컴파일러와 맞서 싸우는 게 일상이지만, 문득 창조의 미학을 탐구하는 디자이너에 대한 호기심이 피어올랐습니다. 화면에 띄우는 건 똑같은 웹페이지인데, 그들은 왜 그토록 세밀한 색상과 여백, 폰트에 열정을 쏟는 걸까요?

저는 궁금했습니다. 그들이 바라보는 세상은 대체 어떤 모습일까? (개발이 지루해서 개발 글 안 올리는 건 절대 아닙니다..)

그래서~~ 디자이너의 입장을 이해하기 위해, 디자이너의 비밀에 대해 알아보고 디자인을 체험해보기로 했습니다!

개발자가 디자이너에게서 배운 세가지 비밀

1. 공간의 생동감

개발자의 코드 창에는 딱히 공간이라는 개념이 없다. '폰트든 뭐든 기능만 하면 되는 것 아닌가?' 라고 생각했습니다. 그런데, 디자이너들은 여백에 집착한다. '마음의 숨통같은 여백'

이렇게 여백이 주는 안정감에 '어? 단순히 여백이라는 것이 비어있는 공간이 아니구나.'

이 사실을 깨달은지 얼마 지나지 않아, 공간에도 생동감이 느껴지기 시작했습니다.

2. 색깔에 얽힌 심리학

개발자에게 빨간색은 에러를 나타내는 신호였지만, 디자이너에게 빨간색은 열정, 사랑, 경고, 심지어 배고픔까지 표현할 수 있는 만능색이라고 합니다.

디자이너에게 단순히 빨간색은 눈에 띄는 강렬한 색상이 아니라, 사람의 마음과 행동에 은밀한 영향력을 발휘하는 컬러라고 합니다.

빨간색은 '온기'와도 관련이 있다고 합니다.

음식점 로고나 메뉴에 빨간색이 많은 이유도 마찬가지입니다. 빨간색을 보면 몸의 반응이 즉각적으로 올라간다는데, 음식을 더 맛있고 따뜻하게 느끼게 만드는 작은 마법이 숨어 있습니다. 특히 배고플 때 빨간색을 보면 더 맛있어 보이게 만드는 묘한 효과가 있어서 패스트푸드점에서는 빨간색을 즐겨 쓴다고 합니다~

이렇듯, 이 색깔 하나에도 담기는 의미가 다양하다는 것을 깨달았습니다!

3. 감각과 직관의 황금비율

개발자는 '효율'을 추구하지만, 디자이너는 '직관'을 믿습니다. 테스트를 통해 데이터가 나와야 직성이 풀리는 개발자와 달리, 디자이너는 "그냥 이게 느낌이 와!"라는 감으로 작업을 이어나갑니다.

이상하게도, 그 감각과 직관이 맞아떨어질 때가 있습니다. 그러한 디자인은 마치 사람을 끌어당기는 힘이 있는 듯 보였습니다.

결국, 개발자의 입장에서 디자이너에게서 배운 것은, 이 세상에 ‘기능’만이 다가 아니라는 것. 작은 픽셀과 색깔에 숨겨진 그들만의 언어를 배우면서, 저는 화면 너머의 더 큰 세상을 보기 위한 한 걸음을 내딛을 수 있었습니다.

한 번 따라해보자!

처음 피그마에서 디자인을 따라해봤을 때, 단순히 ‘디자인을 옮긴다’는 것 이상의 경험이 펼쳐졌습니다.

하나하나 배치된 요소들을 보고 그대로 따라가며, 디자이너의 의도를 읽어내려는 과정이 마치 퍼즐을 맞추는 느낌이 들었습니다. 폰트 크기와 간격 하나하나, 컬러 코드와 레이아웃 비율까지 그대로 옮기려다 보니, 그동안 몰랐던 작은 디테일들이 눈에 들어왔습니다.

처음에는 피그마를 쓸 줄 몰라 이것 저것 복사 + 붙여넣기, 복사 + 붙여넣기만 반복하다가,,

텍스트 집어 넣는 법도 배우고, R키를 이용해서 rectangle을 만들고, I키로 색을 따오는 등,, 모든 아이콘을 다 디자인 해보진 못했지만, 저 로고 하나하나를 디자인 하는 디자이너의 심정을 이해할 수 있었습니다.

개발자 입장에서 폰트는 안중에도 없었지만, 막상 디자이너의 입장이 되어보니 폰트, 여백 등 신경써야하는 것과 중요한 것이 너무 많다는 것을 이해하게 되었습니다.

오늘의 교훈

• 겉으로 쉬워보이는 작업들이 의외로 섬세한 터치의 연속이었다!

• 피그마에서 따라 해보면서 디자이너가 그려낸 작은 디테일의 의미를 하나하나 이해하는 순간, 디자인의 깊이를 비로소 느낄 수 있었다!

• 디자이너님들 고생 많으십니다..

• 이제 디자이너의 입장을 이해했으니, 내가 할 일에 충실하자~ 💻

뾰족한 문제정의, 그거 어떻게 하는건데

안녕하세요, 한동대학교에서 IT 협업 동아리 PARD의 4기 서비스 기획파트 김희민입니다.

이번에는 4차 세미나까지 공부하면서 반복적으로 강조된, 기획에서 가장 중요한 요소에 대해 간단히 다뤄보고자 합니다.

문제정의의 중요성

🦔여러분, 고슴이의 가시는 어떤가요?

뾰족하죠? 얼마나 뾰족하죠?

찔리면 피가 날 정도로 날카롭습니다.

고슴이의 가시처럼 어떤 물체를 뚫어버릴 수 있을 만큼의 뾰족함, 그것이 바로 우리가 추구해야 할 문제 정의의 명확성입니다.

알버트 아인슈타인과 스티브 잡스도 강조하는 문제 정의의 중요성

문제를 명확히 정의하는 것이 문제 해결의 시작입니다.

현상과 문제의 구분

그동안 문제의 배경을 찾고 정의를 내릴 때 가장 헷갈렸던 부분은 현상과 문제를 구분하는 것이었습니다. 문제라고 생각하고 정의를 내려 데스크 리서치를 진행해도 명확한 답이 떠오르지 않고 같은 곳을 맴도는 느낌이었습니다. 계속 이렇게 느꼈던 원인은 문제를 찾은 것이 아니라 문제의 탈을 쓴 현상이었기 때문입니다. 이런 과정을 겪으면서 가설을 세워 올바른 문제인지 검증하는 과정이 굉장히 중요하다는 것을 깨달았습니다.

많은 문제 중에서 진짜 해결해야 할 문제를 발굴하고, 그 문제를 명확히 정의한 후, 현재 상태(As-Is)와 이루고자 하는 목표 상태(To-Be) 사이의 간극을 줄이는 것이 바로 좋은 문제!

근본 원인 파악하기

뾰족한 문제를 찾기 위해서는 근본적인 원인을 파악해야 합니다. 이를 위해 가장 기본적이면서 효과적인 5 Why 기법을 활용해 검증을 합니다. 호기심 많은 어린 아이처럼 모든 가설에 "왜?"라는 질문을 다섯 번 연속으로 던지며 근거를 찾아가다 보면, 놓치고 있던 부분을 발견할 수 있게 됩니다.
why? why? why? why? why?

이 기법 외에도 다양한 검증 방법을 통해 문제가 좁혀졌다면, 아래와 같이 문제 정의를 내리면 됩니다.

"나는 [어떤 사람]이 [어떤 일을 할 때] [어떤 문제]를 겪는다고 생각한다."

문제정의 연습과 변화

문제정의를 내리는 과정을 정리해봤다면, 다음은 조금 부끄럽지만, PARD에 들어와 처음 3주동안 제가 문제 정의 연습과 피드백을 통해 변화하는 과정을 담아봤습니다.

• 아무것도 모르던 첫 번째 과제

  

• 이렇게 파고 드는 건가? (1차 수정)

  

• 이게 진짜 문제인 것 같아. (2차 수정)

  

• 아니야. 이게 진짜 뾰족한 문제인 것 같아. (3차 수정)

  

• 피드백 기반으로 다시 수정해봐~ (4차 수정)
  

4차 수정을 개인적으로 하면서.. 결론부터 말씀드리자면!
지금은 이 문제를 갈아엎고 다른 문제를 열심히 탐구 중입니다. 당시 바로 다음 과제가 피드백을 기반으로 수정한 문제 정의와 함께 서비스 명과 솔루션을 제공해야 했는데, 솔루션으로 OTT 통합이라는 아주 말도 안되고 현실성 없는 솔루션만 생각났기 때문입니다.. (이미 세상엔 많은 서비스들이 존재하기에 겹치지 않으면서 문제를 해결하는 IT 프로덕트 솔루션을 생각하기엔 주제가 너무 터무니 없었습니다)

새로운 문제 탐구

OTT를 포기할까 말까 많은 고민을 하면서 PARD 회장님에게 짧게 배경과 생각해봤던 솔루션들을 설명했을 때, 아주 명쾌하게 한마디로 정리해줬습니다.

“솔루션 현실성 없어? 그럼 갈아엎어!”😮

그래도 미련이 남아 조금이라도 붙들고 있으려 했지만, 그것은 시간 낭비일 뿐..!
아직 문제를 정의하는 연습을 하고 있기 때문에 할 만큼 한 OTT는 이제 제 손에서 떠나보내고 새로운 문제를 선정했습니다.

새로 선정한 문제(문해력 관련 문제로 진행 중) 역시 확신이 없어 이번 주 세미나에서 피드백을 받을 후 또 다시 고민의 늪에 빠질지도 모릅니다. 기존의 문제를 다시 갈아엎고 새로운 문제를 모색하는 것은 꽤나 큰 결심이 필요합니다. 모든 프로세스를 처음부터 다시 거쳐야 하기 때문입니다. 
그리고 다시 제자리걸음을 하는 듯 한 막막함..

(파트장들은 문제를 계속 바꿔서 처음부터 단계를 계속 밟는 것을 추천한다고 합니다)

성장의 과정

하지만 계속해서 문제를 찾아가는 노력과 연습을 통해 뾰족한 문제 정의를 잘 할 수 있는 사람으로 성장할 수 있을 것이라고 확신합니다. 이러한 과정이 바로 고슴도치와 같은 뾰족함을 갖추어가는 여정이 아닐까요?

앞으로도 계속 부딪히고 실패를 경험하면서 🦔처럼 뾰족한 가시를 등에 업은 사람이 되기까지 열심히 하겠습니다~!

다들 파이팅

총 후원금만 1억, 포항의 작은 IT 협업 동아리는 2년간 어떻게 성장했을까?

초기 멤버 2명에서 총 150명의 구성원

시작 비용 0원에서 총 누적 후원금 1억원

서비스 배포, 외주 프로젝트 총 14건

포항시 작은 대학의 학생들이 모여 만든 동아리가 2년만에 이루어낸 성과입니다.

안녕하세요 Pay It Forward를 실천하는 포항시 IT 협업 동아리, PARD 4기 회장 백예은입니다.

2023년 1기 멤버를 시작으로 벌써 2년 동안 PARD의 구성원으로써 활동하고 있는데요, 문제해결을 위해 끊임없이 노력한 PARD가 지금까지 얼마나 성장했는지, 어떻게 성장할 수 있었는지 공유하기 위해 이렇게 글을 작성합니다 ✍️✍️

비수도권의 문제를 발견하다.

먼저, PARD는 비수도권의 대학생들이 IT 프로덕트를 만들기 위해 협업하고, 필요한 지식을 쌓을 수 있는 기회가 부족하다는 문제를 해결하기 위해 만들어진 동아리입니다.

IT 서비스 제작 프로젝트, 부트 캠프, IT 연합 동아리, 기업 연계 인턴십 등은 IT 취업 시장에 진입하기 위해 대학생들에게 꼭 필요한 경험입니다. 대부분 수도권의 학생들에게는 쉽게 접근할 수 있는 것들이죠. IT 시장의 취업과 창업을 하기 위해 꼭 필요한 경험들이 비수도권 학생에게는 시도조차 하기 어려운 경우가 많습니다. 그래서 저희는 ‘인프라의 차이도 극복해 낼 수 있는 성장에 대한 갈망과 열정’을 가지고 PARD를 만들었습니다.

🤔 PARD가 궁금하다면?

• PARD Instagram (클릭)

• PARD Website (클릭)

PARD에서 있었던 일

PARD는 매 순간 기회를 찾고, 움직였습니다. PARD 초기에는 성장 가능성을 알아줄 후원사를 찾기 위해, 그리고 현직자의 멘토링을 받기 위해 100번 이상의 미팅을 통한 협력 요청을 하기도 했습니다. 또한 학부생 수준을 벗어나기 위해 외주 프로젝트의 기회를 찾기도 했으며, 꾸준히 새로운 방법을 찾아 PARD를 알리기 위해 힘썼습니다. 현재는 문제 해결의 규모를 키우기 위해 대구/경북 내 10곳 이상의 IT 관련 동아리와 협력관계를 체결하고 있습니다.

PARD를 만든 초기 멤버들은 현재 남아있지 않습니다. 그럼에도 PARD가 꾸준히 성장할 수 있는 이유는 무엇일까요?

바로 Building in Pubilc과 투명한 공유입니다.

PARD의 창립자이자 1기 회장인 @최현종 님은 Disquiet을 통해 PARD의 메이커로그를 꾸준히 작성해 주었습니다. 그 덕분에, Disquiet을 통해 후원사를 찾기도 했고, 최근에는 Disquiet의 글을 보고 외주를 맡긴 스타트업도 있었습니다. 또한, 현종 님은 조직문화, 대외협력 방안 등을 기록하여 플레이북을 배포하기도 했죠. 이렇게 기록된 결과물들은 당시 발생한 어려움과 성취를 보여주며 앞으로의 가이드를 제공하고 있습니다.

👇위의 성과들을 이룰 수 있게 해준 PARD의 플레이북이 궁금하다면 아래 링크를 통해 신청해보세요👇

IT 연합 동아리 운영 플레이북 by PARD 보러가기

2기 회장이자 또 다른 창립자인 @송예찬 님은 본인의 부족한 점을 매번 투명하게 공유하고, 팀원의 가치를 최대치로 끌어올리는 리더십을 보여줬습니다. 3기 회장 @조세희 님이 겪은 시행착오가 담긴 인수인계 자료는 현재 의사결정에 큰 도움이 되고 있죠. 투명한 공유의 힘이 꾸준히 성장하는 PARD를 만들었다고 말할 수 있겠습니다.

앞으로 PARD는?

PARD는 앞으로도 새로운 기회를 만들기 위해, 그리고 문제를 해결하기 위해 달릴 예정입니다.

PARD에서 11월에는 대구·경북의 대학생 IT 프로덕트 메이커들을 모아 네트워킹 행사를 개최할 예정입니다. 1월에는 4기의 데모데이 행사도 진행될 예정이고요. 앞으로 Disquiet을 통해 성장 과정을 공유할 테니 기대해 주세요!

PARD와 관련하여 궁금한 부분이 있거나 협력 요청을 원하신다면, 언제든지 커피챗 요청 주시길 바랍니다!