추석맞이 1인 개발
정말 긴 추석연휴였다. 이 긴 시간을 어떻게 보낼까 하다가, 오랜만에 1인 개발로 원하는 서비스를 하나 뚝딱 만들어보았다.
이번 서비스는 정말 나를 위해 탄생한 서비스다. 나는 출퇴근길에 대중교통에서 휴대폰으로 기술블로그/뉴스 등을 읽으며 시간을 보내는 편인데, 항상 아쉬움을 느끼는 포인트가 있었다.
- 읽고 배운 내용을 금방 잊어버림
- 잊어버리지 않으려면 간단하게라도 기록을 남겨야 하는데, 모바일 환경으로 읽다보니 읽은 내용을 체계적으로 기록 & 관리하기 어려움 (모바일 노션은 UI가 너무 불편)
그래서 어떻게 하면 출퇴근길에 가볍게 읽은 글들의 내용을 잘 기록하고, 관리하고, 복기할 수 있을까 고민하다가 이에 최적화된 서비스를 만들어보았다.
길다면 긴 연휴였지만 하나의 서비스를 처음부터 끝까지 완성하기에 충분한 시간은 아니라고 생각했다. 그럼에도 추석 연휴 마지막 날 성공적으로 배포를 마친 후 다음날 출근일부터 이 서비스를 출퇴근길에 사용할 수 있게 되었는데, 단연코 일등공신은 AI Assistant였다.
그래서 이 글에서는 이 서비스를 개발하며 내가 어떻게 AI를 개발에 사용했는지, 그 과정에서 무엇을 느꼈는지 설명하고 내 결과물을 소개하는 시간을 가져보려고 한다.
Thanks to Gemini
이번 개발은 Gemini 2.5 pro와 함께 SDD(Specification Driven Develop) 형태로 진행했다. 먼저 명세를 마크다운 형식으로 꼼꼼히 작성하고, 이 명세를 context로 제공하여 작업을 진행했다.
프로젝트를 처음 진행할 때 큰 그림을 그리는 과정(도메인 설계, 데이터 구조 잡기, User Flow 설계 등)에 쓰는 시간이 많은데, 개요만 잡아주고 세부 내용은 AI에게 지시한 뒤 결과물을 리뷰만 하는 방식으로 작업하니 이 과정에 소요되는 시간도 비약적으로 단축되었다. 원래라면 여기서만 3일은 잡아먹었을 텐데, 단 하루 10 to 6 정도의 시간 투자로 완성했다.
그리고 GitHub Repository에 필요한 것들을 세팅하는 과정에서는 GitHub MCP의 도움을 많이 받았다. Specification 기반으로 Task 리스트업을 요청을 해둔 게 있는데, 이걸 GitHub Issue로 만들어달라고 요청하니 일괄 등록을 진행해주었다. (레이블링까지 가능!)
파트별 개발은 Server, Web, UI 3가지 영역에 대하여 별도의 지침(instruction)을 만들어 명세서와 함께 context로 제공하며 진행했는데, 개인적으로는 단순히 소스코드만 context로 제공했을 때보다 결과가 훨씬! 만족스러웠다.
각 영역에 대한 내 숙련도가 모두 다른 만큼 AI assistant를 이용하는 나의 자세 또한 달랐는데, 이걸 영역별로 정리해보자면 아래와 같다.
Server (사전 지식: 풍부)
아무래도 내가 백엔드 개발자인 만큼 instruction을 작성할 때 정확한 기술스택과 버전을 지정하고, 전체적인 코드 스타일, 컨벤션 등을 지정하고 시작했다.
또한, 코드 작성을 지시하는 중간중간에도 더 좋은 방향이 있다고 생각되면 그 방향을 제안하며 AI가 작성한 방향과의 장단점을 비교하고, 더 좋은 안을 채택하도록 했다.
Web (사전 지식: 초급자)
Web 영역에 대해서는 어떤 기술스택들이 있는지 알고 있고 코드를 읽고 이해하는게 가능한 정도의 지식만 있었다.
그래서 대략적인 기술스택을 지정하고, 정말 기본적인 코드 스타일 정도만 지시한 뒤(ex: 공통 컴포넌트를 잘 설계하라) 이 instruction을 들고 Gemini에게 찾아가서 “네가 더 일을 잘 하기 위해 필요한 추가 지침을 추천해달라”고 질문해서 instruction을 보강했다.
‘네가 시니어 Frontend Engineer라고 가정하고’ 라는 ROLE 부여를 해서 진행했고, 기술스택을 React로 명시했더니 아래와 같이 React에서 사용하는 개념들을 기반으로 Instruction을 보충해주었다.
물론 내가 FE 지식이 거의 없는 만큼 이게 좋은지 아닌지에 대해 확실히 판단할 수는 없지만, 적어도 이 지침이 없는 것보다는 코드를 더 일관적으로 작성해주지 않을까 싶다.
작업을 할 때에도 서버 작업 때보다는 좀 더 블랙박스 형식으로 지시하며 작업했다. 어떤 방향으로 문제를 해결하라고 지시하기보다는 내가 해결하려고 하는 문제가 무엇인지 설명하고 이를 해결하도록 요청했다.
예를 들자면 이런 느낌이었다.
- 백엔드: 이 로직을 구현할 때에는 명확한 layer 분리와 재사용성을 위해 새로운 클래스를 생성해야 하고, B 클래스에서 이 클래스를 주입받아야 해.
- 프론트엔드: 서버에서 ~한 json 응답이 올 거고, 이걸 ~한 형태로 화면에 그려줘야 해.
그래서 프론트엔드 부분의 코드 퀄리티를 보장할 수는 없지만, 적어도 오류가 발생했을 때 에러 로그와 함께 관련된 소스코드들을 context로 제공하며 내가 해결하려는 문제를 다시 상기시켜주니 대부분의 오류는 해소되었다.
UI (사전 지식: 없음)
디자인 영역은 정말 기본적인 용어들에 대한 지식조차도 잘 없다. 그래서 포인트 컬러만 color picker 서비스에서 몇 개 콕콕 집어서 선정해두고, AI에게 ‘나는 디자인 지식이 없는데 너에게 어떤 형식의 프롬프트를 제공해야 네가 일관되게 ui를 잘 구성할 수 있겠냐’고 물어봤다.
그 결과, 정말 기본적인 정보(포인트 컬러, 상단에 Navigation Bar가 있었으면 좋겠음 등)만 제공했음에도 아래와 같이 전반적인 레이아웃에 대한 지침, 폰트/개별 컴포넌트들의 UI에 대한 지침을 내가 제공한 포인트 컬러를 기반으로 잘 정리해주었다.
Web 쪽 작업을 할 때에는 Web instruction과 UI instruction을 꼭 함께 제공하면서 작업을 지시했다. 이 명세들과 기존 작업물들을 context로 제공하면, 새 작업물도 기존의 것과 잘 어우러지게 작업을 해주었다.
개인적으로 UI 부분은 정말 ‘사용에 거슬리지 않을 정도’의 결과물이라고 느껴져서, 나중에 UI Design에 대한 기초 인강이라도 하나 수강해볼까 싶다. 역시 아예 배경지식이 zero인 영역은 AI의 도움을 받아도 결과물에 한계가 있는 것 같다.
Vibe coding + SDD 후기
TDD가 다시 강세로 떠오를수도 있겠다. (바이브 코딩과의 합이 좋다!)
확실히 AI가 가장 '엇나가지 않고' 원하는 결과물을 내놓도록 하려면 명확히 input과 output을 제시하는 게 효과가 좋았다. 이러한 점에서 테스트 코드를 context로 제공하고 실제 구현을 요청하면 원하는 결과물을 얻을 수 있다.
그리고 AI를 통해 리팩토링을 하다보면 코드가 깨지는 케이스가 종종 생긴다. 이런 경우에도 먼저 작성된 테스트 코드가 있다면 수정된 코드가 내가 원하는 input-output을 만족하는지 쉽게 검증할 수 있다.
위의 장점들은 원래부터 TDD의 장점으로 꼽히는 것들이었으나, 그럼에도 TDD가 빛을 보지 못한 이유는 빠른 결과물을 요구하는 IT 시장에서 거대한 초기 비용과 더 늘어나는 것만 같은 유지보수 공수 때문이었다고 생각한다. 하지만 이제 코드를 생성하는 것은 high-cost 작업이 아니게 되었고, 테스트 코드와 같이 반복적이고 정형화된 로직들이 많은 코드는 더더욱 빠르게 구현할 수 있게 되었다.
그래서! 테스트 코드를 작성하는 데에 더 적은 비용이 들고, 테스트 코드를 통해 구현 코드를 생성하는 것이 더 간편해진 지금 TDD가 다시 강세로 떠오를 수도 있겠다 하는 생각이 든다.
AI Assistant는 Prompt & Context에 따라 천재가 되기도 하고 바보가 되기도 함
정말 여러분의 행동에 따라 천사가 될 수도 있고 악마가 될 수도 있는 수련회 교관님 같은 분이라고 볼 수 있다.
생각보다 이들의 기억력은 길지 않고, 이들의 추측과 판단 능력은 우리가 의도하는 방향과 다를 수 있다. 그래서 우리가 원하는 결과물을 얻으려면 우리의 의도를 이들이 쉽게 이해할 수 있는 표현으로 최대한 명확하게 설명해줘야 한다.
그래서 Specification, Instruction을 잘 작성하고, 적절한 Prompt와 Context를 제공하는 것이 중요하다. 작성에 어려움을 겪는다면, 이것 또한 AI에게 물어보는 것도 나쁘지 않았다. (결국 그들에게 필요한 것은 그들이 제일 잘 알지 않을까!)
결과물 자랑 타임
이제 제작 과정에 대한 얘기는 충분히 한 것 같으니, 위와 같은 작업을 거쳐 탄생한 서비스 ‘마이위키(My Wiki)’에 대한 소개를 해보려고 한다.
My Wiki
my-wiki.kro.kr
이 서비스가 목표로 하는 것은 크게 3가지이다.
- 출퇴근길에 기술 문서 읽는 습관 형성
- 학습 효과를 극대화할 수 있는 기록 템플릿 제공을 통해 쉽게 요약문을 작성
- 배운 것이 장기기억으로 갈 수 있도록 적절한 타이밍에 요약문을 복기하도록 리마인드
현재 달성한 것은 1번과 2번이고, 3번을 제대로 달성하려면 결국 웹 서비스보다는 앱 서비스로 가야 할 것 같아 다음 Vibe conding은 Android 개발이 되지 않을까 싶다.
현재 제공하는 기능
- 북마크(링크)를 저장하고 나의 북마크 목록을 확인
- 저장한 북마크 글을 읽고, 요약문을 작성
- 요약문을 작성할 때에는 원하는 기록 템플릿을 선택해 형식에 맞게 작성
- (가뜩이나 피곤한) 출/퇴근길에 부담없이 가볍게 기록할 수 있도록, 질의응답 형태로 구성
- 요약문은 언제든 다시 보고 수정할 수 있음
앞으로 제공할 기능
- 작성 후 일주일이 지난 요약문은 다시 읽도록 권장
- 알림을 통해 구현해야 할 듯한데, 이 부분은 앱 버전도 출시하고 도입해야 할 듯하다.
- 북마크를 카테고리로 분류
- 랜덤 글 읽기 (결정장애를 가진 수많은 사람들을 위하여)
배운 것이 머리에서 지워지지 않게 할 수는 없다. 이 서비스를 통해 읽은 내용을 기록하는 습관, 기록한 내용을 복기하는 습관을 만들어 기억을 더 오래 가져가도록 하고 싶었다.
번외 - 크롬 확장 프로그램
그리고 간편한 북마크 등록을 돕기 위한 크롬 확장 프로그램도 제작했는데, 링크를 일일이 복사하고 서비스에 붙여넣는 것도 반복하다보면 귀찮은 일이 될 수 있기 때문에, 아래와 같이 등록하고 싶은 사이트를 발견하면 오른쪽 마우스를 클릭해 북마크를 등록할 수 있다.
만약 컴퓨터로 어떤 글을 읽다가 ‘아, 이거 나중에 출퇴근길에 마저 읽어야지’ 생각이 들면 마이위키 아이콘을 눌러 나오는 팝업에서 현재 페이지를 북마크에 등록하는 기능을 이용할 수도 있다.
이 크롬 확장프로그램도 서비스를 만들 때처럼 명세 작성 - 지침 작성 - 작업 지시 순서로 2~3시간 만에 완성했다. 크롬 확장프로그램은 처음 만들어 본 건데, 이번 기회에 동작을 이해할 수 있어 좋았다.
GitHub Repository
해당 서비스와 관련된 저장소들은 아래 organization에서 관리할 예정이다.
Project My Wiki
Project My Wiki has 2 repositories available. Follow their code on GitHub.
github.com
Next Step?
- 생각보다 너무 재밌고 결과물도 잘 나와줘서 이제 정말 1인 개발의 시대, 아이템 전쟁의 시대라고 보인다.
- 다음 바이브 코딩 때에는 좀 더 다양한 MCP 서버들(태스크 매니징 관련 MCP나 Figma MCP 등)을 활용해보고 싶다.