[](https://www.nhncloud.com/kr)
## 들어가며
AI 코딩 에이전트에게 일을 시키면서, 저는 에이전트가 코드를 작성하는 과정을 계속 지켜보고 있었습니다. 파일이 수정되는 걸 보고, 빌드 로그를 확인하고, 에이전트의 판단이 맞는지 중간중간 개입했습니다. 병렬로 여러 작업을 돌리면 생산성이 올라갈 거라 기대했지만, 실제로는 에이전트 하나하나의 실행 과정을 따라가느라 개발자인 제가 병목이 되고 있었습니다.
여러 시행착오를 거치면서, 에이전트가 일하는 과정이 아니라 돌아오는 **산출물만 검토해도 충분하다**는 것을 깨닫게 됐습니다. 과정을 보던 시절에는 에이전트 3개를 동시에 돌리는 것이 한계였지만, 산출물만 보기 시작하자 그 이상도 감당할 수 있게 됐습니다. 다만 이 전환은 태도만 바꾼다고 되지 않았습니다. 산출물의 정의, 자동화된 테스트, 그리고 에이전트를 조율하는 운용 구조가 함께 있어야 했습니다. 이 글은 그 전환의 과정과 이를 뒷받침하는 구조를 공유합니다.
## 과정을 보면 과정에 개입하게 된다
에이전트에게 "주문 알림 기능을 만들어 줘"라고 시키고 나면, 자연스럽게 궁금해졌습니다. 지금 뭘 하고 있지? 방향이 맞나? 에이전트가 파일을 수정하는 모습이 보이면 더 참기 어려웠습니다. "저 파일이 아니라 이 파일을 수정해야 하는데" — 이런 생각이 드는 순간 이미 개입하고 있었습니다.
개입 자체가 나쁜 것은 아닙니다. 문제는 개입이 **스케일하지 않는다**는 점이었습니다. 에이전트 하나의 과정을 지켜보면서 개입하는 건 가능합니다. 하지만 에이전트가 셋, 다섯으로 늘어나면 이야기가 달라집니다. 병렬로 돌리겠다고 만들어 놓고, 정작 저는 하나씩 순차적으로 들여다보고 있었습니다. 과정을 보는 한 병렬은 불가능했습니다.
한 가지 더 불편한 사실을 깨달았습니다. 과정을 보면서 개입해도, 그것이 결과의 품질을 보장하지 않았습니다. 에이전트가 코드를 작성하는 중간 과정을 아무리 꼼꼼히 지켜봐도, 최종적으로 그 코드가 의도한 대로 동작하는지는 **실행해 봐야** 알 수 있었습니다. 중간 과정 관찰에 쏟은 시간이 결과 검증을 대체하지 못했습니다.
그렇다면 과정을 보지 않고도 결과를 신뢰할 수 있는 구조를 만들 수는 없을까? 이 질문이 이 글에서 공유하려는 것들의 출발점이었습니다.
## Artifact Driven Development
이 경험에 이름을 붙이자면, Artifact Driven Development — AI 에이전트의 실행 **과정** 대신, 에이전트가 만들어 낸 **산출물**을 보고 판단하는 개발 방식입니다. 제가 검토하게 된 산출물은 세 가지였습니다.
* **Plan**: 구현 전에 "무엇을, 어떻게, 어떤 파일을 수정해서" 만들 것인지를 정리한 문서입니다. Plan을 읽고 방향이 맞는지 판단합니다. Plan이 승인되면 에이전트는 그 범위 안에서 구현을 진행합니다.
* **Test Case 결과**: 구현이 끝난 후 — 혹은 구현과 동시에 — 에이전트가 미리 정의된 테스트를 실행한 결과입니다. 중간 수정 과정을 추적하는 것보다, 사전에 정의된 TC를 통과했는지가 훨씬 나은 판단 기준이었습니다.
* **Code**: 최종 코드 변경입니다. Plan의 범위 안에서, TC를 통과한 코드. diff를 리뷰합니다.
세 산출물은 각각 다른 질문에 답합니다. Plan은 "무엇을 만들 것인가", Test Case는 "무엇을 만족해야 완료인가", Code는 "실제로 무엇이 바뀌었는가". 이 세 가지는 자연스럽게 파이프라인을 이루었습니다.
제