🧠아마도 나는 그냥 이해를 못 하는 걸까!

Source: Dev.to

낙관적인 방 안에서 회의론자가 되는 불편한 느낌

나는 AI와 꽤 오래 일해왔다—깊게 파고들고, 제품에 모델을 탑재하고, 새벽 3시에 로그를 보며, 뭔가 이상한 일이 생기면 사용자에게 사과한다. 그런데 매번 이런 글을 보면:

“자율 에이전트가 당신의 비즈니스를 대신 운영할 겁니다.”

머리 속에 조용하고 불편한 목소리가 들린다:

“아마도 내가 이해를 못 하는 걸지도 몰라.”

모두가 자신 있게 이렇게 말한다:

• 모델을 도구 레이어에 연결하고
• 몇 개의 프롬프트로 감싸고
• API를 호출하게 하면

그것이 “운영을 수행한다” 혹은 “회사를 관리한다”는 식이다.

그 사이 나는 거의 지루할 정도로 기본적인 질문을 던진다:

• 우리는 정말 이에게 중요한 의사결정에 대한 실질적인 권한을 주고 있는가?
• 우리의 제어 표면은 정확히 무엇인가?
• 예상치 못한 방식으로 실패하면 어떻게 되는가?
• prompt = governance 라고 정말 생각하는가?

내 안의 한 부분은 내가 너무 조심스럽고, 구식이며, “엔지니어링 뇌”에 머물러 있다고 걱정한다. 세상은 더 유동적이고 확률적인 방향으로 변하고 있다. 또 다른 부분은 이렇게 생각한다:

“아마도 누군가는 프롬프트가 제어가 아니라는 것을 크게 말해야 할 것이다.”

그래서 여기 내 시도—반은 고백, 반은 기술적 불평, 전부는 자기 회의다.

프롬프트는 제어처럼 보이지만, 실제는 아니다

프롬프트를 작성하면 정책을 쓰는 느낌이 든다:

You are an operations assistant. You always follow company policy.
You never issue a refund above 200 EUR without human approval.
You always prioritize customer safety and data privacy.

마치 규칙 집합, 작은 사양처럼 보인다. 하지만 실제로는 자연어 텍스트를 통계 모델에 조건으로 넣는 것일 뿐이다. 이 모델은:

• 그 단어들이 반드시 지켜질 것이라는 엄격한 보장이 없음
• “정책”이나 “위반”이라는 개념이 내장돼 있지 않음
• 결정론적인 실행 경로가 없음
• 하나의 잘못된 행동이 미칠 “폭발 반경”을 인식하지 못함

텍스트를 주면 모델은 텍스트를 반환한다. 제어감은 시스템이 아니라 사용자에게서 온다. 모델은 그 지시가 신성하다는 것을 “알” 수 없으며, 단지 가중치 안에 있는 패턴—“입력이 이렇게 보이면, 이런 텍스트가 자주 뒤따른다.”—만을 인식한다. 이 두 사이의 간극이 바로 위험이 도사리는 곳이다.

소프트웨어 시스템에서 실제 제어가 어떻게 보이는가

AI 과대광고를 제쳐두고 백엔드 엔지니어처럼 생각한다면, “제어”는 언제나 다음과 같은 것들을 의미한다:

권한

• 어떤 정체가 언제, 어디서, 얼마나 자주 할 수 있는가

경계

• 네트워크 구역, 방화벽, 읽기 전용 vs. 읽기‑쓰기 접근, 속도 제한

감사 가능성

• 누가 언제 어떤 매개변수로 무엇을 했는가

되돌릴 수 있음

• 이 작업을 되돌릴 수 있는가? 백업에서 복구할 수 있는가?

제약 및 불변식

• 계좌 잔액은 절대 음수가 될 수 없다
• 주문은 항상 유효한 사용자 ID와 제품 ID를 가져야 한다
• 이 서비스는 초당 X 이상의 업데이트를 푸시할 수 없다

그 위에 우리는 다음을 겹친다:

• 모니터링
• 알림
• 대체 경로
• 킬 스위치
• 변경 관리

지루하고 매력적이지 않지만, 바로 이런 것이 심각한 시스템이 붕괴되지 않게 만든다.

이제 AI 에이전트의 “제어”와 비교해 보자:

• “우리는 모델을 안전하도록 프롬프트로 감쌌다.”
• “우리는 ‘확신이 서지 않으면 인간에게 물어라’는 메시지를 추가했다.”
• “우리는 몇 가지 도구를 설정하고 에이전트가 어느 것을 호출할지 결정하게 했다.”

두 세계 사이에는 거대한 간극이 있다. 나는 스스로에게 계속 묻는다:

“AI 자동화에 동일한 엄격함을 요구하는 것이 과잉 반응인가?
아니면 인터페이스가 너무 친절하고 출력이 너무 유창해서 우리가 집단적으로 과소 반응하고 있는가?”

프롬프트 기반 제어가 취약한 이유

비결정론

같은 모델에 같은 프롬프트와 온도 0.7을 10번 호출하면:

• 약간씩 다른 추론 체인
• 가끔은 매우 다른 답변
• 때때로 드물지만 치명적인 실패 모드

채팅 환경에서는 이런 변동성이 허용될 수 있지만, 출력이 다음과 같은 경우는 그렇지 않다:

• 환불을 승인하거나 거부한다
• 컴플라이언스 이슈를 에스컬레이션할지 결정한다
• 중요한 고객에게 이메일을 보낸다

프롬프트에만 “정책”이 있다면, 토큰 경로가 이상해질 때 모델이 무작위로 벗어날 수 있다.

컨텍스트 희석 및 지시 충돌

복잡한 에이전트 설정에서는 모델의 컨텍스트가 대략 다음과 같다:

System messages ("You are X")
Task instructions
Tool specs
History, previous steps, errors
User messages
Tool responses

신중히 작성한 안전 지시는:

• 컨텍스트 깊숙이 묻혀버릴 수 있다
• 이후 메시지에 의해 가려질 수 있다
• 도구 설명과 충돌할 수 있다
• 사용자 입력과 이상하게 상호작용할 수 있다

어떤 지시가 모델 내부 가중치에서 승리할지 확신할 수 없으며, 가장 중요한 부분이 충분히 크게 들리길 바랄 뿐이다.

분포 이동 및 이상한 엣지 케이스

모델은 정적인 데이터로 학습된 뒤:

• 변화하는 제품
• 변하는 사용자 행동
• 새로운 비즈니스 프로세스
• 영리한 사용자의 적대적 입력

에 투입된다. 내부 테스트에서 관찰한 것은 형식적인 보장이 아니라, 일부 샘플 조건에서 “충분히 잘” 동작했다는 증거일 뿐이다. 하나의 이상한 엣지 케이스가 큰 문제를 일으킬 수 있다.

근거가 없는 상태와 형식적 규칙 부재

전통적인 시스템은 명시적인 상태 머신과 규칙을 가지고 있어 형식화, 증명, 혹은 최소한 추론이 가능하다. AI 에이전트는 보통 다음이 부족하다:

• 환경에 대한 형식적인 내부 모델
• 증명 가능한 의사결정 과정
• 구성 가능한 보장

실제 제어를 원한다면 모델 내부가 아니라 주변에 제어를 구축해야 한다. 그렇다면 왜 많은 사람들이 그 부분을 건너뛰는가? 라는 질문이 떠오른다.

세 가지 A: 자동화, 자율성, 권한

마케팅이 흔히 혼합하는 세 개념을 구분하면 도움이 된다.

자동화

우리가 수십 년간 해온 일:

• 크론 잡
• 스크립트
• 파이프라인
• 데몬

자동화는: “이 특정 루틴 단계가 기계에 의해 처리된다.” 라는 의미다.

(자율성 및 권한에 대한 논의는 원본 강연에서 이어진다.)