# Agentic Coding은 함정이다 > Clean Markdown view of GeekNews topic #29155. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29155](https://news.hada.io/topic?id=29155) - GeekNews Markdown: [https://news.hada.io/topic/29155.md](https://news.hada.io/topic/29155.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-04T16:38:10+09:00 - Updated: 2026-05-04T16:38:10+09:00 - Original source: [larsfaye.com](https://larsfaye.com/articles/agentic-coding-is-a-trap) - Points: 1 - Comments: 1 ## Topic Body - **Agentic coding**은 사람이 요구사항과 계획을 만들고 여러 코딩 에이전트가 구현하는 방식이지만, 생성·커밋되는 코드와 사람 사이의 거리를 계속 벌리는 구조임 - 이 방식은 숙련된 개발자가 아키텍처 수준에서 비판적으로 검토해야 성공하지만, AI 과사용은 그에 필요한 기술을 약화시키는 **인지 부채(cognitive debt)** 를 낳을 수 있음 - Anthropic 연구가 다룬 **감독의 역설**처럼 Claude를 효과적으로 쓰려면 감독할 코딩 역량이 필요하고, 코딩 에이전트 사용은 바로 그 역량을 약화시킬 수 있음 - LLM은 깊은 이해와 간결성보다 일정 시간 안에 생성되는 코드량을 늘리는 방향으로 쓰이기 쉬우며, 모호한 요구를 가정이나 환각으로 채워 더 많은 리뷰와 수정, 토큰 사용을 만들 수 있음 - Claude 장애와 토큰 비용 변동은 **벤더 종속**과 비용 불확실성을 드러내며, AI는 구현을 대체하는 오케스트레이터보다 계획 보조·문서·리서치·제한적 위임 도구로 쓰는 편이 이해 부채를 줄일 수 있음 --- ### 구조적 트레이드오프 - 코딩 에이전트는 유용하고 강력하지만, 이미 정량적·실무적으로 따져야 할 트레이드오프가 있음 - AI의 비결정성에서 오는 모호성을 완화하려면 주변 시스템의 복잡도가 증가함 - 많은 개발자의 기술이 위축될 수 있음 - Claude Code 장애처럼 특정 벤더 장애가 팀 전체를 멈춰 세울 수 있음 - 직원 비용은 고정적이지만 토큰 비용은 계속 변동하고 증가할 수 있음 - 이 방식이 성공하려면 숙련된 개발자가 아키텍처 수준에서 비판적으로 사고하며, 수천 줄의 생성 코드에서 문제가 커지기 전에 발견할 수 있어야 함 - 하지만 AI 도구는 그에 필요한 비판적 사고와 인지적 명료성에 부정적 영향을 줄 수 있으며, [인지 부채(cognitive debt)](https://margaretstorey.com/blog/2026/02/18/cognitive-debt-revisited/)가 커질 수 있음 ### 단순한 새 추상화가 아님 - “프로그래머가 더 높은 추상화 계층으로 올라가는 것”이라는 해석만으로는 충분하지 않음 - 모호성이 높아지는 것이 곧 더 높은 수준의 추상화를 뜻하지는 않음 - FORTRAN, 컴파일러, 고수준 언어가 등장했을 때도 버그, 불안정성, 효율 저하, “마법” 증가를 걱정하는 반응은 있었음 - 과거의 우려는 대부분 새 기술을 받아들이면 무엇을 잃을지에 대한 규범적·이론적 걱정이었지만, AI 도구는 등장 후 몇 년 만에 이미 실질적 영향을 드러내고 있음 - 영향은 주니어 개발자에게만 국한되지 않고 10년 이상 경험을 가진 개발자에게도 나타남 - 주니어 개발자는 코드를 직접 다루는 과정이 줄고 생성 코드를 리뷰하는 역할로 밀려나면서 더 가파른 학습 곡선을 마주함 - 코드 리뷰는 중요하지만 학습 과정의 절반에 그치며, 코드를 직접 작성·디버깅하며 겪는 마찰이 사라지면 학습 능력이 크게 약해짐 - 이 현상은 연구에 시간이 걸리기 때문에 실시간 상황을 파악하려면 일화적 증거도 중요하지만, [MIT Media Lab 보고서](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)와 [Microsoft 관련 보도](https://www.404media.co/microsoft-study-finds-ai-makes-human-cognition-atrophied-and-unprepared-3/)처럼 뒷받침하는 자료도 있음 ### 이번 변화가 다른 이유 - C++ 개발자가 Java나 Python으로 옮겼다고 해서 “브레인 포그”를 호소하지는 않았고, 시스템 관리자가 AWS로 옮겼다고 해서 네트워킹 이해 능력을 잃는다고 느끼지도 않았음 - 시니어 엔지니어가 관리 역할로 이동하며 코딩을 덜 하고 시간이 지나 “rusty”해지는 현상은 새롭지 않음 - 기존 경로에서는 수십 년 동안 코딩, 마찰, 문제 해결을 축적한 엔지니어가 문법보다 아키텍처 결정을 더 많이 다루는 역할로 이동했음 - 지금은 그런 장기적 경험 없이도 개발자들이 AI 에이전트를 관리해야 하는 더 높은 수준의 워크플로로 이동하고 있음 - 문제는 이런 워크플로가 수십 년의 경험으로 얻은 것과 같은 기술을 요구한다는 데 있음 - 시니어 엔지니어도 예외가 아님 - [Simon Willison](https://simonwillison.net/2026/Feb/15/cognitive-debt/)은 거의 30년 경력의 개발자지만, 애플리케이션이 무엇을 할 수 있고 어떻게 동작하는지에 대한 “확고한 정신 모델”이 없으면 기능이 추가될수록 추론이 어려워진다고 밝힘 ### 숙련된 오케스트레이터의 역설 - Anthropic의 최근 [연구](https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic#and-less-hands-on-practice)는 코딩 에이전트를 자주 사용할 때의 위험으로 “감독의 역설”을 다룸 - 핵심은 Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과사용으로 약화될 수 있는 바로 그 코딩 기술이 필요하다는 점임 - LinkedIn에서 50명의 엔지니어를 관리하는 [Sandor Nyako](https://www.businessinsider.com/leaders-worry-about-skill-atrophy-due-to-ai-adoption-2025-10#8786254a-3fe1-4407-98a2-7c2eaac66b6f)는 조직 안에서 기술 위축이 퍼지는 것을 보고, 팀에 “비판적 사고나 문제 해결이 필요한 작업”에는 AI를 쓰지 말라고 요청함 - 그는 기술을 키우려면 어려움을 겪고 문제를 깊이 생각하는 근육을 길러야 하며, 비판적 사고가 없으면 AI가 정확한지 질문하기 어렵다고 봄 - “과사용”의 기준도 불분명하지만, [데이터 기반 연구](https://www.anthropic.com/research/AI-assistance-coding-skills)와 [일화적 자료](https://www.youtube.com/watch?v=pzkwn3hu1Cc)는 몇 달 안에도 기술이 빠르게 약화될 수 있음을 보여줌 - 코딩 에이전트 사용은 에이전트를 잘 관리하는 데 필요한 기술 자체를 약화시키는 모순을 만듦 ### LLM은 잘못된 부분을 가속함 - 반드시 더 빠르게 코드를 작성해야 했던 것은 아님 - 특히 완전히 이해하지 못한 코드나 합리적인 시간 안에 리뷰할 수 없는 대량의 코드를 더 빠르게 만드는 것이 필요한 것은 아니었음 - AI 이전의 좋은 개발자 우선순위는 대체로 다음과 같았음 - 코드와 코드베이스의 관계를 이해함 - 문서화된 효율적 표준에 맞는지 확인함 - 가독성을 유지하면서 목표 달성에 필요한 코드 줄 수를 최소화함 - 처리 시간을 고려함 - Agentic coding과 LLM은 이 우선순위를 사실상 뒤집음 - 현재의 역량과 사용 방식은 일정 시간 안에 생성되는 코드량을 늘려 속도를 높이는 데 초점을 맞추는 경향이 있음 - 속도는 높은 숙련도의 자연스러운 부산물이지만, 강제로 밀어붙이면 정확도 저하로 이어짐 - LLM을 깊은 이해와 간결성을 높이는 방식으로 쓸 수는 있지만, 강제 도입과 조직 전반의 [토큰 사용량 중심 과열](https://www.pymnts.com/artificial-intelligence-2/2026/ai-adoption-is-being-measured-in-tokens-but-the-metric-falls-short-experts-say/)은 실제 사용이 그렇게 흘러가지 않음을 보여줌 ### 코딩은 계획이기도 함 - 일부 개발자는 코드로 더 잘 계획하고 더 잘 생각함 - 코드로 사고하고 작업하는 일은 무의미한 반복 노동이 아니라, 보안·성능·사용자 경험·유지보수성까지 기술적 수준에서 생각하게 만드는 과정임 - OpenCode를 만든 Dax는 [Spec Driven Development 관련 인터뷰](https://youtu.be/IGsbARhERqc?t=501)에서, 새롭거나 어려운 작업을 할 때 직접 코드를 입력하는 과정으로 무엇을 해야 하는지 알아낸다고 말함 - 그는 거대한 스펙을 먼저 쓰기보다 타입, 함수 간 상호작용, 폴더 구조를 직접 만져보며 개념을 잡는 방식을 선호함 - 사람이 말한 것이 실제 의도와 항상 같지는 않으며, LLM은 모호성을 가정이나 환각으로 채움 - 그 결과 더 많은 리뷰, 더 많은 에이전트 수정, 더 많은 토큰 사용, 생성물과의 더 큰 단절이 발생함 - 반대로 매우 명확하고 구조화된 프롬프트를 작성해도 LLM은 환각 메서드를 출력할 수 있음 - LLM은 컴파일러가 아니라 다음 토큰 예측 엔진이기 때문에, 결정적 시스템을 확률적 시스템으로 대체하고 모호성이 0이 되기를 기대할 수 없음 - [AI에 적극적인 시니어 개발자들](https://www.youtube.com/watch?v=cv6rwHTGT5w)도 이런 단절을 커지는 문제로 보기 시작함 ### 벤더 종속과 비용 불확실성 - Claude 장애 당시 일부 개발자와 엔지니어링 팀이 멈춰 섰다는 [게시물](https://www.linkedin.com/pulse/claudes-outages-show-dark-side-ai-productivity-total-system-lam-osbjc/)들이 나왔음 - 일부 워크플로와 코딩 능력은 이미 특정 AI 벤더에 크게 의존하는 수준에 도달했음 - 예전에는 키보드와 텍스트 편집기만 있으면 수행할 수 있던 기술이 AI 모델 제공자 구독을 필요로 하게 됨 - ## 토큰 비용은 예측하기 어려움 - 모델 제공자들은 [크게 보조금을 받고](https://www.theverge.com/ai-artificial-intelligence/917380/ai-monetization-anthropic-openai-token-economics-revenue), 모델 자체도 계속 변하는 기반 위에 있음 - 새 모델 출시는 높은 벤치마크, 과열, 실제 사용 후 “너프됐다”는 불만과 같은 패턴을 반복함 - 같은 일을 처리하는 데 2~3배 더 많은 토큰을 태운다는 불만도 뒤따름 - 직원 비용은 알 수 있지만, 토큰 비용은 일별·월별·연도별로 예측하기 어려움 - 팀 전체가 agentic coding을 기본값으로 사용하면 비용 계정은 매우 유연하게 유지되어야 함 - Primeagen은 완전한 agentic workflow를 쓰면 “[모델 제공자가 사실상 당신을 소유한다](https://www.youtube.com/watch?v=_vB0PDzaa7I&t=3299s)”고 말함 - 토큰 소비 비용을 지불해야만 예전에는 비판적 사고와 문제 해결 능력으로 하던 일을 수행하는 산업 구조가 만들어질 수 있음 - 이는 단순한 제품 벤더 종속이 아니라 산업 전체의 기술 역량에 대한 벤더 종속에 가까움 - 재정적·지적 기반이 언제든 흔들릴 수 있으며, 로컬 LLM은 그 수준의 사용량을 흡수할 만큼 준비되지 않았음 - 이 문제는 이론이 아니라 이미 [보도되고 있으며](https://www.youtube.com/watch?v=5HaQnIPrfKk), 모델 제공자들도 직접 조명하고 있음 - Anthropic의 또 다른 [연구](https://www.anthropic.com/research/AI-assistance-coding-skills)는 디버깅 기술이 **47% 급감**했다고 밝힘 - AI를 직장, 특히 소프트웨어 엔지니어링에 공격적으로 도입하면 빠른 결과를 위해 AI에 기대는 대신, 문제가 생겼을 때 디버깅하는 핵심 기술을 쌓지 못할 수 있음 ### AI의 역할을 낮추는 접근 - LLM은 학습과 역량 향상을 위한 강력한 도구가 될 수 있음 - 개념과 기법을 더 깊고 넓게 탐색하게 하고, 예전보다 더 적은 수고로 새 아이디어를 실험하게 해줄 수 있음 - 코드 생성 도구 자체는 새로운 것이 아님 - [Emmet](https://code.visualstudio.com/docs/languages/emmet), 자동완성, 스니펫은 코드를 직접 덜 쓰고 생성하기 위한 도구였음 - COBOL도 `MOVE`, `WRITE` 같은 영어식 단어로 더 적은 작성량에 더 많은 명령을 담으려 했음 - jQuery의 모토도 “[write less, do more](https://brand.jquery.org/logos/)”였음 - LLM은 이런 코드 생성 도구의 또 다른 추가물로 볼 수 있음 - 중요한 차이는 LLM과 코딩 에이전트를 보조 프로세스로 활용하는 데 있음 - 생산성을 위해 개인의 기술을 희생하지 않고, 계획 단계의 브레인스토밍에는 AI를 활용하되 구현에는 계속 적극적으로 관여하는 방식이 가능함 - 필요할 때만 위임하면 생산성 이득을 얻으면서 이해 부채를 줄일 수 있음 ### 일상적인 사용 방식 - LLM을 스펙과 계획 생성에 사용하되, 구현은 사람이 주도함 - 이는 “오케스트레이션” 워크플로를 뒤집는 방식이며, 작업에 따라 20%에서 100%까지 직접 코딩함 - 모델을 사용할 때도 자주 의사 코드를 작성해 요청과 생성 코드 사이의 거리를 줄임 - 모델은 임시 코드 생성, 대화형 문서, 리서치 도구로 활용함 - [책임 있는 위임 도구](https://cheewebdevelopment.com/dont-vibe-code-delegate-responsible-development-with-llms/)처럼 사용해 질문하고, 반복하고, 리팩터링하고, 접근법을 더 명확히 함 - 한 번에 리뷰할 수 있는 양보다 더 많은 코드는 생성하지 않음 - 리뷰하기에 너무 많으면 속도를 늦추고 작업을 쪼개며, 필요하면 직접 리팩터링해 최종 결과를 포괄적으로 이해함 - 직접 해본 적이 없거나 혼자서는 할 수 없는 구현을 LLM이나 에이전트에 맡기지 않음 - 예외는 교육이나 튜토리얼 목적이며, 그 결과물은 이후 버리는 경우가 많음 - 요약하면 AI를 Star Trek의 Data가 아니라 Ship’s Computer처럼 사용해야 함 ### 더 빠르기보다 더 좋은 작업 - 모델의 생산성 향상은 실제로 존재함 - 동시에 작업을 직접적이고 자주 다루며 생기는 마찰과 이해도 실제로 중요함 - 코딩을 이해하지 못한 채 코딩을 민주화하려는 시도들은 반복적으로 실패해 왔음 - 코드를 이해하려면 코드와 직접 맞물려야 함 - 계속 코드에 관여하고 작성하지 않으면 그 이해와 연결을 잃을 수 있음 - 이해를 잃으면 에이전트를 더 잘 관리하는 능력도 약해지고, AI 코딩 단계는 이상하고 불필요하게 스트레스가 큰 과도기가 됨 ### 더 큰 실험이 될 수 있음 - 현재 흐름은 장기적 영향을 충분히 이해하지 못한 채 스스로에게 실행하는 또 하나의 대규모 실험처럼 보임 - 소셜 미디어 도입 당시에도 장기적 함의를 이해하지 못했고, 이후 광범위한 주의력 결핍 등 여러 문제가 나타남 - 이번에는 더 위험한 것을 걸고 있음 - [fast.ai](https://www.fast.ai/about.html)를 만든 Jeremy Howard는 AI 에이전트에 전부를 거는 사람은 자신의 쓸모없어짐을 보장한다고 말함 - 모든 사고를 컴퓨터에 외주화하면 역량을 높이고 배우고 더 유능해지는 과정을 멈추게 됨 ## Comments ### Comment 56818 - Author: neo - Created: 2026-05-04T16:38:11+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48002442) * 지난 몇 년간 **에이전트형 코딩**으로 일하면서, 35년간 손으로 직접 프로그래밍할 때보다 내가 쓰는 언어·시스템·도구에 대해 더 많이 배웠음 시스템·기법·접근을 결정하는 능력은 여전히 내가 도구보다 훨씬 낫지만, 이 도구들은 잡다한 세부사항을 많이 아는 아주 박식한 인턴 같음. 경험은 적고 실수도 열정적으로 하지만, 적어도 초반에는 피드백을 받아들이며 행동으로 옮김. 다만 완전히 이해하고 내재화한 것이 아니라 자주 잊어버림 작업하는 모든 것을 전부 알아야 한다는 주장은 매우 순진함. 둘 이상 팀에서 일하면 완전히 이해하지 못하는 부분이 많고, 오래된 코드베이스라면 거의 모든 부분이 낯설 수 있음. 수십 년간 쌓인 거대한 단일 저장소에서는 모두가 당신을 전문가로 보는 부분조차 제대로 이해하고 있으면 운이 좋은 편임 이런 주장을 하는 사람들은 대체로 매우 주니어이거나, 거의 혼자 일하거나, 한 프로젝트를 20년 붙잡고 있었던 것처럼 느껴짐. 팀이나 큰 조직에서 일하는 누구도 코드베이스 전체를 안다고 말할 수 없고, 에이전트형 프로그래밍을 하는 사람도 마찬가지임. 그래도 에이전트에게 질문하면 답을 받을 수 있고, 평생 남의 코드를 읽어온 입장에서 LLM이 쓴 코드도 읽을 수 있음. 나쁜 코드를 기계가 썼든 사람이 썼든 전혀 신경 쓰이지 않고, 적어도 기계는 내 피드백을 받아 행동으로 옮김 * 보통 모든 것, 심지어 대부분을 알 필요가 없다는 건 맞지만, 내가 작업하는 프로젝트나 시스템에 대해 필요한 것은 **빠르게 찾아내고 이해할 수 있어야** 함 사소한 문제라도 저수준 언어, 어셈블리, 덜 흔한 알고리즘, 네트워크 프로토콜 같은 추가 기술이 필요해지는 순간 해결하지 못해 멈춰버린 소프트웨어 팀을 많이 봤음 반대로 본 것을 해석할 능력이 없어서가 아니라, 독점 라이브러리나 독점 운영체제처럼 **블랙박스**인 것을 써서 내부를 파고들 수 없고 실제 동작을 확인할 방법이 없어 막히기도 함 그래서 아주 드물게만 필요하더라도, 작업하는 모든 것에 대해 전부 알아낼 수 있는 환경은 항상 가능해야 한다고 봄 * 35년 경력이 있으니 새 지식을 얻는 **학습 능력과 일반적인 틀**이 이미 쌓여 있고, 에이전트형 코딩을 보조 도구로 쓰는 법도 알고 있음. 오늘 시작하는 주니어들은 그게 없어서 에이전트형 코딩에 과하게 의존하고, 자신이 모르는 게 뭔지도 모름 * 이 글은 “작업하는 모든 것을 전부 알아야 한다”고 말하는 게 아니라, **코드를 쓰는 능력과 코드를 효과적으로 읽는 능력**이 본질적으로 연결돼 있다고 말하는 것임 * 동의함. 모래가 트랜지스터가 되는 과정이나 어셈블리를 몰라도 잘 일하고 있으니, 나도 전체 스택을 전부 아는 건 아님 중요한 건 시스템의 나머지를 배우는 걸 두려워하지 않고, **색인**을 유지하는 것임 무엇보다 어떤 것이든 빠르게 파악할 수 있어야 함. 그래야 넓게 다룰 수 있음. 필요할 때는 깊이 파고들고, 필요할 때는 높은 수준에서 훑어보는 식으로 문제에 맞는 적절한 수준을 잡아야 함 오래전 대학에서는 컴퓨터과학 전공자에게 공학 전반을 가르쳤음. “화학공학이나 아날로그 제어 시스템을 언제 알아야 하죠?”라고 묻자, “쓸 일은 없을 것이다. 다만 코딩할 만큼 빠르게 파악하고 나중에 잊으면 된다. 우리는 튼튼한 기반을 주는 것이다”라고 답했음 이건 큰 코드베이스 안에서도 그대로 적용됨 * 여기서 문제는, 어떤 의미에서는 코드를 쓴 에이전트와 그 코드에 대한 질문에 답하는 에이전트가 **같은 에이전트가 아니라는 것**임. 원래 에이전트가 추론 과정을 남기지 않았다면 대체로 막막해짐 git-ai [0] 같은 도구는 LLM 세션을 캡처하고 각 파일 편집을 특정 에이전트 동작과 연결하며, 에이전트가 특정 코드 조각에 대해 그 주변 대화, 즉 사용자가 무엇을 프롬프트했는지, 그 코드를 만든 LLM의 추론이 무엇이었는지 등을 조회하게 해줌. 균형을 바꿀 수 있지만 아직 널리 쓰이지는 않음 [0] [https://usegitai.com/]() * 25년 이상 된 시니어 개발자로서 최근 “5분만 들어와 줄 수 있나요”라는 식으로 회의에 던져졌는데, 중간에 아무 맥락 없이 끌려 들어가는 이런 회의를 정말 싫어함 질문이 소개도 없이 빠르게 쏟아졌고, 수십 개 중 하나인 외부 연동에 관한 내용이었음. 더 나쁘게도 그쪽은 우리와 다른 자체 용어를 씀 이 연동들을 만들 때 모델에 크게 의존했기 때문에 질문을 이해하는 데 **매우 힘들었음**. 극도로 지루한 작업이었고, 외부의 두꺼운 명세가 제공된 상태였음 모델을 쓰지 않았다면 10배 시간을 들여도 이런 연동은 아마 완성되지 못했을 거라는 생각은 여전히 긍정적임. 하지만 이제는 이런 불편한 순간이 다시 생기지 않도록 “아하” 포인트들을 다시 문서화할지 신중히 생각하고 있음 회의에서 이렇게 무지하고 창피하다고 느낀 적이 없었고, 할 수 있는 말은 “그건 확인해서 답하겠습니다, 이것도요, 저것도요”뿐이었음 **인지 부채**는 정말 현실이고, 개인적으로는 기술 부채보다 더 아픔. 기술 부채는 팀 전체가 공유하지만 인지 부채는 개인적이며, 그걸 만든 사람이 바로 나였다면 더 잘 알고 있어야 함 앞으로는 “이건 무엇인가”, “저건 무엇인가” 식의 5분짜리 플래시카드형 Markdown 용어 목록을 만들지 않으면 일이 끝난 게 아니라고 볼 것임 * 이건 의사들이 흔히 불평하는 상황과 비슷함. 환자가 와서 어떤 약 처방만 필요하다고 하지만, 좋은 의사들은 전체 상황을 제대로 이해하기 전에는 약도 조언도 주지 않는 경우가 많음 시니어 개발자라면 마음에 들지 않는 행동에 **제동을 걸어야 하는 사람**임. 권한이 있음. “흥미로운 질문이네요. 제 관점을 말하려면 맥락이 더 필요합니다. 시스템 아키텍처를 간단히 설명해 주시거나, 이 접근으로 실제 어떤 문제를 풀려는지 설명해 주실 수 있나요?”라고 하면 됨 * 어떤 직장이어야 회의 중간에 끌려 들어가 맥락도 없이 기술 질문을 쏟아붓고, 그 자리에서 답하기를 기대하는지 궁금함. 많은 사람이 피하고 싶어 할 테니 알려주면 좋겠음 그런 대우를 받았을 때 “이 질문에 제대로 답하려면 문서와 코드를 검토해야 합니다”는 완전히 괜찮고, 꽤 외교적인 답변임 * 자존심 내려놓고 신경 쓰지 않아도 됨. 도구를 썼고, 쓰지 않았다면 더 곤란했을 것임. “모르겠네요, **AI에 물어보겠습니다**”라고 하면 간단함 * 2014년의 7분짜리 “The Expert” 스케치가 떠오름: [https://www.youtube.com/watch?v=BKorP55Aqvg]() 전문성이 쌓아 올릴 대상으로 보이는 게 아니라 그저 창의적인 **확증 편향**을 확인하는 용도로 쓰이는 회의는 즐겁지 않음 * 쉬움. 마지막에 에이전트가 그 목록을 쓰게 하면 됨. 그리고 절대 읽지 않으면 됨 * 생성된 코드에서 문제를 찾으려면 개발자가 신경을 써야 함. 많은 개발자들, 특히 대기업 개발자들은 이미 일에서 상당히 빠져 있고, 가능한 최소 노력으로 티켓을 닫고 책임을 넘길 방법만 찾고 있음 그런 개발자들은 능력이 있더라도 에이전트가 놓친 문제를 찾을 만큼 생성된 코드를 이해하려고 노력하지 않을 것임. 특히 지금 같은 **AI 주도 속도 열풍** 속에서는 더 그렇다 * 맞음. 생성된 코드는 인간 작성자의 정신 모델에 기대는 모든 **의미적 기대**를 어기기 때문에 읽기가 더 어려움 생성된 코드는 언어적으로는 그럴듯하지만, 흔한 관용구를 자신도 모르게 incoherent하게 흉내 내는 경우가 많아서 실제 버그가 정상적인 인간, 심지어 나쁜 프로그래머도 떠올리기 힘든 방식으로 우연히 숨겨질 수 있음 LLM에는 내부 평가가 없으므로 리뷰어는 이를 감안해 줄 단위로 평가하고, LLM이 애초에 갖고 있지 않았던 숨은 근거와 암묵지를 처음부터 다시 세워야 함. 그러다 비문제에 끌려가 값비싼 시간을 소모하기도 함 이 시점에서는 처음부터 작성하는 것보다 투자가 더 커지는 경우가 많음 * 큰 회사에서는 예외도 있지만, 많은 팀의 많은 개발자들이 **신경 쓰는 것 자체로 처벌**받기도 함 * 어떤 사람들은 큰형님이 정크푸드를 팔고, 그다음 살 빼는 “해결책”을 판다고 말함 어쩌면 지금 회사들은 **정크 AI**를 사고 있고, 다음 단계에서는 그 “해결책”을 약속받는 중일지도 모름. 자본주의는 정확히 예상대로 작동하고 있음 * 이 글은 조금 핵심을 비껴간 것 같음 AI를 많이 쓰면 **기술 손실**은 있음 하지만 방 안의 어색한 코끼리를 인정하고 싶음. AI는 사람들을 너무 빠르게 만들고 있음. 빠른 산출 자체가 나쁘다는 뜻이 아니라, 코드를 만들어낸 전체 이해와 경험보다 빠른 산출물과 코드가 앞서고 있다는 뜻임. 깊은 지식으로 안전한 결정을 하며 만드는 사람보다, 사업 가치를 말하려는 사람에게 보상을 주고 있음 AI는 좋고 좋은 해결책도 만들 수 있지만, 궁극적으로 자신이 뭘 하는지 모르며 최선의 경우에도 강한 조율자가 필요함 우리는 **사업 주도 개발**의 오물탕에 있고, 나쁜 결정에 대해 충분히 가혹한 평판상 처벌이 돌아가지 않고 있음 * 기술 손실은 현실임. 하지만 나는 말 그대로 10년 동안 상사들에게 기술 손실을 불평해 왔음. 그래서 AI는 내게 문제 중 하나일 뿐임. 어떤 이유에서인지 매년 코딩을 점점 덜 하게 됐음 다시 말해 기술 손실이 그렇게 큰 문제인지 확신하지 못하겠음. 그냥 우리 일의 성격이 바뀌고 있다는 신호일 수도 있음. C++ 표준을 줄줄 외우고 수백 가지 기능을 올바르게 쓰는 능력보다 **좋은 아키텍처**를 아는 능력이 더 높게 평가되는 시대가 될지도 모름 * 전반적으로 동의하지만, 냉혹한 진실은 대부분의 기업 우선순위가 늘 대략적이고 허술한 **사업 주도 개발**이었다는 것임. 인간 중심의 엔지니어링 과정은 그 철학의 최악의 결과를 우연히 막아준 견제 장치였지, 의도적으로 마련된 장치가 아니었음 * “너무 빠르다”는 것의 또 다른 측면은 우리 문제들의 순서를 바꾼다는 점임 일반적인 개발에서는 “정말 이걸 만들고 싶은가”, “이렇게 하면 뭐가 잘못될 수 있는가”를 더 오가며 따지는 편이고, 이상적으로는 PR 승인이나 병합·배포 전에 함. 그 일부가 “나중에 누가 불평하는지 보자”로 옮겨가고 있음. 말하듯이 **예방 1온스가 치료 1파운드보다 낫다**는 것임 * 사업 주도 정부가 사업 주도 규칙을 쓰는 사업 주도 세계에서, 성공을 최적화하고 싶다면 대안이 무엇인지 모르겠음 * 기업만 그러는 것도 아님. 오픈소스 프로젝트에서도 겉보기에는 괜찮지만 자잘한 버그가 천 개쯤 들어 있는 큰 PR이 병합되는 걸 자주 봄. 치명적이지는 않아도 충분히 짜증나는 것들임 게다가 그 코드는 해당 프로젝트의 관용적인 C++가 아니었고, LLM은 이미 있는 API를 완전히 무시했음. 고칠 수는 있고 메인테이너가 잡았어야 하지만, 생성되는 코드의 양 때문에 모두가 너무 많은 에너지를 써야 함 * 이런 블로그 글들은 의심할 여지 없이 AI 도움을 받아 쓰였을 텐데, 여기와 인터넷 곳곳에서 수년째 댓글 주제가 되어 왔음. **기술 위축**은 심각한 우려이고, 2022년부터 AI에 회의적인 모두가 반복해서 말해왔지만, 어떤 사람들과 어떤 곳은 그냥 신경 쓰지 않는 것 같음 어느 시점부터 코드에 대한 통찰 없이 **쓰레기 기계** 레버만 당기고 있다면, 상사가 왜 연봉 5만 달러 이상을 받아야 하느냐고 묻는 것도 정당할 수 있음 * 더 빠르게 가려고 AI를 쓰는 건 **잘못된 것을 최적화**하는 것임. 내가 일한 모든 곳에서 기능을 구현하는 데 필요한 다른 모든 일에 비해 “코드 작성” 자체가 가장 적은 시간을 차지했음 하루면 코딩할 수 있는 기능을 보자. 먼저 회사가 쓰는 Agile이든 Waterfall이든 계획 의식을 통해 모든 걸 계획하고, 작업을 쪼개고, JIRA 티켓을 만들고, 누가 할지 정해야 함. 이것만 며칠 또는 몇 주가 걸릴 수 있음. 그다음 제안 설계를 담은 설계 문서를 쓰고 동료·팀원 리뷰를 받아야 하며, 실질적인 기능이라면 또 한 주가 걸림. 여러 팀이 관련되면 그 팀들의 동의와 설계 합의를 받아야 하니 한 주를 더하자. 어떤 곳에서는 작업 시작 승인이 필요하고, 승인자의 일정과 가용성에 따라 며칠이 더 걸림 그런 다음 하루 동안 코드를 쓰고 테스트를 통과시킴 그다음 코드 리뷰가 있고, 팀과 많은 왕복을 하며 여러 번 반복하고 추가 리뷰를 받을 수 있음. 또 며칠 또는 몇 주가 감. 더 큰 회사라면 법무, 개인정보, 성능, 접근성, QA 같은 다른 부서의 온갖 리뷰를 통과해야 함. 병렬로 하더라도 보수적으로 2주를 더하자. 마지막으로 스테이징에 올리고 내부 도그푸더 사이에서 어느 정도 숙성 시간을 가져야 작동에 자신이 생김. 1주 추가. 이제 스테이징에서 프로덕션으로 올릴 준비가 됐지만, 진지한 회사라면 아무것도 바로 100% 프로덕션에 보내지 않음. 천천히 비율을 올리고, 롤백이 필요할 경우를 대비해 피드백과 지표를 확인해야 함. 전체 출시까지 또 2주가 걸릴 수 있음 그러면 설계부터 출시까지 두 달쯤 걸린 기능에서, 우리는 하루 걸린 부분을 5분으로 줄이려고 난리 치는 셈임 * 이 소프트웨어 엔지니어링 격언이 떠오름 소프트웨어를 만들 때, 그것이 문제에 대한 **이해의 스냅샷**임을 기억해야 함. 그것은 모두에게, 미래의 자신에게도, 접근 방식과 명료함, 그리고 당면한 문제에 대한 해법의 적절성을 말해줌. 그러니 무엇을 말할지 현명하게 선택해야 함 설계부터 출시까지 두 달 걸린 기능에서 하루짜리 부분을 5분으로 줄이려 애쓴다는 표현은 잘 짚었음 * 모델은 이제 의존성 업데이트, 빌드·배포 스크립트, 단위 테스트 같은 지루한 작업을 거의 완전히 자동화하는 데 매우 뛰어남. 예전에는 며칠 걸리던 일이 이제 몇 분 걸릴 수 있고, 여기서는 쉽게 **50배 속도 향상**이 가능함 이런 일은 안정된 회사에서 모든 엔지니어의 일상 중 작지 않은 부분이었음. “플랫폼 엔지니어링”이든 뭐라 부르든 이 영역은 죽었음 또 위험과 노력 대비 보상이 맞지 않아 시도하지 않았을 기술적으로 위험한 아이디어들이 이제 손에 닿음. 단순히 “더 빨리 가기”라기보다, 무언가를 시험해 볼 수 있는 속도가 엔지니어링 과정의 성격 자체를 바꿈 * 설명한 모든 프로세스는 소프트웨어 엔지니어가 **코드를 쓰는 시간**을 극대화하기 위해 존재함[0]. 기업에서 소프트웨어 엔지니어는 가장 비싼 직원들 중 하나이고, 그들의 시간이 낭비되는 것은 손익에 의미가 있기 때문에 이런 프로세스를 둠 소프트웨어 엔지니어가 충분히 싸지면 이런 프로세스의 많은 필요성이 사라짐. 이미 이런 프로세스를 가진 회사들은 그런 관료제를 깨기가 극도로 어렵기 때문에 곤란하겠지만, 애초에 그런 프로세스가 없거나 제거할 수 있는 회사들은 상당한 경쟁 우위를 갖게 됨 새 소식은 아님. 스타트업은 항상 실행 속도로 기존 기업과 경쟁해 왔음. 새로워진 건 그 속도를 더 오래 유지할 수 있는 능력임 법무, 개인정보, 성능, 접근성, QA 같은 리뷰도 모두 표적 안에 있음. 회사가 이런 리뷰에 따른 법적 책임을 외부 제공자에게 넘길 수 있다면 그렇게 할 것임 [0] 이 프로세스의 상당 부분이 결국 시간을 아끼려던 바로 그 직원들에게 떠넘겨진다는 아이러니는 일단 무시하자 * 어떤 회사에서 일하느냐에 아주 많이 달려 있음. 예를 들어 스타트업을 이런 식으로 운영할 수는 없음 * 모든 회사가 그렇게 일하지는 않음 빅테크에는 그런 허세 섞인 절차가 많지만, 작은 회사들은 빠르고 거칠게 움직일 수 있음 * 코드 품질은 결국 당신에게 달려 있음 에이전트와 반복해서 작업해, 자신이 직접 썼을 때와 **똑같은 품질**의 코드가 될 때까지 다듬는 걸 막는 건 없음 * 내 기준의 코드 품질을 목표로 한다면, 그냥 내가 직접 쓰는 편이 더 빠르고 덜 답답했음 * 나는 내 코드 품질을 원하는 게 아니라 **AGI 코드 품질**을 원함. 그렇게 약속받았고, 제트팩과 하늘을 나는 자동차도 약속받았음 * 그래서 이런 글들이 이해되지 않고, 인간 게으름에 대한 사례 연구처럼 느껴짐. 좋은 결과를 원한다면 결과를 리뷰하고 반복하면 됨. 좋은 기반을 원한다면 그 기반을 직접 쓰면 되고, 나중에는 그 기반이 LLM이 나쁜 코드를 쓰는 것을 상당히 크게 막아줌 이런 글들은 꽤 답답함. 다만 작성자가 말한 **토큰 비용**은 현실이고 위험임 * 막는 건 없지만, 애초에 직접 쓰는 것보다 느림. AI 생산성 향상은 신화임 * 내 경험상 거기까지 AI를 달래가며 끌고 가는 데 같은 시간이나 더 긴 시간이 걸림. 특히 더 빠르다는 증거도 없다면, LLM을 중간자에 끼워 넣기보다 직접 쓰고 어떻게 동작하는지 아는 편이 낫다 * AI 도구는 접근법을 브레인스토밍하고 가끔 코드를 생성하는 데 쓰지만, 실제 타이핑은 내가 직접 함. 그러면 시간이 지나며 **메커니즘과 프로그래밍 언어**를 잊을 가능성이 줄어듦 * 나도 대부분은 구현 계획을 요청하되, 코드는 최소화하거나 아예 코드 없이, 또는 의사코드로 달라고 하고 실제 코드는 직접 작성함. 오픈소스 작업에서는 내가 즐기는 핵심이 직접 코드를 쓰는 것이기 때문임 솔직히 전체가 LLM에게 코드를 쓰게 프롬프트하고 리뷰하는 일뿐이라면 오픈소스 메인테이너를 굳이 할 것 같지 않음. 전혀 충족감이 없어 보임 실제 유급 직업이라면 LLM 사용 방식이 어떻게 달라질지는 궁금함. 내가 소프트웨어 개발자인 이유는 이 기술 자체를 사랑하기 때문임. 만드는 행위, 뇌를 써서 아이디어를 코드로 바꾸는 행위를 좋아함. 그냥 LLM에 프롬프트하는 일이라면 그 직업을 계속할지 모르겠음. 적어도 전직을 알아보기 시작할 것 같음 * 쓸 수 있는 접근 중 하나는 절대 코드를 대신 쓰지 말라고 요청하는 것임. 그러면 설명을 강제하게 되고, 이후 직접 코딩해 그 아이디어를 시도하면서 더 잘 이해하게 됨 유지보수해야 하는 코드에서는 이 방식을 씀. 그래도 모델이 틀린 정보를 많이 섞기 때문에 가끔 당함. 보통 과거에는 맞았지만 지금은 틀린 내용임 버려도 되는 스크립트나 검증이 쉬운 스크립트는 생성하게 하지만, 과도한 설계나 모든 경계 사례를 잡으려는 시도는 피하라고 요청함. 스크립트에서는 실패한 단계가 그대로 드러나도록 오류가 나게 두는 편이 더 이해하기 좋기 때문임 PowerShell처럼 읽기 어렵다고 느끼는 언어는 피하고, 화면 안에 들어올 만큼 짧아서 전부 읽고 이해할 수 있는 것을 생성하는 편을 선호함. Python, Bash, Batch가 내가 주로 쓰는 스크립트 언어임 * 나도 시스템 프롬프트에 전체 해법이나 코드를 절대 주지 말라고 설정해 뒀음. 그래서 질문하면 짧은 10줄 예제나 의사코드 정도를 내놓음. 이쪽이 훨씬 추론하기 쉬움 AI 제안의 **50% 이상**은 여전히 거절함. 너무 평범하거나, 이유 없이 코드를 옮기거나, 때로는 그냥 틀리기 때문임 * AI가 잊어버린 건 무엇이든 다시 알려줄 수 있다면, 잊는 게 왜 중요하겠음 * 웃긴 점은 이 기술이 둘 중 하나라는 것임 전문성 없이 위임은 할 수 있지만 틀렸거나 아예 불가능한지 알 수 없는 **관리자용 기술**이거나, 전문성은 있지만 그 전문성을 점점 잃게 될 **코더용 기술**임 그래서 다음 분기까지의 VC와 주주 말고는 누구를 위한 건지 잘 모르겠음 * 약간 주제에서 벗어나지만, 글에서 Spec Driven Development가 미래라고 말하는 게 웃김 기술적으로는 우리가 Waterfall을 하던 시절 이미 그렇게 했음. 좋은 문서가 있던 시절이 조금 그립기도 함. 지난 10년, 어쩌면 그 이상 동안은 한 줄짜리 JIRA 티켓을 받는 일이 많았고, 거의 아무것도 명시하지 않아서 사람들에게 전화해야 하는 경우가 잦았음 나는 아직 AI로 일하는 걸 피하고 있음. 실험용으로 로컬 모델 몇 개를 써보려 하지만, 남의 것을 뜯어다 만든 것에 돈을 내기는 거부함. 그리고 지금까지 **로컬 모델**은 기대 이하였음 * 원격 모델들은 점점 더 비싸질 것임. 그들의 사업 미래는 추론 비용 개선에 대한 기대에 달려 있음. 이런 감옥에 스스로 묶이고 싶어 해서는 안 됨