세상에서는 「AI 에이전트에 의한 코딩」이 큰 화제가 되고 있습니다.

앱 개발 경험이 거의 없는 저는, 「정말로 내가 처음부터 만들 수 있을까?」라며 두근거리는 마음을 안고, 화제의 Claude Code를 파트너로 삼아 애플리케이션 제작에 대한 도전을 시작했습니다.

Gemini와 ChatGPT도 저렴한 플랜을 계약하고 있어서, 다른 AI 에이전트 계열 도구도 사용하려고 하면 사용할 수 있었지만, 이번에는 호기심 때문에 화제의 Claude Code를 계약해 보았습니다.

「기왕 도전할 거라면, 오목 같은 교재용 앱이 아니라, 내가 한때 빠져 있었고 애착이 있는 것을 만들고 싶다"

그런 동기에서 선택한 테마는, 취미인 TRPG(Tabletop RPG)에서 애용하던 오픈 소스 세션 도구인 「Udonarium(ユドナリウム)」 및 파생 도구인 **「Udonarium Lily(ユドナリウムリリィ)」**의 리플레이스(Replace)입니다.

아직 프라이빗 리포지토리(Private Repository) 상태이며, 보안 리스크가 없는지 겁을 내며 정밀 조사하고 있는 단계이지만, 구현 직전까지 어떻게든 도달했기에 지식 제로인 제가 눈대중으로 진행한 「구현 전 준비 프로세스」를 기록으로서 공유합니다.

• AI 에이전트(Claude Code 등)를 사용한 개발 프로세스에 관심이 있는 분
• 앱 개발 미경험자로부터 Web 애플리케이션을 만들어 보고 싶은 분
• 기존 OSS를 리플레이스·모다나이즈(Modernize)하며 공부하고 싶은 분

Udonarium은 MIT 라이선스의 훌륭한 OSS입니다. 이번 개발의 목적은 단순히 흉내를 내는 것이 아니라, 「평소 사용하는 도구가 어떤 구조로 만들어져 있는지 배우고, 최신 애플리케이션 개발 지식을 조금이라도 습득하고 싶다」는 공부의 의미가 큽니다.

(※ 형태가 갖춰지면, 원래의 라이선스에 기반하여 파생 작품으로서 공개한다는 전제로 진행하고 있습니다)

우선 Claude Code에 기존 리포지토리의 코드를 읽히고, 「어떤 설계로 되어 있는지」, 「초보자인 내가 처음부터 만든다면 어떻게 접근해야 하는지」를 파악하도록 했습니다.

Udonarium의 최대 특징인 「서버에 데이터를 갖지 않는 브라우저 간의 P2P 통신」이라는, TRPG의 특성을 포착한 훌륭한 설계 사상을 배웠습니다.

서버에 데이터를 올리는 것은 저작권 문제상 바람직하지 않으므로, 사용자끼리 데이터를 교환함으로써 데이터 침해를 일으키지 않는 설계로 되어 있습니다.

한편으로, 인원수나 상호작용이 늘어나면 전체적으로 통신 부하나 메모리 사용량이 올라간다는 과제도 보였습니다 (공식 Issue에서도 OOM(Out of Memory, 메모리 부족)이 발생하고 있다는 내용을 보았습니다). 그래서 AI와 상담하며 다음과 같은 개선안을 세웠습니다.

변경 내용: 기존 설계에서 사용되던 XML을 **Protocol Buffers (Protobuf)**로 변경 -
장점: 데이터 크기가 작고·빠르고·심플하게 다룰 수 있게 되므로, 통신량을 줄여 전체를 경량화할 수 있음

초보자인 저에게는 매우 획기적인 발견이었으며, 설계를 읽어내는 것만으로도 큰 배움이 되었습니다.

앱 개발에 대해서는 아무것도 모르는 상태이지만, 평소 인프라 업무의 일부로 취약점 대응을 하면서 「최근에는 OSS 라이브러리의 보안 리스크(공급망 공격 등)가 늘어나고 있다」는 이야기는 귀에 들어와 있었습니다.

「AI가 권하는 대로, 잘 모르는 라이브러리를 잔뜩 넣어버리는 것이 가장 무섭다"

그렇게 생각한 저는, 처음에 Claude에게 다음과 같은 규칙을 제시했습니다.

⚠️

AI에 대한 지시 규칙

• 신뢰성이 높은 라이브러리만을 엄선하여 제안할 것
• 도입할 때는 반드시 「왜 그것을 사용하는지」를 초보자도 알 수 있도록 설명할 것

이 방어선을 구축한 덕분에, 현재로서는 구조적으로도 불필요한 라이브러리가 들어있지 않은 매우 심플한 구성을 유지하고 있다고 생각합니다.

이면에서 세컨드 오피니언(Second Opinion) AI에게 리포지토리를 체크하게 하거나, 취약점 체크를 수행하거나, 최근의 PR(Pull Request)을 보며 수상한 것이 없는지 일단 체크하고 있습니다. 다만, 애초에 「성숙한(충분히 검증되어 안정된) 라이브러리」가 메인으로 도입되어 있었기에, 현시점에서는 리스크가 없다고 판단했습니다.

장래에는 렌탈 서버 등에 배포하여 다양한 사람들에게 사용하게 하거나, 브라우저뿐만 아니라 전용 앱 버전도 만들 수 있다면 좋겠다는 꿈을 키우고 있습니다.

개발 지식이 거의 없기 때문에, Claude Code가 말하는 것이 정말로 맞는지 저로서는 판단할 수 없습니다. 또한, Claude와의 상호작용만으로 토큰 (Token, 비용 및 제한)을 소비하는 것도 아깝다고 느꼈습니다. (꽤 Opus를 사용했기 때문에, Claude Code를 마음껏 사용하기에는 조금 지갑 사정이…… ㅎㅎ)

그래서 백그라운드에서 Gemini나 ChatGPT를 '세컨드 오피니언 (Second Opinion)'으로 병용하기로 했습니다.

명확한 구분은 없으며 감각적으로 나누어 사용하고 있지만, 지식이 없는 상태이기 때문에 오히려 여러 AI로부터 서로 다른 관점을 배움으로써 "왜 그렇게 진행하는 것이 좋은지"에 대한 이해가 조금씩 깊어갔습니다.

이 멀티 AI 체제로 다음과 같은 항목들을 하나씩 검토(벽치기, Wall-hitting)해 나갔습니다.

• 모던한 서버사이드 (Server-side) / 클라이언트사이드 (Client-side) 구성
• 기술적으로 문제가 될 수 있는 포인트 도출
• 개발 절차, 규칙, 테스트 전략, GitHub 관리 방법
• CI/CD 도입, 문서 관리, 구현 전에 결정해야 할 사항의 망라

검토가 한 차례 끝난 후, 모든 요구사항을 문서 세트로 정리하여 "모순이 없는지", "리스크가 있는 설계는 아닌지", "확장성이 저해되지 않았는지"를 AI에게 확인받았습니다.

나아가, 막상 구현할 때 매번 두꺼운 문서를 다시 읽으며 길을 잃지 않도록, 구현 단계를 세밀하게 나누고 각 단계마다 필요한 정보만을 정리한 "상세 설계"를 만들어 보았습니다.

솔직히 저에게는 아직 이것들을 정확하게 리뷰할 지식이 없습니다. 하지만 여러 AI에게 크로스 체크 (Cross-check)를 받아 "전체적인 디자인으로서 정합성이 맞다"라는 말을 들었기에, 우선은 안심하고 다음 단계로 나아가기로 했습니다.

여기까지가 지식 제로인 제가 보고 배우며 진행해 온 "구현 전 준비"의 전부입니다.

단순히 AI에게 "만들어줘"라고 통째로 맡기는 것이 아니라, 기존의 훌륭한 설계를 배우고, 모르는 것은 다른 AI에게 물어보며, 신중하게 로드맵을 만드는 것. 이 준비 프로세스 자체가 저에게는 정말 좋은 공부가 되고 있습니다.

이번에는 연습과 공부를 겸한 도전입니다. 완벽을 너무 추구하다가 멈춰 서기보다는, 모처럼 AI가 함께 만들어준 이 설계도를 믿고 우선 한 걸음, 구현 단계로 나아가 보려고 합니다!

끝까지 읽어주셔서 감사합니다. 진척 사항이 있으면 다시 글로 남기도록 하겠습니다.