이번에 PVNM(Palette Visual Novel Maker)이라는 노벨 게임 제작 툴을 완성하는 과정에서, 생성형 AI(Generative AI)를 활용한 개발 검증을 수행했다.

특히 의식한 것은 단순히 "AI로 앱을 만들 수 있는가"가 아니라, 다음과 같은 질문이다.

IT 엔지니어가 아닌 사람이 AI와의 자연어(Natural Language) 대화만으로 하나의 앱을 완성 단계까지 이끌 수 있는가?

검증에서는 Claude와 대화할 때는 "엔지니어가 아닌 자신"을 연기하며, 전문 용어나 코드(Code)의 직접적인 제시를 극도로 피했다.

반면, Codex와 작업할 때는 "엔지니어인 자신"으로서 기술적인 어휘, 로그(Log), 파일 구조, 구현 방침 등을 그대로 다루었다.

본 기사는 그 결과와 소감을 정리한 것이다.

본 검증에서는 Claude에 대해 다음과 같은 제약을 두었다.

• Claude에 관한 사전 지식을 갖지 않거나, 모르는 척하기
• IT 엔지니어가 아닌 인물로서 대화하기
• 소스 코드(Source Code)나 구성 파일을 직접 읽지 않기
• 구체적인 코드 예시 제시는 극도로 피하기
• 자연어에 의한 요구사항이나 상황 설명만으로 개발 진행하기

목적은 Claude 단독으로 비엔지니어를 어디까지 앱 완성으로 인도할 수 있는지 확인하는 것이었다.

덧붙여, 이 검증은 Claude와 Codex의 성능 비교를 목적으로 한 것이 아니다.

오히려 AI를 활용할 때 "이용자 측의 지식이나 전달 방식"이 어느 정도 결과에 영향을 미치는지 관찰하기 위한 것임을 미리 밝혀둔다.

최종적으로 PVNM은 다음과 같은 기능을 갖춘 툴로서 완성에 가까운 상태까지 도달했다.

• 장면 편집
• 배경 이미지, 캐릭터 이미지 설정
• BGM / SE 설정
• 선택지와 분기
• 타이틀 화면
• 엔딩 화면
• EXTRAS
• 세이브 / 로드
• Markdown 임포트
• Windows / Web / Android 등으로의 익스포트(Export)
• 일본어·영어 문서
• 라이선스, 제3자 라이선스 통지, 공개용 README

단순한 프로토타입(Prototype)이 아니라, 공개 및 배포를 의식한 상태까지 갖출 수 있었다.

Claude와의 작업에서는 자연어로 기능 추가나 수정을 의뢰하며 개발을 진행했다.

다만, 실제로는 "비엔지니어가 AI의 인도를 받아 개발했다"기보다는, 이쪽에서 상당히 능동적으로 사양 정리, 버그 보고, 화면 설계, 동작 확인을 수행해야 했다.

Claude와의 대화가 격해지면 이쪽에서도 전문적인 용어나 기술적인 워드(Word)를 사용하여 응답해 버려, "비엔지니어"를 연기하는 것을 철저히 하지 못한 점은 반성할 부분 중 하나이다.

참고로 남아있던 Claude와의 대화 메모를 보면, 이쪽에서 Claude에게 던졌던 내용에는 다음과 같은 것들이 많이 포함되어 있었다.

• 화면상의 버튼이 작동하지 않음
• ESC 키로 돌아갈 수 없음
• 취소할 수 없음
• 일본어가 표시되지 않음
• UI의 글자가 겹침
• 버튼과 글자의 위치가 어긋남
• 이미지가 화면 밖에 표시됨
• BGM이 정지하지 않음
• 에러의 Traceback을 붙여넣음
• 스크린샷을 봐달라고 의뢰함
• 사양을 변경함
• 구현 방침을 재정의함

즉, 사용자 측(나)은 단순히 "이런 앱을 원한다"라고 말한 것이 아니라, 실제로는 상당히 세밀하게 QA를 수행하고, 사양을 분해하며, 재현 조건을 전달하고, 기대하는 동작을 정의하고 있었다.

이번에 가장 강하게 느낀 점은, AI와의 개발에서는 "무엇을 만들고 싶은가"보다 "지금 무엇이 일어나고 있는가"를 정확하게 전달하는 능력이 중요하다는 것이었다.

비엔지니어 역할로 대화하다 보면 다음과 같은 장면에서 개발이 막히기 쉬웠다.

• 에러의 원인을 어떻게 설명해야 할지 모르겠다 → 개발이 막힘
• 화면의 깨짐을 언어화할 수 없다 → 개발이 막힘
• 어떤 조작에서 불량이 발생했는지 정리되지 않았다 → 개발이 막힘
• 기대하는 사양과 현재 동작의 차이(Diff)를 전달할 수 없다 → 개발이 막힘
• AI가 수정한 내용이 정말로 맞는지 판단할 수 없다 → 개발이 막힘

AI는 자연어로 응답해 주지만, 개발 그 자체는 여전히 구체적인 작업이다.

화면, 상태, 입력, 출력, 로그, 파일, 재현 절차와 같은 정보가 부족하면 AI의 지원 정밀도는 크게 떨어진다는 것을 알 수 있었다.

한편, Codex와의 작업에서는 이쪽이 엔지니어로서 대화했기 때문에 작업이 상당히 원활하다.

예를 들어, 이쪽에서의 지시를 명확히 했다.

• 알고리즘을 지시함
• 로직(Logic)을 지시함
• 구체적인 처리 내용을 지시함

이에 더해 다음과 같은 정보도 그대로 다루도록 했다.

• 파일 경로 (File path)
• Git 상태 (Git state)
• 에러 로그 (Error log)
• 구현 위치 (Implementation location)
• 런타임 구조 (Runtime structure)
• 빌드 절차 (Build procedure)
• Android 및 Web 내보내기 사양 (Export specification)
• 문서 구성 (Documentation structure)
• 라이선스 정리 (License organization)

이 차이는 단순히 "Codex가 Claude보다 뛰어났다"는 이야기가 아니다.

오히려 AI에게 전달할 수 있는 정보의 입도(Granularity)가 완전히 달랐다는 점이 크다.

제대로 된 엔지니어로서 AI와 대화할 경우, 문제를 상당히 정확하게 AI에게 전달할 수 있다.

그 결과, AI도 구체적으로 조사하고, 수정하고, 검증하기 쉬워진다는 의미다.

더 원활하게 작업을 진행하고 싶다면, skills가 있을 경우 같은 설명을 몇 번이고 반복해야 하는 부담이나 사양의 어긋남, 확인 누락은 상당히 줄어들었을 것이라는 느낌이다.

여기서 말하는 skills를 "AI에게 사전에 전달해 두는 개발 절차서·전문 지식·판단 기준"이라고 생각한다면, PVNM 개발에서는 특히 효과가 컸다고 생각한다.

예를 들어 다음과 같은 skill이 있다면 효과적일 것으로 생각한다.

이번 Claude와의 상호작용을 보면, 반복해서 발생했던 마찰은 "구현 능력" 그 자체보다 오히려 다음과 같은 것들이었다.

• 이전에 결정한 사양이 다음 수정에서 무너짐
• 비슷한 UI임에도 화면마다 동작이 다름
• ESC, 취소, 뒤로 가기 등의 공통 조작이 누락됨
• 일본어 표시나 글자 크기 문제가 반복됨
• 사용자가 매번 상당히 세세하게 사양을 다시 말해야 함

skills는 이러한 "매번 기억해 주길 바라는 전제"를 고정하는 데 적합하다.

한편, skills만으로는 해결할 수 없는 부분도 있다.

특히 이번과 같은 GUI 앱에서는 실제로 실행하고, 화면을 보고, 로그를 보고, 조작하며 확인하는 공정이 중요하다.

skills가 있더라도 최종적으로는 사용자 측의 확인 부담은 남을 가능성이 높다.

따라서 나의 견해로는...

skills가 있었다면 Claude와의 개발은 상당히 원활해졌을 가능성이 높다.

다만, 실용적인 품질까지 끌어올리기 위해서는 skills에 더해 실행 환경에 대한 액세스, 로그 확인, 스크린샷 확인, 테스트 절차의 표준화가 필요했다.

이번 검증에서는 Claude와의 대화에서 "비엔지니어 역할"을 맡았기에 skills 같은 것을 만들 수도 없었고, AI에게 매번 자연어로 사양을 전달하는 방식을 취했기 때문에 사양의 재설명이나 수정 방침의 흔들림이 많이 발생했다.

만약 PVNM 전용 개발 규칙이나 UI 설계 기준을 skills와 같은 형태로 사전에 정의해 두었다면, Claude와의 개발은 더욱 안정되었을 것이며 사용자 측의 설명 부담도 경감되었을 가능성이 높다.

단, skills는 검증 작업 그 자체를 대체하는 것이 아니라, 실행 확인이나 버그 재현, 결과물의 품질 판단에는 여전히 인간 측의 관여가 필요하다고 생각한다.

이번 검증 결과를 당초의 평가 축에 따라 정리하면 다음과 같다.

최종 평가로서는 다음과 같이 정리하는 것이 타당하다고 생각한다.

이번 검증을 통해 얻은 결론은 다음 한 문장으로 집약할 수 있다.

AI를 쓰면 개발할 수 있다가 아니라, AI에게 상황을 올바르게 전달할 수 있는 사람일수록 개발을 더 원활하게 진행할 수 있다.

라고는 하지만, Claude와의 대화에서는 자연어만으로도 많은 작업을 진행할 수 있었다.

즉, 간단한 앱 정도라면 자연어에 의한 AI 개발은 문제없이 할 수 있을 가능성이 높다는 것이다.

이는 큰 성과라고 생각한다.

하지만 실용 품질의 앱을 완성하기 위해서는 단순히 AI에게 의뢰하는 것만으로는 부족했다.

버그를 관찰하고, 재현 조건을 정리하고, 기대하는 동작을 언어화하며, 필요에 따라 사양을 수정하는 능력이 필요함을 느꼈다.

이는 기존의 프로그래밍 기술과는 조금 다르다고 생각한다.

하지만 개발 현장에서 AI를 활용하는 데 있어서는 매우 중요한 기술이라고 느꼈다.

나는 지금까지 엔지니어를 육성하여 실무 현장으로 보내는 업무에 종사해 왔다.

그 관점에서 보면, 이번 검증은 AI 활용 교육의 교재로서 매우 유용하다고 느끼고 있다.

생성형 AI 교육에서는 종종 "AI를 쓰면 편리하다"는 설명에 그치기 쉽다.

하지만 실제로는 성과를 내기 위해 다음과 같은 능력이 필요해진다.

• 요구사항을 분해하는 능력
• 결함을 관찰하는 능력
• 재현 절차를 전달하는 능력
• 에러나 로그를 읽는 능력
• 기대하는 동작을 명확히 하는 능력
• AI의 출력을 검증하는 능력
• 사양 변경을 관리하는 능력

즉, AI 활용 기술이란 단순히 "프롬프트를 작성하는 능력"만이 아니다.

IT 엔지니어로서의 기본적인 능력에 더해, AI와 함께 개발을 진행하기 위한 실무적인 커뮤니케이션 능력 그 자체라고 느꼈다.

PVNM 개발을 통해 AI는 확실히 강력한 개발 지원자가 될 수 있음을 실감했다.

특히 사용자의 의도를 파악하여 구현해 주는 장면도 매우 많았다.

"느리다", "알아보기 어렵다", "이런 느낌으로 해줬으면 좋겠다"와 같이 인간의 감각적인 감상이나 요구사항까지도 어느 정도 정확하게 파악하여, 이를 코드로 구체화해 주는 점이 매우 도움이 되었다.

반면, AI가 모든 것을 자동으로 해결해 주는 것은 아니다.

특히 앱 개발처럼 사양, UI, 상태 관리 (State Management), 파일, 빌드, 배포가 얽혀 있는 작업에서는 사용자 측의 이해도나 전달 방식이 결과에 큰 영향을 미친다.

이번 검증은 "비엔지니어라도 AI만으로 쉽게 앱을 만들 수 있다"는 것을 증명하는 것이 아니었다.

오히려 다음을 보여주는 검증이었다고 생각한다.

AI를 사용하는 것과 AI를 능숙하게 다루는 것은 다르다.

그리고 향후 엔지니어 교육에서는 이 "AI를 능숙하게 다루는 능력"을 어떻게 육성할지가 중요해질 것이라고 생각한다.

이상