메가테라 웹 개발자 과정 20주차 주간 회고

 

3주차 스프린트 주간 작업 목표 및 성과 분석

주간 작업 목표
: 제품의 MVP를 제작해 의도한 가치를 전달하는지 확인한다.

상세 목표
- 최소 기능에 대한 프로젝트 설계 문서 완성
    - 기존 사용자 스토리 반려
    - 최소 기능 사용자 스토리 작성
    - 작업 목록 재작성

- 최소 기능 구현
    - 모델 최소화
    - 운동 게시글 목록 조회
    - 운동 참가 신청
    - 운동 참가 취소

 

---

설계 없는 구현, 검증할 수 없는 구현은 밑 빠진 독에 물 붓기

 

이번 주차는 지난 1, 2주차 스프린트 주간에 어떤 문제가 있었는지 깨닫고 방향성을 바로잡기 위해 몸부림쳤던 한 주였다.

작업 속도도 지지부진했는데 그마저도 결과물이 나오지 않았던 이유는 무엇이었나.

 

사용자 스토리가 가치 중심이 아닌 화면 중심이었다.

사용자 스토리를 다시 돌아본 내용은 완성된 화면을 짜집기해서 글로 풀어 쓴 모양새였다. 그로부터 나오는 작업 목록은 화면에 의존적이었다. 화면 하나하나를 담고 있던 작업은 리소스가 너무 많았고, 핵심이 무엇인지 불명확했다.

 

설계 문서가 없었다.

작업 구현은 사용자 스토리를 기반으로 작성한 작업 목록을 보면서 구현 직전에 로직을 작성하고 구현에 들어가는 식으로 이루어졌다. 이는 잘못된 API 네이밍을 하거나, 기능에 필요한 리소스를 놓치거나, 지나치게 많은 리소스를 기능에 부여하는 결과로 이어졌다.

 

한 번의 작업 단위가 지나치게 크고 복잡했다.

특히 기능의 테스트 코드를 작성하면서 크게 느꼈던 부분이다. 게시글 목록 조회 같은 경우 API 요청의 결과로 주어지는 응답 데이터의 depth가 3 depth 이상으로 들어갔다. 아무 기반이 없는 상태에서 한번에 큰 복잡도를 갖는 기능은 구현에 며칠을 투자해도 피드백을 할 수 있는 유의미한 결과가 나오지 않았고, depth가 깊어질수록 테스트 코드의 크기가 기하급수적으로 늘어나면서 감당할 수 없는 수준이 되었다.

 

질문하지 않았다.

이 모든 문제들을 아샬님이 설계 문서를 리팩터링해주시고, 메가오버플로우에 올렸던 질문에서 설계 상의 문제점을 지적해주시기 전까지는 문제가 있음이 느껴짐에도 질문하지 않고 그대로 끌고 가려 했다.

 

 

문제의 근원이었던 사용자 스토리부터 다시 쓰기

작업 단위를 작게 가져가려면 일단 참고할 설계 문서가 있어야 했고, 설계 문서를 올바르게 만들려면 사용자 스토리가 다시 쓰여야 했다. 눈물을 머금고 자체 1주차로 돌아가는 결정을 내렸다. 기존에 만들었던 화면 중심 사용자 스토리와 UI 프로토타입, 하루 단위로 작업하기에는 지나치게 컸던 작업 목록을 잠시 내려놓았다. 매몰비용에 매달려 있으면 5주차, 6주차, 7주차가 되어도 같은 고민을 반복하고 있을 것 같았다.

 

스스로의 생산성을 생각했을 때 1주차에 그림을 그리면서 만들었던 기능들 만큼의 사용자 스토리를 다 써 내는 것은 불가능했고, 목표는 최소 기능이였던 만큼, '많고 많은 기능들 중에 가장 근본이 되는 기능부터 사용자 스토리를 작성하자'는 쪽으로 방향을 잡았다.

 

내가 생각했을 때 내 애플리케이션에서 가장 최우선적인 근본은 일단 운동 종류, 일정, 장소를 보는 것이라고 생각했다. 그 외의 정보는 모두 쳐냈다. 그 다음으로는 신청할 수 있어야 하고, 그리고 누가 신청했는지 서로 알 수 있어야겠다고 생각했다. 관련된 내용을 사용자 스토리와 인수 테스트로 작성했다. 일단 거기까지만 했다.

 

고민은 설계하면서 하고, 구현은 받아쓰기

Github Project에서 잠깐잠깐 고민하면서 쓰던 내용을 이제는 문서에 작성하기 시작했다. 14주차에 있었던 마카오뱅크 설계 문서 양식을 따라 URL부터 REST API까지의 스펙을 정의했다. 요청을 보내면 어떤 응답이 돌아와야 하는지, 백엔드 처리 과정은 어느 레이어의 어느 동작을 거쳐 구현되는지를 적을 수 있는 만큼 적어보았다.

 

구현은 설계에 적은 내용을 보면서 베껴 쓴다는 느낌으로 진행했다. 구현하면서 문서로 쓸때와는 약간 다른 부분이 생기기도 했지만, 그럴 때는 설계 문서와 구현 양쪽 중에서 더 적합할 것 같다고 생각되는 쪽을 정하고, 반대쪽을 정한 쪽에 맞게 수정했다.

 

목요일부터 이 방식을 최대한 지키려고 해본 결과, 아직 최소기능이기도 하고 한 번은 먼저 해봤기 때문에 그랬을 수도 있지만, 만들어지는 작업 단위가 하나하나가 지나치게 커지지 않게 되었고, 예상 스토리 포인트와 실제 사용 스토리 포인트가 서로 엇비슷한 범위 내에서 형성되게 되었다.

 

---

3주차 스프린트 주간 스토리 포인트 사용량 분석

사용자 스토리	작업명	예상	실제	비고
	프로젝트 설계 문서 재작성	24	24	월~수
1. (a-i) 운동 게시글 목록 조회	운동 게시글 목록 조회 리소스별 API 호출 분리	4	4	수
	모델 최소화, 운동 게시글 목록 조회 참조 리소스 최소화, API 호출 통합	5	7	목
	값 객체 정의	2	4	토
	fake 메서드 인터페이스 개선	6	7	토
	예외처리 추가	2	1	일
	UI 컴포넌트 분리 (게시글 목록 조회, 신청/취소)	2	3	일
4. 운동 참가 신청	운동 게시글 목록 조회 시 User Id Access Token 기준 신청/취소 출력 버튼 구분	3	2	금
	운동 신청 API 요청	2	5	금
	운동 신청 POST 요청 처리	3	3	금
	예외처리 추가	2	4	일
5. 운동 참가 취소	운동 참가 취소 API 요청	1	1	일
	운동 참가 취소 DELETE 요청 처리	2	2	일
합계		58	67	설계 개선 작업, 목요일 이전 작업 제외 시 (-28) = 39

 

내 평균 작업량은?

작업 목록에서 작업을 가져와 문서와 프로젝트 칸반 보드에 설계 과정을 작성하면서 구현을 진행한 것은 실질적으로 수요일부터 진행했던 운동 게시글 목록 조회 리팩터링부터였다.

 

문서에서 제시한 아키텍처 구조를 따르고 테스트 코드로 동작을 검증하는 하나의 최소 단위의 작업은 4일 동안 3가지가 구현되었다. 해당 작업 속도를 참고할 때 일주일 동안 기능을 설계하고 구현할 수 있을 것으로 생각되는 최소 단위 기능의 개수는 약 5~7개일 것으로 추정된다.

 

---

4주차 스프린트 주간 작업 계획

4주차 스프린트 주간을 보내면서 따라볼 방식들과 구현할 기능들은 다음과 같다.

 

목표 달성 기준을 세운다

작업을 하면서 '내가 지금 한 주차의 목표를 달성하기 위해 작업을 정말로 잘 하고 있는지' 파악하기 위해서는, 달성 기준으로 삼을 수 있는 목표가 있어야 한다. 왜 이 작업을 하고 있는지 스스로에게 설명할 수 있어야 작업이 막힌다 하더라도 동력을 쉽게 잃지 않을 것이다.

 

완성본이 제시하는 핵심 가치의 기준을 생각한다

이번 주에 구현했던 MVP는 스스로는 모집에 정말 필요한 핵심적인 내용을 빠뜨리지 않았다고 생각했지만, 노아 트레이너님과 이야기를 나누면서 챙기지 못했던 다른 핵심 가치들을 발견할 수 있었다.

 

운동을 할 사람을 모집하기 위한 최소한의 필요한 정보라고 한다면 '종목' '장소' '일자' '인원 수'면 충분하다고 생각했다. 그러나 내가 이 앱을 이용해서 야구할 사람을 찾는 상황이라고 생각해보면, 저 장소에서 모인다는 사실이 진짜인지 아닌지 확인할 방법이 마땅치 않았다. 작성자의 연락처 같은 게 있는 게 아니었기 때문이다.

 

노아님과 이야기를 나누면서 핵심 가치로 놓치지 말아야 하는 것이 무엇인지 이전보다 조금은 더 알 수 있는 느낌이었다. '사용하기 불편하든, 편하든 어쨌든 사용자의 목적을 계속해서 충족시켜 줄 수 있는가?'에 대한 부분을 계속 가져가는지 생각할 수 있어야겠다.

 

구현이 끝나면 놓치지 않는 디테일이 없는지 점검한다

노아님께 MVP를 보여드리던 도중 질문이 들어왔다. 모집 정원 24명 중 23명이 신청되어 있는 상태에서, 내가 1자리가 남은 화면을 보고 신청하려는 사이 다른 누군가가 먼저 신청해서 내가 신청 버튼을 클릭하는 순간에는 정원이 가득 차 있다면 어떻게 처리되는지를 물으셨다. 사용자의 수를 데이터베이스에 정해진 수만 넣어놓고 구현을 진행하고 있었기 때문에 미처 생각하지 못한 부분이었다.

 

작업을 마치고 완료 목록으로 옮겨놓은 작업이라 하더라도, 실제 사용자 입장에서 생각하면서 '이런 경우에는 어떻게 될까?'를 생각하면서 작업해야 할 것이다.

 

주간 작업 목표
: 운동 모집 게시글이 새로 작성되거나 삭제될 수 있고, 사용자가 신청하면 작성자가 수락하거나 거절할 수 있는 순환 구조를 갖는 애플리케이션이 되도록 MVP를 확장한다.

상세 목표
- '핵심 가치'를 사용성에 반영
    - '모집'을 하기 위해 가장 필요한 내용을 찾아 모델에 반영

- 기능 구현
    - 게시글 상세 정보 보기
    - 운동 참가 신청 수락
    - 운동 참가 신청 거절
    - 게시글 작성
    - 게시글 삭제
    - 게시글 수정

 

---

If I had ...

지난 몇 주일간 고통을 겪으면서 끊임없이 들었던 생각이다. '진작에 질문을 자주 하는 습관을 들였더라면...' '진작에 읽으라는 책 좀 읽었더라면...' '자전ㄱ...'

 

만약 지금 눈앞에 타임머신이 생겨서 5월 7일로 돌아갈 기회가 생긴다고 한다면, 돌아가서 그때 했던 선택들을 절대 하지 않고 완전히 다른 선택만을 하리라는 보장이 있을까, 그렇지 않을 것이다. 분명 똑같은 실수를 반복하고 똑같은 과정을 겪을 것이다.

 

'하라고 한 것을 하지 않았을 때 어떻게 되는지' 몸소 겪었기 때문에 이제는 그렇게 해야 할 당위성이 있다. 그렇기에 지금 겪는 고통이 절대 의미없는 고통이 아니다.

 

 

'그때 그렇게 했더라면'으로 고통받는 것은 이 정도면 그만 됐다.