개발 자동화를 그만두고, 다시 개발의 재미로 돌아온 이유

자동화를 그만둔 것이 아닙니다. 하나의 그래프에 개발 전체를 맡기는 방식을 그만뒀습니다.

한동안 저는 하네스와 그래프, 여러 에이전트를 연결해 개발 루프를 만들고 있었습니다. 프로젝트 이름은 Drig였습니다. 처음의 생각은 합리적이었습니다. 개발을 기획·인터뷰·구현·리뷰·배포 단계로 나누고, 각 에이전트에 역할과 책임 범위를 부여한 뒤, 그래프로 반복 가능한 흐름을 만들면 더 안정적으로 개발할 수 있다고 봤습니다.

여기에는 실제 걱정이 있었습니다. 코딩 에이전트는 맥락을 잃거나 검사를 건너뛸 수 있고, 나중에 이유를 복원하기 어려운 판단을 내릴 수도 있습니다. 구조화된 하네스는 개발 과정을 보이게 하고 반복 가능하게 만드는 방법처럼 보였습니다. 코딩이 중요하지 않아서 자동화하려던 것은 아닙니다. 오히려 개발 품질을 지키려고 과정을 더 엄격하게 만들고 싶었습니다.

작은 코드 작업을 둘러싼 복잡한 워크플로 튜브와 체크리스트, 타이머, 에이전트 노드

단계를 늘릴수록 작업을 시스템 안에서 이동시키는 데 더 많은 노력이 필요해졌습니다.

처음에 기대했던 자동화의 대가

다이어그램 위의 약속은 단순했습니다.

단계	기대한 효과	함께 생긴 숨은 비용
기획과 인터뷰	모호한 요구사항 줄이기	더 많은 맥락을 모으고 인계해야 함
구현	제한된 코딩 책임	경계를 설명하고 복구해야 하는 지점 증가
리뷰와 QA	독립적인 검증	artifact·시간·상태 전환 증가
배포와 closeout	반복 가능한 마지막 단계	유지해야 할 그래프 자체가 제품처럼 커짐

시간이 지나면서 시스템이 해결하려던 문제보다 커졌습니다. 전환 조건을 관리하고, 에이전트 책임을 설명하고, 자동화 예외를 복구하는 데 더 많은 시간을 썼습니다. 테스트가 실패하면 코드만 볼 수 없었습니다. 어느 단계가 결과를 만들었는지, 어떤 맥락이 handoff를 건넜는지, 다음 에이전트가 그 내용을 제대로 해석했는지까지 확인해야 했습니다.

비용은 한 번의 치명적인 버그로 나타나지 않았습니다. 단계가 추가될 때마다 토큰이 들었고, handoff가 생길 때마다 맥락이 줄거나 왜곡되거나 반복될 가능성이 생겼습니다. 복구 경로마다 설계와 테스트가 필요했습니다. 개발을 빠르게 만들려던 시스템에서 정작 제품보다 시스템을 더 많이 개발하고 있었습니다.

보이지 않는 과정도 문제였습니다. 자동화 안에서 많은 일이 일어나지만 무엇이 생성됐는지, 어떤 에이전트가 판단했는지, 왜 다음 단계가 선택됐는지가 항상 선명하지 않았습니다. 루프가 자동화될수록 저는 개발자보다 기계를 지켜보는 운영자에 가까워졌습니다.

다시 정한 경계는 엄격함을 버린 것이 아니었습니다

결국 Drig를 모든 개발 단계를 맡는 자동화 프로젝트로는 내려놓기로 했습니다. 에이전트나 테스트, 리뷰와 증거를 버린 것이 아닙니다. 직접 개발과 오케스트레이션이 만나는 경계를 다시 정한 것입니다.

당시 단순화 계획에서 정한 방향은 제품 구현을 Codex와 직접 진행하고, Drig에는 기획과 개발 후 검증·전달을 맡기는 것이었습니다. 이후 문서에는 체크포인트별 리뷰도 다시 포함됐습니다. 두 시점의 리뷰 범위는 다르지만, 제품 코드를 만드는 일과 완료 여부를 확인하는 경계를 나누려는 방향은 같습니다.

2026년 9월 5일 프로젝트 문서를 다시 확인해 아래 흐름으로 정리했습니다. 기획에서는 작게 끝낼 작업 범위와 통과 기준을 정합니다. 구현 중에는 체크포인트에 변경과 검증 근거를 남기고, 이후 리뷰와 QA가 그 결과를 확인합니다. QA를 통과한 변경만 PR로 보내며, 머지는 소유자의 명시적 결정으로 남겨둡니다.

Drig의 기획, Codex 직접 구현과 체크포인트, 리뷰, 제한된 QA 재시도, PR과 명시적 머지 및 종료 흐름

Drig 개념도

제가 실제로 사용할 수 있게 된 방식은 이렇습니다. 바꾸려는 것을 설명하고, 관련 저장소를 확인하고, 범위가 제한된 slice를 정한 뒤, Codex와 직접 구현하고 검사를 실행합니다. Drig는 그 바깥에서 계속 쓸모가 있습니다. 프로젝트 요청을 정리하고, acceptance criteria를 기록하고, checkpoint 증거를 보존하고, 마지막 QA와 배포 경계를 지키는 역할입니다.

직접 루프로 돌아오자 무엇을 하고 있는지 다시 보이기 시작했습니다. 어떤 질문에 답하고 있는지, 어떤 가정을 두었는지, 다음 명령이 왜 필요한지 알 수 있었습니다. 테스트가 실패해도 보이지 않는 에이전트 인계 체인을 먼저 복원하지 않고 실패 증거에서 코드까지 바로 따라갈 수 있었습니다.

그 과정에서 생각보다 그리웠던 것도 되찾았습니다. 바로 코딩의 재미입니다. 문제를 찾고, 한 줄을 바꾸고, 검사를 실행하고, 동작이 올바른 방향으로 움직이는 것을 확인하는 데는 고유한 만족감이 있습니다. 그 루프가 자동화 뒤에 가려지면 개발자는 통제력뿐 아니라 직접 만들고 있다는 감각도 잃게 됩니다.

실험에서 남긴 것

이번 경험이 그래프나 하네스가 나쁘다는 것을 증명한 것은 아닙니다. 오케스트레이션이 스스로 만드는 조정 비용을 감당할 만한지 먼저 물어야 한다는 기준을 남겼습니다.

독립된 권한, 반복 가능한 전환, 오래 남겨야 할 acceptance 기록, 구현 과정과 분리된 마지막 결정을 요구하는 작업이라면 별도 경계를 둡니다. 반대로 작은 수정에 process diagram의 빈 상자가 하나 있다는 이유로 에이전트를 추가하지는 않습니다. 작고 되돌릴 수 있는 변경이라면, 유능한 모델 하나와 눈에 보이는 검증 루프가 더 나은 하네스일 때가 많습니다.

문서를 다시 읽으며 눈여겨본 것은 재시도에도 끝이 있다는 점입니다. 첫 QA가 실패하면 소유자가 수정하거나 멈추기로 결정합니다. 수정을 선택하면 한 번 더 QA를 받고, 두 번째 QA도 실패하면 그 시도는 닫습니다. 머지 뒤 종료 처리는 리뷰와 QA를 처음부터 반복하지 않습니다. 모델이 판단할 단계와 시스템이 이미 끝난 일을 기록할 단계를 구분한 것입니다.

안정적인 입력이 명확한 단계를 지나 예측 가능한 결과로 이어지는 정돈된 업무 흐름