AI 코딩 (프롬프트, 할루시네이션, 프로토타입)

기획자가 프로토타입을 만드는 현실 가이드

AI가 만든 코드의 완성도는 80~90% 수준이라고 알려져 있습니다. 나머지 10~20%는 사람이 검증해야 한다는 뜻인데, 저는 이 숫자를 처음 접했을 때 솔직히 "그 정도면 충분하지 않나?" 싶었습니다. 직접 써보고 나서야 그 10~20%가 얼마나 위험한 영역인지 알게 됐습니다.

기획자가 처음 AI 코딩을 마주쳤을 때

개발 리소스가 없어서 2주를 기다려야 하는 상황이었습니다. 급하게 필요한 건 간단한 데이터 시각화 대시보드 프로토타입이었고, 반신반의하며 ChatGPT에 "HTML, CSS, JavaScript로 월별 매출 막대 그래프 대시보드를 만들어줘. 하드코딩 데이터로 작동하면 돼"라고 입력했습니다.

5분 후 완전히 동작하는 코드가 나왔습니다. 솔직히 이건 예상 밖이었습니다. 처음엔 반응형 레이아웃이 깨지고 콘솔에 오류도 떴지만, 그 오류 메시지를 그대로 붙여 넣으니 ChatGPT가 다시 수정해줬습니다. 세 번의 수정을 거쳐 2시간 만에 프로토타입이 완성됐습니다. 이 경험 이후로 AI 코딩에 대한 시각이 완전히 바뀌었습니다. "코딩은 개발자만 하는 것"이라는 생각이 조용히 흔들리기 시작한 순간이었습니다.

2025년 기준으로 v0, Bolt, Lovable 같은 노코드·AI 코딩 플랫폼이 빠르게 확산되면서, 비개발 직군도 간단한 프로토타입을 자체 제작하는 흐름이 가속화되고 있습니다. 프론트엔드 채용 공고에서조차 "소규모 컴포넌트 구현은 기획자·디자이너도 AI로 수행 가능"하다는 문구가 등장할 만큼, 패러다임이 바뀐 건 부정할 수 없는 사실입니다.

프롬프트가 곧 기획서다

AI 코딩의 결과물 품질을 좌우하는 건 결국 프롬프트(Prompt)입니다. 프롬프트란 AI에게 작업을 지시하는 입력 텍스트를 의미하는데, 얼마나 구체적으로 맥락을 전달하느냐에 따라 결과물의 수준이 크게 달라집니다.

예를 들어 "로그인 함수를 작성해줘"라는 요청과 "bcrypt와 JWT 인증을 사용하는 Python 로그인 함수를 작성해줘"라는 요청은 결과물이 완전히 다릅니다. JWT(JSON Web Token)란 사용자 인증 정보를 안전하게 전달하기 위해 서버와 클라이언트 사이에서 주고받는 토큰 방식의 인증 표준입니다. 이처럼 기술 스택과 보안 방식까지 명시하면 AI는 훨씬 정확한 코드를 생성합니다.

기획자에게 꽤 유리한 지점이 있습니다. 기능 요구사항, 기술 스택, 예외 처리 범위, 화면 레이아웃을 상세히 적는 작업은 기획자가 매일 하는 스펙 문서 작성과 구조가 거의 같습니다. 사용자 플로우를 정의하고, 예외 케이스를 명시하고, 우선순위를 정하는 기획 역량이 프롬프트 엔지니어링에서도 그대로 힘을 발휘합니다. 생각해보면 저는 이미 프롬프트를 쓰고 있었던 셈입니다. 이 연결고리를 깨달았을 때 "나도 이걸 할 수 있겠다"는 확신이 생겼습니다.

프롬프트 품질에 따라 결과가 달라지는 핵심 요소가 있습니다. 기술 스택 명시가 첫 번째로, 사용할 언어, 프레임워크, 라이브러리를 구체적으로 적을수록 결과가 정확해집니다. 예외 처리 범위를 미리 정의하면 허점이 줄어듭니다. 출력 형식까지 지정하면 재수정 횟수가 감소합니다. 그리고 "bcrypt로 비밀번호를 암호화해줘"처럼 보안 요구사항을 명시하면 취약한 코드를 예방할 수 있습니다.

할루시네이션, 가장 조심해야 할 함정

AI 코딩에서 가장 경계해야 할 현상이 할루시네이션(Hallucination)입니다. 할루시네이션이란 AI가 틀린 정보를 마치 사실인 것처럼 자신감 있게 제시하는 현상을 말합니다. 코드 맥락에서는 존재하지 않는 라이브러리 버전을 태연하게 언급하거나, 보안 취약점이 있는 코드를 정석처럼 내놓는 형태로 나타납니다.

제가 직접 경험한 사례가 있습니다. ChatGPT가 제시한 코드에 특정 npm 패키지의 메서드가 포함돼 있었는데, 실제로 존재하지 않는 API였습니다. 코드 자체는 문법적으로 완벽해 보였고, 설명도 그럴듯했습니다. 만약 제가 그 코드를 이해하지 못한 채 그대로 배포했다면 런타임 오류가 터졌을 겁니다. 이 경험이 "AI를 검증 없이 믿으면 안 된다"는 원칙을 세우게 된 계기였습니다.

XSS(Cross-Site Scripting)와 같은 보안 취약점 문제도 마찬가지입니다. XSS란 악의적인 스크립트를 웹 페이지에 삽입하여 다른 사용자의 정보를 탈취하는 공격 방식인데, AI가 생성한 코드에는 이런 취약점이 무방비 상태로 포함되는 경우가 있습니다. "이 코드에서 보안 취약점이 있으면 알려줘"라고 한 번 더 물어보는 습관을 들인 것도 이 경험 때문입니다.

AI가 만든 코드의 완성도가 80~90% 수준이라는 점은 여러 개발자들 사이에서도 공통적으로 언급되는 수치입니다. 나머지 10~20%를 사람이 검증해야 한다는 말은, 결국 AI가 틀릴 수 있는 영역을 사람이 책임져야 한다는 뜻입니다. 이 책임을 인식하지 못한 채 AI 코딩을 쓰는 게 가장 위험한 패턴이라고 생각합니다.

AI 코딩은 개발자 대체인가, 커뮤니케이션 도구인가

"기획자도 코딩할 수 있다"는 말이 많은 오해를 낳는다고 생각합니다. AI가 생성한 코드가 동작한다는 사실과, 그 코드를 유지보수하거나 확장할 수 있다는 사실은 완전히 다른 이야기이기 때문입니다.

리팩토링(Refactoring)이라는 개념이 있습니다. 리팩토링이란 외부 동작은 그대로 유지하면서 코드의 내부 구조를 개선하는 작업을 말합니다. 프로토타입 단계에서 AI가 만든 코드는 대부분 리팩토링 없이 작성된 상태입니다. 실제 서비스로 전환하는 순간부터 기술 부채(Technical Debt)가 쌓이기 시작하는데, 기술 부채란 빠른 개발을 위해 미뤄둔 코드 개선 작업이 나중에 더 큰 비용으로 돌아오는 현상을 의미합니다. 이걸 나중에 감당하는 건 결국 사람입니다.

더 근본적인 문제는, AI가 자신감 있게 틀린 코드를 제시할 때 기획자는 그것이 틀렸는지 판단할 수단이 없다는 점입니다. AI 코딩 교육이 생산성만 강조하고 리스크 인식을 소홀히 한다면, 돌아오는 부메랑이 더 클 수 있다는 생각을 저는 지금도 갖고 있습니다. 이 균형을 잡는 게 AI 코딩을 제대로 쓰는 핵심이라고 봅니다.

반면 프로토타입 도구로서의 가치는 분명합니다. 개발자와 논의하기 전에 동작하는 프로토타입을 먼저 보여주면 요구사항 미스매치가 눈에 띄게 줄어듭니다. 기획 의도를 텍스트와 와이어프레임으로 설명하는 것과, 실제로 클릭 가능한 화면을 보여주는 것은 커뮤니케이션 효과 자체가 다릅니다. 그 점에서 AI 코딩은 기획자에게 개발자 대체 도구가 아니라 커뮤니케이션 비용을 줄이는 수단에 가깝습니다.

AI 코딩 도구를 잘 쓰는 기획자와 그렇지 않은 기획자의 차이는 프롬프트 실력보다, AI의 한계를 얼마나 정확히 아느냐에서 갈릴 가능성이 높습니다. 프로토타입으로 쓸 것인지, 실제 서비스에 반영할 것인지를 명확히 구분하는 판단력이 앞으로 더 중요해질 것으로 보입니다. AI가 만들어준 코드를 개발자에게 검토받는 과정을 건너뛰지 않는 것, 그게 지금 제가 유지하는 가장 기본적인 원칙입니다.

---

참고:
캡틴판교 블로그 — "ChatGPT를 대하는 프런트엔드 개발자의 자세" (2023): https://joshua1988.github.io/web-development/frontend-development-with-chatgpt/
요즘IT — "2026년 프론트엔드 트렌드 총정리": https://yozm.wishket.com/magazine/detail/3519/
Botpress KO — "ChatGPT 코드 작성 실력": https://botpress.com/ko/blog/how-good-is-chatgpt-at-writing-code
카카오엔터테인먼트 테크블로그 — "ChatGPT는 FE개발자를 대체할 수 있을까?" (2023): https://fe-developers.kakaoent.com/2023/230323-chatgpt-and-fe-developer/