에이전트는 언제나 첫날 채용입니다. 이제 우리는 이를 위해 설계해야 합니다.

2027년까지 74%의 기업이 어느 정도든 에이전트를 사용할 것으로 예상된다고 최근 Deloitte 연구가 밝혔습니다. 수년간 우리는 인간이 앱, 웹사이트, 운영 체제 및 문서를 탐색하는 경험을 개선하기 위해 소프트웨어를 설계하고 구축해 왔습니다. 이제 사용자는 전혀 인간이 아닙니다. 이는 인간 작업을 위한 대시보드와 제어된 워크플로우를 전환하는 것 이상의 의미를 가집니다. 우리는 에이전트의 운영 환경을 설계해야 하는 순간에 와 있으며 또한 인간 워크플로우를 설계해 이러한 환경 내에서 에이전트 경험을 효과적으로 안내해야 합니다.  

우리는 아직 에이전트가 반복적이고 신뢰성 있게 성공하기 위해 우리에게 실제로 무엇이 필요한지 배우는 초기 단계에 있습니다. 본능적으로 에이전트 통합을 단순히 프롬프트나 UI 문제로 여기곤 합니다. 잘 관리되는 실행 환경을 설계하는 것은 우리 문화에 새로운 영역입니다. 그러나 좋은 설계와 좋은 관리의 근본 원칙은 변하지 않았습니다: 우리는 에이전트에게 명확한 컨텍스트, 모호함 없는 방향성, 그리고 명시적인 의도를 제공해야 합니다.

맥락: 코딩이 먼저인 이유

우리가 에이전트가 의도한 수준으로 반복적으로 제공하기를 원한다면, 맥락은 아마도 가장 중요한 입력일 것입니다. 소프트웨어 개발은 거의 모든 분야보다 더 많은 맥락을 기록하고 있습니다: 저장소, API 스키마, 시스템 간 관계, 코드 리뷰 및 커뮤니티 토론 등. 따라서 AI 최전선 연구소들이 코딩부터 시작한 것은 자연스러운 일입니다. 이는 이미 상당한 양의 맥락이 문서화된 몇 안 되는 분야 중 하나입니다.

하지만 소프트웨어 팀의 새로운 직원이 말하듯이, 그 모든 데이터가 있더라도 에이전트는 아무도 문서화하지 않은 암묵적인 규칙에 내재된 조직 기억이 부족합니다. 그 격차는 널리 퍼져 있습니다: 개발자 중 43%는 AI 도구가 특정 프로젝트나 코드베이스에 대한 충분한 맥락이 부족하다고 우려합니다. 암묵적 지식은 특정 작업에 선호되는 라이브러리와 같은 일상적인 관습부터, 늦은 밤에 영원히 남아 있는 핫픽스, 겉보기에 비어 보이지만 실제로는 맞춤형 수익 보고서를 뒷받침하는 데이터베이스 컬럼 등 고위험 운영 유령에 이르기까지 모든 것을 포괄합니다. 이러한 맥락은 선임 엔지니어의 머리 속, 최근 Slack 스레드, 혹은 전혀 존재하지 않을 수도 있습니다. 코드베이스 자체에 기록되는 경우는 드뭅니다.  

만약 소프트웨어와 같이 가장 잘 문서화된 분야에서도 이런 상황이라면, 다른 많은 산업에서 에이전트가 첫날부터 효과적으로 수행하기 어려운 이유를 쉽게 이해할 수 있습니다. 의료와 법률 분야에서는 일상 업무를 형성하는 조직 지식의 대부분이 학습되고 내면화됩니다. 이는 공식 문서가 아니라 사람들의 경험에 살아 있습니다. 법률 에이전트는 특정 파트너가 선호하는 구조, 어조, 혹은 브리프 작성 방식에 대해 모를 수 있고, 의료 에이전트는 바쁜 클리닉이 임상의 주도 삼중 검진을 지원하기 위해 사용하는 지역 워크플로우와 에스컬레이션 관행을 이해하지 못할 수 있습니다. 문서만으로는 그 격차를 메울 수 없습니다. 문제는 단순히 정보에 접근하는 것이 아니라 맥락을 전달하는 것이기 때문입니다. 에이전트가 성공하기 위해 필요한 것을 제공하려면, 우리는 신입 직원에게 온보딩하는 방식과 동일하게 에이전트를 온보딩해야 합니다.

방향: 삼투가 작동하지 않는 이유

새로운 팀원을 온보딩하는 데는 적절한 자료와 접근 권한을 제공하는 것 이상이 필요합니다. 우리가 주변 사람들의 성공에 투자할 때, 우리는 새로운 자료와 접근 권한을 어떻게 활용해야 하는지에 대한 확고한 방향성을 제공합니다: 기대치, 우리가 달성하려는 목표에 대한 명확성, 그리고 진행 과정에서의 피드백. 저는 이 사고방식을 에이전트를 설계하는 데에도 적용합니다. 저는 작업에 직접 관련된 명확하고 구체적인 방향을 제시합니다. 이는 근속 기간에 관계없이 모든 팀원에게 적용됩니다. 그러나 신입 직원 상황에서는 방향성이 더 필요합니다. 왜냐하면 그들은 아직 조직의 맥락을 전혀 가지고 있지 않기 때문입니다.

에이전트를 절대 새로운 직원처럼 생각해 보세요. 에이전트는 열정적이고 유능하며(솔직히 말해 무한한 에너지를 가지고 있습니다), 하지만 사람처럼 시간이 지나면서 암묵적인 규칙을 습득하고 유지하지 못합니다. 인간은 삼투와 경험을 통해 배우지만, 에이전트는 작업 환경에 명시적으로 구축된 아키텍처를 통해 학습합니다.

신입 직원과는 시간이 지나면서 질문, 피드백, 그리고 조직 프로세스와 선호도에 대한 새로운 통찰을 통해 그 격차를 메울 수 있습니다. 실제 커피 머신에서의 대화나 팀 점심과 같은 방식이죠. 에이전트와는 그 격차 메우기를 설계 자체에 포함시켜야 합니다. 이는 다음과 같은 방법을 포함할 수 있습니다: 

• 에이전트에게 지속 가능한 규칙, 작업별 사실, 관련 이력을 구분하는 구조화된 컨텍스트 창을 제공하여, 문서 무더기를 그대로 넘겨주는 것이 아니라 명확히 구분합니다. 
• 권한과 의사결정 경계를 사전에 정의합니다: 에이전트가 독립적으로 수행할 수 있는 일, 승인이 필요한 일, 절대로 접근해서는 안 되는 일 등을 명시합니다. 
• 강력한 출력의 구체적인 예시를 경험에 직접 삽입하여, 에이전트가 작업 수행 방식에 대한 명확한 모델을 갖도록 합니다.
• 지금까지 마주쳤던 실패 사례를 공유합니다.

잘 관리되는 에이전트 환경을 설계하는 것은 모델의 작업을 쉽게 만드는 것이 아니라, 인간 엔지니어링 팀을 보이지 않는 기술 부채로부터 보호하는 것입니다. 그러나 방향성이 잘 잡힌 에이전트라도 지시를 완벽히 따르면서도 핵심을 놓칠 수 있습니다. 방향성은 무엇을 해야 하는지를 알려주지만, “좋은” 것이 어떤 모습인지 알려주지는 않습니다. 그 격차가 바로 의도가 필요한 부분입니다.

의도: 에이전트가 중간으로 흐르는 이유

에이전트는 방대한 지식으로 훈련된 패턴 매칭 기계이며, 통계적 평균을 제공하도록 자연스럽게 설계되었습니다. 명확하고 명시적인 의도가 없으면, 그 평균 출력이 바로 에이전트가 반환하는 결과가 됩니다. 예를 들어 에이전트에게 “사용자 인증 엔드포인트를 추가하라”고 요청하면, 교과서적인 Express 라우트를 기본 비밀번호 해싱과 함께 생성합니다. 이는 동작하지만 팀의 맞춤형 인증 서비스는 무시하고, 필요한 텔레메트리를 생략하며, 표준화된 오류 포맷을 깨뜨립니다. 문서상으로는 적절한 기능일 수 있지만, 상황에 따라 실제로는 아키텍처 버그가 됩니다. 이런 “버그”가 도입되는 쉬운 정도는 과소평가될 수 없습니다.

이를 방지하려면 방향성에 적극적인 의도 검증 및 로깅을 결합해야 합니다. 가드레일은 코드가 컴파일되는지 여부만 확인하면 안 되며(이는 중요합니다), 가드레일은 일반적인 출력을 프로덕션 수준 작업으로 끌어올리는 의견 기반 표준, 엣지 케이스 규칙, 도메인 컨텍스트를 명시적으로 강제해야 합니다. 로깅은 인간에게 시스템 상태 지표로서 중요합니다. 이러한 추적 가능성은 신뢰에 필수적입니다. 

인간 간 상호작용에는 불확실성을 위한 여지가 많습니다. 누군가가 첫 번째 버전을 공유하면, 함께 강점과 개선점에 대해 논의할 수 있습니다. 이는 우리가 인간 동료가 자율적인 기계가 되기를 기대하지 않기 때문에 작동합니다. 에이전트 동료의 힘과 가능성을 진정으로 포착하려면(우리는 더 자율적으로 운영될 필요가 있습니다…), 이러한 방향성 검사를 많이 설계할 수 있습니다. 왕복 과정은 여전히 필요하지만, 전적으로 수동 노력에만 의존할 수는 없습니다. 명확한 수용 기준과 검증 규칙을 앞에 배치함으로써, 에이전트가 자체 내부 피드백 루프를 실행하도록 할 수 있습니다. 오류 방지를 위한 설계는 이 새로운 세계에서 적용할 수 있는 또 다른 건전한 UX 원칙입니다: 에이전트가 행동을 확정하기 전에 낮은 신뢰도를 표시하도록 함으로써, 최선의 추측으로 조용히 기본값을 선택하는 대신 경고를 제공하게 합니다.

비유가 깨지는 곳

신입 직원 프레이밍은 작동하지만, 언제든 한계에 부딪힙니다. 인간 직원을 고용하면 경험이 역량을, 역량이 판단을 낳습니다. 신입 직원이 컨텍스트와 방향성 뒤에 숨은 “왜”를 내면화하는 모습을 지켜보는 것이 시간이 지남에 따라 신뢰를 쌓는 과정이며, 일반적으로 이는 누적됩니다. 에이전트는 이러한 경험을 축적하고 저장할 장소가 없습니다.

신입 직원의 첫 주와 백 번째 주는 서로 다르게 보입니다. 에이전트의 첫 번째 작업과 천 번째 작업은 설계와 구축을 통해 다르게 만들지 않는 한 동일하게 보입니다. 이것이 우리의 새로운 설계 과제입니다.

에이전트 책임은 설계에 달려 있다

책임이 에이전트 자체에 존재할 수 없다면, 그 주변의 골조에 존재해야 합니다. 이는 제가 새로운 직원을 맡기기 전에 항상 묻는 세 가지 질문과 동일합니다: 그들은 어떤 컨텍스트를 가지고 있는가? 어떤 방향성을 제공했는가? 실제 의도는 무엇인가?

다음에 에이전트에게 작업을 맡길 때는 결과만 확인하지 마세요. 먼저 자신의 입력을 점검하십시오. 신입 직원이 첫날에 필요로 하는 컨텍스트를 제공했는가? 방향성이 문자 그대로 해석되어도 견딜 만큼 구체적이었는가? 의도가 충분히 명확해서 “중간 답변”이 최선이 아니었는가?

이러한 명확한 가이드를 손에 넣으면(바이트 단위로?), 흥미로운 일이 일어납니다: 에이전트는 신뢰를 얻기 위해 긴 시간의 러닝 커브가 필요하지 않습니다. 앞서 구축한 컨텍스트, 방향성, 검증이 에이전트가 모든 작업을 수행하는 방식을 정의합니다. 신입 직원은 시간이 지나면서 신뢰를 얻지만, 에이전트는 설계한 시스템을 통해 매번 신뢰를 얻어야 합니다. 책임은 성장해서 얻어지는 것이 아니라 처음부터 내재된 것입니다. 질문은 에이전트가 언제 더 큰 책임을 맡게 될지가 아니라, 모든 작업에서 그 책임을 얻도록 설계했는가 입니다.