비판적 페르소나를 통한 요구사항 검증 (Maja Bilić)

구글 클라우드의 시니어 아웃바운드 프로덕트 매니저 Maja Bilić은 AI 모델에게 코드를 작성하도록 지시하는 대신, 모델이 자신의 기획에 대해 논리적으로 반박하게 만드는 대립적 구조를 설계한다. 이 기법은 모델에게 냉소적인 수석 아키텍트이자 기술 PM(프로덕트 매니저)이라는 구체적인 페르소나를 부여하는 것에서 시작한다. 모델은 이 설정 아래에서 코드 작성이라는 본연의 기능을 일시적으로 금지당하며, 대신 제안된 아이디어가 가진 기술적, 사용자 경험(UX), 아키텍처적 고려사항을 나열해야 한다. 이후 모델은 각 항목에 대해 날카로운 질문을 던지며 사용자와 상호작용한다.

이 과정은 모델이 단순히 코드를 생성하는 도구가 아니라, 기획의 허점을 지적하는 비판적 검토자로 기능하게 만든다. 사용자는 모델과의 대화를 통해 요구사항의 모호함을 제거하고, 기획의 완성도를 실질적으로 높일 수 있다. 특히 모델이 과도한 엔지니어링이나 지나친 단순화에 빠지지 않도록 제약 조건을 설정하는 것이 핵심이다. 이러한 상호작용이 종료된 후, 모델은 논의된 내용을 바탕으로 정제된 요구사항 문서와 구현 계획을 작성한다. 이는 AI가 제시한 계획을 최종 결정으로 받아들이는 대신, 여러 선택지 중 하나로 인식하게 하여 인간이 의사결정의 주도권을 유지하도록 돕는다.

이 기법은 AI와 기술적 의사결정을 내릴 때 발생하는 전형적인 실패 모드를 방지한다. 모델이 내놓는 자신감 넘치고 정형화된 계획은 종종 검증이 끝난 정답처럼 느껴지기 쉽지만, 비판적 페르소나를 도입하면 모델 스스로가 자신의 제안에서 무엇을 포기하고 있는지, 어떤 트레이드오프(상충 관계)를 감수하는지를 나열하게 된다. 결과적으로 모델의 답변을 맹신하는 대신, 성능, 비용, 보안, 유지보수 측면의 단점을 강제로 노출하게 함으로써 인간 엔지니어는 더 넓은 시야에서 기술적 선택을 내릴 수 있다. 이러한 방식은 기획 단계에서부터 잠재적인 결함을 식별하고, 구현 이후 발생할 수 있는 재작업 비용을 줄이는 데 기여한다.

테스트 코드 작성이 아닌 테스트 가능성 감사 (Andrew Brogdon)

테스트 코드 생성 요청은 코드베이스의 구조적 결함을 간과한 채 겉면만 덮는 결과를 초래할 수 있다. Andrew Brogdon은 테스트 코드를 직접 작성하게 하는 대신, 모델이 먼저 코드베이스를 분석하여 테스트 가능성(Testability)을 진단하게 하는 방식을 제안한다. 이는 작성된 코드가 테스트를 수행하기에 적합한 구조인지, 혹은 의존성 주입(Dependency Injection, 외부에서 객체를 주입하여 결합도를 낮추는 기법)이 적절히 구현되었는지, 도메인 로직이 느슨하게 결합(Loosely coupled)되어 있는지 확인하는 과정이다.

이 접근법은 테스트 계획 수립, 실행, 검증의 순서를 엄격히 준수한다. 우선 모델은 UI나 로직 중 테스트 커버리지(테스트가 수행된 코드의 비율)가 부족한 공백 영역을 파악한다. 이후 기존 코드의 구조를 평가하여 테스트 가능한 상태인지 진단하고, 모든 준비가 완료된 이후에야 실제 테스트 계획을 수립하고 실행한다. 이 방식은 단순히 코드를 생성하는 것보다 한 단계씩 신중하게 접근하여, 테스트된 코드와 잘 테스트된 코드 사이의 간극을 제거하는 데 목적이 있다.

2022년 GitHub Copilot 연구 결과에 따르면 AI가 생성한 코드의 40%에서 취약점이 포함될 가능성이 제기된 바 있다. 비록 최신 모델의 성능 향상에 따른 구체적인 취약점 비율 변화 수치는 확인되지 않았으나, 이러한 감사 중심의 워크플로우는 AI가 생성한 코드의 신뢰성을 확보하는 실질적인 방안이 된다. 테스트 가능성 감사는 코드 작성 전 단계에서 아키텍처의 결합도를 점검함으로써, 향후 발생할 수 있는 유지보수 비용을 사전에 차단하는 효과를 낸다.

이러한 워크플로우를 소규모 작업 추적 REST API 프로젝트에 적용하면, 모델은 테스트 작성을 서두르지 않고 먼저 코드의 구조적 결함을 찾아낸다. 모델에게 테스트 코드를 즉시 생성하라고 지시하는 대신, 코드베이스 내의 의존성 관계와 테스트 가능성을 먼저 감사하도록 프롬프트를 구성해야 한다. 결과적으로 모델은 코드의 품질을 평가한 뒤, 테스트 계획을 제안하고 검증하는 과정을 거쳐 더 견고한 결과물을 도출하게 된다.

리뷰 품질을 결정짓는 컨텍스트 분리 전략 (Aja Hammerly)

Aja Hammerly는 코드 리뷰를 요청하기 전, 개발 맥락이 포함되지 않은 별도의 대화 세션에서 두 단계의 좁은 범위 프롬프트를 실행하는 방식을 채택한다. 통합된 대화창에서 리뷰를 진행할 경우 모델이 초기 설정에 동조하거나 모호한 피드백을 내놓는 경향을 방지하기 위함이다. 첫 번째 프롬프트는 기존 테스트를 실행한 뒤, 시스템의 안정성을 위협하는 엣지 케이스(Edge Case, 예외적인 상황)와 레이스 컨디션(Race Condition, 여러 프로세스가 자원에 동시에 접근해 결과가 꼬이는 현상)을 집중적으로 탐색하도록 설계한다.

두 번째 프롬프트는 코드의 기능적 결함이 아닌, 개발 과정에서 누적된 잔여물을 정리하는 데 집중한다. 여기에는 미사용 코드, 디버그 주석, 코드 내용과 일치하지 않는 주석, 그리고 해결되지 않은 TODO 리스트 등이 포함된다. 기능 구현에 몰두하는 동안 코드베이스에 쌓이는 사소한 흔적들을 별도의 세션에서 걸러냄으로써, 리뷰의 정밀도를 극대화하는 전략이다. 이러한 방식은 코드가 단순히 실행 가능하다는 점과 실제로 견고하다는 점 사이의 간극을 명확히 드러낸다.

2022년 GitHub Copilot 연구 결과에 따르면, 보안 관련 시나리오 89개에서 생성된 프로그램 1,689개 중 약 40%가 실제 취약점을 포함하고 있었다. AI가 작성한 코드는 컴파일 과정에서 오류가 발생하지 않고 육안으로 보기에 자연스럽기 때문에, 일반적인 버그 검토 요청만으로는 이러한 잠재적 위험을 발견하기 어렵다. 따라서 모델에게 구체적인 실패 조건을 포함한 평가 기준을 제시하고, 이를 바탕으로 코드의 파괴 가능성을 검증하게 하는 것이 단순한 코드 생성보다 실질적인 계획 수립 가치를 높인다.

이러한 구조적 검토 방식은 모델이 단순히 사용자의 의견에 동의하는 것을 넘어, 회의적인 페르소나를 가진 비평가로서 실제 반론을 생성하게 만든다. 개발자가 구현 계획을 세울 때 모델이 첫 번째 프레임에 순응하는 대신, 비판적인 시각으로 객관적인 결함을 찾아내도록 유도하는 것이 이 전략의 핵심이다. 결과적으로 개발자는 코드의 기능적 완성도와 함께 유지보수 과정에서 간과하기 쉬운 기술적 부채를 체계적으로 관리할 수 있다.

보안 및 권한 설정을 위한 교차 검증 패턴 (Rich Hyndman)

안드로이드 매니페스트 파일(Android Manifest)에 선언된 권한과 실제 코드 내 사용량 사이의 불일치를 찾아내는 작업은 애플리케이션 보안의 핵심이다. Rich Hyndman은 모든 빌드 변형(Build Variants)에서 매니페스트 파일을 추출하고, 선언된 권한 목록을 코드베이스 내 실제 API 호출과 대조하여 불필요한 권한을 식별하는 감사 루틴을 제안한다. 이 과정은 단순히 권한을 나열하는 데 그치지 않고, 런타임 권한 흐름(Runtime Permission Flows)이 올바르게 구현되었는지와 하드웨어 기능 선언이 실제 요구사항과 일치하는지 확인하는 단계를 포함한다.

이 루틴의 핵심은 계획이 승인되기 전까지 코드를 수정하지 않는다는 제약 조건에 있다. 이는 AI의 제안을 즉각적인 자동 수정 도구로 활용하는 대신, 보안 정책과 구현 사이의 간극을 먼저 파악하는 검증 단계로 활용하기 위함이다. 해당 패턴은 안드로이드 환경을 넘어 환경 변수(Environment Variables), API 범위 승인(API Scope Grants), IAM(Identity and Access Management, 클라우드 자원 접근 권한 관리) 역할 할당 등 모든 설정 영역에 동일하게 적용할 수 있다. 모든 선언 위치를 식별하고 실제 사용량과 교차 검증하여 차이점을 보고한 뒤, 수정안을 제안받고 승인을 대기하는 구조는 보안 감사 루틴의 표준화된 모델을 제공한다.

이러한 교차 검증 패턴은 불필요한 권한 노출을 최소화하고 코드베이스의 복잡도를 낮추는 효과를 낸다. 개발자는 AI를 단순한 코드 생성 도구가 아닌, 설정 파일과 실제 구현의 정합성을 검토하는 보안 파트너로 활용하게 된다. 특히 IAM 역할이나 API 스코프와 같이 설정 오류가 보안 사고로 직결될 수 있는 영역에서, 이 루틴은 인간이 놓치기 쉬운 선언과 사용의 불일치를 체계적으로 걸러낸다. 결과적으로 이 워크플로우는 코드 수정 전 단계에서 정밀한 감사 과정을 강제함으로써 시스템의 보안성을 한 단계 높이는 역할을 수행한다.

AI의 자기 논리 Stress-test와 등급 평가 (Shir Meir

AI가 생성한 코드 리뷰 결과가 단순히 예의 바른 칭찬이나 일반적인 주석 제안에 그치는 현상은 실무에서 가장 흔히 발생하는 문제다. Shir Meir Lador는 이러한 모호한 피드백을 방지하기 위해 모델에게 엄격한 수석 엔지니어 페르소나를 부여하고, 코드의 생산 준비 상태에 대해 A부터 F까지 등급을 직접 매기도록 강제하는 방식을 제시한다. 모델은 효율성, 회복탄력성, 아키텍처의 견고함이라는 세 가지 기준을 모두 충족하지 못할 경우 A 등급을 부여할 수 없으며, 단순한 의견 제시를 넘어 구체적인 수정안을 반드시 포함해야 한다.

이러한 등급제는 AI의 결과물을 최종 결정이 아닌 여러 선택지 중 하나로 인식하게 하여 인간 엔지니어의 의사결정권을 강화한다. 특히 James O'Reilly는 구현 계획을 수립한 직후 모델에게 자신의 제안이 가진 단점을 성능, 비용, 보안, 유지보수 측면에서 명시하도록 요구하는 방식을 강조한다. 이는 모델이 자신의 논리를 스스로 스트레스 테스트하도록 유도하여, 첫 번째 제안을 무비판적으로 수용할 때 발생하는 잠재적 결함을 사전에 차단하는 핵심 기제다.

실무 환경에서 AI의 제안을 검증할 때는 명확한 평가 기준을 프롬프트에 내재화하는 것이 필수적이다. 단순히 코드를 검토하라고 지시하는 대신, A부터 F까지 등급을 매기게 하고 왜 A가 아닌지 구체적인 결함과 수정안을 요구하는 페르소나 설정을 적용해야 한다. AI의 첫 제안을 무비판적으로 수용하지 않고, 실무적 결함과 보안 취약점을 사전에 걸러낼 수 있는 검증 기준을 확보하는 것이 엔지니어링의 핵심이다.