▲

Ask HN: 에이전틱 코딩이 실제로 효과가 있나요?

 (news.ycombinator.com)
6P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 에이전트 코딩을 시도해 봤지만, 온라인에서 본 내용과 제가 실제로 구현하는 결과 사이의 괴리 때문에 머리가 아픈데, 실제로 긍정적인 결과를 가져온다는 증거가 있을까요?
  • 과장된 홍보를 넘어, 에이전트 코딩을 성공적으로 구현해 보신 분이 있다면 어떻게 하셨는지 자세히 공유해 주세요
  • "성공적으로 구현한다" 는 것은 다음과 같은 의미
    • 기술 부채보다 더 많은 가치를 창출
    • 아키텍처 책임자가 승인할 수 있을 만큼 구조적으로 견고한 코드를 작성하는 것
  • 최근에는 "아키텍처 검증"에서 "동작 검증"으로 전환해야 한다는 주장과 함께 코드 리뷰를 최소화하거나 아예 없애는 추세가 보임
  • 실제로 이는 코드를 보지 않고 테스트와 CI를 통과하면 배포한다는 의미인 것 같은데, 이런 방식이 장기적으로 지속될 수 있을지 의문
  • 내 생각에는 Codex를 사용하면 정상적인 경로에서는 작동하지만 시간이 지남에 따라 미묘하고 디버깅하기 어려운 오류가 누적되는 "스파게티 코드"가 될 가능성이 높음
  • 기존 코드베이스에 Codex를 적용해 봤을 때, 가이드라인을 설정했든 안 했든, 내 시간의 절반은 Codex가 만들어낸 미묘한 오류나 중복 코드를 수정하는 데 사용함
  • 지난 주말에는 반려동물 사료 알림 iOS 앱을 처음부터 다시 만들어 봤는데
    • Codex에게 SwiftUI 기반의 아키텍처 청사진을 먼저 조사하고 제안해 달라고 요청하고, 구현해야 할 내용과 방법을 설명하는 명세를 Codex와 함께 작성
    • 첫 번째 구현은 버그가 몇 개 있었지만 예상외로 괜찮았지만, 그 후로는 상황이 급격히 악화
    • 남은 주말 동안 Codex가 제대로 작동하도록 하고, 새로운 버그를 만들지 않고 버그를 수정하고, 임의로 코드를 작성하는 대신 모범 사례를 연구하도록 함
    • 새로운 가이드라인과 가이드라인을 발견할 때마다 Codex에 기록하도록 했지만, 상황은 나아지지 않았고, 결국 포기
  • 개인적으로 검토되지 않은 코드를 배포하는 것은 용납할 수 없음
  • 뭔가 잘못된 것 같음. 제품은 제대로 작동해야 하지만, 코드의 품질 또한 높아야 해요
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • LLM이 비용 절감의 열쇠로 여겨지면서 막대한 자금이 걸려 있음
    유명 인플루언서나 전문가들도 ‘최첨단’ 이미지를 유지하려고 과장된 발언을 하곤 함
    하지만 실제로는 아직 LLM 기반 개발의 최적 접근법이 정립되지 않았음
    지금은 신앙처럼 믿기보단 내부 동작을 직접 살펴보는 게 중요하다고 생각함

    • 나도 최근 어떤 회사에서 새 “agentic coding platform”을 홍보해달라며 200달러 제안을 받았음
      이런 제안이 무작위 사용자에게까지 오간다는 건, 이미 상당한 마케팅 캠페인이 진행 중이라는 뜻임
    • LLM은 분명 도약적인 도구이지만, 완전한 자율 개발의 만능열쇠는 아님
      단순한 CRUD 작업에는 즐겁지만, 복잡한 프로젝트에서는 오히려 좌절감을 줌
      지금은 벤치마크 경쟁과 VC 자금이 몰려 냉정한 논의가 어려운 시기임
    • GUI가 처음 등장했을 때처럼, 지금은 직관적 가치를 느끼는 단계라고 생각함
      아직 정량적 증거는 부족하지만, 개발자가 완전히 사라질 일은 없더라도 개발 방식이 영원히 바뀌었음

  • Google의 한 Principal Engineer가 “Claude Code가 1년 걸린 일을 1시간 만에 했다”고 트윗했음
    하지만 나중에 밝혀진 바로는, AI가 만든 건 단순한 ‘토이 버전’ 이었음
    이런 과장된 발언이 기대치를 왜곡하고 실망을 초래함
    관련 트윗 링크

    • 이런 트윗은 종종 AI 리더십 실적을 보여주기 위한 내부 압박 때문임
    • 어떤 사람은 “그런 말을 하다니 말도 안 된다”고 반응했음
    • 또 다른 사람은 “AI 성과는 경험 수준과 투자 비용에 따라 달라진다”고 지적함
    • “AI는 여전히 배포할 수 없는 코드만 내놓는다”며 냉소적인 반응도 있었음
    • “이런 일이 Google을 잘 보여준다”고 꼬집은 사람도 있었음

  • 지난 6개월간의 회고로 보면, 인프라 코드(예: Terraform) 에서는 10배 효율을 얻었음
    하지만 전문 기능 개발은 여전히 들쭉날쭉함
    그래도 반복 작업을 줄여 생긴 시간으로 테스트·보안 품질을 높일 수 있었음
    무엇보다 다시 코딩의 즐거움을 느끼게 되었음

    • 나도 35년째 취미 개발을 하는데, AI가 지루한 타이핑을 덜어주고 창의성을 살려줌
    • 나 역시 빌드 스크립트나 CI 작업에서는 2배 이상 빨라졌지만, 복잡한 HPC 프로젝트는 여전히 어렵고
      보조 코딩(assisted coding) 방식이 가장 효율적이었음
      프로젝트 링크
    • 집의 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% 작성했음
    프로젝트 링크
    순수 C로 작성했고, 웹 인터페이스와 실시간 그래프까지 하루 만에 완성했음
    이전엔 실패했던 dBus–blueZ 통신을 이번엔 성공적으로 구현했음

    • 하지만 다른 사용자가 코드를 검토해보니, SSE 구현이 실제로는 작동하지 않음
      문서에는 SSE라 되어 있지만 내부적으로는 일반 HTTP 응답만 반환함
    • 또 다른 사람은 “AI가 쓴 코드가 처음엔 좋아 보여도 점점 품질이 떨어진다”고 지적함
    • “이런 실제 예시를 공유해줘서 고맙다”며 과장 없는 사례로 평가한 사람도 있었음
    • UI 스타일이 흥미롭다며 디자인에 대해 묻는 댓글도 있었음

  • 나는 매일 Augment + Claude Opus 4.5를 사용함
    직접 코드를 거의 쓰지 않고, 명세 기반 반복 작업으로 프로젝트를 완성함
    병렬로 여러 에이전트를 돌리며 리뷰하는 방식이 특히 효율적임
    명확한 스펙 작성과 단계별 피드백이 핵심임

    • Ruby를 잘 모르지만 Rails 앱 개발에 큰 도움을 받음
      30년 경력 중 가장 혁명적인 변화라고 느끼며, 산업 전반이 바뀔 것이라 확신함
    • 어떤 사람은 “1주짜리 프로젝트를 중간 규모라 부르다니 작다”고 농담했음
    • 또 다른 사람은 “이건 진짜 에이전트 개발이라기보다 LLM 협업 개발에 가깝다”고 평함
    • “스펙 중심 개발(spec-driven) 이 생산품질의 핵심”이라는 의견도 있었음
    • 나는 Claude가 먼저 질문을 던지게 해서 요구사항을 명확히 정리하는 단계를 추가함
      현재는 Claude로 일본어–영어 사전 프로젝트를 진행 중임
      GitHub 링크, 웹사이트

  • 20년 경력의 개발자로서, LLM 덕분에 작업 속도 예측이 완전히 빗나감
    예전엔 2주 걸릴 일도 이제 2일이면 끝남
    코드 리뷰와 상호작용은 필요하지만, 대부분의 인간 개발자보다 낫다고 느낌
    LLM과의 대화는 시니어 개발자와 협업하는 느낌에 가깝고,
    내가 오랫동안 코드 리뷰와 업무 분배를 해온 경험이 큰 도움이 됨

    • 어떤 사람은 “그 정도 속도 향상은 믿기 어렵다”며 문제 유형을 궁금해했음
    • 또 다른 사람은 “증거를 기대했는데 없었다”고 짧게 언급함

  • 내가 써본 방법 중 가장 안정적인 건, 작고 명확한 작업 단위로 Claude에게 맡기는 것임
    계획을 세우고, 검토하고, 구현 후 리뷰하는 식으로 반복함
    완벽하진 않지만 막힌 부분을 뚫는 데 매우 유용함
    다만 가이드라인은 잘 지키지 못하므로, 직접 검증과 정리가 필수임

    • 나도 러버덕 디버깅과 비슷하게 Claude를 사용함.
      한 번에 한 함수씩 맡기고, 결과를 참고해 더 나은 아이디어를 얻음
    • 문서화나 분석 작업에서 LLM이 특히 강력함
      하지만 디자인 중심 문제로 가면 한계가 뚜렷함
    • “가이드라인은 어디에 두냐”는 질문엔, CLAUDE.md에 빌드·테스트 정보를 넣는 게 좋다고 조언함

  • AI 보조 코딩을 오해하는 사람이 많음
    AI는 팀원이 아니라 도우미임
    버그나 오작동을 실패로 보는 게 아니라, 숙련된 개발자가 그 혼란을 정리해내는 과정이 핵심임

    • 어떤 사람은 “그렇게 손이 많이 가면 IDE 자동완성과 뭐가 다르냐”고 물음
    • 또 다른 사람은 “최신 기법이 실제로 품질 향상을 입증한 사례가 있냐”고 질문함
    • “결국 ‘너가 잘못 쓰고 있는 거야’라는 말로 들린다”고 비꼰 사람도 있었음
    • “야구 보면서 완벽한 앱을 만들어주길 기대했다면, 그건 AI가 아니라 마법사를 산 거다”는 농담도 있었음

  • 나도 매일 Claude를 쓰지만, AI가 만든 테스트 코드는 종종 엉망임
    실제로는 expect(true).to.be(true) 같은 무의미한 테스트를 양산함

    • 예전 모델은 실패했지만, 최신 모델은 속임수로 통과하는 코드를 만든다는 글을 본 적 있음
    • 그래서 나는 TDD 방식으로 테스트를 먼저 작성하고 검토함
      구현과 테스트를 동시에 맡기면 자기 채점식 오류가 생김
    • 어떤 사람은 “Claude로 테스트를 쓰는 건 포기했다”고 말함
    • “이건 너무 인간적인 해결책”이라며 웃은 사람도 있었음
답변달기