Jira의 AI 에이전트를 위한 휴먼인더루프(Human-in-the-loop) 패턴

휴먼인더루프는 에이전트가 더 많은 빌드를 처리하는 경우 제어를 유지하는 방법으로, Jira에서는 별도의 도구가 아닌 워크플로 내에서 제공합니다. 실질적인 결과를 내는 팀은 주요 결정만 사람의 판단에 맡기고 나머지는 에이전트가 처리하도록 합니다.

그 판단이 이루어지는 자연스러운 곳이 있습니다. Jira는 팀이 항상 업무를 관리하고 진행할 사항을 승인해 온 곳이며, 이제 에이전트에게도 동일한 기능을 제공합니다. 이 가이드에서는 어느 시점에서 어떻게 사람이 AI 에이전트에 대한 제어를 유지하는지, 누가 어떤 작업을 소유하는지, 어떻게 규모에 맞게 감독을 설계하는지 알아봅니다. 간단히 말해, 휴먼인더루프를 제대로 구현하면 다음의 세 단계를 활용할 수 있습니다.

• 깔끔하게 실행 취소할 수 없는 작업을 제어하는 승인

• 제공 전에 품질이 낮거나 정렬이 잘못된 산출물을 찾아내는 검토

• 에이전트의 불확실한 판단을 사람에게 자동으로 라우팅하는 에스컬레이션

AI 에이전트를 위한 휴먼인더루프란 무엇입니까?

휴먼인더루프란 AI 에이전트가 정의된 체크포인트에서 일시 중지하여 중대한 작업을 진행하기 전에 사람이 업무를 승인하거나 수정하거나 방향을 전환할 수 있도록 하는 시스템 설계입니다. 에이전트는 일상적인 실행을 담당하고, 사람은 실제 결과를 초래하는 결정을 제어합니다.

이것은 안정성을 위한 아키텍처이며, AI가 실패했다는 신호도 아니고 모델이 충분히 발전하면 제거하는 임시방편도 아닙니다. 가장 좋은 에이전트 시스템은 결과를 바꾸는 바로 그 시점에 사람의 판단이 개입하는 시스템입니다.

실제로 휴먼인더루프는 일반적으로 다음 세 가지 패턴으로 나타납니다.

• 승인은 위험도가 높거나 되돌릴 수 없는 작업 전에 최종 승인을 받는 것입니다.

• 검토는 제공 전에 에이전트 산출물의 유효성을 검사하는 것입니다.

• 에스컬레이션은 불확실하거나 컨텍스트가 누락되었거나 범위를 벗어나는 경우 에이전트가 핸드오프하는 것입니다.

휴먼인더루프(Human-in-the-loop), 휴먼온더루프(Human-on-the-loop) 및 휴먼아웃오브더루프(Human-out-of-the-loop) 비교

세 가지 용어는 에이전트가 작업을 시작한 후 사람이 어느 정도의 제어를 유지하는지를 설명합니다. 차이점은 누가 실행하고 누가 결정하는지에 달려 있습니다.

목표는 모든 곳에서 최대한 감독하는 것도, 전혀 감독을 하지 않는 것도 아닙니다. 위험이 실제로 존재하는 곳에 적절한 모드를 적용하고 신뢰가 쌓일수록 업무의 자율성을 높이는 것입니다.

사람은 어떤 부분에서 AI 에이전트에 대한 제어를 유지합니까?

먼저 누가 어떤 작업을 소유하는지 결정

소유권이 체크포인트보다 먼저입니다. 사람이 어느 시점에서 검토하거나 승인할지 결정하기 전에 우선 에이전트가 어떤 작업을 소유할 수 있는지 결정하세요. 체크포인트는 그 결정을 적용할 뿐이며 대체하지는 않습니다.

업무를 분담하는 간단한 방법은 실수가 초래할 비용을 기준으로 나누는 것입니다.

• 에이전트가 소유. 에이전트가 핸드오프 없이 자체적으로 완료하고 종료할 수 있는 명확하게 지정된 업무입니다.

• 에이전트가 제안하고 사람이 결정. 에이전트가 초안을 작성하면 사람이 완료하거나 승인하거나 반려하는 업무입니다.

• 사람이 소유. 처음부터 사람이 판단을 내리고 에이전트는 결정하기보다는 지원합니다.

소유권은 누가 업무를 시작할지를 결정하며, 앞서 언급한 감독 모드는 업무가 진행된 후 누가 관찰할지를 결정합니다. Jira에서는 모든 에이전트 작업이 알려진 ID와 연결되며 업무 항목 기록에 남으므로 책임 소재는 기억이 아닌 기록에 근거합니다.

1. 승인: 영향력이 큰 업무를 진행하기 전 최종 승인

실행 취소가 어려운 작업에는 승인을 사용합니다. 프로덕션 변경, 삭제 및 비용이 발생하는 호출은 잘못하면 대가가 크기 때문에 모두 승인을 거쳐야 합니다. Jira에서 승인은 지정된 사용자가 최종 승인할 때까지 전환을 보류하는 워크플로 승인 단계이므로, 이 게이트는 누군가 기억해야 하는 미리 알림이 아니라 프로세스의 일부분입니다. 조건 및 유효성 검사기를 포함한 이 게이트의 전체 워크플로 규칙 메커니즘에 대한 자세한 내용은 Jira의 에이전트 기반 엔지니어링 가드레일 및 안전을 참조하세요.

• Jira: 에이전트가 프로덕션 구성 업데이트 또는 릴리스와 같이 영향도가 높은 변경 사항을 준비하는 경우, 지정된 승인자가 승인할 때까지 해당 업무 항목은 승인 상태를 벗어날 수 없습니다. 기본 승인 단계는 상태 전환을 승인 또는 거절이라는 두 가지 결과와 연결하며, 업무 항목에 대해 누가, 언제 결정했는지를 기록합니다.

2. 검토: 제공하기 전에 산출물 확인

기존 검사를 통해 확인하기 전까지는 에이전트 산출물을 신뢰할 수 없는 것으로 간주하세요. 코딩 에이전트의 경우 검토 과정은 일반적인 검토 및 병합 프로세스를 거치는 풀리퀘스트입니다.

제대로 된 검토란 단순히 결과뿐만 아니라 업무 전체를 살펴보는 것을 의미합니다. Jira의 추천 페이지의 에이전트 세션 보기에서는 에이전트가 수행한 작업 및 이유를 한곳에서 확인할 수 있으므로, 검토자는 컨텍스트를 다시 구성할 필요 없이 파악한 상태에서 시작할 수 있습니다.

• Jira:Jira 코딩 에이전트와 같은 코딩 에이전트에게 업무 항목을 할당하세요. 에이전트는 업무 항목과 연결된 컨텍스트를 읽은 후 업무 항목에 다시 연결된 초안 풀리퀘스트를 열고, 사용자가 이를 검토합니다. 일반적인 병합 프로세스를 통해 해당 풀리퀘스트를 검토합니다. Jira의 추천 페이지의 에이전트 세션 보기는 다음으로 필요한 작업에 따라 모든 세션을 그룹화하고 각 에이전트가 수행한 작업을 보여주므로, 사용자는 컨텍스트를 다시 구성할 필요 없이 파악한 상태에서 검토할 수 있습니다.

Jira 이슈를 코딩 에이전트에 할당한 다음, 에이전트가 안전한 Cloud 샌드박스에서 코드베이스를 탐색하고 수정 사항 또는 기능을 작성하며 풀리퀘스트를 제기하는 것을 관찰해 보세요.

3. 에스컬레이션: 에이전트가 불확실하거나 범위를 벗어나는 경우 핸드오프

에스컬레이션이란 에이전트가 자신의 한계를 인지하는 것을 의미합니다. 신뢰도가 낮거나 컨텍스트가 부족하거나 정책 경계를 넘어서는 경우, 에이전트는 추측하는 대신 작업을 멈추고 담당자에게 질문하거나 전달해야 합니다. 핵심은 이러한 핸드오프를 체계적으로 만드는 것입니다. 사람이 사후에 실수를 잡아내는 것이 아니라, 에이전트가 예외 상황으로 에스컬레이션을 발생시키도록 트리거를 설계하세요. 에이전트가 스스로의 신뢰도를 확실하게 판단할 것이라고 생각해서는 안 됩니다. 필수 컨텍스트 누락, 낮은 신뢰도 신호가 존재하는 경우, 설정된 크기를 초과하는 변경, 정책 경계를 넘는 모든 작업 등 트리거를 직접 정의해야 합니다.

Jira에서 자동화 규칙은 컨텍스트가 누락된 경우 댓글을 남기거나, 업무 항목에 '보완 필요' 레이블을 지정하거나, 담당자에게 라우팅할 수 있으며, 이는 에이전트가 Atlassian 에이전트이든 타사 에이전트이든 동일하게 작동합니다. 에이전트가 작업 도중 일시 중지하고 질문해야 하는 시점은 (Rovo 또는 Jira 에이전트의 경우 Jira 내에서) 에이전트 자체 지시 사항 또는 타사 에이전트의 도구 설정(Claude, Cursor 또는 Copilot 등)에서 지정됩니다.

• Jira: 자동화 규칙이 매일 아침 열려 있는 모든 보안 업무 항목을 확인하고 심각도에 따라 라우팅합니다. 위험도가 낮고 되돌릴 수 있는 수정 작업은 풀리퀘스트를 생성하는 코딩 에이전트로 전달됩니다. 심각도가 높거나 중요 인프라와 관련된 모든 사항은 변경하기 전에 요약하여 적절한 엔지니어에게 전달하므로, 위험한 결정은 이미 컨텍스트가 파악된 상태로 담당자에게 전달됩니다.

Jira에서 자동화를 한 번만 설정해 두면 나머지는 에이전트가 처리합니다.

사람이 개입하는 과정이 안전장치가 아니라 병목 상태가 되는 경우는 언제입니까?

감독은 두 가지 방향에서 실패할 수 있습니다. 감독이 너무 적으면 목표에 어긋나거나 되돌릴 수 없는 결과물을 배포하게 됩니다. AI 코딩 도입이 늘어남에 따라 개발자 생산성 향상은 약 10~15%에서 정체되었는데, 소프트웨어 배포에서 어려운 부분은 코드를 작성하는 것이 아니기 때문입니다. 진정으로 어려운 부분은 무엇을 구축할지 결정하고 변경하려는 시스템을 이해하며 산출물을 제공해도 안전한지 파악하는 것입니다. 반대로 감독이 너무 지나쳐도 실패하게 됩니다.

게이트가 위험 수준과 맞지 않을 때 사람의 개입은 병목 상태가 됩니다. 흔히 나타나는 세 가지 실패 유형은 다음과 같습니다.

1. 너무 많은 게이트. 모든 작업을 검토하면 검토 피로가 발생하고 에이전트가 담당자를 기다리며 유휴 상태가 되어, 빠른 속도를 위해 도입한 에이전트가 무용지물이 됩니다.

2. 형식적인 승인. 굳이 필요 없는 업무에도 게이트가 작동하면, 담당자는 내용을 읽지도 않고 승인하게 됩니다. 체크포인트는 형식적인 절차가 되며, 정작 실제 문제는 빠져나가 제 기능을 다하지 못합니다.

3. 감독한 내용 대신 감독 여부만을 측정. 승인 횟수를 세는 것은 사람의 개입이 있었다는 사실만 알려줄 뿐, 그들이 무엇을 포착했는지를 알려주지는 않습니다. 검토량이 많다는 것이 좋은 판단력을 의미하는 것은 아닙니다.

처리량을 떨어뜨리지 않으면서 모든 작업에 게이트를 적용할 수 없다면, 대신 샘플링을 활용하세요. 에이전트가 제공하는 모든 항목을 검토하는 대신, 일정 비율만 검토하는 것입니다. Jira에서는 자동화 규칙을 통해 에이전트가 완료한 업무 항목 중 일정 비율에 담당자가 감사하도록 플래그를 지정하거나, 가치가 높은 모든 항목을 라우팅할 수 있습니다. 따라서 작업을 중단하지 않고도 품질을 확실하게 점검할 수 있습니다.

검토 및 승인 환경으로서의 Jira

Jira에서 사람이 개입하는 절차는 별도의 도구가 아니라 팀이 이미 업무를 수행하는 공간 자체이므로, 모든 체크포인트는 업무가 이루어지는 곳에 함께 존재합니다. 이것이 바로 확장 가능한 관리와 아무도 유지 관리하지 않는 병렬 컨트롤 플레인의 차이점입니다.

세 가지 패턴이 모두 하나의 환경에 구현됩니다.

• 지정된 담당자가 승인 서명을 할 때까지 상태 전환을 보류하는 워크플로 승인 단계를 통해 승인합니다.

• 업무 항목과 연결된 풀리퀘스트를 검토하며, Jira 추천 페이지의 에이전트 세션 보기를 사용하여 각 에이전트가 수행한 작업과 나의 조치를 기다리고 있는 항목을 확인합니다.

• 에이전트 지시 사항 및 자동화 규칙을 통해 에스컬레이션을 수행하며, 핸드오프 및 담당자가 업무 항목에 직접 기록됩니다.

Jira를 사용하면 에이전트 산출물을 쉽게 검토하고 제공할 항목을 결정할 수 있습니다

사람과 에이전트는 하나의 기록 시스템에서 업무를 수행합니다. 어떤 에이전트가 업무를 수행하든 팀이 이미 신뢰하는 워크플로, 데이터 권한 및 기록이 적용되므로, AI만을 위해 새로 구축한 별도의 시스템 대신 기존의 제어 기능을 재사용하여 감독할 수 있습니다. 즉, 무분별한 확장 없이 필요한 제어를 확보할 수 있습니다.

AI 에이전트와 함께하는 사람이 개입하는 검토 모범 사례

사람이 개입하는 시스템의 모범 사례는 결과를 바꿀 수 있는 곳에 사람의 주의를 집중하고, 다른 모든 곳에서는 에이전트를 실행하는 것입니다.

• 빈도는 적으면서 더 가치 있는 개입을 지향합니다. 모든 게이트에는 비용이 발생합니다. 형식적인 절차가 된 게이트는 모두 제거하세요.

• 위험 및 복구 가능성에 맞춰 감독을 조정합니다. 반복적인 업무는 자동화하고, 비용이 많이 들거나 되돌리기 어려운 작업에만 승인 절차를 남겨두세요.

• 승인을 검토와 분리합니다. 영향도가 큰 작업 전에 승인을 거치고 제공하는 모든 항목에 대해 검토를 진행하세요.

• 에스컬레이션을 체계화합니다. 낮은 신뢰도, 컨텍스트 누락, 정책 경계 등 트리거 조건을 사전에 정의하세요.

• 좁은 범위로 시작한 다음 점차 확대합니다. 새로운 에이전트에게는 제한된 범위를 부여하고 신뢰가 쌓임에 따라 더 많은 권한을 부여하세요.

Jira에서 사람이 개입하는 워크플로를 처음으로 설정하는 방법

시작하기 위해 재설계까지 필요한 것은 아닙니다. 하나의 워크플로를 선택하고 하나의 체크포인트를 추가한 뒤 점차 확장해 나가세요.

1. 일상적인 작업 하나를 선택합니다. 종속성 업데이트, 불안정한 테스트 수정 또는 설명서 업데이트와 같이 실수를 쉽게 되돌릴 수 있는 부분부터 시작하세요. 설정에 대한 신뢰가 쌓일 때까지 위험 부담이 큰 업무는 나중으로 미룹니다.

2. 해당 작업에 맞게 범위가 지정된 에이전트에게 할당합니다. 담당자 필드, 보드 열 또는 워크플로 전환 등을 통해 에이전트를 추가합니다. 에이전트는 사용자를 대신하여 작동하므로, Jira 내에서는 해당 사용자가 접근할 수 있는 항목에만 접근할 수 있습니다. Jira는 해당 업무에 대한 액세스를 관리하며, 타사 에이전트가 자체 도구로 수행할 수 있는 작업은 Jira 외부에 별도로 설정됩니다. 에이전트를 할당하는 것만으로 실행이 시작되지만, 아직 사람의 개입을 포함하는 것은 아니며, 이는 다음 단계에서 추가할 체크포인트의 몫입니다.

3. 영향이 미치는 곳에 체크포인트를 설정합니다. 영향도가 큰 상태로 전환되는 시점에 승인 단계를 추가하여 업무가 진행되기 전에 담당자가 승인하도록 합니다. 기본 승인 기능이 없는 플랜에서는 전환 조건을 사용하여 업무를 이동할 수 있는 권한을 제한합니다.

4. 산출물을 검토 단계로 보냅니다. 코드의 경우 에이전트가 업무 항목과 연결된 풀리퀘스트 초안을 작성하게 하여 병합 전에 변경 사항을 철저히 검토하도록 하세요. 에이전트의 지시만으로 제공되는 것은 아무것도 없습니다.

5. 경로를 확인한 다음 범위를 확장합니다. 에이전트의 작업이 업무 항목에 기록되었는지 확인한 다음 확장합니다. 되돌릴 수 있는 작업부터 시작하여 다음 상태 전환, 다음 작업 유형 또는 더 넓은 범위로 점차 확대합니다. 에이전트가 신뢰를 얻을수록 자율성을 넓혀줍니다.

Jira에서 에이전트가 수행한 작업 및 결정한 사항을 확인하세요.

최종 목표는 아무런 관리도 필요 없는 에이전트가 아니라, 사람이 정말로 중요한 결정에만 개입하고 나머지 모든 단계가 기록되는 워크플로입니다.

올바른 방식으로 사람의 개입을 구현할 준비가 되셨습니까? AI 네이티브 개발을 위한 Jira 시작하기

사람이 개입하는 AI 에이전트 사용에 대한 자주 묻는 질문

AI 코딩 에이전트를 사용할 때 사람의 개입을 어떻게 유지합니까?

에이전트의 업무를 검토 가능하고 게이트를 거치도록 유지하세요. 산출물을 풀리퀘스트로 라우팅하고 영향도가 높은 변경 사항에 대해서는 사전에 승인을 요구하며 에이전트가 확신이 없거나 범위를 벗어나는 경우 에스컬레이션하도록 트리거를 설계합니다.

Jira의 AI 에이전트가 사람의 승인을 요구할 수 있습니까?

예. 영향이 나타나는 전환에 워크플로 승인 단계를 추가하면 지정된 담당자가 승인하거나 거부할 때까지 업무 항목이 대기 상태로 유지됩니다. 기본 승인은 Premium 및 Enterprise 플랜에서 사용할 수 있습니다.

누가 AI 에이전트가 수행하는 작업을 책임집니까?

항상 사람입니다. 에이전트가 작업을 수행하지만 결과는 사람이 책임집니다. Jira에서는 모든 에이전트 작업이 알려진 ID와 연결되며 업무 항목 기록에 남습니다.

AI 에이전트의 루프 엔지니어링이란 무엇입니까?

루프 엔지니어링은 언제 에이전트가 자체적으로 계속 반복할지 및 언제 사용자에게 핸드오프할지 결정하는 트리거를 설계하는 것입니다. 우수한 트리거는 에스컬레이션을 체계적으로 만들어 감독이 모든 곳이 아닌 위험이 있는 곳에서 수행되게 합니다.

휴먼인더루프가 AI 거버넌스 요구 사항을 충족합니까?

사람의 감독은 EU AI 법 및 NIST AI RMF와 같은 프레임워크의 핵심이지만, 감독만으로는 거버넌스를 의미하지 않습니다. 또한 액세스 권한 적용, 승인 및 감사 내역도 필요합니다. Jira의 에이전트 기반 엔지니어링 가드레일 및 안전을 참조하세요.