업무용 AI 에이전트가 코딩 도구에서 배울 여섯 가지

코딩과 영업은 출발점부터 다릅니다

코딩 에이전트가 코드를 수정하면 테스트로 오류를 확인하고, 문제가 생긴 변경은 Git으로 되돌릴 수 있습니다. 병합하기 전에 사람이 리뷰하는 절차도 흔합니다. 같은 종류의 모델을 영업 업무에 쓰면 출발점부터 다릅니다. 고객 기록은 Salesforce, 문서는 Notion, 메일은 Gmail, 대화는 Slack, 지원 이력은 Zendesk에 있고, 로그인도 제각각입니다. 에이전트가 손대기 전에 흩어진 정보를 스스로 모아야 합니다.

Composio 공동창업자 겸 CTO인 카란 바이디아(Karan Vaidya)는 이 차이를 AI Engineer 채널이 2026년 9월 3일 공개한 컨퍼런스 강연에서 설명합니다. 그가 말하는 지식 업무는 영업, 채용, 고객 지원처럼 코드를 짜지 않는 사무 업무입니다. 그는 정보를 한곳에 모으는 일, 변경 이력, 업무의 구조와 기준, 결과 검증, 프롬프트 밖의 권한 통제, 되돌리기를 여섯 가지로 묶습니다. 자기 회사가 만드는 인프라의 관점에서 말하는 강연입니다.

• 원본 강연 보기
• 한국어 업로드 (Tech Bridge)

모델 바깥의 작업 환경

바이디아는 먼저 모델이 좋아진 것과, 그 발전을 실제로 쓸 수 있게 하는 환경을 구분합니다. 3년 전만 해도 코딩 도움은 다음 코드를 채워 주는 자동 완성에 가까웠고, 지금은 사람들이 코딩 에이전트에게 작업을 맡긴다고 말합니다. 그 속도의 원인을 모델만의 힘으로 보지 않습니다. 저장소와 커밋 이력, 테스트, 리뷰, 린터, 되돌리기가 프롬프트 밖에 있었기 때문이라는 주장입니다. 린터는 코드 스타일과 간단한 오류를 자동으로 검사하는 도구입니다.

모델의 품질과 주변 도구를 나눠 비교한 실험은 이 강연에 나오지 않습니다. 속도의 원인을 환경에서 찾는 것은 바이디아의 해석입니다. Anthropic이 2024년 12월에 공개한 효과적인 에이전트 구축 글은, 지금은 도구 환경이 바뀌었다고 적어 두었습니다. 그래도 구조에 관한 관찰은 여전히 참고할 만합니다. 코딩 에이전트가 반복해서 고칠 수 있는 이유는, 테스트처럼 틀린 결과를 돌려주는 작업 환경이 있기 때문입니다. 그 변경이 프로젝트 전체의 요구에 맞는지는 사람이 리뷰해야 한다고 합니다. 복잡한 구조를 더하기 전에 먼저 측정하라는 주의도 있습니다. 그래서 주변 환경을 함께 보라는 주장은 새겨들을 만합니다. 소프트웨어 공학이 이미 완전히 자율이라는 더 강한 말은, 이 강연만으로는 검증되지 않습니다.

• 원본 강연 1:26, 모델 주변의 환경
• Anthropic, Building effective agents (2024년 12월)

정보가 한곳에 모이는가

코딩 작업은 에이전트가 볼 수 있는 프로젝트에서 시작하는 경우가 많다고 합니다. 영업 건은 사정이 다릅니다. 서로 다른 시스템이 다섯이고, 로그인도 다섯입니다. 정보를 모아 두는 기본 장소가 없습니다. 모델에 도구 접근 권한을 주는 것만으로는 충분하지 않습니다. 여러 앱에 정보가 흩어져 있으면 어느 기록이 최신인지도 가려야 하고, 한 건의 거래와 관련된 기록도 에이전트가 직접 찾아 연결해야 합니다. 코딩 저장소에도 모든 정보가 있는 것은 아닙니다. 티켓, 설계 메모, 운영 설정이 저장소 밖에 있을 수 있습니다. 그래도 코딩에는 시작할 곳이 있습니다.

• 원본 강연 2:35, 정보 모으기

들여다볼 수 있는 변경 이력

코딩 쪽에서 같은 역할을 하는 도구는 Git입니다. 에이전트는 변경이 어떻게 들어왔는지 되짚을 수 있고, 사람은 작업 완료 메시지만 믿지 않고 실제 작업을 볼 수 있습니다. 바이디아가 원하는 것은 여러 앱에 걸친 기록입니다. 무엇을 건드렸고, 무엇을 건너뛰었고, 무엇이 성공했고, 무엇이 실패했는지를 이어서 보는 기록입니다. 이 이력은 나중에 확인할 자료일 뿐, 그 일을 이해했다는 뜻은 아닙니다.

업무용 앱에는 이력이 없다는 설명은 지나치게 넓습니다. Microsoft Dataverse 감사 문서(2026년 9월 9일 확인)에 따르면, 감사 기능을 켜면 고객 레코드의 변경 기록을 남길 수 있습니다. 누가 만들고 고쳤는지, 어떤 항목이 바뀌었는지, 이전 값은 무엇이었는지, Web API나 SDK로 어떻게 꺼내는지까지 적혀 있습니다. 업무 시스템에 쓸 수 있는 이력이 있다는 반례입니다. 그렇다고 제품 다섯 개의 기록이 한 건의 거래 이야기로 이어지지는 않습니다. 문제는 이력이 전혀 없다는 것보다, 여러 앱의 기록이 서로 연결되지 않는다는 데 가깝습니다.

• 원본 강연 4:11, 변경 이력
• Microsoft, Dataverse 감사 관리

업무의 구조와 품질 기준

기록을 많이 모아 두어도 업무의 구조는 생기지 않습니다. 바이디아가 말하는 맥락은 사람들이 흔히 섞어 부르는 두 가지입니다. 하나는 시스템이 어떻게 연결되어 있는지, 데이터가 어디로 흐르는지, 일이 실제로 어떻게 진행되는지 같은 업무의 구조입니다. 다른 하나는 조직의 품질 기준입니다. 같은 문서라도 어떤 내용과 표현을 좋은 결과로 보는지는 조직마다 다릅니다. 고객에게 보낼 문서를 쓰는 사례에서는 첫 문장을 쓰기 전에 사용량, 제품 분석, 거래 상황이 필요합니다. 행동을 충분히 기록하면 패턴이 재사용 가능한 절차가 된다고 합니다. 그 절차는 도구가 작동하는 방식, 회사가 일하는 방식, 한 사람이 선호하는 방식의 세 층으로 나뉩니다.

숙련된 사람이 머릿속에 들고 다니는 것을 설명한 것입니다. 문서를 모아 두는 것과 업무의 구조를 아는 것은 다릅니다. 행동 기록에서 뽑아 낸 절차가 믿을 만한 기술인지는, 이 근거만으로는 확인할 수 없습니다.

• 원본 강연 6:55, 맥락

형식이 맞는 것과 행동이 옳은 것은 다릅니다

코드에서는 단위 테스트, 통합 테스트, 타입 검사, 컴파일러가 정해 둔 조건을 충족하지 못하는 출력을 걸러낼 수 있습니다. 지식 업무에서 이와 대비되는 사례는 바이디아가 말한 채용 메일입니다. 그는 자신의 에이전트에게 채용 후보자 메일을 맡겼고, 에이전트는 지시대로 움직였으며, 메시지는 형식이 맞았고 실제 사람에게 도착했다고 합니다. 그런데도 결과는 후회스러웠다고 말합니다. 코딩에서 쓰는 점검이라면 통과했을 것이라고 합니다. 그 메일을 애초에 보냈어야 하는지는 아무도 묻지 않았다고 합니다.

이 일화는 발표자 본인의 설명입니다. 형식이 맞고 메시지가 도착했다는 사실이, 그 행동이 적절했는지를 답하지는 않습니다. 바이디아가 제안하는 보완은 두 가지입니다. 이전 초안과 톤을 맞춰 보는 검사, 그리고 실제 도구를 쓰기 전에 먼저 시험하는 샌드박스입니다. 샌드박스는 영향을 격리한 시험 환경입니다. 실제 업무에 영향을 주기 전에 일부 실수를 잡을 수 있지만, 실제 환경의 모든 행동을 검증하지는 않습니다.

• 원본 강연 9:26, 결과 검증
• 원본 강연 10:25, 메일 사례

프롬프트 밖의 권한과 정책

거버넌스, 즉 권한과 정책 통제는 소프트웨어 팀이 이미 쓰는 제한입니다. 에이전트는 자기 브랜치에서 일하고, 병합 전에 사람이 검토하며, 중요한 파일은 담당자가 보고, 미리보기 환경은 실제 운영과 다릅니다. 제한의 강도는 실수가 퍼지는 범위에 따라 달라집니다. 바이디아는 메일의 접근 범위나 CRM의 권한 단계처럼, 지식 업무용 앱에도 비슷한 기능이 있다고 말합니다. 다만 흩어져 있어서 사람들은 프롬프트로 돌아가게 된다고 합니다. 대화가 길어져 앞부분이 요약되면, 프롬프트에 적어 둔 제한은 잊힐 수 있습니다. 에이전트가 바꿀 수 없는 규칙은 대화 기억 밖에 있어야 합니다.

도구가 어디까지 접근할 수 있는지와, 그 안에서 무엇을 해도 되는지는 다릅니다. 바이디아는 그 접근 위에, 허용된 행동을 적는 자연어 정책을 두 번째 층으로 두고, 이 역시 프롬프트 밖에서 강제한다고 말합니다. 그 규칙은 설정해야 합니다. 코딩 에이전트라고 해서 병합이나 배포 권한이 원래 없는 것은 아닙니다. 그 권한이 열려 있으면, 일이 코드라는 이유만으로 제한이 있는 것은 아닙니다.

• 원본 강연 12:31, 권한과 정책
• 원본 강연 15:01, 에이전트 밖의 제한

되돌리기와 미리 막기는 다릅니다

로컬에서 바꾼 코드는 대개 되돌릴 수 있습니다. Git 공식 문서는 revert를, 이전 커밋의 효과를 뒤집는 새 커밋을 남기는 일로 설명합니다. 보낸 메일을 회수하거나 송금을 되돌리는 일은 아닙니다. 바이디아도 지식 업무에서 이 마지막 부분은 아직 완성되지 않았다고 말합니다. 라벨을 붙인 일은 떼면 될 수 있고, 완전히 지운 기록이나 보낸 메시지는 그렇지 않을 수 있습니다. 되돌릴 방법이 마땅치 않은 일에는 샌드박스와, 운영에 나가기 전의 검토를 원합니다. 실제 업무에 영향을 주기 전에 막는 것과, 일어난 일을 되돌리는 것은 다릅니다.

• 원본 강연 16:24, 되돌리기
• Git 문서: git revert

로컬에서 실행한 작은 예제

형식 검사를 통과한 요청이라도 실행해도 되는지는 따로 확인해야 합니다. 이 차이를 보여 주기 위해 가상의 작업 데이터를 수정하는 작은 파이썬 예제를 실행했습니다. 파이썬 표준 라이브러리만 사용하며, AI 모델이나 외부 서비스에 연결하지 않는 예제입니다.

허용된 프로젝트의 작업을 올바른 형식으로 수정하면 변경을 반영했습니다. 같은 형식이라도 다른 프로젝트를 가리키거나 오래된 버전 번호를 쓰면 거절했습니다. 요청 형식 자체가 잘못된 경우에는 권한을 확인하는 단계까지 진행하지 않았습니다.

되돌리기를 실행하면 작업 데이터는 이전 상태로 복원되지만, 별도로 남긴 알림 표시는 유지되도록 만들었습니다. 데이터를 복원해도 이미 일어난 다른 효과까지 자동으로 취소되지는 않는다는 점을 보여 주기 위한 구성입니다. 알림은 프로그램 안의 가상 표시이며 실제 메시지를 보내지는 않았습니다.

아래 흐름과 표는 이 예제의 동작과 실행 결과입니다. AI 에이전트의 성능을 측정하거나 강연에서 소개한 플랫폼을 재현한 실험은 아닙니다.

python3 demo.py

assertions_passed: True

이 여섯 가지가 바꾸는 질문

바이디아는 병목이 모델에서 인프라로 옮겨 갔고, 자기 회사가 그 부족한 부분을 채울 도구를 만들고 있다고 강연을 마무리합니다. 여섯 가지로 업무 흐름을 나눠 보는 방식은 여전히 쓸모가 있습니다. 소프트웨어 공학이 완전히 자율이라는 말이나 회사 규모에 관한 주장은, 이 기사에서 확인하지 않았습니다.

이미 코딩 에이전트를 쓰는 사람에게 이 강연이 남기는 것은 새 제품 목록이 아닙니다. 자기 업무에 정보가 모이는 곳이 있는지, 이력을 사람이 열어 볼 수 있는지부터 보면 모델만으로는 부족한 자리가 보입니다. 조직의 업무 기준을 미리 제공하지 않으면 모델은 무엇이 적절한 결과인지 짐작해야 하고, 검사가 형식과 전달뿐이면 형식이 맞는 요청도 틀린 행동이 될 수 있습니다. 제한이 프롬프트 안에만 있으면 대화가 요약될 때 빠질 수 있고, 되돌릴 수 없는 일이면 실제 업무에 영향을 주기 전에 막아야 합니다. 슬라이드와 강연 진행을 보고 싶다면 원본 강연이 있습니다.

• 원본 강연 19:09, 마무리

재현 파일

• README
• demo.py
• fixture.json
• observed-result.json