코딩 에이전트에게 버그 수정을 요청하고, 생성된 PR(Pull Request)을 리뷰하는 등의 개발 프로세스는 일반화되었지만, 이는 Human-in-the-Loop (HITL)라고 불리는 것으로 보입니다. (처음 등장한 것은 다른 분야에서 오래전의 용어인 것 같습니다.)
본 기사에서는 소프트웨어 개발에서의 HITL을 에이전트에게 맡기는 공정 범위에 따라 분류합니다. 공개된 사례 조사를 정리했으며, 계획이나 우선순위 결정까지 맡길 경우의 목표 설정과 인간에게 남겨둘 판단에 대한 고찰 메모를 남겼습니다.
제품 및 구현 설명은 2026년 11월 1일에 확인한 공개 자료를 기반으로 합니다.
개발 프로세스에서의 HITL
본 기사에서는 HITL을 에이전트가 진행하는 개발 공정 속에서 인간이 판단이나 수정을 가하는 메커니즘으로 다룹니다. 대상은 소프트웨어를 개발하는 과정입니다. 개발된 AI 애플리케이션의 답변을 인간이 확인하는 것과 같은 실행 시점의 메커니즘은 다루지 않습니다.
예를 들어, 버그 수정이라면 다음과 같은 흐름을 생각해 볼 수 있습니다.
- 인간이 버그 상황을 전달한다.
- 에이전트가 코드를 조사하고 수정하여 테스트한다.
- 인간이 수정 내용을 확인하고 필요하다면 수정을 요청한다.
- 에이전트가 다시 수정하고, 인간이 채택 여부를 판단한다.
이 흐름에서는 인간이 작업의 시작과 수정 내용의 채택을 담당합니다. 작업의 시작은 자동화하고, 수정의 채택만 인간이 판단하는 구성도 생각해 볼 수 있습니다.
아래에서 인간과 에이전트의 분담을 다음 4개 항목으로 확인하겠습니다.
| 항목 | 판단 및 작업 내용 |
|---|
| 시작 | 작업을 언제부터 시작할지 |
| ... | |
본 기사에서의 HITL 분류
에이전트에게 맡기는 범위를 L1부터 L4까지 분류합니다. 이는 본 기사만의 독자적인 분류이며, 업계 표준이나 조직의 성숙도를 나타내는 것은 아닙니다.
| 레벨 | 맡기는 범위 | 에이전트가 담당하는 작업 |
|---|---|
| L1 | 하나의 Issue 또는 백로그 내 1개 태스크 | 인간이 지정한 변경 사항 구현 및 검증 |
| ... | |
분류 대상은 구체적인 사용 사례입니다. 같은 제품이라도, 수동으로 개별 수정 요청을 하는 경우와 미처리된 Issue를 모니터링하게 하는 경우는 분류가 달라집니다.
L1은 하나의 Issue 또는 백로그 내 1개 태스크를 맡기는 방식이며, L3은 인간이 사전에 계획한 스프린트를 통째로 맡기는 방식입니다. L3에서는 구현 상세나 태스크 간의 조정을 에이전트가 담당하고, 인간은 스프린트 전체의 성과를 확인합니다.
본 기사에서는 여러 스프린트를 통해 달성하고자 하는 것을 '제품 목표(Product Goal)'라 부르고, 이번 스프린트에서 달성하고자 하는 것을 '개발 목표(Development Goal)'라고 부릅니다. Scrum 외에서도 이와 상응하는 단위로 개발을 맡기는 경우에는 동일하게 분류합니다.
또한, L4를 단순한 주기적 실행과는 구분합니다. 이전 결과를 평가하고 다음 개발 목표나 우선순위를 업데이트할 때까지 맡기는 것이 본 기사에서 말하는 L4입니다. 인간이 결정한 제품 목표나 제약 범위 내에서 이루어집니다. 평가에는 테스트 결과나 미해결 과제도 사용될 수 있습니다. 사용자에게 미치는 효과를 목표로 할 경우에는 이용 현황 등의 관측도 필요합니다.
인간의 승인 횟수는 이 분류와 별개로 생각해야 합니다. L4에서도 계획이나 릴리스에 대한 승인을 인간에게 남겨둘 수 있으며, L1에서도 제한된 변경 사항의 승인을 자동화하는 경우가 있습니다.
L1, L2 활용 예시
Anthropic 내부 활용 사례
Anthropic이 2025년 7월에 공개한 기사에서는 Product Engineering 부서가 버그 상황을 Claude Code에게 전달하고 제안된 해결책을 리뷰하는 사용법을 소개했습니다. Security Engineering 부서에서는 가상 코드를 작성하게 하고, 테스트 주도 개발(Test-Driven Development)로 진행하면서 중간 점검을 하는 방법도 보고되었습니다.[1]
인간이 수정 대상이나 진행 방식을 지정하고 결과를 확인하고 있기 때문에, 본 기사에서는 이를 L1의 예시로 간주합니다.
Modal에서의 인시던트 조사
Cognition의 Auto-Triage 소개 기사에는 Modal의 추론 팀(Inference Team)이 Devin Automations을 이용한 댓글이 있습니다. 버그 보고를 모니터링하며, 인간이 개별적으로 프롬프트를 입력하지 않아도 인시던트 조사를 시작하는 사용법입니다.[2]
이 예시에서는 조사 시작을 자동화하고 있기 때문에, L2에 해당한다고 생각합니다. 다만, 출처는 제품 제공 기업의 기사에 실린 담당자의 증언입니다. Modal에서 수정 사항의 승인이나 실제 반영(Production Deployment)을 어떻게 진행했는지, 지속적인 운영으로 어느 정도 효과가 있었는지는 이번 자료에서는 미확인입니다.
L1, L2 제품 사례
L1의 예시로 언급된 Claude Code에서는 사람이 개별적인 작업을 요청하는 사용 방식을 확인할 수 있었습니다. L2 제품 예시로는 Linear Loops가 있습니다.
Linear Loops는 이벤트나 스케줄에 따라 Linear 내 정보를 다루는 에이전트인 Linear Agent를 실행하는 기능입니다. 공식 기사에서는 버그 리포트 조사, 수정 방침이 명확할 경우의 코딩 세션 시작, 기능 요구사항으로부터 후속 Issue 생성, 계획 문서 업데이트 등을 소개하고 있습니다.[3]
Cursor Automations 역시 스케줄이나 외부 이벤트에 따라 클라우드 상에서 작동하는 Cloud Agents를 구동하는 기능을 제공합니다. 공식 문서를 통해서는 PR 리뷰나 Slack상의 버그 리포트 조사 등이 용도로 언급되었습니다.[4]
Linear Loops나 Cursor Automations 같은 도구를 사용하면, 사람이 매번 요청하지 않아도 사전에 지정한 작업을 시작할 수 있습니다.
L1, L2에서 인간에게 남는 작업
L2에서는 버그 리포트 조사나 작업 할당을 자동화할 수 있습니다. 그럼에도 불구하고, 어떤 사용자 문제를 우선순위로 둘지, 여러 변경 사항으로 해당 문제가 개선되었는지 여부, 다음에 무엇에 집중할지는 사람이 결정해야 하는 경우가 있습니다.
예를 들어, 문의 대응 개선을 생각해 봅시다. 보고된 버그를 순차적으로 수정하는 시스템이 있더라도, 문의가 많은 원인이 화면의 이해하기 어려움 때문인지, 기능 부족 때문인지는 별도로 조사해야 합니다. 어느 쪽에 대응하느냐에 따라 필요한 태스크도 달라집니다.
스프린트 단위로 맡기고 싶다면, 개별 Issue 완료 외에도 여러 변경 사항을 통합하고 스프린트 목표를 달성했는지 확인하는 과정이 필요합니다.
L3, L4 개발 플로우
L3에서는 사람이 사전에 스프린트의 목표와 다룰 내용을 결정합니다. 에이전트는 그 계획에 따라 구현과 검증을 진행하고, 스프린트 목표 달성 상황을 보고합니다. 인간은 검증 결과와 실제 작동 여부를 확인하여 성과를 채택할지 판단합니다.
L4에서는 평가한 결과를 다음 목표나 우선순위에도 반영합니다. 예를 들어, 특정 기능을 추가했음에도 사용자 문제가 개선되지 않았다면, 같은 방침으로 개발을 계속할지 아니면 다른 대응을 시도할지 재계획하게 됩니다.
아래는 특정 제품의 사양이 아니라 이 분류를 설명하기 위한 다이어그램입니다.
L3에서는 다음 스프린트 역시 사람이 계획합니다. 에이전트가 계획안을 만드는 경우라 하더라도, 시작 전에 인간의 승인이 필요합니다. L4에서는 평가 결과를 바탕으로 한 다음 계획 업데이트도 에이전트가 담당하며, 인간의 승인이 필요한 조건을 사전에 정해둡니다.
이번 목표를 달성하지 못했을 경우에는, 같은 스프린트 내에서 수정할지, 미완료된 작업을 다음 스프린트로 넘길지를 판단합니다. 계획 범위를 초과하는 변경은 사람에게 확인을 요청해야 합니다.
이 처리를 여러 실행에 걸쳐 계속하려면, 계획, 미완료 태스크, 평가 결과를 저장해야 합니다. 도중에 중단했을 때 재개할 수 있는 것, 실패를 반복했을 때 멈추는 조건 또한 개발 플로우와 함께 정해둡니다.
L3, L4 관련 구현 예시
아래에서는 여러 프로세스를 연결하는 설계 패턴, 스프린트를 운영하는 OSS, 그리고 개발자의 시도 기록을 소개합니다. 이들 모두 L3나 L4를 통한 장기적인 품질이나 비용 효율성을 입증하는 자료로 다루지는 않습니다.
GitHub Agentic Workflows
GitHub Agentic Workflows에는 여러 프로세스를 연결하는 설계 패턴이 공개되어 있습니다. ResearchPlanAssignOps는 조사, 계획, Issue 할당, 리뷰 및 병합을 연결한 예시입니다. 조사를 주기적으로 실행하고 그 결과를 읽은 사람이 계획 생성을 지시하는 등, 프로세스 사이에 인간의 판단을 남기고 있습니다.[5]
OrchestratorOps에서는 부모 워크플로우가 작업을 분할하고 실행 순서를 정하여 워커에게 위임합니다.[6] WorkQueueOps는 실행에 걸쳐 백로그를 처리하기 위한 패턴입니다. 네이티브한 Work Queue에서는 다음에 실행할 태스크를 선택하는 것이 스케줄러이며, 에이전트가 자유롭게 선택하는 구조는 아닙니다.[7]
이러한 것들을 사용하면, 계획 생성, 구현 위임, 미완료 태스크 관리를 여러 실행에 걸쳐 구성할 수 있습니다. 스프린트 목표 달성이나 그 이후의 목표 업데이트까지 할지는 조합하는 워크플로우에 따라 다릅니다.
Maul Team
Maul Team은 Claude Code를 사용하여 Scrum 형식의 개발을 진행하는 OSS입니다. 일반 모드에서는 인간이 Product Owner(PO) 역할을 담당합니다. Scrum Master 에이전트가 제안한 스프린트 목표를 인간이 승인한 후에 개발을 진행합니다. 에이전트가 테스트와 리뷰를 수행하고, 인간이 데모에서 기능을 확인하는 구성은 본 기사의 L3에 가까운 예시입니다.[8]
Autonomous Mode에서는 PO의 판단까지 에이전트에게 맡깁니다. 운영 문서에는 제품 개요를 전달하고, Claude Code 실행을 감시하는 별도의 프로그램(watchdog)이 새로운 세션을 시작하고 저장된 상태에서 개발을 지속하는 메커니즘이 기술되어 있습니다. 판단이나 개발 상태는 파일에 저장됩니다.[9]
README에는 코드 감사의 지적 사항을 PO가 판단하고, 채택한 것을 다음 스프린트의 백로그 항목으로 만드는 흐름도 설명되어 있습니다. 이 PO의 판단 역시 에이전트에게 맡긴다는 점에서, 평가 결과를 다음 계획에 반영하는 L4와 관련된 구현입니다.[8] 본 기사는 공개 문서를 참고했을 뿐이며, 실행 검증이나 장기적인 효과 확인은 하지 않았습니다.
ima-jin의 Autonomous Sprint Loop
ima-jin의 공개 Issue에는 PO 에이전트가 기능을 제안하고, 인간이 방침을 승인한 후에 구현 에이전트를 구동하는 설계가 있습니다. 이 설계에서는 구현 후에도 인간이 PR(Pull Request)을 승인하고, 다음 사이클을 스케줄러로 시작합니다.[10]
같은 Issue에는 첫 시도에서 PO 에이전트가 존재하지 않는 결함을 제안한 기록이 있습니다. 구현 측은 코드를 조사하여 문제가 없다고 판단하고, 수정 PR을 만들지 않았습니다. 이 경험으로부터 개발자들은 구현 전의 제안을 인간이 확인하는 과정을 중요하게 생각합니다.[10]
이 기록에서는 불필요한 수정이 구현 전에 멈추었습니다. 하지만, 제안을 그대로 구현하게 되면 코드 리뷰나 테스트만으로는 애초에 필요한 작업이었는지 확인하기 어려워집니다. 계획을 에이전트에게 맡길 때는, 구현의 품질 외에도 제안의 근거를 확인할 과정이 필요하다고 생각합니다.
L3, L4를 시도할 때 고려 사항
목표 및 평가 방법
태스크의 분해나 우선순위를 에이전트에게 맡길 경우, 태스크를 선택하는 기준도 전달해야 합니다. "문의 대응을 개선한다"라는 것만으로는 신규 기능을 추가할지, 기존 화면을 수정할지 판단하는 데 필요한 정보가 부족합니다.
다음 표는 목표를 구체화하기 위한 가상 예시입니다. 기간이나 수치를 포함하며, 특정 기업의 실적이나 권장치는 아닙니다.
| 항목 | 문의 대응을 개선할 경우의 예시 |
|---|
| 대상 | 초기 설정에서 어려움을 겪는 사용자 |
| ... | |
| 테스트에서는 사양대로 작동하는지 확인합니다. 이용자의 문제가 개선되었는지는 이용 상황이나 문의 내용으로부터 확인합니다. 문의 건수가 줄었더라도, 사용자 자체가 줄어들었다면 개선이라고 판단할 수 없으므로, 평가할 기간과 대상도 정해둡니다. 예시의 2주 동안 충분한 이용 건수를 얻지 못하면, 판단을 보류하고 관측 기간을 연장합니다. | |
L4에서는 이 결과를 다음 계획으로 전달합니다. 효과를 확인하기 위한 데이터가 아직 없다면, 추가 구현을 진행하는 것보다 관측을 기다리자는 판단도 필요합니다. 다음 태스크를 계속 생성하는 것을 계획 업데이트의 목적으로 삼지 않습니다.
인간에게 남기는 판단
인간이 확인하는 과정은 구현 후의 리뷰 외에도 배치할 수 있습니다. ima-jin의 예시라면, 만들 기능을 선택하는 단계에서 확인하고 있습니다. 인증 방식이나 저장 데이터를 변경하는 제안이라면, 구현에 들어가기 전에 담당자가 판단하는 것이 재작업을 줄일 수 있습니다.
승인이 필요한 조건은 변경의 영향에 따라 결정됩니다. Claude Code 팀의 실전 기사에서는 변경 위험도에 따라 승인하는 사람의 수를 조정하고 있습니다. 승인을 생략할 수 있는 저위험 변경에는, 작성자가 리포지토리의 신뢰 목록(trusted list)에 포함되는 등의 조건이 있습니다. 또한, CI 설정 파일 등에서는 인간의 확인을 필수로 합니다.[11]
이 예시를 그대로 채택할 필요는 없지만, 자체 개발이라면 예를 들어 다음과 같은 조건을 고려할 수 있습니다.
- 신규 기능이나 우선순위 변경은 구현 전에 PO가 확인한다.
- 인증, 과금, 저장 데이터 처리를 변경하는 경우는 담당자의 승인이 필요하다.
- 본 반영 판단자와 문제 발생 시 중단 담당자를 정한다.
- 계획에 없는 변경이 필요해진 경우, 그 이유와 영향을 인간에게 보고한다.
여기서 결정하는 것은 어떤 정보를 보고, 누가, 무엇을 승인할지입니다. 판단을 요구할 때는 제안 내용 외에도 근거, 변경의 영향, 대안도 확인할 수 있도록 합니다.
중단 조건 및 운영 재검토
지속적인 실행을 위해서는 종료 및 중단 조건도 필요합니다. 예를 들어, 실행 시간이나 비용 상한에 도달했을 경우, 동일 검증에서 반복적으로 실패했을 경우, 권한 범위를 벗어난 변경이 필요한 경우에는 인간의 확인을 기다리도록 합니다.
운영 후에는 인간 개입 횟수 외에도 재작업(hand-back), 결함(bug), 판단 대기 시간, 비용 등을 측정합니다. 승인 과정의 수고가 줄더라도 불필요한 기능이 늘어나거나 수정에 시간이 오래 걸린다면, 위임할 범위나 확인하는 공정을 재검토해야 합니다.
L4 단계에서는 어떤 평가 결과를 근거로 다음 목표나 우선순위를 결정했는지 운영 기록을 통해 추적할 수 있도록 합니다. 사용자 효과를 목표로 하는 경우라면, 구현이나 테스트 완료만으로 다음 개발 단계로 넘어가지 않았는지도 확인합니다.
요약 및 소감
본 기사에서는 개별 태스크를 위임하는 L1부터 평가 결과에 기반하여 계획 업데이트까지 위임하는 L4까지 HITL을 개발 공정의 범위에 따라 분류했습니다.
계획 수립까지 맡기려면, 달성해야 할 목표, 평가에 사용할 정보, 변경 가능한 범위를 미리 결정해 두어야 합니다. 인간이 확인하는 과정은 구현 후 리뷰에만 국한되지 않고, 기능 제안이나 우선순위 결정 시점에도 배치될 수 있습니다.
같은 프로젝트라도 결함 보고를 모니터링하여 자동 조사하는 작업은 L2, 인간이 계획한 스프린트를 일괄 위임하는 개발은 L3 등 활용 방안을 구분할 수 있습니다. 우선 맡기고 싶은 작업과 인간의 판단이 필요한 내용을 구체적으로 정하고, 실행 결과를 보면서 범위를 조정해 나가는 것이 좋다고 생각합니다.
이번 조사를 하게 된 계기는 애초에 'Human in the Loop'라는 용어 자체에 대한 이질감 때문이었습니다. 마치 사람이 루프를 돌리는 역할을 맡고 있는 것처럼 느껴져서, 아직 인간은 루프 밖에 존재하는 것 같다는 느낌을 받았고, 더 내부 파츠가 되고 싶다는 것이 동기였습니다(특히 제 회사의 백오피스 절차 같은 것은 아무래도 관성이 생겨서 무거워지기 때문에, AI가 루프를 돌려서 저에게 강제하는 역할을 해줬으면 좋겠다는 생각이 들었습니다).
결과적으로 비슷한 시도를 하는 사례들을 찾을 수 있었습니다. 다만, 이번에 확인한 자료만으로는 지속적인 실운영에 적용했을 때 얼마나 잘 작동할지는 미지수라는 인상을 받았습니다.
이에 대해서는 저도 시험적으로 돌려보고 분위기가 좋아진다면 다시 기사를 써서 보고드리려고 합니다.
포스터 뒷면
Astra가 칭찬받아서 대단하다
참고 자료
[1] Anthropic, How Anthropic teams use Claude Code, 2025년 7월 24일.
[2] Cognition, Introducing Auto-Triage, 2026년 5월 18일.
[3] Linear, Introducing Loops, 2026년 7월 20일.
[4] Cursor, Automations.
[5] GitHub Agentic Workflows, ResearchPlanAssignOps.
[6] GitHub Agentic Workflows, OrchestratorOps.
[7] GitHub Agentic Workflows, WorkQueueOps.
[8] sohei56, Maul Team.
[9] sohei56, Autonomous PO Mode.
[10] ima-jin, Autonomous sprint loop — Issue #1327, 2026년 7월 16일.
[11] Addy Osmani, Morgan Westlee Lunt, Qing Wang, How the Claude Code team does code review, 2026년 10월 15일.
토론
