[Level3] Sprint 1 회고 (25.07.08~25.07.11)

 

시작하며

우테코에서 기대하던 팀 프로젝트를 시작했다!

짧게 일주일 동안 주제를 고르고, 팀 빌딩 활동도 하고, 기획도 하고, 데모데이까지 진행했다.

 

회고

팀 빌딩

백엔드 4명, 안드로이드 3명이서 팀이 되었다.

다들 동물의 숲 주민들 같이 둥글둥글한 느낌이었다.

 

팀 빌딩 시간까지 주셔서 오후에 일찍 퇴근할 수 있었다.

우리 팀은 다같이 롯데월드에 갔다.

거의 10년만에 롯데월드인 것 같은데 야무지게 오후권으로 5개나 타고 왔다.

 

주제 선정

우리 팀의 주제는 'IT 종사자들을 위한 팟캐스트 앱'으로 결정됐다.

 

프로젝트에서 주제를 정하는 것이 가장 어렵다.

 

처음에 각자 원하는 바를 공유했다.

공통적으로 나온 니즈는

 

1. 실사용자를 쉽게 구할 수 있어야함

2. 작더라도 진짜 불편함을 해결할 수 있어야 함. (NOT : 너무 넓은 사용자 층, 불편함이 아닌 편리함)

3. 팀원들이 도메인을 이해하고, 4개월 동안 애정을 가질 수 있어야 함

+ 모바일 앱에서만 사용할 수 있는 장점들을 최대한 활용할 수 있는 주제 (GPS, 백그라운드 재생, 이동할 때 사용 등)

 

였다.

 

지도에 기록하는 서비스, 약속 장소를 결정해 주는 서비스 등의 후보도 있었지만 결국 1,2,3을 전반적으로 만족시킬 수 있는 주제로 선정이 되었다. 팟캐스트가 어떻게 2번을 만족시키냐고 할 수 있겠지만, IT 팟캐스트로 개발자들의 IT트렌드를 쉽게 얻고 싶은 니즈가 있다고 판단했다.

 

주제를 정할 때 아래 템플릿을 작성해서 사용했다.

### Pain Point
; 해결하고자 하는 문제점, **1개**의 pain point에 집중하기, 진짜 문제인지 다시 생각해보기(약간 불편하더라도 현재 방식이 너무 강력하진 않은지)

### Target User
; 대상, 대상을 쉽게, 많이, 자주 만날 수 있는지

### Feature
; paint point에 집중한 해결책, 확실하게 해결할 수 있는 방법인지(애매한 해결책 X)

### ETC
; 부가적으로 고려할 것 (기술적으로 가능한지, 학습 측면에서 적절한지, 전체 팀원이 열정을 가지고 지속할 수 있는 주제인지)

 

개인적인 생각으로는 학습측면에서 적절한지, 기술적으로 가능한지는 가장 최후에 고려할 조건들이라고 생각한다. 코치님들도 다른 건 나중에 생각하고 적더라도 실제 사용자를 모을 수 있는 주제 (결국 진짜 불편함을 해결할 수 있는 주제)를 고르라고 말씀하시는데, 나는 이 말에 정말 공감했다. 결국 실제 사용자가 있어야지 뭘 해볼 수 있다는 걸 경험으로 느꼈기 때문이다.

 

지난 1년간 외국인을 위한 한국어 발음 학습 서비스를 개발했었다. 이때, 실제로 피드백을 받아서 서비스를 개선해 보는 경험을 해보고 싶었지만 외국인을 찾기도 힘들었고, 찾더라도 언어의 장벽이 너무 컸다. 실제로 사용자가 있어야지 기술적으로 개선을 하고 필요한 기능을 도입할 수 있다는 걸 깨달았다. 주제 선정을 할 때 학습과 기술에 집중하여 선정해서 실 사용자가 주변에 있을 거라고 깊게 생각해보지 않고 간과했다. (당시 생각 : 우리 학교에 교환학생 많으니까 어떻게든 되겠지 뭐...) 

 

1차 데모데이 피드백

우리의 초반 팟캐스트 기획은

 

1. 링크를 입력하면 해당 내용으로 팟캐스트를 생성 

2. 팟캐스트 저장 및 공유

3. 다른 사람이 공유한 팟캐스트 청취

 

였다.

 

코치님들이 생성이 들어가면 고려해야 할 부분이 너무 많다고 1번, 2번 기능을 삭제하고 3번에 집중하라고 하셨다. (이때, 우리 팀이 폭주기관차마냥 1번 기능을 개발하고 있어서 진정시키기 위해 가장 첫 번째로 피드백을 해주러 오셨다...)

 

우리의 의견은 적지만 주변의 개발자들을 조사해 봤을 때, 팟캐스트로 IT 관련 콘텐츠를 소비하고 싶은 니즈가 있지만 만들기가 너무 귀찮다는 니즈가 있어서 생성하고 공유하는 서비스를 생각했다고 하자 그럼 생성까지 해서 줘야지 왜 사용자보고 하라고 하냐는 피드백이었다.

 

맞는 말이었다.

 

개발자로서 기획을 하면서 나는 '개발'만 하려고 생각을 했지 내가 팟캐스트 컨텐츠를 생성까지 해야 한다는 생각 자체를 하지 못했던 것 같다. 내가 정의한 개발자는 문제를 소프트웨어로 해결하는 사람이었지, 개발만 하는 사람은 아니었다. 문제를 해결하기 위해 개발자들이 느낀 불편함인 '듣고 싶지만 내가 직접 만들어야 함'을 해결하기 위해선 직접 팟캐스트까지 제공을 해주어야지 문제를 해결한 개발자가 되는 것이었다.

 

피드백을 받은 이후 서비스의 기능을 3번 ' 다른 사람(즉 우리)이 공유한 팟캐스트 청취'에 집중하기로 했다.

또, 기능 확장은 최소한의 기능으로 배포를 한 뒤 실제로 필요로 하는 기능을 반영하기로 결정했다.

 

최소한의 기술

기술 스택이나 코드 컨벤션 같은 걸 정하면서 백엔드 팀은 최소한의 기술을 적용하기로 결정했다. 당장에 가장 적절한 선택을 하는 것이다. 이미 일어나지 않는 일을 걱정하고, 대비하는 선택은 하지 않으려고 했다. (ex : 미래에 사용자가 대박 많아서 서버를 여러 대 띄워야 할 수도 있으니까 도커를 사용하자!!)

 

또한 코드를 짤 때도 과한 추상화, 패키지 분리 등을 하지 말자고 결정했다. 실제로 불편함을 느끼면 그때 변경하자로 결정했다. 이러한 방식을 적용하니 이유 없는 기술과 방식을 사용하지 않아도 돼서 너무 좋았다.

 

4인 페어 

서로 컨벤션을 맞추고 코드 스타일을 이해하기 위해 4인 페어를 해봤다.

생각보다 쉽지 않았다.

 

내가 코딩할 때 3명이 쳐다보고 있는 것이 압박감이 장난 아니었다. (누구도 날 압박주진 않았지만)

팀원들도 비슷하게 힘들었던 것 같다. 그래도 서로의 스타일을 이해하고 맞지 않는 부분은 토론하면서 맞춰나갈 수 있는 기회가 돼서 좋았다. (ResponseEntity, Record 스타일, test 방법 등등)

 

마무리

걱정하던 프로젝트가 시작되었는데, 생각보다 순조롭게 진행되고 있는 것 같다.

팀원들이 모두 열정적이어서 감사하다.