안녕하세요! IT 동아리 디프만 15기의 4팀 막내온탑🐣의 막내 팀장 조혜원입니다.

저희 팀은 디자이너 3명, 서버 개발자 3명, 웹 개발자 4명으로 이루어져 있으며,

취준생을 위한 서비스 뽀각을 열심히 만들어가고 있습니다!

우리의 첫 단체사진

어느덧 프로젝트를 시작한지 8주가 지나고, 기획 단계부터 UT를 거쳐 지금까지 진행한 결과를 팀별로 발표하여 공유하는 중간발표를 진행했어요. 다른 팀의 UT 인사이트를 적용한 화면, MVP 등도 살펴볼 수 있었고 적극적인 피드백과 QnA도 오가는 유익한 시간이었습니다.

발표를 맡아주신 우리팀 멋쟁이 두 분입니다!
(그리고 긴장해서 심장 부여잡은 비하인드…)

중간발표 이후, 저희 팀은 지난 2개월을 돌아보며 열심히 중간 회고를 진행하였어요. 런칭 데이라는 다음 마일스톤을 향해 잘 달려가기 위해 중간 과정을 점검하고, 앞으로의 프로젝트 방향성을 잡아보았습니다.

오늘 해당 내용을 공유드리고자 합니다 💪

💥 뽀각은 어떤 서비스인까요?

먼저 저희 팀이 열심히 만들어가고 있는 서비스에 대해 간단히 소개해드리겠습니다!

저희 10명이 열심히 만들어가는 🍀 뽀각🍀은 ’취업 준비 과정에서 수집하는 정보들의 정리 및 확인에 도움을 주는 서비스’ 입니다.

🤔 왜 이런 서비스를 만들게 되었을까요?

저희 팀은 구성 초기에 어떤 서비스를 만들고 싶은지에 대해 이야기 하였고,

‘범위가 좁아도 확실한 하나의 문제를 해결해주는 서비스를 만들자!’라는 공동의 목표를 세우게 되었습니다.

👇🏻 다들 취준 과정에서 이런 경험... 겪어보신 적 있으신가요?

분명 저번에 비슷한 질문의 자소서 답변 써놨었는데... 어느 기업에 지원할 때 썼더라?

아..노션 템플릿 찾기 귀찮다.. 일단 페이지 하나 만들어서 모아놔야지

저희 팀원들은 취준 과정에서의 이런 경험에 대부분 공감했고, 정말 다른 유저들도 느끼는 문제인지 가설을 검증하기 위해 리서치를 진행했어요.

🤔 저희가 발견한 문제는 무엇이었을까요?

저희 팀은 리서치를 통해

‘취준 과정에서 정보를 수집 및 정리한 경험이 있지만, 기존의 템플릿을 잘 활용하지 못하는’
유저군을 발견하게 되었으며,

해당 유저군이 공통적으로

‘취준 관련 정보를 다시 찾아보는 것에 니즈를 가지고 있지만, 정보를 다시 확인할 때 불편함을 느낀다.’
라는 문제를 겪는다는 인사이트를 얻게 되었습니다.

👉 이러한 문제를 해결해주고자 '뽀각'을 기획하게 되었습니다.

🤔 발견한 문제를 어떻게 해결해줄까요?

처음부터 정보를 잘 기입하고 그 정보를 잘 활용할 수 있는 것이 가장 중요하다는 것을 발견하여, 이를 해결해주기 위해 기능을 크게 두가지로 나누어 구성했습니다.

정보 기입) 정보 기입 단계에서부터 체계적으로 정보와 생각을 정리할 수 있도록 하고,
정보 탐색) 잘 정리된 정보를 잘 찾아서 활용할 수 있도록 돕는다.

여러분의 취뽀를 도와줄 🍀뽀각!🍀 우리 서비스의 목표는?

뽀각의 목표는 기존 템플릿 활용에 어려움을 겪는 유저들이

1) 정보를 잘 기입하고
2) 잘 찾고
3) 찾은 정보를 잘 활용하고
4) 취업 전략 정리를 돕는

서비스가 되는 것입니다.

🗯️ 여기서 뽀각 서비스 네이밍의 의미를 간단히 설명해드릴게요!

‘뽀각'은 취준생들에게 많이 쓰이는 '취뽀'를 활용하여 (취)뽀 + 각 을 합친 말입니다!
뽀각 서비스를 사용하며 취준에 필요한 정보를 모으고 정리하는 취준생 유저들의 취뽀 행운을 응원하는 의미를 가득 담은 귀여운 이름이랍니다🍀

많은 관심 부탁드립니다!

💥 우리 팀의 중간 회고

저희 팀은 효과적인 회고를 위해 회고 템플릿을 사용하기로 하였고, 특정 활동에 대해 느낀 생각과 경험을 중심으로 회고를 진행하는 방식인 4L 회고 템플릿을 사용하였습니다.

4L은 특정 활동에 대해 느낀 생각과 경험을 중심으로 회고를 진행하는 방식으로, 팀/개인이 프로젝트나 작업을 마친 후 경험을 되돌아보기 위해 사용하는 간단한 프레임워크입니다.

Liked (좋았던 점)
Lacked (아쉬웠던 점)
Learned (배운 점)
Longed for (앞으로 바라는 점)

🗯️ 액션 아이템

저희 팀은 추가적으로, 회고 내용을 바탕으로 실천해야할 액션 아이템까지 정해보았는데요!

프로젝트가 끝날 때쯤, 최종 회고를 통해 이것들을 얼마나 잘 실천했는지 점검해보고자 합니다.

소통 늘리고 더 친해지는 것! 번개 모각작이나 대면 만남 늘리기
공동 작업 시간 가지기 (코어 타임) → 얼마나 잘 지키나 점검하기
개발 - 디자인 사이의 소통을 더 적극적으로 하기
- 작은 사항도 전체 공유될 수 있게 노력하기 + 디자인도 중간상황도 공유하고 소통
  - 소소하게 결정된 것들도 바로 글로 작성해서 슬랙에 기록 남기는 것 → 카톡으로 노티 주는 방식으로 진행하기로
- 디자인 - 웹 회의를 통해 UI 관련 소통 늘리기
- 현황 공유 되로록 백로그 관리, 기능정의 문서 등
백엔드 팀에서 현황 공유 및 Task 마감 기한을 줄이는 대신, 하나의 마감기한 동안의 Task를 더 잘게 분할하여 자주 소통하고 자주 코드를 통합하는 환경을 만들기
- 하나의 기간을 2~3일로 하고 마감 당일을 코어타임으로 정하고 현황 공유 및 문제점 공유, 앞으로 할일 공유 회의를 20~30분내로 종료하기
목표설정 (OKR이나 이니셔티브) → 회고를 통해 잘 지켰나 점검하기

이제 어떻게 이 액션 아이템들을 결정하게 되었는지 자세하게 알려드리겠습니다!👇🏻

👊 Liked (좋았던 점)

1) 다정하고 든든한 팀원들로 이루어진 좋은 팀 분위기

각자의 일정 속에서 최선을 다하는 모습이 보여서 동기부여가 된다.
실력 있는 동료에 대한 신뢰가 깔려있다.
팀 분위기가 편해서 눈치보지 않고 내 의견을 쉽게 낼 수 있다.
회사에서는 얻을 수 없는 에너지들을 많이 받아간다.
피드백을 주고 받고, 이를 반영하는 과정이 잘 이루어진다.
팀외/팀내 질문에 언제나 정확한 답변을 받을 수 있었다.

2) 기획 단계에서 사용자의 불편함을 중심으로 문제를 정의하고, 해결책 도출

기획, 디자인 단계에서 사용성에 대한 고민을 충분히 할 수 있었던 것이 좋았다.
문제를 발견하고 무엇이 문제인지 해결책은 무엇인지 도출해가는 지점이 탄탄했다고 생각한다.
- ‘특정 기능이 있다면 서비스가 있다면 어떨까?’에서 출발하지 않고 ‘특정 근위의 유저는 어떤걸 제일 불편해할까?’ '취준이라는 큰 주제에서 무엇이 가장 불편할까?’라는 관점에서 시작하였다.
- 이후 계속 유저 탐색 과정에서 문제 정의 + 해결책 도출을 하며 → 문제해결 관점에서 서비스 방향성을 잡아갈 수 있었다.
  - 보통 사이드 프로젝트를 하다보면 한정된 시간으로 인해 이미 아이디어 기반으로 특정 기능은 구상이 되어있고 이후 기획 과정이 ’그 아이디어의 기능이 필요한게 맞다!‘라는 식으로 짜맞춰가는 과정에 빠지기 쉽다.

3) 파트별 협업 과정에서 얻는 시너지 효과

디자인 파트
- 다양한 경험을 가진 디자인 팀원들과 협업하며 소통하며 많은 것들을 배워가고 있다.
- 화면을 그릴 때도 사용성을 근거로 의사결정을 하고자 하여 좋았다.
개발 파트
- 디자인을 깊게 고민, 설계할 필요 없이 사용할 백엔드 기술적으로 집중할 수 있는 환경이 좋았다. 디자인의 추후 변경 가능성을 고려하여 데이터베이스 설계를 고민해보는 순간도 좋았던 것 같다.
- 평소 대충대충 쓰던 코드는 더 깔끔히, 이렇게 코드를 작성하는 이유를 한줄 한줄 고민하며 작성해볼 수 있었다.
- 팀원들한테 내 작업이 보이니 평소보다 더 열심히 작업에 몰두할 수 있어 좋았다.
- 개인적으로 안 해본 파트를 도전하며 작업 시간이 많이 소요되었는데, 파트원들이 믿고 기다려줘서 고마웠다.
- 서버/프론트엔드가 여러명인 환경에서 작업할 수 있어서 좋았다.
- 코드리뷰 품질이 굉장히 좋다고 생각한다.

👊 Lacked (아쉬웠던 점)

1) 조금 길어진 기능 정의와 일정 딜레이

앞단에 시간을 쏟다보니 기능 정의가 빠르게 되지 않았고, 자연스럽게 일정이 조금씩 딜레이되었다.
이어서 개발자분들과 기획 측면에서 충분한 소통이 이뤄지지 않아서 탑다운으로 느끼셨을 가능성이 있다고 생각한다.
- 디자인 측에서 1차적으로 잘 완성해서 넘겨주는 것이 좋다고 생각했는데, 개발자 입장에서는 중간 과정에 대한 공유가 부족하다고 느꼈다.

2) 스펙 문서 정리와 더 명확한 디자인 시스템 가이드 필요

아직 스펙문서나 기능정의문서가 정리되지 않은 상태라, 소통을 하면서 업데이트하면 좋을 것 같다고 생각했다.
디자인팀 내부에서도 디자인 시스템을 고려하며 화면을 짤 때 시스템을 추가하는 기준이나 네이밍 등 가이드가 명확하지 않아 각 작업자마다 다르게 표현하는 화면이 생기는 것을 발견했다. 디자인 시스템 구축 초반단계라, 시스템을 구축하다보면 기준으로 참고할 수 있는 화면이 정리되면 어느정도는 해결할 수 있는 문제라고 본다.
서버 문제로 API 문서 전달이 예상보다 뒤로 미뤄진 점이 아쉽다. 앞으로 운영을 위한 서버 인프라 환경에는 더 신경쓰고 공부해서 문제 없이 운영하고 싶다.
개인적으로 욕심은 많은데 시간 관리는 잘 못해서, 작업 능률이 잘 나온것 같지는 않아서 아쉬웠다.
절대적인 양의 소통을 늘려서 작업 속도를 더 올릴 필요가 있다고 생각한다.

3) 대면 만남을 늘리자

대면 회식이 많지 않아서 아쉽다.
- 많이 만나서 함께 작업하는 시간이 더 많이 있었으면 좋겠다.
- 인간적으로 더 친해지면 작업 능률도 올라갈 것 같고 더 좋은 프로덕트가 나올 것이라고 생각한다.

👊 Learned (배운 점)

1) 디자인 파트

반응형 그리드 + 웹 환경에서 디자인 시스템을 짜다보니, 기존 익숙하게 제작했던 모바일과는 또 다르게 고려할 점이 너무 많다고 느껴졌다. 하지만 그만큼 스킬업했다고 생각한다.
실무 경험이 없는 입장에서, 든든한 능력자 파트원들을 통해 협업을 위한 파일 관리부터 네이밍, 시스템 정리 스킬 등을 많이 배워가고 있다.

2) 개발 파트

Server
- 3명의 백엔드 개발자가 작업하는 프로젝트다 보니 코드를 통합하는 과정에서 잘 돌아가는 코드인가가 중요했다. 테스트 작성을 필수로 하고 CI 환경을 구축해 서버 구동환경에서 에러가 나지 않도록 하였고, 코드를 더 깔끔하고 책임을 분리해서 설계해야 테스트가 편하다는 것을 알았다.
- 팀원들에게 새로운 기술을 적용하거나 디자인 패턴, 지켜야할 컨벤션들이 추가로 생겼다면 글로 작성해서 공유를 하는 것이 좋다는 것을 알았다. 머리로만 알고 있으면 나조차도 나중에 까먹는다는 사실..
- 막히는 부분이 생겼을 때, 시간 투자를 좀 더 하면 충분히 알아낼 수 있을 것이라고 생각해 문제 상황에 대한 디테일을 팀과 충분히 공유하지 못했다. 도움 요청이 필요할 때만 문제 상황에 대한 디테일을 공유해왔던 것 같은데, 이제 평소에도 좀 더 디테일하게 상황을 공유하려고 한다.
- 새로운 기술, 새로운 컨밴션, 새로운 개발 프로세스 기술적으로 흥미를 가지고 공부하고 있어서 재미있다.
Web
- 시스템을 처음부터 구축해나가는 경험, 즉 언제 어떻게 시스템을 구축해야하는지를 배운다.
  - 왜 개발자와 디자이너가 함께 시스템을 구축해야하는지 등
- 시간 관리와 태스크 관리에 대해 배운다.
- 컴포넌트에 대해서 이렇게 깊게 생각해 본 적이 한 번도 없었는데, 컴포넌트에 대해서 넓고 깊게 배우고 있다.
- 코드 작성 후 논리적으로 디깅하는 것, 논리에 따른 작업 흐름
- 돌아가는 코드가 아니라 왜, 어떻게 돌아가는지에 대해서 고민하는 것에 대해 배웠다.
- 여러 환경의 개발자들과 협업하다보니 개발에 대한 새로운 시각을 보게됨
  - 예를 들어 노 커밋, 노 브랜치 룰
- 당연한 것들을 당연하지 않게 바라보는 법을 배운다.
- 다른사람들과 원만하게 협업하는 방법과 원만하게 협업하며 조직의 목적을 달성하는 방법을 배우고 있다.

👊 Longed for (앞으로 바라는 점, 앞으로 적용하고 싶은)

1) 디자인 - 개발 소통 늘리기

특히 디자인 파트와 프론트의 소통을 많이해야겠다는 생각이 많이 들었다.
- 디자인 시스템을 이런식으로 짜도되는지 버튼 종류 구성을 이렇게 처리해도되는지 등 짜잘하게 고민되는 부분이 많았는데 화면 짜느라 급급해서 물어볼 여유는 없었다.
- 디자인팀 💗 웹팀만의 개별 정기 회의시간을 따로 잡아봤으면 좋겠다.
최종 화면 하나만 전달드리는 것이 아닌, 수정 사항이 생기는 경우도 고려하여 작업 중인 화면도 따로 표시하여 알 수 있도록 피그마 페이지를 정리하였으면 좋겠다.
구체적이고 중요한 것이 아니더라도 소수의 논의로 정해진 것은 전체 공유될 수 있게 노력하면 좋겠다.

2) 모든 파트가 함께하는 작업시간 늘리기

디자이너, 서버, 웹 파트 모두 작업이 한창인 만큼 같이 더 자주 모여서 작업을 하고 싶다.
일주일에 특정 날짜의 특정 시간에 게더에 모여 작업을 하는 공동 작업 시간 (코어 타임)을 정하면 좋을 것 같다.

3) 테스트 관리, 목표 관리

개발 일정 공유, 계획 관리 및 태스크 관리를 조금더 세분화해서 하면 좋을것 같다.
프로젝트를 할 때 OKR이나 이니셔티브를 세워서 우리가 해야하는 일에 대해 동기를 높이면 좋겠다.
- 예) 토스 - 인터렉션에 스며들게 하기 / 국내에서 가장 유려한 앱이 되자 → 반기마다 회고하고 진짜 실행했는지 점검

4) 더 더 더 친해지기!