[사이드 프로젝트 회고] bridgeType 회고

최관수·2025년 10월 11일

회고

목록 보기

8/8

https://bridge-type.netlify.app/

참여 계기와 성과

추석 연휴 간 bridgeType이라는 사이드 프로젝트를 진행했다. 비사이드의 SOLO 포텐데이 참여를 계기로 시작하게 됐는데, 추석 연휴 동안 AI를 활용해 1인 개발을 하는 챌린지였고, 긴 연휴이니 뭐라도 하나 만들자는 생각에 충동적으로 신청했다. 사실 끝까지 참여를 망설이긴 했다. 방송대 중간 과제, 앱 개발과 데이터베이스 스터디 이미 할 게 산더미인데 이게 되나..? 근데 뭐 또 벌려 놓으면 하겠지 싶은 ‘의욕 드리븐’으로 참여를 결정했다.

결과적으로는 단촐하지만 깔끔한 웹서비스를 만들긴 했고, ‘AI 드리븐, 다음엔 이렇게’라는 제목으로 발표까지 마칠 수 있었다. 개인적으로 결과물 그 자체보다 AI를 활용해 단기간에 하나의 완성된 프로덕트를 만들어냈다는 경험 자체가 더 큰 의미가 있었다. 이미 개발 실무에서는 AI를 활용해 왔지만, 기획이나 디자인을 포함한 전체 프로덕트를 만들어 본 경험은 없었기 때문에 그 가능성을 직접 확인할 수 있는 경험이었다.

이번엔 이렇게

이번 프로젝트는 기획부터 개발까지 AI와 협업하며 진행했다. 각 단계에서 AI를 어떻게 활용했는지 간략하게 정리해 보았다.

기획

포텐데이에 신청할 당시엔 구체적인 아이디어가 없었기 때문에 몇 가지 목적을 중심으로 방향을 잡아 나갔다.

기술적 목표: 프론트엔드 퍼널(Funnel)패턴을 효율적으로 관리해 보기
기획적 목표: 단순하지만 생각거리를 던질 수 있는 서비스
개인적 목표: 기존 앱(TimeBridge)과의 연결성 확보
AI적(?) 목표: 다양한 AI 플랫폼을 활용해 보기

또한 1인 개발에 익숙하지 않다는 점을 고려하여 데이터베이스 활용을 최소화하면서도 동기부여가 가능한 프로젝트여야 한다는 점이 중요했다.

이번 프로젝트는 Codex를 중심으로 작업할 생각이었기 때문에 기획 단계부터 GPT 5를 이용했다. 개인적인 경험상 GPT가 기획 단계에서 세밀하고 논리적인 설계를 잘 도와주는 편이어서 선택했다.

GPT 5에게 내 기획의 방향과 목적, 그리고 제약 조건 등을 프롬프트로 전달하니 네 가지 초기 기획안을 제안받았다.

관계 성향 테스트 - 가볍고 공유하기 좋은 컨텐츠
세대 싱크율 테스트 - 세대 차이를 넘어 공감 포인트를 직관적으로 보여주는 콘텐츠
스토리 카드 - 개발 중인 앱의 핵심 기능(질문 카드)을 미리 경험하게 하는 콘텐츠
회고록 미리보기 - 감성적인 접근으로 ‘디지털 회고록’과 직접적으로 연결되는 기능

2, 3번은 MVP 개발 기간 안에 구현하기에는 세부 기획이 까다로울 수 있다고 느꼈고, 4번은 현재 개발 중인 앱과 유사했다. 1번 기획이 가장 단순하지만 일정 안에 MVP 배포엔 무리가 없을 것으로 판단되어 선택했다.

이후 필요한 기능을 구체적으로 정의하고 세부 기획안을 요청해 작성해 나갔다. 세부 기획안을 토대로 단계별 구현 로드맵을 생성시켰는데, 이렇게 단계별 구현 로드맵을 만들어두면 AI에게 순차적으로 맥락을 이해시키기 좋다. 꼭 개발뿐만 아니라 코어 기능과 무관한 오버 스펙은 왜 이 스펙이 필요한지 되묻고, 불필요하다 판단되면 제외하거나 세부 요청을 하기에도 용이했다. 각 단계는 ‘맥락 이해 → 세부 요청 → 피드백 반영’의 사이클로 진행했고, 가능한 한 하나의 프롬프트 맥락 안에서 마무리하는 방식으로 진행했다.

디자인

기획을 마친 후, 디자인은 개발과 거의 동시에 진행했다.

Lovable이나 Figma Make 같은 AI 디자인 툴도 고려했지만, 시간상 적극적으로 활용하지 못한 점이 다소 아쉽다. 로고나 일러스트는 Gemini 2.5 Pro와 같은 다른 모델을 병행 사용했는데, 프롬프트만 던지는 것보다 핀터레스트 등에서 찾은 레퍼런스 자료를 함께 제공했을 때 훨씬 정확한 결과를 얻을 수 있었다.

확실히 기획이나 개발에 비해 디자인은 AI에게 레퍼런스와 같은 어떤 기준을 제시하는 것이 얼마나 중요한지 체감할 수 있었다.

개발

개발은 기능 단위 분할을 핵심 원칙으로 했다. 실무에서도 느끼지만, AI에게 일을 맡길 때는 피처 단위로, 확실하게 더 작은 단위로 쪼갤수록 결과물이 좋아진다.

이번 프로젝트는 AI 드리븐 개발을 목표로 했기 때문에 내가 개입하더라도 수정이 용이한 방향을 원했고, 개발 중간에 그런 이유로 간단한 마이그레이션을 진행하기도 했다.

최초 기술 스택: CSS Modules + Mantine
변경 후: 코드레벨을 온전히 파악한 게 아닌 상황에서는 스타일시트 수정이 번거로워 Tailwind + Shadcn으로 전환
데이터베이스: 기존에 사용하던 Supabase 활용

초기에 /init 명령어를 통해 AI에게 전체 구조를 이해시키고, 필요한 문서(AGENT.md)를 참고하게 했다. /init 외에 좀 더 맥락을 이해시키기 위한 팁들이 존재하는데, 이건 각 LLM 공식 문서를 참고하는 편이 가장 좋다.

AI 기반의 1인 개발을 하면서 느낀 건, 디버깅과 테스트의 중요성이 훨씬 커진다는 점이다. 스스로 작업하는 것보다 상대적으로 코드 베이스를 온전히 파악하기 어려울 수 있어, 사소한 디버깅 포인트가 더 자주 발생할 수 있다. 또한 AI가 작성한 코드가 기능적으로 잘 돌아가더라도, 예상치 못한 사이드 이펙트나 엣지 케이스가 있을 수 있다. 그런 맥락에서 개발자의 역할이 ‘코드 작성’에서 ‘검증과 통합’으로 이동하고 있는 게 아닌가 싶은 느낌도 들었다.

Codex 자체의 경험은 만족스러웠다. 결과 도출까지 시간이 다소 오래 걸리지만, 프롬프트가 명확하다는 가정하에 꽤 구현 정확도가 높았다. Claude 4 Sonnet이나 Gemini Pro 2.5 대비 빠르진 않지만, 코드 품질은 안정적이었다. 다만 단순한 기능 수정에도 연산이 길어지는 경우가 있어, 상황에 따라 여러 모델을 병행하는 게 효율적일 거라는 생각이 들었다.

결과 페이지는 미리 정의된 데이터 구조 안에서 입력값을 매핑하는 단순한 형태로 구현했다. 이 방식이 제한된 일정 안에 프로젝트를 완성하는 데 효율적이었고, 향후 실제 AI 모델을 연동하여 실험하기 위한 기반으로도 충분했다. 과거 AI를 활용해 답변을 생성했을 때 다소 동떨어진 결과가 나오던 경험과 토큰 비용, 개발 기간을 종합적으로 고려했을 때 간단한 매핑 방식이 가장 합리적인 선택이라고 생각했다.

다음엔 이렇게

작은 성공의 법칙

AI에게 일을 맡길 때도 ‘작은 성공 단위’로 나누는 것이 중요하다. AI는 명확한 범위와 목표를 줬을 때 가장 좋은 결과물을 준다. 1인 개발자에게도 이는 동일하다. 큰 기능을 한 번에 해결하려 하다가 좌절을 반복하는 것보다, 작은 성공을 통해 동기부여를 지속하는 것이 좋다고 느꼈다.

목적은 하나만 확실하게

제품을 만들 것인가, 기술을 익힐 것인가. 두 가지를 동시에 잡으려 하면 결국 어느 쪽도 명확하지 않게 된다. 이번 프로젝트는 여러 목표를 동시에 고려하다 보니, 핵심 목표가 명확하지 않아 의사결정의 기준이 흔들리는 경우가 있었다. 그럼에도 기술적 목적의 우선순위가 높았기 때문에 기획의 깊이는 단순화된 경향 또한 있었다. 다음엔 반대로 ‘타인의 문제 해결’을 중심으로 한 접근을 시도해 보고 싶다. 프로젝트가 끝나고 ‘내 사이드 프로젝트가 쓰레기통으로 가는 이유’라는 영상을 봤는데, 예고도 없이 뼈를 심하게 때려 맞았다..

분리와 결합

AI와 협업할수록 작업을 분리하는 것이 곧 효율적인 방식이라는 생각을 하게 된다. 기획, 디자인, 개발을 동시에 처리하다 보면 각 단계의 작업을 뭉뚱그려 진행하게 되는 경향이 있고, 각 산출물 관리가 다소 어렵기도 하다. 각 작업을 명확히 분리해 관리하면, 나중에 AI에게 별도로 프롬프트를 던지기에도 유리하다. 결합 단계에서는 각각 분리된 산출물을 첨부해 맥락을 재구성하거나, MCP를 통해 딸깍 재결합하는 형태의 워크플로우가 이상적이라는 생각이 들었다.