AI 에이전트에게 백엔드 개발을 맡기며 배운 것 — 세 개의 루프

“AI가 알아서 개발했다”가 아니라, 일을 맡기고 · 점검하고 · 피드백을 다시 넣는 반복 구조를 만든 이야기

최근 백엔드 개발 프로젝트 하나를 에이전트 중심으로 운영해 봤습니다. 개발 지시는 Jira에만 남기고, 자동화가 10분 간격으로 Jira 변경분을 감시해 실행 후보를 골라내고, 실제 구현은 별도 에이전트 세션이 맡는 방식입니다.

결론부터 말하면, 이 방식은 “AI에게 한 번에 크게 맡기면 알아서 다 해준다”와는 거리가 멉니다. 오히려 핵심은 작은 루프를 여러 개 만들고, 그 루프를 계속 고치는 것이었습니다. 이 글에서는 그 구조를 세 개의 제품 개발 루프 관점으로 정리합니다.

• Agentic Coding Loop: 에이전트가 spec과 검증 기준을 보고 코딩하는 루프
• Developer Feedback Loop: 개발자가 자동화 결과를 보고 방향과 규칙을 조정하는 루프
• External Feedback Loop: QA와 운영 검증 결과가 다시 개발 방향으로 들어오는 루프

먼저, 용어 몇 개

용어	쉽게 말하면
heartbeat	10분마다 Jira 변경 사항을 확인하는 자동 점검
manager	작업을 나눠 주고 결과를 검증하는 관리 세션
worker	실제 구현을 맡은 에이전트 세션 — 한 번에 이슈 하나만
closeout	”진짜 끝났는지” 배포·검증·기록까지 확인하는 마지막 절차
traceability	코드·문서·요구사항이 서로 맞는지 확인하는 정합성 검증

루프 1 — 에이전트가 일하는 방식 (Agentic Coding Loop)

첫 번째 루프는 에이전트와 spec/eval 사이의 루프입니다. 이번 프로젝트에서는 이렇게 대응시켰습니다.

• coding agent: 이슈별 worker 세션
• spec: Jira 이슈의 설명·최신 댓글·상태·담당자, 그리고 저장소의 공식 문서(API 명세, 설계 기록)
• eval: 테스트, traceability 검증, 배포 후 smoke/health/로그 확인

중요한 것은 작업 지시를 채팅에 흩어두지 않았다는 점입니다. 지시는 Jira 이슈에만 남겼고, 에이전트는 작업 전에 Jira 최신 상태를 다시 읽고 저장소의 문서와 비교한 뒤 실행 여부를 판단했습니다. worker는 단일 이슈만 맡아 구현 → 테스트 → 문서 갱신을 반복했고, manager는 worker의 “끝났다”는 주장을 그대로 믿지 않고 closeout 기준으로 재검증했습니다.

이 루프의 본질은 “에이전트에게 일을 시킨다”가 아니라, 에이전트가 따라야 할 spec과 채점 기준을 시스템(Jira와 저장소) 안에 계속 남기는 것입니다.

루프 2 — 사람이 규칙을 고치는 방식 (Developer Feedback Loop)

두 번째 루프의 실행 장치는 10분 단위 heartbeat였습니다. heartbeat는 매번 전체를 다시 훑지 않고 Jira 변경분(delta)만 확인해, 영향을 받는 범위만 제한적으로 재조회했습니다.

여기서 중요한 점은 heartbeat 지침이 고정된 cron 명령이 아니었다는 것입니다. 매 루프에서 나온 문제를 회고하고, 다음 지침에 바로 반영했습니다. 실제로 이런 식이었습니다.

• 처리 결과와 잔여 목록이 너무 길어지면 → 담당자 기준으로 출력 범위를 줄였습니다.
• 하위 에이전트가 너무 많이 생기면 → 꼭 필요한 조회만 남기고 worker 생성을 제한했습니다.
• 같은 이슈에 worker가 중복 생성될 위험이 보이면 → 시작 전 중복 확인(기존 세션·worktree·브랜치)을 필수 조건으로 올렸습니다.
• worker가 완료를 주장해도 → 배포 후 검증과 Jira 기록이 없으면 closeout하지 않도록 조건을 강화했습니다.

이 방식의 핵심은 자동화 prompt 자체를 운영 산출물처럼 다룬 것입니다. 한 번 만든 자동화를 그대로 두지 않고, 실제 루프에서 생긴 실패와 과잉 동작을 다음 지침에 흡수했습니다. 자동화 지침도 코드처럼 개선 대상입니다.

루프 3 — 외부 신호를 다시 개발로 (External Feedback Loop)

세 번째 루프는 QA·운영 검증 신호가 다시 개발 판단으로 돌아오는 루프입니다. 이번 프로젝트에서 외부 피드백에 해당한 것은 QA 이슈, Jira 최신 댓글, 배포 후 smoke/health 결과, 로그 마스킹 검증, Slack 완료 보고였습니다.

한 가지 운영상 선택을 공유하면, QA는 개발 이슈와 섞지 않고 별도 이슈로 분리해 추적했습니다. 개발 이슈는 배포 후 검증과 기록까지 마치면 QA 대기 없이 종료하고, QA에서 발견된 문제는 새로운 입력 — 원인분석 후보나 후속 이슈 — 으로 되돌렸습니다. 개발 이슈의 완료 조건에 외부 확인을 섞어두면 이슈가 계속 열려 있는 상태로 늘어지는데, 분리하고 나니 각 이슈의 Done 판정이 훨씬 또렷해졌습니다.

솔직히 말하면 이번 프로젝트의 외부 루프는 실사용자 피드백까지 간 것은 아니고, QA·운영 검증 중심의 초기 형태였습니다. 그래도 에이전트 코딩 루프가 “혼자 닫히지 않도록” 외부 신호를 다시 넣는 통로를 만들어 둔 것이 중요했다고 봅니다.

가장 유효했던 것: 이슈를 잘게 나누기

운영 원칙을 여럿 지켰지만 — Jira를 유일한 작업 입력으로, manager와 worker 분리, 중복 worker 방지, closeout은 운영 완료 기준으로 — 돌아보면 가장 유효했던 것은 따로 있습니다.

이슈를 “명확하게 Done 처리할 수 있는 단위”로 잘게 나눈 것.

완료 판정이 또렷한 이슈는 모든 것을 쉽게 만듭니다. 에이전트는 무엇을 하면 끝인지 알고, manager는 무엇을 검증하면 되는지 알고, 사람은 결과 목록만 봐도 진행 상황을 판단할 수 있습니다. 반대로 완료 기준이 흐릿한 큰 이슈는 worker가 “끝났다”고 주장해도 그 주장을 검증할 방법이 없고, 루프 전체가 흔들립니다.

QA를 별도 이슈로 분리한 것도 같은 원칙의 연장입니다. 하나의 이슈에 “구현 + 배포 + QA 확인”을 다 담으면 Done 판정이 외부 일정에 묶이지만, 분리하면 각각이 독립적으로 닫힙니다.

작게 시작해 보기

처음부터 백엔드 개발 전체에 적용할 필요는 없습니다. 문구 수정 이슈 하나로도 세 루프를 전부 연습할 수 있습니다.

1. Jira 이슈 작성 — 할 일과 확인 방법을 같이 적는다
2. 에이전트가 수정 — 관련 파일을 찾아 최소 범위로 고친다
3. 테스트·확인 — 검증 결과를 요약해 보고한다
4. 사람이 지침 보정 — 마음에 안 든 점을 다음 지침에 반영한다
5. QA 이슈 분리 — 확인이 필요한 항목은 별도 이슈로 추적한다
6. 기록 후 완료 — Jira에 결과를 남기고 닫는다

첫 결과가 마음에 들지 않으면 그 피드백을 다음 지침에 반영하는 것 — “다음부터는 담당자가 아닌 이슈는 결과에서 빼라”, “문서만 바꾼 작업은 배포 완료처럼 쓰지 마라” — 이 두 번째 루프의 시작입니다.

특정 도구에 묶이지 않습니다

이 방식은 특정 코딩 에이전트 전용이 아닙니다. 핵심은 도구가 아니라 역할 분리와 반복 규칙입니다. manager/worker 세션 분리는 별도 스레드로도, worktree와 tmux로도 구현할 수 있습니다. 다만 어떤 도구를 쓰든 최소한 이 규칙은 필요합니다.

• 이슈 key를 브랜치·커밋·worker 세션의 공통 식별자로 쓴다.
• worker에게는 한 번에 이슈 하나만 맡긴다.
• worker의 완료 주장은 manager가 별도로 재확인한다.
• 완료 기준은 “코드 완료”가 아니라 “배포 후 검증 + 기록 완료”로 정의한다.
• 토큰·좌표·원문 로그 같은 민감 정보는 문서와 보고에 남기지 않는다.

마치며

이번 운영에서 배운 것을 한 줄로 줄이면 이렇습니다.

한 번에 크게 맡기지 말고, 작은 루프를 만들어 계속 고치세요.

에이전트가 아무리 빠르게 코딩해도, 개발자가 자동화 지침을 계속 조정하지 않고 QA·운영 검증 신호가 다시 개발 판단으로 돌아오지 않으면 같은 실수를 반복합니다. 그리고 그 모든 루프의 품질은 결국 입력의 품질 — 명확하게 Done 처리할 수 있는 단위로 나뉜 이슈 — 에서 시작합니다.