7부 34장. CLI 기반 AI 도구는 왜 강력한가

많은 사람이 AI를 처음 만나는 장소는 웹 채팅 창이다. 질문을 입력하면 답이 돌아오고, 코드를 붙이면 설명을 해 주고, 에러 메시지를 넣으면 원인을 추정해 준다. 이 방식은 분명 편하다. 가볍게 묻고, 빠르게 답을 얻기에는 아주 좋다.

그런데 개발을 조금 깊게 해 본 사람일수록 어느 순간 이런 생각을 하게 된다.

"답변은 괜찮은데, 내가 결국 직접 다 옮겨야 하네."

코드를 복사해 에디터에 붙여 넣고, 파일을 찾아 수정하고, 터미널로 돌아가 테스트를 돌리고, 실패하면 다시 에러를 복사해 채팅창에 넣는다. 이 과정이 한두 번이면 괜찮다. 하지만 실제 작업은 보통 여러 파일과 여러 명령, 여러 차례의 확인을 동반한다. 이때부터는 '잘 대답하는 AI'보다 '내 작업 환경 안에서 움직이는 AI'가 훨씬 더 강해진다.

바로 여기서 CLI 기반 AI 도구의 힘이 나온다. CLI는 Command Line Interface, 즉 터미널에서 명령어로 작업하는 환경을 뜻한다. 말이 어렵게 들릴 수 있지만, 개발자에게는 아주 익숙한 공간이다. 코드를 실행하고, 테스트를 돌리고, 파일을 찾고, 로그를 보고, Git으로 변경 사항을 확인하는 곳이 바로 터미널이다.

이번 장에서는 왜 많은 고급 사용자가 웹 채팅보다 CLI 환경을 선호하는지, 그리고 파일 시스템과 터미널에 연결된 AI가 왜 생산성을 크게 끌어올리는지 차근차근 살펴보자.

웹 채팅의 AI와 CLI의 AI는 무엇이 다른가

겉으로 보면 둘 다 같은 모델처럼 보일 수 있다. 둘 다 질문에 답하고, 코드도 써 주고, 설명도 해 준다. 하지만 실제로는 일하는 자리가 다르다.

웹 채팅의 AI는 주로 대화 공간에서 일한다. 사용자가 텍스트를 넣어 주면 그것을 바탕으로 대답한다. 문서를 붙여 넣으면 읽고, 에러를 복사해 오면 해석한다. 즉, 사용자가 맥락을 가져다줘야 한다.

반면 CLI의 AI는 작업 공간에서 일한다. 현재 디렉터리에 어떤 파일이 있는지 볼 수 있고, 필요한 파일을 열어 읽을 수 있으며, 명령을 실행해 실제 결과를 확인할 수 있다. 즉, 사용자가 일일이 중계하지 않아도 맥락에 더 가까이 다가갈 수 있다.

이 차이는 아주 작아 보여도 실제 체감은 크다.

웹 채팅에서는 보통 이런 식이다.

에러를 복사한다. 관련 코드를 복사한다. 폴더 구조를 설명한다. 실행 환경을 글로 적는다. 답변을 다시 복사해 와서 적용한다. 그리고 터미널에서 직접 확인한다.

CLI에서는 흐름이 더 짧아진다.

AI가 저장소를 훑어본다. 관련 파일을 읽는다. 실패한 테스트를 실행한다. 원인을 추정한다. 코드를 고친다. 다시 테스트한다. 마지막으로 변경 내용을 요약한다.

즉, 웹 채팅은 설명과 제안에 강하고, CLI는 탐색과 실행에 강하다.

강력함의 핵심은 답변이 아니라 연결이다

CLI 기반 AI 도구를 이해할 때 가장 중요한 단어는 '연결'이다. 단순히 말 잘하는 모델이 아니라, 실제 개발 흐름의 요소들과 연결되어 있다는 점이 핵심이다.

개발 작업은 생각보다 분절적이다. 코드를 읽다가 테스트를 돌리고, 테스트 결과를 보고 다시 파일을 열고, grep이나 ripgrep 같은 검색 도구로 관련 코드를 찾고, Git diff로 변경 범위를 확인한다. 개발자는 하루 종일 이 조각난 행동들을 이어 붙이며 일한다.

CLI 기반 AI는 이 조각들을 하나의 흐름으로 묶어 준다. 그래서 강하다.

예를 들어 버그 하나를 고친다고 해 보자. 웹 채팅에서는 개발자가 중간중간 모든 상황을 전달해야 한다. 하지만 CLI 환경에서는 AI가 직접 실패한 테스트를 보고, 어떤 파일이 관련 있는지 찾고, 수정 후 다시 검증할 수 있다. 이때 생산성 차이는 단순히 몇 줄의 코드를 대신 써 주는 수준을 넘어선다. 문맥 전환 비용이 줄어들기 때문이다.

생산성을 깎아먹는 가장 큰 적 중 하나는 타이핑 속도 부족이 아니라, 작업 맥락이 자꾸 끊기는 일이다. 브라우저와 에디터, 터미널과 문서를 오가는 동안 집중력은 계속 흔들린다. CLI 기반 AI는 바로 그 흔들림을 줄여 준다.

터미널은 원래 개발의 실행실이다

많은 초보자는 터미널을 조금 딱딱한 장소처럼 느낀다. 하지만 개발자에게 터미널은 단순한 검은 화면이 아니다. 실제로 일이 굴러가는 실행실에 가깝다.

여기서 개발자는 이런 일을 한다.

• 프로젝트를 실행한다

• 테스트를 돌린다

• 패키지를 설치한다

• 로그를 확인한다

• 파일과 폴더를 검색한다

• Git 상태와 차이를 본다

• 서버나 컨테이너에 접속한다

즉, 터미널은 설명의 공간이 아니라 검증의 공간이다. 코드가 맞는지 틀린지, 가설이 통하는지 안 통하는지, 지금 시스템이 어떤 상태인지가 여기서 드러난다.

그래서 AI가 터미널에 들어온다는 것은 단순히 인터페이스가 바뀌는 일이 아니다. AI가 드디어 결과를 확인할 수 있는 자리에 앉는다는 뜻이다.

사람 개발자도 그렇다. 설명만 듣고는 확신하기 어렵다. 직접 실행해 보고, 깨지는 지점이 어디인지 보고, 수정이 정말 통했는지 확인해야 한다. CLI 기반 AI의 강점은 바로 여기에 있다. 그럴듯한 말을 하는 것을 넘어서, 실제 실행 결과를 작업에 반영할 수 있다.

파일 시스템 접근이 왜 그렇게 중요한가

개발 작업은 거의 언제나 파일 위에서 이루어진다. 코드 파일, 설정 파일, 테스트 파일, 환경 변수 파일, 문서 파일이 얽혀 있다. 실제 문제는 한 파일 안에만 있지 않은 경우가 많다.

웹 채팅 AI는 보통 사용자가 붙여 넣은 일부 코드만 본다. 그래서 답변도 그 일부를 기준으로 나온다. 물론 짧은 문제에는 충분하다. 하지만 실무에서는 문제가 주변 맥락에 숨어 있는 경우가 많다. 함수 정의는 여기 있는데, 타입은 다른 파일에 있고, 설정은 또 다른 디렉터리에 있으며, 실패 원인은 테스트 데이터나 환경 설정에 있을 수 있다.

CLI 기반 AI는 파일 시스템에 접근하면서 이 주변 맥락을 직접 찾을 수 있다. 이것이 큰 차이를 만든다.

예를 들어 "이 함수가 왜 실패하나요?"라는 질문은 사실 함수 한 줄만 보면 답이 안 나올 때가 많다. 호출하는 쪽, 반환 타입, 예외 처리, 설정 값, 테스트 픽스처까지 봐야 할 수 있다. 파일 시스템을 볼 수 있는 AI는 이 연결을 따라갈 수 있다. 그래서 더 현실적인 답을 내놓을 가능성이 높아진다.

쉽게 말하면 이렇다.

웹 채팅 AI는 사용자가 가져다준 조각을 보고 추리하는 탐정에 가깝고, CLI 기반 AI는 현장에 직접 들어가 주변을 둘러볼 수 있는 탐정에 가깝다.

고급 사용자가 CLI를 선호하는 첫 번째 이유: 복사-붙여넣기가 사라진다

고급 사용자는 대개 시간을 아주 이상한 곳에서 잃지 않는다. 코드 한 줄 더 빨리 치는 것보다, 불필요한 왕복을 줄이는 데 민감하다.

웹 채팅 기반 작업은 생각보다 왕복이 많다. 에러를 붙이고, 답을 받고, 코드를 붙이고, 다시 결과를 붙인다. 사람이 중간에서 계속 물류센터 역할을 해야 한다. 이게 반복되면 꽤 피곤하다.

CLI 기반 AI는 이 중간 운반 과정을 크게 줄여 준다. 현재 프로젝트 안에서 바로 파일을 읽고, 수정하고, 실행하고, 결과를 다시 볼 수 있기 때문이다.

이 차이는 단순한 편의가 아니다. 작업 리듬을 바꾼다. 손이 덜 바쁘면 머리는 더 중요한 판단에 쓸 수 있다. 그래서 숙련된 사용자는 자주 말한다. 좋은 도구는 '대단한 답'을 한 번 주는 도구가 아니라, '사소한 마찰'을 계속 줄여 주는 도구라고.

CLI 기반 AI는 바로 그 마찰 감소 장치에 가깝다.

두 번째 이유: 로컬 맥락이 훨씬 풍부하다

고급 사용자가 CLI를 선호하는 또 다른 이유는 로컬 환경의 정보량이 훨씬 많기 때문이다.

웹 채팅은 보통 대화창 안에 들어온 정보만 다룬다. 반면 로컬 작업 환경에는 이미 엄청난 맥락이 깔려 있다. 프로젝트 구조, 파일 이름 규칙, 테스트 스크립트, 린트 설정, 패키지 버전, Git 기록, README, 예전 코드 스타일이 모두 여기에 있다.

숙련된 개발자는 안다. 좋은 코드는 단지 문법적으로 맞는 코드가 아니다. 그 프로젝트에서 자연스러운 코드여야 한다. 이름 짓는 방식, 에러 처리 스타일, 테스트 관습, 디렉터리 구조를 따라야 한다.

CLI 기반 AI는 이런 로컬 맥락을 더 쉽게 읽을 수 있다. 그래서 "일반적으로 맞는 코드"보다 "이 저장소에서 어울리는 코드"를 만들 가능성이 높아진다.

이 차이는 생각보다 중요하다. 실무에서 정말 시간을 잡아먹는 것은 코드를 처음 쓰는 일보다, 기존 시스템과 어긋난 코드를 나중에 다시 맞추는 일인 경우가 많기 때문이다.

세 번째 이유: 실행과 검증이 붙어 있다

코드는 글과 다르다. 읽기 좋아 보여도 실행하면 깨질 수 있다. 그래서 개발에서는 생성보다 검증이 중요하다.

CLI 기반 AI가 강한 가장 현실적인 이유 중 하나는 바로 검증 루프를 바로 돌릴 수 있다는 점이다. 코드를 수정한 뒤 테스트를 실행하고, 린트를 확인하고, 빌드를 돌리고, 결과를 보고 다시 고칠 수 있다.

이때 AI의 역할은 단순한 생성기가 아니라 작은 작업 루프를 굴리는 조수로 바뀐다.

예를 들어 실패한 테스트 하나를 고치는 작업을 생각해 보자. 이 작업은 보통 다음처럼 진행된다.

문제를 재현한다. 관련 파일을 읽는다. 수정한다. 테스트를 다시 돌린다. 여전히 실패하면 다른 원인을 찾는다. 통과하면 변경 범위를 점검한다.

CLI 환경에서는 이 루프가 자연스럽다. 반면 웹 채팅에서는 사용자가 매 단계의 결과를 다시 가져와야 한다. 그래서 숙련자는 검증이 필요한 작업일수록 CLI를 선호한다. 말 잘하는 답보다 실제로 확인된 결과가 더 믿을 만하기 때문이다.

네 번째 이유: 작은 도구들을 조합할 수 있다

CLI의 문화는 원래부터 '하나의 큰 마법'보다 '작은 도구들의 조합'에 가깝다. 검색 도구, 텍스트 처리 도구, 테스트 명령, Git 명령, 빌드 스크립트가 서로 이어진다.

AI가 이 환경에 들어오면 단독 영웅이 되기보다 기존 도구 생태계에 합류한다. 이것이 강력하다.

예를 들어 AI는 스스로 모든 것을 기억할 필요가 없다. 파일 검색은 검색 도구를 쓰고, 테스트는 테스트 러너를 쓰고, 변경 확인은 Git diff를 보면 된다. 잘하는 일을 기존 도구에 맡기고, 그 결과를 읽어 다음 행동을 정하면 된다.

이 구조는 의외로 안정적이다. 왜냐하면 AI가 혼자 상상으로 밀어붙이는 비중이 줄어들기 때문이다. 실제 도구의 출력과 상태를 보면서 움직이면 엉뚱한 방향으로 오래 달려갈 가능성이 줄어든다.

그래서 CLI 기반 AI는 단순히 "터미널에서 채팅하는 AI"가 아니다. 더 정확히 말하면 터미널 생태계와 협력하는 AI다.

다섯 번째 이유: 작업 기록이 남고 재현하기 쉽다

고급 사용자는 결과만큼 과정을 중시한다. 특히 팀으로 일할 때는 더 그렇다. 무엇을 바꿨는지, 어떤 명령을 실행했는지, 왜 그런 결정을 했는지가 중요하다.

CLI 환경은 원래 작업 흔적이 남기 쉬운 장소다. 실행한 명령, 변경된 파일, 테스트 결과, Git diff가 비교적 명확하다. 그래서 AI가 한 일도 사람이 검토하기가 좋다.

이 점은 실무에서 매우 중요하다. AI가 만든 결과가 괜찮아 보여도, 어떻게 거기까지 갔는지 알 수 없다면 신뢰하기 어렵다. 반면 CLI에서는 보통 다음이 더 잘 보인다.

• 어떤 파일을 읽었는가

• 어떤 파일을 수정했는가

• 어떤 명령을 실행했는가

• 테스트나 빌드 결과가 어땠는가

• 최종 diff가 무엇인가

즉, CLI 기반 AI는 '한 번 그럴듯하게 답하는 도구'보다 '검토 가능한 작업 흔적을 남기는 도구'에 더 가깝다. 고급 사용자가 이런 도구를 좋아하는 이유는, 신뢰가 감이 아니라 확인에서 나오기 때문이다.

여섯 번째 이유: 원격 환경까지 같은 방식으로 다룰 수 있다

개발은 꼭 내 노트북 안에서만 일어나지 않는다. 서버, 컨테이너, 가상 환경, 원격 머신, CI 환경과 연결되는 경우가 많다. 이때 CLI는 유난히 강하다.

터미널은 원래 로컬과 원격의 경계를 비교적 자연스럽게 넘나든다. SSH로 서버에 접속하고, 컨테이너 안에서 명령을 실행하고, 로그를 확인하고, 배포 환경을 점검하는 일은 CLI의 익숙한 작업이다.

그래서 CLI 기반 AI는 장기적으로 더 넓은 작업 범위를 가질 수 있다. 단순히 코드 조각을 쓰는 일을 넘어서, 실행 환경을 살피고, 문제를 재현하고, 운영 맥락과 연결되는 흐름으로 확장되기 쉽다.

물론 이때는 권한과 안전 장치가 매우 중요하다. 하지만 가능성의 크기만 보면, 브라우저 안에 갇힌 AI보다 훨씬 넓은 작업 공간을 갖게 된다.

실제로 어떤 작업에서 차이가 크게 나는가

CLI 기반 AI의 진짜 가치는 복잡한 설명보다 실제 장면을 보면 더 잘 느껴진다.

예를 들어 테스트가 깨진 프로젝트가 있다고 하자. 웹 채팅에서는 보통 실패 로그를 복사해서 붙여 넣고, 관련 코드도 일부 가져와야 한다. AI는 수정안을 제안하지만, 적용과 검증은 결국 사람이 한다.

CLI 기반 AI라면 흐름이 달라진다. 실패한 테스트를 직접 실행해 보고, 관련 모듈을 찾고, 코드를 수정한 뒤 다시 테스트를 돌릴 수 있다. 그 결과 통과 여부까지 포함해 작업이 하나로 이어진다.

또 다른 예로, 여러 파일에 걸친 리팩터링을 생각해 보자. 함수 이름을 바꾸고 호출부를 수정하고 타입 정의와 테스트까지 손봐야 하는 작업이다. 웹 채팅은 이런 일을 도와줄 수는 있어도, 전체 범위를 스스로 따라가기는 어렵다. 반면 CLI 기반 AI는 검색, 수정, 검증을 반복하며 훨씬 실무적인 방식으로 움직일 수 있다.

즉, 이런 작업에서 차이가 커진다.

• 여러 파일이 연결된 수정

• 테스트나 빌드 확인이 필요한 작업

• 코드베이스 탐색이 먼저 필요한 작업

• 반복적이고 구조적인 변경 작업

• 사람의 복사-붙여넣기 왕복이 많은 작업

이런 일들은 모두 웹 채팅보다 CLI가 유리하다.

그렇다고 웹 채팅이 쓸모없다는 뜻은 아니다

여기서 오해하면 안 된다. CLI가 강력하다고 해서 웹 채팅이 쓸모없다는 뜻은 전혀 아니다. 둘은 역할이 다르다.

웹 채팅은 여전히 아주 좋다. 특히 개념을 물을 때, 방향을 잡을 때, 낯선 기술을 이해할 때, 아이디어를 빠르게 넓힐 때 강하다. 아직 프로젝트에 들어가지 않아도 되는 초기 탐색 단계에서는 오히려 웹 채팅이 더 편할 때도 많다.

반면 CLI는 실제 작업을 밀어 넣는 데 강하다. 이미 저장소가 있고, 고쳐야 할 파일이 있고, 실행과 검증이 필요한 순간에는 CLI의 가치가 커진다.

쉽게 나누면 이렇다.

웹 채팅은 생각을 넓히는 장소에 가깝고, CLI는 작업을 굴리는 장소에 가깝다.

잘하는 사람은 둘 중 하나만 고집하지 않는다. 문제를 이해할 때는 대화형 도구를 쓰고, 실제 수정과 검증은 CLI로 가져가는 식으로 섞어 쓴다.

CLI 기반 AI를 잘 쓰려면 무엇을 알려줘야 하는가

CLI 도구가 강력하다고 해서, 아무 말만 던지면 완벽하게 일하는 것은 아니다. 오히려 작업 공간에 가까운 도구일수록 더 분명한 지시가 중요하다.

특히 다음 다섯 가지가 중요하다.

• 목표: 무엇을 해결하려는가

• 범위: 어디까지 바꿔도 되는가

• 성공 기준: 무엇이 되면 끝난 것인가

• 검증 방법: 어떤 테스트나 명령으로 확인할 것인가

• 금지 사항: 건드리면 안 되는 영역은 무엇인가

예를 들어 "버그 고쳐 줘"보다 "로그인 후 세션 만료 처리 버그를 수정하고, 관련 테스트를 통과시켜 줘. 데이터베이스 스키마는 변경하지 마"가 훨씬 낫다.

CLI 기반 AI는 스스로 움직일 수 있는 폭이 넓기 때문에, 목표와 경계가 분명할수록 더 좋은 결과를 낸다. 자율성이 커질수록 지시의 품질이 더 중요해지는 셈이다.

강력한 만큼 더 필요한 것: 권한과 검토

CLI 기반 AI의 힘은 실제로 파일을 바꾸고 명령을 실행할 수 있다는 데서 나온다. 그런데 바로 그 점 때문에 위험도 생긴다.

잘못된 파일을 건드릴 수 있고, 과한 수정으로 범위를 넓힐 수 있으며, 위험한 명령을 실행할 수도 있다. 그래서 CLI 기반 AI는 항상 '더 편한 채팅창'처럼 다루면 안 된다.

중요한 것은 자율성과 통제의 균형이다. 읽기만 허용할지, 파일 수정까지 허용할지, 명령 실행은 승인 후에만 하게 할지, 어떤 디렉터리만 건드리게 할지 같은 경계를 정해야 한다.

실무에서는 보통 중요한 변경일수록 사람이 중간 검토를 넣는다. 예를 들어 큰 리팩터링, 배포 관련 설정, 보안과 인증 로직, 데이터 삭제 가능성이 있는 명령은 특히 조심해야 한다.

즉, CLI 기반 AI는 강력한 드릴과 비슷하다. 손에 쥐면 작업은 빨라지지만, 어디에 얼마나 써야 하는지는 여전히 사람이 판단해야 한다.

왜 많은 고급 사용자가 결국 CLI로 돌아오는가

이제 이유를 한 문장으로 정리해 보자.

고급 사용자가 CLI를 선호하는 이유는, 거기가 실제 일이 일어나는 곳이기 때문이다.

웹 채팅은 생각을 돕는다. CLI는 생각을 결과로 연결한다.

고급 사용자는 대개 다음을 중요하게 여긴다.

• 작업 맥락이 끊기지 않을 것

• 로컬 프로젝트의 실제 상태를 반영할 것

• 생성 뒤에 바로 검증할 수 있을 것

• 기존 도구들과 자연스럽게 연결될 것

• 작업 흔적을 검토하고 재현할 수 있을 것

CLI 기반 AI는 이 조건을 비교적 잘 만족한다. 그래서 점점 더 많은 숙련자가 브라우저 탭보다 터미널 창에서 AI를 만나게 된다.

이것은 취향의 문제가 아니다. 생산성 구조의 문제다. 답을 받는 것보다 일을 끝내는 것이 더 중요해질수록, AI는 대화창보다 작업장에 가까이 와야 한다.

앞으로 더 중요해질 능력

CLI 기반 AI 도구가 널리 퍼질수록, 개발자에게 중요한 능력도 조금씩 바뀐다.

앞으로는 단순히 프롬프트를 예쁘게 쓰는 능력만으로는 부족하다. 대신 이런 능력이 더 중요해진다.

첫째, 작업을 좋은 단위로 자르는 능력이다. 너무 크면 AI가 헤매고, 너무 작으면 오히려 왕복이 많아진다.

둘째, 검증 루프를 설계하는 능력이다. 어떤 테스트를 돌릴지, 무엇을 성공 기준으로 볼지 정해야 한다.

셋째, 권한과 위험을 관리하는 능력이다. 어디까지 자동화하고 어디서 사람이 멈춰 세울지 판단해야 한다.

넷째, 로컬 도구 체인을 이해하는 능력이다. 검색, 테스트, 빌드, 린트, Git이 어떻게 연결되는지 아는 사람일수록 CLI 기반 AI를 더 잘 쓴다.

즉, CLI 기반 AI는 단순한 편의 기능이 아니라 개발자의 작업 설계 능력을 증폭시키는 도구다. 잘 쓰는 사람은 훨씬 빨라지고, 대충 쓰는 사람은 오히려 혼란을 겪을 수도 있다.

이 장의 정리

CLI 기반 AI 도구가 강력한 이유는 단순히 터미널에서 쓸 수 있어서가 아니다. 파일 시스템, 명령 실행, 테스트, Git, 로컬 맥락과 연결되어 있기 때문이다.

웹 채팅 기반 AI가 설명과 아이디어 제안에 강하다면, CLI 기반 AI는 실제 프로젝트 안에서 탐색하고, 수정하고, 실행하고, 검증하는 흐름에 더 가깝다. 그래서 복사-붙여넣기 같은 중간 작업이 줄고, 문맥 전환 비용이 낮아지며, 결과를 더 빠르게 확인할 수 있다.

많은 고급 사용자가 CLI를 선호하는 이유도 여기에 있다. 그들은 멋진 답변보다, 실제 저장소에서 검증된 변경을 원한다. 그리고 CLI는 바로 그 요구에 가장 가까운 자리다.

결국 중요한 차이는 이것이다.

웹 채팅의 AI는 주로 말로 돕고, CLI의 AI는 일의 흐름 안으로 들어와 돕는다.

그리고 개발에서 생산성을 크게 바꾸는 쪽은 대개 후자다.