0. 프로젝트 기획
방황 후 첫 개인 프로젝트.
AI

요즘은 AI 때문에 세상이 하루가 다르게 바뀐다.
사실 처음에는 나름 그런 변화를 좋아한다고 그 속도가 재밌었다.
하지만 사람은 몸소 위기를 느껴야 위기인 줄 아나보다. 적어도 나는 그랬다.
나만의 작은 선생님인 줄 알았던 AI가 아닌, 그 속도에 내가 끌려다니고 있는 하나의 개가 되어 있었다. 멍멍
취업 공고도 AI 관련 내용도 많아졌다. 내가 알던 개발이 아닌 시점은 이미 오래다.
"MCP, skill, 하네스", "이번엔 Opus가 SOTA, 다음엔 GPT가 SOTA.."
요즘 아마 AI 판에서 가장 많이 들리는 단어들이 아닐까 싶다. 어쩌면 개발자라면 다 아는 단어일 것이다. 점점 느낀다. 내가 공부했던 프론트엔드 지식은 흐려져만 가고 AI 지식들로 가득 찰 것만 같은 기분. 브라우저의 새 탭은 계속 늘어나는데 결과물은 안 늘어나는 상태. 개발자라기보다 브라우저 탭 관리자에 가까운 느낌..
가혹한 현실을 받아들이자.
정말 많이 방황했다. 자신감, 자존감 많이 떨어졌다. 이런 아무 결과물 없는 삶, 안정하지 못한 삶이 싫어 뭐라도 붙잡고 싶었다. 앞으로 뭘 해야할지 AI와도 많이 대화해봤고, 결과물을 내놓고 싶어 자격증도 몇 개 땄다. 하지만 취업 시장이 AI 때문에 어떻게 바뀔지도 모르기에 직업의 방향까지 다시 생각까지도 했다. 그러는 사이, 내 GitHub 잔디는 아주 제초한 것 마냥 반짝 대머리가 되었다. 의욕이 떨어진 주인의 칸 하나조차 심기지 않는 겨울 그 자체였다.
그러다 어느 날 유튜브 영상을 보다가 다시 움직일 계기가 생겼다. 지금은 AI 덕분에 누구나 개발할 수 있는 시대가 됐고, 이런 1인 개발 시대에는 아이디어가 더 중요하다는 이야기였다. 듣고 보니 내가 너무 복잡하게 생각하고 있었다. AI는 아직 도구다. 결국 중요한 건 그 도구로 뭘 만드느냐다.
그래서 거창한 걸 찾기보다 일상에서 불편했던 걸 다시 보기로 했다. 일상에서 불편함을 찾기란 어려운 문제다. 다행스럽게도 어느 날 기초 화장품을 바르다가 문득 이런 생각이 들었다.
"이거 꽤 비싼데 별로 안 남았네.. 성분 비슷한 더 저렴한 제품 없을까?"
이 생각이 꽤 오래 머리에 남았다. 기존에 서비스가 있든, 그런 서비스에 흥미가 생겨 프로젝트로 만들어보기로 했다.
근데 스크래핑이나 유사도는 어떻게 구현하지?
AI는 이럴 때에 써먹는 거지!
프로젝트 나음
Naum Logo
만들려는 건 단순하다. DB에 등록된 화장품을 검색하면, 전성분이 닮은 다른 제품들을 보여주는 서비스다.
프로젝트 이름은 나음으로 붙였다. 현재의 의미는 이 화장품보다 더 나은 화장품의 나음이지만, 나중에는 나에게 더 나은 화장품을 찾아주는 서비스로 넓혀보고 싶은 마음이다. 이름에 욕심을 조금 넣었다.
AI도 최대한 적극적으로 써보려고 한다. 나는 프론트엔드 웹 개발 지식이 대부분이라, 데이터 수집 및 정규화, DB 같은 영역에서 최대한 이용하려고 하고, 요즘 유행하는 하네스 구축 및 skill, plugin 등을 활용해보려고 한다. 써보고 왜 유행을 했는지 경험할 수 있을 것이다.
누구를 위한
우선 MVP만 봤을 때에는 나처럼 화장품 성분을 간단하게 보며 "이거랑 비슷한 성분의 다른 제품은 뭐가 있지?"라고 생각하는 사람들을 위한 서비스다.
그래서 기본 화면은 최대한 단순하게 가기로 했다. 검색, 검색 상품과 전성분 유사도 순위.
미니멀함은 개인적인 취향이기도 하지만 타겟을 생각해도 필요하다. 많은 정보를 들이밀면 나라도 도망간다.
Frontend
프론트는 고민이 길지 않았다. 내가 제일 많이 다뤄봤고 레퍼런스도 가장 많은 스택으로 갔다.
- Next.js + TypeScript — SSR을 해본 게 Next.js뿐이기도 하고, 익숙함과 시장성을 같이 챙겼다.
- Tailwind CSS v4 — 여러 CSS 프레임워크 중에 가장 생산성이 좋지 않을까 싶다. 컴포넌트 단위로 React를 짜는 흐름과도 잘 맞는다.
@theme로 색·간격을 토큰으로 잡아두고, 컴포넌트엔 hex를 직접 쓰지 않기로 했다. 디자인은 참고로Claude Desgin이나Open Design을 통해서 만들어 보려고 한다. - Biome — 원래 ESLint + Prettier 두 개를 설치했지만
Biome은 단일에 Rust 언어로 개발되어 더욱 빠르고 설정이 단순하다. 확장성만 따지면 ESLint 생태계가 더 넓지만, 이 규모엔 가벼움이 더 맞다고 봤다. - Vitest — 테스트 러너. Jest와 고민했는데 ESM·TS를 기본으로 지원하고 설정이 가벼워서, 요즘 Vite/Next 생태계엔 Vitest가 더 자연스러웠다. AI를 통해서 TDD로 진행하지 않을까 싶다.
shadcn 같은 컴포넌트 킷은 일부러 안 쓰도록 한다. 개발 속도가 빠르긴 하지만, 앞서 말했듯이 요즘 유행하는 기술들을 다 직접 써보고 싶었다. Claude Design으로 디자인을 뽑을 예정이다. 고생길 예약
우선 이렇게만 생각해 두었고, 차차 개발하면서 바뀌거나 할 것이다.
Backend
본론부터 AI가 대부분을 도와줄 것이다.
별도 서버를 띄우는 대신 Next.js 하나로 가기로 했다. 굳이 독립 서버를 굴릴 이유가 없다고 판단했고, 복잡도를 줄이는 것도 설계 판단이라고 봤다. DB는 Supabase(Postgres)를 사용할 것 같다.
최근에 SQL 공부를 했었기 때문에 필기로만 공부했던 SQL을 실제로 좀 써보는 계기가 될 것 같다. 물론 AI가 95%는 도와주겠지만 말이다.
스크래핑은,
- 성분 사전은 식약처 공공데이터에서 가져온다.
- 제품별 전성분은 각 브랜드 자사몰에서 직접 모은다.
모은 데이터는 성분명을 표준화하고, 두 제품이 얼마나 닮았는지 점수로 만든 뒤, 미리 계산해서 저장해둔다. 닮은 정도를 어떻게 점수로 만들지는 따로 한 편을 들여 다룰 생각이다. 이 글에서 거기까지 들어가면 기획 글이 아니라 수학 공부가 되기 때문에 넘어가겠다. (내가 봐도 무슨 말인지 모름)
이 프로젝트에서 중요하게 본 것
흥미로 시작했지만 누군가에게 보여줄 수 있는 프로젝트여야 하기 때문에 잘 돌아가는 것도 중요하지만, 어떤 판단을 했는지가 보여야 했다. 그래서 만들기 전에 몇 가지 기준을 정했다.
AI를 도구로 다루는 법
요즘 코드는 AI가 많이 짜준다. 그래서 얼마나 잘 짜느냐만큼이나 얼마나 잘 부리느냐도 중요해졌다고 봤다. 이 프로젝트에서는 AI를 단순 자동완성이 아니라 하나의 작업 흐름으로 다뤄보기로 했다.
- 프로젝트 규칙(스택·컨벤션·테스트 범위)을
CLAUDE.md에 적어두고, 매번 설명하지 않아도 일관되게 작업하도록 한다. - 반복되는 작업(예: 새 브랜드 스크래퍼 추가)은 직접 만든 스킬로 절차화한다.
- 코드는 Claude에서, Claude 내부에서 Codex로 리뷰하는 식으로 교차 검증한다.
여러 만들어진 하네스도 있는 것 같은데 좀 더 알아보고 사용할지 말지 의사결정하려고 한다.
TDD
전부 TDD로 짜지는 않기로 했다. UI까지 전부 테스트로 감싸면 생산성이 많이 떨어지고 그렇게까지는 무의미하다고 보았기에 대신 핵심 로직에만 TDD를 적용하려고 한다. 생각한 부분은 아래와 같다.
- 성분 파싱, 성분 정규화 등 입출력이 명확하고 버그가 치명적인 부분
- TDD를 작성하는 부분은 RED-GREEN-REFACTOR로, 테스트를 먼저 쓰고 통과시키는 방식으로 진행
- 스크래퍼는 저장해둔 HTML(픽스처)로 테스트해서 실제 네트워크 없이 검증
어디에 테스트를 쓰고 어디에 안 쓸지 판단하는 것도 역량이라고 생각했다.
비용
개인 프로젝트라 비용도 현실적인 제약이다. 그래서 최대한 AI와 대화를 하여 어떻게 캐싱을 할 것인지, 로직이 대략적으로 어떻게 이루어지는지 물어봤다.
- 매칭 결과는 조회할 때 계산하지 않고, 데이터를 적재하는 시점에 미리 계산(precompute)해둔다. 사용자가 보는 화면은 만들어둔 결과를 읽기만 하니 빠르고 싸다.
- 별도 백엔드 서버를 띄우지 않는다. 요청 시점에 무거운 계산이 없으니 독립 서버를 굴릴 이유가 크지 않았다. 복잡도를 줄이는 것도 설계 판단이라고 봤다.
정리
이 프로젝트에서 보고 싶은 건 세 가지다.
- AI를 얼마나 잘 부리는가, 규칙·스킬·교차 리뷰로 작업 흐름 만들기
- 테스트할 가치가 있는 곳을 골라 TDD 적용하기
- 부담 없는 단순한 구조 유지하기
마치며
오랜만에 해보는 개인 프로젝트다. 오랜만이니만큼 꾸준하게 잘 해내고 싶다. 어떻게든 결실을 맺어서 좋은 결과가 뒤따라 왔으면 좋겠다는 마음이다.
다음 글부터는 실제 설계와 구현으로 들어갈 것 같다.
-
- 기술 스택 선정 이유
-
- 스크래퍼 설계, 브랜드별 어댑터와 테스트
-
- 성분 정규화와 스코어링 공식
댓글
Giscus is not configured yet.
Add the NEXT_PUBLIC_GISCUS_REPO, NEXT_PUBLIC_GISCUS_REPO_ID, NEXT_PUBLIC_GISCUS_CATEGORY, and NEXT_PUBLIC_GISCUS_CATEGORY_ID environment variables.