Stairno 0. 전체 로드맵

혼자 만드는 브랜드 Stairno의 개발 기록 시리즈 첫 글. 개발자가 아니어도 처음부터 따라올 수 있게 썼다. 처음 보는 용어는 링크를 누르면 용어 정리 글의 그 항목으로 간다.

1. Stairno가 뭔가

Stairno는 내가 만드는 것들을 한 이름 아래 모으는 브랜드다. 외주로 남의 일을 해 주고, 게임을 만들고, 작은 프로그램과 웹 서비스를 만들어 판다. 이 셋을 각각 따로 굴리면 이름도 셋, 사이트도 셋, 계정도 셋이 된다. 그래서 하나로 묶었다.

이름은 고트어(옛 게르만어의 하나)로 별이라는 뜻의 stairno에서 왔다. 영어로 읽으면 계단(stair)이 들어 있다. 바닥에서 한 칸씩 올라가는 별이라는 뜻으로 골랐다.

2. 사이트가 넷인 이유

실선은 지금 운영 중, 점선은 만들 예정

하는 일이 완전히 다르니 사이트도 나눴다. 외주를 맡기려는 사람과 게임을 찾는 사람이 같은 페이지에서 헤맬 이유가 없다. 허브는 그 사이에서 "Stairno는 이런 걸 한다"만 보여 주는 정문이다. 도메인은 넷 다 2026년 10월 17일에 샀다.

3. 계정은 하나인 이유

사이트가 넷이면 로그인과 결제도 넷이 되기 쉽다. 사이트마다 회원가입을 만들고, 사이트마다 결제사를 붙이고, 사이트마다 환불 절차를 두는 식이다. 혼자 운영하는 입장에서 이건 같은 일을 네 번 하고, 버그와 보안 구멍도 네 배가 된다는 뜻이다.

그래서 Amazon 계정처럼 만들기로 했다.

• Stairno 계정 하나로 허브를 뺀 모든 Stairno 사이트와 제품에 로그인한다
• 카드는 한 번만 등록한다
• 구매, 구독, 다운로드 내역은 계정 센터(account.stairno.com) 한 곳에서 본다
• 결제, 구독, 권한은 공용 API(api.stairno.com) 한 곳에서 처리한다

나머지 사이트는 로그인과 결제를 직접 만들지 않고, 이 둘을 불러다 쓰기만 한다. 위 그림에서 모든 화살표가 가운데 띠로 모이는 이유다. 허브에는 계정 화면도 결제도 없고, 헤더에 계정 메뉴 하나만 있다.

4. 로드맵

2026년 10월 18일에 순서를 정했다. 날짜는 두지 않고 순서만 둔다.

왜 이 순서인가

• 디자인 패키지가 맨 앞이다. 계정 센터 화면부터 모든 사이트가 허브와 같은 모양으로 시작하게 하려고. 사이트를 먼저 만들고 나중에 모양을 맞추면 사이트 수만큼 고쳐야 한다
• 계정과 API가 사이트보다 앞이다. 나머지 사이트가 전부 이 둘을 불러다 쓰기 때문이다. 서버는 이 둘뿐이고, 사이트는 소개 페이지로 시작해서 로그인과 결제가 필요한 곳만 나중에 붙인다
• 실제 결제는 9단계다. 진짜 돈을 받으려면 사업자등록과 결제사 계약이 먼저다. 그 전까지 결제는 전부 테스트 모드로 만들고, 전환은 열쇠만 바꾸면 되게 설계한다
• Works는 Labs 다음이다. 외주 사이트는 리뷰가 몇 개 쌓여야 쓸모가 생긴다. 그 전까지 외주는 외주 플랫폼에서 받는다

5. 지금 어디쯤인가

4단계가 끝났다. 운영 결제 리허설 10개가 모두 통과했고, 리허설용 스크립트와 접속 정보를 지우고, 공유 문서를 마크다운 원본에 맞추고, 쌓인 변경을 v0.4.3으로 냈다. 닫는 날의 이야기는 4a편 12절에 있다. 다음은 5단계 Labs인데, 그 전에 리허설에서 나온 일(계정 센터의 환불 요청, 로그인 유지, 찾아 놓은 버그 셋)을 먼저 한다.

일정이 이상하게 빠르다고 느낄 수 있다. 계획서에는 로그인 12주, 결제 23주라고 적어 뒀는데, 실제로는 코드가 하루 안에 들어갔다. 코드 대부분은 AI 코딩 에이전트(Claude Code)가 썼고, 나는 범위와 결정을 정하고, 결과를 확인하고, 대시보드 설정이나 카드 입력처럼 사람이 해야 하는 일을 했다. 다만 빨랐던 만큼 놓친 것도 있었고, 그건 각 글에 숨기지 않고 적었다.

6. 일하는 원칙

시리즈 전체에 깔린 원칙 넷이다. 각 글에서 다시 나온다.

1. 혼자 운영할 수 있는가. 기술은 "멋있어 보이는가"가 아니라 혼자 굴릴 때 덜 힘든가로 고른다. 언어는 하나(TypeScript), 서버는 남이 관리해 주는 것, 고정비는 0원에 가깝게
2. 문서가 먼저다. 코드를 짜기 전에 계획서, 요구사항 명세서, 설계 명세서를 쓴다. 문서와 코드가 어긋나면 같은 변경 안에서 둘 중 하나를 고친다
3. 테스트가 먼저다. TDD. 실패하는 테스트를 먼저 쓰고 통과시킨다
4. 운영에서 확인한다. 테스트 통과로 끝내지 않고, 단계가 끝날 때마다 실제 서비스 주소에서 인수 체크리스트를 하나씩 확인한다

7. 시리즈 목차

용어 정리 글은 다섯 개다.

8. 이 시리즈에 나오는 도구

이름만 보고 겁먹을 필요는 없다. 전부 "남이 만들어 둔 부품"이다.

9. 레포

다음 글: Stairno 1. 공용 디자인 패키지