바이브의 해

• 2025년은 에이전틱 코딩 도구가 본격적으로 프로그래밍 방식을 바꾼 해로, 직접 키보드를 치는 대신 가상 인턴 프로그래머를 이끄는 엔지니어링 리드 역할로 전환
• Claude Code에 대한 집착으로 시작해 자체 에이전트 구축과 활용을 반복하며, 코드 생성·파일 시스템·프로그래밍 도구 호출·스킬 기반 학습이 여전히 최선의 접근법임을 확신
• LLM과 도구 실행의 결합이 코드 생성을 넘어 일상 업무 정리까지 확장되면서, 기계와의 관계에 대한 재고와 의도치 않은 준사회적 유대감(Parasocial Bond) 형성에 대한 우려 존재
• 기존 버전 관리 시스템과 코드 리뷰 도구가 AI 생성 코드 검토에 적합하지 않아, 프롬프트 이력과 실패 경로까지 추적할 수 있는 새로운 시스템 필요
• AI 코딩으로 인해 경험과 데이터 없이 '바이브'에 의존한 의견이 난무하는 상황이며, 오픈소스에 무분별하게 던져지는 AI 생성 PR에 대한 새로운 사회적 합의 필요

2025년의 변화

• 회사를 떠나 새 회사를 시작했을 뿐 아니라, 기존의 프로그래밍 방식을 완전히 바꾼 해
• 6월부터 Cursor 대신 Claude Code를 거의 전적으로 hands-off 방식으로 사용
  • "6개월 전이었다면 가상 프로그래머 인턴의 엔지니어링 리드 역할을 선호하게 될 거라고 했으면 믿지 않았을 것"
• 2007년 이후 블로그 전체 글의 약 18%에 해당하는 36개 포스트를 작성
  • 에이전트 래빗홀에 빠진 후 호기심에 불타 프로그래머, 창업자 등과 약 100회의 대화 진행
• 2025년은 세계적으로 좋지 않은 해이기도 해서, 별도의 블로그(dark.ronacher.eu) 를 만들어 그런 생각을 분리

에이전트의 해

• 4~5월 Claude Code에 대한 집착으로 시작하여, 수개월간 자체 에이전트 구축과 타인 에이전트 사용 반복
• SNS에서 AI에 대한 다양한 의견이 폭발함
• 현재 안정적인 상태에 도달: 코드 생성, 파일 시스템, 인터프리터 글루를 통한 프로그래밍적 도구 호출, 스킬 기반 학습에 집중
  • Claude Code가 혁신한 방식이 여전히 최첨단이며, 파운데이션 모델 제공자들이 스킬에 집중하는 것이 이 믿음을 강화함
• TUI(텍스트 기반 사용자 인터페이스) 가 강하게 복귀한 점이 놀라움
  • 현재 명령줄에서 Amp, Claude Code, Pi 사용
  • Amp는 Apple이나 Porsche 같은 느낌, Claude Code는 저렴한 Volkswagen, Pi는 해커들이 선호하는 오픈소스 선택
  • 모두 자신들의 제품을 만드는 데 과도하게 사용하는 사람들이 만든 프로젝트 느낌이지만, **각기 다른 트레이드오프 ** 존재
• LLM과 도구 실행의 결합에 계속 놀라움
  • 연초에는 주로 코드 생성에 사용했지만, 이제 일상적인 일에도 에이전트를 많이 활용
  • 2026년에는 소비자 제품으로의 흥미로운 진전이 있을 것으로 예상
  • LLM이 이제 삶을 정리하는 데 도움을 주고 있으며, 그 활용도가 더 커질 것으로 기대

기계와 나

• LLM이 프로그래밍뿐 아니라 다른 영역까지 도와주면서, 기계와의 관계를 재고하기 시작
• 도구와 준사회적 유대감(Parasocial Bond) 을 형성하지 않기가 점점 어려워지고 있으며, 이것이 이상하고 불편함
• 오늘날 대부분의 에이전트는 기억이 거의 없고 성격도 별로 없지만, 그런 것을 가진 에이전트를 직접 만들기는 쉬움
  • 메모리가 있는 LLM은 떨쳐내기 어려운 경험
• 2년간 이 모델들을 단순한 토큰 텀블러로 생각하려 훈련했지만, 그 단순화된 관점은 더 이상 통하지 않음
• 우리가 만드는 시스템은 인간적 경향을 가지지만, 인간 수준으로 격상시키는 것은 실수임
• "에이전트" 라는 용어에 점점 문제를 느끼지만 더 나은 단어가 없음
  • 에이전시와 책임은 인간에게 남아야 하기 때문
  • 무엇이 되어가든, 주의하지 않으면 해로울 수 있는 감정적 반응(챗봇 사이코시스 참조)을 유발 가능
  • 이러한 창조물을 우리와의 관계에서 적절히 명명하고 위치시키지 못하는 것은 해결해야 할 과제
• 이러한 의도치 않은 의인화로 인해, 기계와 작업하는 방식을 설명할 적절한 언어를 찾기 어려움
  • 이것이 본인만의 문제가 아니며 다른 사람들도 마찬가지
  • 현재 이러한 시스템을 완전히 거부하는 사람들과 작업할 때 더 불편함을 야기
  • 에이전틱 코딩 도구 기사에 대한 가장 흔한 댓글 중 하나가 기계에 성격을 부여하는 것에 대한 거부

의견이 넘쳐남

• AI를 많이 사용하면서 예상치 못한 측면: 다른 무엇보다 바이브에 대해 훨씬 더 많이 이야기함
• 이 작업 방식은 1년도 안 되었지만, 반세기의 소프트웨어 엔지니어링 경험에 도전함
• 많은 의견이 있지만 어떤 것이 시간의 검증을 견딜지 말하기 어려움
• 동의하지 않는 기존 통념이 많지만, 내 자신의 의견을 뒷받침할 근거는 없음
  • 연중 MCP에 대한 어려움에 대해 꽤 목소리 높여 공유했지만, "나한테는 안 됨" 이상의 근거가 없었음; 다른 사람들은 이를 맹신함
  • 모델 선택도 마찬가지: Peter(연초에 Claude에 빠지게 해준 사람)는 Codex로 옮겨 만족 중; 본인도 코덱스를 더 많이 사용하게는 되었지만, 클로드 만큼 즐겁지는 않음
  • Claude에 대한 선호를 뒷받침할 것은 바이브 외에 없음
• 일부 바이브는 의도적인 신호와 함께 온다는 것을 아는 것도 중요
  • 온라인에서 볼 수 있는 많은 사람들의 견해는 한 제품에 대해 다른 제품보다 재정적 이해관계가 있음 (투자자이거나 유료 인플루언서)
  • 제품을 좋아해서 투자자가 되었을 수도 있지만, 그 관계에 의해 견해가 영향받고 형성되었을 가능성도 있음

아웃소싱 vs 직접 구축

• 오늘날 AI 회사의 라이브러리를 보면 Stainless나 Fern으로 만들어졌음을 알 수 있음
  • 문서는 Mintlify 사용, 사이트 인증 시스템은 Clerk일 수 있음
• 이전에는 직접 만들었을 서비스를 전문 회사에 아웃소싱하는 것이 증가하면서, 사용자 경험의 일부 측면에서 기준이 높아짐
• 그러나 에이전틱 코딩 도구의 새로운 힘으로, 이것의 상당 부분을 직접 만들 수 있음
  • Claude에게 Python과 TypeScript용 SDK 생성기를 만들게 함 — 호기심 반, 충분히 쉬워 보여서 반
• 단순한 코드와 직접 만들기의 지지자로서, AI가 더 적은 의존성 위에 구축하도록 장려할 잠재력이 있다는 점에서 다소 낙관적
• 동시에, 모든 것을 아웃소싱하는 현재 추세를 감안할 때 그 방향으로 가고 있는지는 명확하지 않음

배운 것과 바라는 것

• 이제부터는 예측이 아니라 다음에 에너지를 쏟을 수 있는 곳에 대한 바람을 얘기해보고자 함
• 정확히 무엇을 찾는지는 모르지만, 고통점을 지적하고 맥락과 생각할 거리를 제공하고자 함

• 새로운 종류의 버전 관리

  • 가장 큰 예상치 못한 발견: 코드 공유를 위한 기존 도구의 한계에 도달
  • GitHub의 풀 리퀘스트 모델은 AI 생성 코드를 제대로 리뷰하기에 충분한 정보를 담지 못함 — 변경을 이끈 프롬프트를 볼 수 있으면 좋겠음
  • GitHub만의 문제가 아니라 git도 부족
  • 에이전틱 코딩에서 모델이 오늘날 작동하게 하는 것의 일부는 실수를 아는 것
    • 이전 상태로 되돌릴 때, 도구가 무엇이 잘못되었는지 기억하기를 원함
    • 더 나은 말이 없지만, 실패에 가치가 있음
    • 인간으로서도 어디로도 이끌지 않은 경로를 아는 것이 도움이 될 수 있지만, 기계에게 이것은 중요한 정보
    • 대화 기록을 압축하려 할 때 이것을 알게 됨: 잘못된 경로를 버리면 모델이 같은 실수를 다시 시도
  • 일부 에이전틱 코딩 도구는 worktree를 스핀업하거나 git에서 복원을 위한 체크포인트를 생성, 대화 내 브랜치 및 언두 기능 제공
  • 이러한 도구를 더 쉽게 작업할 수 있게 하는 UX 혁신의 여지가 있음
    • stacked diffs와 Jujutsu 같은 대안 버전 관리 시스템에 대한 논의가 나오는 이유
  • 이것이 GitHub를 바꿀지, 새로운 경쟁 업체가 등장할 공간을 만들지 모르겠지만 후자가 되기를 바람
  • 진정한 인간 입력을 더 잘 이해하고 기계 출력과 구분하고 싶음
  • 프롬프트와 실패한 시도를 보고 싶음
  • 그런 다음 병합 시 모두 압축하되, 필요하면 전체 기록을 검색할 수 있는 방법을 원함

• 새로운 종류의 리뷰

  • 버전 관리와 관련됨: 현재 코드 리뷰 도구는 AI와 맞지 않는 엄격한 역할 정의를 할당
  • GitHub 코드 리뷰 UI 예: 정기적으로 PR 뷰에 대한 코멘트를 사용하여 내 에이전트에게 노트를 남기고 싶지만, 그렇게 할 수 있는 안내된 방법이 없음
    • 리뷰 인터페이스는 자신의 코드를 리뷰하게 허용하지 않고 코멘트만 가능하지만, 그것은 같은 의도가 아님
  • 증가된 코드 리뷰가 이제 로컬에서 본인과 에이전트 사이에서 일어나는 문제도 있음
    • 예: GitHub의 Codex 코드 리뷰 기능은 한 번에 하나의 조직에만 바인딩될 수 있어 작동이 중단됨
    • 이제 명령줄에서 Codex로 리뷰하지만, 그것은 반복 주기의 전체 부분이 팀의 다른 엔지니어에게 보이지 않음을 의미; 이것은 작동하지 않음
  • 코드 리뷰는 VCS의 일부가 되어야 할 것 같은 느낌

• 새로운 관측성(Observability)

  • 관측성이 다시금 주목받을 만한 가치가 있음
  • 이제 완전히 새로운 수준에서 이를 활용할 필요와 기회가 모두 생기게 됨
  • 대부분의 사람들은 자체 eBPF 프로그램을 만들 수 있는 위치에 있지 않았지만, LLM은 가능
  • 많은 관측성 도구가 복잡성 때문에 SQL을 피했지만, LLM은 어떤 독점 쿼리 언어보다 SQL을 더 잘함
    • 쿼리 작성, grep, map-reduce, LLDB 원격 제어 가능
    • 어떤 구조와 텍스트가 있는 것은 갑자기 에이전틱 코딩 도구가 성공할 비옥한 땅
  • 미래의 관측성이 어떻게 생겼는지는 모르지만, 여기서 많은 혁신을 볼 것이라는 강한 직감이 있음
    • 기계에 대한 피드백 루프가 좋을수록 결과가 좋음
  • 나도 정확히 내가 무엇을 요청하는지 확실하지 않지만, 과거의 과제 중 하나는 더 나은 관측성을 위한 많은 멋진 아이디어들 — 특히 더 타겟팅된 필터링을 위한 서비스의 동적 재구성 — 이 복잡하고 사용하기 어려워 사용자 친화적이지 않았다는 것
    • 그러나 이제 LLM의 이러한 힘든 작업 수행 능력 증가로 인해 그것들이 올바른 솔루션일 수 있음
    • 예: Python 3.14에 외부 디버거 인터페이스 탑재 — 에이전틱 코딩 도구를 위한 놀라운 기능

• 슬롭과 함께 작업하기

  • 다소 논쟁적일 수 있지만, 올해 관리하지 못한 것은 기계에 완전히 맡기는 것
  • 여전히 일반 소프트웨어 엔지니어링처럼 다루고 많이 리뷰함
  • 점점 더 많은 사람들이 이 엔지니어링 모델로 작업하지 않고 대신 기계에 완전히 맡기고 있음을 인식
    • 미친 소리처럼 들리지만, 일부 사람들이 이것으로 꽤 성공하는 것을 봤음
    • 이것에 대해 어떻게 생각해야 할지 아직 모르지만, 결국 코드가 생성되더라도 그 새로운 세계에서의 작업 방식은 본인이 편안한 세계와 매우 다름이 분명
    • 그 세계가 여기 있으니, 이것들을 분리하기 위한 새로운 사회적 계약이 필요할 수 있음
  • 가장 명백한 버전은 오픈소스 프로젝트에 대한 이러한 유형의 기여가 증가하고 있다는 것
    • 솔직히 그 모델로 작업하지 않는 사람에게는 모욕
    • 그런 풀 리퀘스트를 읽으면 상당히 분노를 느낌
  • 개인적으로 기여 가이드라인과 풀 리퀘스트 템플릿으로 이 문제를 공격하려 했음
    • 그러나 이것은 풍차와의 싸움 같음
    • 이것은 우리가 하는 것을 바꾸는 것에서 해결책이 오지 않을 수 있는 것
    • 대신, AI 엔지니어링에도 찬성하는 목소리 높은 사람들이 에이전틱 코드베이스에서 좋은 행동이 무엇인지 말하는 것에서 올 수 있음
    • 그리고 그것은 리뷰되지 않은 코드를 던지고 다른 사람이 그 문제를 해결하게 하는 것이 아님