에이전트 기반 코딩 실험 회고

2025년 4월부터 2025년 8월 사이에 짬을 내서 에이전트 기반 코딩에 대한 이런저런 실험을 해봤는데, 지금쯤(2025년 8월 19일) 회고를 한 번 하면 좋을 것 같아서 돌아보며 정리를 해봤다.

첫번째 실험

2025년 4월 12일, 첫번째 실험에서는 두 가지 아이디어를 시도해봤다.

1. 컨텍스트 유지를 위해 PLAN.md라는 파일을 만들고 여기에 할일과 진행 상황을 기록
2. 계획 에이전트, 구현 에이전트, 리팩토링 에이전트를 분리하여 별개의 지시(instruction)를 주고, 단계에 따라 적합한 에이전트와 협업

구현 에이전트가 TDD를 하도록 유도해봤는데 좀처럼 잘 따라하지 못했던 점이 아쉬웠다. 아마 인터넷에 TDD를 잘못 설명하는 글이 제대로 설명하는 글보다 월등히 많은 점, TDD의 중요한 실천 방법들이 대체로 암묵지 형태인 점 등과 관련이 있어 보인다.

두번째 실험

John Ousterhout 애자일 디자인 및 테스트 주도 개발 비판하는 한 유튜브 대담을 보고 이런저런 생각을 하던 중, 불현듯 내가 지금까지 공부했던 소프트웨어 공학(애자일 방법론 포함)이 AI 시대와 맞지 않는다는 생각에 이르게 됐다. 소프트웨어 공학은 1) 소프트웨어 개발은 인간이 하는데, 2) 인력과 시간은 비싼 자원이고, 3) 인간의 지적 활동에는 여러 특수성이 있다는 점을 명시적/암묵적으로 전제하고 있는데, 이런 전제가 더이상 성립하지 않게 되었기 때문이다. (참고: AI 시대의 소프트웨어 공학)

이런 생각을 품고 첫번째 실험을 돌이켜보니 인간이 하던 좋은 실천법을 AI가 그대로 흉내내도록 하려는 시도(예: AI에게 TDD 시키려고 노력하기)로 보였다.

2025년 4월 25일에는 두번째 실험에서는 (그동안은 지양해왔던) 과도한 선행 설계를 하고 전통적인 무거운 방법론(big-M methodologies)에서 말하는 추적가능성(traceability) 개념을 도입하는 시도를 해봤다. 거의 아무 형식도 없었던 PLAN.md를 보강하여 BPRD(Business and Product Requirements Document)라는 이름의 절반쯤 형식화된 문서(yaml 형태)를 고안했다. 미션과 비전에서부터 비즈니스 목표, 기능 목록, 인수 테스트 명세가 구조적으로 연결하는 문서다. 그리고 이 문서의 내적 일관성이 성립하는지 분석하는 간단한 CLI 도구를 만들어서 에이전트를 도와주도록 했다.

세번째 실험

이런저런 일들로 바빠서 한참 방치하다가 7월부터 다시 조금씩 실험을 해보기 시작했다. 세번째 실험에서는 두번째 실험을 더 확장하고 다듬었다.

두번째 실험의 BPRD는 “요구사항 문서”라는 뜻을 포함하는데 이건 너무 협소하다는 느낌이 들었다. 필요한건 요구사항 문서가 아니라 소프트웨어 프로젝트 전반에 대한 주요 정보를 담고 있는 명세서여야 한다. 이름을 s4 (semi-structured software specification)로 바꾸고 문서 형식 및 CLI를 개선했다.

8월 초부터는 s4를 이용하여 s4를 개발하는 소위 개밥 먹기가 가능해졌다.

내가 하려는 일이 뭔지 생각을 정리하던 중, 상태없는 AI-인간 인터랙션이라는 개념을 고안하고 이를 s4에 반영했다. 덕분에 한 세션에 끝내기 어려운 큰 작업을 여러 세션에 걸쳐 코딩 에이전트에게 위임하기가 수월해졌고, AI 에이전트를 위한 테스크 큐 같은 것도 쉽게 만들 수 있게 됐다.

부산물

• 상태없는 AI-인간 인터랙션
• AI 에이전트를 위한 테스크 큐

생각 조각들

• 내가 잘 아는 분야일수록(예: 소프트웨어 공학) 밑바닥부터 다시 생각하는 게 참 어렵다는 걸 느꼈다. 참고: 검색어를 입력하면 한 달 뒤에 결과가 나오는 세상
• 명세서를 LLM에게 입력하여 얻어낸 코드에 대한 신뢰도와 코드를 컴파일러에게 입력하여 얻어낸 바이너리에 대한 신뢰도 사이에는 아직 큰 차이가 있다. 이 간극을 완전 제거할 수는 없고(그게 바람직하지도 않고), 좀 더 좁힐 필요는 있겠다. 그러기 위해서는 아마도 자연어로 작성된 명세서의 한계를 벗어나는 게 필요하겠다.