내가 처음으로 프로덕션(production)에 투입한 에이전트는 신입 사원처럼 대했다. 명확한 브리프(brief)를 주고, 처음 몇 개의 출력물을 확인한 뒤 깨끗하다는 것을 확인하고는 신뢰하기 시작했다. 약 2주가 지났을 때, 이 에이전트는 다운스트림(downstream) 작업을 망가뜨리는 설정 변경을 자신 있게 밀어붙였다. 에러도 없었고, 플래그(flag)도 없었다. 그저 조용히 다음 작업으로 넘어갔을 뿐이다.

그날 나는 지금 모두가 반복하고 있는 조언이 절반만 사실이라는 것을 깨달았다.

Ethan Mollick은 어제 "The Twilight of the Chatbots"를 발표하며 50만 명 이상의 독자들에게 에이전트를 사용하는 가장 좋은 방법은 자신을 관리자(manager)라고 생각하는 것이라고 말했다. 그는 이러한 변화에 대해 옳게 짚었다. 업무의 성격이 모델과 채팅하는 것에서, 몇 주 동안 스스로 실행되는 모델에게 작업을 맡기는 것으로 이동했다. 하지만 "관리자처럼 생각하라"는 말에는 조용히 하나의 가정이 숨어 있다. 바로 사람에게 사용하는 방식이 에이전트에게도 그대로 적용될 것이라는 가정이다. 하지만 대부분은 그렇지 않다.

여기서 나에게 통하지 않았던 네 가지 방식과, 대신 지금 내가 하고 있는 것들을 소개한다.

방식 1: 신뢰 곡선은 역방향으로 흐른다

사람의 경우, 신뢰는 복리로 쌓인다. 주니어 개발자는 코드 리뷰(code review)를 거치고, 그다음에는 더 가벼운 리뷰를 받으며, 결국 수백 번 증명되었기에 당신은 더 이상 확인하지 않게 된다. 역량은 축적된다.

하지만 에이전트는 매 실행(run)마다 신뢰를 다시 얻어야 한다. 어제의 깨끗한 출력물은 오늘의 출력물에 대해 거의 아무것도 알려주지 않는다. 왜냐하면 약간 다른 입력값에 대해 동일한 프롬프트(prompt)를 사용하더라도 당신이 테스트하지 않은 곳으로 엇나갈 수 있기 때문이다. 앞으로 이어지는 "수백 번 증명했다"는 개념은 존재하지 않는다. 당신은 에이전트를 "더 이상 확인할 필요가 없다"는 단계로 졸업시킬 수 없다.

도움이 된 사고방식의 조정: 나는 리뷰(review)를 에이전트가 성장하며 벗어나는 단계로 생각하는 것을 멈추고, 시스템의 영구적인 속성으로 취급하기 시작했다. 나는 이를 속도 제한(rate limits)이나 불안정한 네트워크(flaky network)처럼 취급한다. 팀원의 능력에 대한 평가가 아니라, 도구의 고정된 제약 사항으로 보는 것이다.

방식 2: 침묵은 진전이 아니다

사람을 관리할 때, 침묵은 대개 일이 잘 진행되고 있음을 의미한다. 유능한 보고자는 해결할 수 없는 문제에 부딪혔을 때 당신에게 알림을 보낸다. 질문이 없다는 것은 업무가 궤도에 올라와 있다는 약한 신호다.

에이전트(Agents) 또한 이 점을 역전시킵니다. 제가 사용한 에이전트는 사람이 멈춰서 질문했을 법한 지점을 그대로 지나쳐 버렸고, 아주 자신만만하게 수행했습니다. 저는 "오류가 발생하지 않음"을 "일을 올바르게 수행함"으로 해석했지만, 이 둘은 같은 의미가 아닙니다. 실패는 시스템 충돌(crash)이 아니었습니다. 그것은 망설임 없이 전달된, 그럴듯해 보이는 오답이었습니다.

그래서 저는 에이전트가 문제를 표면화하기를 기다리는 것을 멈추고, 제가 사람이 직접 확인하기를 가장 원했던 순간들에 계측(instrumenting)을 시작했습니다. 간단한 버전은 다음과 같습니다:

# 전체 테스트 스위트가 아닌, 체크인용 트립와이어 (tripwire)
tripwires:
  - when: "files_changed > 5"
...

이것들은 전혀 영리한 기술이 아닙니다. 핵심은 에이전트가 나에게 알려주기를 기대하는 대신, 내가 _언제 확인할지_를 미리 결정한다는 것입니다. 에이전트는 알려주지 않을 것입니다.

단계 3: 모든 작업에 대해 매번 범위를 재설정하라 (You re-scope every task, not once)

사람은 한 번만 온보딩(onboard)하면 됩니다. 그들은 팀이 어떻게 일하는지, 이곳에서 "좋은 결과물"이란 무엇인지, 어떤 지름길이 괜찮고 어떤 행동이 누군가를 호출(paged)하게 만드는지를 흡수합니다. 그 맥락(context)은 향후 모든 작업에 무료로 따라옵니다.

에이전트는 당신이 직접 메모리(memory)를 구축하지 않는 한, 작업 간에 그러한 맥락을 전혀 유지하지 못합니다. 각 할당(assignment)은 당신이 예상하는 것보다 훨씬 더 백지 상태(cold)에 가까운 지점에서 시작됩니다. 초기에는 우리 팀의 관례를 이미 알고 있는 사람에게 하듯 간결한 티켓(tickets)을 계속 작성했는데, 에이전트는 그 빈틈을 우리에게는 틀린, 하지만 그럴듯하게 들리는 추측들로 계속 채워 넣었습니다.

이제 공유된 맥락이 실제로 어딘가에 영구적으로 인코딩(encoded)될 때까지, 범위 설정(scoping)은 작업마다 이루어집니다. 초반에 더 많은 말을 해줄수록, 마지막에 마주할 놀라운 상황(surprises)은 줄어듭니다.

단계 4: 수정 사항은 기억하는 것이 아니라 기록되어야 한다

이것이 저에게 가장 많은 재작업(rework) 비용을 치르게 한 부분입니다. 사람에게 "우리는 X를 절대 하지 않는다"라고 한 번만 말하면 그들은 적응합니다. 그 수정 사항은 그때부터 그들의 머릿속에 남습니다.

에이전트에게 말하고, 해당 실행(run)에서 그것이 문제를 해결하는 것을 지켜본 다음, 다음 실행에서 똑같은 실수를 반복하는 것을 지켜보십시오. 피드백이 고착되지 않은 이유는 그것이 고착될 장소가 없었기 때문입니다. 수정 사항은 다음 실행에서 실제로 읽히는 프롬프트(prompt)나 가드레일(guardrail)에 존재할 때만 살아남습니다.

AGENTS.md

엄격한 규칙 (매 실행 시 읽을 것)

• generated/ 디렉토리 아래의 파일은 절대 수정하지 마십시오. 이 파일들은 빌드 결과물(build output)입니다.
  ...

만약 수정 사항이 다음 실행 시 로드되는 파일에 포함되어 있지 않다면, 당신은 아무것도 수정하지 않은 것입니다. 그저 에이전트가 한 번 그렇게 행동하는 것을 지켜본 것뿐입니다.

사고방식을 실행 가능하게 만드는 세 가지 움직임

Mollick은 수많은 청중에게 사고방식(mindset)을 전달했습니다. 그가 열어둔 부분은 방법론(method)이기에, 여기 제가 사용하고 있는 버전을 소개합니다.

첫째, '움직임 2'에서 언급된 '체크인 트리와이어(check-in tripwires)'를 확인하십시오. 작업이 끝난 후가 아니라, 작업이 시작되기 전에 확인해야 할 시점을 결정하십시오.

둘째, 노력(effort)을 관리적 결정(management call)으로 취급하십시오. Anthropic은 어제 Sonnet 5에 조절 가능한 노력 수준(adjustable effort levels)을 출시했습니다. 여기서 흥미로운 질문은 설정값이 아니라, 어떤 종류의 작업이 비용이 많이 들고 신중한 검토(careful pass)를 거칠 가치가 있느냐는 것입니다. 이는 작업에 시니어 엔지니어가 필요한지, 아니면 누구에게나 맡길 수 있는지를 결정하는 것과 같은 범위 설정(scoping) 결정입니다.

셋째, 작업을 할당한 후가 아니라, 할당하기 전에 '완료(done)'와 '에스컬레이션(escalate)'의 기준을 정의하십시오. 사람은 문맥(context)을 통해 이 두 가지를 추론할 수 있습니다. 하지만 에이전트는 둘 다 추론할 수 없습니다. 완료된 상태가 어떤 모습인지, 그리고 어떤 상황에서 작업을 멈추고 당신을 찾아와야 하는지를 글로 적을 수 없다면, 그 작업은 위임할 준비가 되지 않은 것입니다.

이 모든 과정을 더 쉽게 만들어주는 한 가지 요소는, 도구들이 '감사 가능한 산출물(auditable artifacts)', 즉 에이전트가 실제로 무엇을 했는지에 대한 내장된 기록(trail)이 포함된 작업 결과물을 내놓기 시작했다는 점입니다. 단순히 결과만 보는 대신 그 경로(path)를 읽을 수 있게 되면, 에이전트를 관리하는 일이 추측(guesswork)에 의존하는 일에서 훨씬 벗어날 수 있습니다.

그리고 이것은 곧 전문가만의 기술이 아니게 될 것입니다. Copilot은 오늘부로 M365 등급에 포함된 영구적인 SKU가 되었습니다. 이는 조직 전체가 에이전트를 요청했든 아니든 에이전트를 갖게 된다는 것을 의미합니다. "이런 것을 실제로 어떻게 관리하는가"라는 질문은 초기 수용자(early adopters)뿐만 아니라 모든 사람이 답해야 하는 질문으로 변하고 있습니다.

제가 논쟁하고 싶은 한 가지를 남기며 마치겠습니다. 이 네 가지 중 당신은 무엇을 가장 먼저 겪었습니까? 저의 경우는 '자신만만한 침묵(confident silence)'이었으며, 저는 여전히 그것을 완전히 해결했는지 확신하지 못합니다.

Tags: #AIAgents