▲

AI 코딩의 함정

 (chrisloy.dev)
27P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • AI 코딩 에이전트가 코드 작성 속도를 극적으로 높이고 있지만, 실제로 개발 과정에서 가장 중요한 부분은 여전히 이해와 문제 해결임
  • LLM을 활용해 빠르게 코드를 만들 수 있으나, 전체 맥락 파악 부족으로 인해 후처리 작업과 이해에 더 많은 시간이 소요됨
  • 이로 인해 생산성에 대한 기대와 실제 효율성 사이의 격차가 발생하며, 개발자들이 원하는 창의적 작업 대신 테스트·리팩터링·문서화 같은 반복적이고 부담스러운 작업에 시간을 쏟게 되는 문제를 유발
  • 과거 ‘테크 리드의 딜레마’ 처럼, 단기 성과를 위해 복잡한 작업을 AI 또는 시니어에게 몰아줄 경우 장기적으로 팀 역량 저하와 위기가 초래됨
  • LLM을 강력한 주니어 엔지니어로 인식하고, 검증된 개발 프로세스를 AI와의 협업에 적용함으로써 지속 가능한 소프트웨어 전달 구조를 만들어야 함

문제 인식: 코딩 그 자체보다 중요한 것

  • 소프트웨어 개발은 문제 해결 중심 작업임
  • 실제 코딩은 개발자의 모든 사고와 고민의 마지막 일부에 해당함
  • 개발자는 코드 외에도 도메인 파악, 요구사항 세분화, 추상화, 부작용 고려, 점진적 테스트, 버그 수정 등 다양한 작업 수행
  • 기존 개발 흐름: 충분히 생각 후 코드 작성
  • AI 코딩 시대: 코드 우선, 이해는 나중의 패턴으로 전환됨

AI 코딩의 전환: 코드가 먼저 생성되는 패러다임

  • Claude Code 등 AI 코딩 에이전트가 코드를 빠르게 생성하지만, 전체 시스템 맥락을 완전히 파악하지 못함
  • 인간의 검토·테스트·통합 과정이 필수적이며, AI가 작성한 코드를 사후적으로 이해하는 데 많은 시간 소요
  • 마케팅에서는 코딩 속도 향상을 강조하지만, 실제 작동 소프트웨어 전달 생산성의 향상은 미미함
  • 개발자는 AI가 만든 결과물의 테스트, 중복 제거, 문서화, 인프라 관리 등 반복적이고 어려운 작업에 더 많은 시간 투입
  • 실제 코딩의 즐거움은 줄고, 반복 작업이 늘어나는 경험 발생

기술 리더의 오래된 딜레마

  • 엔지니어가 테크 리드 역할을 맡으면 팀의 기술 전달 책임을 부담
  • 팀 내 경험치가 한 명에게 집중될 때 생산성 불균형 초래
  • 공정한 분배(팀원 성장을 중시)와 몰아주기(빠른 개발 중심) 두 가지 전략 사이에서 갈등
    • 몰아주기는 단기적 이득이 크나, 경험 편중으로 팀의 장기적 리스크(버팀목 부재, 번아웃, 지원 곤란) 야기
  • 건강한 팀 문화를 위해서는 성장과 효율의 균형을 맞추는 방법 필요

좋은 리더십의 핵심: 프로세스와 성장의 균형

  • 경험 많은 엔지니어 노하우를 팀 전체가 익히도록 다양한 개발 원칙과 프레임워크 적용 필요
  • 예시: 익스트림 프로그래밍, 코드 리뷰, 점진적 배포, 모듈형 설계, 테스트 주도 개발, 페어 프로그래밍, 문서화, 지속적 통합 등
  • 궁극적 목표: 재작업 최소화, 협업 극대화, 개인 성장 촉진

AI 에이전트와의 협업: 새로운 팀 리더 역할

  • 최신 LLM 기반 코딩 에이전트는 엄청나게 빠른 주니어 개발자와 유사
  • 기존 주니어와 달리 LLM은 학습 능력 부재, 속도 제한 없음이라는 뚜렷한 차이 존재
  • AI는 품질 향상 대신 계속 속도 증대에 집중하며, 사람의 맥락·도메인 이해는 부족
  • 두 가지 협업 패턴:
    • AI 기반 엔지니어링: 느리더라도 효율적이고 지속 가능한 팀워크 지향
    • 바이브 코딩: 빠른 결과 도출에 집중하나, 점점 복구 불가 혼란 누적
  • 실리콘밸리 코드 성장의 전통적 맹점과 흡사: 단기 이득 뒤 성장 한계 벽 도달

AI 코딩 함정에서 살아남기 위한 실질적 방법

  • LLM은 자신만의 상황을 모르고 무분별하게 코드를 양산
  • 엔지니어는 AI에게 명확한 구조와 표준, 프로세스를 제공해 원시적 출력을 실제 서비스로 전환해야 함
  • 전통적 개발 주기의 베스트 프랙티스를 AI 협업 환경에 밀착 적용하는 새로운 플레이북 필요
  • 주요 단계별 AI 활용 방안:
    • 스펙 정의: 엣지 케이스 분석, 목표 범위 집중
    • 문서화: 반복 사용 가능한 가이드·증거 확보
    • 모듈 설계: 맥락 한정으로 이해도 향상
    • 테스트 주도 개발: 구현 전 테스트케이스 생성, 회귀 방지
    • 코딩 표준: 스타일·품질 유지
    • 모니터링: 로그 자동 분석 및 인사이트 도출

결론

  • 소프트웨어 전달은 코드 작성만으로 이뤄지지 않으며, AI와 인간의 효율적인 협업 구조 정립이 필수적임
  • LLM을 초고속 주니어 개발자로 간주하고, 검증된 개발 프로세스를 적용해야 확장성 있는 고품질 소프트웨어 제공 가능
▲
shakespeares 1일전  [-]

공감이 됩니다. AI 코딩을 했을 때 후처리 작업이 너무 많아서 실제 비즈니스를 녹이고 유지보수하는 데 너무 힘이듭니다.
같이 개발한다는 입장으로 최대한 핑퐁을 많이 주고받고 진행해도 일부 코드가 직접 작성한 것이 아니기에 머리에서 휘발되는 경우가 많습니다.
경계는 무조건 필요하다고 생각되네요.

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 단순히 “기술이 사람을 게으르게 만든다”는 주장에 기반하지 않은 anti-AI 논거가 보고 싶음. 진지하게 LLM으로 코드를 만들어 본 사람은 계획-구성-테스트-회고 루프가 여전히 매우 중요하다는 걸 느낌. 주의 없이 그냥 돌리면 바로 망가지기 쉬움. 이 루프를 잘 적용하면 내가 좋아하는 아키텍처 설계와 결과 경험을 테스트하는 데 많은 시간을 쓸 수 있음. LLM이 쉬운 파트들을 빠르게 처리해주니, 결국 우리가 남아서 처리해야 하는 건 덜 흥미롭고 감사받지 못하는 일들임. AI가 전문성을 빛내는 분야에서는, 일 자체를 즐기는 사람과 생각하는 경험을 즐기는 사람 사이의 견해차가 극명히 나타남. 생각하는 것이 좋은 사람은 AI 덕분에 거의 전적으로 그 영역에 집중할 수 있음. 반면, 직접 타이핑하고 조작하는 걸 좋아하는 사람에게는 AI가 오히려 내가 좋아하는 부분을 빼앗아 감

    • AI 코드 생성과 관련해, 기술이 사람을 게으르게 만든다는 생각보다는 AI가 생성한 코드에 대한 깊은 이해를 빼앗는다는 점이 더 중요한 비판으로 봄. 소프트웨어 엔지니어의 핵심은 코드를 생성하는 것이 아니라 전체 시스템을 설계하는 것임. 여기서 중요한 건 코드가 작동하는 방식에 대한 사고방식(mental model)과 도메인 전문성인데, 코드는 이 정신 모델에서 파생된 결과물임. 일정 규모 이상의 프로젝트에서는 직접 코드를 작성한 저자가 아닌 이상 그 코드를 완전히 알기는 어려움. 이러한 정신 모델을 쌓지 않으면 다른 문제도 따라옴. LLM 기반 코딩 에이전트들은 문법 수준의 추론에 한계가 있어 확장성에 약점을 보임

    • 내 생각을 말하자면, 나는 Cline 같은 AI 도구를 가끔 쓰지만 점점 직접 타이핑해서 코딩하는 비율이 높아지고 있음. 그 이유는 대부분의 경우 코딩을 프롬프트 작성으로 대체할 뿐임. 프롬프트 작성과 추론 시간이 내 손으로 직접 코딩하는 시간보다 짧으면 AI를 쓰지만, 보통 이런 건 리팩토링 정도의 속도 한계일 때만 해당됨. 대부분의 작업에서는 직접 하면 10분, AI로 하면 프롬프트 작성하고 실행하고 8분 걸림. 실수 없이 잘 되면 2분 절약이지만, 수정이나 재프롬프트가 발생하면 오히려 10~12분 걸리고, AI 크레딧도 썼으니 최악임. 이런 계산을 하다 보니 코드 퀄리티나 소요시간 모두를 생각하면 수작업이 더 안전하다는 결론에 이름

    • 기술이 사람을 부주의하게 만든다는 주장에 대해, 일반적으로 기술이 사람을 더 신중하게 만드는 경우도 많음. 문제는 이 AI 기술이 사용자에게 부주의를 유도할 가능성이 크다는 점임. 내 관심사는 코딩의 재미있는 부분이 아니라, 나는 설계(아키텍처) 자체를 더 선호함. 만약 의도를 바로 코드에 반영할 수 있다면 그 방식을 쓸 것임. 하지만 챗봇 인터페이스는 의도를 간접적이고 불완전하게 전달하므로, 고수준 코드 빌드에 사용할 때 내 머릿속 모델과 실제 코드 이해가 빠르게 멀어져서 불안정한 기초를 남김. 라인별로 꼼꼼히 리뷰해볼 수도 있지만, 도구의 취지와는 반대임. AI 코딩은 “10배 빠르다”는 느낌 때문에 세부 구현과 거시적 이해의 괴리를 부추김. 실제로 구조적 부분을 덜 생각하는 것이 AI 코딩을 홍보하는 주요 이점이지만, 이 이해 격차가 나중에 문제를 일으킴. 좋은 자동화는 신뢰성 있고 예측 가능해서 상위 불변식만 이해하면 되지만, 챗봇 코드는 이런 보장을 주지 않아 결국 모든 것을 수동으로 검증해야 하는 구조를 만듦. 여기서는 안전과 신뢰성이 오히려 더 어렵게 여겨짐

    • “생각하는 부분에 집중하라”는 논리를 너무 자주 봐서 이제는 식상하다고 느낌. 문제는, 다년간 실무를 직접 해보지 않은 사람이 생각만으로 깊이 있는 활동을 할 수 있는지 의문임. 결국, 직접 해보는 경험 없이는 생각마저 점점 얕아질 위험이 있음

    • 내 견해는, 디버깅이 쓰는 것보다 더 힘드니 내가 안 쓴 코드를 디버깅하느니 직접 쓰는 게 낫다는 점임

  • 이런 논의 읽으면서 매번 드는 생각은, 과연 저자가 나와 같은 도구를 쓰고 있는지 궁금해짐. 나는 Claude Code로 단순한 보일러플레이트부터 복잡한 알고리즘까지, 아주 헷갈리는 대규모 코드베이스 내에서도 거의 다 만들어낼 수 있음. 물론 100% 맞지는 않지만 매우 근접함. 게다가 내가 생각하지 못했던 알고리즘도 종종 제안함. 이런 도구들은 내 시간을 최소 10배는 아껴줌

  • 이 글은 괜찮으나 두 가지 허수가 보임. 첫째, 숙련된 개발자가 LLM을 쓸 때에도 여전히 충분한 탐구와 사전 고민, 설계가 필수적임. 오히려 LLM을 제대로 활용하려면 평소보다 더 많이 사고하고, 다양한 설계안을 비교하고, 전체 구조를 그림. 예전에는 이런 과정을 문서화하지 않았지만 이제는 설계 문서로 남기고 있음. 둘째, LLM이 성장하지 않는 주니어 개발자와 같다는 주장인데, 둘은 완전히 다름. 인간 신입 개발자는 사람이고 LLM은 도구임. 중요한 건 신입과 함께 일하면 누적 가치가 생기고 LLM과는 그렇지 않다고들 하는데, 이 또한 옳지 않음. LLM이 학습하지 않아도, 내가 훨씬 효율적으로 길들이며 더 잘 활용하게 됨. 제품에 LLM을 잘 적용하는 초창기이니, 당연히 복합적인 성장 가치가 보임

    • “LLM이 학습하지 않더라도, 나는 학습함”에 공감하지만, 여전히 LLM이 유저와의 상호작용에서 진짜로 배우길 바람. 내가 원하는 것은, 세션의 내용을 파일로 저장/불러오기 해서 LLM이 이전에 배운 컨텍스트 전체를 빠짐없이 알아듣는 것임. 일부 프론트엔드 UI에서 세션을 저장/복구할 수 있지만, 중요한 점은 a) 이런 “재학습”이 LLM의 현재 context window에 영향을 안 줬으면 좋겠고(아예 이 개념이 없어졌으면 좋겠지만), b) 절대 유실 없는 방식이어야 함. 요약 후 이어가기, RAG 같은 방법이 이미 나와 있지만, 이들 모두 정보 손실이나 현재 상호작용이 트리거되어야만 복원이 가능한 등의 근본적 한계가 있음. 예를 들어, 어제 LLM에게 어떤 함수에 대해 설명 후 세션을 저장했다가, 오늘 세션 복구 후 아무 접점 없는 질문을 해도 LLM이 예전 맥락까지 다 고려해 답해주길 바람. 새 출발(clean slate)도 원할 땐 명시적으로 할 수 있는 방식이 필요하다고 봄

    • 맞는 말임. 소프트웨어의 전체적인 생산성에서 사고하는 시간이 실제 코드를 작성하는 시간보다 훨씬 큰 비중을 차지하기 때문에, LLM이 코딩 부분을 빠르게 해도 전체 생산성이나 인력 수요에 극적인 변화가 생기진 않음

    • DO NOT WRITE ANY CODE YET 프롬프트로 시작하는 게 나도 기본임. LLM이 뭘 하려는지 먼저 파악하고 내 통제권을 확보하는 방법임. 난 코드를 쓰는 것보다 논리/문제 해결/시스템 통합 등 설계 자체가 더 재밌음

    • Copilot의 Ask 모드, GPT-5 Codex의 Plan/Chat 모드처럼 코드 파일을 변경하지 않고 계획만 할 수 있는 기능이 있음. Codex를 며칠 써봤는데 충분한 지시를 주면 아주 뛰어남

    • 나도 대부분 “먼저 계획을 말해줘”처럼 LLM에게 구체적인 실행 전 계획부터 묻는 것을 선호함

  • 이번 글은 Microsoft의 마케팅 자료만을 인용해 10% 생산성 향상을 주장하는데, Harvard 연구에서는 실제로 오히려 10% 생산성 저하가 기록됨. 특정 기업의 홍보가 아닌, 독립적인 연구 결과를 먼저 인용하는 글이 더 좋겠음

  • 이 글이 완전히 전달하지 못한 핵심 중 하나로, Casey Muratori가 말한 “학습 중심 마인드셋으로 프로그래밍한다면 AI는 오히려 무의미하다”는 점에 공감함. 개인적으로 AI 코드 생성기는 일회성·버릴 예정인 코드에만 유효함. 진지하게 배우고 싶은 영역에서는 AI에게 코드 생성을 맡기지 않는 것이 학습 효과를 극대화한다고 느꼈음. “AI 주도 엔지니어링”이 유의미한 분들도 분명 있겠으나, 적어도 내게는 직접 손으로 코드 블록을 작성해야 더 재미있고 결국 결과물도 더 잘 완성되는 느낌임. 관련 영상, 5분 분량

    • “학습이 극대화되는 상태는 AI로 아예 코드를 생성하지 않는 경우다”라는 논리가 너무 극단적임. 배움을 위해 스스로 해보는 게 중요해도, 타인과 소통하거나 도움을 전혀 구하지 않는 것과 마찬가지로 너무 강한 주장으로 느껴짐

  • Claude Code를 쓰며 생각하는 데 훨씬 더 많은 시간을 쓰게 됨. 하고 싶은 기능을 400~600단어로 묘사하는 일이 과거에는 없었는데, 이젠 더 많은 정보를 골똘히 정리함. 이런 고민 덕분에 더 빠르고 좋은 결과가 나오긴 하지만, 동시에 코드에 대한 나의 이해도는 이전보다 다소 낮아짐. 하지만 Claude Code 쓰면 경험 많은 개발자가 덜 고민한다는 주장에는 동의할 수 없음. 아마 많은 사람들이 거의 프롬프트만 쓰는 등 비효율적으로 에이전트를 사용하는 경우가 많을 것 같은데, 그건 에이전트의 잘못이라고 보진 않음

  • 이런 논의들을 보면, 지금은 아직 애매한 과도기라고 생각하게 됨. 내년쯤이면 오늘과 같은 논의가 "너무 생각이 많다"는 느낌으로 취급될 것 같음. 인터넷이 보급되기 전후에 “일시적 유행” “잘못된 투자”같은 의문이 많았던 시기처럼 보임

  • 이런 글이 자주 놓치는 점은 다음과 같음

    1. 모든 코딩이 같지 않음. 상대는 프로덕션 시스템일 수 있고 나는 단순 실험용일 수 있음
    2. 모두의 에이전트 활용법이 다름
    3. 뛰어난 개발자의 시간도 비용임
      AI 코드보조의 장·단점과 트레이드오프만 체계적으로 정리한 글이 있었으면 좋겠음. 도덕적 가치판단(좋음/나쁨)은 빼고 논의하는 게 필요함. “코딩 실력”이 나의 정체성일 때 특히 냉정하게 접근하기 힘든 점 인정함
    • 본문은 네가 지적한 1번 항목(코딩의 상황 다양성)에 대해 한 번 언급하고 있음

  • 매일 “30년만 더 버티면 은퇴하자”라고 스스로 독려함. 머신러닝 분야 10년째, 컴퓨터 앞에 지치고 일도 지침. 그냥 풀밭에서 뒹굴고 싶음

    • 휴식(안식년)이 필요해 보여서 한 번 권하고 싶음

  • “생각&코딩 vs 생각&수정” 그래프가 흥미로움. 최근 Codex를 쓰며 확실히 AI가 내 코드를 많이 고치게 만들 거라 기대했음. 실제로는, 문제의 원인이 전혀 코드와 상관 없을 때 시간이 왕창 소모됨. 최근에는 인증 문제로 한참을 코드만 파봤는데, 원인은 VM의 ipv6 설정 장애로 밝혀짐

답변달기