The Hard Part of AI Coding Isn’t Using AI. It’s Knowing When Not to Trust It.

개요

AI 코딩 도구의 발전으로 개발 워크플로우 전반에 AI를 활용할 수 있게 되었으나, AI가 생성한 결과의 신뢰성을 판단하고 올바르게 적용하는 것이 개발자의 핵심 역량으로 부상하고 있다.

주요 내용

* AI의 함정: 그럴듯한 결과와 실제 정확성의 차이
* AI 코딩 도구는 깔끔하고 자신감 있는 코드, 설명, 주석을 생성하여 결과가 올바른 것처럼 보이게 할 수 있다.
* 하지만 AI는 API 메서드를 잘못 만들거나, 오래된 설정을 사용하거나, 라이브러리 버전을 오해하거나, 엣지 케이스를 무시하거나, 보안 검사를 약화시키거나, 근본적인 버그 대신 증상만 수정하는 등의 오류를 범할 수 있다.
* 특히 즉각적으로 애플리케이션을 충돌시키지 않는, 겉보기에는 정상 작동하는 것처럼 보이는 실패가 더 위험하며, 인증 우회, 개발 DB와 실제 DB에서의 마이그레이션 실패, 잘못된 가정을 기반으로 통과하는 테스트 등이 이에 해당한다.

* 철저한 검증은 필수적인 개발 워크플로우의 일부
* AI가 생성한 라이브러리 기능, 인증 코드 변경, SQL 마이그레이션, 종속성 추가 등에 대해 반드시 문서를 확인하고, 보안 영향을 검토하며, SQL을 읽고, 테스트를 실행하고, 변경 사항을 확인해야 한다.
* AI 생성 코드는 동료가 작성한 코드와 동일하거나 더 높은 수준의 검토를 받아야 하며, AI는 결과에 대한 책임을 질 수 없기 때문이다.
* 인간 팀원은 결정의 배경을 설명하고 요구사항 변경을 기억하며 사용자 경험을 고려할 수 있지만, AI는 사후 생성된 설명만을 제공할 뿐이다.
* 인증, 권한 부여, 결제, 파괴적 작업, 개인 데이터, 인프라, DB 스키마, 프로덕션 구성 등 위험도가 높은 변경 사항에는 더 많은 주의가 필요하며, "좋아 보인다"는 것을 증거로 받아들이기 어렵다.

* 테스트 통과가 잘못된 자신감을 유발할 수 있음
* AI가 생성한 구현과 동일한 기대를 확인하는 테스트는 유용하지만, AI의 기대치가 제품 요구사항과 일치함을 증명하지는 못한다.
* 동일한 모델이 구현과 테스트를 모두 작성할 경우, 요구사항에 대한 오해가 공유될 수 있다. 예를 들어, "계정 소유자만 프로젝트를 삭제할 수 있다"는 요구사항을 AI가 "인증된 모든 사용자"로 해석하여 테스트를 통과시킬 수 있다.
* 좋은 검증은 단순히 테스트가 통과하는지 여부를 넘어, 테스트가 실제 요구사항을 반영하는지, 실패 경로가 포함되는지, 다양한 사용자 역할 관점에서 권한이 테스트되는지, 경계 조건이 포함되는지, 구현이 미묘하게 약화되었을 때 테스트가 실패하는지, 기존 테스트가 제거 또는 변경되지 않았는지 등을 확인해야 한다.

* 기술적으로 정확해도 잘못된 솔루션이 될 수 있음
* AI 생성 솔루션이 기술적으로 유효하더라도 프로젝트에 적합하지 않을 수 있다. 불필요한 상태 관리 라이브러리 도입, 복잡한 추상화로의 대체, 배포 환경과 비호환되는 종속성 사용, 코드 이해도를 크게 떨어뜨리는 성능 문제 해결 등이 해당된다.
* AI 모델은 종종 아무것도 변경할 필요가 없다는 결론 대신, 변경을 제안하는 경향이 있으며, 리팩토링을 요청하면 원본 코드가 완벽했더라도 리팩토링 결과를 받을 가능성이 높다.
* 좋은 엔지니어링은 가장 정교한 솔루션을 선택하는 것이 아니라, 문제에 의해 복잡성이 정당화되는 솔루션을 선택하는 것이다. AI는 옵션을 제안할 수는 있지만, 트레이드오프를 책임질 수는 없다.

* AI 도구 선택에도 판단력이 요구됨
* 새로운 코딩 AI 도구가 계속 출시되지만, 모든 도구를 쫓을 필요는 없다. 일부 도구는 유용하지만, 특정 맥락에서만 뛰어나거나, 개발 워크플로우를 재구성한 후 사라질 수도 있다.
* 코드 탐색에 뛰어난 모델, 인터페이스 생성에 능숙한 모델, 백엔드 진단에 어려움을 겪는 모델, 전문 검토 에이전트 등이 있으며, 최적의 워크플로우는 여러 도구를 조합하거나 단일 도구를 신중하게 사용하는 것일 수 있다.
* 목표는 가능한 가장 큰 AI 스택을 조립하는 것이 아니라, 엔지니어링 판단이 필요한 결정에 더 많은 주의를 기울일 수 있도록 마찰을 줄이는 것이다.

* 무엇을 위임할지를 아는 것이 핵심 기술로 부상
* AI 지원 프로그래밍과 함께, 어떤 작업을 위임할지를 아는 미묘한 기술이 발전하고 있다.
* 보일러플레이트 코드 생성, 비정형 코드베이스 탐색, 대안 구현 생성, 반복적인 테스트 작성, 오류 메시지에서 가설 목록 생성 등은 AI에게 위임하기 좋은 작업이다.
* 반면, 보안 가정 수용 여부, 프로젝트 규모 및 수명에 맞는 아키텍처 설계, 사용자의 실제 문제 해결, 데이터 수집의 필요성, 새 종속성 유지보수의 가치, 작업 중단 시 영향, 프롬프트 충족 여부 등은 인간의 책임으로 남아야 한다.
* "실행은 자유롭게 위임하고, 판단은 더 신중하게 위임하라"는 규칙은 기계적 작업, 컨텍스트 수집, 가능성 생성, 반복 처리 등은 AI에게 맡기되, 의도, 위험, 트레이드오프, 결과 등은 신중하게 위임해야 함을 시사한다.

* 더 많은 컨텍스트가 항상 올바른 컨텍스트는 아님
* AI 도구는 컨텍스트 수집 능력이 향상되고 있으나, 모든 중요한 요소를 완벽하게 파악하지는 못한다. 저장소는 볼 수 있지만, 특정 기능이 의도적으로 제외된 대화는 보지 못할 수 있다.
* 이슈를 읽을 수는 있지만, 특정 구현이 초래할 지원 부담을 이해하지 못할 수 있으며, 코드의 작동 방식을 알더라도 팀이 그렇게 선택한 이유를 알지 못할 수 있다.
* 넓은 컨텍스트 창(context window)도 이를 완전히 해결하지 못하며, 더 많은 컨텍스트가 곧 올바른 컨텍스트를 의미하지는 않는다.
* 개발자는 기술 환경, 제품 요구사항, 배포 제한, 호환성 기대치, 보안 경계, 변경되면 안 되는 사항 등 중요한 제약 조건을 식별하고 전달해야 한다. AI 도구가 잘못된 결과를 생성하는 것은 종종 불충분한 작업 지시와 그로 인한 AI의 가정 때문일 수 있다.

* 자신감보다는 변경 사항 자체를 검토해야 함
* AI 에이전트는 종종 "문제가 해결되었습니다" 또는 "모든 테스트가 통과합니다"와 같은 확신에 찬 선언으로 작업을 요약하지만, 이는 검증해야 할 보고서로 간주해야 한다.
* 실제 diff, 변경된 파일, 관련 없는 수정 사항, 기존 동작의 제거 여부, 구성 변경, 테스트 약화, 하드코딩된 값, 무음 오류 처리, 광범위한 권한, 불필요한 종속성, 자리 표시자 논리 등을 철저히 검사해야 한다.
* 요약의 자신감은 코드의 정확성과는 무관하며, 아름답게 설명된 실수도 여전히 실수이다.

* 개발자의 역할은 변화하는 것이지 사라지는 것이 아님
* AI 지원 코딩은 개발자를 불필요하게 만들지 않으며, 오히려 그들의 주의가 가장 가치 있는 곳으로 전환된다.
* 예측 가능한 코드를 처음부터 작성하는 데 드는 시간은 줄어들고, 동작 정의, 컨텍스트 제공, 대안 평가, 변경 사항 검토, 검증 설계, 구축 대상 결정 등에 더 많은 시간을 할애하게 된다.
* 이는 덜 중요한 개발 형태가 아니라, 시스템 이해, 제약 조건 식별, 트레이드오프 관리, 실패 모드 예측, 사용자에게 도달하는 것에 대한 책임 등 실제 작업이 포함된다.
* AI는 코드 생산을 가속화할 수 있지만, 배포 결과에 대한 책임은 개발자에게 있다.

* 더 빠른 코딩에는 더 나은 제동 장치가 필요함
* AI 지원 코딩은 AI가 기계적 작업을 처리하고 인간이 의도, 검증, 결과에 대한 소유권을 유지할 때 가장 효과적이다.
* 이는 생성된 모든 세미콜론을 불안하게 지켜보는 것이 아니라, 작업에 따라 신뢰도를 조정하는 것을 의미한다.
* 실수가 저렴하고 명백한 곳에서는 AI를 자유롭게 사용하고, 오류가 숨겨지거나 심각한 피해를 줄 수 있는 곳에서는 검토를 강화해야 한다.
* 테스트, 린터, 타입 검사, 문서화, 코드 검토, 격리된 환경 등은 생성 후의 의례적인 단계를 넘어 검증 시스템의 일부로 활용되어야 한다.
* 무엇보다 중요한 것은 AI 도구와 의견이 다를 수 있는 능력을 유지하는 것이다. AI 사용 여부에 대한 논쟁은 이미 현실에 의해 추월되었으며, 더 중요한 질문은 AI를 충분히 잘 사용함으로써 빠른 코딩이 곧 빠른 실수가 되지 않도록 할 수 있는지 여부이다. AI는 빠르게 움직이도록 도울 수 있지만, 엔지니어링 판단은 언제 속도를 늦춰야 하는지를 알려준다.

시사점

AI 코딩 도구는 개발 생산성을 높이는 강력한 도구이지만, AI가 생성한 결과물에 대한 비판적 사고와 철저한 검증 없이는 오히려 심각한 오류를 야기할 수 있으므로, 개발자는 AI의 강점을 활용하되 결과에 대한 최종 책임과 판단 권한을 명확히 가져야 한다. AI 활용 능력의 핵심은 위임할 것과 위임하지 않을 것을 구분하는 판단력에 있으며, 이는 개발자의 역할이 사라지는 것이 아니라 더 전략적인 방향으로 변화함을 의미한다.