다른 포스트에서 말했듯 현재 나는 6개월간 동일한 주제를 가진 프로덕트를 2번씩이나 뒤엎고 만들고 있다. (링크 참조 : 2번의 프로젝트 관리 실패로 배운 1인 개발의 씁쓸한 회고록)

그 과정에서 뼈저리게 느꼈던 후회는 잘못된 점을 빠르게 캐치하고 고쳐야 했다는 것이다. 그래서 이번 개발 할 때는 내가 만들고자 하는 기능들을 가장 작은 단위들로 나눠 빠르게 개발하고 개발 과정을 측정하고 배우는 애자일 개발 방법론을 이용하기로 했다.

나는 이 작은 단위들을 Slice 라고 정의하기로 했고 지금 적는 회고록은 내 프로젝트 첫 번째 Slice 에 대한 회고록이다.

note

회고록 자체를 처음 써보기에 LLM에게 어떻게 해야 회고록을 잘 쓸 수 있냐 템플릿을 물어보고 방식들을 물어봤다.
템플릿을 가져오고 깊은 고민을 하기 보다 빠른 시간안에, 줄글보다 불렛 형태로 쓰는 것이 낫다고 하여 그 방법들을 차용하여 적어본다. (줄글 형태를 유지하면 감정을 제외하고 팩트만 기록 할 수 있고 추후 회고를 모아 데이터화 할 때 도움이 된다고 한다.)

정량적 사실 확인 (Fact Check)

Lead Time : 첫 번째 슬라이스를 기획하고 배포까지 얼마나 시간이 걸렸는가?

• Target : 7일 (1월1일 ~ 1월7일)
• Actual : 12일 (1월 1일 ~ 1월12일) -> 5일 지연
• Pivot Log : 초기 10일간(12/22~31) 직접 에디터를 구현하려다 실패. "직접 구현" 포기 후 "라이브러리" 도입 결정. 이 결정이 없었다면 이번 슬라이스도 실패했을 것임.
• Delay Reason : 구현이 완료된 슬라이스에 대한 기획이 변경되어 다시 구현을 하는 행위가 반복되면서 개발이 지연되었음 (초기에 모델링 했던 데이터 형태로 50% 구현하였다가 데이터 모델을 변경하여 다시 구현)

Accuracy : 계획한 기능 범위와 실제 구현된 기능의 범위 차이는 ?

• Planned: 에디터 UI, DB 모델링, 교정 API, LLM 연동, DB 저장, GA 연동
• Delivered: 에디터 UI(라이브러리), 최소 DB, 교정 API, LLM 연동, DB 저장
• Scope Cut (제외된 기능): GA 연동 파트
• Reason: 핵심 가치(에디터를 이용한 영어 교정)와 무관한 독립적 기능임. 다음 슬라이스로 이관 결정.

Tech Dept : 나중에 고쳐야지하고 처리하거나 하드 코딩한 부분은 몇 군데인가?

1. [API/Convention] 정해둔 코드 컨벤션(함수형) 위반

• Status: 서버 로직을 함수형으로 작성하기로 약속했으나, 실제 구현 시 습관적으로 절차지향 코드를 작성하여 스타일이 혼재됨.
• Reason: 익숙함에 기댄 관성적 코딩 & 구현 속도 압박.
• Priority: [Medium] (당장 에러는 안 나지만, 코드가 쌓일수록 가독성과 유지보수성이 급격히 떨어짐. 다음 슬라이스 시작 전 리팩토링 권장.)

2. [API/Security] 프로덕션 환경 로깅 노출

• Status: 디버깅을 위해 찍어둔 로그가 프로덕션 레벨에서도 차단되지 않고 그대로 노출됨.
• Reason: 로거(Logger) 설정 미비 및 환경 변수(Environment Variable)에 따른 분기 처리 누락.
• Priority: [High] (보안 취약점 및 성능 저하 원인. 즉시 해결 필요.)

3. [API/Cleanup] 더미(Dummy) 코드 방치

• Status: 이전 슬라이스 테스트 용도로 만든 라우트 핸들러가 삭제되지 않고 남아있음.
• Reason: '혹시 나중에 볼까 봐' 하는 미련 & 정리 귀찮음.
• Priority: [Low] (기능에 영향 없음. 눈에 거슬릴 뿐.)

4. [Types] any 타입 남발

• Status: 데이터 모델링이 완벽하지 않아, 타입 정의를 건너뛰고 any로 떡칠된 코드가 다수 존재함.
• Reason: DB 스키마가 확정되지 않은 상태에서 빠르게 기능을 구현하려다 보니 발생.
• Priority: [High] (TypeScript를 쓰는 의미가 퇴색됨. 비즈니스 로직이 복잡해지기 전에 타입 정의(Type Definition)를 바로잡아야 함.)

5. [DB/Migration] Supabase 마이그레이션 관리 미흡

• Status: DB 변경이 잦았으나 마이그레이션 파일이 정리되지 않고 지저분하게 쌓여 있음.
• Reason: Knowledge Gap (Supabase CLI 및 마이그레이션 워크플로우에 대한 이해 부족으로 건드리지 못함.)
• Priority: [Medium] (혼자 개발할 땐 괜찮지만, 실수로 DB를 날릴 위험 존재. 학습이 필요한 항목.)

6. [Frontend/Code Quality] 매직 넘버/스트링(상수) 미분리

• Status: 코드 곳곳에 하드코딩된 문자열이나 숫자가 그대로 박혀 있음 (상수화 안 함).
• Reason: "일단 돌아가게 만들자"는 생각으로 분리 작업을 미룸.
• Priority: [Low] (수정이 어렵지 않음. 반복되는 값이 3회 이상 등장할 때 추출해도 늦지 않음.)

7. [Frontend/Arch] 아키텍처 부재

• Status: 명확한 프론트엔드 아키텍처 정의 없이 개발 진행.
• Reason: 아키텍처 고민보다 기능 구현(MVP)에 집중함.
• Priority: [Low] (초기 단계에서는 과도한 아키텍처보다 기능 구현이 우선임. 자연스러운 현상.)

8. [Testing] 테스트 코드의 미도입

• Status : 현재 슬라이스 기반 개발에서 QC해야 할 부분들을 계획하고 사람이 직접 테스트 함
• Reason : 테스트를 도입하기 귀찮았음, 기능이 단순해서 사람이 직접 해도 괜찮을 정도라 생각함
• Priority : [Midum] 현재까진 휴먼 리소스를 추가해도 괜찮을 정도긴 하지만 기능이 복잡해질 수록 더 많은 시간과 토큰을 소모 할 수 있고 휴먼 에러가 발생 할 수 있음

엔지니어링 & 프로세스 분석 (Deep Dive)

진정한 수직 분할이였는가?

important

Verticla Slice 데이터베이스부터 UI부터 모든 계층을 관통하여, 사용자에게 실질적 가치를 제공하는 최소 단위의 기능을 의미한다.

• Q : End To End 처럼 DB - Server - Client가 모두 연결 되어 실제로 동작하는가?

  • A : 실제로 동작하나 API 비용 문제로 외부 LLM 파트는 동작하는지 테스트만 하고 목업 데이터로 변경, 다만 Slice의 범위가 너무 컸던거 같다고 생각함

• Q : 이 슬라이스만으로 사용자가 에디터를 이용한 영어 교정이란 핵심 가체를 체감 할 수 있는가?

  • A : 교정 요청 이후의 액션을 볼 수 있는 UI가 존재하지 아니하여 완전히 체감 할 순 없음, 하지만 네트워크 창을 통해서 데이터가 주고 받아짐은 알 수 있음

• Q : 지금 당장 배포해도 깨지지 않고 돌아가는가?

  • A : 동작은 함

• Q : 핵심 로직에 더미 데이터가 아닌 실제 로직이 적용 되었는가?

  • A : 원한다면 실제 로직을 적용 가능함

기술적 병목은 어디였는가?

important

개발 속도를 가장 크게 저하시킨 구간들을 선정한다.

1. 지속적인 기획 변경 , 특히 어떤 데이터 모델을 가지고 어떤 가치를 제공할 것인지

• 문제 상황 : 교정 관련되어 LLM 모델이 생성하기로 한 Output 에 대한 모델이 구현 초기와 구현 후기에 달라져 DB 모델링 및 DTO들이 지속적으로 변경되었음
• 근본 원인 : 기획 자체의 큰 그림이 확고하지 않았음. 큰 그림이 확실하지 아니하니 구현 단계마다 고민하고 매번 Local Solution 을 찾아냄, 그 Local Solution 을 Global Solution으로 적용하려 하니 이전 구현 조각들에 영향을 미침

2. 개발 문서 관리 방식에 대한 변경

• 문제 상황 : 에이전트를 활용하여 개발하기 위해 문서화의 중요성을 깨닫고 다양한 문서화 방식을 사용해봤음, 적절한 문서 방식을 찾기 위해 2번정도 방식을 변경함
• 근본 원인 : 초기 계획을 완벽하게 하지 않아 불필요하게 방법론적으로 수정하는 과정을 거침

3. 4Ls 회고 (Retrospective)

note

작성 가이드:

• Engineering: 코드, 아키텍처, 툴, 생산성 등 기술적 측면
• Self & Life: 감정, 건강, 수면, 집중력, 습관 등 개인적 측면

1. Liked (좋았던 점)

무엇이 나를 춤추게 했는가? (성취감, 올바른 선택)

• 💻 Engineering

  • 에디터 라이브러리 도입으로 많은 시간을 절약함 , 심지어 퀄리티도 좋음
  • 에이전트를 효과적으로 관리하기 위해 문서들을 이용한 iteration 기법, Slice 기법 등 다양한 기법을 도입했으며 직접 하드코딩 하던 시절보다 생산 효율성이 월등히 올라감
  • Slice 개발 방법론을 사용해 동작 가능한 첫 번째 기능을 완성함
  • 회고의 중요성을 깨닫고 회고를 자주 함, 성장 하는 기분이 듬

• 🧘‍♂️ Self & Life

  • 이른 아침 일어나 일상 생활과 작업의 밸런스를 맞출 수 있었음
  • 새벽마다 런닝을 시작했는데 개운함 (근데 2번해봄)
  • 취미로 시작한 요리로 스트레스도 관리되고 가정에서도 반응이 좋음

2. Learned (배운 점)

실패나 성공을 통해 무엇을 깨달았는가? (지식 습득)

• 💻 Engineering

  • 기획이 자주 변경 될 수록 코드 베이스는 꼬인다. 구현 전 기획을 탄탄하게 하자.
  • 개발 방법론적인 어떤 부분을 시행하기로 했다면 그 방법론 시행 전 후로 어땠는지 회고하도록 하자. 회고가 없다보니 불편함을 늦게 깨달았다.

• 🧘‍♂️ Self & Life

  • 주변에 아무도 없는 시간에 가자 집중이 잘 되고 주변에 사람이 있을 땐 집중이 잘 되지 않는다. 집중 할 수 있는 작업 시간을 완벽하게 잡아둬야겠다.

3. Lacked (부족했던 점)

무엇이 아쉬웠고, 무엇이 문제였는가? (반성)

• 💻 Engineering

  • 아무리 문서화가 중요하다고 해도 문서는 결국 썩는다. 진정하게 최신의 문서 형태를 유지 가능한건 코드이다. 현재 내 문서들중 이미 썩어버린 문서들도 존재한다.
  • 에이전트를 세심하게 관리하지 않으면 높은 생산성으로 인해 악취나는 코드들로 코드베이스가 범벅이 된다.
  • 테스트 코드를 만들어두지 않으니 에이전트의 코드들이 시한 폭탄처럼 느껴지고 불안하다.
  • 커밋 메시지를 단순 feat, hotfix .. 등등 일반적인 말머리만 붙혀두니 어떤 도메인 영역 (front,server,database .. etc) 에서 일어난 작업 사항인지 파악하기 힘들다.

• 🧘‍♂️ Self & Life

  • 에이전트가 구현을 하는 동안 남는 시간에 다른 짓을 하느라 집중력이 흐트러졌다.
  • 이른 아침 일어나긴 하지만 잠을 늦게 자 하루 수면 시간이 부족한 감이 있었다.
  • 밥을 너무 자주 먹어서 살이 쪘다.... 오마이갓

4. Longed for (바라는 점)

다음에는 무엇을 얻고 싶은가? (비전, 희망 사항)

• 💻 Engineering

  • 올바른 개발 컨벤션 생성 (슬라이스 정의 , 커밋 컨벤션)
  • 초기 기획이 그대로 유지 되어 매끄럽게 진행되는 하나의 Slice 작업 단위 실행
  • Slice 의 작업 사항들을 테스트 할 수 있는 테스트 문화 도입
  • 코드 구현 사항의 퀄리티를 높히기 위한 성실하고 많은 양의 instructions 도입

• 🧘‍♂️ Self & Life

  • 하루에 2시간 이상 운동에 투자 할 수 있도록 시간 여유를 내고 싶음
  • 하루 3끼 밥 차리는 시간을 포함하면 3시간정도 요리에 시간을 투자하는데 시간을 조절해야겠음

---

4. Action Item 도출 : 다음 슬라이스를 위한 전략

note

원칙: 너무 많은 것을 바꾸려 하지 마십시오. 가장 치명적인 1~2가지만 선택하여 확실하게 실행하십시오.
(추상적인 다짐 금지 ❌ -> 측정 가능한 행동 ⭕)

🛑 Stop Doing (그만하기)

생산성을 저해하거나 품질을 떨어뜨리는 나쁜 습관 즉시 중단.

• [Dev] 에이전트가 구현하는 과정에서 다른 짓을 하느라 집중력 떨어뜨리지 않기, 에이전트가 구현을 하는 동안 테스트 코드를 이해하거나 다음 진행 사항 예상하기
• [Life] 취미 (운동,요리)에 투자하는 시간이 하루에 너무 많음, 취미에 투자 가능한 시간을 하루에 제한 (하루 상한선 2.5시간 [운동 1.5시간, 요리 1시간])
• [Life] 수면 시간 지키기, 하루 최소 수면 시간 6시간 유지, 새벽 1시 이전 취침

🚀 Start Doing (시작하기)

다음 슬라이스부터 새롭게 시도할 구체적인 행동.

• [Dev]Slice 구현 기반에 대한 엄격한 컨벤션 및 개발 방법론 업그레이드 (DoD 수립, 도메인 영역 별 컨벤션, 에이전트의 기본 동작 등)

• [Dev] Slice 기반 구현 시 도메인 영역을 나타낼 수 있도록 커밋 컨벤션 수정 (ex : feat(server) : ... )

• [Dev]Slice 기반 구현에 대한 깃허브 관리법 생성

• [Dev] 문서화 최소화 하고 가장 최신의 문서를 유지 할 수 있도록 테스트 코드 자체가 문서가 되도록 테스팅 도입

• [Dev] 뽀모도로 작업 방식 재도입, 시간 타이머를 두고 하니 텐션감 있고 좋았음

• [Life] 식단 조절 (하루 3끼, 간식 덜 먹기)

✨ Keep Doing (유지하기)

이번 슬라이스에서 효과가 좋았던 행동 유지.

• [Dev] 비록 부족하지만 Slice 기법을 도입했던 것, 동작 가능한 기능을 하나 완성했다는 점
• [Life] 불렛 저널을 이용해 작게 나마 하루를 계획하고 리캡 가능했던 점
• [Dev,Life] 회고를 시작했던 점, 작업물 뿐 아니라 삶 또한 회고하고 성장 가능하다는 희망이 생김
• [Dev] 현재의 문서화 방식이 마음에 들진 않지만 문서화의 중요성에 대해 깨달았음
• [Dev] 현재의 에이전트 관리 방식이 마음에 들진 않지만 에이전트를 본격적으로 관리해봄으로서 원하는 결과물을 도출해냄