지금 하는 일에서 AI를 얼마나, 그리고 어떻게 쓰고 있는가? 요즘은 프롬프트, 에이전트, 컨텍스트, 하네스 같은 용어를 이제 개발자만 쓰지 않는다. 기획자도, 디자이너도, 운영 조직도 AI를 “어떻게 붙일지”를 이야기한다. 겉으로 보면 AI는 이미 모두의 도구가 된 것처럼 보인다.

그런데 정작 현장에서 벌어지는 일은 조금 다르다. 많은 조직이 아직도 AI를 “답변을 잘 뽑아주는 도구” 정도로 다룬다. 좋은 프롬프트를 쓰는 사람이 앞서고, 모델을 빨리 바꿔 쓰는 사람이 유리하다고 생각한다. 하지만 에이전트가 본격적으로 업무에 들어오면, 경쟁력의 축은 전혀 다른 곳으로 이동한다. 중요한 것은 더 이상 한 번에 더 좋은 답을 뽑는 능력이 아니다. 일을 기계가 다룰 수 있는 단위로 쪼개고, 기준을 명시하고, 실패를 되돌릴 수 있게 설계하는 능력이다.

에이전트는 단순한 챗봇이 아니다. 문서를 읽고, 코드를 바꾸고, 툴을 호출하고, 결과를 다시 평가해 다음 행동을 선택하는 실행 주체다. 이 말은 곧, AI를 잘 쓴다는 것이 “질문을 잘하는 사람”에 머무르지 않는다는 뜻이다. 이제는 AI와 사람이 함께 일해도 무너지지 않는 구조를 설계하는 사람이 오래 살아남을 것이다.

이 글의 핵심은 하나다. 에이전트 시대의 승부처는 모델 이해가 아니라 업무 설계다. 누가 더 멋진 프롬프트를 쓰느냐보다, 누가 더 나은 작업 단위와 검증 루프를 만들 수 있느냐가 훨씬 중요해진다.

AI Agent의 등장은 무엇을 바꾸는가

AI Agent의 등장은 생산성을 올린다. 하지만 더 정확히 말하면, 생산성의 병목을 이동시킨다. 예전에는 결과물을 만드는 실행력이 중요했다면, 이제는 생성보다 검증, 작성보다 조율, 개인 숙련보다 시스템 설계가 더 중요해진다. 에이전트는 많은 일을 빠르게 처리할 수 있지만, 동시에 그럴듯하게 틀릴 수도 있다. 그래서 에이전트를 잘 쓰는 조직은 “무엇을 자동화할 것인가”보다 “어디서 멈추고, 어떻게 검증할 것인가”를 먼저 설계한다.

실제로 바뀌는 것은 업무의 단위다. 과거의 자동화가 정해진 규칙을 코드로 옮기는 일이었다면, 에이전트 기반 자동화는 애매한 문맥과 예외를 포함한 채 일을 진행한다. 이때 중요한 것은 모델 자체보다 그 모델이 의존하는 환경이다. 컨텍스트는 단순히 긴 프롬프트가 아니라, 무엇이 최신 정보인지, 어떤 문서가 기준인지, 어떤 툴을 호출할 수 있는지, 어떤 경우에 중단해야 하는지를 포함한 운영 환경 전체다. 하네스는 그 환경을 안전하게 반복 실행하게 만드는 장치다.

예를 들어, 플랫폼 팀이 수백 개 저장소의 설정 파일을 새 표준으로 마이그레이션한다고 해보자. 에이전트는 저장소 구조를 읽고, 필요한 수정 사항을 판단하고, PR까지 만들 수 있다. 하지만 어떤 저장소를 대상에 포함할지, 얼마나 큰 diff를 허용할지, 반드시 통과해야 할 테스트는 무엇인지, 예외 케이스는 누구에게 넘길지, 실패 시 어떻게 롤백할지를 정해두지 않으면 이 작업은 금방 PR 스팸이 된다. 결국 생산성을 가르는 것은 “더 빨리 쓰는 능력”이 아니라, 그 작동 조건을 설계하는 능력이다.

또 하나 드러나는 것은 암묵지의 한계다. 사람은 “이 서비스는 원래 이렇게 다뤄야 한다” 같은 구두 규칙으로도 어떻게든 협업하지만, 에이전트는 그런 문맥을 일관되게 따르지 못한다. 그래서 문서화가 약하고, 기준이 사람마다 다르고, 예외 규칙이 정리돼 있지 않은 조직일수록 에이전트를 붙였을 때 혼란이 더 커진다.

결국 AI Agent의 등장은 “일을 대신 해주는 똑똑한 도구”의 추가가 아니라, 일을 설계 가능한 형태로 바꾸라고 요구하는 변화에 가깝다. 잘 정리된 조직은 레버리지를 얻고, 정리되지 않은 조직은 혼돈이 증폭된다.

실무자는 무엇을 세팅해야 하는가?

일을 잘게 나누고, 기준을 명시하고, 검증 루프를 설계하기

그러면 실무자는 무엇부터 해야 할까? 실무자가 가장 먼저 해야 할 일은 자기 일을 어떤 상태 전이의 묶음으로 볼 수 있는지 정의하는 것이다. 말하자면 “내 업무를 API처럼 설명할 수 있는가”가 핵심이다. 입력은 무엇이고, 필요한 맥락은 무엇이며, 출력은 어떤 형식이어야 하고, 어느 조건에서 실패로 간주해야 하는지 설명할 수 있어야 한다.

이때 일을 나누는 기준은 조직도나 직무명이 아니라, 가역성과 관측 가능성이다. 되돌리기 쉽고 결과를 확인하기 쉬운 일은 에이전트에게 많이 맡길 수 있다. 예를 들어, 포맷팅, 테스트 코드 초안 작성, 규칙 기반 리팩토링, 문서 정리 같은 작업은 비교적 안전하다. 반대로 되돌리기 어렵거나 결과를 바로 검증하기 어려운 일, 예컨대 운영 환경 설정 변경, 고객 커뮤니케이션의 최종 발송, 보안 정책 예외 승인 같은 일은 반드시 사람 승인이나 추가 검증이 필요하다. 문제는 많은 팀이 이 구분 없이 “일단 붙여보자”는 식으로 접근한다는 점이다. 그러면 자동화는 늘어나는데 신뢰는 쌓이지 않는다.

우리가 사람들로 이루어진 조직에서 일을 할 때 생각해보면 팀장과 팀원이 있을 때 처음에 팀장이 일을 받아온다. 팀장은 팀원들의 업무 이해도나 숙련도를 종합적으로 판단해서 업무를 분배하고 기간을 조율한다. 그러면 팀원들은 그 업무를 받아서 수행하고 중간중간 팀장은 팀원들이 막히는 영역을 같이 해결해 준다. 그렇게 팀원들이 각자에게 주어진 업무를 완료하면 팀장은 종합해서 본인의 상사에게 보고한다. 이러한 흐름을 팀장 = 실무자, 팀원 = 에이전트가 하는 것이라고 생각하면 이해가 쉬울 것이다.

기준을 명시하는 것도 중요하다. 대부분의 실패는 에이전트가 멍청해서 생기지 않는다. 성공 조건이 애매해서 생긴다. “좋은 코드로 바꿔줘”는 지시가 아니다. 성능 회귀가 없어야 하는지, 공개 API 호환성을 유지해야 하는지, 마이그레이션 비용을 최소화해야 하는지, 테스트 커버리지를 유지해야 하는지, 로깅 정책을 따라야 하는지가 빠져 있다면 에이전트는 결국 가장 손쉬운 지역 최적화로 흘러간다.

예를 들어, PR 리뷰 에이전트를 생각해 보자. 많은 팀이 이런 시도를 한다. 그런데 대개 초기에 받는 평가는 비슷하다. “말은 많은데 도움이 안 된다.” 이유는 간단하다. 리뷰 기준이 없기 때문이다. 스타일 잔소리를 할지, 동시성 문제를 볼지, 데이터 무결성 리스크를 볼지, API 변경의 파급 범위를 볼지 기준이 없으면 에이전트는 가장 표면적인 문제만 건드린다.

반대로 리뷰 기준을 “보안, 동시성, 마이그레이션 리스크, 외부 인터페이스 영향, 테스트 누락” 같은 축으로 명시하고, 각 축마다 어떤 근거를 제시해야 하는지 정해두면 에이전트의 품질은 급격히 달라진다. 중요한 것은 답변의 문장력이 아니라, 판단의 프레임이 구조화되어 있는지다.

검증 루프는 더 중요하다. 여기서 많은 팀이 흔히 빠지는 함정이 있다. 같은 모델에게 “다시 확인해봐”라고 시키는 것을 검증이라고 착각하는 것이다. 하지만 자기 자신에게 채점하게 하는 것은 검증이라기보다 자기합리화에 가깝다. 좋은 검증 루프는 생성기와 독립적이어야 한다. 정적 분석기, 테스트 스위트, 샌드박스 실행, 시뮬레이션, 스키마 검증, 정책 룰 엔진, 휴먼 리뷰처럼 다른 종류의 체크포인트가 필요하다.

장애 대응에서도 이 차이는 분명하게 드러난다. 에이전트에게 “장애 원인을 찾아봐”라고 하면 로그를 읽고, 최근 배포를 찾고, 메트릭 변화를 요약하고, 가능한 가설을 정리하는 데는 꽤 유용하다. 하지만 바로 롤백이나 설정 변경까지 맡기면 위험해진다. 잘 되는 팀은 런북을 서술형 문서가 아니라 의사결정 트리처럼 관리한다. 어떤 증상이 보이면 어떤 증거를 먼저 수집하고, 어떤 조건이 충족될 때만 롤백 후보를 제안하며, 어느 선을 넘으면 반드시 당직자가 승인하게 할지를 명시한다. 이 구조 안에서 에이전트는 “판단의 대체자”가 아니라 “관찰과 정리의 가속기”가 된다. 바로 이 지점이 실무적이다. 좋은 팀은 에이전트에게 자율성을 주기 전에, 먼저 실패 반경을 줄인다.

또 하나의 실무 포인트는 컨텍스트를 덜어내는 능력이다. 많은 사람이 컨텍스트 엔지니어링을 “관련 자료를 최대한 많이 넣는 일”로 이해한다. 하지만 실제로는 반대다. 많이 넣는 것보다, 충돌하지 않게 넣는 것이 어렵다. 낡은 문서와 최신 정책이 함께 들어가 있고, 예외 규칙이 본문 어딘가에 buried 되어 있고, 동일한 개념이 팀마다 다른 이름으로 쓰이면 에이전트는 높은 확률로 그럴듯한 혼합물을 만든다. 실무자가 해야 할 일은 지식을 더 많이 넣는 것이 아니라, 기준이 되는 지식을 더 작고 더 선명하게 만드는 일이다.

이 글을 쓰는 시점(2026년 4월)에서 Claude Opus 4.7 모델이 가장 최신인데, 한 번에 1M 토큰까지 컨텍스트를 기억할 수 있다. 그런데 우리가 점점 복잡한 작업을 하다 보면 이 한계치는 생각보다 금방 도달하게 된다. 그렇기 때문에 컨텍스트를 1M 이내에서 적절하게 넣고, 요약하고, 새로운 대화로 옮겨서 이어가는 등의 전략을 사용하는 것이 중요하다.

요약하면, 개인이 에이전트 시대에 세팅해야 할 역량은 세 가지다. 일을 잘게 나누는 분해력, 성공과 실패를 명시하는 명세력, 결과를 믿을 수 있게 만드는 검증 설계력이다. 프롬프트 감각은 그 다음 문제다.

팀과 리더는 무엇을 설계해야 하는가?

도입보다 중요한 공통 설정과 운영 체계

개인이 AI를 잘 쓴다고 조직 전체가 잘 굴러가지는 않는다. 에이전트가 팀 단위로 들어오는 순간, 누구의 문서를 기준으로 삼을지, 어떤 데이터에 접근할지, 잘못된 행동을 누가 감시할지 같은 운영 문제가 함께 생긴다. 이걸 개인 재량에 맡기면 팀은 금방 “AI를 쓰는 사람”과 “AI가 만든 결과를 뒷수습하는 사람”으로 갈라진다.

그래서 리더가 가장 먼저 설계해야 할 것은 공통 컨텍스트 레이어다. 용어 사전, 시스템 경계, API 계약, 운영 정책, 보안 규칙, 예외 승인 절차가 흩어진 위키 문서로 존재해서는 안 된다. 에이전트가 읽을 수 있고 사람도 신뢰할 수 있는 형태로 정리돼야 한다. 결국 조직의 AI 경쟁력은 모델보다 내부 문서의 정합성에서 나온다. 어떤 문서가 최신인지, 같은 개념이 팀마다 다른 이름으로 불리지 않는지, 런북과 실제 운영 상태가 어긋나지 않는지가 기본기이자 레버리지다.

다음은 권한과 책임의 경계다. 무엇을 보여줄지보다 무엇을 못 하게 할지가 더 중요하다. 읽기와 쓰기 권한은 분리돼야 하고, 운영 변경은 샌드박스나 드라이런을 거쳐야 하며, 민감한 액션에는 승인 단계가 필요하다. 에이전트 운영은 똑똑함의 문제가 아니라 통제의 문제다. 실패는 종종 모델 한계보다 권한 설계 부실에서 나온다.

기존에 많은 팀에서 사용하는 RBAC(Rule Based Access Control)이나 OAuth 같은 인증, 권한 방식은 사람에게 적합한 방식이다. 예를 들어, CTO가 RBAC에서 최고 관리자 권한을 가지고 있어서 깃헙 레포지토리를 지우거나, 프로덕션 DB를 수정할 수 있다고 하더라도 사람은 그 행동을 일반적인 경우에 하지 않는다. 왜냐하면 그 행동이 위험하고 문제를 일으킬 수 있다는 것을 알기 때문이다.

하지만 에이전트는 최고 관리자 권한이 있다면 마음대로 레포지토리를 지우거나 프로덕션 DB 테이블을 수정할지도 모른다. 따라서 이러한 기존의 인증, 권한 방식도 에이전트 기반 워크플로에서는 다른 대안을 찾을 필요가 있다.

평가 체계도 필수다. 좋은 팀은 프롬프트보다 평가 셋을 공유한다. 어떤 요청에 어떤 응답이 나와야 하는지, 어떤 행동은 금지인지, 과거에 어디서 실패했는지를 축적한다. 이건 품질 관리가 아니라 회귀 테스트에 가깝다. 예를 들어 보안 취약점 triage를 자동화할 때 자산 중요도 기준, 예외 승인 규칙, 에스컬레이션 정책이 통일돼 있지 않으면 에이전트는 금방 신뢰를 잃는다. 반대로 이 기준들이 정리돼 있으면 업무량을 실제로 줄일 수 있다.

리더가 봐야 할 지표도 달라져야 한다. “몇 명이 AI를 쓰는가”보다, 에이전트 결과의 채택률, 수정 시간, 재오픈율, 롤백률, 리뷰 부담이 줄었는지를 봐야 한다. 팀과 리더의 역할은 AI를 도입하는 것이 아니라, AI가 들어와도 조직이 무너지지 않게 공통 설정과 운영 체계를 만드는 데 있다.

결국 살아남는 사람의 공통점

도구 사용자가 아니라 협업 환경 설계자

에이전트 시대에 오래 살아남는 사람은 AI를 가장 자주 쓰는 사람이 아니다. 오히려 AI와 사람이 함께 일할 때 어디서 마찰이 생기고, 어디서 오류가 커지며, 무엇을 미리 구조화해야 하는지 아는 사람이다. 이들은 도구 사용자가 아니라 협업 환경 설계자에 가깝다.

이런 사람들은 암묵지를 외부화한다. 자기만 아는 요령을 체크리스트, 예시, 금지 규칙으로 바꾼다. 예전에는 “감으로 안다”가 강점이었다면, 이제는 “그 감을 구조로 바꾼다”가 더 큰 강점이 된다. 또한 일을 설명할 때 자연어의 모호함에 기대지 않는다. 입력과 출력, 예외와 중단 조건, 책임이 넘어가는 지점을 분명히 한다. 에이전트를 잘 다루는 사람은 프롬프트 장인이 아니라 인터페이스 설계자다.

이들은 복구 가능성도 중시한다. 에이전트가 실수하지 않게 만드는 것만큼, 실수했을 때 빨리 되돌릴 수 있게 만드는 것을 중요하게 본다. 드라이런, 샌드박스, 작은 배치, canary, 롤백 스크립트, 승인 게이트에 집착하는 이유다. 에이전트 시대의 유능함은 정답을 많이 만드는 능력보다 오답의 비용을 낮추는 능력에 더 가깝다.

반대로 도태되기 쉬운 사람은 AI를 검색창의 연장선으로만 보고, 맥락 없는 결과물을 대량으로 만드는 데 만족하는 사람이다. “모델이 더 좋아지면 해결될 문제”라고 믿으며 기준과 운영 설계를 미루는 태도도 마찬가지다. 시간이 갈수록 커지는 것은 결과물의 양이 아니라 주변 사람들의 검토 비용이다. 결국 살아남는 사람은 AI를 잘 쓰는 사람이 아니라, AI가 잘 일할 수 있는 환경을 만드는 사람이다.

마치며

에이전트 시대의 경쟁력은 기술 이해가 아니라, 일의 방식을 재설계하는 능력이다. 모델 이름을 많이 아는 것, 프롬프트를 그럴듯하게 쓰는 것, 최신 기능을 빨리 시험해 보는 것만으로는 오래 가지 않는다. 진짜 차이는 일을 얼마나 기계가 처리할 수 있는 단위로 나누고, 얼마나 명확한 기준으로 정의하며, 얼마나 튼튼한 검증 루프로 감쌌는지에서 나온다.

에이전트는 엔지니어를 대체하기보다, 엔지니어링이 얼마나 구조화돼 있는지를 시험한다. 기준이 사람 머릿속에만 있고, 예외가 문서화되지 않았고, 검증이 개인의 감각에 의존하던 조직은 에이전트를 붙일수록 불안정해진다. 반대로 일의 경계가 분명하고, 실패가 기록되며, 시스템이 복구 가능하게 설계된 조직은 에이전트를 통해 폭발적인 레버리지를 얻는다.

그래서 지금 필요한 질문은 “AI를 쓸 것인가 말 것인가”가 아니다. “우리의 일은 에이전트와 협업 가능한 구조인가”다. 이 질문에 제대로 답할 수 있는 사람, 그리고 그 구조를 실제로 설계할 수 있는 사람이 결국 살아남는다.

에이전트 시대에 강한 사람은 도구를 능숙하게 쓰는 사람이 아니다. 사람과 AI가 함께 일해도 품질과 신뢰가 무너지지 않는 시스템을 만드는 사람이다. 앞으로의 경쟁력은 손이 빠른 사람보다, 기준을 세우는 사람에게 있다. 프롬프트를 잘 쓰는 사람보다, 실패를 설계하는 사람이 오래 남는다. 이 글을 읽는 모든 분들이 에이전트 시대에서 변화에 잘 적응하고 성장할 수 있길 바란다.