From 8f7173877c50a3a2adb469f55241105223841a67 Mon Sep 17 00:00:00 2001 From: Yujong Date: Sun, 1 Nov 2026 15:49:20 +0900 Subject: [PATCH 1/2] =?UTF-8?q?=C2=A73.5=20AI=20=EC=BD=94=EB=94=A9=20?= =?UTF-8?q?=EB=8F=84=EA=B5=AC=EC=9D=98=20=EC=9C=A0=ED=98=95=EA=B3=BC=20?= =?UTF-8?q?=EC=84=A0=ED=83=9D=201=EC=B0=A8=20=EC=B4=88=EC=95=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 네 가지 작업 형태(일반 chat, AI IDE, terminal agent, background agent)와 형태를 고를 때의 고려사항 다섯 가지를 서술한다. 다른 장과 겹치는 내용은 해당 절을 참조하는 문장으로만 남겼다. Co-Authored-By: Claude Opus 5.5 --- ko/sections/03-5-coding-tool-landscape.qmd | 166 +++++++++++++++++++++ 1 file changed, 166 insertions(+) diff --git a/ko/sections/03-5-coding-tool-landscape.qmd b/ko/sections/03-5-coding-tool-landscape.qmd index 8bfe85e..ab0ed54 100644 --- a/ko/sections/03-5-coding-tool-landscape.qmd +++ b/ko/sections/03-5-coding-tool-landscape.qmd @@ -1,2 +1,168 @@ + # §3.5 AI 코딩 도구의 유형과 선택 {.unnumbered} +3장은 AI에게 일을 맡기는 방법을 네 방향에서 살펴보았다. 3.1은 요청을 어떻게 쓸지를, 3.2는 AI가 대화를 넘어 파일을 고치고 명령을 실행하게 된 과정을 다루었다. 3.3은 작업에 필요한 정보를 어떻게 골라 보여 줄지를, 3.4는 바로 만들어 보며 탐색할지 명세부터 합의할지를 다루었다. 무엇을 어떻게 요청할지 정했다면 남는 질문은 그 작업을 어디에서, 어떤 방식으로 맡길 것인가이다. + +같은 요청을 여러 도구에 넣어 보면 이 질문이 왜 필요한지 드러난다. "테스트가 실패하는 함수를 고쳐 달라"고 요청한다고 하자(가상의 예시다). 일반 채팅에서는 사용자가 함수 코드와 오류 메시지를 대화창에 붙여 넣고, 수정안을 받아 자기 파일에 옮긴 뒤 직접 다시 실행한다. AI 기능이 들어간 편집기에서는 열려 있는 파일이 대체로 함께 전달되고, 수정안이 파일의 변경 내역으로 표시되면 사용자가 수락할지를 정한다. 터미널에서 동작하는 에이전트는 테스트를 직접 실행해 실패를 재현하고, 관련 파일을 찾아 고친 뒤 테스트를 다시 돌려 결과를 보고한다. 작업을 원격 환경에 넘기는 에이전트는 이 과정을 사용자가 보지 않는 곳에서 진행하고, 흔히 변경 사항을 브랜치나 풀 리퀘스트(pull request, 저장소에 변경을 반영해 달라는 요청)로 돌려준다. + +네 경우 모두 요청은 같고, 같은 모델이 쓰였을 수도 있다. 달라진 것은 사람이 맡는 일이다. 첫 번째 경우에는 필요한 정보를 모아 전달하는 일, 코드를 실행하는 일, 결과를 확인하는 일이 모두 사람에게 있다. 뒤로 갈수록 앞의 두 가지가 AI 쪽으로 넘어가고, 사람에게는 무엇을 맡길지 정하는 일과 돌아온 결과를 검토하는 일이 남는다. 3.2에서 보았듯 같은 모델이라도 도구를 쓸 수 있느냐에 따라 실제 문제를 해결하는 비율이 크게 달라진다. 모델 바깥에서 이런 차이를 만드는 실행 구조를 하네스(harness)라고 하며, 7.1에서 자세히 다룬다. + +이 꼭지는 도구를 제품 단위로 비교하지 않는다. 제품의 기능은 몇 달 단위로 바뀌고, 한 회사가 채팅 앱, 편집기 확장, 명령줄 도구, 클라우드 에이전트를 함께 내놓는 경우도 흔하다. 제품 비교표는 책이 나올 무렵이면 낡는다. 대신 사람과 AI가 일을 나누는 방식, 곧 작업 형태를 단위로 삼는다. 일반 chat, AI IDE, terminal agent, background agent의 네 가지다. 형태를 단위로 보면 빠르게 바뀌는 것(제품과 기능)과 오래 남는 것(분담의 구조)을 구분할 수 있다. + +네 형태를 가르는 기준은 세 가지로 정리할 수 있다. 첫째, AI가 무엇을 보고 무엇을 바꿀 수 있는가. 대화에 붙여 넣은 코드만 보는지, 프로젝트 전체와 실행 환경까지 다루는지의 차이다. 둘째, 작업이 어떻게 진행되는가. 사람이 매 단계를 지켜보며 함께 진행하는지, 범위를 정해 맡기고 다른 일을 하다가 결과를 받는지의 차이다. 셋째, 무엇을 돌려받는가. 설명과 코드 조각인지, 변경 내역인지, 실행 기록과 테스트 결과까지인지의 차이다. 3.2의 대화, 실행, 위임은 이 기준을 따라 시간 순서로 나타난 단계였다. 지금은 네 형태가 함께 쓰이며, 같은 사람이 같은 프로젝트에서도 작업에 따라 형태를 바꾼다. + +도구를 설정하고 외부 기능을 연결하는 방법은 7장에서, 어떤 모델을 쓸지는 5장에서 다룬다. + +## 네 가지 작업 형태 + +네 형태는 사람이 AI와 만나는 자리, AI가 보고 바꿀 수 있는 범위, 돌려받는 결과물, 그 결과 사람에게 남는 일에서 차이가 난다. 아래의 제품 예시와 기능 설명은 2026년 10월 28일에 각 제품의 공식 문서로 확인한 내용이다. 문서에 제품 버전이 표기되어 있지 않아 버전은 적지 않았다. + +### 일반 chat + +일반 chat은 웹이나 앱의 대화창에서 AI와 문답을 주고받는 형태다. ChatGPT, Claude, Gemini 같은 범용 채팅 서비스가 대표적이다. 사용자는 질문을 쓰고, 필요하면 코드나 오류 메시지를 붙여 넣고, 돌아온 답을 읽은 뒤 다음 질문을 이어 간다. AI가 볼 수 있는 것은 원칙적으로 사용자가 대화에 넣은 내용뿐이다. 최근의 채팅 서비스는 파일을 올리거나 대화 안의 격리된 환경에서 코드를 실행하기도 하지만([Anthropic, Create and edit files with Claude](https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude) (확인: 2026-10-28)), 그 환경은 사용자의 프로젝트나 컴퓨터와 분리되어 있다. 돌려받는 것은 설명, 코드 조각, 여러 선택지의 비교다. + +이 형태에서 사람에게 남는 일은 많다. 무엇을 보여 줄지 고르는 일, 받은 코드를 실제 파일에 옮기는 일, 실행해 보고 결과를 다시 대화로 전달하는 일이 모두 사람 몫이다. 이 부담은 약점이면서 장점이기도 하다. AI가 프로젝트를 직접 건드리지 않으므로 의도하지 않은 변경이 생기지 않고, 사람은 받은 코드를 한 줄씩 읽고 옮기면서 내용을 이해할 기회를 얻는다. 대신 AI가 보는 정보가 실제 프로젝트 상태와 어긋날 수 있다. 사용자가 다른 파일의 정의나 설치된 라이브러리 버전을 빠뜨리면, AI는 그럴듯한 추측으로 빈칸을 채운다. + +### AI IDE + +AI IDE는 코드 편집기 안에 AI 기능이 들어간 형태다. Cursor처럼 AI를 중심으로 새로 만든 편집기도 있고, VS Code에 GitHub Copilot을 붙이는 것처럼 기존 편집기에 확장 기능으로 더하는 경우도 있다. 사용자는 코드를 보면서 자동완성을 받거나, 편집기 옆 대화창에서 수정을 요청한다. AI는 열려 있는 파일과 프로젝트의 다른 파일을 참고할 수 있고, 수정안은 편집기 안에서 파일별 변경 내역(diff)으로 표시된다. 사용자는 변경을 하나씩 수락하거나 되돌린다. + +이 형태의 특징은 사람이 코드를 보는 자리에서 AI의 변경을 확인한다는 데 있다. 채팅에서처럼 코드를 옮겨 붙일 필요가 없고, 무엇이 바뀌었는지가 원래 코드 옆에 바로 드러난다. 최근의 AI IDE는 여러 파일을 한꺼번에 고치거나 터미널 명령을 실행하는 에이전트 기능도 갖추고 있어서([Cursor, Agent](https://cursor.com/docs/agent/overview) (확인: 2026-10-28); [Microsoft, GitHub Copilot in VS Code](https://code.visualstudio.com/docs/copilot/overview) (확인: 2026-10-28)), 할 수 있는 일만으로는 다음에 볼 terminal agent와 구분하기 어려워졌다. 두 형태를 가르는 것은 능력보다 검토가 일어나는 자리다. AI IDE에서는 편집기 화면의 diff가 검토의 중심이 된다. + +### terminal agent + +terminal agent는 명령줄에서 실행되는 에이전트다. Anthropic의 Claude Code와 OpenAI의 Codex CLI가 대표적이다([Anthropic, Claude Code overview](https://code.claude.com/docs/en/overview) (확인: 2026-10-28); [OpenAI, Codex 문서](https://learn.chatgpt.com/docs) (확인: 2026-10-28)). 사용자는 터미널에서 에이전트를 띄우고 대화로 작업을 지시한다. 에이전트는 사용자의 컴퓨터에서 저장소의 파일을 찾아 읽고, 고치고, 테스트나 빌드 같은 명령을 직접 실행한 뒤 그 결과를 보고 다음 행동을 정한다. 돌려받는 것은 변경 내역과 함께 어떤 명령을 실행했고 무엇이 출력되었는지에 대한 기록이다. + +이 형태는 사용자의 실제 개발 환경에서 동작한다는 점이 핵심이다. 설치된 라이브러리, 로컬 데이터, 설정 파일이 모두 그대로 쓰이므로, 코드가 정말 이 환경에서 돌아가는지를 에이전트가 직접 확인할 수 있다. 같은 이유로 에이전트의 행동이 실제 파일과 환경에 바로 영향을 준다. 그래서 대부분의 도구는 파일 수정이나 명령 실행 전에 사용자의 승인을 받는 단계를 두고, 그 승인을 어디까지 생략할지를 사용자가 정하게 한다. 승인과 샌드박스가 왜 필요한지는 8.3에서 다룬다. 사람에게 남는 일은 승인할지 판단하는 일과, 대화 흐름에 쌓인 실행 기록을 읽고 결과를 확인하는 일이다. 같은 도구를 대화 없이 한 번의 명령으로 실행해 스크립트나 자동화 흐름에 넣을 수도 있다. 이런 반복 실행에서 재시도와 중단 조건을 어떻게 설계할지는 6.2에서, 일정이나 이벤트에 맞춰 스스로 시작하는 상시형 에이전트는 16.3에서 다룬다. + +### background agent + +background agent는 작업을 맡기면 사용자가 지켜보지 않는 곳에서 진행하고 결과를 돌려주는 형태다. GitHub의 Copilot cloud agent, OpenAI의 Codex Cloud, Claude Code의 클라우드 세션, Cursor의 Cloud Agents가 이 방식으로 동작한다([GitHub, About Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent); [OpenAI, Codex Cloud](https://learn.chatgpt.com/docs/cloud); [Anthropic, Use Claude Code in the cloud](https://code.claude.com/docs/en/claude-code-on-the-web); [Cursor, Cloud Agents](https://cursor.com/docs/cloud-agent) (모두 확인: 2026-10-28)). 사용자는 웹 화면, 이슈나 풀 리퀘스트의 댓글, 편집기, 터미널 등에서 작업을 지시한다. 에이전트는 원격의 격리된 환경에 저장소를 복제하고, 필요한 의존성을 설치한 뒤, 파일을 고치고 테스트를 실행한다. 작업이 끝나면 변경 사항을 브랜치나 풀 리퀘스트로 올리고, 무엇을 바꿨는지와 테스트 결과를 돌려준다. 그동안 사용자는 다른 일을 할 수 있고, 여러 작업을 동시에 맡길 수도 있다. + +이 형태에서 사람의 일은 작업 전과 작업 후로 몰린다. 작업 전에는 무엇을 어디까지 할지, 어떤 상태가 되면 끝난 것인지를 정해 넘겨야 한다. 작업 중에 방향을 바로잡기 어려우므로, 이 단계가 부실하면 결과도 엉뚱해진다. 작업 후에는 돌아온 변경을 검토하고 받아들일지 정한다. 원격 환경에서 돌아간다는 점도 고려해야 한다. 내 컴퓨터에만 있는 데이터나 설정은 그 환경에 없고, 반대로 저장소와 작업에 필요한 정보는 그 환경으로 옮겨 간다. 완료 기준을 쓰는 방법은 6.1에서, 돌아온 결과를 검증하는 방법은 10장에서, 여러 작업을 맡기고 기다리는 일이 개인과 팀의 일과를 어떻게 바꾸는지는 15.1에서 다룬다. + +### 네 형태를 읽을 때 주의할 점 + +네 형태를 한눈에 정리하면 다음과 같다. + +| 형태 | 사람과 만나는 자리 | AI가 다루는 범위 | 돌려받는 것 | 사람에게 남는 일 | +|---|---|---|---|---| +| 일반 chat | 대화창 | 대화에 넣은 내용 | 설명, 코드 조각, 선택지 | 정보 전달, 반영, 실행, 확인 | +| AI IDE | 편집기 | 프로젝트 파일 (도구에 따라 실행 포함) | 파일별 diff | 변경 수락, 확인 | +| terminal agent | 터미널의 대화 | 저장소와 로컬 실행 환경 | diff와 실행 기록 | 승인, 기록 검토 | +| background agent | 작업 지시 화면과 결과 보고 | 원격 환경에 복제된 저장소 | 브랜치나 풀 리퀘스트, 변경 요약, 테스트 결과 | 범위와 완료 기준 정하기, 사후 검토 | + +이 표를 읽을 때 네 가지를 함께 기억해야 한다. + +첫째, 네 형태는 같은 축 위의 네 칸이 아니다. 일반 chat, AI IDE, terminal agent는 사람이 AI와 만나는 환경에 따른 구분이고, background agent는 작업이 진행되는 방식에 따른 구분이다. 그래서 둘은 겹칠 수 있다. 편집기나 터미널에서 작업을 지시하고 원격에서 진행되게 하는 도구가 그런 예다. VS Code의 Copilot은 편집기에서 클라우드 에이전트로 작업을 넘길 수 있고, Claude Code는 터미널에서 클라우드 세션을 시작할 수 있다. + +둘째, 네 형태는 발전 단계가 아니다. 표의 아래쪽이 더 앞선 도구라는 뜻이 아니며, 위쪽 형태가 사라지고 있다는 뜻도 아니다. 1장에서 보았듯 스프레드시트와 노코드 도구가 AI 코딩과 함께 쓰이는 것처럼, 네 형태도 각자 맞는 작업이 있어 함께 쓰인다. + +셋째, 제품과 형태는 일대일로 대응하지 않는다. Claude Code는 터미널, 편집기 확장, 데스크톱 앱, 웹에서 쓸 수 있고, Codex도 명령줄 도구, 편집기 확장, 클라우드로 제공된다. Cursor는 편집기 안의 에이전트와 원격의 Cloud Agents를 함께 제공한다. 같은 제품이 판올림하면서 다른 형태의 기능을 더하기도 한다. 그래서 "이 제품은 어떤 형태인가"보다 "이번 작업에서 이 도구를 어떤 형태로 쓰는가"를 묻는 편이 정확하다. 이 형태들이 앞으로 하나로 합쳐질지는 17.3에서 다룬다. + +넷째, 터미널에서 동작한다고 자율성이 높은 것은 아니다. terminal agent도 모든 변경을 하나씩 승인받으며 쓸 수 있고, AI IDE에서도 승인 없이 여러 파일을 고치게 할 수 있다. AI가 얼마나 스스로 진행하는지는 형태보다 설정과 사람의 개입 방식이 정한다. 이 점은 다음에 볼 고려사항 가운데 개입 방식에서 다시 다룬다. + +마지막으로, 이 네 가지 분류는 사람과 AI의 분담을 설명하기 위해 이 책이 세운 구분이다. 연구로 검증된 범주가 아니며, 제품이 바뀌면 경계선도 조금씩 움직일 수 있다. + +## 작업자가 고려할 사항 + +형태를 고를 때 살펴볼 것은 다섯 가지다. 지금 작업이 어떤 상태인가, AI가 무엇을 보고 바꿔야 하는가, 사람은 언제 개입하는가, 무엇을 돌려받아 검토하는가, 작업은 어디에서 돌아가는가. 앞의 넷은 작업이 어떻게 진행될지에 관한 것이고, 마지막은 그 전에 걸리는 조건이다. 다섯 가지는 점수를 매겨 합산하는 표가 아니다. 서로 영향을 주고받으며, 한 가지가 다른 선택지를 미리 지워 버리기도 한다. + +설명에는 하나의 작은 작업을 계속 예로 든다. 이미 있는 CSV 분석 스크립트에 결측치 처리와 그래프 기능을 더하는 일이다(가상의 예시다). 분석 방법이 통계적으로 타당한지는 이 꼭지에서 다루지 않는다. 그 문제는 4.2에서 다룬다. + +### 작업 상태: 방법을 찾는 중인가, 실행하려는가 + +Barke 등은 프로그래머 20명이 코드 생성 도구인 GitHub Copilot으로 과제를 푸는 모습을 관찰하고, 사용 방식이 두 가지 모드로 나뉜다고 보고했다([Barke 외, Grounded Copilot: How Programmers Interact with Code-Generating Models](https://doi.org/10.1145/3586030) (Proceedings of the ACM on Programming Languages 7(OOPSLA1), 2023)). 가속 모드(acceleration mode)에서는 다음에 무엇을 할지 이미 알고 있고, 도구를 써서 그 구현에 더 빨리 도달하려 한다. 탐색 모드(exploration mode)에서는 어떻게 진행할지 아직 모르며, 도구의 출력으로 가능한 선택지를 살펴본다. 두 모드에서 사람이 출력을 대하는 태도는 달랐다. 가속 모드의 참가자들은 제안이 의도와 맞는지를 빠르게 훑어보고 받아들였으며, 여러 줄에 걸친 긴 제안은 작업의 흐름을 끊는다고 느꼈다. 탐색 모드의 참가자들은 여러 제안을 띄워 놓고 비교하거나 출발점으로 삼았고, 받아들이기 전에 더 꼼꼼히 확인했다. + +이 구분이 형태 선택에 중요한 이유는, 탐색 중인 작업을 실행 중인 작업처럼 맡기면 정한 적 없는 결정이 코드에 굳어 버리기 때문이다. 결측치를 버릴지 채울지 정하지 않은 채 에이전트에게 "결측치를 처리해 달라"고 맡기면, 에이전트는 어느 쪽이든 하나를 골라 구현한다. 사용자는 돌아온 코드가 잘 돌아가는 것을 보고 그 선택을 기본값처럼 받아들이기 쉽다. 반대로 할 일이 분명한 작업을 대화로만 진행하면, 코드를 옮기고 실행하고 결과를 다시 전하는 일이 반복되어 시간이 든다. + +그래서 형태를 고르기 전에 지금이 어느 상태인지부터 묻는 편이 좋다. 간단한 판단 신호는 완료 조건을 한 문장으로 쓸 수 있는가이다. "모든 숫자 열의 결측치를 열 평균으로 채우고, 처리 전후의 결측치 개수를 출력한다"처럼 쓸 수 있으면 실행할 준비가 된 것이다. "결측치를 적당히 처리한다" 이상으로 쓸 수 없다면 아직 탐색 중이다. 탐색 단계에서는 결과물이 가볍고 버리기 쉬운 형태가, 실행 단계에서는 변경을 곧바로 반영하고 확인할 수 있는 형태가 대체로 편하다. 다만 Barke 등의 연구는 자동완성 중심의 도구를 대상으로 했고, "탐색에는 이 형태, 가속에는 저 형태"라는 대응을 제시하지 않았다. 이 연결은 이 책의 해석이다. + +같은 프로젝트에서도 상태는 바뀐다. 처리 방법을 정하는 동안은 탐색이고, 정한 뒤 여러 파일에 반영하는 동안은 가속이다. 형태도 그에 맞춰 바꿀 수 있다. 무엇을 먼저 탐색하고 무엇부터 명세로 합의할지는 3.4에서 다루었다. + +### 작업 범위: AI가 무엇을 보고 무엇을 바꾸는가 + +AI가 다룰 수 있는 범위는 대략 네 단계로 넓어진다. 대화에 붙여 넣은 코드, 프로젝트의 파일, 로컬 실행 환경(명령, 테스트, 설치된 라이브러리), 그리고 원격 저장소나 외부 서비스 같은 바깥 시스템이다. 앞에서 본 네 형태는 이 범위가 각각 다르다. + +범위가 좁으면 AI는 사용자가 준 정보만으로 판단한다. 사용자가 빠뜨린 정보는 AI가 추측으로 채운다. 다른 파일에 정의된 함수의 이름, 설치된 라이브러리의 버전, 데이터의 실제 열 이름 같은 것들이 대표적이다. 그 결과 문법은 맞고 설명도 그럴듯하지만 실제 프로젝트에서는 돌아가지 않는 코드가 나올 수 있다. 이런 오류의 유형은 9.1에서 다룬다. 범위가 넓으면 AI가 직접 파일을 찾아 읽고 코드를 실행해 확인할 수 있으므로 이런 어긋남이 줄어든다. 대신 AI가 바꿀 수 있는 대상도 함께 늘어난다. 요청하지 않은 파일이나 설정까지 고치는 일이 생길 수 있고, 이 문제는 9.2에서 다룬다. + +그러면 범위는 어디까지 열어야 하는가. 이 책이 제안하는 기준은 AI가 작업을 끝냈는지 스스로 확인하는 데 필요한 만큼이다. 그래프 함수 하나를 새로 쓰는 일이라면 대화에 함수의 입력과 출력을 설명하는 것으로 충분할 수 있다. 결측치 처리를 기존 전처리 모듈과 맞물려 넣어야 한다면 AI가 그 모듈과 호출하는 쪽 파일을 볼 수 있어야 한다. 처리 결과가 실제 데이터에서 맞게 나오는지까지 확인해야 한다면 코드를 실행할 수 있어야 한다. 판단 신호는 세 가지로 정리할 수 있다. 여러 파일을 함께 바꿔야 하는가, 결과를 확인하려면 실행이 필요한가, 프로젝트 바깥의 시스템을 건드려야 하는가. 하나라도 해당하면 대화만으로 진행하는 형태로는 부족할 가능성이 크다. + +범위를 넓히는 구체적인 방법, 예를 들어 외부 문서나 서비스를 연결하는 방법은 7.3에서, 넓어진 범위 가운데 무엇을 골라 보여 줄지는 6.3에서 다룬다. + +### 개입 방식: 작업 중에 판단할 것인가, 끝난 뒤에 검토할 것인가 + +사람이 개입하는 방식은 세 수준으로 나눌 수 있다. 매 응답을 보고 다음 요청을 정하며 함께 진행하는 방식, AI가 진행하되 파일을 바꾸거나 명령을 실행할 때마다 승인하는 방식, 범위를 정해 맡긴 뒤 끝난 결과를 검토하는 방식이다. 일반 chat, AI IDE, terminal agent는 대체로 앞의 두 방식으로 진행되고, background agent는 세 번째 방식에 가깝다. 앞서 말했듯 같은 terminal agent라도 승인 설정에 따라 두 번째와 세 번째 사이를 오갈 수 있다. + +개입이 줄어든다고 사람의 판단이 줄어드는 것은 아니다. 판단이 일어나는 시점이 작업 중에서 작업 전과 작업 후로 옮겨 갈 뿐이다. 함께 진행할 때는 방향이 어긋나는 순간 바로 바로잡을 수 있다. 맡기고 기다릴 때는 그럴 수 없으므로, 작업 전에 범위와 완료 기준을 더 분명히 정해야 하고, 작업 후에는 그동안 일어난 일을 한꺼번에 검토해야 한다. 그러니 개입을 줄이는 선택은 검토를 뒤로 미루는 선택에 가깝다. 이 정리는 연구 결과에서 나온 것이 아니고 이 책의 제안이다. + +매 단계 승인하는 방식이 늘 안전한 것도 아니다. 승인 요청이 잦으면 사람은 내용을 읽지 않고 습관처럼 허용하게 되기 쉽다. 승인을 어느 지점에 둘지는 6.4에서 자세히 다룬다. + +판단 신호는 세 가지다. 진행 중에 방향이 바뀔 가능성이 큰가. 되돌리기 어려운 변경이 포함되는가. 나는 결과를 보기 전에 무엇이 맞는지 판단할 기준을 갖고 있는가. 앞의 둘에 해당하거나 마지막 질문에 답하기 어렵다면 함께 진행하는 쪽이 낫다. 예를 들어 그래프의 모양을 보면서 축과 색을 다듬어야 한다면, 맡기고 기다리기보다 결과를 바로 보며 고치는 편이 빠르다. 반대로 이미 정한 결측치 처리 규칙을 여러 분석 스크립트에 똑같이 적용하는 일이라면, 범위를 정해 맡기고 끝난 뒤 검토할 수 있다. 실패했을 때 몇 번까지 다시 시도하고 언제 멈출지는 6.2에서 다룬다. + +### 검토 가능성: 무엇을 돌려받아야 끝났다고 판단할 수 있는가 + +네 형태가 돌려주는 것은 점점 많아진다. 일반 chat은 설명과 코드 조각을, AI IDE는 파일별 변경 내역을, terminal agent는 변경 내역과 실행 기록을, background agent는 브랜치나 풀 리퀘스트와 함께 변경 요약과 테스트 결과를 돌려준다. 이 결과물은 사람이 작업이 제대로 끝났는지 판단하는 근거가 된다. 그래서 형태를 고를 때는 AI가 무엇을 만들어 줄 수 있는가와 함께, 내가 그 결과를 확인할 수 있는가를 물어야 한다. + +두 질문을 나누어야 한다는 점은 초기 연구에서도 드러났다. Vaithilingam 등은 참가자 24명에게 GitHub Copilot을 쓸 때와 쓰지 않을 때 각각 프로그래밍 과제를 하게 했다([Vaithilingam 외, Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models](https://doi.org/10.1145/3491101.3519665) (CHI 2022 Extended Abstracts)). Copilot이 과제 완료 시간이나 성공률을 반드시 개선하지는 않았지만, 대부분의 참가자는 일상적인 프로그래밍에서 Copilot을 쓰고 싶어 했다. 쓸 만한 출발점을 주고 온라인에서 검색하는 수고를 덜어 주었기 때문이다. 동시에 참가자들은 생성된 코드를 이해하고, 고치고, 오류를 찾는 데서 어려움을 겪었고, 이 어려움이 과제 해결을 크게 방해했다. 초기 도구를 대상으로 한 연구이므로 지금 제품의 성능을 말해 주지는 않는다. 다만 코드를 만들어 주는 능력과 사람이 그 코드를 검토할 수 있는지는 서로 다른 문제라는 점은 지금도 유효하다. + +돌려받는 결과물이 많아지면 검토가 쉬워지기도 하고 어려워지기도 한다. 실행 기록과 테스트 결과가 있으면 코드를 한 줄씩 읽지 않아도 무엇이 확인되었는지 알 수 있다. 반면 여러 파일에 걸친 변경과 수십 번의 명령 기록이 한꺼번에 돌아오면, 무엇을 먼저 봐야 할지부터 판단해야 한다. 결국 따져야 할 것은 결과물의 양보다 그 결과물로 무엇을 판단할 수 있는가이다. + +여기서 가장 흔한 함정은 끝났다는 보고와 끝났다는 증거를 혼동하는 일이다. 결측치 처리를 맡긴 뒤 "결측치 처리를 완료했습니다"라는 답을 받았다고 하자. 이 문장만으로는 어떤 열에 어떤 규칙이 적용되었는지, 처리 전후에 행 수가 어떻게 바뀌었는지, 실제로 실행해 확인했는지 알 수 없다. 검토할 수 있는 결과를 받으려면 요청할 때부터 무엇을 함께 돌려받을지 정해 두어야 한다. 적용한 규칙, 처리 전후의 결측치 개수, 실행한 명령과 그 출력, 그리고 확인하지 못한 부분이다. 마지막 항목은 특히 중요하다. 그럴듯하지만 사실과 다른 출력, 그 가운데 확인하지 않은 것을 확인했다고 하는 경우는 9.1에서 다룬다. + +이 고려사항에서 형태 선택의 한 가지 조건이 나온다. 맡기고 기다리는 형태를 쓰려면 두 가지가 먼저 갖춰져 있어야 한다. 무엇이 되면 끝난 것인지 미리 적을 수 있어야 하고, 결과를 확인할 수단, 예를 들어 테스트나 실행해 볼 수 있는 확인 절차가 있어야 한다. 둘 중 하나라도 없다면 결과를 보며 함께 진행하는 형태가 낫다. 완료 기준을 쓰는 방법은 6.1에서, 테스트를 설계하는 방법은 10.1에서, 에이전트가 남긴 기록을 따라가며 판단을 되짚는 방법은 10.3에서, 돌아온 변경을 브랜치와 자동 검사로 통제하는 방법은 12.3에서 다룬다. + +### 실행 위치: 작업은 어디에서 돌아가고 데이터는 어디로 가는가 + +마지막 고려사항은 AI가 실행하는 코드와 읽는 데이터가 어디에 있는가이다. terminal agent는 대개 사용자의 컴퓨터에서 동작하고, background agent는 대개 원격의 격리된 환경에서 동작한다. 일반 chat에 붙여 넣은 내용과 AI IDE가 참고하는 파일도, 모델을 외부 서비스로 쓰는 한 그 서비스의 서버로 전송된다. + +로컬에서 실행하면 내 환경 그대로 결과를 확인할 수 있지만, 에이전트의 행동이 내 파일과 환경에 직접 영향을 준다. 원격 격리 환경에서 실행하면 내 컴퓨터와 분리되어 있어 실수의 영향이 그 환경 안에 머무른다. 대신 저장소와 작업에 필요한 데이터가 그 환경으로 옮겨 가야 하고, 내 컴퓨터에만 있는 데이터나 설정은 쓸 수 없다. + +이 고려사항은 다른 네 가지보다 먼저 걸리는 경우가 많다. 분석할 CSV에 개인정보나 공개 전 연구 데이터가 들어 있다면, 어떤 형태가 편한지를 따지기 전에 그 데이터를 AI 도구에 넣어도 되는지부터 확인해야 한다. 넣을 수 없다면 선택지는 크게 줄어든다. 데이터를 익명화하거나 합성 데이터로 바꿔 작업할 수도 있고, 외부로 데이터를 보내지 않는 운영 방식을 찾아야 할 수도 있다. 데이터가 전송되고 학습에 쓰이고 보관되는 조건을 따지는 방법은 9.5에서, 모델과 호스팅 방식을 고르는 일은 5.3에서, 모델을 직접 운영하는 선택은 17.2에서 다룬다. + +이 꼭지는 이번 작업을 어떤 형태로 시작할지를 다룬다. 여러 작업을 오래 맡길 에이전트 환경을 어떻게 갖출지, 예를 들어 세션과 메모리를 어떻게 이어 가고 권한을 어떻게 나눌지는 7.2에서 다룬다. + +## 정리: 형태를 고르는 순서 + +다섯 가지 고려사항을 네 형태에 겹쳐 보면 다음과 같다. + +| | 작업 상태 | 작업 범위 | 개입 방식 | 돌려받는 것 | 실행 위치 | +|---|---|---|---|---|---| +| 일반 chat | 방법을 찾을 때 쓰기 쉽다 | 대화에 넣은 내용 | 매 응답을 보고 다음 요청 | 설명, 코드 조각, 선택지 | 코드 실행은 사용자 몫, 대화 내용은 서버로 전송 | +| AI IDE | 정한 일을 반영할 때 쓰기 쉽다 | 프로젝트 파일 (도구에 따라 실행 포함) | 변경마다 수락 | 파일별 diff | 사용자 컴퓨터의 편집기 | +| terminal agent | 실행해 봐야 알 수 있는 일 | 저장소와 로컬 실행 환경 | 설정에 따라 단계별 승인부터 사후 검토까지 | diff와 실행 기록 | 대개 사용자 컴퓨터 | +| background agent | 범위와 완료 기준이 분명한 일 | 원격 환경에 복제된 저장소 | 범위를 정해 맡기고 사후 검토 | 브랜치나 풀 리퀘스트, 변경 요약, 테스트 결과 | 대개 원격 격리 환경 | + +이 표는 경향을 정리한 것이다. 칸마다 정답이 정해져 있다는 뜻이 아니며, 같은 도구도 설정과 쓰는 방식에 따라 다른 칸에 놓일 수 있다. + +다섯 가지를 따지는 순서에도 일정한 흐름이 있다. 먼저 실행 위치에서 걸리는 조건이 없는지 본다. 다룰 데이터를 AI 도구에 넣을 수 없다면 나머지를 따지기 전에 선택지가 줄어든다. 다음으로 작업 상태를 묻는다. 아직 방법을 찾는 중이라면 결과물이 가볍고 바로 확인할 수 있는 형태로 시작하고, 정해야 할 것을 먼저 정한다. 할 일이 분명해졌다면 작업 범위와 개입 방식을 함께 정한다. AI가 끝났는지 스스로 확인하는 데 필요한 만큼 범위를 열고, 방향이 바뀔 가능성과 되돌리기 어려운 정도에 맞춰 개입 수준을 정한다. 마지막으로 검토 가능성을 확인한다. 맡기고 기다리는 형태를 쓰려면 완료 기준과 확인 수단이 먼저 있어야 하고, 둘 중 하나가 없으면 함께 진행하는 형태로 돌아간다. + +이 순서는 한 번 정하고 끝나는 절차가 아니다. 같은 결측치 처리 작업도 처리 방법을 고르는 동안에는 대화로 탐색하고, 방법을 정한 뒤에는 편집기에서 기존 코드에 반영하고, 실제 데이터로 돌려 봐야 할 때는 실행할 수 있는 환경으로 옮기고, 같은 규칙을 다른 스크립트에 적용하는 일은 범위를 정해 맡길 수 있다. 작업이 진행되면서 상태가 바뀌면 형태도 다시 고른다. + +정리하면, AI 코딩 도구를 고르는 일은 이번 작업에서 AI가 무엇을 다루고, 사람이 언제 개입하고, 무엇을 돌려받아 검토할지를 정하는 일이다. 제품의 이름과 기능은 빠르게 바뀌지만, 이 세 가지를 묻는 방식은 도구가 바뀌어도 그대로 쓸 수 있다. + +## 이후 장에서 이어지는 내용 + +이 꼭지에서 짧게 언급하고 넘긴 내용은 다음 장들에서 자세히 다룬다. + +| 더 알고 싶은 것 | 다루는 곳 | +|---|---| +| 이런 형태로 실제로 무엇을 만들었나 | 4장 | +| 작업에 맞는 모델 고르기 | 5.1 | +| 모델과 호스팅 방식 고르기, 직접 운영하기 | 5.3, 17.2 | +| 완료 기준 쓰기 | 6.1 | +| 재시도와 중단 조건 | 6.2 | +| 무엇을 골라 보여 줄 것인가 | 6.3 | +| 사람의 승인을 어디에 둘 것인가 | 6.4 | +| 에이전트 하네스 고르기 | 7.2 | +| 도구, MCP, 스킬 연결 | 7.3 | +| 메모리, 세션 재개, 체크포인트 | 7.4 | +| 에이전트가 도구를 쓰는 원리와 샌드박스, 승인 | 8.3 | +| 그럴듯하지만 틀린 코드, 요청 밖 수정 | 9.1, 9.2 | +| 데이터, 저작권, 라이선스 | 9.5 | +| 테스트와 행동 기록으로 검증하기 | 10.1, 10.3 | +| 브랜치와 자동 검사로 변경 통제하기 | 12.3 | +| 배우는 단계에서 AI를 쓰는 방법 | 14.2, 14.3 | +| 위임과 대기, 병렬 작업이 바꾸는 일과 | 15.1 | +| 계속 일하는 상시형 에이전트 | 16.3 | +| 개발 환경은 하나로 합쳐질까 | 17.3 | From d17a48cd216cccb3c50cea8f15631545be429e63 Mon Sep 17 00:00:00 2001 From: Yujong Date: Mon, 2 Nov 2026 11:35:10 +0900 Subject: [PATCH 2/2] =?UTF-8?q?=C2=A73.5=20=EB=AC=B8=EC=B2=B4=20=EC=A0=90?= =?UTF-8?q?=EA=B2=80=20=EB=AA=A9=EB=A1=9D=20=EB=B0=98=EC=98=81?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 조건 대구와 마무리 경구를 평서문으로 고치고, 반복되던 헤지 표현을 줄였다. IDE, CLI, 샌드박스, 의존성을 처음 나올 때 설명했다. 3.2 원고가 없는 상태에서 근거가 비어 있던 수치 주장은 3.2를 참조하는 문장으로 바꿨다. Co-Authored-By: Claude Opus 5.5 --- ko/sections/03-5-coding-tool-landscape.qmd | 32 +++++++++++----------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/ko/sections/03-5-coding-tool-landscape.qmd b/ko/sections/03-5-coding-tool-landscape.qmd index ab0ed54..0127a3c 100644 --- a/ko/sections/03-5-coding-tool-landscape.qmd +++ b/ko/sections/03-5-coding-tool-landscape.qmd @@ -1,13 +1,13 @@ # §3.5 AI 코딩 도구의 유형과 선택 {.unnumbered} -3장은 AI에게 일을 맡기는 방법을 네 방향에서 살펴보았다. 3.1은 요청을 어떻게 쓸지를, 3.2는 AI가 대화를 넘어 파일을 고치고 명령을 실행하게 된 과정을 다루었다. 3.3은 작업에 필요한 정보를 어떻게 골라 보여 줄지를, 3.4는 바로 만들어 보며 탐색할지 명세부터 합의할지를 다루었다. 무엇을 어떻게 요청할지 정했다면 남는 질문은 그 작업을 어디에서, 어떤 방식으로 맡길 것인가이다. +3장은 AI에게 일을 맡기는 방법을 네 방향에서 살펴보았다. 3.1은 요청을 어떻게 쓸지를, 3.2는 AI가 직접 파일을 고치고 명령을 실행하게 된 과정을 다루었다. 3.3은 작업에 필요한 정보를 어떻게 골라 보여 줄지를, 3.4는 바로 만들어 보며 탐색할지 명세부터 합의할지를 다루었다. 이 꼭지는 그다음 질문을 다룬다. 정한 작업을 어디에서, 어떤 방식으로 AI에게 맡길 것인가이다. -같은 요청을 여러 도구에 넣어 보면 이 질문이 왜 필요한지 드러난다. "테스트가 실패하는 함수를 고쳐 달라"고 요청한다고 하자(가상의 예시다). 일반 채팅에서는 사용자가 함수 코드와 오류 메시지를 대화창에 붙여 넣고, 수정안을 받아 자기 파일에 옮긴 뒤 직접 다시 실행한다. AI 기능이 들어간 편집기에서는 열려 있는 파일이 대체로 함께 전달되고, 수정안이 파일의 변경 내역으로 표시되면 사용자가 수락할지를 정한다. 터미널에서 동작하는 에이전트는 테스트를 직접 실행해 실패를 재현하고, 관련 파일을 찾아 고친 뒤 테스트를 다시 돌려 결과를 보고한다. 작업을 원격 환경에 넘기는 에이전트는 이 과정을 사용자가 보지 않는 곳에서 진행하고, 흔히 변경 사항을 브랜치나 풀 리퀘스트(pull request, 저장소에 변경을 반영해 달라는 요청)로 돌려준다. +같은 요청을 여러 도구에 넣어 보면 이 질문이 왜 필요한지 드러난다. "테스트가 실패하는 함수를 고쳐 달라"고 요청한다고 하자(가상의 예시다). 일반 채팅에서는 사용자가 함수 코드와 오류 메시지를 대화창에 붙여 넣고, 수정안을 받아 자기 파일에 옮긴 뒤 직접 다시 실행한다. AI 기능이 들어간 편집기에서는 AI가 열려 있는 파일을 참고하고, 수정안이 파일의 변경 내역으로 표시되면 사용자가 수락할지를 정한다. 터미널에서 동작하는 에이전트는 테스트를 직접 실행해 실패를 재현하고, 관련 파일을 찾아 고친 뒤 테스트를 다시 돌려 결과를 보고한다. 작업을 원격 환경에 넘기는 에이전트는 이 과정을 사용자가 보지 않는 곳에서 진행하고, 변경 사항을 브랜치나 풀 리퀘스트(pull request, 저장소에 변경을 반영해 달라는 요청)로 돌려준다. -네 경우 모두 요청은 같고, 같은 모델이 쓰였을 수도 있다. 달라진 것은 사람이 맡는 일이다. 첫 번째 경우에는 필요한 정보를 모아 전달하는 일, 코드를 실행하는 일, 결과를 확인하는 일이 모두 사람에게 있다. 뒤로 갈수록 앞의 두 가지가 AI 쪽으로 넘어가고, 사람에게는 무엇을 맡길지 정하는 일과 돌아온 결과를 검토하는 일이 남는다. 3.2에서 보았듯 같은 모델이라도 도구를 쓸 수 있느냐에 따라 실제 문제를 해결하는 비율이 크게 달라진다. 모델 바깥에서 이런 차이를 만드는 실행 구조를 하네스(harness)라고 하며, 7.1에서 자세히 다룬다. +네 경우 모두 요청은 같고, 같은 모델이 쓰였을 수도 있다. 달라진 것은 사람이 맡는 일이다. 첫 번째 경우에는 필요한 정보를 모아 전달하는 일, 코드를 실행하는 일, 결과를 확인하는 일이 모두 사람에게 있다. 뒤로 갈수록 앞의 두 가지가 AI 쪽으로 넘어가고, 사람에게는 무엇을 맡길지 정하는 일과 돌아온 결과를 검토하는 일이 남는다. AI가 도구를 쓸 수 있게 되면서 코딩 작업이 어떻게 달라졌는지는 3.2에서 다루었다. 모델 바깥에서 이런 차이를 만드는 실행 구조를 하네스(harness)라고 하며, 7.1에서 자세히 다룬다. -이 꼭지는 도구를 제품 단위로 비교하지 않는다. 제품의 기능은 몇 달 단위로 바뀌고, 한 회사가 채팅 앱, 편집기 확장, 명령줄 도구, 클라우드 에이전트를 함께 내놓는 경우도 흔하다. 제품 비교표는 책이 나올 무렵이면 낡는다. 대신 사람과 AI가 일을 나누는 방식, 곧 작업 형태를 단위로 삼는다. 일반 chat, AI IDE, terminal agent, background agent의 네 가지다. 형태를 단위로 보면 빠르게 바뀌는 것(제품과 기능)과 오래 남는 것(분담의 구조)을 구분할 수 있다. +이 꼭지는 도구를 제품 단위로 비교하지 않는다. 제품의 기능은 몇 달 단위로 바뀌고, 한 회사가 채팅 앱, 편집기 확장, 명령줄 도구, 클라우드 에이전트를 함께 내놓는 경우도 흔하다. 제품 비교표는 책이 나올 무렵이면 낡는다. 대신 사람과 AI가 일을 나누는 방식, 곧 작업 형태를 단위로 삼는다. 일반 chat, AI IDE, terminal agent, background agent의 네 가지다. IDE는 통합 개발 환경(integrated development environment)으로, 코드 편집과 실행, 디버깅을 한 프로그램에서 하게 해 준다. 형태를 단위로 보면 빠르게 바뀌는 것(제품과 기능)과 오래 남는 것(분담의 구조)을 구분할 수 있다. 네 형태를 가르는 기준은 세 가지로 정리할 수 있다. 첫째, AI가 무엇을 보고 무엇을 바꿀 수 있는가. 대화에 붙여 넣은 코드만 보는지, 프로젝트 전체와 실행 환경까지 다루는지의 차이다. 둘째, 작업이 어떻게 진행되는가. 사람이 매 단계를 지켜보며 함께 진행하는지, 범위를 정해 맡기고 다른 일을 하다가 결과를 받는지의 차이다. 셋째, 무엇을 돌려받는가. 설명과 코드 조각인지, 변경 내역인지, 실행 기록과 테스트 결과까지인지의 차이다. 3.2의 대화, 실행, 위임은 이 기준을 따라 시간 순서로 나타난 단계였다. 지금은 네 형태가 함께 쓰이며, 같은 사람이 같은 프로젝트에서도 작업에 따라 형태를 바꾼다. @@ -31,13 +31,13 @@ AI IDE는 코드 편집기 안에 AI 기능이 들어간 형태다. Cursor처럼 ### terminal agent -terminal agent는 명령줄에서 실행되는 에이전트다. Anthropic의 Claude Code와 OpenAI의 Codex CLI가 대표적이다([Anthropic, Claude Code overview](https://code.claude.com/docs/en/overview) (확인: 2026-10-28); [OpenAI, Codex 문서](https://learn.chatgpt.com/docs) (확인: 2026-10-28)). 사용자는 터미널에서 에이전트를 띄우고 대화로 작업을 지시한다. 에이전트는 사용자의 컴퓨터에서 저장소의 파일을 찾아 읽고, 고치고, 테스트나 빌드 같은 명령을 직접 실행한 뒤 그 결과를 보고 다음 행동을 정한다. 돌려받는 것은 변경 내역과 함께 어떤 명령을 실행했고 무엇이 출력되었는지에 대한 기록이다. +terminal agent는 명령줄 인터페이스(command-line interface, CLI), 곧 터미널에서 실행되는 에이전트다. Anthropic의 Claude Code와 OpenAI의 Codex CLI가 대표적이다([Anthropic, Claude Code overview](https://code.claude.com/docs/en/overview) (확인: 2026-10-28); [OpenAI, Codex 문서](https://learn.chatgpt.com/docs) (확인: 2026-10-28)). 사용자는 터미널에서 에이전트를 띄우고 대화로 작업을 지시한다. 에이전트는 사용자의 컴퓨터에서 저장소의 파일을 찾아 읽고, 고치고, 테스트나 빌드 같은 명령을 직접 실행한 뒤 그 결과를 보고 다음 행동을 정한다. 돌려받는 것은 변경 내역과 함께 어떤 명령을 실행했고 무엇이 출력되었는지에 대한 기록이다. -이 형태는 사용자의 실제 개발 환경에서 동작한다는 점이 핵심이다. 설치된 라이브러리, 로컬 데이터, 설정 파일이 모두 그대로 쓰이므로, 코드가 정말 이 환경에서 돌아가는지를 에이전트가 직접 확인할 수 있다. 같은 이유로 에이전트의 행동이 실제 파일과 환경에 바로 영향을 준다. 그래서 대부분의 도구는 파일 수정이나 명령 실행 전에 사용자의 승인을 받는 단계를 두고, 그 승인을 어디까지 생략할지를 사용자가 정하게 한다. 승인과 샌드박스가 왜 필요한지는 8.3에서 다룬다. 사람에게 남는 일은 승인할지 판단하는 일과, 대화 흐름에 쌓인 실행 기록을 읽고 결과를 확인하는 일이다. 같은 도구를 대화 없이 한 번의 명령으로 실행해 스크립트나 자동화 흐름에 넣을 수도 있다. 이런 반복 실행에서 재시도와 중단 조건을 어떻게 설계할지는 6.2에서, 일정이나 이벤트에 맞춰 스스로 시작하는 상시형 에이전트는 16.3에서 다룬다. +이 형태는 사용자의 실제 개발 환경에서 동작한다는 점이 핵심이다. 설치된 라이브러리, 로컬 데이터, 설정 파일이 모두 그대로 쓰이므로, 코드가 정말 이 환경에서 돌아가는지를 에이전트가 직접 확인할 수 있다. 같은 이유로 에이전트의 행동이 실제 파일과 환경에 바로 영향을 준다. 그래서 대부분의 도구는 파일 수정이나 명령 실행 전에 사용자의 승인을 받는 단계를 두고, 그 승인을 어디까지 생략할지를 사용자가 정하게 한다. 승인 절차와 샌드박스(프로그램을 격리된 공간에서 실행해 바깥에 영향을 주지 않게 하는 장치)가 왜 필요한지는 8.3에서 다룬다. 사람에게 남는 일은 승인할지 판단하는 일과, 대화 흐름에 쌓인 실행 기록을 읽고 결과를 확인하는 일이다. 같은 도구를 대화 없이 한 번의 명령으로 실행해 스크립트나 자동화 흐름에 넣을 수도 있다. 이런 반복 실행에서 재시도와 중단 조건을 어떻게 설계할지는 6.2에서, 일정이나 이벤트에 맞춰 스스로 시작하는 상시형 에이전트는 16.3에서 다룬다. ### background agent -background agent는 작업을 맡기면 사용자가 지켜보지 않는 곳에서 진행하고 결과를 돌려주는 형태다. GitHub의 Copilot cloud agent, OpenAI의 Codex Cloud, Claude Code의 클라우드 세션, Cursor의 Cloud Agents가 이 방식으로 동작한다([GitHub, About Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent); [OpenAI, Codex Cloud](https://learn.chatgpt.com/docs/cloud); [Anthropic, Use Claude Code in the cloud](https://code.claude.com/docs/en/claude-code-on-the-web); [Cursor, Cloud Agents](https://cursor.com/docs/cloud-agent) (모두 확인: 2026-10-28)). 사용자는 웹 화면, 이슈나 풀 리퀘스트의 댓글, 편집기, 터미널 등에서 작업을 지시한다. 에이전트는 원격의 격리된 환경에 저장소를 복제하고, 필요한 의존성을 설치한 뒤, 파일을 고치고 테스트를 실행한다. 작업이 끝나면 변경 사항을 브랜치나 풀 리퀘스트로 올리고, 무엇을 바꿨는지와 테스트 결과를 돌려준다. 그동안 사용자는 다른 일을 할 수 있고, 여러 작업을 동시에 맡길 수도 있다. +background agent는 작업을 맡기면 사용자가 지켜보지 않는 곳에서 진행하고 결과를 돌려주는 형태다. GitHub의 Copilot cloud agent, OpenAI의 Codex Cloud, Claude Code의 클라우드 세션, Cursor의 Cloud Agents가 이 방식으로 동작한다([GitHub, About Copilot cloud agent](https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent); [OpenAI, Codex Cloud](https://learn.chatgpt.com/docs/cloud); [Anthropic, Use Claude Code in the cloud](https://code.claude.com/docs/en/claude-code-on-the-web); [Cursor, Cloud Agents](https://cursor.com/docs/cloud-agent) (모두 확인: 2026-10-28)). 사용자는 웹 화면, 이슈나 풀 리퀘스트의 댓글, 편집기, 터미널 등에서 작업을 지시한다. 에이전트는 원격의 격리된 환경에 저장소를 복제하고, 코드 실행에 필요한 라이브러리(의존성)를 설치한 뒤, 파일을 고치고 테스트를 실행한다. 작업이 끝나면 변경 사항을 브랜치나 풀 리퀘스트로 올리고, 무엇을 바꿨는지와 테스트 결과를 돌려준다. 그동안 사용자는 다른 일을 할 수 있고, 여러 작업을 동시에 맡길 수도 있다. 이 형태에서 사람의 일은 작업 전과 작업 후로 몰린다. 작업 전에는 무엇을 어디까지 할지, 어떤 상태가 되면 끝난 것인지를 정해 넘겨야 한다. 작업 중에 방향을 바로잡기 어려우므로, 이 단계가 부실하면 결과도 엉뚱해진다. 작업 후에는 돌아온 변경을 검토하고 받아들일지 정한다. 원격 환경에서 돌아간다는 점도 고려해야 한다. 내 컴퓨터에만 있는 데이터나 설정은 그 환경에 없고, 반대로 저장소와 작업에 필요한 정보는 그 환경으로 옮겨 간다. 완료 기준을 쓰는 방법은 6.1에서, 돌아온 결과를 검증하는 방법은 10장에서, 여러 작업을 맡기고 기다리는 일이 개인과 팀의 일과를 어떻게 바꾸는지는 15.1에서 다룬다. @@ -76,7 +76,7 @@ Barke 등은 프로그래머 20명이 코드 생성 도구인 GitHub Copilot으 이 구분이 형태 선택에 중요한 이유는, 탐색 중인 작업을 실행 중인 작업처럼 맡기면 정한 적 없는 결정이 코드에 굳어 버리기 때문이다. 결측치를 버릴지 채울지 정하지 않은 채 에이전트에게 "결측치를 처리해 달라"고 맡기면, 에이전트는 어느 쪽이든 하나를 골라 구현한다. 사용자는 돌아온 코드가 잘 돌아가는 것을 보고 그 선택을 기본값처럼 받아들이기 쉽다. 반대로 할 일이 분명한 작업을 대화로만 진행하면, 코드를 옮기고 실행하고 결과를 다시 전하는 일이 반복되어 시간이 든다. -그래서 형태를 고르기 전에 지금이 어느 상태인지부터 묻는 편이 좋다. 간단한 판단 신호는 완료 조건을 한 문장으로 쓸 수 있는가이다. "모든 숫자 열의 결측치를 열 평균으로 채우고, 처리 전후의 결측치 개수를 출력한다"처럼 쓸 수 있으면 실행할 준비가 된 것이다. "결측치를 적당히 처리한다" 이상으로 쓸 수 없다면 아직 탐색 중이다. 탐색 단계에서는 결과물이 가볍고 버리기 쉬운 형태가, 실행 단계에서는 변경을 곧바로 반영하고 확인할 수 있는 형태가 대체로 편하다. 다만 Barke 등의 연구는 자동완성 중심의 도구를 대상으로 했고, "탐색에는 이 형태, 가속에는 저 형태"라는 대응을 제시하지 않았다. 이 연결은 이 책의 해석이다. +그래서 형태를 고르기 전에 지금이 어느 상태인지부터 묻는 편이 좋다. 간단한 판단 신호는 완료 조건을 한 문장으로 쓸 수 있는가이다. "모든 숫자 열의 결측치를 열 평균으로 채우고, 처리 전후의 결측치 개수를 출력한다"처럼 쓸 수 있으면 실행할 준비가 된 것이다. "결측치를 적당히 처리한다" 이상으로 쓸 수 없다면 아직 탐색 중이다. 탐색 단계에는 결과물이 가볍고 버리기 쉬운 형태가, 실행 단계에는 변경을 곧바로 반영하고 확인할 수 있는 형태가 맞는다. 다만 Barke 등의 연구는 자동완성 중심의 도구를 대상으로 했고, "탐색에는 이 형태, 가속에는 저 형태"라는 대응을 제시하지 않았다. 이 연결은 이 책의 해석이다. 같은 프로젝트에서도 상태는 바뀐다. 처리 방법을 정하는 동안은 탐색이고, 정한 뒤 여러 파일에 반영하는 동안은 가속이다. 형태도 그에 맞춰 바꿀 수 있다. 무엇을 먼저 탐색하고 무엇부터 명세로 합의할지는 3.4에서 다루었다. @@ -86,19 +86,19 @@ AI가 다룰 수 있는 범위는 대략 네 단계로 넓어진다. 대화에 범위가 좁으면 AI는 사용자가 준 정보만으로 판단한다. 사용자가 빠뜨린 정보는 AI가 추측으로 채운다. 다른 파일에 정의된 함수의 이름, 설치된 라이브러리의 버전, 데이터의 실제 열 이름 같은 것들이 대표적이다. 그 결과 문법은 맞고 설명도 그럴듯하지만 실제 프로젝트에서는 돌아가지 않는 코드가 나올 수 있다. 이런 오류의 유형은 9.1에서 다룬다. 범위가 넓으면 AI가 직접 파일을 찾아 읽고 코드를 실행해 확인할 수 있으므로 이런 어긋남이 줄어든다. 대신 AI가 바꿀 수 있는 대상도 함께 늘어난다. 요청하지 않은 파일이나 설정까지 고치는 일이 생길 수 있고, 이 문제는 9.2에서 다룬다. -그러면 범위는 어디까지 열어야 하는가. 이 책이 제안하는 기준은 AI가 작업을 끝냈는지 스스로 확인하는 데 필요한 만큼이다. 그래프 함수 하나를 새로 쓰는 일이라면 대화에 함수의 입력과 출력을 설명하는 것으로 충분할 수 있다. 결측치 처리를 기존 전처리 모듈과 맞물려 넣어야 한다면 AI가 그 모듈과 호출하는 쪽 파일을 볼 수 있어야 한다. 처리 결과가 실제 데이터에서 맞게 나오는지까지 확인해야 한다면 코드를 실행할 수 있어야 한다. 판단 신호는 세 가지로 정리할 수 있다. 여러 파일을 함께 바꿔야 하는가, 결과를 확인하려면 실행이 필요한가, 프로젝트 바깥의 시스템을 건드려야 하는가. 하나라도 해당하면 대화만으로 진행하는 형태로는 부족할 가능성이 크다. +그러면 범위는 어디까지 열어야 하는가. 이 책이 제안하는 기준은 AI가 작업을 끝냈는지 스스로 확인하는 데 필요한 만큼이다. 그래프 함수 하나를 새로 쓰는 일이라면 대화에 함수의 입력과 출력을 설명하는 것으로 충분할 수 있다. 결측치 처리를 기존 전처리 모듈과 맞물려 넣어야 한다면 AI가 그 모듈과 호출하는 쪽 파일을 볼 수 있어야 한다. 처리 결과가 실제 데이터에서 맞게 나오는지까지 확인해야 한다면 코드를 실행할 수 있어야 한다. 여러 파일을 함께 바꿔야 하는 일, 결과를 확인하려면 실행이 필요한 일, 프로젝트 바깥의 시스템을 건드려야 하는 일은 대화만으로 진행하는 형태로는 부족할 가능성이 크다. 범위를 넓히는 구체적인 방법, 예를 들어 외부 문서나 서비스를 연결하는 방법은 7.3에서, 넓어진 범위 가운데 무엇을 골라 보여 줄지는 6.3에서 다룬다. ### 개입 방식: 작업 중에 판단할 것인가, 끝난 뒤에 검토할 것인가 -사람이 개입하는 방식은 세 수준으로 나눌 수 있다. 매 응답을 보고 다음 요청을 정하며 함께 진행하는 방식, AI가 진행하되 파일을 바꾸거나 명령을 실행할 때마다 승인하는 방식, 범위를 정해 맡긴 뒤 끝난 결과를 검토하는 방식이다. 일반 chat, AI IDE, terminal agent는 대체로 앞의 두 방식으로 진행되고, background agent는 세 번째 방식에 가깝다. 앞서 말했듯 같은 terminal agent라도 승인 설정에 따라 두 번째와 세 번째 사이를 오갈 수 있다. +사람이 개입하는 방식은 세 수준으로 나눌 수 있다. 매 응답을 보고 다음 요청을 정하며 함께 진행하는 방식, AI가 진행하되 파일을 바꾸거나 명령을 실행할 때마다 승인하는 방식, 범위를 정해 맡긴 뒤 끝난 결과를 검토하는 방식이다. 일반 chat, AI IDE, terminal agent는 주로 앞의 두 방식으로 진행되고, background agent는 세 번째 방식에 가깝다. 앞서 말했듯 같은 terminal agent라도 승인 설정에 따라 두 번째와 세 번째 사이를 오갈 수 있다. 개입이 줄어든다고 사람의 판단이 줄어드는 것은 아니다. 판단이 일어나는 시점이 작업 중에서 작업 전과 작업 후로 옮겨 갈 뿐이다. 함께 진행할 때는 방향이 어긋나는 순간 바로 바로잡을 수 있다. 맡기고 기다릴 때는 그럴 수 없으므로, 작업 전에 범위와 완료 기준을 더 분명히 정해야 하고, 작업 후에는 그동안 일어난 일을 한꺼번에 검토해야 한다. 그러니 개입을 줄이는 선택은 검토를 뒤로 미루는 선택에 가깝다. 이 정리는 연구 결과에서 나온 것이 아니고 이 책의 제안이다. 매 단계 승인하는 방식이 늘 안전한 것도 아니다. 승인 요청이 잦으면 사람은 내용을 읽지 않고 습관처럼 허용하게 되기 쉽다. 승인을 어느 지점에 둘지는 6.4에서 자세히 다룬다. -판단 신호는 세 가지다. 진행 중에 방향이 바뀔 가능성이 큰가. 되돌리기 어려운 변경이 포함되는가. 나는 결과를 보기 전에 무엇이 맞는지 판단할 기준을 갖고 있는가. 앞의 둘에 해당하거나 마지막 질문에 답하기 어렵다면 함께 진행하는 쪽이 낫다. 예를 들어 그래프의 모양을 보면서 축과 색을 다듬어야 한다면, 맡기고 기다리기보다 결과를 바로 보며 고치는 편이 빠르다. 반대로 이미 정한 결측치 처리 규칙을 여러 분석 스크립트에 똑같이 적용하는 일이라면, 범위를 정해 맡기고 끝난 뒤 검토할 수 있다. 실패했을 때 몇 번까지 다시 시도하고 언제 멈출지는 6.2에서 다룬다. +함께 진행하는 쪽이 나은 경우는 진행 중에 방향이 바뀔 가능성이 클 때, 되돌리기 어려운 변경이 포함될 때, 결과를 보기 전에는 무엇이 맞는지 판단할 기준이 없을 때다. 예를 들어 그래프의 모양을 보면서 축과 색을 다듬어야 한다면, 맡기고 기다리기보다 결과를 바로 보며 고치는 편이 빠르다. 반대로 이미 정한 결측치 처리 규칙을 여러 분석 스크립트에 똑같이 적용하는 일이라면, 범위를 정해 맡기고 끝난 뒤 검토할 수 있다. 실패했을 때 몇 번까지 다시 시도하고 언제 멈출지는 6.2에서 다룬다. ### 검토 가능성: 무엇을 돌려받아야 끝났다고 판단할 수 있는가 @@ -114,7 +114,7 @@ AI가 다룰 수 있는 범위는 대략 네 단계로 넓어진다. 대화에 ### 실행 위치: 작업은 어디에서 돌아가고 데이터는 어디로 가는가 -마지막 고려사항은 AI가 실행하는 코드와 읽는 데이터가 어디에 있는가이다. terminal agent는 대개 사용자의 컴퓨터에서 동작하고, background agent는 대개 원격의 격리된 환경에서 동작한다. 일반 chat에 붙여 넣은 내용과 AI IDE가 참고하는 파일도, 모델을 외부 서비스로 쓰는 한 그 서비스의 서버로 전송된다. +마지막 고려사항은 AI가 실행하는 코드와 읽는 데이터가 어디에 있는가이다. terminal agent는 사용자의 컴퓨터에서 동작하고, background agent는 원격의 격리된 환경에서 동작한다. 조직에 따라 이 원격 환경을 자체 서버에 두기도 한다. 일반 chat에 붙여 넣은 내용과 AI IDE가 참고하는 파일도, 모델을 외부 서비스로 쓰는 한 그 서비스의 서버로 전송된다. 로컬에서 실행하면 내 환경 그대로 결과를 확인할 수 있지만, 에이전트의 행동이 내 파일과 환경에 직접 영향을 준다. 원격 격리 환경에서 실행하면 내 컴퓨터와 분리되어 있어 실수의 영향이 그 환경 안에 머무른다. 대신 저장소와 작업에 필요한 데이터가 그 환경으로 옮겨 가야 하고, 내 컴퓨터에만 있는 데이터나 설정은 쓸 수 없다. @@ -130,16 +130,16 @@ AI가 다룰 수 있는 범위는 대략 네 단계로 넓어진다. 대화에 |---|---|---|---|---|---| | 일반 chat | 방법을 찾을 때 쓰기 쉽다 | 대화에 넣은 내용 | 매 응답을 보고 다음 요청 | 설명, 코드 조각, 선택지 | 코드 실행은 사용자 몫, 대화 내용은 서버로 전송 | | AI IDE | 정한 일을 반영할 때 쓰기 쉽다 | 프로젝트 파일 (도구에 따라 실행 포함) | 변경마다 수락 | 파일별 diff | 사용자 컴퓨터의 편집기 | -| terminal agent | 실행해 봐야 알 수 있는 일 | 저장소와 로컬 실행 환경 | 설정에 따라 단계별 승인부터 사후 검토까지 | diff와 실행 기록 | 대개 사용자 컴퓨터 | -| background agent | 범위와 완료 기준이 분명한 일 | 원격 환경에 복제된 저장소 | 범위를 정해 맡기고 사후 검토 | 브랜치나 풀 리퀘스트, 변경 요약, 테스트 결과 | 대개 원격 격리 환경 | +| terminal agent | 실행해 봐야 알 수 있는 일 | 저장소와 로컬 실행 환경 | 설정에 따라 단계별 승인부터 사후 검토까지 | diff와 실행 기록 | 사용자 컴퓨터 | +| background agent | 범위와 완료 기준이 분명한 일 | 원격 환경에 복제된 저장소 | 범위를 정해 맡기고 사후 검토 | 브랜치나 풀 리퀘스트, 변경 요약, 테스트 결과 | 원격 격리 환경 | 이 표는 경향을 정리한 것이다. 칸마다 정답이 정해져 있다는 뜻이 아니며, 같은 도구도 설정과 쓰는 방식에 따라 다른 칸에 놓일 수 있다. -다섯 가지를 따지는 순서에도 일정한 흐름이 있다. 먼저 실행 위치에서 걸리는 조건이 없는지 본다. 다룰 데이터를 AI 도구에 넣을 수 없다면 나머지를 따지기 전에 선택지가 줄어든다. 다음으로 작업 상태를 묻는다. 아직 방법을 찾는 중이라면 결과물이 가볍고 바로 확인할 수 있는 형태로 시작하고, 정해야 할 것을 먼저 정한다. 할 일이 분명해졌다면 작업 범위와 개입 방식을 함께 정한다. AI가 끝났는지 스스로 확인하는 데 필요한 만큼 범위를 열고, 방향이 바뀔 가능성과 되돌리기 어려운 정도에 맞춰 개입 수준을 정한다. 마지막으로 검토 가능성을 확인한다. 맡기고 기다리는 형태를 쓰려면 완료 기준과 확인 수단이 먼저 있어야 하고, 둘 중 하나가 없으면 함께 진행하는 형태로 돌아간다. +다섯 가지를 따지는 순서에도 일정한 흐름이 있다. 먼저 실행 위치에서 걸리는 조건이 없는지 본다. 다룰 데이터를 AI 도구에 넣을 수 없다면 나머지를 따지기 전에 선택지가 줄어든다. 다음으로 작업 상태를 묻는다. 아직 방법을 찾는 중이라면 결과물이 가볍고 바로 확인할 수 있는 형태로 시작하고, 정해야 할 것을 먼저 정한다. 할 일이 분명해진 뒤에는 작업 범위와 개입 방식을 함께 정한다. AI가 끝났는지 스스로 확인하는 데 필요한 만큼 범위를 열고, 방향이 바뀔 가능성과 되돌리기 어려운 정도에 맞춰 개입 수준을 정한다. 마지막으로 검토 가능성을 확인한다. 맡기고 기다리는 형태를 쓰려면 완료 기준과 확인 수단이 먼저 있어야 하고, 둘 중 하나가 없으면 함께 진행하는 형태로 돌아간다. 이 순서는 한 번 정하고 끝나는 절차가 아니다. 같은 결측치 처리 작업도 처리 방법을 고르는 동안에는 대화로 탐색하고, 방법을 정한 뒤에는 편집기에서 기존 코드에 반영하고, 실제 데이터로 돌려 봐야 할 때는 실행할 수 있는 환경으로 옮기고, 같은 규칙을 다른 스크립트에 적용하는 일은 범위를 정해 맡길 수 있다. 작업이 진행되면서 상태가 바뀌면 형태도 다시 고른다. -정리하면, AI 코딩 도구를 고르는 일은 이번 작업에서 AI가 무엇을 다루고, 사람이 언제 개입하고, 무엇을 돌려받아 검토할지를 정하는 일이다. 제품의 이름과 기능은 빠르게 바뀌지만, 이 세 가지를 묻는 방식은 도구가 바뀌어도 그대로 쓸 수 있다. +AI 코딩 도구를 고르는 일은 이번 작업에서 AI가 무엇을 다루고, 사람이 언제 개입하고, 무엇을 돌려받아 검토할지를 정하는 일이다. ## 이후 장에서 이어지는 내용