# 바이브의 해 > Clean Markdown view of GeekNews topic #25352. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25352](https://news.hada.io/topic?id=25352) - GeekNews Markdown: [https://news.hada.io/topic/25352.md](https://news.hada.io/topic/25352.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-26T11:31:02+09:00 - Updated: 2025-12-26T11:31:02+09:00 - Original source: [lucumr.pocoo.org](https://lucumr.pocoo.org/2025/12/22/a-year-of-vibes/) - Points: 21 - Comments: 1 ## Summary 2025년은 **에이전틱 코딩 도구**가 프로그래밍의 주체를 바꾼 해로, 개발자는 직접 코드를 작성하기보다 가상 인턴을 지휘하는 **엔지니어링 리드**로 이동하는 모습을 많이 보이고 있습니다. LLM과 도구 실행의 결합은 코드 생성에서 일상 업무 관리로 확장되며, 인간과 기계의 관계를 다시 묻고 있고요. 기존 **버전 관리·코드 리뷰 시스템**이 AI 생성 코드를 다루기에 한계를 드러내면서, 프롬프트 이력과 실패 경로까지 추적하는 새로운 협업 인프라가 필요하다고도 이야기 합니다. 올해의 AI 트렌드 정리는 다들 비슷한 느낌인 것 같아요. ## Topic Body - 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년간 이 모델들을 단순한 토큰 텀블러로 생각하려 훈련했지만, 그 단순화된 관점은 더 이상 통하지 않음 - 우리가 만드는 시스템은 인간적 경향을 가지지만, 인간 수준으로 격상시키는 것은 실수임 - **"에이전트"** 라는 용어에 점점 문제를 느끼지만 더 나은 단어가 없음 - 에이전시와 책임은 인간에게 남아야 하기 때문 - 무엇이 되어가든, 주의하지 않으면 **해로울 수 있는 감정적 반응**([챗봇 사이코시스](https://en.wikipedia.org/wiki/Chatbot_psychosis) 참조)을 유발 가능 - 이러한 창조물을 **우리와의 관계에서 적절히 명명하고 위치시키지 못하는 것**은 해결해야 할 과제 - 이러한 의도치 않은 의인화로 인해, 기계와 작업하는 방식을 설명할 적절한 언어를 찾기 어려움 - 이것이 본인만의 문제가 아니며 다른 사람들도 마찬가지 - 현재 이러한 시스템을 완전히 거부하는 사람들과 작업할 때 더 불편함을 야기 - 에이전틱 코딩 도구 기사에 대한 가장 흔한 댓글 중 하나가 기계에 성격을 부여하는 것에 대한 거부 ### 의견이 넘쳐남 - AI를 많이 사용하면서 예상치 못한 측면: 다른 무엇보다 **바이브**에 대해 훨씬 더 많이 이야기함 - 이 작업 방식은 1년도 안 되었지만, **반세기의 소프트웨어 엔지니어링 경험에 도전**함 - 많은 의견이 있지만 어떤 것이 시간의 검증을 견딜지 말하기 어려움 - 동의하지 않는 기존 통념이 많지만, 내 자신의 의견을 뒷받침할 근거는 없음 - 연중 **MCP**에 대한 어려움에 대해 꽤 목소리 높여 공유했지만, "나한테는 안 됨" 이상의 근거가 없었음; 다른 사람들은 이를 맹신함 - 모델 선택도 마찬가지: **[Peter](https://steipete.me/)**(연초에 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 엔지니어링에도 찬성하는 목소리 높은 사람들이 **에이전틱 코드베이스에서 좋은 행동이 무엇인지 말하는 것**에서 올 수 있음 - 그리고 그것은 **리뷰되지 않은 코드를 던지고 다른 사람이 그 문제를 해결하게 하는 것이 아님** ## Comments ### Comment 48269 - Author: neo - Created: 2025-12-26T11:32:02+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46352875) - 나는 **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는 ‘감정’과 ‘느낌’의 영역이라 **측정 불가능한 품질** 문제를 가짐