AI 없이 한 달

AI 요약

오픈소스 프로젝트 LibreWeddingPlanner를 운영하는 글쓴이는 몇 달 전부터 프로젝트에 AI가 만든 기여를 받지 않기로 했지만, 직장에서는 AI 코딩 도구를 계속 사용했습니다. AI 활용이 개발자의 속도와 역량을 높인다고 여겼지만, 시간이 지나면서 코드 이해와 판단이 줄고 검토 부담이 커졌다고 설명합니다. 한 달 전 사용을 멈춘 뒤 경험을 돌아보며, AI에 작업을 맡길 때 무엇을 잃을 수 있는지 이야기합니다.

빠른 작성, 줄어든 이해

처음에는 VS Code의 자동완성이나 코드 생성 모델을 사용하다가 함수 구현과 테스트 작성까지 맡겼습니다. 오랫동안 TDD(Test-Driven Development)를 해 온 개발자라 테스트부터 작성하게 했지만, 결국 구현도 AI에 맡기면서 테스트가 구현 방식에 편향되지 않도록 하는 TDD의 취지가 약해졌다고 합니다. 에이전트가 커밋에 공동 작성자로 표시되는 것을 보고 설정을 끄기도 했습니다. 자신이 만든 코드처럼 보이고 싶다는 생각이 들었기 때문입니다.

이후 Jira 티켓 설명 전체를 붙여 넣어 구현을 맡기고, 여러 에이전트를 각기 다른 Git worktree에서 동시에 돌렸습니다. ACLI를 Jira에 연결해 티켓 처리를 지시하기도 했습니다. 하지만 작업을 병렬로 늘리자 어떤 변경이 실제로 필요한지 판단하기 어려워졌습니다. 에이전트가 프로젝트 코드를 모두 읽었다는 이유로 제안한 변경을 받아들이면서, 프로덕션에 들어가는 코드 가운데 자신이 제대로 이해하는 부분이 얼마나 되는지 걱정하게 됐습니다.

작은 작업은 에이전트가 5분 만에 끝내도 검토와 수정에 이틀이 걸릴 때가 있었습니다. 여러 작업 사이를 오가며 코드와 테스트, 스타일, CI 결과를 확인하고 리뷰 의견에 대응해야 했습니다. 글쓴이는 20분이면 집중해서 끝낼 일을 에이전트가 먼저 작성하게 한 뒤 이틀 동안 검토하는 상황을 겪었습니다. 작업 수를 늘리면 생산성도 높아질 것처럼 보였지만, 글쓴이의 경험에서는 피로와 전환 비용이 더 크게 쌓였습니다.

PR을 검토하는 사람은 누구인가

글쓴이는 AI가 만든 PR을 그대로 병합한 적이 없었다고 말합니다. 코드뿐 아니라 테스트와 설명도 확인해야 했지만, 에이전트가 작성한 긴 PR 설명은 점점 읽지 않게 됐습니다. 전문적으로 들리는 문장과 그럴듯한 변경에 익숙해지면서, 예전이라면 받아들이지 않았을 코드도 왜 나쁜지 설명할 수 없다는 이유로 넘어갔다고 합니다. 몇 달 동안 직접 코드를 한 줄도 쓰지 않고, 에이전트에게 커밋과 푸시까지 요청한 사실을 깨닫고는 사용을 중단하기로 했습니다.

전환점은 동료의 코드 리뷰였습니다. 글쓴이가 작성한 테스트가 애플리케이션 코드에서 바뀐 시나리오를 실제로 검증하지 않는다는 지적을 받았고, 검토 결과 동료 말이 맞았습니다. 10년 넘게 TDD를 해 왔는데도 기본적인 테스트 오류를 놓쳤다는 사실에 부끄러움을 느꼈습니다. 더 꼼꼼하게 AI를 지시하는 방식으로는 문제가 해결되지 않는다고 판단했습니다.

AI가 작성한 초안 PR을 직접 이어받아 보니, 무엇을 하는 코드인지 몰랐던 정도를 뒤늦게 알게 됐습니다. 결국 기존 변경을 버리고 처음부터 다시 쓰기도 했습니다. 글쓴이는 TDD와 작은 PR, 두 줄로 요점을 적은 설명으로 돌아갔습니다. 변경 내용을 직접 설명하고 배포를 자신 있게 진행하며, 동료의 코드 리뷰에서 설계 결정과 코드베이스의 배경을 배우는 즐거움도 되찾았다고 합니다. 직접 작성과 검토를 계속하면 코드베이스를 더 잘 이해하는 개발자가 된다는 것이 글쓴이의 주장입니다.

AI 활용을 둘러싼 반응

댓글에서는 AI가 만든 코드를 사람이 이해하고 책임져야 한다는 주장과, 작업에 따라 AI를 적극 활용해도 된다는 의견이 맞섰습니다. 한 개발자는 “코드가 중요하다면 누군가는 변경에 책임져야 합니다. 이해하지 못한 채 책임질 수는 없고, 이해에는 시간이 듭니다”라고 썼습니다. 그는 중요한 코드에서는 AI를 사람의 맥락을 넓히는 도구로 쓰고, 프로토타입처럼 중요도가 낮은 작업에서는 자유롭게 실험해도 된다고 덧붙였습니다.

다른 댓글 작성자는 에이전트 코딩을 팀에서 강하게 추진한 뒤, 여섯 명이 각각 두 개 이상의 프로젝트를 동시에 진행하게 됐다고 전했습니다. 코드 생성과 PR 수는 늘었지만 통합 단계에서 일이 밀렸고, 이해관계자와 고객이 만족하는 결과물을 내는 데 어려움을 겪었습니다. 팀은 진행 중 작업을 제한하고, 규모가 큰 프로젝트에는 최소 두 명이 협업하도록 바꿨습니다. 코드 생산 속도와 토큰 비용은 줄었지만 밀린 작업이 풀렸다고 합니다.

반면 AI가 작성한 코드의 검토가 실제로 시간을 아껴 준다는 의견도 있었습니다. 한 이용자는 코드를 직접 읽지 않고 6개월 넘게 개발해 왔다며, 테스트와 가이드, 최신 모델을 잘 활용하면 대다수 개발자보다 나은 구현을 얻을 수 있다고 주장했습니다. 이에 다른 댓글은 테스트를 읽지 않았다면 테스트가 정확한지 어떻게 아느냐고 물었습니다. 또 다른 이용자는 에이전트 환경에서는 코드베이스의 품질이 증명할 수 있는 범위에 달린다며, 정적 분석과 엄격한 타입 검사, 형식 검증 같은 도구의 중요성이 커질 것이라고 답했습니다.

AI 활용의 중간 지점을 찾자는 의견도 나왔습니다. 한 개발자는 로그 분석과 프로덕션 장애 조사, 일회성 스크립트, 기계적인 리팩터링에는 AI가 유용하지만, 결과를 확인하고 맥락을 바로잡아야 한다고 설명했습니다. 반대로 AI 없이 한 시간만 작업해도 실력이 얼마나 무뎌졌는지 놀랄 수 있다는 댓글도 있었습니다. 토론은 AI를 금지할지 허용할지에 그치지 않았습니다. 어떤 작업을 맡길지, 검토와 책임을 누가 질지, 코드 생성량이 실제 제품 완성으로 이어지는지를 함께 따져야 한다는 쟁점으로 이어졌습니다.

Hacker News 반응

• @austin-cheney — AI에 지나치게 의존하는 이유를 이해하지 못하겠습니다. 코드를 쓰는 일 자체가 어려운 건 아닙니다. 새 기능을 밀어 넣고 테스트하는 데 걸리는 시간은 몇 시간 정도로 대수롭지 않을 때가 많습니다. 진짜 어려운 일은 새로운 아이디어를 만드는 것이며, 그런 아이디어는 대개 제품으로 코드를 써 보거나 큰 코드베이스를 유지보수하고 리팩터링하는 데서 나옵니다.
  • @XCSme — 코드 작성이 어려운 건 아니지만, 제 시간을 가장 많이 쓰던 일이었습니다. 타이핑만이 아니라 구현 방법을 고민하는 시간도 들었습니다. 이제 “2단계 인증을 추가해”라고 하면 제가 다른 걸 테스트하는 동안 5분 만에 끝납니다. 반복 작업도 훨씬 빨라졌습니다. 결과를 보고 마음에 들지 않으면 코드를 전부 버리고 다시 시작하면 됩니다.
  • @anygivnthursday — 그래도 그 2단계 인증 코드를 검토해야 하고, 그러려면 구현을 고민해야 하지 않나요?
  • @XCSme — 아닙니다. 6개월 넘게 코드 한 줄도 쓰지 않았고 읽지도 않았습니다. 예전에는 코딩을 좋아했고 프로그래밍 대회에도 나갔지만, 요즘 “코딩”은 이렇게 돌아갑니다. 기능이 어떻게 작동할지 머릿속에 그려 두고, 확인 질문을 하고, 놓치기 쉬운 점을 살펴보라고 지시합니다. 그다음 제가 기능을 조금 테스트합니다. 보안 측면에서는 최신 사이버 모델이 취약점 탐지와 침투 테스트에서 저보다 낫다고 생각합니다.
  • @OccamsMirror — 책임을 내려놓고 계십니다. 자기 장난감 앱이라면 괜찮겠지만, 사람들이 계정을 지켜 줄 거라고 기대하는 2단계 인증이라면 괜찮지 않습니다.
• @gizajob — “제가 20분이면 쉽게 끝낼 작업을 AI 에이전트는 5분 만에 했고, 저는 검토에 이틀을 썼습니다.” 어떤 분야든 AI를 생산성 도구로 쓰면 이런 일이 생깁니다. Claude를 실험 삼아 책을 썼습니다. 책은 완성됐고 놀라운 도구였으며 즐거운 경험이었습니다. 하지만 결과물은 모든 문장을 다시 써야 하고, 논리적 모순이 곳곳에 있으며, 문체가 너무 나빠서 고쳐 쓰느니 버리는 편이 나을 정도입니다.
  • @thwarted — 결과물을 그렇게 많이 고쳐야 하고, 본인 평가로는 버려야 할 정도라면 어떻게 즐거운 경험이었나요? 다시 작업하는 데 드는 비용이 너무 커서 처음 결과물이 최종물에 거의 기여하지 못했다고 봐야 하는 지점은 어디인가요?
  • @gizajob — 늘 맥락을 파악하고 있고, 잊어버리지 않으며, 며칠 뒤에도 이전 작업을 이어가는 조수가 있다는 점은 정말 흥미로웠습니다. 논점을 정리하고 요약도 잘했습니다. 문제는 계획을 줘도 한 번에 한 장씩만 제대로 작업했고, 한 장을 바꾸면 다른 장에서 한 말과 어긋나곤 했다는 점입니다. 문체도 진부한 표현과 나쁜 비유, 반복이 많았습니다. 문법은 괜찮았지만 제 이름을 걸 수 없는 글이었습니다.
• @goalieca — “설명은 다른 사람을 위한 것이니 읽지 않게 됐다”는 부분이 있습니다. 작성자 본인도 읽지 못한다면, 제가 무엇을 검토해야 하는지 긴 글을 읽고 어떻게 이해하겠습니까? PR 설명은 직접 쓰시길 강하게 권합니다. 다른 사람이 이해할 만큼 간결하게 설명하지 못한다면 변경 사항을 이해하지 못하는 것이고, 리뷰를 요청하지 말아야 합니다.
• @qwertyhjkl — 사업 관점에서 LLM 에이전트의 도움 없이 거의 같은 생산성을 낸다고 주장할 수는 없다고 봅니다. 조종사가 가끔 구름 속에서 직접 비행해 실력을 유지하듯, 금요일 하루 정도는 직접 코드를 써서 기술을 유지하고 나머지 시간에는 자동 조종을 쓰면 됩니다.
• @iLoveOncall — AI로 코딩을 많이 하는 분들에게 AI를 전혀 쓰지 않고 한 시간만 작업해 보라고 권합니다. 기술이 얼마나 퇴화했는지 깜짝 놀랄 겁니다.
• @thevinter — 글은 좋고 현재 AI 개발의 문제를 잘 담았습니다. 다만 결론과 대응은 다소 과장됐다고 느낍니다. AI를 완전히 끊는 건 물론 타당한 선택입니다. 하지만 AI는 잘못 쓰기 쉬운 도구이기도 합니다. 저희는 거대한 PR을 검토하느라 병목을 겪고, 아무도 읽지 않는 긴 커밋 설명이 늘었습니다. 반면 품질이 중요하지 않은 빠른 도구를 만들거나 데이터를 처리할 때, 로그 파일로 코드베이스 문제를 조사할 때는 큰 도움이 됩니다. 일부 작업에서 문제가 생긴다고 해서 AI를 완전히 포기해야 하는지는 모르겠습니다. 저도 새 프로젝트에서는 AI를 전혀 쓰지 않기로 했습니다.
• @bunderbunder — 올여름 저희 팀도 에이전트 코딩을 강하게 추진했습니다. 한 달도 안 돼 여섯 명이 각자 늘 두 개 이상의 프로젝트를 동시에 맡았습니다. Little’s Law를 다시 깨달았습니다. 진행 중인 작업이 쌓이고 통합 단계에서 감당하기 어려워졌습니다. 프로젝트를 시작하는 데는 능숙해졌지만 끝내기는 어려웠습니다. 티켓은 잘 움직였고 코드 생성과 PR 제출량도 크게 늘었지만, 고객과 이해관계자가 만족할 정도로 프로젝트를 완성하지 못했습니다. 그래서 엄격한 진행 중 작업 제한을 다시 도입하고, 중요 프로젝트에는 두 명 이상이 협업하도록 했습니다. 코드 생산량과 토큰 비용은 줄었지만 밀린 작업이 풀리고 있습니다.
• @osigurdson — 요점은 코드가 중요하다면 누군가는 변경에 책임져야 한다는 것입니다. 이해하지 못하면 책임질 수 없고, 이해에는 많은 시간이 듭니다. AI는 큰 도움이 되지만, 중요한 코드에서는 AI가 맥락을 채우게 하십시오. 사람이 맥락을 AI에 넘기지는 마십시오. 중요하지 않은 코드, 프로토타입이나 속도 실험에서는 마음껏 AI를 써도 좋습니다.

원문: blog.bustikiller.com / 번역·요약: Trawling