AI에는 지혜가 없고, 당신도 그렇게 될 수 있습니다

AI 요약

글쓴이는 최근 한 달 동안 “2025년 이후 코드를 쓰지 않았다”, “코드 리뷰는 끝났다”, “사람들은 더 이상 코드를 읽지 않는다”는 말을 들었다고 합니다. 개발 업계가 바뀌는 흐름 자체는 인정하지만, 코드를 읽고 쓰는 일을 포기하는 사람과 조직은 대가를 치르게 된다고 봅니다.

유지보수성은 늦게 드러납니다

Vibe coding으로 만든 프로젝트는 시간이 지나면서 유지보수하기 어려운 엉망진창으로 변한다고 설명합니다. 나쁜 아키텍처와 유지보수하기 어려운 코드의 결과는 몇 달에서 몇 년이 지나야 드러나기 때문입니다. 즉시 측정할 수 있는 좋은 평가 지표가 없다는 점도 문제입니다. 만약 유지보수성을 정확히 측정할 방법이 있었다면 이미 linter에 반영됐을 것이라고 말합니다.

나쁜 코드는 읽기 어렵고, 이해하기 어렵고, 미래의 변화에 맞춰 수정하기 어렵습니다. 한 부분을 바꾸면 멀리 떨어진 코드의 동작이 비결정적으로 깨집니다. 기능 하나를 추가하려고 여러 위치를 고쳐야 하고, 일부 수정을 빠뜨려 코드 사이에 불일치가 생깁니다. 설계의 불변 조건이 분명하지 않아 작성자가 떠난 뒤에는 규칙 위반을 막기 어렵습니다. 테스트를 작성하려면 mock을 많이 사용해야 하고 구현 세부 사항을 테스트에 노출해야 해서, 리팩터링을 막는 취약한 테스트가 만들어집니다.

숙련된 개발자는 운영 장애를 디버깅하고 고치는 과정에서 이런 문제를 일찍 감지하는 감각을 익힙니다. 하지만 그 감각은 상황에 따라 달라지므로 엄격한 규칙 목록으로 만들기 어렵습니다. 글쓴이는 초보자에게 생산성을 높여주는 규칙과 숙련자가 따르는 판단 기준이 다르다고 봅니다. 초보자는 규칙을 따르지만, 전문가는 상황에 맞는 규칙을 직접 만듭니다. Dreyfus model에서 대부분의 개발자는 여전히 ‘고급 초보자’ 단계에 머물러 있으며, 좋은 함수를 설계하는 일은 경험을 쌓아야 가능한 기술이라고 설명합니다.

AI가 유지보수 가능한 코드를 배우기 어려운 이유

AI 학습에서 강화학습 보상은 즉시 측정할 수 있어야 합니다. 몇 달이나 몇 년 뒤에 드러나는 유지보수성은 보상 신호로 쓰기 어렵습니다. AI는 초보자용 규칙집에서 규칙을 배우고, 실제 코드에서 패턴을 익히지만 현실의 코드는 대체로 품질이 낮습니다. 따라서 AI가 유지보수성을 제대로 최적화할 기준을 찾기 어렵다고 주장합니다.

글쓴이는 최신 성능 모델조차 코드를 ‘단순화’하는 데 약하다고 지적합니다. 큰 함수에서 작은 함수를 무조건 추출하지만, 추출한 함수가 실제로 재사용되지 않는 경우가 많습니다. 큰 함수의 동작을 이해하려면 다시 추출된 함수의 구현을 읽어야 한다면, 코드가 더 명확해진 것이 아닙니다. 재사용 가능하면서도 의도를 분명히 전달하는 함수를 설계하는 일은 단순한 분할 규칙으로 해결되지 않는다고 봅니다.

사람이 AI의 코드를 검토하고 실수에서 배우는 구조라면 문제를 줄일 여지가 있습니다. 그러나 AI가 코드 작성뿐 아니라 코드 읽기까지 대신하면, 사용자는 선택과 책임을 내려놓게 됩니다. 실수한 주체는 AI가 되지만 AI는 그 실수에서 지속적으로 배우지 않고, AI에 의존하는 사람도 직접 판단하고 고치는 경험을 잃습니다. 그 결과 숙련에 도달하기 어려워진다는 주장입니다.

AI는 도구지만 판단을 넘겨서는 안 됩니다

글쓴이는 LLM을 거부하지 않습니다. 일상 업무에 AI를 통합했고 동료에게 배운 점을 가르치며, 지루하고 소모적인 일을 LLM에 맡기고 효율성도 얻고 있다고 말합니다. 다만 LLM은 도구일 뿐이며, 도구가 코드 작성과 판단 전체를 대신해서는 안 된다고 선을 긋습니다.

글쓴이는 앞으로 일부 기업이 ‘NO-AI’ 정책을 경쟁 우위로 내세울 것이라고 예측합니다. 자동화가 항상 더 효율적인 것은 아니며, 소프트웨어 산업은 원래 대규모 자동화를 해오던 분야라고 설명합니다. LLM만이 자동화 수단은 아니고, 상황에 따라 LLM 사용이 오히려 주의를 분산시킬 수 있습니다. 새로운 C/C++ 컴파일러를 LLM에 만들게 하기보다 이미 존재하는 GCC나 LLVM을 복제하는 편이 더 나을 때도 있습니다. 기업과 개발자가 AI 사용에 책임을 다하지 않으면 그에 따른 결과를 맞게 된다는 말로 글을 마무리합니다.

Lobsters 반응

• @hyperpape — 앞으로 점점 더 많은 기업이 ‘NO-AI’ 정책을 경쟁 우위로 자랑하게 될 것이며, 그 판단이 옳을 것이라는 예측은 흥미롭지만 분명히 틀렸다고 생각합니다. 코드 읽기를 반대하는 사람은 아니지만, 기업의 AI 사용은 계속 늘어날 것이라고 확신합니다. 그 예측을 검증 가능한 형태로 만드는 방법은 모르겠습니다. 기업이 “AI로 사람을 대체하려다 실패했고, 다시 사람을 채용해 달라고 부탁하게 된 이유”를 설명하는 이야기는 많이 나오겠지만, 일반 사무직과 개발자 업무에서 AI 사용이 완전히 사라지지는 않을 것이라고 봅니다.
• @cflewis — AI 지원 개발 전반을 매우 긍정적으로 보고 있으니 감안해서 읽어야 합니다. AI가 사람이 유지보수하기 좋은 코드를 잘 작성하지 못한다는 글의 기본 전제에는 동의합니다. 글쓴이가 직접 말하지는 않았지만, 여기서 말하는 유지보수 가능성은 인간을 위한 것이라고 강하게 읽힙니다. 다만 AI와 사람이 함께 읽고 수정하는 코드는 과도기적인 상태라고 봅니다. 언젠가는 AI만 코드를 읽고 쓰는 단계로 갈 수 있습니다. 그때 중요한 기준은 AI가 유지보수하기 좋은 코드를 작성하는지 여부이며, 인간에게 좋은 코드와는 다른 기준일 수 있습니다. 가까운 미래에는 별도의 에이전트가 밤새 코드를 리팩터링하면서, 당장의 문제를 해결하는 데 그치지 않고 전체 구조의 개선 기회를 찾게 할 수도 있습니다. AI 지원 개발의 처음부터 배포까지 어떤 작업 흐름이 적절한지 아직 많이 실험하는 중입니다. 유지보수성과 가독성을 높이는 자동 야간 리팩터링도 그 흐름에 포함될 수 있습니다. 다만 AI가 긴 파일과 반복 코드에서 더 잘 작동하는지, 짧은 파일과 함수에서 더 잘 작동하는지는 아직 분명하지 않습니다. Java보다 학습 데이터가 적은 Go에서 ‘먼 곳의 코드가 예기치 않게 영향을 주는 현상’을 줄이는 방식이 더 나은지도 알 수 없습니다. 하위 클래스가 다시 사용되지 않는지도 질문으로 남습니다.
  • @dulaku — 제가 이해하기로 LLM이 경험적으로 접근하기 쉬운 코드를 만드는 조건은 사람이 접근하기 쉬운 코드의 조건과 같습니다. 좋은 문서, 일관된 구조와 스타일, 견고한 테스트 모음, 널리 알려진 관용구 등이 해당합니다. 이론적으로도 코드 유지보수 벤치마크와 학습 과제 상당수는 인간의 활동에서 파생되므로, 모델은 인간이 하는 일을 모방하는 법을 배우게 됩니다. 두 관점을 합치면 AI가 유지보수하기 좋은 코드를 만들려면 인간이 유지보수하기 좋은 코드를 만들 때와 같은 결정을 내려야 한다는 예상이 합리적입니다.
  • @Corbin — 알고리즘의 계산 복잡도나 코드 줄 수처럼 객관적으로 측정할 수 있는 기준도 있습니다. 챗봇은 이런 기준에서도 나쁜 코드를 자주 만듭니다. 이유는 설명하기 쉽습니다. 챗봇의 출력은 정의상 평균적인 수준이고, 현실에 존재하는 코드의 중간값도 계산 복잡도가 나쁘기 때문입니다.
  • @atmosx — 성과를 수치화하려는 관리자에게 이런 지표는 중요하지 않다고 설명하는 데 지난 20년을 쓰지 않았습니까?
  • @mtset — 그런 지표가 개별 개발자의 성과를 측정하지 못한다고 말해온 것이라고 생각합니다. 장황함과 복잡성에는 최적 범위가 있다는 데 동의하지 않을 사람은 없다고 봅니다.
  • @atmosx — 장황함과 복잡성에 최적 범위가 있다는 데 동의하지 않을 사람은 없다고 하셨습니다. 당연한 말이고 상식입니다.
  • @mtset — 그렇다면 바로 위 댓글에 답글을 단 이유는 무엇입니까?
  • @darth-cheney — 현실의 코드가 복잡도 면에서 나쁘기 때문에 챗봇의 출력도 정의상 평균적인 수준이라면, 같은 종류의 코드가 더 많이 쌓이는 미래에는 어떤 일이 생깁니까?
  • @hyperpape — 아무 일도 생기지 않습니다. 현재 LLM이 작동하는 방식은 더 이상 그것과 같지 않기 때문입니다. 여러 연구소가 사후 학습 과정에서 시뮬레이션 환경의 코딩 테스트를 강화학습에 사용하고 있습니다. 출력이 짧도록 보상을 주는 일은 쉽습니다. 계산 복잡도는 더 까다롭지만 측정해서 보상 신호에 넣을 수 있습니다. 출력 길이와 실행 시간이 강화학습 환경에서 이미 일부 학습되고 있을 가능성도 있다고 봅니다. 다만 “가능한 한 짧은 코드를 작성하라”고 가르치면 모든 코드를 코드 골프처럼 만들게 되고, 지금보다 더 나빠집니다. 합리적인 객관 지표라면 모델이 그 지표를 추구하도록 가르칠 수 있을 가능성이 큽니다. 다만 그 지표를 지나치게 밀어붙이는 일이 좋은지는 별개의 문제입니다.
• @Sanity — LLM 지원 코딩의 좋은 부분을 얻으면서도 그 과정에서 쌓은 지혜를 잃지 않는 방법을 다룬 글이 흥미로웠습니다. 링크된 글은 LLM과 함께 프로그래밍을 계속 즐기는 방법을 이야기합니다. 다만 그렇게 하려면 절제가 필요해 보입니다. LLM의 슬롯머신 이론이 틀렸기를 바랍니다.

원문: alexn.org / 번역·요약: Trawling