# Ask HN: 에이전틱 코딩이 실제로 효과가 있나요? > Clean Markdown view of GeekNews topic #26020. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26020](https://news.hada.io/topic?id=26020) - GeekNews Markdown: [https://news.hada.io/topic/26020.md](https://news.hada.io/topic/26020.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-22T02:33:43+09:00 - Updated: 2026-01-22T02:33:43+09:00 - Original source: [news.ycombinator.com](https://news.ycombinator.com/item?id=46691243) - Points: 6 - Comments: 1 ## Summary 에이전틱 코딩이 실제 개발 생산성을 높이는지에 대한 회의가 커지고 있습니다. 일부 개발자들은 **Codex 같은 AI 도구가 구조적으로 견고한 코드를 만들기보다, 시간이 지날수록 디버깅이 어려운 오류를 누적시킨다**고 지적합니다. 테스트 통과만으로 배포를 결정하는 최근 흐름도 코드 품질 관리의 공백을 낳고 있으며, 자동화된 생성 코드에 대한 **‘동작 검증’ 중심 문화의 지속 가능성**이 논의의 핵심으로 떠오르고 있습니다. ## Topic Body - 에이전트 코딩을 시도해 봤지만, **온라인에서 본 내용과 제가 실제로 구현하는 결과 사이의 괴리** 때문에 머리가 아픈데, 실제로 긍정적인 결과를 가져온다는 증거가 있을까요? - 과장된 홍보를 넘어, 에이전트 코딩을 **성공적으로 구현**해 보신 분이 있다면 어떻게 하셨는지 자세히 공유해 주세요 - **"성공적으로 구현한다"** 는 것은 다음과 같은 의미 * 기술 부채보다 더 많은 가치를 창출 * 아키텍처 책임자가 승인할 수 있을 만큼 **구조적으로 견고한 코드를 작성**하는 것 - 최근에는 "아키텍처 검증"에서 "동작 검증"으로 전환해야 한다는 주장과 함께 **코드 리뷰를 최소화하거나 아예 없애는 추세**가 보임 - 실제로 이는 코드를 보지 않고 **테스트와 CI를 통과하면 배포한다는 의미**인 것 같은데, 이런 방식이 **장기적으로 지속될 수 있을지 의문** * 내 생각에는 Codex를 사용하면 정상적인 경로에서는 작동하지만 **시간이 지남에 따라 미묘하고 디버깅하기 어려운 오류가 누적**되는 "스파게티 코드"가 될 가능성이 높음 * 기존 코드베이스에 Codex를 적용해 봤을 때, 가이드라인을 설정했든 안 했든, **내 시간의 절반은 Codex가 만들어낸 미묘한 오류나 중복 코드를 수정하는 데 사용**함 - 지난 주말에는 반려동물 사료 알림 iOS 앱을 처음부터 다시 만들어 봤는데 - Codex에게 SwiftUI 기반의 아키텍처 청사진을 먼저 조사하고 제안해 달라고 요청하고, 구현해야 할 내용과 방법을 설명하는 명세를 Codex와 함께 작성 - 첫 번째 구현은 버그가 몇 개 있었지만 예상외로 괜찮았지만, 그 후로는 **상황이 급격히 악화** - 남은 주말 동안 **Codex가 제대로 작동하도록 하고, 새로운 버그를 만들지 않고 버그를 수정하고, 임의로 코드를 작성하는 대신 모범 사례를 연구**하도록 함 - 새로운 가이드라인과 가이드라인을 발견할 때마다 Codex에 기록하도록 했지만, 상황은 나아지지 않았고, 결국 포기 - 개인적으로 **검토되지 않은 코드를 배포하는 것은 용납할 수 없음** - 뭔가 잘못된 것 같음. **제품은 제대로 작동해야 하지만, 코드의 품질 또한 높아야 해요** ## Comments ### Comment 49650 - Author: neo - Created: 2026-01-22T02:33:43+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46691243) - LLM이 **비용 절감**의 열쇠로 여겨지면서 막대한 자금이 걸려 있음 유명 인플루언서나 전문가들도 ‘최첨단’ 이미지를 유지하려고 과장된 발언을 하곤 함 하지만 실제로는 아직 **LLM 기반 개발의 최적 접근법**이 정립되지 않았음 지금은 신앙처럼 믿기보단 내부 동작을 직접 살펴보는 게 중요하다고 생각함 - 나도 최근 어떤 회사에서 새 “agentic coding platform”을 홍보해달라며 **200달러 제안**을 받았음 이런 제안이 무작위 사용자에게까지 오간다는 건, 이미 상당한 **마케팅 캠페인**이 진행 중이라는 뜻임 - LLM은 분명 **도약적인 도구**이지만, 완전한 자율 개발의 **만능열쇠는 아님** 단순한 CRUD 작업에는 즐겁지만, 복잡한 프로젝트에서는 오히려 좌절감을 줌 지금은 벤치마크 경쟁과 VC 자금이 몰려 **냉정한 논의가 어려운 시기**임 - GUI가 처음 등장했을 때처럼, 지금은 **직관적 가치**를 느끼는 단계라고 생각함 아직 정량적 증거는 부족하지만, 개발자가 완전히 사라질 일은 없더라도 **개발 방식이 영원히 바뀌었음** - Google의 한 **Principal Engineer**가 “Claude Code가 1년 걸린 일을 1시간 만에 했다”고 트윗했음 하지만 나중에 밝혀진 바로는, AI가 만든 건 단순한 **‘토이 버전’** 이었음 이런 과장된 발언이 **기대치를 왜곡**하고 실망을 초래함 [관련 트윗 링크](https://xcancel.com/rakyll/status/2007659740126761033#m) - 이런 트윗은 종종 **AI 리더십 실적**을 보여주기 위한 내부 압박 때문임 - 어떤 사람은 “그런 말을 하다니 말도 안 된다”고 반응했음 - 또 다른 사람은 “AI 성과는 **경험 수준과 투자 비용**에 따라 달라진다”고 지적함 - “AI는 여전히 **배포할 수 없는 코드**만 내놓는다”며 냉소적인 반응도 있었음 - “이런 일이 Google을 잘 보여준다”고 꼬집은 사람도 있었음 - 지난 6개월간의 회고로 보면, **인프라 코드(예: Terraform)** 에서는 10배 효율을 얻었음 하지만 **전문 기능 개발**은 여전히 들쭉날쭉함 그래도 반복 작업을 줄여 생긴 시간으로 **테스트·보안 품질**을 높일 수 있었음 무엇보다 다시 **코딩의 즐거움**을 느끼게 되었음 - 나도 35년째 취미 개발을 하는데, AI가 **지루한 타이핑을 덜어주고 창의성**을 살려줌 - 나 역시 **빌드 스크립트나 CI 작업**에서는 2배 이상 빨라졌지만, 복잡한 HPC 프로젝트는 여전히 어렵고 **보조 코딩(assisted coding)** 방식이 가장 효율적이었음 [프로젝트 링크](https://github.com/finos/opengris-scaler) - 집의 NAS 파일 검색기를 Claude로 만들었는데, **매일 자동 색인**하는 Go 백엔드와 웹 UI를 하루 만에 완성했음 이런 개인 프로젝트가 진짜 **게임 체인저**라고 생각함 - 작업을 **작게 쪼개면** 에이전트가 훨씬 잘 작동함 - 다만 **테스트 코드 품질**은 여전히 낮음. 학습 데이터 자체가 테스트 작성에 약하기 때문임 - 나는 **기존 앱에 에이전트를 붙이는 방식**으로 큰 성공을 거둠 에이전트는 **아키텍처 설계에는 약하지만**, 이미 구조화된 코드에서는 매우 잘 작동함 타입 시스템이 엄격하고 테스트 커버리지가 넓을수록 효과가 큼 - 현재는 Rust 프로젝트를 **LLM이 직접 관리·개발**하도록 실험 중임 Claude가 작성한 ROADMAP.md, TASKS.md, STATUS.md를 기준으로 진행 중이며 놀랍게도 **20% 정도 완성**된 상태임 - C#은 **엄격한 컴파일러와 규칙 기반 환경** 덕분에 에이전트와 궁합이 좋음 반면 Python이나 JS는 **약한 타입 시스템** 때문에 신뢰하기 어려움 - 기존 코드베이스가 **정돈되어 있을수록** 에이전트 성능이 높음 처음부터 만드는 건 어렵지만, **명확한 스펙**을 주면 효율이 높음 - Go는 **언어가 단순하고 일관된 패턴** 덕분에 LLM이 다루기 쉬움 - Typescript는 **빠른 컴파일과 강한 타입 시스템** 덕분에 에이전트용으로 이상적임 반면 Python의 선택적 타입은 오히려 **오류 전파**를 유발함 - 나는 Linux용 **실시간 블루투스 심박수 모니터**를 Claude Code로 100% 작성했음 [프로젝트 링크](https://github.com/lowrescoder/BlueHeart) 순수 C로 작성했고, 웹 인터페이스와 실시간 그래프까지 하루 만에 완성했음 이전엔 실패했던 **dBus–blueZ 통신**을 이번엔 성공적으로 구현했음 - 하지만 다른 사용자가 코드를 검토해보니, **SSE 구현이 실제로는 작동하지 않음** 문서에는 SSE라 되어 있지만 내부적으로는 일반 HTTP 응답만 반환함 - 또 다른 사람은 “AI가 쓴 코드가 처음엔 좋아 보여도 **점점 품질이 떨어진다**”고 지적함 - “이런 실제 예시를 공유해줘서 고맙다”며 **과장 없는 사례**로 평가한 사람도 있었음 - UI 스타일이 흥미롭다며 디자인에 대해 묻는 댓글도 있었음 - 나는 매일 **Augment + Claude Opus 4.5**를 사용함 직접 코드를 거의 쓰지 않고, **명세 기반 반복 작업**으로 프로젝트를 완성함 병렬로 여러 에이전트를 돌리며 리뷰하는 방식이 특히 효율적임 명확한 스펙 작성과 단계별 피드백이 핵심임 - Ruby를 잘 모르지만 Rails 앱 개발에 큰 도움을 받음 30년 경력 중 가장 **혁명적인 변화**라고 느끼며, 산업 전반이 바뀔 것이라 확신함 - 어떤 사람은 “1주짜리 프로젝트를 중간 규모라 부르다니 작다”고 농담했음 - 또 다른 사람은 “이건 진짜 **에이전트 개발**이라기보다 LLM 협업 개발에 가깝다”고 평함 - “**스펙 중심 개발(spec-driven)** 이 생산품질의 핵심”이라는 의견도 있었음 - 나는 Claude가 먼저 질문을 던지게 해서 **요구사항을 명확히 정리**하는 단계를 추가함 현재는 Claude로 일본어–영어 사전 프로젝트를 진행 중임 [GitHub 링크](https://github.com/tkgally/je-dict-1), [웹사이트](https://www.tkgje.jp/) - 20년 경력의 개발자로서, LLM 덕분에 **작업 속도 예측이 완전히 빗나감** 예전엔 2주 걸릴 일도 이제 2일이면 끝남 코드 리뷰와 상호작용은 필요하지만, **대부분의 인간 개발자보다 낫다**고 느낌 LLM과의 대화는 **시니어 개발자와 협업하는 느낌**에 가깝고, 내가 오랫동안 **코드 리뷰와 업무 분배**를 해온 경험이 큰 도움이 됨 - 어떤 사람은 “그 정도 속도 향상은 믿기 어렵다”며 **문제 유형**을 궁금해했음 - 또 다른 사람은 “증거를 기대했는데 없었다”고 짧게 언급함 - 내가 써본 방법 중 가장 안정적인 건, **작고 명확한 작업 단위**로 Claude에게 맡기는 것임 계획을 세우고, 검토하고, 구현 후 리뷰하는 식으로 반복함 완벽하진 않지만 **막힌 부분을 뚫는 데** 매우 유용함 다만 가이드라인은 잘 지키지 못하므로, **직접 검증과 정리**가 필수임 - 나도 **러버덕 디버깅**과 비슷하게 Claude를 사용함. 한 번에 한 함수씩 맡기고, 결과를 참고해 더 나은 아이디어를 얻음 - 문서화나 분석 작업에서 LLM이 특히 강력함 하지만 **디자인 중심 문제**로 가면 한계가 뚜렷함 - “가이드라인은 어디에 두냐”는 질문엔, **CLAUDE.md에 빌드·테스트 정보**를 넣는 게 좋다고 조언함 - AI 보조 코딩을 오해하는 사람이 많음 AI는 **팀원**이 아니라 **도우미**임 버그나 오작동을 실패로 보는 게 아니라, **숙련된 개발자가 그 혼란을 정리해내는 과정**이 핵심임 - 어떤 사람은 “그렇게 손이 많이 가면 IDE 자동완성과 뭐가 다르냐”고 물음 - 또 다른 사람은 “최신 기법이 실제로 **품질 향상**을 입증한 사례가 있냐”고 질문함 - “결국 ‘너가 잘못 쓰고 있는 거야’라는 말로 들린다”고 비꼰 사람도 있었음 - “야구 보면서 완벽한 앱을 만들어주길 기대했다면, 그건 **AI가 아니라 마법사**를 산 거다”는 농담도 있었음 - 나도 매일 Claude를 쓰지만, **AI가 만든 테스트 코드**는 종종 엉망임 실제로는 `expect(true).to.be(true)` 같은 **무의미한 테스트**를 양산함 - 예전 모델은 실패했지만, 최신 모델은 **속임수로 통과하는 코드**를 만든다는 글을 본 적 있음 - 그래서 나는 **TDD 방식**으로 테스트를 먼저 작성하고 검토함 구현과 테스트를 동시에 맡기면 **자기 채점식 오류**가 생김 - 어떤 사람은 “Claude로 테스트를 쓰는 건 포기했다”고 말함 - “이건 너무 인간적인 해결책”이라며 웃은 사람도 있었음