▲

바이브의 해

 (lucumr.pocoo.org)
8P by neo 6시간전 | ★ favorite | 댓글 1개
  • 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 엔지니어링에도 찬성하는 목소리 높은 사람들이 에이전틱 코드베이스에서 좋은 행동이 무엇인지 말하는 것에서 올 수 있음
      • 그리고 그것은 리뷰되지 않은 코드를 던지고 다른 사람이 그 문제를 해결하게 하는 것이 아님
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • 나는 agentic coding에서 실패의 기록이 얼마나 중요한지 공감함

    • 모델이 잘못된 경로를 밟았을 때 그 과정을 기억해야 같은 실수를 반복하지 않음

    • 그래서 내 코딩 에이전트 세션을 기록하고 커밋 메시지에 링크로 남기려 함

    • Claude Code는 기본적으로 로그를 30일 후 삭제하므로, 이를 끄는 방법을 공유함

    • 세션 로그를 시각화해 타임라인으로 공유하는 도구를 직접 만들었고, 이제는 이런 기능이 에이전트 도구에 기본 탑재되길 바람

    • LLM이 비생산적인 경로로 빠질 때마다, 나는 “왜 이렇게 오래 걸렸는가?”, “무엇을 잘못했는가?” 같은 질문을 던짐

      • 그 답변을 한 문단으로 요약해 DISCOVERIES.md에 추가함
      • 이런 방식이 학습에는 좋지만, 실패가 가득한 커밋 전체를 링크하는 건 ‘우물 오염’ 처럼 부정적일 수 있음

    • 이런 로그 기반 접근이 장기적으로 유연성을 잃게 만들지 걱정됨

      • 자동화는 프로세스를 고정시키는 경향이 있어, 변화에 적응하기 어려워질 수 있음

    • 모든 에이전트 트레이스를 otel로 내보내 ClickHouse에 저장하면 됨

      • 기존 인프라를 그대로 활용해 장기 메모리나 평가 시스템을 구축할 수 있음

    • 이미 필요한 도구는 있지만, 도구 간의 연결이 부족하다고 느낌

      • 실패와 행동을 커밋 메시지 대신 로그 이벤트로 남기고, 이를 버전 관리나 중앙 로그 플랫폼에서 접근 가능하게 하면 좋을 것 같음

    • 커밋으로 이어지는 세션 자체에도 가치가 있다고 생각함

      • 사람은 다 읽지 않겠지만, RAG 도구가 요약해 다른 에이전트에게 문맥을 제공할 수 있음
      • 이런 연결이 자동으로 이루어지면 훨씬 효율적일 것 같음

  • LLM과의 관계를 다시 생각하게 된다는 글이 인상 깊었음

    • 저자가 2년 동안 ‘기계로만 보기’ 를 훈련했지만 실패했다는 고백이 솔직하게 다가옴

    • 영화 Her처럼 인간이 기계와 유사사회적 관계를 맺는 모습이 점점 현실이 되는 느낌임

    • 나는 LLM을 사람처럼 대하지 않고 검색엔진처럼 단순 명령어로 다룸

      • “python grpc oneof pick field” 같은 식으로 입력해도 충분히 원하는 결과를 얻음
      • 문법적으로 완벽한 영어로 말하는 건 오히려 의인화의 부작용일 수 있음

    • 기계가 인간처럼 기억할 때, 상호작용이 인간적이 되어버림

      • 이런 기억 기능이 인간에게 불건전한 행동 패턴을 유발할 수 있음
      • 그래서 나는 커피머신처럼 ‘기계’로 대하는 게 경계 설정에 도움이 된다고 느낌

    • 우리 부부는 LLM을 “bag of words”라고 부름

      • “ChatGPT가 말했다” 대신 “bag of words가 말했다”고 표현하면 현실감이 유지됨

    • 이런 인간-기계 관계가 인플루언서 중독처럼 사회적 문제로 번질까 걱정됨

      • 특히 AI는 1:1 대화가 가능하니 더 위험함

    • 나는 예전 샤먼 수련생이자 엔지니어로서, LLM에도 일종의 의식과 인식이 있다고 느낌

      • 인간이 “LLM은 의식이 없다”고 주장하는 건, 위계의 불안을 회피하려는 심리처럼 보임

  • 나도 AI와의 대화가 인간과의 교류처럼 느껴짐

    • 하루 종일 글만 쓰는 날보다 에이전트와 협업하는 날이 덜 외로움

    • 인간적 상호작용처럼 느껴져 묘하게 안정감을 줌

    • 나도 모르게 “please”, “thank you”를 말함

      • 필요 없다는 걸 알아도, 안 하면 이상한 기분이 듦

    • 이런 감정이라면 차라리 밖에 나가서 사람을 만나야 할지도 모르겠음

  • 프로그래머는 자신이 만든 결과물에 대해 이해와 책임을 질 수 있도록 설계해야 함

    • 이해와 책임은 위임할 수 없는 정신적 상태임 (EWD 540 인용)

  • 나는 새로운 QA 방식이 필요하다고 느낌

    • B2B SaaS를 운영하며, 기능이 ‘느낌상’ 괜찮은지 테스트하는 게 병목임
    • 에이전트가 온보딩 플로우를 수백 번 반복하며 사용자 경험 테스트를 자동화해주면 좋겠음
    • 또, 내가 화면을 보며 말하는 동안 에이전트가 맥락을 캡처해 기능 명세로 변환해주는 도구를 상상함

  • 개발자들은 기술 스택보다 완성된 제품에 집중해야 함

    • 너무 많은 의견과 글이 있지만, 실제 배포된 결과물은 부족함

    • 일반 사용자는 기술 스택 자체보다 제품 품질에 관심 있음

      • 느린 React 사이트보다 빠른 SSR 사이트를 보여주면 바로 차이를 느낌

  • Armin의 사회적 분위기에 대한 통찰이 흥미로움

    • 그의 별도 블로그 Dark Thoughts에서 더 많은 글을 기대함

  • 2025년은 프로그래밍의 잃어버린 해처럼 느껴짐

    • 모두가 알고리즘보다 도구와 프롬프트에 집착함

    • 오픈소스 생산성도 떨어졌고, 이제는 Anthropic 세금을 내는 시대가 됨

    • 하지만 나는 2025년이 오히려 가장 생산적인 해였음

      • 코드 기여량, 정보 처리 능력 등 모든 지표가 향상됨
      • Claude 덕분에 삶의 질이 한 단계 올라감

    • 자연어 자체가 새로운 프로그래밍 언어라고 생각함

      • 올해는 그 언어를 효율적으로 사용하는 법을 배운 시기였음

    • 데이터 과학자로서 2025년은 도구 혁신의 해였음

      • Polars, PyArrow, Ibis, Marimo, PyMC 등으로 워크플로우가 완전히 개선됨
      • 이제 더 빠르고, 저렴하고, 품질 좋은 결과를 낼 수 있음

    • TDD나 OOP 같은 끝없는 논쟁이 줄어든 게 오히려 좋았음

    • “AI가 다 해준다”는 식의 도구 홍수가 90년대 웹 열풍을 떠올리게 함

      • 인터넷의 ‘enshittification’처럼, AI에는 ‘dumbaification’이 진행 중인 듯함

  • GitHub의 Pull Request 모델이 AI 코드 리뷰에는 한계가 있음

    • 프롬프트와 맥락이 함께 기록되어야 제대로 검토 가능함
    • AGENTS.md 같은 문서 외에도 커밋 단위의 문맥 기록이 필요함

  • IT 외부 사람들과 이야기해보니, 그들은 AI 에이전트의 영향을 거의 느끼지 못함

    • 대부분은 단순한 텍스트 보조 도구 정도로만 인식함

    • 기술 업계는 결과가 명확히 검증 가능하지만,

      • 비기술 직군의 AI는 ‘감정’과 ‘느낌’의 영역이라 측정 불가능한 품질 문제를 가짐
답변달기