한동안 업계는 에이전트가 채팅처럼 보이도록 만들기 위해 매우 노력했습니다.

사용자가 작업을 입력하면, 모델이 응답합니다. 어쩌면 도구(tool)를 호출할 수도 있고, 파일을 편집할 수도 있습니다. 어쩌면 풀 리퀘스트(pull request)를 생성하고, 당신의 CI 파이프라인과는 전혀 접점이 없는 듯한 쾌활한 요약본을 남길 수도 있습니다.

이것은 위험할 정도로 충분히 유용했습니다. 하지만 채팅은 진지한 에이전트 작업에 있어 항상 잘못된 사고 모델(mental model)이었습니다.

AWS가 7월 요약에서 AI 에이전트를 위한 Amazon WorkSpaces를 언급하고, GitHub가 Copilot 앱을 에이전트 네이티브 데스크톱 경험이라고 설명하는 것은 모두 동일한 현상의 징후입니다. 즉, 에이전트에게는 작업할 공간이 필요하다는 것입니다.

텍스트 박스가 아니라.

워크스페이스(workspace)가 필요합니다.

agent opening seventeen windows and calling it productivity

실제 소프트웨어 작업에 실제로 무엇이 필요한지를 생각하기 전까지는 이것이 단순한 제품 패키징처럼 들릴 수 있습니다. 파일, 자격 증명(credentials), 브라우저 세션, 데스크톱 앱, 터미널, 로그, 인간의 승인, 장기 실행 작업, 부분적인 상태(partial state), 실패한 시도, 증거 등이 필요합니다.

다시 말해, 이 모든 지루한 것들 말입니다.

그 지루한 것들이 바로 런타임(runtime)입니다.

작업에 상태(state)가 생기기 전까지는 채팅도 괜찮습니다

채팅은 질문을 하기에는 괜찮은 인터페이스입니다.

"이 에러가 왜 발생하는 거죠?"

"이 문서를 요약해 주세요."

"이 Terraform 리소스는 무엇을 하나요?"

괜찮습니다. 저는 컴퓨터에 질문하는 것을 좋아합니다. 그것은 전기에 대해 불평할 수 있는 몇 안 되는 사회적으로 용인되는 방법 중 하나니까요.

하지만 작업은 질문만이 아닙니다. 작업에는 상태(state)가 있습니다.

코딩 에이전트는 이슈를 조사하고, 브랜치를 생성하고, 테스트를 실행하고, 문서를 읽고, 브라우저를 열고, 파일을 변경하고, 로그를 비교하고, 승인을 요청하고, CI가 실패한 후 재시도하고, 그런 다음 인간 리뷰어가 그 경로를 신뢰할 수 있을 만큼 충분한 컨텍스트를 담아 풀 리퀘스트를 생성해야 할 수도 있습니다.

그것은 채팅 기록이 아닙니다. 그것은 세션(session)입니다.

그리고 세션은 머무를 곳이 필요합니다.

세션이 오직 채팅창 안에만 존재한다면, 중요한 모든 것들이 이상해집니다. 파일은 어디에 있나요? 에이전트가 본 리포지토리(repo)의 버전은 무엇인가요? 어떤 명령어가 실행되었나요? 어떤 자격 증명(credentials)을 사용할 수 있었나요? 어떤 브라우저 상태(browser state)가 사용되었나요? 어떤 도구 호출(tool call)이 실패했나요? 에이전트가 테스트를 통과시키고 아키텍처를 망가뜨리는 영리한 지름길을 택하기 전에 무슨 일이 일어났었나요?

만약 그 답이 "위로 스크롤하기"라면, 축하합니다. 당신은 고고학을 통한 관측성(observability)을 발명하셨군요.

데스크톱 앱은 기업의 화석 기록의 일부입니다

AWS가 AI 에이전트를 위한 WorkSpaces를 출시한 것은 흥미롭습니다. 왜냐하면 벤더들이 보통 속삭이기만 하고 싶어 하는 사실을 인정하고 있기 때문입니다:

모든 비즈니스 워크플로우가 깔끔한 API를 가지고 있지는 않다는 사실 말입니다.

어떤 업무는 여전히 데스크톱 애플리케이션 내에 존재합니다. 어떤 업무는 오래된 웹 UI 뒤에 머물러 있습니다. 어떤 업무는 정확한 신원(identity), 네트워크 경로, 그리고 조건부 액세스 정책(conditional access policy)을 갖춘 브라우저 세션을 필요로 합니다. 어떤 업무는 아무도 기억하고 싶지 않은 예산 주기 동안 구매했던 도구들 사이에서 일어납니다.

자동화의 환상적인 버전은 우리가 먼저 모든 것을 현대화하고, 깔끔한 API를 노출하며, 계약(contracts)을 문서화한 다음, 에이전트가 우아하게 작동하도록 할 것이라고 말합니다.

참으로 사랑스럽군요.

대부분의 기업은 시스템의 박물관을 보유하고 있습니다. ERP 화면, 내부 관리 패널, 벤더 포털, 매크로가 포함된 스프레드시트, VPN 전용 대시보드, 그리고 RevenueToolFinal2 같은 이름을 가진 두꺼운 클라이언트(thick clients)들까지 말이죠. 소프트웨어는 오래되었지만, 업무는 실재합니다.

enterprise workflow discovering it still needs a desktop

이것이 바로 "에이전트를 위한 관리형 데스크톱(managed desktops for agents)"이 단순히 이상한 클라우드 SKU가 아닌 이유입니다. 이는 에이전트 인프라에 UI 자동화, 브라우저 제어, 파일 시스템, 신원 경계, 그리고 원격 환경이 포함될 것임을 인정하는 것입니다.

에이전트에게는 API 키만 필요한 것이 아닙니다.

에이전트에게는 머신(machine)이 필요할 수도 있습니다.

워크스페이스는 소유권의 경계입니다

에이전트가 실제 워크스페이스 (workspace)를 갖게 되면, 플랫폼 팀은 익숙한 질문에 직면하게 됩니다.

이 환경의 소유권은 누구에게 있는가?

이 질문은 지루하게 들릴 수 있지만, 바로 그렇기 때문에 중요한 문제입니다.

관리형 에이전트 워크스페이스에는 정책 (policy)이 필요합니다. 어떤 파일이 마운트 (mount)되는가? 어떤 비밀 정보 (secrets)가 세션에 들어올 수 있는가? 허용된 네트워크 목적지는 어디인가? 에이전트가 임의의 웹사이트를 열 수 있는가? 고객 데이터를 노출하는 데스크톱 앱을 사용할 수 있는가? 누가 대화 기록 (transcript)을 검사할 수 있는가?

이것은 피해망상이 아닙니다. 정상적인 운영 (operations) 과정입니다.

우리는 이미 CI 러너 (CI runners), 개발자 노트북, Kubernetes 네임스페이스 (namespaces), 빌드 에이전트 (build agents), 배스천 호스트 (bastion hosts), 그리고 클라우드 자동화 역할 (cloud automation roles)에 대해 이 작업을 수행하고 있습니다. 에이전트는 단지 또 다른 작업자 계층일 뿐입니다. 다만 이 계층은 자연어를 읽고, 창의적으로 재시도하며, 때로는 "버그를 수정해"라는 요청을 "lockfile이 외로워 보여서 의존성 6개를 업그레이드했습니다"로 바꿔버린다는 점이 다를 뿐입니다.

따라서 워크스페이스는 단순한 편의 기능이 아닙니다. 그것은 권한 부여 (access)가 명시적으로 변하는 경계입니다.

에이전트가 하나의 저장소 (repository)를 수정해야 한다면, 그 저장소에 대한 권한만 부여하십시오. 문서 확인을 위해 인터넷 접속이 필요하다면, 그 접속을 관찰 가능한 (observable) 경로를 통해 라우팅하십시오. 자격 증명 (credentials)이 필요하다면, 해당 작업 범위로 제한하십시오.

목표는 에이전트를 약하게 만드는 것이 아닙니다.

목표는 에이전트의 힘을 읽을 수 있게 (legible) 만드는 것입니다.

병렬 에이전트에는 분위기가 아닌 조정 (coordination)이 필요합니다

GitHub의 Copilot 앱 프레이밍 (framing) 또한 유용한데, 이는 여러 에이전트가 병렬로 작동하는 것에 대해 이야기하기 때문입니다.

이 지점에서 채팅의 비유는 완전히 무너집니다.

운영 환경의 버그를 조사하는 단 하나의 에이전트는 관리할 수 있습니다. 하지만 관련된 이슈들을 가로질러 작업하는 다섯 명의 에이전트는 커밋 권한과 자신감을 가진 작은 분산 시스템 (distributed system)이 될 수 있습니다. 이제 여러분에게는 작업 상태 (task state), 소유권 (ownership), 순서 지정 (sequencing), 리뷰 대기열 (review queues), 그리고 각 에이전트가 무엇을 시도했는지 이해할 수 있는 방법이 필요합니다.

기본적으로는 프로젝트 관리 (project management)와 같지만, 동료들이 잠을 자지 않고 가끔 라이브러리 API를 환각 (hallucinate)한다는 점이 다릅니다.

when every agent has a branch and nobody has a plan

중요한 인터페이스는 단지 "프롬프트 전송 (send prompt)"만이 아닙니다.

그것은 다음과 같습니다:

• 무엇이 실행 중인지 보여줘
• 무엇이 변경되었는지 보여줘
• 무엇이 실패했는지 보여줘
• 무엇에 인간의 판단 (human judgment)이 필요한지 보여줘
• 이 작업을 일시 중지해
• 저 작업을 재개해
• 이 시도들을 비교해
• 이상한 결과물이 풀 리퀘스트 (pull request)가 되기 전에 폐기해

이것은 마치 IDE, 작업 실행기 (job runner), 리뷰 대시보드 (review dashboard), 그리고 운영 콘솔 (operations console)이 불편한 회의를 거쳐 제품 로드맵을 만들어낸 것과 매우 흡사해 보이기 시작합니다.

좋습니다.

그것이 실제 작업의 형태에 훨씬 더 가깝습니다.

재개 가능성 (resumability)은 프로덕션 기능입니다

워크스페이스의 과소평가된 속성 중 하나는 재개 가능성 (resumability)입니다.

유용하고 많은 엔지니어링 작업은 단 한 번의 모델 응답으로 끝나지 않습니다. 시간이 걸립니다. 테스트가 실패합니다. 의존성 (dependencies) 설치가 느립니다. 브라우저 세션이 만료됩니다. 리뷰어가 질문을 합니다. CI가 불안정합니다 (flakes). 마이그레이션 (migration)에 재검토가 필요합니다. 누군가 "스테이징 로그 (staging logs)도 확인해 줄 수 있나요?"라고 말하는데, 이것이 바로 2시간짜리 작업이 삶의 방식 (lifestyle)이 되어버리는 과정입니다.

만약 모든 중단이 에이전트의 작업 상태 (working state)를 파괴한다면, 시스템은 조용하지만 비용이 많이 드는 구조가 됩니다. 에이전트는 컨텍스트 (context)를 다시 찾아야 합니다. 인간은 의도 (intent)를 다시 설명해야 합니다. 아무도 뿌듯함을 느끼지 못합니다.

진정한 워크스페이스는 작업 상태 (task state)를 유지할 수 있습니다. 영원히는 아닙니다. 마법 같은 기억의 늪처럼 말이죠. 하지만 명령 (commands), 차이점 (diffs), 로그 (logs), 승인 (approvals), 도구 출력 (tool outputs), 그리고 결정 (decisions)과 같은 유용한 증거를 보존할 수 있을 만큼 충분한 시간 동안은 말입니다.

그것은 인간의 역할 또한 변화시킵니다.

리뷰어는 더 이상 최종적인 차이점 (diff)만을 검토하는 것이 아닙니다. 그들은 경로 (path)를 검토합니다. 에이전트가 무엇을 조사했는가? 어떤 테스트를 실행했는가? 어떤 가정을 했는가? 경계선이 멈추라고 했을 때 멈췄는가?

이것이 에이전트의 작업이 연극적인 것이 아니라 통제 가능하게 (governable) 변하는 방식입니다.

이것은 다시 플랫폼 엔지니어링 (platform engineering)입니다

재미있는 점은 이 중 그 어떤 것도 철학적으로 새로운 것이 아니라는 사실입니다.

우리는 이전에도 실행 환경 (execution environments)을 구축해 왔습니다. CI 러너 (CI runners), 프리뷰 환경 (preview environments), 클라우드 셸 (cloud shells), 컨테이너 샌드박스 (container sandboxes), 원격 데스크톱 (remote desktops), 서비스 계정 (service accounts), 감사 로그 (audit logs), 아티팩트 저장소 (artifact stores), 정책 엔진 (policy engines), 그리고 개발자 포털 (developer portals)을 만들었습니다. 몇 년마다 우리는 작업에는 장소가 필요하고, 그 장소에는 경계가 필요하며, 그 경계에는 소유자가 필요하다는 사실을 재발견하곤 합니다.

에이전트 (Agents)는 단지 다른 문을 통해 동일한 교훈을 강요하고 있을 뿐입니다.

에이전트 워크스페이스 (agent workspaces)를 단순히 화려한 UI 카테고리로만 취급하는 것은 실수입니다. UI도 중요합니다. 개발자들은 12개의 탭을 열고 로딩 스피너 (loading spinners)와 개인적인 관계를 맺지 않고도 무슨 일이 일어나고 있는지 확인해야 합니다.

하지만 더 깊은 가치는 운영 (operational) 측면에 있습니다:

• 재현 가능한 환경 (reproducible environments)
• 범위가 지정된 ID (scoped identity)
• 제어된 네트워크 액세스 (controlled network access)
• 관리되는 파일 시스템 (managed filesystems)
• 지속 가능한 작업 상태 (durable task state)
• 감사 가능한 도구 사용 (auditable tool use)
• 검토 가능한 증거 (reviewable evidence)
• 작업 완료 시 깔끔한 정리 (clean cleanup)

이것이 바로 "멋진 데모"와 "리스크를 성격적 특성인 양 가장하지 않고도 중요한 작업에 이를 접촉하게 할 수 있는 단계"를 구분 짓는 체크리스트입니다.

핵심 (the punchline)

AI 에이전트는 인간 동료가 될 필요가 없습니다.

그들은 잘 운영되는 작업자 (well-operated workers)가 되어야 합니다.

이는 에이전트에게 워크스페이스를 제공해야 함을 의미합니다. 즉, 그들이 읽고, 쓰고, 탐색하고, 실행하고, 기다리고, 실패하고, 재개하며, 증거를 남길 수 있는 장소를 제공해야 한다는 것입니다. 또한 채팅 (chat)은 유용한 시작 인터페이스였을 뿐, 진지한 작업이 머물러야 하는 런타임 (runtime)이 아니었음을 인정하는 것을 의미하기도 합니다.

다음 세대의 유용한 에이전트 제품들은 아마도 마법 같은 챗봇 (chatbots)이라기보다는 정책, 상태, 로그, 승인 및 정리가 포함된 관리형 작업 환경 (managed work environments)에 더 가깝게 느껴질 것입니다.

덜 화려하게. 더 견고한 배관 (plumbing)처럼.

훌륭합니다. 소프트웨어는 배관 위에서 생존합니다.

에이전트가 실제 작업을 수행할 수 있다면, 실제 워크스페이스를 제공하십시오.

그런 다음, 누군가가 화요일에 무심하게 운영할 수 있을 정도로 워크스페이스를 지루하게 만드십시오.

참고 문헌 (references)

참고 문헌 (references)

• AWS News Blog: AWS Weekly Roundup, 2026년 7월 6일
• GitHub Blog: GitHub Copilot 앱: 에이전트 네이티브 데스크톱 경험
• O'Reilly Radar: AI 에이전트 스택 (2026년 판)

프로젝트를 테스트하기 위해 Railway를 사용합니다. 시작하려면 20 USD를 원하시면 이 링크를 이용하세요.