자동화가 편해지면, 사고도 자동화됩니다

에이전트가 똑똒해질수록 한 가지 질문이 따라와요. “이거 알아서 해도 돼?”

사양서 초안을 만드는 건 괜찮아요. 데이터를 정리하는 것도요. 하지만 프로덕션에 배포하는 건? 외부에 메시지를 보내는 건? 정책을 바꾸는 건?

편리함과 위험은 같은 방향에 있어요. 에이전트가 할 수 있는 일이 많아질수록, “해도 되는 일”의 경계를 더 정확하게 그어야 해요.

이 글은 이전 글에서 다룬 PaSelf(Platform as Self, 개인화 소프트웨어)의 3대 과제 중 **안전(Safety)**을 풀어보는 시도예요.

”알아서 해줘”의 함정

실제로 겪은 일이에요.

에이전트에게 “이거 처리해줘”라고 했어요. 에이전트는 착실하게 요청서를 작성하고, 팀에 전달하고, 작업을 트리거했어요. 문제는 — 제가 확인하기 전에 실행됐다는 거예요.

요청 내용이 틀린 건 아니었어요. 하지만 타이밍이 안 맞았고, 대상이 달랐어요. 결과적으로 되돌리는 데 시간을 썼어요.

또 다른 경우. 에이전트 A가 댓글 API 코드를 수정하고 바로 커밋·푸시를 했어요. 코드 자체는 맞았지만 — 그 순간 에이전트 B도 같은 브랜치에서 마이그레이션 파일을 수정 중이었어요. A가 먼저 푸시하면서 B의 작업 기반이 흔들렸고, B가 푸시하려다 충돌이 났어요. 되돌리고 리베이스하는 데 시간을 썼어요.

“커밋까지는 OK, 푸시는 확인 후”라는 규칙이 없었던 거예요. 에이전트 입장에서는 “작업 완료 → 푸시”가 자연스러운 흐름이에요. 하지만 여러 에이전트가 같은 저장소에서 동시에 작업할 때, 푸시는 더 이상 개인 행동이 아니에요.

두 사례 모두 에이전트가 잘못한 게 아니에요. 경계가 없었던 거예요. “여기까지는 알아서 해도 돼, 여기부터는 물어봐”라는 선이 없으면, 에이전트는 할 수 있는 일을 전부 해요. 그게 에이전트의 본질이니까요.

경계를 긋는 두 가지 축

경계는 두 축으로 그을 수 있어요.

축 1: 영향 범위 — 안이냐 밖이냐

구분	예시	위험도
내부	파일 읽기, 코드 수정, 초안 작성, 검색	낮음
외부	메시지 전송, 배포, API 호출, 결제	높음

안에서 하는 일은 되돌릴 수 있어요. 파일을 잘못 수정해도 git으로 복구할 수 있고, 초안이 이상해도 다시 쓰면 돼요.

밖으로 나가는 일은 되돌리기 어려워요. 한 번 보낸 메시지는 회수할 수 없고, 프로덕션에 배포된 코드는 영향이 즉시 퍼져요.

그래서 첫 번째 원칙이 나와요: “밖으로 나가는 모든 행동은 확인 후 실행.”

축 2: 판단 수준 — 실행이냐 결정이냐

구분	예시	위험도
실행	포맷 맞추기, 데이터 추출, 빌드, 정해진 패턴 적용	낮음
결정	정책 변경, 우선순위 판단, 예외 처리, 새 규칙 생성	높음

실행은 패턴이 있어요. “사양서는 이 포맷으로 써”, “빌드는 이 명령어로 해” — 정해진 규칙을 따르면 돼요.

결정은 맥락이 필요해요. “이 기능을 지금 넣을 것인가?”, “이 예외를 어떻게 처리할 것인가?” — 정해진 규칙이 아니라 상황을 읽어야 해요.

두 번째 원칙: “결정이 필요한 행동은 사람이 한다.”

두 축을 조합하면 4칸이 나와요

	내부	외부
실행	✅ 자동 실행	⚠️ 확인 후 실행
결정	⚠️ 제안 후 승인	🔴 반드시 승인

✅ 내부 + 실행: 자유롭게 해도 돼요. 파일 읽기, 코드 수정, 검색, 초안 작성, 빌드.

⚠️ 외부 + 실행: 실행 자체는 단순하지만 밖으로 나가니까 확인이 필요해요. 메시지 전송, 배포, 외부 API 호출.

⚠️ 내부 + 결정: 안에서 일어나지만 판단이 필요해요. 정책 초안 작성 후 승인, 우선순위 제안 후 확인.

🔴 외부 + 결정: 가장 위험해요. 정책 변경을 외부에 반영하는 것, 결제 처리, 사용자 데이터 삭제. 반드시 사람이 확인하고 승인해야 해요.

실전에서의 규칙

이론은 깔끔해요. 하지만 실전에서는 경계가 흐릿해지는 순간이 있어요. 몇 가지 규칙으로 보완했어요.

실전에서는 네 가지 규칙으로 운영했어요

이론만으로는 경계가 잘 안 지켜져요. 그래서 실전에서는 네 가지 규칙으로 고정했어요. 이 중에서 가장 효과가 컸던 건 외부 실행 전 2문장 확인이었어요.

규칙 1: 외부 실행 전, 2문장 확인

밖으로 나가는 모든 행동 앞에 확인 질문을 넣었어요.

“이건 요청(Task)인가요, 질문(Chat)인가요?”
“대상은 누구고, 어떤 경로로 보낼까요?”

이 두 문장이 없으면 에이전트는 실행하지 않아요. 단순하지만 효과가 커요. 확인 질문이 있으면 에이전트가 “알아서 보내는” 사고가 구조적으로 차단돼요.

나머지 세 규칙은 이 2문장을 보완하는 장치예요.

규칙 2: 커밋과 푸시를 분리

커밋은 내부 행동, 푸시는 외부 행동으로 봐요.
특히 main 브랜치 푸시는 확인 후에만.

규칙 3: 에이전트가 에이전트를 통제하지 않는다

에이전트1이 에이전트2에게 직접 작업을 지시하지 않아요.
작업 요청서는 사람이 확인한 뒤 큐에 등록해요.

실제로 PM 역할의 에이전트가 기획을 마친 뒤 “다음 단계는 개발”이라고 판단하고 바로 다음 큐에 태스크를 넣은 적이 있었어요. 그런데 아직 결정되지 않은 사항이 남아 있었고, 결국 방향을 다시 바꿔야 했어요. 빠름 자체가 문제가 아니라, 사람의 승인 없이 다음 단계가 연결된 것이 문제였어요.

규칙 4: 품질 이슈 발견 시 즉시 중단

자동화 도중 품질 이슈가 보이면 전부 중단해요.
원인 수정 → 샘플 확인 → 재개 순서로만 움직여요.

승인의 비용

“그러면 매번 확인받으면 느려지지 않냐?”

맞아요. 승인에는 비용이 있어요. 확인 한 번이 30초라도, 하루에 50번이면 25분이에요.

하지만 사고 한 번의 비용은 그보다 훨씬 커요. 잘못된 배포 하나, 잘못된 메시지 하나가 만드는 복구 시간은 몇 시간에서 며칠이에요.

그래서 핵심은 “전부 승인”이 아니라 **“어디에 승인을 넣을 것인가”**예요. 4칸 매트릭스에서 ✅ 영역은 자유롭게, ⚠️와 🔴 영역에만 승인을 넣으면 — 속도와 안전을 둘 다 잡을 수 있어요.

신뢰가 쌓이면 ⚠️ 영역의 일부를 ✅로 옮길 수도 있어요.

실제로 이런 과정이 있었어요. 처음에는 dev 브랜치 푸시도 매번 확인했어요. 에이전트가 dev에 여러 번 푸시했고 — 전부 문제없었어요. 충돌도, 불필요한 커밋도 없었어요. 그 시점부터 “dev 푸시는 자동”으로 규칙을 바꿨어요.

반면 main 브랜치 병합은 여전히 확인해요. dev는 실험 공간이지만, main은 배포와 직결되니까요. dev에서 쌓은 신뢰가 main으로 자동 확장되지는 않아요. 영역이 달라지면 신뢰도 처음부터 쌓아야 해요.

이렇게 점진적으로 권한을 넓히면 — 속도와 안전이 같은 방향이 될 수 있어요.

PaSelf에서 이게 왜 중요한가

이전 글에서 PaSelf의 3대 과제로 안전, 해석, 지속을 꼽았어요.

안전이 첫 번째인 이유는 — 신뢰가 없으면 나머지가 의미 없기 때문이에요.

에이전트가 아무리 똑똑하게 해석하고, 아무리 오래 지속되더라도, “이 에이전트가 내 돈을 마음대로 쓸 수 있다”거나 “내 모르게 메시지를 보낼 수 있다”면 — 아무도 안 써요.

개인 소프트웨어에서 권한/승인 설계는 기업 소프트웨어의 RBAC(Role-Based Access Control)와는 결이 달라요. 기업에서는 “직급별로 권한을 나눈다”지만, 개인 소프트웨어에서는 사용자가 한 명이에요. 권한을 나눌 사람이 없어요.

대신 나누는 건 **“자동 실행 영역”과 “승인 필요 영역”**이에요. 사람(나) vs 에이전트의 경계가 아니라, 안전한 행동 vs 위험한 행동의 경계를 긋는 거예요.

정리

에이전트에게 일을 맡길 때, 두 가지를 물어보세요.

이건 안에서 끝나는 일인가, 밖으로 나가는 일인가?
이건 정해진 패턴을 따르는 실행인가, 맥락이 필요한 결정인가?

이 두 질문의 교차점에서 네 가지 레벨이 나와요: 자동 실행, 확인 후 실행, 제안 후 승인, 반드시 승인.

전부 자동화하면 빠르지만 위험하고, 전부 승인하면 안전하지만 느려요. 경계를 정확히 그으면 둘 다 잡을 수 있어요.

“알아서 해줘”는 편한 말이지만, 그 뒤에는 “여기까지만”이 꼭 따라와야 해요.

오늘 에이전트에게 맡긴 일 하나를 떠올려서, 이 4칸 중 어디에 놓이는지 한 번만 점검해보세요. 그 한 번의 점검이 사고를 막아요.

다음 글 예고: 이 원칙을 실전에 적용한 이야기. 사케덕을 48시간 만에 기획→개발→QA→배포까지 완성한 과정에서, 에이전트 팀의 역할 분담과 승인 게이트가 어떻게 작동했는지를 정리합니다.

에이전트에게 뭘 맡기고, 뭘 직접 승인할 것인가 — 개인 소프트웨어의 안전 경계