사람의 승인과 테스트 검증을 포함한 n8n 코드 변경 워크플로 구축

워크플로 한눈에 보기

n8n을 사용하면 AI 에이전트가 저장소 변경안을 제안하도록 하면서도 쓰기 작업에는 사람의 승인을 요구할 수 있습니다. 쓰기가 승인되면 결과 커밋을 대상으로 테스트를 실행하고 결과를 보고합니다. 병합이나 배포는 별도의 결정으로 분리하세요.

핵심은 도구 승인과 출력 승인의 차이입니다. n8n의 사람 검토 단계는 선택한 도구가 실행되기 전에 AI Agent를 일시 중지할 수 있습니다. 검토자는 제안된 도구와 매개변수를 확인합니다. 승인하면 해당 호출이 실행되고, 거부하면 호출이 취소되어 에이전트에 전달됩니다. 이 동작은 n8n의 휴먼 인 더 루프 가이드에 문서화되어 있습니다.

OneMux는 하나의 OpenAI 호환 API를 통해 AI 모델에 접근할 수 있도록 합니다. 이 설계에서 사용할 수 있는 모델 접근 경로일 뿐, 검증된 n8n 연동은 아닙니다. 사용할 엔드포인트와 매개변수에 맞춰 OneMux API 문서와 n8n 노드 설정을 확인하세요.

구축 전 준비 사항

• AI Agent, 적절한 채팅 모델 연결, Slack 또는 n8n Chat 같은 사람 검토 채널을 사용할 수 있는 n8n 인스턴스
• 지정된 리비전을 읽고 프로덕션이 아닌 브랜치에 패치를 적용할 수 있는 저장소 연동 또는 자체 서비스. 쓰기 자격 증명에는 해당 저장소와 브랜치에 필요한 권한만 부여하세요.
• 프로덕션 자격 증명 및 시스템과 분리된 테스트 실행기. 정확한 커밋 식별자를 받고 상태와 결과 링크 또는 참조를 반환해야 합니다.
• 모델 호출에 OneMux를 선택하는 경우 OneMux 계정과 API 액세스 권한. 최신 연결 정보는 빠른 시작을, 사용 가능한 모델을 선택할 때는 모델 카탈로그를 확인하세요.
• 테스트 명령이 정해져 있고 기본 브랜치가 보호되며 변경 제안을 검토할 권한이 있는 담당자가 지정된 저장소

이 내용은 구현 패턴이지, 가져와서 바로 사용할 수 있는 워크플로가 아닙니다. 저장소 도구, 실행기 연동, 모델 선택, 정확한 n8n 필드는 환경에 따라 달라집니다. 특히 제공된 문서는 특정 OneMux 모델이 n8n AI Agent에 필요한 도구 호출 동작을 지원하는지 확인해 주지 않습니다. 이 설계에 의존하기 전에 지원 여부를 검증하세요.

정확한 리비전을 기준으로 워크플로 설계하기

실용적인 절차는 다음과 같습니다.

1. 요청을 받습니다. 신뢰할 수 있는 워크플로 설정에서 저장소, 이슈 설명, 대상 작업 브랜치, 기준 커밋, 허용된 테스트 명령을 가져옵니다.
2. 읽고 변경안을 제안합니다. 에이전트가 기준 커밋의 관련 파일을 확인하고 패치를 준비하도록 합니다. 읽기 권한으로 저장소를 수정할 수 없어야 합니다.
3. 쓰기 작업을 검토합니다. 패치 적용 도구를 n8n 사람 검토 단계에 연결합니다. 검토자가 제안된 도구 호출을 승인하거나 거부합니다.
4. 적용하고 식별합니다. 승인되면 쓰기 서비스가 브랜치가 여전히 승인된 기준 커밋을 가리키는지 확인하고, 승인된 패치를 적용한 뒤 새 커밋 ID를 반환합니다. 기준이 바뀌었다면 안전을 위해 작업을 중단하고 새 변경안과 승인을 요청합니다.
5. 검증합니다. 격리된 실행기에서 해당 새 커밋을 대상으로 설정된 테스트를 실행합니다. 명령, 커밋, 상태, 결과 참조를 기록합니다.
6. 결과를 보고합니다. 검토자와 요청자에게 커밋 및 테스트 결과를 전달합니다. 실패, 취소, 결과 누락은 통과로 간주하지 않습니다.

이는 권장 제어 방식이며 n8n의 사람 검토 단계가 보장하는 기능은 아닙니다. 특히 기준 커밋을 확인하고 승인된 패치와 실제 적용되는 패치가 일치하도록 보장해야 하는 책임은 저장소 서비스에 있습니다.

모델 연결 구성하기

n8n에서 구성 가능한 OpenAI 호환 엔드포인트와 AI Agent에 필요한 도구 호출 동작을 모두 지원하는 채팅 모델 설정을 선택하세요. 최신 OneMux 문서에 명시된 엔드포인트, 인증 방식, 모델 식별자를 사용합니다. 자격 증명은 프롬프트나 워크플로 메시지가 아니라 n8n의 자격 증명 시스템에 저장하세요.

저장소 액세스를 연결하기 전에 간단한 테스트 요청을 보내 응답이 n8n 노드에서 기대하는 형식으로 도착하는지 확인하세요. 그런 다음 안전한 도구 호출을 테스트합니다. OpenAI 호환이라고 해서 모든 엔드포인트, 매개변수, 도구 호출 형식을 서로 바꿔 쓸 수 있는 것은 아닙니다. 여기서 호환되려면 양쪽이 필요한 요청과 응답을 지원해야 합니다. 이 문서의 설정은 테스트되지 않았습니다.

사용 가능한 모델 연결이 에이전트의 도구 호출을 지원하지 않는다면, 모델에 직접 쓰기 자격 증명을 제공해 승인을 우회하지 마세요. 호환되는 설정을 사용하거나, 별도의 명시적인 검토 절차를 거치는 쓰기 서비스 인계 흐름을 구축하세요.

저장소 쓰기 작업에 사람 승인 단계 추가하기

AI Agent 노드에서 Tools 커넥터를 열고 Tools Panel에서 Human review를 찾습니다. 승인 채널을 선택하고 자격 증명을 설정하세요. 저장소 쓰기 도구를 검토 단계의 도구 커넥터에 연결합니다. 적절한 경우 읽기 전용 도구는 분리하고, 외부 상태를 변경할 수 있는 다른 도구도 각자의 검토 단계나 이에 준하는 제어 뒤에 배치하세요.

n8n 문서에 따르면 검토자는 도구 이름과 AI가 제공한 매개변수를 받을 수 있습니다. 예를 들어 검토 메시지를 다음과 같이 설정할 수 있습니다.

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

검토 가능한 입력에 저장소, 브랜치, 기준 커밋, 전체 패치 또는 다이제스트가 포함된 변경 불가 패치 참조가 들어가는 쓰기 도구를 사용하세요. 패치가 채널에 담기에는 너무 크다면 안전하게 접근할 수 있는 검토 위치를 제공하고, 쓰기 서비스가 같은 내용을 적용하는지 확인합니다. “테스트를 고쳐 주세요”처럼 모호한 지시는 특정 저장소 변경을 승인하기에 충분하지 않습니다.

문서에 기재된 $tool.parameters 값에는 $fromAI() 표현식으로 설정된 필드가 포함됩니다. 메시지에 모든 고정 자격 증명, 숨겨진 설정 값, 후속 영향이 노출된다고 가정하지 마세요. 고정 설정은 제한하고 검토자가 별도로 확인할 방법을 제공하세요. 매개변수는 승인 메시지에 표시될 수 있으므로 도구 매개변수에 비밀 정보를 넣지 마세요.

승인 단계가 필요한 도구를 지정하고 거부 시 에이전트가 어떻게 처리할지 알려주는 시스템 지침을 추가하세요. 예를 들면 다음과 같습니다.

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

이 지침은 에이전트가 검토 결과에 대응하도록 돕지만 보안 경계는 아닙니다. 권한과 브랜치 제한은 프롬프트 외부에서 적용하세요.

승인된 변경 사항 검증하기

쓰기 서비스가 커밋 ID를 반환한 뒤에만 테스트 실행기를 시작하세요. 실행기가 최신 브랜치 헤드가 아니라 해당 ID를 체크아웃하고, 팀에서 정의한 허용 목록의 명령을 실행하도록 구성합니다. 저장소 관리자가 선택한 명령의 예는 다음과 같습니다.

npm test

위 명령은 예시일 뿐입니다. 프로젝트의 실제 테스트 지침을 따르세요. 저장소 코드, 종속 항목 설치 스크립트, 테스트 출력은 신뢰할 수 없는 것으로 취급합니다. 프로덕션 비밀 정보 없이, 네트워크와 파일 시스템 접근을 제한하고 시간 및 리소스 한도를 설정해 실행하세요. 테스트 통과는 해당 환경에서 선택한 검사가 통과했음을 보여줄 뿐, 변경이 안전하거나 올바르다는 것을 입증하지는 않습니다.

승인된 기준 커밋, 새 커밋, 테스트 명령, 통과/실패 상태, 로그 링크를 담은 간결한 결과를 반환하세요. 테스트가 실패하면 에이전트가 수정된 패치를 제안할 수 있지만, 추가 쓰기에는 별도의 승인이 필요합니다. 검토자가 앞선 도구 호출을 승인했다는 이유로 자동 병합하지 마세요.

문제 해결 및 운영상 한계

승인 요청에 유용한 정보가 부족한 경우

어떤 입력이 AI에서 제공되며 $tool.parameters에 표시되는지 확인하세요. 패치 식별 정보, 브랜치, 기준 리비전을 검토 가능한 도구 입력에 포함하거나 안전하고 변경 불가한 검토 자료를 제공하세요. 검토자가 정확한 쓰기 작업을 식별할 수 없다면 거부해야 합니다.

에이전트가 도구를 호출할 수 없는 경우

먼저 저장소 권한과 무관한 안전한 도구 호출을 테스트하세요. 최신 문서를 기준으로 n8n 노드, OneMux 엔드포인트, 선택한 모델, 필수 도구 호출 매개변수를 확인합니다. 제공된 출처는 특정 모델과 노드 조합을 검증하지 않습니다.

브랜치가 변경되었거나 테스트가 완료되지 않은 경우

패치를 다른 기준에 적용하지 말고 기준이 오래된 쓰기 작업을 거부하세요. 시간 초과, 실행기 오류, 로그 누락이 발생하면 검증 미완료로 보고합니다. 적절한 경우 같은 커밋을 대상으로 다시 실행하고, 제안된 쓰기 내용이 달라지면 새 승인을 요청하세요.

결론

핵심 경계는 명확합니다. 사람이 특정 저장소 쓰기 작업을 승인하고, 격리된 실행기가 결과 커밋을 검증합니다. n8n은 문서화된 도구 수준의 일시 중지 및 승인 흐름을 제공하며, 나머지 안전장치는 저장소 서비스, 실행기, 권한, 검토 절차가 담당합니다. 선택한 엔드포인트와 매개변수가 n8n 설정에서 작동하는지 확인한 뒤에만 OneMux를 모델 액세스 계층으로 사용하세요.

출처

• n8n: 도구를 위한 휴먼 인 더 루프 — 도구 승인 동작, 설정, 검토 채널, 검토 메시지 변수
• OneMux 문서 — 최신 API 연결 정보 확인