토리스가 제품을 만드는 방식

토리스(Toris Inc.)는 1인 소프트웨어 스튜디오입니다. 기획자, 디자이너, 프론트엔드, 백엔드, 인프라 담당이 모두 한 사람이라는 뜻이고, 그래서 워크플로가 곧 팀입니다. 사람이 부족한 만큼 프로세스와 자동화가 그 자리를 대신해야 하고, 어떤 도구를 왜 쓰는지에 대한 기준이 흐려지면 곧바로 품질이 흔들립니다.

이 글은 토리스가 제품을 기획에서 운영까지 어떤 방식으로 만드는지, 각 단계에서 어떤 도구와 품질 게이트를 두는지, 그리고 그 선택들의 트레이드오프가 무엇인지 정리한 공개 문서입니다. 자체 제품과 클라이언트 프로젝트 모두 같은 골격 위에서 돌아갑니다.

전체 파이프라인

기획 → 설계 → 개발 → 품질 게이트 → 배포 → 운영/피드백 → 다시 기획

단계는 다섯이지만 실제로는 순환 구조입니다. 운영에서 수집한 피드백이 다음 기획의 입력이 되고, 이 사이클을 짧게 유지하는 것이 1인 스튜디오가 규모의 열세를 상쇄하는 방법이라고 생각합니다.

1. 기획 — 문서가 첫 번째 결과물

코드를 열기 전에 세 가지를 먼저 문서로 만듭니다.

1. 요구사항 분석

   • 기능 명세: 무엇을 만들고, 무엇을 만들지 않을지를 명시합니다. “만들지 않을 것” 목록이 특히 중요합니다. 1인 스튜디오에서 스코프 관리 실패는 곧 일정 실패이기 때문입니다.
   • 기술 스택 선정: 기본값은 이미 검증된 스택(아래 참조)이고, 이탈할 때만 이유를 적습니다.
   • 아키텍처 설계: 다이어그램 한 장 수준으로 시작합니다. 초기 과설계는 피합니다.

2. 프로젝트 초기 설정

   • 레포지토리 생성과 개발 환경 구성
   • CI/CD 파이프라인을 첫 커밋 시점에 설정합니다. 나중에 붙이는 CI는 결국 안 붙기 때문입니다.

여기서의 트레이드오프: 문서화에 쓰는 시간은 당장의 개발 속도를 늦춥니다. 그래도 유지하는 이유는, 혼자 일할수록 “3개월 뒤의 나”가 사실상 다른 팀원이고, 그 사람에게 인수인계할 수단이 문서뿐이기 때문입니다.

2. 표준 스택 — 선택지를 줄이는 것이 속도다

토리스의 기본 스택은 다음과 같습니다.

Frontend

기획 → 디자인 시스템 → 컴포넌트 개발 → 상태 관리 → 테스트 → 배포

• React / Next.js — 프론트엔드 프레임워크
• TypeScript — 타입 안전성 확보
• Tailwind CSS — 스타일링
• Jest / React Testing Library — 테스트

Backend

API 설계 → 데이터베이스 설계 → 서버 구현 → 테스트 → 배포

• Node.js / Express — 서버
• PostgreSQL / MongoDB — 데이터 성격에 따라 선택 (관계가 명확하면 PostgreSQL, 스키마가 유동적이면 MongoDB)
• Jest / Supertest — API 테스트
• Docker — 컨테이너화

DevOps

코드 커밋 → CI 파이프라인 → 자동 테스트 → 배포 → 모니터링

• GitHub Actions — CI/CD
• Vercel / AWS — 프론트엔드는 Vercel, 인프라 제어가 필요한 워크로드는 AWS
• Sentry — 에러 추적

왜 이 조합인가 — 트레이드오프

• 프론트와 백엔드를 모두 TypeScript/JavaScript로 통일한 것은 언어별 최적 도구를 포기하는 대신 컨텍스트 스위칭 비용을 없애는 선택입니다. 혼자서 하루에 프론트·백엔드·인프라를 오가는 구조에서는 언어 통일의 이득이 더 큽니다.
• Vercel을 기본 배포처로 쓰는 것은 인프라 자유도를 일부 포기하고 운영 부담을 사는 선택입니다. 서버 관리에 쓸 시간이 없다는 제약을 인정한 결과이며, Vercel로 감당이 안 되는 요구(장시간 작업, 세밀한 네트워크 제어 등)가 있을 때만 AWS로 갑니다.
• Tailwind CSS는 디자인 시스템을 코드에 밀착시키는 대신 마크업이 장황해지는 비용을 치릅니다. 별도 디자이너 없이 일관된 UI를 유지해야 하는 상황에서는 유틸리티 클래스의 제약이 오히려 디자인 가드레일 역할을 합니다.

핵심 원칙은 하나입니다. 프로젝트마다 스택을 새로 고르지 않는다. 새 도구 평가에 쓰는 시간은 1인 스튜디오에서 가장 비싼 비용이고, 표준 스택에서 이탈할 때는 문서에 그 이유를 남깁니다.

3. 개발 — 작업 관리와 브랜치 전략

이슈 관리

• GitHub Issues로 모든 작업을 추적합니다. 별도 프로젝트 관리 도구를 두지 않는 이유는 단순합니다. 코드와 이슈가 같은 곳에 있어야 혼자서도 관리가 유지되기 때문입니다.
• 우선순위를 명시하고 진행 상황을 이슈에 기록합니다. 이슈가 곧 작업 로그이자 회고 자료가 됩니다.

브랜치 전략

• 기능별 브랜치를 따서 작업하고, PR을 통해 기본 브랜치에 병합합니다.
• 1인 개발에서도 PR을 만드는 이유: PR은 리뷰 요청서이기 전에 변경 단위의 기록입니다. 셀프 리뷰라도 diff를 한 번 다시 보는 과정에서 잡히는 실수가 적지 않고, 나중에 “이 변경이 왜 있었지”를 추적하는 단위가 됩니다.

개발 순서

1. Frontend — 컴포넌트 설계·구현, 상태 관리, UI/UX 다듬기
2. Backend — API 설계·구현, 데이터베이스 설계, 인증/인가
3. 통합 — 단위 테스트, 통합 테스트, 필요 시 E2E 테스트

4. 품질 게이트 — 사람이 없으면 게이트가 막는다

리뷰어가 없는 구조에서 품질을 지키는 방법은 자동화된 게이트뿐입니다. 토리스의 게이트는 다음 순서로 걸립니다.

1. 타입 체크 — TypeScript가 첫 번째 리뷰어입니다.
2. 자동 테스트 — 단위 테스트(Jest/RTL), API 테스트(Jest/Supertest)가 CI에서 실행됩니다. 통과하지 못하면 병합되지 않습니다.
3. CI 파이프라인 — GitHub Actions가 커밋마다 빌드와 테스트를 돌립니다.
4. 배포 후 모니터링 — Sentry 에러 추적과 성능 모니터링이 배포 이후의 게이트 역할을 합니다.

테스트 커버리지에 대한 입장도 트레이드오프입니다. 모든 코드에 테스트를 쓰는 것은 1인 리소스로는 비현실적이므로, 깨졌을 때 비용이 큰 경로(결제·인증·데이터 변형 로직, 공개 API)에 테스트를 집중하고 UI의 세부는 얇게 갑니다.

5. 배포와 운영

배포 자동화

• Docker 컨테이너화로 환경 차이를 제거합니다.
• 클라우드 배포(Vercel, AWS)는 CI에 연결되어 있어, 병합이 곧 배포 후보가 됩니다.
• 수동 배포 절차를 남기지 않는 것이 원칙입니다. “나만 아는 배포 순서”는 1인 스튜디오에서 가장 위험한 단일 장애점입니다.

운영 최적화

• 성능 모니터링 — 배포 후 성능 지표를 확인하고 회귀를 추적합니다.
• 에러 추적 — Sentry로 런타임 에러를 수집합니다. 사용자가 신고하기 전에 아는 것이 목표입니다.
• 사용자 피드백 수집 — 피드백은 다음 사이클의 기획 입력으로 들어갑니다.

클라이언트 프로젝트 — 주 단위 공유로 신뢰를 만든다

자체 제품과 클라이언트 프로젝트의 개발 골격은 같지만, 클라이언트 워크에는 한 겹이 더 있습니다. 주 단위 공유입니다.

1인 스튜디오에 일을 맡기는 클라이언트의 가장 큰 불안은 “진행이 보이지 않는 것”입니다. 그래서 토리스는 다음을 주 단위 리듬으로 유지합니다.

• 이번 주에 한 것 / 다음 주에 할 것 / 막힌 것을 정리해 공유합니다. 막힌 것을 숨기지 않는 것이 핵심입니다. 문제는 늦게 알릴수록 비싸집니다.
• 진행 상황은 말이 아니라 볼 수 있는 것으로 보여줍니다. 배포된 미리보기 URL, 스크린샷과 데모 영상, 아키텍처 다이어그램 같은 시각 자료를 준비합니다.
• 스코프 변경은 구두로 처리하지 않고 문서(이슈)로 남깁니다. 서로를 보호하는 장치입니다.

이 방식의 트레이드오프도 분명합니다. 매주 정리·공유에 쓰는 시간은 개발 시간에서 나옵니다. 그럼에도 유지하는 이유는, 신뢰가 무너진 프로젝트를 복구하는 비용이 주간 공유 비용보다 항상 크기 때문입니다.

문서화와 지식 관리

• README — 모든 레포지토리는 클론 직후 실행까지의 경로를 README로 보장합니다.
• API 문서화 — 공개 API는 문서가 곧 인터페이스입니다.
• 기술 블로그 — 프로젝트 회고, 문제 해결 과정, 학습 내용을 이 블로그에 정리합니다. 글로 쓰는 과정 자체가 설계 검증이고, 공개된 기록은 스튜디오의 포트폴리오이기도 합니다.

지속적인 학습 — 스튜디오의 R&D

1인 스튜디오에서 학습은 복지가 아니라 생존입니다. 새 기술을 평가할 때는 다음 순서를 지킵니다.

1. 기초 학습 — 공식 문서를 먼저 읽고, 튜토리얼로 기본기를 확인합니다.
2. 실습 프로젝트 — 토이 프로젝트에 적용해 보고, 리팩토링하면서 실제 감각을 확인합니다. 클라이언트 프로젝트에 검증 안 된 기술을 바로 넣지 않기 위한 완충 단계입니다.
3. 심화와 환원 — 고급 패턴을 익히고, 오픈소스 기여나 블로그 글로 정리합니다.

이 과정을 거쳐 살아남은 기술만 표준 스택 후보가 됩니다.

정리

토리스의 워크플로를 한 문장으로 요약하면 이렇습니다.

사람이 하나뿐이므로, 반복되는 모든 것은 자동화하고, 판단이 필요한 모든 것은 문서로 남긴다.

• 표준 스택으로 선택 비용을 없애고
• CI·테스트·모니터링이 리뷰어의 빈자리를 메우고
• 주 단위 공유가 클라이언트와의 신뢰를 만들고
• 운영 피드백이 다음 기획으로 돌아오는 짧은 사이클

이 구조는 완성형이 아니라 계속 다듬는 중이며, 바뀔 때마다 이 문서도 갱신할 예정입니다.

참고 리소스

• MDN Web Docs — 웹 표준 참고 자료
• React 공식 문서 / TypeScript 공식 문서
• GitHub — 코드 관리와 이슈 추적
• Vercel / AWS — 배포 인프라