2025년을 마무리하며 에이전트 코딩, 도구, 그리고 인간과 기계의 관계 변화에 대해 되짚는다.
Armin Ronacher의 생각과 글
2025년 12월 22일 작성
2025년이 저물어가고 있고, 정말 여러모로 대단한 한 해였다. 작년 이맘때 나는 내 삶을 되돌아보는 글을 썼다. 만약 그때 프로그래밍에 대해 썼더라면, 2025년은 내 직업에 있어 전례 없는 해였기 때문에 글이 금방 낡아 보였을지도 모른다.
2025년은 변화의 해였다. Sentry를 떠나 새 회사를 시작했을 뿐 아니라, 예전과 같은 방식으로 프로그래밍하는 일을 멈춘 해이기도 했다. 6월에 나는 내 작업 방식이 달라졌다는 것을 마침내 자신 있게 공유할 수 있었다:
예전에는 Cursor에서 대부분의 시간을 보냈지만, 지금은 거의 완전히 손을 떼고 Claude Code를 주로 쓴다. […] 불과 6개월 전만 해도, 내가 직접 키보드를 두드리는 것보다 가상 프로그래머 인턴을 관리하는 엔지니어링 리드 역할을 더 선호하게 될 거라고 누가 말했더라면 나는 믿지 않았을 것이다.
작년에 더 많이 쓰고 싶다고 마음먹긴 했지만, 그 바람은 에이전트 코딩과는 아무 관련이 없었다. 그런데도 나는 글을 36개나 올렸다. 2007년 이후 이 블로그에 올라온 전체 글의 거의 18%에 해당한다. 또 에이전트 토끼굴에 빠져들고 난 뒤 호기심에 불이 붙어, 프로그래머와 창업가 등과 AI에 대해 대략 백 번 정도 대화를 나누기도 했다.
2025년은 세계에겐 그리 좋은 해가 아니기도 했다. 그와 화해하기 위해, 내 생각을 이곳과 분리하려고 별도의 블로그를 시작했다.
4월이나 5월 즈음 Claude Code에 대한 집착이 점점 커지면서 시작되었다. 그 결과 몇 달 동안 나만의 에이전트를 만들고 다른 이들의 에이전트를 쓰며 지냈다. 소셜 미디어는 AI에 대한 의견으로 폭발했다. 좋은 의견도 있었고 나쁜 의견도 있었다.
이제 나는 우리가 어디에 있고 어디로 가는지에 대해 어떻게 사고해야 할지, 비교적 안정적인 새로운 ‘현 상태’를 찾은 느낌이다. 나는 코드 생성, 파일 시스템, 인터프리터 글루를 통한 프로그래밍 방식의 도구 호출, 그리고 스킬 기반 학습에 더더욱 집중하고 있다. 요컨대: Claude Code가 혁신한 것이 여전히 내게는 최첨단이다. 지난 몇 달 동안 이 방식은 아주 잘 작동했고, 파운데이션 모델 제공자들이 스킬에 힘을 싣는 모습을 보며 이 접근에 대한 내 믿음은 더 강화되었다.
TUI가 이렇게 강하게 되살아난 것이 여전히 의아하다. 지금 나는 명령줄에서 Amp, Claude Code, Pi를 모두 쓰고 있다. Amp는 에이전트 코딩 도구 중 애플이나 포르쉐 같은 느낌이고, Claude Code는 합리적인 폭스바겐, Pi는 내게 해커의 오픈소스 선택지다. 셋 다 나처럼 자기 제품을 만들기 위해 건강하지 않을 정도로 그 도구를 사용하는 사람들이 만든 프로젝트처럼 느껴지지만, 각기 다른 트레이드오프가 있다.
도구 실행과 결합된 LLM이 할 수 있는 일은 여전히 나를 놀라게 한다. 연초에는 주로 코드 생성에 썼지만, 이제 내 에이전트 활용의 상당수는 일상적인 작업들이다. 2026년에는 소비자 제품 쪽으로 흥미로운 움직임이 많이 나올 거라 확신한다. LLM은 이제 내 삶을 정리하는 데도 도움을 주고 있고, 그 비중은 더 커질 거라고 기대한다.
LLM이 이제 프로그래밍뿐 아니라 여러 면에서 나를 돕게 되면서, 나는 그 기계들과의 관계를 다시 생각하게 되었다. 내가 쓰는 일부 도구들과 ‘일방적 유대감(파라소셜)’을 만들지 않기가 점점 더 어려워지고 있다. 이건 이상하고 불편하게 느껴진다. 오늘날 우리가 쓰는 대부분의 에이전트는 기억도 많지 않고 성격도 거의 없지만, 기억과 성격을 가진 것을 직접 만들어내기는 쉽다. 기억이 있는 LLM은 한번 겪으면 쉽게 떨쳐내기 어려운 경험이다.
매혹적이면서도 의심스럽다. 나는 2년 동안 이 모델들을 그저 토큰을 굴리는 기계로 생각하려고 스스로 훈련해왔지만, 그 환원적 관점은 더 이상 내게 통하지 않는다. 우리가 이제 만들어내는 이런 시스템들은 인간적인 경향을 갖고 있지만, 그것들을 인간 수준으로 격상시키는 것은 실수일 것이다. 나는 이런 기계를 “에이전트”라고 부르는 것에 점점 더 문제의식을 느끼지만, 더 나은 단어도 없다. “에이전트”라는 용어가 마음에 들지 않는 이유는, 행위 주체성과 책임은 인간에게 남아 있어야 하기 때문이다. 그것들이 무엇이 되어가든, 우리가 조심하지 않으면 해로울 수 있는 감정적 반응을 우리에게 유발할 수 있다. 이러한 창조물을 우리와의 관계 속에서 제대로 이름 붙이고 위치시키지 못하는 문제는, 우리가 반드시 해결해야 할 과제라고 믿는다.
이 모든 의도치 않은 의인화 때문에, 나는 때로 내가 이 기계들과 어떻게 일하고 있는지 적절한 말로 표현하기가 정말 힘들다. 이게 나만의 문제가 아니라는 것도 안다. 다른 사람들도 그렇다. 그리고 현재 이런 시스템을 완전히 거부하는 사람들과 함께 일할 때 그 불편함은 더 커진다. 에이전트 코딩 도구 글에 달리는 가장 흔한 반응 중 하나는, 기계에 성격을 부여하는 것에 대한 거부다.
AI를 이렇게 많이 쓰게 되며 예상치 못했던 점은, 우리가 다른 무엇보다도 ‘바이브(vibes)’에 대해 훨씬 더 많이 이야기하게 된다는 것이다. 이런 방식의 작업은 채 1년이 되지 않았지만, 소프트웨어 공학 반세기의 경험을 정면으로 도전한다. 그래서 의견이 정말 많고, 무엇이 결국 시간의 시험을 통과할지는 말하기 어렵다.
나는 동의하지 않는 기존의 통념을 많이 접했지만, 내 의견을 뒷받침할 근거는 없다. 어떻게 있겠는가? 나는 1년 내내 MCP에 대한 내 실패 경험을 꽤 노골적으로 공유했지만, “나한테는 안 맞는다” 이상의 근거는 거의 없었다. 다른 이들은 MCP를 굳게 신뢰했다. 모델 선택도 비슷하다. 연초에 나를 Claude에 푹 빠지게 만든 Peter는 Codex로 옮겨가 만족해하고 있다. 나는 그 경험을 그만큼 즐기지 못한다. 다만 더 많이 쓰기 시작하긴 했다. Claude를 선호하는 내 취향을 뒷받침하는 것도 결국 바이브 말고는 없다.
또 어떤 바이브는 의도적인 신호 보내기에서 오기도 한다는 점을 알아야 한다. 온라인에서 볼 수 있는 많은 사람들은 한 제품이 다른 제품보다 좋다는 주장에 경제적 이해관계가 있다. 예컨대 그 제품에 투자했거나 유료 인플루언서일 수 있다. 제품이 좋아서 투자자가 되었을 수도 있지만, 그 관계 때문에 그들의 관점이 영향을 받고 형성되었을 가능성도 있다.
요즘 어떤 AI 회사의 라이브러리를 집어 들든 Stainless나 Fern으로 만들어졌다는 것을 알게 될 것이다. 문서는 Mintlify를 쓰고, 사이트 인증 시스템은 Clerk일지도 모른다. 기업들은 예전이라면 직접 만들었을 서비스를 이제 판매한다. 핵심 서비스의 아웃소싱이 늘면서, 사용자 경험의 어떤 측면에서는 기준선이 올라갔다.
하지만 에이전트 코딩 도구가 준 새로운 힘 덕분에, 이런 것들의 상당수를 직접 만들 수도 있다. 나는 호기심도 있고 충분히 쉬워 보이기도 해서, Claude에게 Python과 TypeScript용 SDK 생성기를 만들어 달라고 했다. 알다시피 나는 단순한 코드와 직접 만드는 것의 옹호자다. 그래서 AI가 의존성을 줄이고 직접 만드는 방향을 장려할 잠재력이 있다고 다소 낙관한다. 동시에, 모든 것을 아웃소싱하는 현재의 추세를 보면 우리가 그 방향으로 가고 있는지는 확실치 않다.
이제 예측이 아니라, 다음에 우리가 에너지를 어디에 쏟을 수 있을지에 대한 ‘바람’으로 넘어가려 한다. 솔직히 여기서 내가 정확히 뭘 원하는지는 잘 모르겠지만, 내 고통 지점을 짚고 몇 가지 맥락과 생각거리를 제공하고 싶다.
가장 뜻밖의 발견: 코드를 공유하기 위한 전통적 도구의 한계에 부딪히고 있다. GitHub의 PR(풀 리퀘스트) 모델은 AI 생성 코드를 제대로 리뷰하는 데 필요한 정보를 충분히 담지 못한다. 변경을 낳은 프롬프트를 보고 싶다. 문제는 GitHub만이 아니라 git 자체에도 있다.
에이전트 코딩에서 오늘날 모델이 잘 작동하는 이유 중 하나는 ‘실수’를 알고 있기 때문이다. 더 이른 상태로 되돌려 조정하려면, 도구는 무엇이 잘못됐는지 기억해야 한다. 달리 표현할 말이 없지만, 실패에는 가치가 있다. 인간에게도 막다른 길이었던 경로를 아는 것이 도움이 될 수 있지만, 기계에게는 이것이 결정적인 정보다. 대화 기록을 압축하려고 할 때 이 점이 드러난다. 길을 잃게 만든 경로를 버리면, 모델은 같은 실수를 다시 시도하게 된다.
일부 에이전트 코딩 도구는 복원을 위해 worktree를 띄우거나 git 체크포인트를 만들고, 대화 중 브랜치/되돌리기 기능을 제공하기 시작했다. 이런 도구를 더 쉽게 쓰게 해줄 UX 혁신의 여지가 있다. 아마 그래서 스택드 디프(stacked diffs)나 Jujutsu 같은 대안 VCS에 대한 논의가 나오는 것일 테다.
이것이 GitHub를 바꿀까, 아니면 새로운 경쟁이 들어설 공간을 만들까? 그랬으면 좋겠다. 나는 진짜 인간의 입력을 더 잘 이해하고, 그것을 기계 출력과 구분하고 싶다. 프롬프트와, 그 과정에서 실패한 시도들을 보고 싶다. 그리고 머지할 때는 somehow 전부 스쿼시하고 압축하되, 필요하면 전체 히스토리를 되찾을 수 있는 방식이 있었으면 한다.
이것은 버전 관리 문제와 연관된다. 지금의 코드 리뷰 도구는 AI와 함께 일하기에 맞지 않는 엄격한 역할 정의를 전제로 한다. GitHub 코드 리뷰 UI를 보자. 나는 PR 화면의 코멘트를 사용해 내 에이전트들에게 메모를 남기고 싶을 때가 자주 있지만, 이를 위한 안내된 방식이 없다. 리뷰 인터페이스는 내 코드에 대해 ‘리뷰’를 하도록 허용하지 않고, ‘코멘트’만 할 수 있게 하는데, 그 의도는 미묘하게 다르다.
또 코드 리뷰가 점점 더 ‘나와 내 에이전트 사이에서 로컬로’ 이뤄지는 문제도 있다. 예컨대 GitHub의 Codex 코드 리뷰 기능은 한 번에 하나의 조직에만 묶을 수 있어서 내게는 작동이 멈췄다. 그래서 나는 이제 커맨드라인에서 Codex로 리뷰를 하지만, 그러면 내 반복(iteration) 사이클의 상당 부분이 팀의 다른 엔지니어들에게 보이지 않게 된다. 나는 이 방식이 맞지 않는다.
내게 코드 리뷰는 VCS의 일부가 되어야 한다고 느껴진다.
나는 관측 가능성도 다시 쟁탈전이 벌어질 거라 믿는다. 이제 우리는 이를 완전히 새로운 수준으로 활용할 필요와 기회를 동시에 갖게 됐다. 대부분의 사람들은 자신만의 eBPF 프로그램을 만들 수 있는 입장이 아니었지만, LLM은 할 수 있다. 마찬가지로 많은 관측 가능성 도구는 SQL의 복잡성 때문에 SQL을 피했지만, LLM은 어떤 독점 쿼리 언어보다도 SQL을 잘한다. 쿼리를 쓸 수 있고, grep을 할 수 있고, map-reduce를 할 수 있고, LLDB를 원격 조종할 수도 있다. 구조와 텍스트가 있는 것이라면 무엇이든, 갑자기 에이전트 코딩 도구가 성공하기 좋은 비옥한 토양이 된다. 미래의 관측 가능성이 어떤 모습일지는 모르겠지만, 내 강한 직감으로는 여기에서 많은 혁신이 일어날 것이다. 기계에 대한 피드백 루프가 좋아질수록 결과도 좋아진다.
내가 여기서 정확히 무엇을 요구하는지도 확신이 없지만, 과거의 과제 중 하나는 더 나은 관측 가능성을 위한 많은 멋진 아이디어—특히, 더 목표 지향적인 필터링을 위해 서비스를 동적으로 재구성하는 것—가 복잡하고 쓰기 어려워 사용자 친화적이지 않았다는 점이라고 생각한다. 하지만 이제 LLM이 이런 고된 일을 처리하는 능력이 커졌으니, 오히려 그런 해법이 정답이 될지도 모른다. 예를 들어 Python 3.14에는 외부 디버거 인터페이스가 들어갔는데, 이는 에이전트 코딩 도구에 엄청난 능력이다.
이 부분은 다소 논쟁적일 수 있는데, 올해 내가 결국 해내지 못한 것은 기계에 ‘완전히 맡겨버리기’다. 나는 여전히 이를 일반적인 소프트웨어 공학처럼 대하며 많이 리뷰한다. 동시에 점점 더 많은 사람들이 이런 공학 모델로 일하지 않고, 기계에 완전히 맡겨버리는 방식으로 일하고 있다는 것도 알고 있다. 미친 소리처럼 들리지만, 나는 실제로 그런 방식으로 꽤 성공한 사람들을 본 적이 있다. 나는 아직 이 현상을 어떻게 해석해야 할지 모르지만, 분명한 건 결국 코드가 생성되긴 해도 그 새로운 세계에서의 작업 방식은 내가 익숙한 세계와는 매우 다르다는 점이다. 그리고 그 세계가 계속될 거라는 의심이 들기 때문에, 이것들을 구분해낼 새로운 사회적 계약이 필요할지도 모른다.
가장 분명한 형태는 오픈소스 프로젝트에 이런 유형의 기여가 늘어나는 것이다. 솔직히 말해, 그런 모델로 일하지 않는 사람들에게는 모욕이다. 나는 그런 PR을 읽는 게 정말 분노를 유발한다고 느낀다.
개인적으로 나는 기여 가이드라인과 PR 템플릿으로 이 문제를 해결하려 했다. 하지만 이건 돈키호테식 싸움처럼 보인다. 어쩌면 해법은 우리가 하는 일을 바꾸는 데서 나오지 않을 수도 있다. 대신 AI 기반 엔지니어링에도 찬성하는 목소리를 가진 사람들이, 에이전트 코드베이스에서 좋은 행동이 무엇인지에 대해 공개적으로 말해주는 쪽에서 해결이 나올지도 모른다. 그건 검토되지 않은 코드를 던져 놓고 다른 사람이 똥을 치우게 만드는 게 아니다.
이 글에는 ai, personal, thoughts 태그가 달려 있다.
다음 형식으로 복사 / 마크다운 보기
© Copyright 2025 Armin Ronacher.
콘텐츠는 Creative Commons Attribution-NonCommercial-ShareAlike 라이선스에 따라 제공된다.
추가 정보: 임프린트 & AI 투명성. 구독: atom / RSS.
색상 스킴: 자동, 라이트, 다크.
