AI 코딩이 만든 나쁜 코드를 어떻게 예방하고 개선할까?

TL;DR

AI 코딩의 성과를 높이려면 요구사항을 충분히 질문하고, 프로젝트 용어를 통일하며, 테스트를 먼저 작성해야 한다. 복잡한 구현은 단순한 인터페이스 뒤의 깊은 모듈로 묶고, 사람은 인터페이스와 시스템 설계를 책임져야 한다. 발표자의 결론은 AI가 좋은 코드베이스에서는 잘 작동하지만 변경하기 어려운 코드베이스를 스스로 구해내지는 못한다는 것이다.

Transcript

코드는 더 이상 비싸지 않다. 요즘 AI 업계 분위기가 이거였거든요. 근데 한 사람이 무대에 올라와서 정 반대로 외쳤습니다. 코드는 싸지 않다. 오히려 나쁜 코드는 그 어느 때보다 비싸다.이 한마디로 일주일 만에 40만 명을 끌어 모았어요. 그 사람이 정리한 AI 시대 여섯 가지 함정과 여섯 가지 처방 18분짜리 발표를 핵심만 추려서 정리해 드립니다. 특히 클로드 코드 쓰시는 분들한테 와닿을 한 마디가 있어요. 발표자가 이런 말을 했거든요. AI는 자기가 만든 미로에서 자기가 길을 잃는다. 이게 무슨 말인지 영상 중반에 풀어 드릴게요. 먼저 한 가지 미리 알려 드릴게요.이 영상에는 중간중간 발표자 본인 영상이 1분에서 ... Read More

Key Insights

• 발표자는 변경하기 어려운 나쁜 코드가 AI의 생산성 이점을 막기 때문에 이전보다 더 큰 비용을 만든다고 주장한다.
• 요구사항 구현 전에 AI가 설계 결정과 의존성을 끝까지 질문하게 하면 사람과 AI 사이의 이해 차이를 줄일 수 있다.
• 코드베이스의 핵심 용어를 마크다운 사전으로 정리하면 사람과 AI가 같은 개념을 같은 이름으로 다룰 수 있다.
• 테스트를 먼저 작성하면 AI가 한꺼번에 많은 코드를 생성하지 못하고 검증 가능한 작은 단계로 작업하게 된다.
• 피드백 속도는 개발 속도의 상한선이므로 AI도 타입 검사와 테스트가 확인할 수 있는 범위를 넘어 구현해서는 안 된다.
• 작은 모듈과 복잡한 인터페이스가 많은 구조에서는 AI가 의존성을 놓치거나 수정할 모듈을 잘못 선택할 수 있다.
• 깊은 모듈은 많은 기능을 단순한 인터페이스 뒤에 숨겨 AI가 탐색해야 할 경로와 사람이 검토할 표면을 줄인다.
• 회색 상자 전략에서는 사람이 인터페이스와 경계를 설계하고 AI에 내부 구현을 맡기되 중요한 모듈은 직접 검토한다.

Questions & Answers

Q: AI가 의도와 다른 기능을 만들지 않게 하려면 어떻게 해야 하나요?

구현을 시작하기 전에 AI가 계획의 모든 측면을 질문하도록 해야 합니다. 발표자가 소개한 방식은 설계 결정의 각 갈래를 따라가며 결정 사이의 의존성을 하나씩 해결하고, 사람과 AI가 같은 이해에 도달한 뒤 결과를 제품 요구사항 문서나 작업 이슈로 전환하는 것입니다.

Q: 발표자가 기본 계획 모드보다 질문 중심 방식을 선호하는 이유는 무엇인가요?

발표자는 기본 계획 모드가 결과물을 너무 빨리 만들려는 경향이 있다고 봅니다. 반면 질문 중심 방식은 구현 전에 수십 개의 질문을 던질 수 있으며, 설계 의도와 선택의 근거를 먼저 맞춘다는 점에서 더 낫다고 개인적인 견해를 밝혔습니다.

Q: AI의 장황하고 일관성 없는 표현을 어떻게 줄일 수 있나요?

코드베이스에서 실제로 사용하는 용어를 추출해 사람과 AI가 함께 보는 마크다운 사전을 만들 수 있습니다. 도메인의 같은 개념을 매번 같은 단어로 부르게 하면 표현의 흔들림을 줄이고, 코드와 요구사항이 서로 다른 의미로 해석되는 문제를 완화할 수 있습니다.

Q: AI 코딩에서 테스트 주도 개발이 중요한 이유는 무엇인가요?

테스트를 먼저 작성하면 AI가 검증 없이 큰 기능을 한꺼번에 구현하지 못하고 작은 단계로 움직이게 됩니다. 각 단계에서 테스트와 타입 검사의 피드백을 받을 수 있으므로, 많은 코드를 만든 뒤에야 오류를 발견하는 상황을 줄이는 데 도움이 됩니다.

Q: 피드백 속도가 AI 개발의 속도 제한이라는 말은 무슨 뜻인가요?

AI가 테스트나 타입 검사로 확인할 수 있는 범위보다 빠르게 코드를 만들면 오류가 누적될 수 있다는 뜻입니다. 발표자는 이를 헤드라이트가 비추는 거리보다 빠르게 달리는 상황에 비유하며, 검증 가능한 작은 단위 안에서 진행해야 한다고 설명합니다.

Q: 얕은 모듈이 AI의 코드 탐색을 어렵게 만드는 이유는 무엇인가요?

얕은 모듈은 기능은 적으면서 인터페이스와 연결 관계가 복잡해질 수 있기 때문입니다. 작은 모듈이 많이 흩어지면 AI가 의존성을 끝까지 추적하지 못하거나 적절한 모듈에 제때 도달하지 못해, 잘못된 곳을 수정하고 다른 부분에 오류를 만들 수 있습니다.

Q: 코드베이스를 깊은 모듈 구조로 개선하려면 어떻게 해야 하나요?

먼저 코드베이스를 탐색해 서로 관련된 기능과 아키텍처 코드를 찾고, 이를 하나의 경계 안에 묶어 단순한 인터페이스를 제공해야 합니다. 복잡한 구현은 내부에 숨기고 외부 진입점을 신중하게 설계하면 AI가 탐색해야 할 구조를 줄일 수 있습니다.

Q: 회색 상자 전략에서 사람과 AI의 역할은 어떻게 나뉘나요?

사람은 모듈의 인터페이스와 시스템 경계를 직접 설계하고, AI는 그 안쪽 구현을 맡습니다. 사람은 주로 인터페이스 단위로 결과를 검증하지만, 금융처럼 중요한 모듈에는 이 원칙을 그대로 적용하지 않고 내부 구현까지 모두 살펴봐야 합니다.

Q: 왜 AI 시대에도 소프트웨어 설계에 매일 투자해야 하나요?

부분적인 요구사항 수정과 코드 재생성을 반복하면서 전체 설계를 돌보지 않으면 소프트웨어 엔트로피가 커질 수 있기 때문입니다. 발표자는 설계 투자를 줄이는 접근이 코드베이스를 점차 변경하기 어렵게 만들며, AI의 이점도 제한한다고 주장합니다.

Q: AI 코딩에서 개발자는 어떤 역할을 맡아야 하나요?

개발자는 AI가 수행하는 개별 코드 변경보다 높은 수준에서 시스템 전략과 설계를 책임져야 합니다. 발표자는 AI를 현장에서 전술적 변경을 수행하는 병장에 비유하고, 사람은 인터페이스와 구조를 판단하는 전략가가 되어야 한다고 설명합니다.

Summary & Key Takeaways

• AI가 의도와 다른 결과를 만드는 원인은 사람과 AI 사이에 설계 개념이 충분히 공유되지 않기 때문이다. 발표자는 AI가 결과물을 서둘러 만들기 전에 설계 결정의 각 갈래와 의존성을 끈질기게 질문하게 하고, 그 대화를 제품 요구사항 문서나 작업 이슈로 전환하라고 제안한다.

• AI의 장황함과 실행 오류에는 공통 언어와 짧은 피드백 루프가 필요하다. 코드베이스에서 사용하는 용어를 추출해 사람과 AI가 함께 보는 사전을 만들고, 테스트를 먼저 작성해 작업 단위를 작게 제한하면 타입 검사나 테스트가 제공하는 피드백 범위 안에서 구현을 진행할 수 있다.

• 작은 모듈과 복잡한 인터페이스가 늘어나면 AI도 의존성을 추적하지 못한다. 관련 기능을 단순한 인터페이스 뒤의 깊은 모듈로 묶고, 사람은 인터페이스를 설계하며 구현은 AI에 위임하는 회색 상자 전략이 대안이다. 단, 금융처럼 중요한 모듈은 내부까지 검토해야 한다.