Claude Code를 사용해 1월과 2월의 4주 동안 새로운 프로그래밍 언어 Cutlet을 만들면서 얻은 결과와, 에이전틱 엔지니어링을 위해 필요한 기술과 작업 방식에 대해 정리한다.
2026년 3월 10일 오후 9:53(IST)에 게시
1월과 2월에 걸친 4주 동안, 나는 Claude Code를 사용해 새로운 프로그래밍 언어를 만들었다. 내 고양이 이름을 따서 Cutlet이라고 지었다. 그렇게 해도 완전히 합법이다. 소스 코드는 GitHub에서 확인할 수 있고, 빌드 안내와 예제 프로그램도 함께 있다.
나는 2021년 GitHub Copilot의 초기 공개 이후로 LLM 보조 프로그래밍을 써 왔지만, 지금까지는 보일러플레이트를 생성하거나 내 프로젝트에 특정하고 표적화된 변경을 가하는 데에만 LLM 사용을 제한해 왔다. 하지만 Cutlet을 만드는 동안에는 Claude가 코드의 모든 줄을 생성하도록 허용했다. 나는 그 코드의 어떤 부분도 읽지 않았다. 대신 제대로 동작하는지 확인하기 위한 가드레일을 만들었다(이건 뒤에서 더 이야기한다).
이 실험의 결과는 놀랍다. Cutlet은 지금 존재한다. macOS와 Linux 모두에서 빌드되고 실행된다. 실제 프로그램을 실행할 수 있다. 내부 깊숙한 곳에 버그가 숨어 있을 수도 있지만, 아마도 세상에 존재하는 다른 “4주 된” 프로그래밍 언어에서 찾을 법한 버그보다 더 나쁘지는 않을 것이다.
이 모든 일과 이것이 내 직업에 의미하는 바에 대해 Feelings™가 있긴 하지만, 설교단에 올라가기 전에 먼저 언어를 한 번 둘러보게 하고 싶다.
같이 따라 하고 싶다면, 소스에서 Cutlet 인터프리터를 빌드한 뒤 /path/to/cutlet repl로 REPL에 들어가면 된다.
배열과 문자열은 어떤 동적 언어에서든 기대하는 대로 동작한다. 변수는 my 키워드로 선언한다.
cutlet> my cities = ["Tokyo", "Paris", "New York", "London", "Sydney"]
=> [Tokyo, Paris, New York, London, Sydney]
변수 이름에는 대시를 포함할 수 있다. Raku와 같은 문법 규칙이다. 숫자 타입은(현재로서는) double 하나뿐이다.
cutlet> my temps-c = [28, 22, 31, 18, 15]
=> [28, 22, 31, 18, 15]
여기 멋진 게 하나 있다. @ 메타-연산자는 일반적인 이항 연산자를 배열에 대한 벡터화 연산으로 바꿔 준다. 다음 줄에서는 temps-c의 모든 원소에 1.8을 곱한 다음, 그 결과 배열의 각 원소에 32를 더한다.
cutlet> my temps-f = (temps-c @* 1.8) @+ 32
=> [82.4, 71.6, 87.8, 64.4, 59]
@: 연산자는 zip 연산이다. 두 배열을 zip해서 맵으로 만든다.
cutlet> my cities-to-temps = cities @: temps-f
=> {Tokyo: 82.4, Paris: 71.6, New York: 87.8, London: 64.4, Sydney: 59}
내장 함수 say로 텍스트를 출력한다. 이 함수는 nothing을 반환하는데, 이는 Cutlet에서의 null에 해당한다.
cutlet> say(cities-to-temps)
{Tokyo: 82.4, Paris: 71.6, New York: 87.8, London: 64.4, Sydney: 59}
=> nothing
@ 메타 연산자는 비교에도 동작한다.
cutlet> my greater-than-seventy-five = temps-f @> 75
=> [true, false, true, false, false]
또 하나 멋진 부분: 불리언 배열을 사용해 배열을 인덱싱할 수 있다. 이는 필터 연산이다. true에 해당하는 인덱스의 원소만 고르고, false에 해당하는 것은 버린다.
cutlet> cities[greater-than-seventy-five]
=> [Tokyo, New York]
이걸 더 짧게 쓰는 방법은 다음과 같다.
cutlet> cities[temps-f @> 75]
=> [Tokyo, New York]
사용자 친화적인 메시지와 함께 출력해 보자. ++ 연산자는 문자열과 배열을 연결한다. 내장 함수 str는 값을 문자열로 바꾼다.
cutlet> say("Pack light for: " ++ str(cities[temps-f @> 75]))
Pack light for: [Tokyo, New York]
=> nothing
전위(prefix) 위치의 @ 메타-연산자는 reduce 연산으로 동작한다.
cutlet> my total-temp = @+ temps-c
=> 114
평균 기온을 구해 보자. @+는 모든 기온을 더하고, 내장 함수 len()은 배열의 길이를 구한다.
cutlet> (@+ temps-c) / len(temps-c)
=> 22.8
이것도 보기 좋게 출력해 보자.
cutlet> say("Average: " ++ str((@+ temps-c) / len(temps-c)) ++ "°C")
Average: 22.8°C
=> nothing
함수는 fn으로 선언한다. Cutlet에서는 함수와 조건문을 포함해 모든 것이 표현식이다. 함수 안에서 표현식이 만들어낸 마지막 값이 반환값이 된다.
cutlet> fn max(a, b) is
... if a > b then a else b
... end
=> <fn max>
사용자가 만든 함수도 @와 함께 쓸 수 있다. max 함수로 기온을 reduce해서 가장 더운 기온을 찾아보자.
cutlet> my hottest = @max temps-c
=> 31
Cutlet은 더 많은 것을 할 수 있다. 동적 언어에서 기대할 만한 일반적인 기능(루프, 객체, 프로토타입 기반 상속, 믹스인, 마크-앤-스윕 가비지 컬렉터, 친절한 REPL)을 모두 갖추고 있다. 아직 파일 I/O는 없고, 에러 처리 같은 기본적인 구성 요소 일부도 빠져 있지만, 곧 채워 나갈 예정이다!
전체 문서는 git 저장소의 TUTORIAL.md를 참고하라.
나는 프론트엔드 엔지니어이자 (가끔은) 디자이너다. LLM을 써서 웹 애플리케이션을 만들어 보려 했지만, 항상 한계에 부딪혔다.
내 경험상 Claude와 친구들은 복잡한 비즈니스 로직을 쓰는 데는 무서울 정도로 뛰어나지만, 시각적 디자인 능력이 필요한 작업에서는 성능이 나쁘다.
반응형 레이아웃과 애니메이션을 영어로 설명하는 건 쉽지 않다. 어떤 스크린샷과 와이어프레임도 유동적인 레이아웃과 애니메이션을 LLM에게 전달해 주지 못한다. Claude가 고쳤다고 장담한 레이아웃 문제를, 나는 여전히 새는 인간 눈으로 똑똑히 보고 있었고, 그걸로 몇 시간을 허비했다.
또한 이런 도구들은 공개 저장소에서 이미 봤던 쿠키커터 UI를 만들어 내는 데에는 뛰어나지만, 새로운 무언가를 하려고 하면 급격히 무너진다는 것도 알게 됐다. 나는 종종 특정 니치 도메인을 위한 복잡한 데이터 시각화를 만드는 클라이언트와 일하는데, LLM은 이 프로젝트들에서 유용한 결과물을 만드는 데 전반적으로 실패했다.
반면 지난 몇 달 동안 LLM을 사용해 사람들이믿기 어려운일들을해내는 것을 봤고, 나도 직접 그런 실험을 재현해 보고 싶었다. 하지만 이전의 LLM 사용 경험은, 프로젝트를 신중하게 골라야 한다는 점을 시사했다.
작고 동적인 프로그래밍 언어는 이 모든 요구사항을 만족했다.
make test와 make check를 오류가 없어질 때까지 돌려라”보다 더 나은 피드백 루프는 없다.마지막으로, 이것은 에이전틱 엔지니어링을 어디까지 밀어붙일 수 있는지 알아보기 위한 실험이기도 했다. 6개월짜리 일을 몇 주로 압축할 수 있을까? 내 능력으로는 만들 수 없을 수준의 무언가를 만들 수 있을까? LLM 주도 프로그래밍에 올인하면 내 일상 업무는 어떻게 보일까? 이런 질문들에 답하고 싶었다.
이 실험을 시작할 때 나는 어느 정도 회의적이었다. Claude Code로 무언가를 전부 만들어 보려던 이전 시도들은 잘 되지 않았기 때문이다. 하지만 이번 시도는 성공했을 뿐 아니라, 내가 가능하다고 상상한 것 이상을 만들어 냈다. 나는 미래의 모든 소프트웨어가 LLM에 의해 작성될 것이라고 믿지는 않는다. 하지만 상당히 큰 부분집합은 부분적으로 혹은 대부분을 이런 새 도구에 아웃소싱할 수 있다고는 믿는다.
Cutlet을 만들면서 중요한 걸 배웠다. LLM으로 코드를 생성한다고 해서 소프트웨어를 만드는 법에 대해 배운 걸 전부 잊게 되는 건 아니다. 에이전틱 엔지니어링에는 생성형 AI 이전부터 가치 있던 소프트웨어에 늘 요구되던 것처럼, 신중한 계획, 기술, 장인정신, 규율이 필요하다. 코딩 에이전트와 일하는 데 필요한 기술은 편집기에 한 줄씩 타이핑하는 것과는 달라 보일 수 있지만, 여전히 우리가 평생 갈고닦아 온 엔지니어링 기술 그 자체다.
LLM에서 좋은 출력물을 얻으려면 많은 작업이 필요하다. 에이전틱 엔지니어링이란, 채팅창에 모호한 지시를 던져 넣고 나오는 코드를 수확하는 일을 뜻하지 않는다.
나는 오늘날 코딩 에이전트와 효과적으로 일하기 위해 배워야 할 주요 기술이 네 가지라고 믿는다.
모델과 하네스는 빠르게 변하고 있으므로, LLM이 어떤 문제를 잘 푸는지 파악하려면 직관을 기르고, 동료들과 이야기하고, 동향을 계속 살펴봐야 한다.
하지만 빠르게 변하는 분야를 따라잡고 싶지 않다면(나는 그런 선택을 해도 전혀 비판하지 않을 것이다. 정말 미친 세상이다), 내 문제가 LLM 형태(LLM-shaped)인지 알아보기 위해 스스로에게 던질 수 있는 질문이 두 가지 있다.
이 둘 중 하나라도 답이 “아니오”라면, AI를 문제에 던져 넣는다고 해서 좋은 결과가 나올 가능성은 낮다. 둘 다 “예”라면, 에이전틱 엔지니어링으로 성공할 수도 있다.
좋은 소식은, 이걸 알아보는 비용이 Claude Code 구독료와, 팀에서 한 달쯤 코드베이스에 적용해 보겠다고 나설 희생양 한 명의 비용이라는 점이다.
LLM은 자연어로 작동하므로, 단어로 아이디어를 전달하는 법을 배우는 것이 중요해졌다. 동료에게 글로 아이디어를 설명할 수 없다면, 코딩 에이전트와도 효과적으로 일할 수 없다.
단순하고 모호하고 지나치게 일반적인 프롬프트로도 Claude Code에서 꽤 많은 것을 얻을 수 있다. 하지만 그렇게 하면 많은 생각과 의사결정을 로봇에게 아웃소싱하게 된다. 버리는 프로젝트에는 괜찮지만, 프로덕션에 넣고 수년간 유지보수할 무언가를 만드는 경우라면 더 신중해지고 싶을 것이다.
코딩 에이전트에게는 문제 공간을 가능한 한 많이 담아낸, 정밀하게 쓰인 명세를 먹여야 한다. Cutlet을 만드는 동안 나는 대부분의 시간을 명세 문서를 쓰고, 생성하고, 읽고, 고치는 데 썼다.
나에게는 새로운 경험이었다. 나는 주로 초기 단계 스타트업과 일해 왔기 때문에, 내 경력 대부분에서 코드를 곧 명세로 취급해 왔다. 형식적인 명세를 쓰는 것은 낯선 경험이었다.
다행히 Claude가 이런 명세 대부분을 작성하는 데 도움을 줄 수 있었다. Cutlet이 실험이었기 때문에 나는 이 방식이 편했다. 내 명성을 걸고 싶은 프로젝트라면, 아예 에이전트를 제외하고 내가 직접 명세를 쓸지도 모른다.
Cutlet에서 어떤 변경을 할 때든 나의 전반적인 워크플로는 이랬다.
plans/doing/ 디렉터리에 들어갈 파일로 써 달라고 한다. 하나의 기능에 대해 3~4개의 계획 파일이 생기는 경우도 있었다. 의도한 바였다. 계획은 사람이 읽을 수 있어야 했고, 각각의 계획은 일이 잘 안 되면 롤백할 수 있는 원자적 단위여야 했다. 또한 프로젝트의 진화 과정을 기록하는 히스토리 역할도 했다. Cutlet 저장소에서 역사적인 계획 파일 전체를 볼 수 있다.sudo 접근을 포함한 모든 권한을 준 상태로 Claude를 실행한 다음, 내 계획을 구현해 달라고 요청한다.이 워크플로는 언어에 어떤 변경을 가할 때든 인지적 노력을 앞단에 쏟게 만들었다. 코드 한 줄이 작성되기 전에 모든 사고가 끝나는 셈인데, 나는 거의 이런 식으로 일하지 않는다. 내게 프로그래밍은 작업하면서 문제의 형태를 유기적으로 발견하는 과정이기 때문이다. 하지만 LLM과 함께 그런 방식으로 일하는 것은 어렵다는 것을 알게 됐다. LLM은 코드베이스 전반에 걸친 큰 변화에는 뛰어나지만, 빠르고 반복적인 유기적 개발 워크플로에는 형편없다.
추론이 더 빨라지고 모델이 더 좋아지면 내 워크플로도 진화할지 모르지만, 그때까지는 이런 폭포수식 모델이 가장 잘 맞는다.
나는 이것이 코딩 에이전트와 일하는 데 가장 흥미롭고 재미있는 부분이라고 생각한다. 완전히 새로운 종류의 문제다!
핵심 원칙은 이렇다. 코딩 에이전트는 컴퓨터 프로그램이기 때문에, 자신이 존재하는 세계를 제한적으로만 볼 수 있다. 에이전트가 내가 풀려고 하는 문제를 들여다볼 수 있는 유일한 창은 접근 가능한 코드 디렉터리뿐이다. 이것만으로는 좋은 일을 하기 위한 충분한 자율성이나 정보가 없다. 그러니 에이전트가 잘 해내도록 돕기 위해서는, 더 넓은 세계로 손을 뻗어 필요한 정보를 얻을 수 있도록 도구 형태로 자율성과 정보를 제공해야 한다.
실제로는 어떤 모습일까? 프로젝트마다 다르겠지만, Cutlet에서는 이렇게 했다.
clang-tidy와 clang-format을 사용한다. 테스트와 마찬가지로, 프로젝트 지침은 주요 변경 뒤에 이런 도구들을 매번 실행하라고 했다. clang-tidy는 종종 진단 메시지를 뿜어서 Claude가 코드 일부를 다시 쓰게 만들었다. 더 비싼 정적 분석 도구(예: Coverity)를 쓸 수 있었다면, 개발 프로세스에 추가했을 것이다.make test-sanitize 타깃을 만들게 했는데, 이는 ASan과 UBSan을 켠 상태로(ASan을 통해 LSan도 함께) 프로젝트와 테스트 스위트 전체를 다시 빌드한 다음, 계측된 빌드로 모든 테스트를 실행한다. 프로젝트 지침에는 계획 구현이 끝날 때 이 체크를 수행하는 것도 포함했다. 이는 테스트나 린터가 찾지 못하는 메모리 오류(해제 후 사용, 버퍼 오버플로, 정의되지 않은 동작)를 잡아냈다. 이 테스트는 시간이 걸려 에이전트를 크게 느리게 만들었지만, clang-tidy보다도 더 많은 문제를 찾아냈다.ctags와 cscope에 접근할 수 있었다. 얼마나 유용했는지는 모르겠다. 사용하는 걸 거의 본 적이 없다. 대부분은 심볼을 찾기 위해 그냥 grep을 썼다. 나중에는 제거할지도 모르겠다.--dangerously-skip-permissions를 켜고 전체 sudo 접근을 준 상태로 실행했다. 나는 이것이 큰 프로젝트에서 코딩 에이전트를 쓰는 유일하게 실용적인 방법이라고 믿는다. 권한 프롬프트에 답하는 것은 에이전트 5개를 병렬로 돌릴 때 인지적으로 매우 고되고, 무엇이든 하려는 능력을 제한하면 업무 효율이 떨어진다. LLM에게 시스템을 완전히 제어할 능력을 주었을 때 생기는 온갖 안전 문제를 해결해야 하겠지만, 이 프로젝트에서는 YOLO 모드가 가져오는 위험을 감수할 의향이 있었다.이 모든 도구와 능력은 코드 업데이트가 최소한 컴파일되고 실행되는 프로젝트로 이어지도록 보장했다. 하지만 더 중요한 것은, Claude가 더 많은 정보와 자율성에 접근할 수 있게 만들어, 내가 개입하지 않아도 문제를 발견하고 디버깅하는 데 더 효과적이게 했다는 점이다. 이 프로젝트를 계속한다면, 내 주요 초점은 에이전트가 만들고 있는 아티팩트를 더 깊이 들여다볼 수 있도록 더 많은 통찰을 주고, 더 많은 디버깅 도구와 더 많은 자유, 더 많은 유용한 정보에 대한 접근을 제공하는 데 있을 것이다.
각자의 프로젝트에 맞는 툴링을 직접 고안하고 싶어질 것이다. Django 앱을 만든다면 에이전트에게 스테이징 데이터베이스 접근을 주고 싶을 수도 있다. React 앱을 만든다면 헤드리스 브라우저 접근을 주고 싶을 수도 있다. 모든 프로젝트에 통하는 단 하나의 정답은 없고, 사람들은 LLM이 현실 세계에서 자신의 작업 결과를 관찰할 수 있게 해 주는 매우 흥미로운 도구들을 만들게 될 거라고 확신한다.
코딩 에이전트는 때때로, 내가 준 도구를 비효율적으로 쓰기도 한다.
예를 들어 이 프로젝트를 하면서, Claude가 어떤 명령을 실행한 뒤 출력이 컨텍스트 창에 너무 길다고 판단하고, head -n 10으로 파이핑한 버전을 다시 실행하는 일이 있었다. 또 어떤 때는 make check를 실행하고는 출력에서 에러를 grep으로 찾는 걸 잊어버린 채, 출력을 캡처하기 위해 두 번째로 실행하기도 했다. 그러면 단일 편집 과정에서 같은 비싼 체크들이 여러 번 실행되곤 했다. 이런 실수는 에이전틱 루프를 크게 느리게 만들었다.
나는 CLAUDE.md를 편집하거나 커스텀 스크립트의 출력을 바꾸는 것으로 일부 성능 병목을 고칠 수 있었다. 하지만 발견하고 고치는 데 더 많은 노력이 필요한 문제들도 있었다.
나는 빠르게 습관을 들였다. 에이전트가 일하는 모습을 관찰하고, 반복해서 수행하는 명령 시퀀스를 발견하면, 그것을 에이전트가 대신 호출할 수 있는 스크립트로 바꿨다. Cutlet의 scripts 디렉터리에 있는 많은 스크립트들은 이런 방식으로 생겼다.
이건 매우 수동적이고, 별로 재미없는 일이었다. 시간이 지나면서 더 자동화되길 바란다. 어쩌면 미래의 Claude Code는 자신이 호출한 도구들의 출력들을 검토하고, 내가 작성할 수 있는 스크립트를 제안해 줄 수도 있지 않을까?
물론 가장 결실이 큰 최적화는, --dangerously-skip-permissions와 sudo 접근을 켠 채 Docker 안에서 Claude를 실행한 것이었다. 그렇게 함으로써, 나는 에이전틱 루프에서 _나 자신_을 빼 버렸다. 계획 파일이 만들어진 뒤에는, 에이전트가 ls를 실행하려고 할 때마다 내가 옆에서 지켜보고 Yes라고 말하고 싶지 않았다.
Cutlet이 진화하면서, Claude를 위해 만든 인프라도 함께 진화했다. 결국 Claude가 자연스럽게 따르던 많은 워크플로를 스크립트, 슬래시 커맨드, 혹은 CLAUDE.md의 지침으로 캡처하게 됐다. 또한 에이전트가 주로 어디서 넘어지는지 파악했고, 더 나은 지침이나 실행할 스크립트를 제공함으로써 그 실수를 선제적으로 막았다.
Claude를 위해 만든 인프라는 프로젝트에서 일하는 인간인 나에게도 가치가 있었다. Claude가 일을 자동화하는 데 도움이 된 동일한 스크립트들이, 나 역시 흔한 작업을 빠르게 처리하는 데 도움을 줬다.
프로젝트가 성장함에 따라 이 인프라도 계속 진화할 것이다. 모델은 항상 변한다. 프로젝트 요구사항과 워크플로도 그렇다. 나는 이 모든 프로젝트 인프라를, 프로젝트가 살아 있는 한 계속 변해 갈 유기적인 것으로 본다.
이제 개인 개발자가 아주 짧은 시간에 엄청난 일을 해낼 수 있게 되었는데, 소프트웨어 엔지니어링은 커리어로서 죽은 걸까?
내 대답은 아니, 전혀 아니다. 소프트웨어 엔지니어링 기술은 언어 모델이 좋아지기 전과 마찬가지로 오늘날에도 여전히 가치가 있다. 내가 대학에서 컴파일러 수업을 듣고 _Crafting Interpreters_를 공부하지 않았다면, Cutlet을 만들 수 없었을 것이다. 나는 (어느 정도의) 도메인 지식과 경험이 있었기에 내릴 수 있는 기술적 결정을 여전히 내려야 했다.
게다가, Cutlet을 효과적으로 만들기 위해 나는 새로운 기술도 잔뜩 배워야 했다. 이 새로운 기술들 역시 기술적 지식을 요구했다. 이상하고 새롭고 다른 종류의 기술적 지식이긴 하지만, 어쨌든 기술적 지식이다.
이 프로젝트를 하기 전에는 5년 뒤에도 내가 직업을 가질 수 있을지 걱정했다. 하지만 오늘은, 미래에도 세상은 소프트웨어 엔지니어를 필요로 할 것이라고 확신한다. 우리의 일은 변할 것이고—어떤 사람들은 새 일자리를 더 이상 즐기지 못할 수도 있지만—그래도 우리에게는 할 일이 많을 것이다. 어쩌면 이전보다 더 할 일이 많아질지도 모른다. LLM 덕분에 더 많은 소프트웨어를 훨씬 더 빨리 만들 수 있기 때문이다.
그리고 LLM을 절대 만지고 싶지 않은 사람들에게도, LLM이 전혀 침투하지 못하는 도메인들이 있을 것이다. 저수준 멀티미디어 시스템을 하는 내 친구들은, 웹앱을 만드는 사람들에 비해 LLM으로 성공을 덜 경험했다고 한다. 아마도 이는 여러 해 동안 계속될 것이다. 결국 그런 일자리도 변하겠지만, 훨씬 더 느린 변화가 될 것이다.
_Cutlet을 만든 것이 나다_라고 말하는 게 공정할까? 결국 대부분의 일을 한 것은 Claude였다. 내가 기여한 것은 프롬프트를 쓴 것 말고 또 무엇이 있을까?
게다가 이 실험이 작동한 것은, Claude가 학습 데이터 안에 여러 언어 런타임과 컴퓨터 과학 책을 가지고 있었기 때문이다. 수백 명의 프로그래머, 학자, 작가가 자신들의 작업을 대중에게 무료로 기여해 온 덕분에 이 프로젝트가 가능했다. 그렇다면 Cutlet을 진짜로 만든 건 누구일까?
나는 그에 대한 좋은 답을 갖고 있지 않다. 코딩 에이전트가 토큰을 생성하도록 돌보는 일에 대한 공을 가져가는 건 편하지만, 코드 자체에 대한 소유감은 없다.
나는 이것을 “내” 작업이라고 생각하지 않는다. 뭔가 맞지 않는다. 미래에 내 감정이 바뀔지도 모르지만, 어떻게 바뀔지는 잘 모르겠다.
이 코드가 वास्तव에 누구에게 속하는지에 대한 내 유보 때문에, 나는 Cutlet의 GitHub 저장소에 라이선스를 추가하지 않았다. Cutlet은 인터넷에 자신의 작업을 공개해 온 모든 프로그래밍 언어 디자이너, 구현자, 교육자의 집단 의식에 속한다.
(또한 Cutlet에는 거의 확실히 Lua와 Python 인터프리터의 코드가 포함되어 있다는 점도 언급할 만하다. 언어 기능에 대해 이야기할 때 우리는 계속 그 언어들을 참조했다. 나는 _Crafting Interpreters_의 코드가 코드베이스에 들어오는 것도 내 두 개의 살덩이 눈으로 숱하게 보았다.)
이미 거대한 이 블로그 글에서 정신 건강에 대한 메모를 넣지 않는다면 직무유기일 것이다.
에이전틱 엔지니어링 도구는 중독되기 쉽다. 이 프로젝트를 하는 동안, 나는 종종 자정에 컴퓨터 앞에 앉아 “프롬프트 한 번만 더”를 외치곤 했는데, 마치 세상에서 가장 난해한 Civilization 게임을 하는 것 같았다. 손님이 집에 와 있을 때도, 샤워하러 들어갈 때도, 점심 먹으러 갈 때도 Claude Code를 백그라운드에서 돌리고 있었던 일이 많았다는 걸 인정하기 부끄럽다. 이렇게 짧은 시간에 많은 것을 해내는 데서 오는 취기가 있다.
그보다 더 중독적인 것은 이 도구들에 내재된 예측 불가능성과 무작위성이다. Claude에게 문제를 던지면, 무엇을 내놓을지 절대 알 수 없다. 몇 주 동안 막혀 있던 어려운 문제를 한 방에 해결할 수도 있고, 거대한 난장판을 만들 수도 있다. 슬롯머신처럼, 무슨 일이 일어날지 알 수 없다. 그래서 모든 것에, 언제나, 이것을 써 보고 싶은 강한 충동이 생긴다. 그리고 슬롯머신과 마찬가지로, 하우스는 언제나 이긴다.
요즘 나는 Claude를 얼마나 오래, 얼마나 자주 쓸 수 있는지 제한을 둔다. LLM이 널리 보급되면서, 사회는 정신 건강을 망치지 않으면서 이를 최선으로 사용하는 방법을 찾아야 할 것이다.
나는 이 부분에 대해 별로 낙관적이지 않다. 우리는 소셜 미디어 사용을 규제하거나 제한하는 데 철저히 실패했고, LLM에서도 같은 시나리오가 반복될 거라고 나는 기꺼이 내기할 수 있다.
이제 큰 규모의 코드를 아주 빠르게 만들어 낼 수 있는데, 이전에는 할 수 없었던 무엇을 할 수 있을까?
이 질문 역시 나는 지금 당장 완전히 답할 준비가 되어 있지 않다.
다만 LLM이 내 개인적 용도에서 즉시 쓸모가 있을 것 같은 영역 하나는, 아주 빠르게 실험할 수 있는 능력이다. Cutlet에서는 열 가지 다른 기능을 시도하는 게 아주 쉬운데, 명세를 써 놓고 컴퓨터에서 떠나기만 하면 되기 때문이다. 실패한 실험의 비용은 거의 0이다. Claude가 생성한 코드를 쓸 수 없다 해도, 동작하는 프로토타입은 아이디어를 빠르게 검증하고 나쁜 아이디어를 일찍 버리는 데 도움을 준다.
또한 나는 JavaScript와 Python 프로젝트에서 서드파티 라이브러리에 대한 의존성을 크게 줄일 수 있었다. 예전에는 NPM이나 PyPI에서 의존성을 끌어와야 했던 작은 유틸리티 함수들을, 이제는 LLM으로 생성하는 경우가 많다.
하지만 솔직히 말해 이런 변화는 소소한 수준이다. AI 에이전트 때문에 생길 더 큰 사회적 변화를 나는 예측할 수 없다. 내가 할 수 있는 말은, 2030년의 프로그래밍은 2026년과 비교해 급진적으로 달라져 있을 것이라는 점뿐이다.
이 프로젝트는 Claude Code를 어디까지 밀어붙일 수 있는지 보기 위한 개념 증명이었다. 나는 현재 프론트엔드 엔지니어로서 새 계약을 찾고 있어서, Cutlet 작업을 계속할 시간이 아마 없을 것이다. 또한 에이전틱 프로그래밍을 더 밀어붙이기 위한 아이디어가 몇 가지 더 있어서, Cutlet을 계속하는 것보다는 그쪽을 우선할 가능성이 크다.
기분이 내키면, 언어에 작은 기능을 가끔 추가할지도 모른다. 이제 개발 루프에서 나 자신을 빼 버렸기 때문에, 시간과 노력은 많이 들지 않는다. 12월에는 Cutlet으로 Advent of Code를 할지도 모른다!
물론, Anthropic에서 일하는 사람이 나에게 돈을 줘서 이 실험을 계속 돌리게 해 주고 싶다면, 나는 앞으로 8개월 동안 계약 일을 할 수 있다 :)
일단은 Cutlet에 대한 책을 덮고, 다른 프로젝트(그리고 고양이)로 넘어가려 한다.
이 글을 교정해 준 Shruti Sunderraman에게 감사한다. 그리고 오늘 키보드 위를 걸어 다니며 내 작업을 세 번이나 지워 준 고양이 Cutlet에게도 감사한다.
이것은 블로그 글이다. **2026년 3월 10일 오후 9:53(IST)**에 게시되었다.