자동화가 잘될수록 사람은 더 적게 개입하게 됩니다. 자료를 찾고, 파일을 만들고, 테스트를 실행하고, 배포 후보를 준비하는 일이 한 번의 요청에서 이어집니다.
그런데 자동화의 성공을 “중간에 사람이 끼어들지 않았다”로 정의하면 곧 문제가 생깁니다. 빠르게 실행되는 흐름이 무엇을 읽었는지, 무엇을 외부로 보냈는지, 어떤 권한으로 실행했는지, 어디에서 비용이 발생했는지 설명하지 못하기 때문입니다.
자동화의 반대말은 수동 작업이 아닙니다. 자동화의 반대편에는 통제되지 않은 실행이 있습니다. 오늘은 빠른 흐름을 멈추게 하는 장애물이 아니라, 빠른 흐름이 오래 작동하게 하는 운영 경계선을 그려 보겠습니다.
1. 모든 단계가 같은 위험도를 갖지는 않는다
“전부 자동화하자”는 말에는 서로 다른 종류의 일이 한데 묶여 있습니다. 공개 문서를 검색하는 일과 고객 자료를 외부 API로 보내는 일, 초안을 로컬 파일에 저장하는 일과 운영 사이트에 게시하는 일은 모두 자동화할 수 있지만 위험도는 전혀 다릅니다.
업무를 먼저 네 가지 동작으로 나누면 경계가 보이기 시작합니다.
| 동작 | 예시 | 기본 통제 |
|---|---|---|
| 조회 | 공개 자료·프로젝트 파일 검색 | 범위 제한, 출처 기록 |
| 준비 | 초안 생성, 변환, 테스트 실행 | 샌드박스, 변경 목록 확인 |
| 외부 변경 | 커밋, 메시지 발송, 배포 | 명시적 승인, 대상 재확인 |
| 고위험 실행 | 결제, 권리 포기, 대외 법률 판단 | 사람의 직접 결정과 기록 |
위험도는 도구 이름만으로 정해지지 않습니다. 같은 파일 수정도 임시 브랜치에서 하는 것과 운영 브랜치에서 하는 것은 다릅니다. 같은 검색도 공개 정보와 비공개 고객 자료를 함께 검색하는 순간 통제 기준이 달라집니다.
따라서 자동화 설계의 첫 질문은 “어떤 제품을 연결할까?”가 아니라 “이 단계가 실패했을 때 무엇이 바뀌는가?”여야 합니다.
아키텍처 교훈 ① 자동화의 위험도는 기능의 화려함보다 정보의 민감도, 실행 권한, 외부 영향과 되돌릴 수 있는 정도에 따라 달라진다.
2. 권한은 에이전트가 아니라 단계에 붙인다
에이전트 하나에 모든 권한을 몰아주면 설계는 단순해집니다. 검색도 하고, 파일도 수정하고, 배포도 할 수 있습니다. 하지만 한 단계의 오류나 잘못된 지시가 전체 시스템의 권한으로 확대될 수 있습니다.
더 안전한 구조는 작업을 단계로 나누고 각 단계에 필요한 최소 권한만 부여하는 것입니다.
조회 에이전트
└─ 읽기 전용 자료·검색 권한
준비 에이전트
└─ 격리된 작업 공간·임시 변경 권한
검증 단계
└─ 빌드·테스트·정적 검사 권한
배포 단계
└─ 승인된 환경·제한된 배포 권한
이렇게 하면 에이전트가 같은 역할을 계속 수행하더라도 사고의 범위를 줄일 수 있습니다. 특히 조회 결과를 만든 주체가 곧바로 외부 변경까지 수행하지 않게 하면, 검색 결과의 오해나 프롬프트의 모호함이 운영 상태로 직행하는 일을 막을 수 있습니다.
MCP의 보안·신뢰 원칙은 호스트가 데이터 노출과 도구 호출 전에 사용자의 동의와 통제를 확보하고, 서버에 필요한 데이터만 전달해야 한다는 방향을 제시합니다. MCP 연결을 많이 만드는 것보다 중요한 것은 각 연결이 어느 자료와 동작까지 책임지는지를 구분하는 일입니다.
3. 비밀정보는 숨겨진 문자열이 아니라 이동을 제한해야 하는 데이터다
비밀정보를 .env나 시크릿 저장소에 넣었다고 해서 보호가 끝나는 것은 아닙니다. 비밀정보가 다음 경로로 이동할 수 있기 때문입니다.
저장소
→ 실행 환경
→ 에이전트·MCP 서버
→ 로그·아티팩트
→ 외부 API·배포 서비스
각 단계에서 다음을 물어야 합니다.
- 이 단계가 비밀정보를 정말 필요로 하는가?
- 전체 값을 받아야 하는가, 제한된 작업만 위임하면 되는가?
- 로그와 오류 메시지에 값이 남지 않는가?
- 작업이 끝난 뒤 토큰을 회수하거나 교체할 수 있는가?
- 다른 환경이나 다른 에이전트가 같은 비밀정보를 볼 수 있는가?
비밀정보의 안전한 취급은 “절대 노출하지 말자”라는 구호보다 필요한 단계에만 짧게 주입하고, 사용 후 기록과 권한을 점검하는 것에 가깝습니다.
GitHub도 Actions 보안 사용 지침에서 워크플로의 토큰 권한을 최소화하고, 민감정보를 평문으로 저장하지 않으며, 환경 승인과 로그 마스킹을 고려하도록 안내합니다. 에이전트가 만든 변경을 Actions로 넘기는 구조라면 이 원칙은 에이전트 단계에도 그대로 이어져야 합니다.
4. 데이터 전송은 ‘호출’이 아니라 경계를 넘는 사건이다
도구 호출은 화면에서 버튼 하나처럼 보이지만, 실제로는 데이터가 한 시스템에서 다른 시스템으로 이동하는 사건입니다. “이 서버를 연결할까요?”라는 질문만으로는 부족합니다. 어떤 데이터가, 어느 범위로, 어떤 보존 정책을 가진 시스템에 전달되는지 확인해야 합니다.
예를 들어 다음 세 요청은 모두 “문서를 분석해 달라”는 말로 표현할 수 있습니다.
- 로컬 폴더의 공개 초안을 읽고 목차를 정리한다.
- 비공개 기술자료에서 핵심 구성을 추출한다.
- 고객 식별정보가 포함된 파일을 외부 서비스에 보내 분석한다.
자동화는 세 요청을 모두 처리할 수 있지만, 허용 조건은 같을 수 없습니다. 1번은 로컬 읽기와 결과 저장만으로 충분할 수 있고, 2번은 접근 권한과 원본 출처를 기록해야 하며, 3번은 비식별화·사용자 승인·전송 대상의 확인이 먼저입니다.
그래서 저는 데이터 전송을 다음처럼 기록하려 합니다.
| 항목 | 확인 질문 |
|---|---|
| 데이터 | 무엇이 실제로 전달되는가? |
| 대상 | 어느 서버·도구·계정으로 가는가? |
| 목적 | 현재 작업에 꼭 필요한가? |
| 보존 | 결과와 원문이 얼마 동안 남는가? |
| 철회 | 잘못 보냈을 때 회수하거나 차단할 수 있는가? |
이 표를 매번 길게 작성할 필요는 없습니다. 민감도에 따른 기본 규칙을 문서화하고, 예외일 때만 사람의 확인을 받으면 됩니다. 중요한 것은 “AI가 알아서 처리했다”가 데이터 이동의 설명이 되지 않는다는 점입니다.
5. 비용도 권한처럼 예산을 정해야 한다
자동화의 비용은 API 사용료만을 뜻하지 않습니다. 호출 횟수, 긴 컨텍스트, 병렬 에이전트 수, 저장·검색·빌드 시간, 사람이 다시 검토하는 시간까지 포함됩니다.
특히 자동화가 잘 작동하면 사용량이 눈에 띄지 않게 늘어날 수 있습니다. 실패한 작업이 재시도되고, 관련 없는 자료까지 검색되며, 같은 결과를 여러 단계가 중복 생성할 수 있습니다. 속도는 빨라졌는데 비용과 검토량이 함께 커지는 상황입니다.
이를 막으려면 자동화마다 최소한 다음 제한을 둘 수 있습니다.
- 한 작업에서 호출할 수 있는 도구와 횟수
- 읽어 올 수 있는 자료의 범위와 크기
- 병렬로 실행할 수 있는 에이전트 수
- 재시도 횟수와 중단 조건
- 비용이 일정 수준을 넘을 때의 알림·승인
비용 제한은 창의성을 막는 장치가 아닙니다. 오히려 에이전트가 어디까지 탐색해야 하는지 알려 주는 업무 범위의 숫자화입니다. 예산을 정하지 않은 자동화는 언젠가 비용뿐 아니라 데이터 접근 범위도 함께 넓어질 가능성이 큽니다.
6. 감사 로그는 모든 것을 적는 것이 아니라 중요한 전환을 남기는 일이다
감사 로그를 남기자고 하면 모든 대화와 도구 호출을 영구 보관해야 할 것처럼 느껴집니다. 그러나 실무에서 먼저 필요한 것은 정보의 양보다 상태가 바뀐 순간입니다.
다음 전환은 우선 기록할 가치가 있습니다.
조회 시작
→ 비공개 자료 접근
→ 외부 시스템으로 데이터 전송
→ 파일·코드 변경
→ 검증 통과 또는 보류
→ 사람 승인
→ 외부 게시·배포
각 전환에 작업 ID, 시간, 대상, 사용한 자료의 식별자, 실행 주체, 결과 상태를 붙이면 나중에 전체 대화를 다시 읽지 않아도 작업의 흐름을 복원할 수 있습니다. 다만 로그 자체에도 민감정보가 들어갈 수 있으므로 접근 권한과 보존 기간을 별도로 정해야 합니다.
좋은 로그는 “에이전트가 무엇을 많이 했는가”보다 “어느 경계선을 언제 넘었고, 누가 허용했는가”를 보여 줍니다. 이 관점은 운영 장애를 조사할 때뿐 아니라 비용을 줄이고 권한을 재설계할 때도 유용합니다.
7. Human Gate는 자동화의 실패가 아니라 설계된 책임 분담이다
사람의 승인을 넣으면 자동화가 느려진다고 생각하기 쉽습니다. 그래서 많은 시스템이 마지막 단계까지 자동으로 연결한 뒤, 문제가 생기면 사람이 사후에 수습하는 방식을 택합니다.
하지만 모든 승인이 같은 방식일 필요는 없습니다. 위험이 낮고 되돌릴 수 있는 작업은 자동으로 통과시키고, 외부 영향이 큰 작업만 짧고 명확한 확인을 요구하면 됩니다.
| 조건 | 처리 방식 |
|---|---|
| 읽기 전용·공개 자료·되돌릴 수 있음 | 자동 실행 |
| 내부 파일 변경·검증 가능 | 자동 실행 후 변경 목록 확인 |
| 외부 게시·배포·비용 발생 | 사전 승인 |
| 비밀정보·고객 자료·법적 판단 | 범위와 근거를 사람이 직접 확인 |
여기서 Human Gate는 사람이 모든 과정을 다시 수행한다는 뜻이 아닙니다. 사람은 에이전트가 잘하는 반복 작업을 빼앗지 않고, 권한이 확대되거나 책임이 외부로 이동하는 순간에 판단합니다.
앞선 글에서 근거·승인·감사 로그를 하나의 흐름으로 설명했듯이, 승인 버튼만 추가해서는 충분하지 않습니다. 승인자는 무엇을 승인하는지, 어떤 근거를 보았는지, 승인 이후 어떤 외부 변경이 일어나는지를 확인할 수 있어야 합니다.
8. 빠른 자동화를 위한 운영 경계선 체크리스트
자동화를 새로 연결하거나 기존 흐름을 넓힐 때는 다음 질문만으로도 위험한 기본값을 꽤 많이 걸러낼 수 있습니다.
[ ] 이 단계는 조회·준비·외부 변경 중 무엇인가
[ ] 현재 단계에 필요한 최소 권한만 부여했는가
[ ] 비밀정보가 필요 없다면 아예 전달하지 않는가
[ ] 데이터가 어느 시스템으로 이동하는지 알고 있는가
[ ] 호출 수·자료 범위·재시도·비용 제한이 있는가
[ ] 상태가 바뀌는 순간과 결과를 기록하는가
[ ] 외부 영향이 큰 단계에 Human Gate가 있는가
[ ] 실패하거나 잘못 실행했을 때 중단·회수·롤백할 수 있는가
이 체크리스트는 자동화를 포기하게 만드는 문서가 아닙니다. 오히려 “어디까지 맡겨도 되는가”를 미리 정해 두어, 매번 같은 불안을 새로 계산하지 않게 해 줍니다.
마치며
빠른 자동화와 안전한 운영은 서로 반대되는 목표가 아닙니다. 자동화가 맡을 일을 작게 쪼개고, 권한과 데이터를 단계별로 제한하고, 비용과 실행 이력을 보이게 만들며, 외부 영향이 커지는 지점에 사람의 승인을 두면 둘은 함께 갈 수 있습니다.
결국 디지털 아키텍처에서 중요한 것은 “얼마나 많은 일을 자동으로 했는가”가 아닙니다. 무엇을 자동화했고, 무엇을 멈췄으며, 그 경계를 누가 어떤 근거로 정했는가를 설명할 수 있는가입니다.
에이전트는 빠른 실행자일 수 있습니다. 그러나 운영 가능한 시스템이 되려면 권한의 울타리, 데이터의 이동 규칙, 비용의 예산, 감사의 기억, 사람의 책임이 함께 있어야 합니다. 그 경계선이 선명할수록 자동화는 한 번의 시연을 넘어 오래 반복할 수 있는 업무 구조가 됩니다.