본문 바로가기
회고/프로젝트

마켓컬리 해커톤 우승 회고

by illlilillil 2022. 9. 12.

목차

  1. 참여배경부터 팀빌딩까지
    1. 정윤, 수민, 혜원 작성
    2. [팀 디테일리테일 결성] 정윤
  2. 예선
    1. [첫 회의-물류센터 공정 이해하기] 정윤
    2. [서비스화할 문제를 정의] 정윤
    3. [해결기능 구상] 정윤
    4. [설문조사 진행] 정윤
    5. [IA, 프로토타입, 간트차트 작성] 수민
    6. [아키텍쳐 설계] 완수
  3. 본선
    1. [각자의 위기와 어려움과 극복] 각자 작성
  4. 본선 이후
    1. [잘한 점, 뿌듯한 점]
    2. [아쉬운 점, 보완할 점]
  5. 결선
    1. [발표 연습]

 

1. 참여배경부터 팀빌딩 까지


[될까요? 에서 됩니다! 로]

정윤님 - 우연히 ‘컬리 핵 페스타 2022’ 공고를 보게 되었다. 주제1번을 보는데, 컬리 물류센터에서 알바 해 본 경험으로 어떻게든 아이디어를 낼 수 있지 않을까 하는 생각이 들었다. 보자마자 내가 생각한 물류센터의 공정과 문제점을 빈 종이에 죽 써내려봤다. 생각보다 발전시킬 만한 아이디어가 꽤 많이 나왔다.

문제는 내가 해커톤의 ‘ㅎ’ 도 모르는 진성 문과생이라는 것이었다. 소프트웨어 개발이 어떻게 이루어지는지, 팀원분들과 제대로된 소통은 할 수 있을런지 걱정이 앞섰다. 이틀 간 ‘와 이거 될 거 같은데….’ 하면서 머릿속만 복잡하다가, 내가 거의 유일하게 알고 있는 학교 선배 개발자 수민님에게 일단 아이디어나 공유해보자 하는 생각을 했다.

 

‘컬리 아이디어 제안서’ 라는 이름으로 노션 페이지를 열고, 내가 알고 있는 것들을 우다다 적은 후 수민님과 생각을 나눴다. 정말 고맙게도 해볼만 하겠다는 피드백을 받고, 함께 진행해보기로 했다. (이 때 수민 언니가 적극적으로 이끌어주지 않았다면… 절대 세상에 나오지 못 했을 아이디어다.)

 

수민님 - 여느 때와 같이 바쁜 나날을 보내던 중 정윤님에게 갑작스러운 연락이 왔다. 마켓컬리 물류센터에서 겪은 경험들이 있는데 실현 가능한지 모르겠다는, 본인이 도움이 안 될 것 같으니 아이디어나 투척하고 사라지겠다는 식의 연락이었다.(ㅋㅋ) 그녀의 자신감 없던 첫 연락과는 다르게 첫 미팅에서 정윤님에게 들은 이야기들은 나에게 “아 이거 되겠다” 하는 확신을 주었다. 내가 겪어온 해커톤 경험 상, 해커톤에서 가장 부족한 건 데이터다. 그리고 기획에서 가장 중요한 것 역시 데이터다. 데이터가 있어야 근거가 탄탄한 기획을 할 수 있고, 그 기획이 방향을 잃지 않는다. 하지만 보통 주최측에서는 주제 외에 아무런 유저 데이터나 인사이트를 제공해주지 않는다.

그런데 졍윤이는 ‘유저 데이터 그 자체’ 였던 것이다.

유저 데이터가 탄탄하다면, 그걸 분석해서 문제를 정의하고 기능을 기획하는 것은 “충분히 할 수 있는” 류의 일이었다.

그래서 수락했고, 지금도 이때를 떠올리면 내 판단이 사랑스럽게 느껴진다.

 

혜원님 - 크게 4가지 목표를 가지고 마켓컬리 해커톤에 참여하게 되었다.

  1. 우승해서 입사 연계 혜택 얻기
  2. 내 협업 방식이 어느 정도 수준인지 확인하기
  3. 백엔드 관련 설계(erd, aws, ci/cd 등) 배우기
  4. 벼르고 있었던 안드로이드 아키텍처 적용해보기

입사 연계라는 너무 좋은 조건을 내건 해커톤이라 개최 소식을 접하자마자 바로 팀빌딩에 나서게 됐는데 참가 자격에 특별히 제한을 두고 있지 않아서 현업에 계신 분들과 팀을 이루게 된다면 특히 배울 점이 많을 것 같아 매우 기대가 됐다.

하지만 물류 쪽에 배경 지식이 거의 전무했기 때문에 실현 가능한 좋은 아이디어를 내줄 수 있는 팀원이 간절했다. 며칠 간 팀빌딩에 소득이 없어서 ‘직접 물류센터 알바를 다녀올까..’ 고민하던 찰나, 정말 물류센터에서 6개월 간 근무한 경력을 보유한 정윤님이 나타났다. 팀빌딩 당시부터 노션이 잘 정리되어 있는 걸 봤을 때 놓칠 수 없는 기회라고 생각되어 간절한 마음을 담아 연락을 드리게 되었고 본격적으로 프로젝트를 시작할 수 있었다.

 

- 프로그래머스 교육 과정을 마치고 취업 준비를 슬슬 해야 하는 시기였다. 컬리 해커톤의 존재는 알았지만 마땅히 같이 할 팀원도 없었거니와 좋은 아이디어 또한 없었다. 오픈 카톡을 주시하며 좋은 기회를 엿보다 기획이 탄탄해보이는 팀에게 연락을 드렸고, 좋은 기회로 같이 하게 되었다.

 

[팀 디테일리테일 결성]

정윤님 - 수민님과 나를 제외하고 다른 팀원으로 프론트와 백엔드 한 분 씩이 필요했다. 오픈 카톡방에 팀원 모집 글을 올리자, 총 열 분 내외로 연락을 주셨다. 후보자 분들의 스펙과 질문을 여러가지 받고 질문을 하기도 했다. (사실 본인 스펙 설명해주시는 것도 나는 못 알아들어서 열심히 수민님께 정보 전달했다.)

수민님

의 검토 아래, 기술 스택이 맞는 팀원을 모아서 최종적으로 두 분을 충원할 수 있었다. 내세울 것 없는 노션 페이지 였음에도 우리 팀을 선택해주신 두 분께, 다시 생각해도 너무 감사하다.

 

2. 예선


[첫 회의: 물류센터 공정 이해하기]

정윤님 - 첫 번째 회의에서 한 일은 ‘내가 아는 컬리 물류센터 브리핑하기’ 였다. 주제1번이 ‘물류 센터 휴먼에러 감소 방안’ 이었는데, 이 방안을 이해하려면 먼저 물류센터가 어떻게 돌아가는지 모두가 알아야한다고 생각했다. 시각적 효과를 위해 prezi 를 사용하여 프리젠테이션을 제작했고, 내 기억으로는 장장 1시간에 걸쳐 설명과 질의응답을 마쳤다. 실제로 물류센터를 둘러보며 정보를 듣는 게 아니라, 설명하기에도 어렵고 한 큐에 이해하기도 어려웠다고 생각한다.

 

[서비스화 할 문제를 정의]

정윤님 - 내 머리 속에 있는 정보들 중 뭐가 쓸만한 것들인지 @SOOMIN LEE 이 정리해 주었다. 기능으로 개발시킬 지점이 분명하게 있는 부분이 있었고, pain point는 맞지만 해결점이 마땅하지 않은 것들도 있었다. 이런 지점들을 구분하여 어떤 것들을 발전시킬지 수민이 확실하게 정리해줬다. 수민이 개발 지식이 있으니, 해볼 만한 것과 그렇게는 안 될 것들을 정확하게 스캔할 수 있었다. 나였으면 더 좋은 기능을 고민하느라 계속 질질 끌었을 것이다.

정의된 문제는 다음과 같다.

  1. 작업자는 작업 투입까지 오래 걸리고, 관리자는 작업자 현황을 수기로 관리한다.
  2. 피킹 토트를 인식하지 않고 작업을 진행하는 오류가 발생함.
  3. 엔드가 송장을 분실하거나 뒤바꼈을때, qps에게 송장 재발행을 부탁해야하는 번거로움이 있음.
  4. 패킹 작업자마다 포장법, 포장 기준이 다름.

 

[해결 기능 구상하기]

정윤님 - 문제 정의를 하고 나니, 해결 기능을 구상하는 것은 보다 쉬웠다. 아래에 우리 팀 과제계획서에 첨부한 문제 - 해결 표를 첨부한다.

 

[설문조사 진행]

수민님 - 정윤님은 굉장히 구체적인 소비자 경험을 제공해 주었지만 정성적 데이터였다. 나는 이를 보완할만한 정량 데이터를 수집하고 싶었고, 그래서 설문조사를 제안했다. 설문조사를 통해 추가 기능을 기획할 수 있었고, 해결안의 수치적 근거와 기대효과를 수치화할 수 있었다. 물론 수집된 설문의 양이 부족해서 충분한 객관성을 확보하지 못했다는 아쉬움은 있지만, 정윤님이 제공하는 정성 데이터를 보완하는 정도로는 아쉽지 않게 사용할 수 있었다.

설문조사를 시행하면서 내가 놀랐던 점은 정윤님의 적극성이다. 정윤은 단순히 커뮤니티에 설문을 올리는 것에 그치지 않고, 블로그를 뒤져서 마켓컬리 아르바이트를 한 사람들에게 일일이 쪽지를 보내 설문을 요청했다.

 

[IA, 프로토타입, 간트차트 제작]

수민님 - IA, 프로토타입, FLOWCHART, 간트차트 등을 만들어서 개발자 분들에게 공유했다. IA, 프로토타입은 정윤이 함께 만들어주었는데 함께하지 않았다면 많은 산출물들을 이렇게 짧은 시간에 모두 만들어서 전달하기 힘들었을 것이다. 함께 한 덕에 기획 단계가 빨리 끝나서 개발 일정을 조금 더 앞당길 수 있었고, 이후에는 개발자 분들의 엄청난 실력이 더해져서 거대한 이 시스템을 완성도 있게 개발해 낼 수 있었다.

 

[아키텍처 설계]

- RDS, EC2는 수민님이 만들어주셔서 수정할게 없었다. CI/CD는 혼자 처음해봤는데 같이 프로그래머스 과정을 들으며 친해진 범석님께서 많은 도움을 주셔서 일사천리로 끝낼 수 있었다.

 

[KurlyFlow 애그리거트 및 바운디드 컨텍스트]

 -  건축을 하기 위해선 기초, 즉 뼈대가 탄탄해야 한다. 이처럼 좋은 설계가 좋은 품질을 만든다고 생각한다. 우리가 다뤘던 프로세스들을 정의하고 애그리거트별로 도메인을 나누는 작업을 했다.

3. 🔥본선 진출


[각자의 위기와 어려움과 극복]

수민님 - 나는 UX에 집착하는 경향이 있다. 내가 만든 프로덕트를 보고 사용자(발표자료의 경우에는 심사위원)가 제대로 이해하지 못한다면 그건 실패한 UX 기획이다. 심사위원분들이 어떻게 하면 힘들이지 않고 우리의 프로덕트를 이해할 수 있을까 고민이 많이 되었다.

왜냐하면 이번 프로덕트는 프로덕트를 만든 우리도 헷갈리는 부분이 많을 정도로 복잡성이 높았기 때문이다. 우선 물류라는 도메인 특성 상 단어들이 생소했다. 또 우리가 만든 시스템은, 어플리케이션 내에서 하나의 FLOW를 따라 이동하는 일반적인 앱이 아니라, 오프라인에서의 행동이 주가 되고 어플리케이션이 보조적 역할을 하는 성격의 시스템이었다. 그렇기 때문에 시연영상 만으로는 이게 무엇을 위한 기능인지 이해하기 힘들었다.

그래서 애니메이션을 선택했다. 애니메이션을 통해 이 어플리케이션을 사용하는 작업자와 관리자의 ‘오프라인에서의 행동’을 보여주고 중간중간 시연영상을 덧붙여 시스템이 어떻게 물류 시스템을 보조하는지 보여주었다.

 

혜원님 - 훌륭한 아이디어들이 너무 많은 덕분에 무시하지 못할 개발 양이 쌓이게 되었다. 그려야 하는 페이지만 대충 15~20개 였는데 또 예선 마감부터 본선 마감까지 9일 밖에 없었기 때문에 본선 진출은 거의 확정적이다 생각하고 본선 전부터 미리 구현하기 시작했다.

나도 마찬가지였지만 서버 개발도 완수님 혼자서 하다 보니 빠르게 완료되기 어려웠다. api 명세서는 모두 작성되어 있는 상태였음에도 당시 기획 쪽에서 수정되는 부분이 꽤 있었기 때문에 분명 api 설계도 어느 정도 바뀔 거라고 예상됐다. 그렇게 서버 개발 속도에 맞춰가다 보니 클라이언트 쪽 개발도 늦춰지게 되었고 막판에는 12시간씩 개발만 하게 됐다.

거기에 부족한 실력까지 더해져 목표로 잡았던 안드로이드 권장 아키텍처 적용은 꿈도 꿀 수 없었고 가능한 보기 좋게 패키지를 나눠서 mvc 아닌 mvc 구조..로 개발하게 되었다. 실전에서 적용할 수 있게 공부는 미리미리 해두자. 개발자의 길은 멀고 험하니까..

본격적으로 api를 연결하다보니 서버의 문제인지 클라이언트의 문제인지 알기 힘든 순간들이 있었다. 협업에 있어서 api 명세가 되게 중요하다고 깨닫는 순간이었다. 시간적 압박으로 나도 문서화에 전혀 참여하지 못했기 때문에 할 말이 없지만.. response body 구조를 잘 만들어 놓는 게 필요해 보였다.

거의 매번 header에 토큰을 담아줘야 하고 request가 body 형식이다 보니 간단하게 웹상에서 url로 테스트할 수가 없어서 매번 api 테스트를 완수님에게 의존(죄송합니다)했다. postman을 설치하면 됐지만 심심하면 블루스크린을 띄우는 낡고 지친 노트북에게 새로운 프로그램을 설치한다는 게 요즘 가장 두려운 일이다. 그러다 보니 완수님이 놓치는 부분이 생기면(예 - 동일한 코드임에도 로컬과 배포 환경이 달라서 로컬 서버 테스트는 잘되지만 배포 서버 테스트는 안될 때) 나라도 문제를 발견해야 하는데 그게 안됐다. 몇 시간을 정상인 곳에서 문제를 찾는데 낭비한 후에야 무언가 잘못 됐다는 걸 깨닫고 postman을 깔았다. 그리고 배포 서버의 문제를 찾을 수 있었다. 책임을 미루지 말자.

 

- 처음 ERD를 짤 때 생소한 용어들이 많아 혼동이 있었다. 여러 차례 수정을 거치면서 느낀 점은ERD 짜는 것에 과도한 시간이 소모된 다는 걸 느꼈다.. 물론 중요한 부분이지만 우리 팀이 원하는 것은 완성된 로직이고 잘 돌아가는 서비스일텐데라는 생각이 들었다. 이때부터 ERD에 의존하지 않고 요구 사항에 따라 도메인을 만들어갔다. 단순했던 요구 사항이 개발에 들어갔을때 데이터 전체 구조를 바꾸기도 했었다.

두번째 어려움은 로컬과 배포 환경의 os Lang이 달라 날짜 표시 형식이 달랐던 점이다. ORA-01861라는 문제로 인해 원하는 쿼리가 수행되지 않았다. 해결 방법은 두 가지가 있었지만, 빠르게 만들어야 하는 해커톤 특성에 맞춰 배포 환경의 os Lang을 바꿔주는 방식으로 해결했었다.

세 번째 어려움은 userDetails의 커스텀 구현체를 여러 개 등록해 securityContext에서 올바른 객체를 불러오지 않는 문제였다. 우리 팀은 현재 단일 어플리케이션이지만 추후 실사화된다면 여러 앱으로 나뉜다는 설정을 가지고 있었기에 관리자와 작업자 테이블로 분리해야 했다. 이과 정에서 userDetails를 여러 개 등록해야 했고, 작업자, 관리자 config를 따로 두어 두 가지 모두 등록하며 해결할 수 있었다. 이 후가 문제였는데,, loadUserByUsername를 구현할때 동일한 커스텀 객체를 반환해야 securityContext에서 잘 불러올 수 있는데 userDetails에 대한 이해가 부족해 두 개의 객체를 반환해버려 @currentUser같은 어노테이션 사용시 불러오는 객체가 상이해 지속적인 문제를 발생시켰다. 인지하지 못한채 개발하다가 제출 마지막 날 발견해 시간적 압박이 있었지만 다행히 빠르게 해결할 수 있었다.

 

4. 본선 결과물 제출 이후


[잘한 점, 뿌듯한 점]

정윤님 - 본선은 할 말이 없다! 다들 너무 잘해주셨다! 나는 물개박수나 쳐야겠다!

 

수민님 - 데이터를 기반으로 기획하고자 설문조사를 제안한 점, 데이터들을 기반으로 문제와 기능을 정의한 점, 산출물들을 자세히 작성하여 커뮤니케이션 하고자 한 점, 제출물과 발표자료의 UX를 신경쓴 점은 스스로 칭찬해주고 싶다. 하지만 우승에 가장 큰 영향을 미친 것은 팀워크이다. 팀원들 모두 하루에도 여러 번 소통하려고 노력했기 때문에 좋은 결과가 있었던 것 같다. 그리고 가장 놀랐던 것은 개발 퀄리티였다. 기획을 찰떡 같이 업그레이드 해주신 것 같다.

 

혜원님 - 팀원들이 새벽에도 늘 연락이 잘 닿을 정도로 모두 열정적이어서 ‘이런 게 팀플이지…’ 하고 재밌었다. 무엇보다 나태하던 요즘, 한번을 안 움직이고 12시간 동안 개발에만 집중해서 기능 구현을 모두 완료했을 때 정말 짜릿했다. 이런 경험이 자존감을 올려준다는 것을 깨달아서 앞으로 좀 더 열심히 살 수 있을 것 같다.

 

- 짧은 시간 안에 많은 API를 개발했다는 점이 뿌듯하다. 팀원들의 피드백이 너무 빨라 기획을 개발로 끌어올때 생기는 문제들이 있었지만 비교적 빠르게 해결할 수 있었다. 

 

[아쉬운 점, 보완할 점]

정윤님 - 정신없이 개발 과정을 옆에서 지켜보고 나니, 유능한 기획자가 중요하구나를 깨달았다. 나는 정말 모지리였기 때문에 화면 구성에 출력되는 값이 무엇인지도 미리 작성을 안 해두고 팀원 분들이 여쭤봐야 답을 내놓는 (ㅜㅜ) 감자였다. 그래도 팀원분들이 정말 친절하게 질문해주시고 이해해 주셔서 무사히 마칠 수 있었다. 개인적으로 ‘적어도 소통에 문제는 없게끔 개발 프로세스를 알아야겠구나’ 하고 많이 반성하는 계기가 되었다.

 

수민님 - 페이지 간의 연결에 있어서 놓친 부분이 있었지만, 개발자분들의 피드백을 통해 개선할 수 있었다. WIRE FRAME을 작성할 때 꼼꼼한 기획이 필요하다는 것을 깨달았다. 또 개발이슈 발생을 염두에 두고 여유롭게 프로젝트를 매니징해야 겠다는 생각도 들었다.

 

혜원님  - 서버 환경 구축이나 api 명세에 참여하지 못해서 아쉽다. 어느 정도 백엔드 파트에도 손을 댈 수 있을 거라 기대하고 시작했는데 도저히 시간적 여유가 없었다. 특히 완수님이 DDD 아키텍처나 CI/CD 등 내가 몰랐던 부분을 알고 계신 게 많아서 직접적으로 협업 했다면 배우는 게 많았을 것 같은데 역시 아쉽다.

mvvm 아키텍처나 테스트 코드 작성에 대해서 공부하고 적용할 수 있는 프로젝트가 되기를 바랬는데 이 역시 어려웠다. 반성을 머금고 간단한 토이 프로젝트를 통해 안드로이드 AAC에 대해 공부를 시작했다.

restful api 설계와 협업에 있어서 좋은 명세란 무엇일지 고민하고 알아보는 시간을 가져야겠다.

서버 개발이 완료 되지 않아도 클라이언트 개발만 질주할 수 있는지 궁금해졌다. mock 데이터라는 단어를 들은 적 있는데 관련이 있는지 알아봐야겠다.

 

- 시간적 여유가 부족해 도메인 위주의 테스트만 확인하고, 서비스, 컨트롤러 단의 테스트를 하지 못한 점이 아쉬웠다. 

 

5. 결선 진출


1. 발표 준비

[끊임없는 영상 수정과 발표 연습]

정윤님 - 발표는 내가 마지막으로 팀에 기여할 수 있는 부분이라고 생각했다. 5분의 분량 제한이 있었고, 우리는 수민님이 만든 영상 길이를 딱 5분으로 수정하여 여기에 내 멘트를 맞추는 형식으로 계획했다. 나의 대사와 영상의 싱크가 맞아야했기에, 미세하게 2초 3초씩 수정이 필요했고 따라서 수민과 실시간으로 밤을 새며 수정을 거듭했다. 발표 당일 오전 5시에 컬리해커톤 운영팀에게 최종 영상본을 제출하고, 잠에 들었다. 

2. 행사장 참석, 발표

[생각보다 축제같던 행사장]

정윤님 - 행사장에 도착하기 전에, 팀원들끼리 먼저 모여 발표 피드백을 듣고 예상질문을 연습하는 시간을 가졌다. 

 

질문이 들어왔다. 소개 문구에 DDD를 활용해 확장에 용이한 설계라고 얘기했기 때문에 질문이 나올 수 밖에 없었다. 준비는 해놨지만 당시 머리가 하얘져 질문에 대답을 잘 하지 못했다..ㅠㅠ 지금에서야 답변을 적어보자면 기능적, 트래픽 측면 두 가지 주제로 나눠서 대답할 수 있을 거 같다. 

 

첫번째 기능적 측면

비즈니스를 도메인 별로 나누어 도메인 간 의존성을 최소화하고 응집성을 최대화하였다. 그렇기에 기능적인 확장을 하더라도 의존성이 적기 때문에 무리 없이 확장성을 가져갈 수 있다.

두번째 트래픽 측면

트래픽 성능 향상에 대해 가장 먼저 떠올렸던 것은 스케일 아웃, 읽기 성능 향상이다. 대부분의 api 요청이 읽기 요청이기에 우선적으로 고려해볼 수 있다.

첫번째는 캐시를 적용하는 것이다. 레디스 캐시를 적용해 읽기 성능 향상을 꾀할 수 있을 것이다.

두 번째는 DB Replication이다.

이번 프로젝트에 적용한 방법은 DDD + CQRS 모델이다. 명령 조회 모델을 분리하는 것만으로도 목적성을 명확히 줄 수 있어서 좋았다. 우리 프로젝트는 단일 데이터베이스로 되어 있어 성능상 이점이 없지만 추후 조회 모델에 NoSQL을 사용해 성능 상 이점을 챙길 수도 있다. 이 때 데이터 정합성 문제가 대두되는데 일정한 시간마다 RDBMS에서 이벤트를 발행해 NoSQL에 반영하는 식으로 해결할 수 있다. 메시지큐로 카프카를 사용하면 이벤트 발행에 실패하더라도 내역이 전부 남기때문에 예외 복구에도 좋다.

🔥🔥🔥 우승 🔥🔥🔥


1. 시상식

정윤님 - 수상 소감 때 팀원들 이름을 호명하지 못 한 게 너무너무 아쉽다. 믿을 수가 없어서 팀원들만 계속 쳐다봤던 기억이 난다. 

수민님 - 기획과 개발 완성도 모든 측면에서 우리 프로덕트에 자신이 있었지만, 너무 쟁쟁한 팀들이 많았고, Q&A가 미흡한 부분이 있어서 기대를 안하려고 노력했다. (발표하실 때 일부러 딴 데 쳐다보고 있었다.)

김슬아 대표님이 가장 첫 팀으로 우리를 호명했을 때 어두운 장내가 대낮같이 환해지는 느낌을 받았다. 팀원들이랑 팔을 쭉 뻗고 거의 얼싸 안고 있었던게 기억이 난다.

 

2. 회식

정윤님 - 고기를 안 먹어도 배가 부르고 술을 안 마셔도 취하는 기분이었다. 500만원 상금이 적힌 우승 판넬을 식당에 전시해두면서 직원분들한테 자랑도 했다..

 

수민님 - 감사합니다 x 무한대 :: 서로에게 무한 감사를 표하는 회식 자리였다.

 

3. 마무리

정윤님 - 내 인생 최고의 ‘팀웍’을 경험했다. 소통에 어려움이 많았을 나를 멱살 잡고 견인해서 우승까지 책임져준 모든 팀원 분들께 감사하다.

수민님은 (내 정신적 안식처) 풍부한 공모전 경험으로 지금 시간에 해야 할 일이 무엇인지 정해주어서 모든 일이 시간 안에 진행 될 수 있었다. 혜원님의 꼼꼼함으로 기획 논리에 빠진 구멍을 채울 수 있었으며, 디자인까지 도맡아주셔서 큰 힘이 되었다. 완수님이 혼자 백엔드를 맡아 방대한 양의 개발을 진행해주셨고, 소통할 때도 쉽게 풀어서 말씀해주셔서 감사해하고 있다. 개인적으로는 이번 해커톤으로 기획 직무의 매력을 알게 되어서, 더 공부해보려고 한다.

 

수민님 - 자기 역할에 충실한 것 이상으로, 모든 팀원이 적극적으로 전체 프로젝트에 대한 의견을 내고 서로에게 피드백을 주면서 원팀이 무엇인지 배울 수 있었다. 부족했던 기획에 최고의 아웃풋을 내준 개발자분들께 너무 감사하다.

혜원님은 기획과 개발 모든 파트에 예리한 피드백을 주어 완성도 있는 프로덕트를 만들 수 있게 해주셨다. 기획을 하면서도 믿음직한 혜원님이 한번 더 봐주실 거라는 게 참 든든한 기분이었다. 그 꼼꼼함과 개발 속도는 말할 것도 없다. 👍

완수님의 부드러운 소통 방식은 닮고 싶은 점이 많다. 개발에 바쁠 때에도 기획적인 의견을 굉장히 적극적으로 수용해주셨고 피드백도 빨랐다. 개발 속도 뿐 아니라 구조적인 부분을 놓치지 않으려는 모습도 참 멋있었다. 👊

정윤님의 에너지는 나에게도 많은 자극이 되었다. 물류 도메인을 설명하려고 프레지를 만들어오거나 설문을 위해 블로거에게 쪽지를 보내는 모습은 깊은 인상으로 남았다. 컬리 아르바이트를 하면서 배우고 느낀 것을 토대로 프로젝트 모든 과정에서 최고의 ‘유저 데이터’가 되어준 정윤에게 감사하다. 😘

 

혜원님 - 개발 뿐만 아니라 프로젝트 수립과 진행에 있어서 PM을 맡아주신

수민님과 기획을 맡아주신 정윤님에게도 배울 점이 많았다. 프로젝트 전체 일정을 미리 계획해서 간트 차트로 표현하거나 모든 기능을 자세하게 플로우 차트로 만드는 등 협업은 말로 소통하는 게 다가 아니다 라는 걸 잘 알 수 있었다. 또 공모전 나갈 거 있으면 언제든 불러주세요 ^^ 다들 고생 많으셨고 정말 고맙습니다, 디테일리테일 팀!

 

-  이해가 부족해 팀원분들께 질문할 거리가 수도 없이 많았는데, 그때마다 바로 바로 답해주시고, 해결해주셔서 병목없이 온전히 개발에만 집중할 수 있었다. 기획이 바뀌거나 개편되면 개발하기가 어려워지는 상황이 생기는데 처음부터 좋은 기획을 가지고 계셔서 개발하기 수월했다. 다시 한번 좋은 기획을 내주신 정윤님, 수민님께 감사드리고, 가장 고생한 혜원님께도 감사드립니다.  고생하셨습니다!!!!

 

프로젝트 링크

과제 계획서 - https://drive.google.com/file/d/10bG3zmDK-itsKCObTtsnK3s-HUjMxr2P/view

Front - https://github.com/Kurly-Flow/Kurly-Flow-FE

Back - https://github.com/Kurly-Flow/Kurly-Flow-BE

댓글