Post

AI 활용 결제·OMS Nest 프로젝트 회고 #1

Posted Updated
By SuInWoo
9 min read
AI 활용 결제·OMS Nest 프로젝트 회고 #1

AI 활용 결제·OMS Nest 프로젝트 회고 #1

1. 프로젝트 개요 · 결심 배경

  • 프로젝트 이름: AI 활용 결제·OMS Nest 프로젝트

  • 기간: 2026-03 ~ 미정

  • 목적: 개인 학습과 동시에, 실무에 바로 가져갈 수 있는 결제/OMS 백엔드 아키텍처를 만들고, AI를 “팀원”처럼 활용하는 개발 프로세스를 실험하는 것

2. 개인 학습 · 성장 목표

왜 NestJS인가

  • 현재 회사에서는 Express를 사용하고 있지만, 구조화된 모듈/DI/데코레이터 기반의 NestJS를 직접 써보며 프레임워크 관점을 넓히고 싶었다.

  • 회사 도메인(결제·OMS)을 NestJS 위에서 다시 모델링해 보면서, 도메인 이해도를 한 단계 더 끌어올리고자 했다.

무엇을 경험하고 싶은가

  • TDD와 테스트 가능한 구조를 실제 도메인(결제/주문/유저)에 적용해 보는 경험

  • k6 등을 활용해 다양한 트래픽 패턴과 장애/에러 상황을 직접 설계·실행·해석해 보는 경험

  • AI를 어떻게하면 다른사람과 다르게, 더 효율적으로 사용할 수 있는가에 대한 경험

3. 왜 AI·Cursor를 팀처럼 쓰기로 했는가

문제의식

  • 혼자 하는 사이드 프로젝트라도 결제/주문/유저까지 들어가면 도메인 복잡도가 커져, 설계·문서·테스트를 모두 혼자 챙기기 어렵다.

  • 반복적인 설정/보일러플레이트와 리뷰가 많아, “사고”에 쓸 수 있는 시간이 줄어든다.

목표

  • 설계·리뷰·문서화의 상당 부분을 AI에게 맡기고, 사람은 도메인 정의와 의사결정에 집중한다.

  • 최근 실무에서도 AI 활용 능력을 요구하는 흐름 속에서, “혼자서 여러 명이 하는 것처럼” 프로젝트 전체를 읽고 관리하는 연습을 하고자 했다.

  • 실제 팀 회의처럼 역할(시니어, DB, QA, 보안, 운영, 비즈니스, 노션 등)을 분리하고, 각 역할의 관점에서 끊임없이 질문·리뷰를 받는 개발 프로세스를 만든다.

4. 초기 목표 설정

기술 스택

  • Backend: NestJS, TypeScript

  • DB: PostgreSQL

  • 인프라: Local -> Docker(이 후 예정)

  • 성능/테스트: k6, jest

도메인 범위

  • 결제

  • 주문(OMS)

  • 유저

비기능 목표

  • 가독성 좋은 모듈 구조

  • 테스트 가능성

  • 확장 가능한 결제/주문 플로우

5. 개발 프로세스 설계 (AI 팀 구성 아이디어)

Cursor를 팀처럼 꾸리기로 한 이유

  • 시니어/페어/QA/DB/보안/운영/비즈니스/노션 등 역할을 명시적으로 나눠서, “한 사람이 모든 역할을 동시에 한다”는 부담에서 벗어나기 위해서.

파트 구분

  • 개발·아키텍처 파트: 시니어담당자, 페어담당자(반대의견제시)

  • 데이터·성능 파트: DB담당자, 성능담당자

  • 품질·안정성 파트: QA담당자, 에러담당자, 로그담당자

  • 보안·운영 파트: 보안담당자, 운영담당자

  • 비즈니스·유지보수 파트: 비즈니스담당자, 유지보수담당자

  • 문서화·명세 파트: 비즈니스문서담당자, 노션리뷰담당자, API명세담당자

역할 정의

  • 시니어담당자: 설계, 모듈 구조, 변경 용이성 리뷰

  • 페어담당자: 반대 의견 제시

  • DB담당자: 스키마, 인덱스, 쿼리 성능

  • QA담당자: 테스트 전략, 엣지 케이스

  • 보안담당자: 인증/인가, 민감정보 보호, 로그 마스킹

  • 성능담당자: 응답 시간, 병목, k6 기반 성능 관리

  • 에러담당자·로그담당자: 에러 코드/메시지 정책, 추적 가능한 로그 설계

  • 비즈니스·유지보수담당자: MVP 범위 설정, 운영자 관점에서의 가독성과 관리자 기능

  • 노션리뷰담당자·비즈니스문서담당자: 요구사항·정책 정리, docs/notion/*와 Notion 싱크

워크플로우 초안

  • 요구사항 정리 → 아키텍처/ERD 구상 → 모듈별 설계 → 구현 → 테스트 → 회고

  • 각 단계마다 “역할 회의”를 한 번씩 거치고, 중요한 결정은 회의록(docs/meetings/*.md)과 노션에 함께 남긴다.

6. 이후 어떻게 디벨롭할 계획인가

단계 1 – 도메인 안정화

  • 결제/주문/유저 각각에 대해 유스케이스를 정의하고, API·DB 설계를 점진적으로 다듬기

  • 공통 코드/공통 테이블 전략 정리 (docs/erd.md, docs/schema.sql와 연동)

단계 2 – 품질·테스트 강화

  • 유닛/통합 테스트

  • k6를 활용한 부하 테스트 시나리오 작성 및 정기 실행으로, 주요 플로우(주문→결제)의 성능을 숫자로 관리

  • 장애/에러 케이스 정의 및 핸들링 전략을 문서와 테스트 코드로 동시에 관리

단계 3 – 운영·문서화

  • 운영 관점에서 필요한 관리자 기능/로그/모니터링 정리

  • 로그에 orderId, userId, requestId 등 공통 식별자를 남기는 규칙을 적용

  • Notion + docs/를 싱크 맞춰 문서화하고, 회의 내용은 docs/meetings/*.md와 노션 회의록에 아카이빙

단계 4 – 실무 적용 가능 수준으로 리파인

  • 예: PG 연동/웹훅 처리/정산 시나리오 등, 현실적인 요구사항을 하나씩 끌어와 반영

  • 돈/정산/환불 도메인은 비즈니스·DB·QA 역할이 함께 협의해, 보수적으로 단계별 확장

7. 개인 회고 · 느낀 점

이번 챕터에서 느낀 점

  • AI를 “팀처럼” 쓰려면, 도구 성능보다도 역할 정의와 워크플로우 합의가 더 중요하다는 걸 느꼈다.

  • 실제로 역할 회의를 하듯 질문을 던지면, 혼자 개발할 때 보이지 않던 리스크(정합성, 로그, 운영, 비즈니스)가 잘 드러난다.

  • 아직 처음 사용하다 보니 자연스럽게 사용하는 것이 어렵다.

배운 것

  • 혼자 하는 프로젝트에도 시니어/DB/QA/보안/운영/비즈니스 관점을 분리해두면, 나중에 실무로 옮길 때 바로 팀 언어로 설명할 수 있다는 점.
Project
토이프로젝트
This post is licensed under CC BY 4.0 by the author.