# 한 달 AI 없이 코딩해 보니, 내가 쓴 코드조차 낯설어졌다

> AI 코딩 의존 한 달 중단기, 통제력 상실과 피로만 남았다

- 매체: AI 브리핑
- 담당: 이슈 데스크
- 분야: 논쟁
- 발행: 2026-09-26T14:49:55.869Z
- 원문 주소(웹): https://ai-news-1c0.pages.dev/posts/2026-09-26-%ED%95%9C-%EB%8B%AC-ai-%EC%97%86%EC%9D%B4-%EC%BD%94%EB%94%A9%ED%95%B4-%EB%B3%B4%EB%8B%88-%EB%82%B4%EA%B0%80-%EC%93%B4-%EC%BD%94%EB%93%9C%EC%A1%B0%EC%B0%A8-%EB%82%AF%EC%84%A4%EC%96%B4%EC%A1%8C%EB%8B%A4/
- 태그: AI코딩, 개발자도구, 생산성논쟁, 기술의존, 업무변화

---

한 개발자가 AI 코딩 도구를 완전히 끊은 지 한 달이 지났다. 그가 블로그에 남긴 기록은 **AI가 생산성을 높여준다는 통념을 정면으로 뒤집는다**.

## AI를 끊게 된 계기
필명 'bustikiller'의 개발자는 오픈소스 프로젝트 'LibreWeddingPlanner'에서 AI 기여를 금지했다. 기여가 많아서가 아니라 **향후 분쟁을 피하고 입장을 정하기 위해서**였다. 하지만 직장에선 달랐다. 동료 대부분이 AI를 쓰고 있었고, 그도 '강화된 자동완성'부터 시작해 코드 생성 모델을 연달아 도입했다.

## 통제가 환상이 된 순간
처음엔 함수 하나, 테스트 하나를 맡겼다. 곧 **Jira 티켓 전체를 붙여넣고 구현을 맡기는 단계**로 나아갔다. 낯선 코드베이스에서 AI가 "이 변경이 필요하다"고 하면 그대로 따랐다. 나중엔 **깃 워크트리 여러 개에 에이전트를 띄워 병렬로 돌리는** 지경에 이르렀다.

그는 고백한다. **PR을 검토하는 데 2일이 걸렸다**. 직접 짰다면 1시간이면 끝날 일이었다. 컨텍스트 전환이 기계는 빨라도 사람은 견디지 못했다. **단 한 건도 AI 결과물 그대로 머지하지 못했다**고 적었다.

## 커뮤니티는 둘로 갈렸다
해커뉴스 댓글 126개는 두 축으로 나뉜다.

**도구 탓이 아니다**  
"TDD를 지키며 테스트부터 짜고 AI를 제약하면 된다", "PR을 작게 쪼개면 검토 비용도 줄어든다"는 반론이 적지 않다. **AI를 '마약'에 비유한 글쓴이의 태도 자체가 문제**라는 지적도 있다.

**구조적 한계다**  
"2000년대 '인터넷 없이 한 달' 글과 같다", "측정해 보니 오히려 품질이 올랐다"는 반박도 있다. 하지만 **"토큰이 떨어져 직접 고쳐보니 30분 만에 끝났는데, 내가 아직 할 수 있는지 불안했다"는 댓글**이 가장 많은 공감을 얻었다. 의존이 만든 **심리적 위축**을 보여준다.

## 본지가 앞서 짚은 두 지점과 맞닿는다
**[오픈소스 거장들이 AI 기여를 거절하는 진짜 이유](/posts/2026-08-30-오픈소스-거장들이-ai-기여를-거절하는-진짜-이유/)**에서 다룬 **'검토 비용 폭증'**이 바로 이 글의 핵심이다. AI가 코드를 쏟아내면 **사람이 읽고 판단하는 비용이 기하급수적으로 는다**.

**[AI에게 글쓰기를 맡기면 내 생각이 사라질까](/posts/2026-09-08-ai에게-글쓰기를-맡기면-내-생각이-사라질까/)**에서 논의된 **'주체성 상실'**도 같은 맥락이다. 코드를 이해하려 애쓰는 게 '수치심 회피'였다는 고백은, **생각을 위임했을 때 돌아오는 대가가 무엇인지** 보여준다.

## 쉽게 풀어보면
이 개발자는 **AI라는 '초고속 조수'를 여럿 둔 현장 소장**이었다. 조수들이 밤새 도면을 그려 놓으면, 소장은 아침마다 검수하느라 진이 빠졌다. **직접 그리는 게 더 빠르고 정확했다**는 깨달음이다.

중요한 건 **AI가 쓸모없다는 이야기가 아니다**. **'여러 일을 동시에 맡기는 방식'이 사람 뇌에 맞지 않는다**는 점이다. 한 번에 하나, 작게, 검증 가능하게 — 이건 AI 이전부터 좋은 개발 습관이었다. 도구가 바뀌어도 **원칙은 변하지 않는다**.

## 나에게 미치는 영향
챗GPT나 클로드로 코드 조각을 묻는 정도라면 **이 글과 무관하다**. 하지만 **'에이전트에게 티켓 통째로 맡기기'를 시도 중이라면** 두 가지를 오늘 확인해 보라.

첫째, **PR 크기를 5개 파일 이하로 제한**해 보라. 검토 시간이 확 줄어든다.  
둘째, **테스트를 먼저 쓰고 AI에게 통과시키는 코드만 짜게 하라**. TDD의 원래 목적대로 '설계 도구'로 쓰면 된다.

**직접 타이핑하는 20분이, AI 결과물 읽고 고치는 2일보다 낫다**는 게 이 개발자의 결론이다. 당신의 워크플로도 한 번쯤 되짚어 볼 시점이다.

## 남은 쟁점
양측이 동의하는 지점은 **'검토 비용이 본질'**이라는 것이다. 갈리는 지점은 **그 비용을 줄이는 방법이 '도구 사용법 개선'에 있느냐, 'AI 의존도 축소'에 있느냐**다.

관전 포인트는 세 가지다.  
**첫째**, IDE 내장 에이전트가 '자동완성'에서 '자율 실행'으로 넘어가며 이 문제가 일반화될 것이다.  
**둘째**, 오픈소스뿐 아니라 사내 코드리뷰 문화도 **'AI 생성물 검토 가이드라인'**을 따로 만들게 될 가능성이 크다.  
**셋째**, **'직접 짜는 개발자'와 'AI 지휘하는 개발자'의 임금 격차**가 생길지, 아니면 후자가 번아웃으로 이탈할지가 현장의 다음 화두다.

글쓴이는 끝내 **TDD로 돌아왔다**. 테스트부터 짜고, 작은 커밋을 쌓고, 직접 읽으며 이해하는 방식. **도구가 아니라 습관이 생산성을 결정한다**는 오래된 진실이, AI 시대에도 유효함을 그는 한 달 만에 증명했다.

---

## 출처

- [Hacker News] One Month Without AI — https://news.ycombinator.com/item?id=49855018

## 집필 방식 고지

이 기사는 위 원문과 커뮤니티 반응을 바탕으로 AI의 도움을 받아 작성했으며, 발행 전 사람이 확인했습니다.
인용 시 출처를 "AI 브리핑"으로 표기하고 https://ai-news-1c0.pages.dev/posts/2026-09-26-%ED%95%9C-%EB%8B%AC-ai-%EC%97%86%EC%9D%B4-%EC%BD%94%EB%94%A9%ED%95%B4-%EB%B3%B4%EB%8B%88-%EB%82%B4%EA%B0%80-%EC%93%B4-%EC%BD%94%EB%93%9C%EC%A1%B0%EC%B0%A8-%EB%82%AF%EC%84%A4%EC%96%B4%EC%A1%8C%EB%8B%A4/ 로 연결해 주세요.