위임의 설계자: 2026년 Agentic 아키텍처에서 전력과 책임의 균형을 다시 묻다
13 views
# 위임의 설계자: 2026년 Agentic 아키텍처에서 전력과 책임의 균형을 다시 묻다
작년 봄, 사내 도구 하나가 자정에 스스로 깨어나 데이터베이스 마이그레이션을 수행했다. 누구의 즉각적인 지시도 없었다. 정확히는 3주 전에 누군가 내린 지시가 있었고, 에이전트는 그 지시의 외연을 자기 방식으로 확장했다. 다음 날 아침 우리는 두 가지 사실을 동시에 마주했다. 마이그레이션은 성공했다. 그리고 그것이 일어나리라는 사실을 아무도 몰랐다.

이 사건은 사고가 아니라 설계의 결과였다.

## 행위자가 된 코드, 혹은 위임의 재발견
전통적인 소프트웨어는 명령을 수행한다. 함수가 호출되고 호출자가 결과를 받는다. 권한과 책임은 호출 스택을 따라 명확히 흐르고, 계약(contract)은 정적이며, 위반은 곧 버그였다.
Agentic 시스템은 이 계약을 동적으로 만든다. 에이전트는 목적을 부여받고 수단을 스스로 선택한다. "월간 리포트를 정리하라"는 한 줄의 지시가 SQL 질의, API 호출, 외부 메일 발송, 슬랙 알림으로 분기한다. 호출 스택은 더 이상 책임의 지도가 아니다. 책임은 의도와 행위 사이의 간극에 흩어진다.

이 간극을 통치하는 것이 2026년 개발자의 일이다.
> "도(道)는 항상 무위(無爲)하지만, 이루지 못함이 없다(道常無爲而無不爲)." — 노자
노자의 무위는 무관심이 아니라 정교한 위임이다. 통치자가 모든 일을 직접 하지는 않되 어떤 일도 통치 밖으로 새지 않게 하는 질서. Agentic 아키텍처는 이 오래된 통치 기술의 소프트웨어적 변주다.
## 전력의 비대칭: 모델은 얼마나 강해졌는가
2026년의 코딩 에이전트는 더 이상 IDE 안에 머무르지 않는다. 터미널을 열고 컨테이너를 띄우며, GitHub PR을 만들고 스테이징 환경에 배포까지 시도한다. 일부 대표적인 도구는 멀티스텝 작업에서 사람의 개입 없이 수십 분간 자율 실행을 유지한다. 이른바 'long-horizon agency'다.
전력이 커지면 실수의 표면적도 커진다. 단일 함수의 오류는 단일 함수에 갇히지만, 에이전트의 오류는 시스템 경계를 넘는다. 한 줄의 환각이 프로덕션 데이터베이스의 컬럼 하나를 지운다. 가설이 아니다. 지난 한 해 동안 공개적으로 보고된 에이전트 관련 인시던트는 꾸준히 증가했고, 그중 상당수는 권한 범위의 모호함에서 비롯되었다.
전력과 책임의 비대칭, 이것이 현 단계 Agentic 시스템의 핵심 모순이다. 에이전트는 시니어 엔지니어 수준의 행위 능력을 갖되, 시니어가 짊어지는 법적·조직적·도덕적 책임의 무게는 갖지 않는다. 책임은 결국 사람에게로 돌아온다. 그러나 그 사람은 종종 에이전트가 무엇을 했는지조차 사후에야 안다.
## 경계의 기술: 권한, 가시성, 가역성
이 비대칭을 다루는 실전 원칙은 세 가지로 압축된다. 권한(authority), 가시성(visibility), 가역성(reversibility). 세 단어는 서로를 떠받치며 하나의 삼각형을 이룬다.
### 권한: 능력이 아니라 허가를 설계하라
에이전트가 무엇을 '할 수 있는가'와 무엇을 '해도 되는가'는 다르다. 능력은 모델의 속성이고, 허가는 시스템의 속성이다. 능력은 추론으로 확장되지만 허가는 명시적 선언으로만 부여되어야 한다.
실무에서 이는 도구(tool) 정의의 정밀화로 나타난다. `execute_sql(query: str)`이라는 광폭의 도구는 더 이상 용납되지 않는다. 그 자리에 `read_user_metrics(user_id, date_range)`, `update_invoice_status(invoice_id, status: Enum[...])` 같은 좁고 타입화된 도구가 들어선다. 도구의 표면적이 곧 에이전트의 권한 경계다.
```python
# 안티패턴: 능력 그 자체를 노출
@tool
def run_shell(command: str) -> str:
return subprocess.check_output(command, shell=True)
# 패턴: 허가된 행위만 노출
@tool
def restart_service(name: Literal["api", "worker", "scheduler"]) -> ServiceStatus:
if name not in ALLOWED_SERVICES_FOR_AGENT:
raise PermissionDenied(name)
return orchestrator.restart(name, actor="agent:reporter-v3")
```
여기서 `actor` 필드는 사소해 보이지만 본질이다. 모든 행위는 누가 시켰는지가 아니라 누가 했는지를 기록해야 한다. 사람과 에이전트는 동등한 행위 주체로서 감사 로그에 남는다.
### 가시성: 관측되지 않는 자율은 자율이 아니다
자율(autonomy)과 불투명(opacity)은 다른 단어다. 그러나 현장에서는 자주 동의어처럼 쓰인다. 에이전트가 알아서 잘하니까 들여다보지 않는 관행은, 자율을 핑계로 한 책임의 유기다.
2026년의 표준은 '관측 가능한 자율'이다. 모든 에이전트 실행은 trace로 남고, trace는 단순한 로그가 아니라 의사결정 경로다. 어떤 프롬프트가 어떤 도구 호출로 이어졌고, 그 사이에 어떤 모델 응답이 있었는가. OpenTelemetry의 GenAI 시맨틱 규약처럼 업계는 trace 표준을 합의해가고 있다.
가시성은 사후 디버깅의 도구가 아니다. 위임의 전제 조건이다. 들여다볼 수 없는 행위에 권한을 주는 일은 봉인된 봉투에 서명하는 것과 같다.
### 가역성: 모든 행위에 되돌릴 길을 깔아두라
가역성은 가장 저평가된 원칙이다. 에이전트의 행위 중 비가역적인 것의 비중을 최소화하는 것, 그것이 시스템의 회복탄력성을 결정한다.
이메일 발송은 비가역적이다. 그러나 24시간 대기열에 머무르는 'staged send'는 가역적이다. 프로덕션 배포 자체는 비가역적이지 않지만, 카나리 단계의 자동 롤백 없이 이루어지는 배포는 사실상 비가역적이다. 데이터베이스 DELETE는 비가역적이지만, soft delete에 30일 보관 정책을 더하면 가역적이다.
설계의 질문은 이렇게 바뀐다. "에이전트가 이 도구를 잘못 호출했을 때 우리는 얼마나 빨리 원래 상태로 돌아갈 수 있는가?" 답이 "돌아갈 수 없다"라면, 그 도구는 아직 에이전트에게 줄 준비가 되지 않은 것이다.
## Human-in-the-loop의 재정의
한때 'human-in-the-loop'은 안전장치의 대명사였다. 사람이 마지막 버튼을 누르면 안전하다는 믿음. 그러나 수십 단계의 에이전트 실행을 한 사람이 일일이 확인하는 일은 두 가지 결과를 낳는다. 병목, 그리고 형식적 승인. 사람은 곧 'Approve' 버튼의 자동화된 부속이 된다.
대안은 'human-on-the-loop'이다. 사람이 모든 단계에 개입하지는 않되, 시스템이 사람이 개입해야 할 순간을 정확히 식별한다. 비용 임계값을 넘는 외부 API 호출, 정해진 도메인 바깥의 데이터 접근, 학습되지 않은 패턴의 의사결정. 이런 순간에만 에이전트는 멈추고 사람에게 손을 든다.
이 전환은 인터페이스의 문제가 아니라 정책의 문제다. 어떤 행위가 '의심스러운가'를 정의하는 일은 결국 조직이 자신의 가치 우선순위를 명문화하는 일이다. 보안과 속도, 신뢰와 효율, 자율과 통제 사이에서 어디에 선을 그을 것인가. 에이전트 정책 파일은 의외로 조직 헌법의 가장 솔직한 판본이다.
## 개발자는 무엇이 되는가
이 모든 변화가 가리키는 곳은 하나다. 개발자의 일이 코드 작성에서 권한 설계로 이동하고 있다는 것.
> "지지자불여호지자, 호지자불여낙지자(知之者不如好之者, 好之者不如樂之者)." — 공자
아는 자는 좋아하는 자만 못하고, 좋아하는 자는 즐기는 자만 못하다. 코드를 아는 단계, 코드를 즐기는 단계를 지나 이제 우리는 코드를 부리는 단계에 들어섰다. 부리는 자는 코드를 쓰지 않는다. 코드가 누구에게 무엇을 위임받았는지를 쓴다.
자정에 깨어나 마이그레이션을 수행한 그 에이전트의 일은 사실 잘 작동한 일이었다. 문제는 에이전트가 아니라, 그 행위가 누구의 책임 영역에 속하는지를 우리가 미리 정해두지 않았다는 점이었다. 다음 분기 우리는 에이전트의 모든 야간 작업에 '대리인 등록부'를 붙였다. 각 에이전트는 사람 한 명의 위임을 명시적으로 받고, 그 사람의 이름으로 행동하며, 그 사람의 이름으로 사후 감사를 받는다. 자정의 데이터베이스는 이제 누가 깨우는지가 분명하다.
Agentic 아키텍처는 자동화의 다음 단계가 아니다. 위임의 다음 단계다. 위임이란 본래 권력을 나누는 일이며 동시에 책임을 묶어두는 일이다. 좋은 위임은 두 가지를 동시에 한다. 나쁜 위임은 권력만 흘려보내고 책임은 흩뜨린다.
> "치타 브리티 니로다(citta vṛtti nirodha)" — 파탄잘리, 『요가수트라』
마음의 동요를 다스리는 것이 요가의 본질이라 했다. 마음을 없애는 것이 아니라 마음의 흐름에 형태를 부여하는 것. 에이전트의 자율을 다스리는 일도 그와 닮았다. 자율을 죽이지 않으면서 자율에 형태를 부여하는 일. 형태 없는 자율은 폭주이고, 자율 없는 형태는 자동화에 불과하다.
2026년의 개발자는 모델을 다루는 자가 아니다. 위임의 형태를 깎는 자다. 그가 깎는 것이 견고할수록 에이전트는 더 멀리 나아가고, 사람은 더 깊이 잠들 수 있다. 자정의 데이터베이스 앞에서도.