서론

안녕하세요, takeMiya입니다.

평소에는 프로덕트 마케팅 (Product Marketing) 영역에서 일하고 있으며, 엔지니어가 아닌 입장에서 개인 개발에 임하고 있습니다.

이 Zenn에서는 지금까지 2편의 글을 써왔습니다.

▶ 비엔지니어 개인 개발자가, iOS App Review 에서 ATT 관련 리젝트를 2번 겪으며 배운 것

▶ 비엔지니어가 AI만으로 앱을 출시하기까지, 개발 환경을 3번 바꾼 이야기

이번에는 그 너머에 있는 질문에 다가갑니다.

정말로, 코드 한 줄도 쓰지 않고 출시할 수 있었을까?

결론부터 말씀드리면, 답은 예스 (Yes) 입니다.

저 자신은 정말로 코드 한 줄도 쓰지 않았습니다.

작성한 것은 모두 Claude Code 입니다.

작성한 것은 이 앱입니다.

이번 앱

TicTacToe GO

는 심플한 보드게임 앱입니다.

클래식한 ○×에 더해, 여러 가지 게임 모드를 탑재

대인전·CPU전이 있어, 혼자서도, 친구나 부모 자식 간에도 즐길 수 있는 캐주얼 층 대상

AdMob을 사용한 광고 수익 모델

앱의 게임 화면

이 앱을 저는 코드 한 줄도 쓰지 않고 만들었습니다.

이 기사에서 전하고 싶은 것

「코드 한 줄도 쓰지 않고 출시할 수 있었다」라는 사실 그 자체는, AI 툴의 진화를 생각하면 이제 특별한 이야기가 아니라고 생각합니다.

다만, 「AI에게 맡기는 것」의 리얼리티 —— 무엇을 맡기고, 무엇을 맡기지 않으며, 어떻게 마주했는가 —— 에 대해, 조금 시점을 바꾸어 코딩 경험이 없는 비엔지니어의 입장에서 정리했습니다.

출시하기까지 느꼈던, 자신의 리얼한 위치와 궁리를 남겨두고 싶다.

이것이 이 기사를 쓰는 동기입니다.

또한, 「코딩 경험이 있는 엔지니어가 스스로 코드를 쓰지 않고 AI에게 맡기는」 사례는 이미 많은 글이 있다고 생각합니다.

이번에는 다른 사례로서, 코딩 경험이 없는 비엔지니어가 코드 한 줄도 쓰지 않고 어떻게 출시했는지에 대해 소개합니다.

상정 독자는,

• 앞으로 앱을 출시하고 싶다고 생각하는 비엔지니어 분
• AI에게 무엇을 어디까지 맡기면 좋을지 고민하고 있는 분

입니다.

어디까지나 「내 경우는 이랬다」 라는 하나의 예시이지만, 여러분의 힌트에 도움이 된다면 기쁘겠습니다.

【결론】정말로 한 줄도 쓰지 않았다

먼저 정리합니다.

• 게임 로직 (Game Logic) 구현도, UI 구현도, 스토어 신청 관련 업무도, 저는 한 줄도 코드를 쓰지 않았다
• 작성한 것은 모두 Claude Code
• 자신은 코드를 읽을 수 없고, 리뷰 (Review)도 할 수 없다

그럼에도 앱은 출시할 수 있었습니다.

단, 쓰지 않는 대신에 하고 있었던 것이 있다

「쓰지 않는다」는 것만으로 완결된 것은 아닙니다.

코드를 쓰지 않는 대신, 저는 세 가지를 의식했습니다.

각각의 내용은 이후 본문에서 전개하겠습니다.

🤖AI에게 맡긴 것

처음부터 「이것과 이것을 맡기자」라고 결정하고 시작한 것은 아닙니다.

코딩 경험이 없기 때문에, 애초에 무엇을 맡길 수 있는지, 어디까지 AI에게 부탁할 수 있는지 스스로 이미지화하지 못했던 것이 솔직한 심정입니다.

개발을 진행하면서 Claude Code가 맡아주는 범위는 생각보다 넓었으며, 결과적으로 「구현 부분은 거의 전부」가 되었습니다.

돌이켜보면 Claude Code가 담당했던 영역은 크게 4가지로 분류할 수 있습니다.

1. 설계·아키텍처 (Architecture) 방침

이것은 솔직히 말하자면, 저에게는 판단할 수 없는 영역이었습니다.

「상태 관리 (State Management)는 Provider와 Riverpod 중 어느 것으로 할까요?」

「MVVM 아키텍처로 구성해도 될까요?」

「파일 구성은 클린 아키텍처 (Clean Architecture)에 가깝게 할까요?」

이와 같이 질문을 받아도, 어느 것을 선택해야 할지 스스로 판단할 재료가 없습니다.

그래서 방침으로서, 「목적과 제약을 전달할 테니, 설계 판단은 Claude Code에게 맡긴다」 라는 자세로 진행했습니다.

구체적으로 어떤 제약을 전달했는지는 다음 섹션에서 쓰겠습니다.

2. 구현·코딩

게임 로직도, UI도, 상태 관리도, 모두 Claude Code가 작성했습니다.

• 게임 로직 (Game Logic): ○× 판정, 링 모드 승패 판정, CPU 차례 처리
• UI 구현 (UI Implementation): Flutter 위젯, 화면 전환, 애니메이션
• 상태 관리 (State Management): 플레이어 차례, 게임 상태, 설정값 유지

저 자신은 이 코드들을 단 한 줄도 쓰지 않았으며, 작성된 코드를 행 단위로 읽고 이해하지도 않았습니다.

동작 확인은 구현된 앱을 가지고 있는 실기기에서 직접 만져보는 방식으로 진행했습니다.

3. SDK · 외부 서비스 통합

외부 서비스 연동은 구현 절차만으로도 복잡합니다.

이 부분도 Claude Code에게 맡겼습니다.

• AdMob: 전면 광고 (Interstitial Ad) 삽입
• Firebase: FCM (푸시 알림), Crashlytics (크래시 리포트), Analytics
• ATT: 트래킹 허용 다이얼로그 (이전 기사에서 상세 기술)

각각 원래라면 공식 문서를 읽으면서 설정 파일을 수정하는 작업이 발생할 것이라고 생각합니다.

비엔지니어가 수동으로 하려고 하면 막힐 법한 영역이지만, Claude Code에게 넘기니 한 차례 모두 구축해 주었습니다.

4. 스토어 신청 관련 설정

스토어 신청에 필요한 파일들도 Claude Code가 준비했습니다.

• iOS 측의 Info.plist, InfoPlist.strings의 각 언어 버전
• Android 측의 AndroidManifest.xml, build.gradle 설정

이 내용들은 제가 직접 한 줄도 쓰지 않았으며, 처음에는 의미를 알 수 없었습니다.

Apple Developer Portal이나 Google Play Console에서의 조작은 수동이었지만, 앱 측의 파일 정비는 Claude Code에게 맡겼습니다.

👩‍🏫 설계 리뷰는 다른 AI에게 맡겼다

Claude Code에게 설계와 구현을 모두 맡긴 이상, **"그 판단이 정말로 타당한가?"**라는 의문이 남습니다.

저는 코드를 읽을 수 없기에 코드 리뷰는 할 수 없습니다.

하지만 설계의 정당성이나 이점을 다른 관점에서 검증하는 것은 가능합니다.

그래서 Claude Code가 제시해 온 설계 방침에 대해 다른 AI (ChatGPT)에게 의견을 구하도록 했습니다.

예를 들어, "이 앱에서 MVVM을 채택하는 이점은 무엇입니까?", "다른 어떤 선택지가 있으며, 각각의 장점과 단점은?"와 같은 질문을 ChatGPT에 던져서 Claude Code의 판단을 다른 각도에서 비추어 보는 식의 리뷰입니다.

코드의 내용이 아니라, 설계 판단이라는 상위 계층에서 리뷰하는 것.

이것은 코드를 쓰지 못하는 저에게도 가능한 몇 안 되는 방법이었습니다.

자세한 내용은 다음 섹션인 「내가 한 것」에서 쓰겠습니다.

「거의 전부 맡겼다」를 냉정하게 관찰하기

이렇게 써 내려가 보니, 앱의 내용으로서 동작하고 있는 코드는 거의 모두 Claude Code가 작성한 것임을 알 수 있습니다.

처음에는 "어디까지 맡겨도 되는지" 몰라서 매번 상담하며 진행했는데, 진행할수록 맡겨도 되는 범위는 생각보다 훨씬 넓었다는 결과가 되었습니다.

단, "전부 맡겼다"와 "전부 떠넘겼다"는 다릅니다.

코드를 쓰지 않은 대신, 저는 다른 역할을 수행하고 있었습니다.

다음 섹션에서 그 내용을 써 내려가겠습니다.

✋️ 내가 한 것

"코드를 쓰지 않는다"는 것만으로 끝난 것은 아닙니다.

코드를 쓰지 않는 대신, 저는 세 가지를 의식적으로 수행하도록 했습니다.

목적과 제약 사항을 처음에 전달하기
상위의 추상 개념을 이해하기
AI 간의 가교 역할이 되지 않기

순서대로 써 내려가겠습니다.

1. 목적과 제약 사항을 처음에 전달하기

가장 먼저 한 일은 이 앱으로 무엇을 목표로 하는지, 어떤 제약이 있는지를 Claude Code에게 전달하는 것이었습니다.

타이밍은 프로젝트를 시작할 때입니다.

구체적으로 전달한 내용은 다음과 같습니다.

릴리스 후에도 게임 모드 추가와 업데이트를 계속할 것
재작업 (rework)이 발생하지 않도록 할 것
의존 관계가 적은 구조로 만들 것
방법은 맡기되, 검증된 (mature) 방식이어도 괜찮음
iOS / Android가 동시에 출시될 수 있고, 기능 차이를 가급적 없앨 것

기술 용어로 번역하려고 하지 않고, 제 언어 그대로 전달했습니다.

아는 척하며 넘기기보다, 제 의도가 흔들리지 않고 전달된 느낌입니다.

2. 상위의 추상 개념을 이해하기

코드의 내용은 읽을 수 없습니다.

하지만, 「전체적으로 어떻게 움직이는가」를 상위 계층에서 이해하는 것은 코드를 읽지 못해도 가능하다고 생각했습니다.

구체적으로는, 책임의 분리 (Separation of Concerns) —— UI / 로직 (Logic) / 데이터 (Data)의 3개 계층이 어떻게 나누어져 있는지를 파악하는 것에 제 이해의 초점을 맞추었습니다.

이는 업무에서의 역할 분담의 이미지와 같습니다.

「누가 무엇을 담당하고 있는가」를 알 수 있다면, 코드의 내용을 읽지 못해도 전체적인 움직임은 쫓을 수 있습니다.

🎄파일 구조로부터 설계 구조를 대조하기

구체적인 방법은 심플합니다.

VS Code의 파일 트리 (File Tree)를 바라보며 AI에게 질문해 나갔습니다.

• 「이 lib/screens/ 폴더는 무엇을 위한 거야?」
• 「lib/services/와 lib/models/의 차이는?」
• 「설계의 책임 분담과 이 파일 구조는 어떻게 연결되어 있어?」

파일 구조는 설계의 물리적인 발현이라는 것을 깨달았습니다.

「책임의 분리」와 같은 추상적인 설계 이야기를 파일의 위치라는 구체적인 것에 연결하여 이해함으로써, 코드를 읽지 않고도 전체상을 파악할 수 있게 되었습니다.

🥛지식을 Google 문서에 축적하기

이해의 질을 높이기 위해 한 가지 더 실천하고 있었던 것이 있습니다.

Google 문서에 개발 중인 지식을 스톡 (Stock) 해두는 것입니다.

구체적으로는 다음과 같이 운영했습니다.

• Claude Code가 구현 후에 제시하는 **「구현 요약 (Implementation Summary)」**과 **「작업 의뢰의 목적」**을 세트로 붙여넣기
• 「의뢰 프롬프트 (Prompt)」는 그때그때 달라지므로 남기지 않고, 「목적」만 남기기
• 자주 등장하는 용어나 작업은 중요도가 높다고 간주하여, 의미를 조사해서 덧붙이기

개발 중에는 AI가 제시하는 용어나 개념의 의미를 그 자리에서는 모르는 경우가 허다합니다.

그대로 흘려보내 버리면, 나중에 다른 문맥에서 같은 단어가 나와도 자신 안에 쌓이지 않습니다.

스톡해 둠으로써 「그때는 그런 의미였구나」라고 나중에 되돌아볼 수 있었습니다.

그리고 깨달은 것은, AI와의 주고받음은 흘러가 버린다는 점입니다.

채팅 스크롤은 끝없이 이어지지만, 그곳에서 자신의 지식으로 남는 것은 스스로 의식해서 꺼내지 않으면 남지 않습니다.

Google 문서는 **「나만의 지식을 축적할 수 있는 장소」**로서 결과적으로 큰 가치를 가졌습니다.

💡이해해 두면 무엇이 변하는가

상위 개념을 이해해 둠으로써 구체적으로 도움이 되었던 장면이 두 가지 있습니다.

• 다른 AI (ChatGPT)에게 리뷰를 의뢰할 때, 문맥을 전달하기 쉬웠다
  「이 앱은 MVVM으로 구성되어 있다」, 「설정값의 유지는 책임으로서 분리되어 있다」와 같은 전제를 전달할 수 있으면 ChatGPT의 리뷰 질이 올라갑니다.
• AI가 제시한 새로운 용어나 개념을 이해한 상태에서 대화할 수 있게 되었다
  「이것은 무엇인가?」, 「무엇을 위한 것인가?」를 확인하는 습관이 여기서 빛을 발합니다.

3. AI 사이의 가교 역할이 되지 않기

Claude Code가 구현하고, ChatGPT가 설계를 리뷰하는 구성.

이 두 AI 사이에 서 있는 인간으로서, 방심하면 **「오른쪽에서 왼쪽으로 정보를 흘려보내기만 하는 존재」**가 되기 쉽습니다.

예를 들어, Claude Code의 설계 방침을 ChatGPT에게 묻고, 돌아온 대답을 그대로 Claude Code에게 돌려주는 것.

이것만으로는 자신은 아무것도 판단하지 않고 있습니다.

그래서 의식하려고 노력한 것은, ChatGPT로부터 돌아온 대답에 대해 **「우리들의 목적에 비추어 볼 때, 이것이 정말 효과적인가?」**라고 자신의 머리로 한 번 생각하는 것이었습니다.

답이 바로 나오지 않는 경우도 많습니다.

다만, 「이것은 내가 판단해야 하는 장면이다」라고 인식하는 것만으로도 입장이 바뀌었다고 느끼고 있습니다.

앞서 언급한 「상위 개념의 이해」가 여기서 효과를 발휘했다고 느꼈습니다.

책임의 분리나 파일 구조, 목적과 제약 사항.

이것들을 나름대로 파악해 둠으로써, AI의 판단을 「목적에 비추어 생각할」 재료가 수중에 있는 상태를 만들 수 있었던 것이라고 생각합니다.

되돌아보면, 「오른쪽에서 왼쪽으로 흘리는」 것이 아니라 「위에서 조망하는」 감각에 가까웠던 것 같습니다.

이러한 감각을 가질 수 있었던 것이, 다시 가교 역할(Bridge)로 돌아가지 않아도 되었던 이유였을지도 모릅니다.

💡 깨달음: AI와 나의 관계란?

개발을 통해 한 가지 깨달음이 있었습니다.

AI보다 내가 「아래」의 존재가 되어버리면, AI의 가치를 제대로 끌어낼 수 없다는 것입니다.

Claude Code는 저보다 훨씬 많은 것을 알고 있습니다.

지식량이라는 영역에서 인간이 AI보다 우위에 서는 것은 어렵다고 생각합니다.

하지만, 지식량으로 이길 수 없으니 전부 맡겨버리자라고 생각하는 순간, 나의 위치는 「지시를 내리는 쪽」에서 「승인 도장만 찍는 존재」로 바뀌어 버립니다.

지난 기사에서 썼던 바로 그 감각입니다.

이번 개발 과정에서 제가 배운 것은, 지식량이 아니라, 위치와 역할로서 대등해지려고 노력하는 것의 중요성이었습니다.

이 모든 것들은 코드를 쓸 줄 몰라도 할 수 있는 일이라고 생각합니다.

그리고, 이것들을 하느냐 하지 않느냐에 따라 AI와의 관계성은 크게 달라진다고 느끼고 있습니다.

지식량으로 위에 서는 것은 어렵습니다.

하지만, 「이 개발에서 무엇을 목표로 할 것인가」를 결정하는 것은 나의 역할입니다.

그 역할을 놓지 않는 한, AI와 건설적으로 대화할 수 있는 관계를 유지할 수 있지 않을까 생각합니다.

아직 답을 내린 것은 아니지만, 앞으로도 계속 의식해 나가고 싶습니다.

마치며

여기까지 읽어주셔서 감사합니다.

「정말로 코드 한 줄도 쓰지 않고 출시할 수 있었는가?」라는 질문에 대해, 사실과 그 이면에서 했던 일들을 써 내려왔습니다.

되돌아보면, 「코드를 쓸 수 있는 것」과 「앱을 출시할 수 있는 것」은 별개의 능력이라고 느낍니다.

코드를 쓰는 능력은 AI로 대체할 수 있었습니다.

반면, 무엇을 만들고 싶은지를 언어화하는 것, 전체상을 파악하는 것, 판단을 놓지 않는 것 ――이것들은 현재로서는 제가 직접 해야만 하는 일들입니다.

비엔지니어라도 개인 개발로 앱을 출시할 수 있다.

그것이 실현될 수 있는 타이밍에 저는 우연히 함께할 수 있었습니다.

이 기사가 같은 도전을 고민하고 계신 분들에게 힌트가 된다면 기쁘겠습니다.

이번 앱

다시 한번, 이 기사에서 다룬 TicTacToe GO의 링크를 남겨둡니다.

• App Store에서 보기
• Google Play에서 보기

앱의 게임 화면

괜찮으시다면 한번 플레이해 보세요.