Action Item Review: Iteration 1 Hardening
1. Overview (개요)
이 문서는 첫 번째 이터레이션 종료 후 식별된 기술적 부채(Technical Debt) 및 프로세스 비효율을 해결하기 위해 수행한 액션 아이템의 결과를 리뷰한다.
수행된 작업들이 기존의 문제점(Pain Point)을 명확히 해결했는지 검증하고, 향후 개발 속도에 기여할 수 있는지 평가한다.
저번 이터레이션에 대한 리뷰 : [InklignMe : Slice-1 : Recap] 조그만 기능 대비 쓸데없이 복잡한 엔지니어링 과정을 거쳤던 과정 회고
2. Review by Action Items (항목별 상세 리뷰)
2.1 세부적인 Instructions 생성
- 소요 시간 : 2H
- 기존 문제 : 이전 단계에선 instructions 들이 부실하여 결과물이 만족스럽지 못했고 좋은 결과물을 위해 매번 동일한 프롬프트를 작성해야하는 리소스 투입이 있었음. 또한 일관되지 않은 프롬프팅으로 인해 안정성이 보장되지 아니함
- 관련 작업 : Agent 를 다루기 위한 instructions 들을 항목 별로 세세하게 생성함
생성된 instructions들
모든 지침사항들은AGENT_WORKFLOL.instructions.md문서 파일에서 간략하게 소개 된 후 인덱싱 되어 에이전트에게 전송됨 - 검증 결과 : Agent 는 작업 시 적용되어야 하는 모든 instructions 들을 지침으로 삼은 후 작업함
- 평가 : Agent가 모든 instructions 들을 읽는데 소요되는 시간이 2초 남짓밖에 소요되지 않지만 작업의 결과물이 좋아져 만족스러움
2.2 깃허브 MCP 에이전트 생성
- 소요 시간 : 8H
- 기존 문제 : 매번 깃허브 이슈나 PR 을 생성 할 때 마다 작업 사항들을 옮겨 적는 것이 피로했으며 코드 베이스에 존재하는 문서화 깃허브에 존재하는 문서간의 정합성이 맞지 않는 경우가 존재했음
- 관련 작업 : 깃허브 MCP를 이용한 코파일럿 서브 에이전트를 생성함. 해당 에이전트는 IDE에서 에이전트로 생성한 작업 요구 사항(Slice)를 토대로 이슈 생성뿐 아니라 PR템플릿을 통한 PR생성, 코드리뷰 등의 일을 함
- 검증 결과 :
IDE에서 생성된 문서파일은 깃허브 이슈에도 실시간으로 업데이트 된다.
해당 작업 내용과 관련된 부분이 PR템플릿에 맞춰 PR에 생성된다.
- 평가 : 평소 문서들이 노션, 로컬 IDE, 깃허브 셋으로 분산되어 있었어서 관리하기 어려웠는데 이번 작업을 통해 모든 문서들은 로컬 IDE와 로컬 IDE를 추적하는 깃허브만 둠으로서 복잡성이 떨어짐, 다만 MCP 활용 방식에 대해서 익숙치 않아 소요 시간이 너무 오래 걸렸음.
2.3 테스트 코드 구현
- 소요 시간 : 1H (테스트 코드 지침사항 생성) + 1H (테스트 코드 생성)
- 기존 문제 :
- 기존 방식은 직접 스크립트를 실행하거나 인력을 동반하여 테스트해야 하여 시간이 많이 소모 되었음
- 이후 있을 액션 아이템에서 폴더 구조를 변경하는 등 변경 전 회귀 테스트 코드의 필요성이 화두됨
- 관련 작업 :
- Test Code Instructions 생성
- UI 테스트를 제외한 모든 파일 테스트 코드 생성
- 검증 결과 :
-
평가 :
2.4. Feature Slice 기반 폴더 구조 재설계
- 소요 시간 : 1H
- 기존 문제 :
- 기존 폴더 구조는
client(클라이언트로직) , server (서버로직), shared (공통 모듈)처럼 영역 별로 나뉘어져 있었음 - 내 작업의 동작 방식은 한 기능 (feature) 을 기반으로 하여
client ,server, shared로직을 모두 하나의 작업 단위(slice) 에서 처리하는 방식임 - 기존 폴더 구조는 작업 내역들을 올바르게 모으지 못하고 나누게 됨
- 기존 폴더 구조는
- 관련 작업 :
- 폴더 구조를 단순히
app (실제 동작하는 모듈) , feature (작업단위) , shared (공통 모듈)로 나눔 feature에선 해당 기능과 관련된 모든 기능들이 들어가있음
 + 1H (기존 코드 베이스 클린업)
- 기존 문제 :
- 기존
eslint , prettier두 개 모두 서로 다른 패키지로 관리 한 채로 프로덕트에서 두 개의 패키지를 섞어 사용했음. - 이 과정에서 두 개의 설정이 충돌하여 실제 코드 베이스에선 eslint , prettier 가 제대로 동작하지 아니했음
- 기존
- 관련 작업 :
- eslint ,prettier 통합 패키지 생성
- 통합 패키지를 앱에서 불러와 사용
- 검증 결과 :
- 모든 코드 베이스에 eslint, prettier 가 적절히 사용됨
- 평가 :
- 거의 마지막 작업이라 그런지 집중력이 떨어져 Agent 한테 일을 맡겨두고 다른일을 하느라 세 시간이나 소모했음
- 제대로 내가 겪고 있는 문제들을 정의한 후 일을 맡겼다면 설정은 30분이면 끝났을 거임
3. Retrospective (회고)
4.1. Liked (좋았던 점)
- Agent 를 다루는 Instructions 파트들을 튜닝하면 할 수록 작업의 속도와 퀄리티가 올라감을 느꼈음
- 액션 과정에서 문제를 정의하고 쪼갠 후 해결하는 방식들에 대해서 더 익숙해질 수 있었음
- 지금의 첫 번째 액션이 다음 이터레이션에 도움이 분명히 될 것이란걸 느꼈기에뿌듯함
4.2. Lacked (아쉬운 점)
- 생각했던 것 보다 시간이 많이 소모되었음, 일수로 치면 3일정도 투자한 거 같은데 Agent 한테 일을 대충 맡겨두고 소모한 시간이 많은 거 같아서 아쉬움
- 여전히 지금의 액션이 완벽하진 않음. 고치고 싶은점이 많지만 시간이 많이 소모되었기에 이정도로 만족하고 넘어가도록 함
4.3. Lessons Learned (배운 점)
- 초기 계획의 중요성 : 뭐든지 작업 하기 전 어떤 일이 일어날지 계획을 철저히 해야겠음. Agent 로 인해 작업 시간이 줄어든 것은 맞지만 초기 계획이 잘못되게 되면 Agent에게 투입한 토큰과 시간을 모두 날려버리고 처음부터 작업해야 하는 경우가 있음. 가장 최악의 경우를 피하기 위해 초기 계획을 제대로 잡고 문제를 Breakdown 해야겠음