Vibe Engineer가 3개월 동안 만든 레포를 물려받았다. 내 커리어 사상 가장 만족스러운 PR을 작성했다.

새 회사에 입사해서 'Vibe Engineer'가 만든 백엔드 레포를 물려받았다. Claude를 사용해 일주일 만에 동일한 기능을 유지하면서 더 안정적인 아키텍처와 적절한 통합 테스트를 갖춘 코드로 재작성했다.

한마디로 제품에 실제로 필요한 것과는 거리가 먼, 비대해진 레포였다. 하지만 다들 그가 에이전트 접근 방식을 얼마나 고급스럽게 사용하는지 칭찬하고 있었다.

그는 수십 개의 스킬과 다양한 에이전트 역할을 사용하여 레포에서 일어나는 모든 일을 문서화하기 위해 복잡한 방법을 사용했다.
5천 줄이 넘는 코드가 담긴 파일이 수두룩했고, 아키텍처는 거의 없었으며, 무엇을 테스트하는지 알 수 없는 테스트 코드들만 가득했다.
또한 그는 아마 gstack 같은 변형 도구를 사용해서 프로젝트에 필요하지도 않은 기능을 빌드하는 루프를 돌리고 있었던 것 같다:

• 220개의 핸들러 중 실제로 사용되는 건 20개뿐이었다 (그중 5개는 기본적인 API 키 관리용이라 삭제 가능했다)
• 40개 이상의 시크릿 중 프로젝트 실행에 필요한 건 2개뿐이었다
• 309k 줄의 코드가 240k 줄의 문서로 덮여 있었다
• md 파일에 엄청난 양의 로그가 쌓여 있었다 (100만 줄 이상)

여기서 많은 사람들이 다양한 지식 베이스 관리에 투자하는 걸 보는데, 항상 궁금했다. 그게 실제로 얼마나 도움이 될까? 필요한 것만 작성하고 레포를 깔끔하게 유지하면, 고급 지식 베이스 관리의 혜택을 과연 누릴 수 있을까? 그리고 그게 도움이 되는지, 아니면 그냥 뭔가 많이 하고 있다는 느낌만 주는 건지 어떻게 알 수 있을까?

개인적으로 나는 여전히 몇 개의 Agents.md 파일을 사용하고 에이전트가 백로그에 접근할 수 있게 하지만, 그게 전부다. 그 외에는 기본적인 아키텍처 원칙과 주요 시나리오를 다루는 통합 테스트를 사용하며 좋은 엔지니어링 관행을 따르려고 노력할 뿐이다. 아, 그리고 나는 '미래를 위한' 비즈니스 로직은 만들지 않는다. 왜냐하면 경험상 그 미래가 닥쳐서 상상했던 대로 통합하려고 하면 절대 그렇게 되지 않아서 결국 다시 작성해야 한다는 걸 알기 때문이다.

솔직히 말해서, 그 코드 줄 중 상당수는 그의 '실험'이었을 것이다. 하지만 나는 우리가 처음부터 깔끔한 아키텍처에 투자한다면 그런 실험조차 반복하기 더 쉬워질 것이고, 실험이 끝난 후에도 레포를 안전하게 계속 유지할 수 있을 것이라고 생각한다.