Claude Code 시리즈 튜토리얼 3: 왜 터미널만 제공하는가

1.3 왜 터미널에서 코드를 작성해야 할까?

비유를 들어 보자: 새로운 기능을 작성하고 있는데 갑자기 세 파일에 흩어져 있고 일부 호출이 모듈을 넘나드는 하위 수준의 유틸리티 함수를 수정해야 한다고 하자. 편집기를 열고 전역 검색을 한 뒤 파일을 하나하나 넘기며 조심스럽게 수정하고, 다시 테스트를 돌리면—실패. 에러 메시지를 보고 스택을 추적하고, 고치고, 다시 실행한다.

이 과정에서 '어떻게 고칠지'를 진지하게 고민하는 시간은 절반도 안 될 수 있다. 나머지 절반은 기계적인 작업, 즉 파일 찾기, 참조 수정, 컴파일 대기, 마우스 클릭 등이다.

AI를 터미널에 넣는 주된 목적은 이런 기계적인 작업을 압축하는 것이다.

터미널은 코드에 가장 가까운 곳

VS Code, JetBrains, Vim 등 어떤 편집기를 사용하든 코드 작성 과정에서 터미널을 피할 수 없다. npm test, git log, grep, make build 같은 작업은 본질적으로 명령줄에서 수행된다.

그렇다면 AI 파트너가 같은 터미널에 자리 잡고 있으면 상황이 훨씬 간단해진다. 파일 내용을 채팅 창에 복사해서 붙여넣을 필요도 없고, '내 프로젝트에 UserService라는 클래스가 있는데 src/services/user.ts 42번째 줄에 있어요'라고 직접 설명할 필요도 없다. Claude Code는 프로젝트 루트에 위치하므로 스스로 확인할 수 있다.

이는 컨텍스트의 차원이 다른 압도적인 우위다. Claude Code에게 '로그인 모듈의 오류 처리를 리팩토링해 줘'라고 말하면 실제로 auth/login.ts와 errors.ts를 읽고, 호출하는 모든 곳을 찾은 후 직접 수정한다. 중간에 데이터를 전달할 필요가 없다.

'조작자' 역할에서 해방되기

브라우저 기반 AI 채팅을 사용할 때 우리는 종종 무의식적으로 '중개자' 역할을 한다: AI가 코드를 출력하면 우리가 읽고 검증하며 복사한 후 다시 편집기에 붙여넣는다. 코드가 돌아가면 모든 게 좋고, 그렇지 않으면 오류 메시지를 복사해서 다시 질문하고 또 복사한다. 이 과정은 몰입을 자주 방해한다.

Claude Code의 설계 철학은 사용자를 다시 '사고자'의 위치로 되돌리는 것이다. 아이디어를 말하면 AI가 실행한다. 수정 후 터미널에서 바로 diff를 확인하고 수용 여부를 결정할 수 있다. 또한 테스트나 린트를 실행해 주기도 한다. 사용자는 대부분의 시간을 코드를 읽고 결정을 내리는 데 쓰며, 창을 반복해서 전환하지 않는다.

편집기 플러그인이 아닌 이유는?

이쯤에서 궁금할 수 있다: 그렇다면 편집기에 AI 플러그인을 직접 넣지 않는 이유는 무엇일까?

편집기 플러그인도 물론 유용하며 많은 팀이 이미 사용하고 있다. 하지만 터미널의 Claude Code는 플러그인으로 대체하기 어려운 몇 가지 장점이 있다:

편집기에 구속되지 않는다. 오늘 VS Code를 쓰다가 내일 Neovim으로 바꾸거나 GUI가 없는 원격 서버에서도 Claude Code를 사용할 수 있다. 도구 선택과 무관하다.
더 '파격적인' 일을 할 수 있다. 터미널에서는 어떤 셸 명령이든 실행할 수 있다. 즉, 할 수 있는 일의 범위가 훨씬 넓다—데이터베이스 마이그레이션을 검증하기 위해 Docker 컨테이너를 시작하거나, 원격 브랜치를 가져와 충돌을 확인하거나, 코드 수정 후 e2e 테스트를 자동으로 실행할 수 있다. 이러한 작업은 편집기 플러그인이 일반적으로 쉽게 하지 못하거나 아예 할 수 없다.
일괄 처리 및 자동화. Claude Code를 스크립트에 넣어 수십 개의 리포지토리를 처리하거나, 문서를 일괄 생성하거나, 이슈를 자동으로 처리할 수 있다. 이때는 더 이상 '도우미'가 아니라 파이프라인의 한 부분이 된다.

내 경험담

얼마 전 약 2만 줄의 JavaScript 프로젝트를 TypeScript로 마이그레이션해야 했다. 내 접근 방식은 수동으로 파일마다 타입을 추가하거나 편집기 플러그인이 모든 것을 처리할 거라고 기대하는 것이 아니었다.

프로젝트 디렉터리에서 Claude Code를 시작하고 다음과 같이 지시했다: '이 프로젝트를 점진적으로 TypeScript 엄격 모드로 마이그레이션해. 한 번에 몇 개의 파일씩 수정하고, 수정이 끝날 때마다 tsc --noEmit을 실행해. 오류가 있으면 스스로 고쳐서 전부 통과할 때까지 반복해.'

다음 30분 동안 내가 한 일은 기본적으로 단 한 가지였다: AI가 수정한 diff를 보고 승인하거나 거절하는 것. 가끔 '여기 타입은 any 말고 interface를 정의해'라고 말하면 계속 작업을 이어갔다. 최종적으로 프로젝트 컴파일이 통과되었고 예상 시간보다 몇 배나 빨랐다.

물론 이것이 Claude Code가 플러그인보다 더 똑똑하다는 의미는 아니다. 하지만 스스로 '수정-검증-수정'의 닫힌 루프를 완성할 수 있다는 점이 채팅형 AI와의 가장 근본적인 차이점이다.

결국 터미널은 AI에게 손발을 준 셈

AI를 터미널에 넣는 것은 본질적으로 제안 능력뿐만 아니라 실행 능력을 부여하는 것이다.

이를 통해 코드 리포지토리는 더 이상 읽기만 가능한 텍스트 더미가 아니라 AI가 '만지고' 수정하고 검증할 수 있는 실제 환경이 된다. 이것은 엄청난 도약이다.

여전히 프로젝트의 방향과 모든 주요 결정은 사용자가 쥐고 있지만, 지루하고 창의성이 낮으며 반복적인 작업은 더 적합한 담당자를 찾은 것이다.