AI의 문제일까?
"ChatGPT한테 로그인 기능 만들어달라고 했는데, 이상한 코드를 줬어요."
최근 이런 불평을 자주 듣습니다. GitHub Copilot, ChatGPT, Claude... AI 도구들이 쏟아지고 있지만, 정작 프로덕션에 쓸 만한 코드는 나오지 않는다는 거죠.
AI가 문제일까요? 아닙니다.
문제는 우리가 AI와 대화하는 방식에 있습니다.
실제 사례를 보겠습니다.
개발자의 요청은 "로그인 기능 만들어줘"였습니다.
AI의 결과는 username과 password를 받아서 "admin"과 "password"가 맞으면 success를 반환하고, 아니면 failed를 반환하는 간단한 함수였습니다.
개발자의 반응은 "이게 뭐야? AI 별로네..."였습니다.
잠깐, 여기서 누가 잘못한 걸까요?
신입 개발자에게 "로그인 기능 만들어"라고만 지시하면 어떻게 될까요?
아마 이런 질문들이 돌아올 겁니다. "어떤 프레임워크 쓰나요?", "DB는 뭐 쓰나요?", "세션? JWT?", "소셜 로그인도 되나요?", "비밀번호 규칙이 있나요?"
그런데 AI는 질문을 하지 않습니다. 그냥 가장 일반적인 답을 줄 뿐입니다.
컴퓨터 공학의 오래된 격언이 있습니다.
"쓰레기를 넣으면 쓰레기가 나온다"
AI 시대에는 이렇게 바뀌었습니다:
"모호한 요청을 넣으면 모호한 코드가 나온다"
실제 테스트 결과를 보겠습니다.
테스트 1은 모호한 요청으로 "사용자 관리 기능 만들어줘"라고 했을 때 기본 CRUD 스켈레톤 30줄이 나왔고, 실용성은 10%였습니다.
테스트 2는 구체적인 요청으로 "Django REST Framework로 사용자 관리 API 만들어줘. 이메일 인증, JWT 토큰, 권한 그룹(admin, user), 프로필 이미지 업로드, 소프트 삭제, 페이지네이션"이라고 했을 때 완성도 높은 코드 500줄이 나왔고, 실용성은 85%였습니다.
차이가 보이시나요?
AI는 컨텍스트의 노예입니다. 우리가 제공한 정보만큼만 이해하고 구현합니다.
좋은 프롬프트의 구조는 배경 설명(프로젝트 종류, 기술 스택, 제약 사항), 구체적 요구사항(기능 목록, 비기능 요구사항, 엣지 케이스), 예시나 참고 자료(비슷한 코드, API 문서 링크, 원하는 출력 형식)입니다.
나쁜 요청은 "결제 기능 만들어줘"입니다.
좋은 요청은 Node.js Express 서버에서 Stripe를 사용한 결제 시스템을 구현해달라고 하며, 요구사항으로 카드 결제(일회성), 구독 결제(월간/연간), 웹훅으로 결제 상태 업데이트, 실패 시 재시도 로직(3회), 결제 내역 조회 API, 환불 처리를 명시하고, 기술 스택으로 Node.js 18+, Express 4, TypeScript, Stripe API v2023, PostgreSQL을 명시하며, 에러 처리로 카드 거절, 잔액 부족, 네트워크 타임아웃, 중복 결제 방지를 명시하고, 보안으로 API 키 환경변수, 웹훅 서명 검증, Rate limiting, SQL Injection 방어를 명시합니다.
이렇게 요청하면 실제로 사용 가능한 코드가 나옵니다.
AI가 잘하는 것은 보일러플레이트 코드(CRUD 기본 구조, 설정 파일, 테스트 템플릿), 알고리즘 구현(정렬, 검색, 데이터 변환, 수학적 계산), 문서화(주석 추가, README 작성, API 문서), 리팩토링(코드 정리, 네이밍 개선, 중복 제거)입니다.
AI가 못하는 것은 비즈니스 로직 이해(도메인 특화 규칙, 회사별 정책, 암묵적 요구사항), 아키텍처 결정(확장성 고려, 성능 최적화, 기술 부채 관리), 창의적 문제 해결(새로운 알고리즘, 혁신적 접근, 특수한 최적화)입니다.
AI를 주니어 개발자로 생각하고 협업하세요.
Step 1은 큰 그림 설명입니다. "우리는 이커머스 플랫폼을 만들고 있어. 주요 기능은 상품 관리, 주문, 결제야. 기술 스택은 Next.js + NestJS + PostgreSQL이고."라고 설명합니다.
Step 2는 구체적 태스크 분할입니다. "먼저 상품 관리 API를 만들 거야. 1. 상품 CRUD, 2. 카테고리 관리, 3. 재고 추적, 4. 이미지 업로드"라고 나눕니다.
Step 3은 하나씩 구현입니다. "상품 생성 API부터 시작하자. POST /api/products, 요청 본문: {name, price, category_id, stock}, 검증: 가격 > 0, 재고 >= 0, 응답: 201 Created with product object"라고 구체적으로 요청합니다.
Step 4는 점진적 개선입니다. "좋아, 이제 여기에 트랜잭션 추가해줘", "에러 핸들링 개선해줘", "단위 테스트 작성해줘"라고 점진적으로 개선합니다.
여기서 WBS(Work Breakdown Structure)가 빛을 발합니다.
WBS로 작업을 잘게 나누면, 각 작업이 AI가 이해하기 쉬운 크기가 됩니다.
WBS 없이 AI 사용은 "쇼핑몰 만들어줘" → AI: "???"(쓸모없는 코드)입니다.
WBS로 분해 후 AI 사용은 사용자 인증을 1.1 회원가입 API(1.1.1 이메일 중복 체크, 1.1.2 비밀번호 암호화, 1.1.3 인증 메일 발송), 1.2 로그인 API(1.2.1 자격증명 검증, 1.2.2 JWT 토큰 발급, 1.2.3 리프레시 토큰 관리)로 나누면 각 최하위 태스크(1.1.1, 1.1.2...)는 AI가 정확히 구현할 수 있는 크기입니다.
제가 실제로 사용하는 템플릿입니다. 컨텍스트로 프로젝트명, 현재 작업(WBS 번호 및 설명), 기술 스택(언어, 프레임워크, DB)을 명시하고, 요구사항으로 기능 요구사항과 비기능 요구사항(성능, 보안, 확장성)을 명시하며, 제약사항으로 기존 코드와의 호환성, 외부 API 제한, 라이브러리 버전을 명시하고, 예상 입출력으로 입력 예시 데이터와 출력 예상 결과를 명시하고, 참고 코드로 기존 코드나 비슷한 예시를 제공합니다.
이 템플릿을 사용하면 AI의 정확도가 3배는 올라갑니다.
ChatGPT는 장점이 설명 잘함, 다양한 언어이고, 단점이 최신 정보 부족이며, 용도는 개념 설명, 알고리즘입니다.
GitHub Copilot은 장점이 IDE 통합, 컨텍스트 이해이고, 단점이 짧은 코드만이며, 용도는 자동완성, 보일러플레이트입니다.
Claude는 장점이 긴 코드, 정확도 높음이고, 단점이 보수적이며, 용도는 복잡한 로직, 리팩토링입니다.
Cursor는 장점이 코드베이스 전체 이해이고, 단점이 유료이며, 용도는 대규모 리팩토링입니다.
AI가 개발자를 대체할까요? 절대 아닙니다.
AI는 힘을 증폭시키는 도구입니다. 망치가 목수를 대체하지 못하듯, AI도 개발자를 대체하지 못합니다.
다만, AI를 잘 쓰는 개발자가 못 쓰는 개발자보다 10배는 생산적일 겁니다.
핵심은 명확한 요구사항입니다.
WBS로 작업을 잘게 나누고, 각 작업을 명확히 정의하면, AI는 놀라운 생산성 도구가 됩니다.
"AI가 코드를 못 짠다"고 불평하기 전에, 우리가 요구사항을 제대로 전달했는지 돌아봐야 합니다.
Garbage In, Garbage Out.
명확한 입력, 명확한 출력. 이게 AI 시대의 개발 방법론입니다.
AI와 함께 효율적인 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.