Claude Code가 왜 개발자에게 ‘재미’와 ‘흐름’을 주는지, 레트로한 CLI 미학, 신뢰 구축 방식, 속도와 모멘텀, 그리고 ‘제품 하네스(도구·환경·프롬프트)’를 최적화하는 메타게임 관점에서 살펴보는 글.
코딩 에이전트를 둘러싼 논쟁은 끝이 없다. 최고의 프롬프트 방식은 무엇인가? 출력물은 어떻게 검토해야 하나? 결과가 쓰레기라 결국엔 시간을 더 낭비하게 만드는 건 아닌가?
하지만 내 주변 엔지니어 친구들이 모두 동의하는 한 가지가 있다. “요즘 코딩은 훨씬 더 재미있다.” 그리고 그중 다수가 같은 도구를 가리킨다: Claude Code. 1
OpenAI에서 Codex를 작업2한 뒤, 왜 Claude Code가 개발자들을 그렇게 열광시키는지 더 가까이서 살펴보고 싶었다.
처음에는 CLI 도구로 코드 수정을 관리하는 것에 꽤 회의적이었다. 내 프로그래밍 경력 대부분은 IDE 중심이었기 때문이다. 하지만 몇 주간 Claude Code를 써보니, 그 ‘재미’의 감각을 느끼지 않을 수 없었다.
Claude Code의 장점을 여러 가지로 말할 수 있지만—가장 과소평가된 측면은 바로 내가 끝없이 내 취향대로 해킹할 수 있다는 느낌이다.
Claude Code를 쓰는 경험은 지라에서 티켓을 이리저리 옮기는 것보다 피아노를 연주하는 것에 가깝다. 도구를 다르게 쓰면 나도 비르투오소가 될 수 있을 것 같은 막연한 감각이 든다.
단지 코드를 쓰는 ‘게임’만 있는 게 아니라, 우리가 각자 기발하고 멋진 방식으로 이 도구를 사용하며 함께 플레이하는 ‘메타게임’이 있다.
처음 claude를 실행했을 때, 두 가지가 단번에 눈에 들어왔다. 1) 세심한 디테일, 2) 올드스쿨 비디오 게임에서 받은 영감.
Claude Code를 실행하면 맨 처음 이런 화면이 보인다.
평범한 CLI 도구와 달리, 진짜로… UI 디자인이 있다?
작은 강조 색상이 UI를 발랄하고 흥미롭게 만든다. 세 가지 톤의 텍스트 색은 시선을 특정 영역으로 끌어준다(헤더 > 입력 박스 > 변경 로그). 애니메이션 텍스트는 은은하게 색이 변한다. Anthropic 로고를 어렴풋이 떠올리게 하는 세련된 유니코드 아이콘도 보인다. 레트로한 미학이 재미를 준다. 그리고 명확한 콜투액션으로 맞이해 준다: Try "write a test for InboxList.tsx".
첫 화면은 또한 이 도구를 더 잘 쓰는 법을 알려준다. 변경 로그, 프롬프트, 오늘의 팁을 제공한다. 단축키 메뉴를 펼치면 고급 기능 사용법이 보인다.
선택을 해야 할 때, Claude Code는 팔로업 같은 작업에 대해 몇 가지 옵션을 제시한다.
RPG에서 하듯 1, 2, 3 중 하나를 고를 수 있다. 단축키도 예상한 대로 모두 잘 작동한다.
Claude Code는 또한 ‘무엇이 아닌가’로도 정체성이 드러난다—IDE가 아니다.
여기서는 구형 JetBrains를 예로 들었는데, 아마 가장 나쁜 사례일 수 있지만 “해가 뜨는 모든 기능을 IDE에 다 얹자”는 욕망을 상징적으로 보여준다.
이게 중요한 이유는 두 가지다:
그 결과물은 시도하기 쉽고, 동시에 인간이 코드를 쓰지 않는 미래를 최적화할 자유를 갖는다.
Claude Code는 폴더 트리나 파일 열람을 위한 화면을 기대하지 않기 때문에, 서브에이전트나 훅 같은 것들에 더 많은 화면 공간을 할애할 수 있다.
온보딩 이후, 어떤 에이전트형 도구든 가장 큰 허들은 신뢰를 쌓는 일이다. 사용자들은 이런 질문에 답해야 한다: “모델이 원샷으로 처리할 수 있는 작업 복잡도는 어디까지인가?” “매 줄을 뒤지지 않고 어떻게 결과를 검증할 수 있나?”
일명 ‘바이브 코딩’ 앱은 신뢰 구축에 종종 애를 먹는다. 한편으로는, 사용자가 앱을 클릭 몇 번으로 곧바로 동작을 검증할 수 있어 좋다(훌륭!). 하지만 다른 한편으로는, 무언가 잘못됐을 때 내부에서 무슨 일이 벌어졌는지를 파악하기가 더 어렵다.
OpenAI에서 Codex의 클라우드 버전을 만들 때, 우리는 사용자가 중간중간 모델을 들여다보며 ‘조종’하려 들지 않기를 바랐다.
이는 보통 정확성 관점에서 좋다. 모델은 실패 복구에 놀라울 정도로 능숙하고, 에이전트에게 코드를 실행할 ‘긴 리드’를 주면 성능이 크게 오른다. 하지만 사용자가 모델이 정말 올바른 일을 하고 있다고 느끼게 만드는 데에는 그만큼 기여하지 못한다.
무언가 해법은 필요했다. 그래서 모델이 자체 환경에서 실행하는 터미널 명령을 사용자에게 보여주었다. 테스트와 린트 결과를 출력하도록 한 것과 더불어, 나쁘지 않은 타협처럼 느껴졌다.
문제는 터미널 명령이 TODO 리스트보다 훨씬 직관적이지 않다는 점이다—완료된 TODO는 한눈에 이해되지만, sed 명령은… 덜 그렇다.
TODO 리스트 도구를 활용하는 게 실제로 eval 점수를 올리는지는 모르겠다. 어쩌면 사용자 배려 차원일지도. 하지만 최소한 키보드 앞의 사람이 무슨 일이 벌어지는지를 이해하는 데에는 확실히 도움이 된다.
또 하나는 컨텍스트 관리의 문제다. IDE에서는 어떤 파일과 탭이 컨텍스트 윈도우에 포함되는지 불분명하다. 새 채팅을 만들면 모델의 이전 사고가 지워질 수도 있는데, 그렇다면 내가 보고 있는 파일은 여전히 포함될까?
Claude Code는 이걸 더 이해하기 쉽게 만든다. 터미널 세션 안에서 호출한 모든 것은 컨텍스트에 포함된다. Claude Code가 컨텍스트 윈도우를 압축(compaction)하면 그 사실을 알려준다. 수동으로 압축을 실행하고 싶다면, 문서가 방법을 설명한다.
흐름(flow) 감각에 크게 기여하는 요소 중 하나가 Claude Code의 속도다.
모델 샘플링이 빠르게 느껴진다. CLI의 네트워크 트래픽을 보면 용도에 따라 세 가지 모델(Haiku, Sonnet, Opus) 사이를 오가는 게 보인다.
인터페이스를 자세히 들여다보면, Claude Code가 무언가를 하고 있다는 작은 신호들이 여럿 보인다:
이 모든 합이 인터페이스를 민첩하고 살아 있는 느낌으로 만든다. 사용하면서 일이 진행 중이라는 것을 확신할 수 있다.
OpenAI의 한 친구는 이렇게 말했다. “내 노트북에서 <INTERNAL_AGENT>가 돌지 않으면 스트레스를 받는다.”
매주 새로운 SOTA 모델이 나오고 VC들이 수백만 개의 GPU에 자금을 대는 지금, 코딩 에이전트를 쓰지 않는 건 낭비처럼 느껴진다. 마치 공짜 지능을 길바닥에 버려두는 것 같다.
Claude Code는 이런 심리를 깊이 자극한다. 내가 쓰는 토큰 수를 숨기려 하기보다, 오히려 극대화하도록 유도한다. ‘Claude Max’ 요금제를 쓰면, 개별 토큰 단가가 높더라도 체감상 토큰이 무제한처럼 느껴진다.
여기서 Claude Code의 마지막 마법 같은 요소로 이어진다. 꾸준한 연습을 통해 내 생산성을 10배로 끌어올릴 수 있다는 감각이다.
Claude Code를 사용할 때, 내가 최적화할 수 있는 루프는 사실상 두 부분으로 나뉜다:
알고 보니 제품 하네스를 최적화하는 일은 실제로 제품을 만드는 것만큼이나 재미있다.
모든 코딩 에이전트에는 도박의 요소가 있다. 프롬프트를 제출하면 어디로 튈지 알 수 없다. 여러 번 룰렛을 돌려 보며 결과를 지켜볼 수밖에.
하지만 Claude Code에는 중요한 차이가 있다. 단지 모델을 어떻게 프롬프트하느냐만 바꾸는 게 아니라, 제품 하네스 자체를 바꾸도록 유도한다.
즉 Claude Code가 엉뚱한 일을 했을 때, 도구를 탓하기보다 나 스스로에게 이렇게 묻게 된다. “내가 뭘 더 잘할 수 있었을까?” 제품 하네스를 바꾸면 더 나은 결과가 나올까?
이 ‘메타게임’은 결국 Claude Code의 1등급 마케팅 수단이 된다. 모두가 하기 때문이다. 임베디드 Rust 프레임워크를 쓰든, Typescript 프런트를 쓰든, 누구나 Claude Code의 모든 기능을 어떻게 쓰는 게 최선인지 실험하게 된다.
사용자가 자신의 제품 하네스를 ‘소유’할 수 있으니, 각자의 팁과 트릭을 자랑하고 싶어진다. 내 트위터 피드는 Claude Code 자동화와 베스트 프랙티스로 가득하다.
제품 형태도 이를 돕는다. CLI 도구는 본질적으로 합성 가능하다. 이런 상상을 하기가 쉬워진다: “GitHub 이슈에서 작업을 바로 시작할 수 있을까?”, “에이전트를 체인처럼 연결하고, 순차적으로 CLI를 호출하게 만들 수 있을까?”, “git worktree를 써서 세션을 잔뜩 병렬로 돌릴 수 있을까?”3
최종 결과물은 자동화 게임을 닮는다. 하지만 ‘플레이’를 끝냈을 때, 나는 세상에 쓸모 있는 무언가를 남긴다.
한 친구가 지적했듯, Claude Code를 재미있게 만드는 건 전통적 의미의 ‘게이미피케이션’이 아니다. 배지, 레벨, 연속 출석 같은 건 없다.
대신, 도구를 잘 쓰며 얻는 몰입(flow)과 숙련의 감각이 있다.
진입 장벽이 낮다—명령 하나 실행하고 입력 칸에 프롬프트를 타이핑하면 시작이다. 제품은 매일의 팁과 제안을 통해 CLI를 쓰는 새로운 방식을 점차 드러낸다. 모멘텀의 감각이 있고, 에이전트가 무엇을 하는지에 대한 명확하고 즉각적인 피드백이 따라온다.
무엇보다도, 더 고급 기능과 자동화를 통해 실력을 끌어올릴 기회가 존재한다. Claude Code는 그 ‘제품 하네스 루프’를 계속 연마하라고 독려한다.
코딩은 이런 아이디어의 완벽한 배양 접시지만, 같은 기법은 다른 도메인에도 적용될 수 있다. 결국 대부분의 지식 노동은 여전히 비판적 사고, 자원 배분, 전략적 기획을 포함한다. 아마 엔터프라이즈 소프트웨어는 1950년대식 회계보다는 Minecraft에서 아이디어를 더 많이 빌려와야 할지 모른다.
코딩이 시사하듯, 요즘 이기는 도구는 사용자가 자신의 워크플로를 해킹하고 ‘흐름의 감각’을 최적화하도록 만들어 준다.
내 가장 큰 깨달음은, 중요한 건 eval만이 아니라—제품 하네스도 중요하다는 것이다.
이 온갖 트윅과 커스터마이즈가 정말 생산성을 올릴까, 아니면 그냥 재미있는 걸까? 아마 그 사이 어딘가에 효율적 전선이 있을 것이다. 그리고 그걸 찾으려면 변형 가능한 도구가 필요하다.
이 글에서는 에이전트형 CLI 개념을 선도한 Claude Code를 다룬다. 내 이전 직장에 대한(인정하건대 편향된) 의견이지만, Codex CLI 팀도 훌륭한 작업을 하고 있으며 여기서 말한 아이디어 상당수를 반영하고 있다. 업데이트를 정말 많이 내놓았으니, 한동안 안 써봤다면 꼭 최신 버전으로 업그레이드해 다시 써보기를 권한다. Gemini도 뒤따랐지만, 충분히 테스트할 기회는 없었다. ↩
CLI가 아니라 클라우드 버전. ↩
이것이 실제로 우리가 Codex에서 건 ‘킬러 기능’ 베팅이었다. 비동기적으로 동작하기 때문에 worktree가 필요 없더라도 원하는 만큼 작업을 병렬로 시작할 수 있다. 시간이 지나면 사용자들도 모델과 이런 방식으로 상호작용하길 원하게 될 거라고 본다. 다만 사용자 쪽의 약간의 ‘리-툴링’은 필요하다. ↩
