AI 보조 코딩, 실제 현업에서 어떻게 돌아가고 있나? (HN 설문 2026년 3월)

TL;DR Highlight

Hacker News 스레드는 현업 개발자들의 AI 코딩 도구 실제 사용 경험을 통해 만능 생산성 도구와 팀 파괴 도구 사이의 현실적인 격차를 드러냈다.

Who Should Read

AI 코딩 도구(Cursor, Claude Code 등) 도입을 고민 중이거나 이미 쓰고 있는 개발자, 특히 혼자 작업할 때와 팀에서 쓸 때 체감 차이가 궁금한 시니어/미드레벨 개발자.

Core Mechanics

그린필드(새 프로젝트) vs. 기존 레거시 코드베이스에서 체감이 완전히 다르다. 새 프로젝트나 독립적인 작은 모듈은 10배 이상 생산성이 올라간다는 경험이 많지만, 대형 레거시 코드베이스에서는 'AI가 프로젝트 맥락을 전혀 파악 못 한다'는 불만이 지배적이다.
Unity 게임 개발처럼 바이너리/씬 그래프 구조가 섞인 환경에서는 현재 세대 AI가 C- 수준으로 평가받는다. 반면 웹/API 개발처럼 텍스트 기반이고 Stack Overflow 학습 데이터가 풍부한 영역은 A 수준이라는 평가가 나왔다.
Amazon 엔지니어는 Claude Opus 4.6 기반 사내 도구(Kiro)로 업무 2~4배, 사이드 프로젝트 10배 이상 생산성이 올랐다고 밝혔다. 코드 작성뿐 아니라 데이터 분석, CloudWatch 로그 확인, 배포 루프 관리 등 반복 작업 전반에 걸쳐 효과를 봤다고 했다.
코드 스킬 퇴화(atrophy) 우려가 여러 명에게서 나왔다. 한 시니어 엔지니어는 '지금 AI 없이 스타트업에 가면 작년보다 기능 구현 능력이 떨어질 것 같다'고 솔직히 인정했고, 주니어 개발자가 AI를 쓴 뒤 1년 만에 버그가 있는 MR을 반복적으로 올리게 됐다는 경험담도 있었다.
관리자·PM들이 Claude로 50페이지짜리 PRD나 슬라이드를 순식간에 만들어 '빨리 검토해달라'고 보내는 현상이 생겼다. 정작 만든 사람도 안 읽고, 받는 사람도 안 읽고, 다른 사람의 Claude가 요약해서 읽는 구조가 됐다는 비판이 있었다.
AI가 만든 코드를 기존 코드베이스에 합치는 작업이 새로운 고통 포인트로 떠올랐다. 한 개발자는 AI로 만든 기능 코드를 메인 코드베이스에 머지하는 데 1주일 이상 걸렸다고 했다. AI 코드가 기존 API 설계를 무시하고, 불필요한 에러 처리와 파싱 코드가 덕지덕지 붙어 있어서 오히려 초기 개발팀보다 자신이 느린 것처럼 보였다고 한다.
솔로 개발자나 작은 팀에서는 AI를 '소프트웨어 공장'처럼 운영하는 실험도 나왔다. 한 개발자는 TDD(테스트 주도 개발) 강제와 자기반성 루프를 도입해 Claude Code로 ~20만 줄 규모 Python/TypeScript 코드베이스를 구축했고, 자신이 직접 작성한 건 500~1000줄 정도라고 밝혔다.
AI 도구의 효과는 맥락(context) 길이와 코드베이스 복잡도에 민감하다. 한 개발자는 MCP로 Unity 프로젝트를 연동했더니 간단한 테스트 프로젝트에선 잘 됐지만, 실제 프로젝트에서는 30k 토큰을 소모하고 40분을 날린 뒤 코드를 다 망가뜨렸다고 했다.

Evidence

팀원이 내 코드를 가져다 Claude에게 넘겨서 '완성'해온 경험담이 공유됐다. 작업 중이던 기능 코드를 팀원들이 Claude에 넣고 대안을 내왔는데, 각 제안마다 비즈니스 요구사항이 하나 이상 빠져 있고 심각한 버그도 있었다는 것. '내가 거의 다 했는데 AI한테 넘기면 금방 된다고 생각한 게 모욕적이었다'는 반응에 대해, 일부 댓글은 '그건 AI 문제라기보다 팀 문제'라고 봤고, 다른 사람은 'AI가 없었다면 그런 상황 자체가 생기지 않았을 것'이라고 반론했다.
FAANG 근무자가 '사내에서 AI로 제대로 된 커밋을 한 번도 못 만들었다'고 고백했다. 개인 그린필드 프로젝트에서는 10x 개선을 경험했지만, 회사 코드에서는 거의 제로 수준이라고. 팀에서 AI 성과를 자랑하는 글은 대부분 새 프로젝트나 리팩토링 프로젝트 팀들이라는 패턴도 지적됐다.
AI 코딩 툴이 '마약처럼 느껴진다'는 비유가 등장했다. 한 개발자는 동료가 AI 코드 생성에 의존하다가 끊으려 했는데 정말 힘들었다고 고백했다고 전했다. 또 다른 동료는 AI가 만드는 코드가 장기 유지보수에 좋지 않다는 걸 알고 코드 생성은 끊고 질문 용도로만 쓴다고 했다. 이에 대해 '그냥 사용 안 하는 게 낫다'는 의견과 '도구는 도구일 뿐, 규율의 문제'라는 의견이 나뉘었다.
AI를 쓰지 않겠다는 개발자도 있었다. 자신의 게으름 성향을 잘 알기 때문에 스킬 퇴화를 막으려고 의도적으로 AI를 쓰지 않는다고 했다. 반면 AI 연구자는 'Claude Code가 나보다 실수를 적게 하는 것 같아서 무섭다'며 이미 코드를 거의 직접 작성하지 않는다고 밝혔다. 같은 현상(AI가 더 잘한다)을 두고 한쪽은 위협, 한쪽은 기회로 보는 대조가 인상적이었다.
Plan 모드(구현 전에 계획을 먼저 잡는 방식)와 Git worktree(여러 작업 브랜치를 동시에 체크아웃하는 Git 기능)를 조합하는 워크플로우가 공유됐다. 한 개발자는 Claude Code의 ExitPlanMode 훅을 이용해 계획서를 UI로 어노테이션하고 에이전트와 피드백 루프를 도는 오픈소스 도구(plannotator)를 만들어 공개했다. 이처럼 AI 도구 위에 직접 워크플로우 도구를 만드는 사례가 여럿 나왔다.

How to Apply

레거시 코드베이스 이해가 병목인 경우, 코드 생성보다 '코드베이스 탐색 도구'로 AI를 활용해보자. 대형 모노레포에서 인도/동유럽 동료에게 밤새 질문하던 걸 AI로 대체해 사전 조사 시간을 수일에서 수시간으로 줄인 사례가 있다. 코드 생성이 아닌 '이 로직이 어디 있어?' 식의 탐색 질문부터 시작하면 실망이 적다.
AI가 만든 코드를 팀 코드베이스에 합치는 작업이 예상보다 훨씬 오래 걸린다. 특히 AI는 기존 API 설계를 무시하고 불필요한 에러 처리나 파싱 코드를 과잉 생성하는 경향이 있으므로, AI 코드를 머지할 때는 '기존 코드베이스의 패턴을 따르고 있는가'를 반드시 체크리스트로 추가하자. 그렇지 않으면 빠르게 만든 만큼 빠르게 기술 부채가 쌓인다.
솔로 프로젝트나 프로토타입에서는 TDD(테스트 주도 개발) 강제 + 계획 모드 조합이 효과적이다. Claude Code로 ~20만 줄 코드베이스를 혼자 유지하는 개발자는 테스트 검증 강제와 자기반성 루프를 워크플로우에 넣으면 AI 실수를 자동으로 잡아낼 수 있다고 했다. 처음부터 테스트 없이 AI에게 전권을 주면 코드베이스가 빠르게 망가진다.
AI 도구 도입 전에 팀 내 '누가 어떤 역할로 AI를 쓸 것인가'를 먼저 합의하자. AI가 가능해지면 팀원이 다른 사람의 작업을 가로채거나, 관리자가 검토도 안 되는 50페이지 문서를 쏟아내거나, 주니어가 이해 없이 AI 코드를 MR로 올리는 문제가 생긴다. 툴 도입보다 팀 협업 규칙 정비가 먼저다.

Terminology

그린필드(Greenfield)기존 코드 없이 완전히 새로 시작하는 프로젝트. 레거시 제약이 없어서 AI가 가장 잘 작동하는 환경이다.

TDD(Test-Driven Development)테스트를 먼저 작성하고 그 테스트를 통과하는 코드를 나중에 짜는 개발 방식. AI가 생성한 코드가 맞는지 자동으로 검증하는 안전망으로 활용된다.

Git worktree하나의 Git 저장소에서 여러 브랜치를 동시에 다른 디렉토리에 체크아웃해두는 기능. AI 에이전트를 병렬로 여러 작업에 돌릴 때 유용하다.

MCP(Model Context Protocol)AI 모델이 외부 도구나 시스템(파일, DB, 앱 등)과 표준화된 방식으로 연결할 수 있게 해주는 프로토콜. IDE나 Unity 씬 같은 환경을 AI에게 '눈'처럼 보여주려 할 때 쓴다.

Plan 모드Claude Code 등 AI 에이전트가 코드를 바로 작성하기 전에 구현 계획을 먼저 제시하고 사람이 승인하는 워크플로우. 방향 이탈을 조기에 잡을 수 있다.

컨텍스트 창(Context Window)AI 모델이 한 번에 읽을 수 있는 텍스트 분량 한계. 대형 코드베이스는 이 한계를 쉽게 초과해서 AI가 앞부분을 '잊어버리는' 문제가 생긴다.