[Gem민이들] “이 회고를 읽으면 프로젝트 50시간을 아낍니다리미” 롱커톤 2주차

안녕하세요! 포항시 IT 연합 동아리 PARD 4기 롱커톤을 준비 중인 Gem민이들입니다! ㅎㅎㅎㅎ

PARD 4기에서는 Forward라는 주제로 3주동안 데모데이와 프로덕트 산출을 목표로 뜨겁게 달리고 있습니당 😎🔥!

휴식 시간도 반납하고 열정적으로 협업하기 위해 노력하는 PARD의 모든 멤버, 행사를 위해 노력하시는 운영진 분들을 위해 많은 관심 부탁드립니다~!~!

팀 컨셉과 사랑에 빠져버려서 조금 어눌하고 킹받아도 이해해주세욧 , , , ! ㅎㅎㅎ💎💍🫅

우선 저희 서비스 구경하고 가시죠!!

💎💎 팀원 소개 💎💎

기획자 2명 디자이너 1명 프론트 개발 3명 백엔드 개발 1명으로 구성된 팀입니다!

다들 인물이 훤하죠?

?: 얼굴 안나오는게 깐지임

죄송합니다 ㅎ~ㅎ

아래에 첨부된 링크로 가시면 팀원 정보를 확인하실 수 있습니다 😎😎

📝 PM (Perpect Manager) 2명!

INTJ 하갱(김하경)

"? 제작자는 이론고 안쓰는게 간지임."

INTJ 찐잼민(김규리)

"롱커톤 뿌셔뿌셔!!"

팀의 중심을 잡아주는 똑똑이들이에요~ 심지어 디자인을 전공하고 있어서 감각까지 탑티어! 부럽쥬?

기획이들이 없었다면, 저희 팀이 굴러갈 수 없어요~~ ⚽️⚽️

뾰쪽하다 못해 바늘같은 섬세한 문제정의에 저희 팀원들은 항상 감탄을 자아냅니당 ㅎㅎ

🎨 Designer (Design Nobel Prize) 1명!

INFP 갱민(박경민)

"최상의 퀄리티를 내는 그날까지! 아자!!"

전반적인 UI / UX를 담당하고 있는 디자인 천상천하 유아독존입니다!

디자인 노벨상이 없어서 못받아서 아쉽지만, 조만간 받을꺼 같네용~

도전을 두려워하지 않고, 어디선가 빛나는 디자인을 가져오는 그대.. ✨✨ 눈이 부십니다..

🧑‍💻 FE-Developer (백엔드까지 섭렵?!) 3명

ENTP 아서(강신엽)

"재밌게 해보자잇!"

ESFJ 서켱쥐(지석영)

"후회없는 롱커톤!"

INFJ 정민초(정민찬)

"뭐든 급할수록 도라에몽"

저희 프론트엔드 개발은 기획 단계에서부터 열정적으로 참여해 뾰족한 문제정의를 돕는 건 물론, 기획, 디자이너와의 원활한 소통, 심지어 미적 감각을 보유한 프론이들입니다! 😎🤓🧐

🔙 BE-Developer (프론트엔드까지 섭렵?!) 1명

ISFP 서버여신(김민제)

"모두 3주간 화이팅!!"

여신의 자리에 걸맞게, 서버와 데이터베이스를 완벽히 섭렵하고 있습니다~

백엔드와 프론트를 넘나드는 멀티여신입니다 🗽🗽

딱딱한 서버와 상반되는 상큼한 매력을 보유!

저희팀은 걱정? 사치라고 생각해요! 🥰🥰 항상 든든한 빽(백엔드 여신)이 있거든요~!!

2주차 협업 진행 과정 👀

급훈 ❣️

우선, 저희 팀의 급훈 보시고 가실까요?

무서워서 협업하겠나~ 라는 생각이 드시겠지만, 저희는 진짜 빠따 칩니다! 🏏🏏

저희는 언제나 심리적 안전감이 형성되어있어요 ㅎㅎ

그래서 뾰족한 문제정의가 뭔데? 🤔🤔

저희 팀은 협업에 있어서 기.디.개의 Align을 가장 중시하고 있습니다! ☝️

여기서 Align이란, 협업 상황에서 목표나 방향성을 조율하고 같은 선상에 두다라는 사전적 정의가 있는데요!

각자 맡은 분야에만 치중하는 것이 아닌, 서비스를 사랑하는 마음으로 함께 끊임없이 고민하며,

하나되어 앞으로 나아가는 것이 저희 팀의 목표이자 지향점입니다~ 🫶 🎯

그래서 아이디에이션과 솔루션 도출, 기능 정의 등 모든 기획 단계에 같이 참여하고 고민하는 시간을 많이 가졌습니다!

저희 팀 너무 귀엽지 않나요? ✨✨🥹🥹🫶

저희는 하루 종일 몰입을 하며,,

아서(신엽)가 제공해주는 호빵도 먹고요!

붕어빵도 당일 장사 접게 해드렸습니다~! 🍞🍞

망고 빙수도 먹고,, 🍨🍨🍧

귤도 먹고 정말 맛있었어요! 🍊🍊

그런데, 갑자기 왠 음식 자랑이냐고요?

바로, 심리적 안전감 형성이 잘 되고있다는 것을 표현하고 싶었습니다!

저희 팀은 몰입과 집중의 시간에는 사적인 대화를 하기가 힘들지만, 무언가를 먹으면서 스몰 토크도 하고, 웃음 꽃이 번지는 과정에서 협업은 시작이라고 생각하기 때문입니다!!!!!! 😊😊☺️

하지만, 저희 팀이 먹고만 있는 건 아니에요! 😆😆

Forward하기 위해! 올바른 협업을 하기 위해!

몰입 하고 있습니다! 🔥🔥🔥

롱커톤 2주차를 마무리하며,

그래서 저희가 준비하고 있는 프로덕트는요~!

서비스명: wecand:(위캔드:)

한 줄 소개: 원하는 공모전 파트너를 찾을 수 있는 곳, wecand:

디테일한 설명: wecand:는 직접 작성한 역량카드로 서로의 작업 스타일과 역량을 파악하며 공모전 팀원을 모집합니다. 공모전에 함께 할 최적의 파트너를 찾고, 최고의 팀워크를 완성하세요! 더 나은 협업의 시작, wecand:

도메인 링크: wecand.shop

저희는 지금도 달리고 있습니다~~!!!

이 글을 읽으시는 여러분들 모두 무사히 2024년 마무리하고 2025년에도 행복만 가득한 한 해 되시길 바랍니다~~!!! ✨✨🔥🔥

완전 변태 🐛🦋 (변화에 적응하기)

서론

안녕하세요! 저는 포항시 IT 협업 동아리 PARD 4기에서 웹 개발 파트의 부원으로 활동 중인 정민찬입니다~

이번 글을 쓰게 된 계기는 IT 제품들에 대해 고민하던 중, 시대에 따라 사람들의 요구와 니즈가 어떻게 달라졌는지 떠올리게 되었기 때문입니다. IT 제품은 단순히 기술의 발전만을 반영하는 것이 아니라, 특정 시대와 문화의 흐름 속에서 사용자의 기대에 따라 진화해왔습니다.

이 글이 읽는 분들께 조금이나마 영감을 줄 수 있다면 좋겠습니다!

본론

기술은 단순히 발전하는 것에 그치지 않고, 시대와 문화의 흐름과 변화 속에서 인간의 편리함을 증진시키고, 삶을 변화시키는 중요한 역할을 해왔습니다!

과거에는 단순한 편리성과 연결성을 제공하는 것이 주 목적이었지만, 현대에 들어서 개인적인 경험, 공감, 지속가능성까지 어우르는 방향으로 발전하고 있습니다~~

시간 참 빠른거 같아요~ 제가 어릴 때는 2G, 3G 데이터를 사용하였는데 말이죠~..

문화적 변화와 IT product의 트렌드 변화

초창기 (1990년대 ~ 2000년대 초반): 편리함과 연결성

주요 트렌드: 이메일, 인터넷 검색 엔진, 웹사이트

사용자 기대: 정보를 빠르게 검색하고, 사람들과 연결되기 위한 수단을 제공받길 원함.

대표 IT 제품: Yahoo, Google

-> 인터넷의 보급으로 정보 접근성과 디지털 연결이 가능해지며, 사용자들은 기능적인 편의성에 초점을 맞췄음.

웹 2.0 시대 (2000년대 중반 ~ 2010년 초반): 소셜 네트워크와 참여

주요 트렌드: 소셜 미디어, 블로그, 사용자 생성 콘텐츠 (UGC)

사용자 기대: 단순한 정보 소비를 넘어서, 자신이 직접 콘텐츠를 만들고 공유하며 소통하고자 함.

대표 IT 제품: Facebook, YouTube

-> 개인의 목소리를 내고 사회적 관계를 확장할 수 있는 플랫폼을 원함. 기념일이나 축제를 기록하고 공유하는 방식이 디지털화됨.

모바일 혁명 (2010년대 초반 ~ 2020년 초반): 개인화와 즉각적인 연결

주요 트렌드: 스마트폰 앱, 모바일 커머스, 인공지능 기반 추천 시스템

사용자 기대: 자신의 위치, 선호도, 행동 데이터를 기반으로 개인화된 서비스를 제공받길 원함.

대표 IT 제품: Instagram, Amazon, Spotify

-> 모바일 기기의 보급으로 언제 어디서나 연결될 수 있는 세상이 열림. 사용자들은 기념일 선물 추천, 이벤트 알림 등 개인화된 경험을 선호하기 시작함.

현대 (2020년대 ~ 현재): 공감과 경험 중심

주요 트렌드: AI 챗봇, AR/VR 기술, 정서적 연결을 고려한 제품 디자인

사용자 기대: 기능적인 편리함을 넘어, 정서적 만족감과 깊은 공감 경험을 원함.

대표 IT 제품: ChatGPT, Calm (명상 앱), VR 기반 행사 플랫폼

-> 코로나19 팬데믹 이후 디지털 환경 속에서도 인간적인 경험을 중시하는 경향이 강해짐. 예를 들어, 온라인으로 기념일을 축하하거나 가상 환경에서 축제를 즐기는 방식이 주목받고 있음.

미래: 지속 가능성과 윤리적 책임

예상 트렌드: 지속 가능한 IT 제품, 사용자 중심의 윤리적 디자인

사용자 기대: 환경과 사회적 책임을 고려한 제품과 서비스, 더 인간적이고 친절한 기술을 원할 것이다!

가능성 있는 제품: 탄소 발자국을 줄이는 IT 솔루션, AI 기반 관계 유지 서비스 ~~

-> 개인화와 공감을 넘어, 기술이 사회적 문제를 해결하고 지속 가능한 발전을 추구해야 한다는 목소리가 커지고 있음.

결론

IT Product 뿐 아니라, 사회의 전반적인 분야에서 이러한 변화의 흐름을 읽고 파악하는 것이 중요하다는 것을 깨달았습니다!

협업할 때 이런 트렌드의 흐름을 읽고, 앞으로의 트렌드를 예상하거나 옛 트렌드에서의 단점을 추출하여 서비스를 개선하는 등 전반적인 사고 확장이 일어나지 않을까 기대가 됩니다~

행복한 연말 보내세요~~!

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

안녕하세요, 포항시 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 (시도할 점)

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

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

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

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

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

  • 소통 역량 강화:

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

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

  • 발표 준비 강화:

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

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

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

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

(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를 말씀드리고 글을 마무리 하겠습니다.

급할수록, 도라에몽

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

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

디자이너의 고충..

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

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

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

(시안을 5개 보내줌)

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

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

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

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

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

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

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

1. 공간의 생동감

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

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

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

2. 색깔에 얽힌 심리학

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

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

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

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

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

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

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

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

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

한 번 따라해보자!

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

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

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

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

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

오늘의 교훈

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

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

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

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

[하찮은 인사이트, 아이디어 글] 그래서 IT Product가 뭔데? 🤷

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

여느 때와 다름없이 거북목 자세로 흑백 화면을 보며 키보드를 두들기던 저에게 문득 이런 생각이 들었습니다.

'그래서 IT Product가 뭔데?'

프로덕트 매니저가 기획한 IT Product를 기반으로 UI/UX 디자이너가 제작한 디자인을 바탕으로 구현한 Product를 기반으로 피드백을 기반으로 -> 프로덕트 매니저가 기획한 IT Product를 기반으로 UI/UX 디자이너가 제작한 디자인을 바탕으로...

'좋은 아이디어를 가지고 있어도 실현 가능성이 있는가?', '아무도 내가 만든 서비스를 이용해주지 않으면 어떡하지?', '프로덕트 매니저는 무슨 일을 하지?'
그래서 프로덕트 매니저가 무슨 일을 하는지 궁금해졌습니다~

(‼️ 저의 주관, 배경지식이 담긴 글로 Product Management와 전~혀 관련이 없는 그런 것입니다 ‼️)

1. Time To Market, Time To Value

제가 이해한 IT Product를 기획 시 고려해야 할 점은
Time To Market (TTM), Time To Value (TTV)입니다.

최적의 시기의 시장에 대응하기 위한 TTM,

고객이 제품 또는 서비스를 이용해 가치를 느끼는 데까지 걸리는 시간을 최소화하는 TTV,

시장에 출시되는 시간이 빠르면 빠를 수록, 가치(수익)을 얻는 시간이 빠르면 빠를 수록 좋습니다.

또한, TTM과 TTV의 균형이 잘 이루는 것이 중요합니다!

-> 너무 빠르게 시장에 진입하려다 보면 제품 완성도가 떨어짐.
-> 완성도를 너무 높이려다 보면 시장 기회를 놓침.

• ex) 뗀석기를 만들었는데, 이미 신석기였다~

• ex)돌 도끼 열심히 깎았더니, 옆에선 벌써 도자기로 밥 짓고 있었다.

2. Market Research & User Requirements Analysis

아무리 TTM과 TTV가 훌륭할지라도, 시장조사와 사용자들의 요구 분석이 충분히 이루어지지 않으면 사용자가 없는 IT Product에 지나지 않을 것이라 생각했습니다.

충분한 시장조사 + 아이디어도 중요하지만, 실현 가능성을 배제하면 안됨!

초기 사용자 피드백을 무시한 제품은 아무리 훌륭한 계획을 가지고 있어도 실패할 가능성이 높음!

• ex) 돼지고기를 안 먹는 나라 한복판에 삼겹살집을 오픈하는 Miracle

• ex) 나: 사장님, 고기가 질겨요~ ?: 그럼 먹지 마세요.

3. 협업과 의사소통

협업과 의사소통이 원활히 이루어지지 않으면, 팀내에서의 불일치가 생겨나고, 제품의 목표가 흐려질 수 있습니다.

Agile이나 Scrum과 같은 방법론을 사용!

Figma, Slack, JIRA와 같은 협업 도구 사용!

• ex) ?: 개발자님~ (디자이너가 개발자에게 디자인 파일을 던지며,) '이건 뭐, 잠 못 자겠네?'라는 무언의 메시지를 보냈다.

• ex) ?: '이거 금방 끝날 거예요!' 나: '우주선이라면서요?'

오늘은 제가 생각하는 'Product Manager들이 하는 IT Product 메이킹 과정'에 대해 알아 보았습니다~

그렇다면, 이러한 상황에서 취할 수 있는 것들은??

- 온보딩 과정을 최소화하여 TTV를 줄인다!

- UI를 직관적으로 디자인한다!

- 최소 기능 제품을 개발하여 TTM을 줄이고, 유저 피드백에 열려있자!

금주의 아이디어!

이벤트 및 모임 계획 앱 너다나 (너는 계획이 다 있구나)

아이디어 계기: 대학생의 입장에서 약속 잡는 것도 너무 어렵고, 시간이 안나서 약속을 그냥 안잡아 버립니다~.. 그래도 사람답게 살아보자는 생각으로 아이디어를 내봅니다~!

이벤트 및 모임 계획 앱: 친구들 또는 동료들과의 모임을 계획하는 데 도움을 주는 앱. 사용자가 원하는 날짜와 장소를 제안하고, 투표 기능을 통해 최종 결정을 쉽게 할 수 있도록 합니다.

이벤트 생성:

• 사용자가 새로운 이벤트를 생성 시 제목, 설명, 날짜 및 시간을 설정

• 장소를 제안할 수 있는 옵션 제공, 사용자의 위치 기반 근처 인기 장소 추천

투표 시스템:

• 제안된 날짜와 장소에 대해 초대된 친구들이 투표할 수 있는 기능을 제공

• 각 친구는 일정과 장소에 대해 좋아요/싫어요 또는 선호하는 옵션을 선택 (투표 비공개 가능)

일정 조율:

• 사용자가 제안한 날짜 중 친구들의 가능한 일정을 자동으로 분석, 가장 많은 참여자가 가능한 날짜를 제안

• 투표 수가 적거나 행사 주최자의 불참 등 여러 변수를 고려하여 파토 여부 결정~

이벤트 후기 및 사진 공유:

• 이벤트가 끝난 후 참여자들이 후기를 남기고 사진을 공유할 수 있는 공간을 제공

• 후기를 통해 다음 이벤트 계획에 참고

기대 효과

• 모임 문화 조성

• 약속 잡기에 소요되는 시간 단축

• 자신의 의견을 피력하기 힘든 사람들의 적극적 참여

여러분~ 이렇게 열심히 약속 잡고 약속 파토는 아니되어요~ (반성 중)

(아이디어 글) Beyond 1 Day 1 Commit => 1 Week 1 Idea

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

학업스트레스로 인해 넘치는 아이디어(잡생각)를 주체하지 못해 여기에 적습니다~

1.서론 췍~

개발자들 사이에서는 "1일 1커밋"이라는 말이 널리 퍼져 있습니다. 이는 개발에서 꾸준함이 얼마나 중요한지를 잘 보여줍니다. 그렇다면 우리가 개발을 통해 진정으로 추구하는 것은 무엇일까요?

2. 개발의 본질 췍~

개발은 아이디어를 바탕으로 프로덕트를 창조하는 과정입니다. 그러나 AI 기술의 발전으로 인해 이제는 많은 작업이 AI에 의해 수행될 수 있는 시대가 되었습니다. AI는 기존 데이터를 학습하고 패턴을 찾아내는 데 뛰어난 능력을 가지고 있지만, 인간의 직관적이고 비약적인 창의성은 결코 따라잡을 수 없습니다. 결국 완전히 새로운 개념이나 아이디어는 인간이 창출해내는 것이기에, 인간의 창작성과 감정적 깊이는 대체할 수 없는 소중한 자산입니다.

3. 아이디어에 대한 접근 췍~

따라서, 각자의 분야(기획, 디자인, 프론트엔드, 백엔드 등)에서 꾸준함과 최선을 다하는 것뿐만 아니라, 항상 아이디어에 깨어 있는 마음가짐이 중요하다고 생각합니다. 그래서 저는 적어도 일주일에 한 번은 사소한 아이디어라도 기록해보려 합니다. 주제가 무엇이든 간에, 아이디어를 지속적으로 키워나간다면 언젠가 어떤 분야에서든 긍정적인 변화를 가져올 수 있을 것이라고 믿습니다.

4. 협업 툴 개발 아이디어 췤~

제목: 개발자, 디자이너, 기획자를 위한 협업 툴 개발

배경

현대 소프트웨어 개발 환경에서는 개발자, 디자이너, 기획자 간의 원활한 소통이 필수적입니다. 하지만 각 직군의 전문 용어와 언어 차이로 인해 커뮤니케이션이 원활하지 않아 프로젝트 효율성이 저하될 수 있습니다.

기존 협업 툴에서의 한계점

저도 노션을 쓴지는 1년도 안되었지만, 적응하는 데 꽤 긴 시간을 썼던 것 같습니다..

개인적 사용에서의 어려움

(노션)

• 잘쓰면 진짜 유용함 -> 잘쓰기 진짜 힘듬

• 자동화 기능의 부족 -> 효율적으로 관리하기 위해 시간 소모

• 모바일 앱에서의 제한 -> 복잡한 사용자 인터페이스

협업에서의 어려움

(슬랙)

1. 전문 용어 소통의 어려움

2. 정보의 과부하

3. 통합적인 프로젝트 관리 기능 부족

(노션)

1. 실시간 피드백 부족

2. UI / UX의 복잡합

3. 문서 버전 관리의 어려움

목표

1. 팀원들이 쉽게 소통하고 협력할 수 있는 환경을 조성

2. 프로젝트 진행 속도 향상

3. 결과물 품질 향상

구현 방법

1. 협업 툴 개발: 실시간으로 피드백을 주고받을 수 있는 플랫폼을 구축.

2. 언어 번역 기능: 각 직군의 전문 용어를 상호 이해할 수 있도록 변환해주는 소프트웨어를 구현.

3. 통합 대시보드: 모든 팀원이 진행 상황을 한눈에 확인할 수 있는 대시보드를 제공.

예상 효과

• 팀원 간의 소통이 원활해지면 프로젝트 진행 속도가 빨라지고, 오해나 커뮤니케이션 오류가 줄어듦.

• 결과적으로 사용자에게 더 나은 서비스를 제공

추가 고려사항

• 각 직군의 언어를 어떻게 정의할 것인지에 대한 명확한 기준이 필요.

• 소프트웨어의 사용성을 높이기 위해 직관적인 UI/UX 디자인을 고려.

한계점

1. 초기 설정의 복잡성 : 팀원들이 앱을 사용할 때 각자의 전문용어와 협업 흐름을 정의하는 과정이 필요. ->이러한 과정이 복잡하거나 시간을 많이 소모한다면 사용자들의 기피 가능성 존재.

2. 기술적 한계: 기술을 알짜배기만 넣는다 하더라도, 기술적 구현에서 한계 존재.

3. 사용자 유지 문제: 기존의 프로그램들에 적응된 사용자들이 프로그램 이용에서 불편을 느낄 수 있음.

여러분 사소한 거에도 항상 아이디어에 깨어있어봐요~

ex) 점심뭐먹을지, ootd, 오늘뭐할지~

🧩9️⃣월 2️⃣0️⃣〰️2️⃣1️⃣🧩 서핑데이 회고

안녕하세요~ 4기 웹 파디 정민찬입니다!

여름과 가을의 임계점을 맞이함과 동시에 파드의 서핑데이는 막을 열었습니다~🌊🌊🏄‍♂️🏄

회고 글이 엉성하고 중구난방이어도, 이쁘게 봐주시면 감사하겠습니다 🤹‍♀️ (사진이 좀 많아요~)

파도 앞에서의 낯가림

저는 워낙 낯을 가리지지만, 빨리 친해지고 싶어하는 조금 모순적인 성격을 가지고 있습니다.

목표

• 먼저 다가가기

• 라포 형성

• 피곤해하지 않기

• 안친해졌다고 울지 않기(?)

1일차, 우리 친해져요~

경주에 있는 펜션에 도착한 후, 저녁식사를 마치고 레크레이션을 진행하였습니다.

이때까지만해도 좀 어색하고 허허만 했었습니다 ..

서핑데이에 앞서 많은 걱정과 근심에 휩싸였지만, 협업을 위해 모인 사람들은 달랐습니다.

순간순간마다 들려오는,

"E~ey~" "E-e~y"

추임새와

정겨운 대화의 장은 이미 저를 분위기에 녹아들게 해주었습니다.

👆( 블로그에 진심인 사람들 )

👆( 21즈 화석이 되. )

+마피아 게임 + 다음 프로그램은요 + ETC -> 새벽 🕓 ~🥱🥱

그렇게 1일차 서핑데이 모든 일정을 마친 후, 여름밤이 지나갔습니다~

2일차: 우리 협업해요~

👆( 소파와 협업중, 역시 협업에 미친 김 모 파트장님 👍👍 )

사실 저도 소파랑 협업하다 빗소리 들으러 왔습니다~

날씨도 이제야 협업을 하는군요

👆 ( 아~ 이거 기획이 하는 건데.. )

👆 ( 파드가 지향하는 가치를 퍼즐에 담고 녹여내어, 진정한 협업의 가치를 느낄 수 있게 하는 내용, 직관적이고 심플하고 예쁘기까지 한 UI 디자인, 몸이 4개로 나뉘어져 기획하는 매니지먼트, 레이아웃 구성 및 퍼즐 UI, 메마르지 않는 아이디어 뱅크의 합작)

근소한. 차이로 졌습니다~

회고

원래 나의 생각: '협업 그냥 하면 되는거 아니야?'

서핑데이의 미니프로젝트에 참여한 후:

생각보다 고려해야 할 사항이 많았다.

• DVDM (Define, Value, Difficulty, Method) -> 미니프로젝트에 간간히 쓰인 Difficulty도 시간적 여유가 부족할 때 고려되지 않았다.

• 각 파트가 각자의 일만 해서는 안된다. -> 결국 프로덕트의 모든 파트는 유기적으로 연결되어 있어야한다.

• 서로 간의 상황, 컨디션을 실시간으로 공유할 수 있어야한다. -> 추후 갈등 상황 발생시, 해결점 탐색

• 협업에서의 타협의 의미 -> 그 시점의 상황과 감정에 대한 타협 X 맞서야 함, 유저에게 제공되는 서비스를 준비하기 위한 시간, 자원, 기술적 타협

• 등등 -> 일단 친해져야 한다.

이것 말고도 떠오르는 것이 엄청 많지만 숏커톤 때 호되게 당해보고 성장하고 싶습니다~

참 많은 생각이 들었고, 협업.. 역시 쉽지 않구나라는 생각이 들었습니다.

명언 하나 던지고 가겠습니다.

경험은 엄한 스승이다. 먼저 시험에 들게하고, 그 후에 교훈을 주기 때문이다.
-버논 샌더스 로-

마지막으로, 서핑데이를 위해 헌신하고 Pay it forward를 몸소 실천해주신 PARD의 운영진분들께 감사 인사 올립니다~! 🙇🙇

(🚶🏻🚶🏻‍♀️🚶‍♂️ + 🥔) -> 🍟 협.잘.개(협업 잘하는 개발자)가 되자! (ver_1)

⬆️(올림픽 공원 나홀로 나무 = 고립된 상태)⬆️

서론

저는 지금껏 마치 올림픽 공원에 서 있는 ‘나홀로 나무’처럼 모든 것을 혼자 해결하려 했습니다. 교류 없이, 나만의 방식으로 살아왔죠.
처음에는 단순히 개발자 직군에 대한 막연한 희망만으로, 코딩 실력만 잘 키우면 충분하다고 생각했습니다. 저도 하드 스킬만 발전시키면 개발자의 꿈을 이룰 수 있을 거라 믿었습니다.
그러나 시간이 지나 깨달았습니다. 저는 그저 아무것도 모르는 ‘감자’에 불과했고, 협업과 집단지성의 무한한 성장 가능성을 깨달은 이후로 제 생각은 크게 달라졌습니다.

부족하지만, 저는 4기 웹 파디로서 1차 세미나(2024.09.14 / 웹 파트)에서 진행한 세미나를 통해 얻은 인사이트를 나누고자 합니다.

개발자란?

"글을 작성하는 사람", "코딩을 할 줄 아는 사람", "프로그램을 만드는 사람" 등의 다양한 정의가 있을 수 있습니다. 그러나, 개발자가 해야 할 일은 단순히 코드만 잘 작성하는 것이 아닙니다.

개발자로서 갖추어야 할 역량

문제 해결 능력, 구현력, 학습 능력은 훌륭한 개발자가 되기 위해 필수적인 역량입니다. 하지만 이는 단편적인 시각에서 바라본 것일 뿐입니다.
현실에서 개발자는 단순히 ‘코딩하는 사람’이 아닌, ‘프로그래밍하는 사람’이어야 합니다.

• 코딩: 코드를 작성하는 과정

• 프로그래밍: 프로그램을 설계하고 코딩하며, 에러를 수정, 유지 보수하는 일련의 과정을 말합니다.

코딩은 프로그래밍의 한 부분일 뿐이고, 더 넓은 관점에서 전체적인 문제를 해결할 수 있어야 합니다.

목표

개발자의 궁극적인 목표는 사용자에게 가치를 제공하는 것입니다. 단순히 코드를 잘 작성하는 개발자가 되는 것을 넘어서, 급격히 변하는 시장의 흐름을 이해하고 대응할 수 있어야 합니다.
혼자서 모든 역량을 키우는 것만으로는 유저를 만족시키기에 충분하지 않다는 사실을 인정하고, 커뮤니케이션과 협업 능력을 필수적으로 키워야 합니다.

세미나에서 깨달은 점

• 협업에서 개발자만 알아들을 수 있는 언어 X, 협업을 위한 언어 O

• 코드를 작성 시, 주석을 달자!

• 나만의 문제 해결 X, 팀, 전체의 문제 해결을 위해 끊임없이 탐구하자!

지금 내가 할 수 있는 것!

개발자의 소프트 스킬 향상

• 소통: 팀원들과 원활하게 소통하며 프로젝트를 이끌어나가는 능력을 기르기

• 팀워크: 협업을 통해 더 나은 결과를 도출하고, 함께 성장하는 과정 체험하기

• 문제 해결 능력: 협업 속에서 다양하게 발생하는 문제를 효과적으로 해결하는 능력

• 코드 가독성 높이기: 다른 사람과 협업할 때 누구나 이해하기 쉬운 코드를 작성하기

• 도움 요청에 귀 기울이기: 어려울 때는 도움을 청하고, 그 과정에서 배움을 얻기

• 피드백의 가치 깨닫기: 코드 리뷰 등을 통해 얻는 피드백의 중요성을 인식하고 적극적으로 반영하기

결론

개발자는 단순한 '코드 작성자' 그 이상의 존재입니다.
기술만을 잘 다루는 것 뿐만 아니라, 협업과 집단지성을 통해 더 큰 성장 가능성을 탐구하는 것이 중요합니다. 지금 더 나은 개발자가 되기 위해 소프트 스킬을 갈고닦고, 협업을 통해 더 넓은 시각을 갖추어 봅시다~!

++

귀 기울여 봅시다~!