내 프로젝트를 남이 쓰는 서비스 기준으로 점검하기

캐시 · Claude Code로 서비스 만들기 · · 좋아요 0 · 답글 0

연재 Claude Code로 서비스 만들기 6/12편

소개

제 깃허브 저장소와 로컬 프로젝트를 강의가 꼽은 서비스 기준으로 세어, 배포 자동화는 15일 동안 54번 실패 없이 돌았지만 사용자 로그인 코드와 설계 문서는 0건이라는 것을 확인했습니다. 만든 도구는 많은데 남에게 내놓은 것이 있는지 점검해 보고 싶은 분께 권합니다.

이 스터디의 제목이 "프로토타입을 넘어서, 남이 실제로 쓰는 서비스 만들기"입니다. 스터디장 로미오는 4주 뒤 목표를 이렇게 잡았습니다.

4주 뒤에 여러분이 꼭 한 사람에게 전달할 수 있는 서비스를 만들어 봤으면 좋겠다는 바람이 있습니다.

그리고 프로토타입을 넘을 때 실제로 시간이 드는 곳을 네 가지로 꼽았습니다. 디자인, 보안, 로그인, 서비스를 열었을 때의 예외 처리입니다.

저는 바이오와 제약 데이터를 분석하면서 도구를 계속 만들어 왔습니다. 런칭 스프린트에서는 프로젝트 14개에 결제 코드가 0줄이라는 것을 세었고, 4주차에는 citation-verifier의 파일 12개가 전부 6월 20일 그대로라는 것을 확인했습니다. 그때 결론은 "만든 것은 많고 출시한 것은 없다"였습니다.

그 뒤로 47일이 지났습니다. 이번에는 같은 것을 다시 세는 대신, 이 스터디가 제시한 기준으로 각도를 바꿔 봤습니다. 커밋 수는 이미 23기에서 세었으니 빼고, 질문을 셋으로 좁혔습니다.

  1. 외부에서 열리는 주소가 붙은 것이 몇 개인가

  2. 그 주소에 남이 남긴 흔적이 있는가

  3. 1주차 과제인 설계 문서가 기존 프로젝트에 존재하는가

세 번째 질문이 이번 주의 과제와 바로 맞물립니다. 이번 주 과제는 디스커버와 인터뷰로 설계 문서까지 뽑는 것인데, 저는 그 문서 없이 지금까지 만들어 왔기 때문입니다.

참고: 스터디 기준 하네스는 스터디장이 만든 게이트킷이지만 설치는 선택이라고 안내했습니다. 저는 설치하지 않은 상태에서 기존 프로젝트를 측정했습니다.

진행 방법

사용 도구: Claude Code, git, gh CLI, curl, Python 3

Step 1. 외부 공개 주소 확인

먼저 버셀부터 확인했습니다. 강의가 프런트를 버셀로 잡았기 때문입니다.

which vercel            # vercel not found
ls "$HOME/Library/Application Support/com.vercel.cli"
# agent-preferences.json  auth.json  config.json

CLI는 없고 인증 파일은 있습니다. 계정은 있는데 명령줄 도구를 설치한 적이 없다는 뜻입니다. vercel ls로 전체 배포 목록을 받지 못했으므로, 대신 깃허브 저장소에 등록된 홈페이지 주소를 훑었습니다.

gh repo list kakyungkim --limit 100 --json name,homepageUrl,stargazerCount,isPrivate

저장소 18개 중 외부 주소가 걸린 것은 셋이었습니다. 실제로 열리는지 확인했습니다.

for u in https://kakyungkim.github.io https://summer-form.vercel.app https://pie-canvas-lite.vercel.app; do
  curl -s -o /dev/null -w "%{http_code} $u\n" --max-time 15 "$u"
done

주소

응답

정체

kakyungkim.github.io

200

Jekyll 블로그. GitHub Pages

summer-form.vercel.app

200

form studio 프런트 목업

pie-canvas-lite.vercel.app

404

홈페이지 주소는 남아 있고 배포는 사라졌습니다

배포 주소를 가진 것은 3개이고 그중 하나는 죽어 있습니다. summer-form은 열리지만 README를 열어 보니 목업이라고 스스로 적어 두었습니다. 데이터는 lib/mock/*만 쓰고 외부 호출이 0건이라는 규칙이 README에 있습니다. 주소가 살아 있다는 것과 서비스라는 것은 다른 말이었습니다.

Step 2. 남이 남긴 흔적 집계

응답하는 주소에 사람이 왔는지를 봐야 했습니다. 깃허브가 제공하는 지표 가운데 확인 가능한 것만 모았습니다.

gh api repos/kakyungkim/<repo>/traffic/views --jq '[.count,.uniques]'
gh api repos/kakyungkim/<repo> --jq '.stargazers_count'

항목

값

공개 저장소 전체 스타

1개

포크

1개

스타와 포크가 모두 0인 저장소

17 / 18

14일 조회수가 0인 저장소

13 / 18

14일 조회수가 있는 저장소

해커톤 146회(방문자 16명), pharmasignal 3회, 하네스 2건 각 1~2회

스타 1개와 포크 1개는 전부 korea-agentic-hackathon-2026 하나에 붙어 있습니다. 9월 25일에 만든 해커톤 제출 저장소이고, 팀이 따로 있어 기여자가 1명으로 잡힙니다. 블로그 저장소의 14일 조회수는 0입니다.

여기서 반대 방향의 결과가 하나 나왔습니다. 서비스가 아닌 쪽에서는 사람이 있었습니다.

git -C ~/projects/autobiox/BioProject01 shortlog -sn --all
git -C ~/projects/autobiox/BioProject02 shortlog -sn --all

저장소

기여자

제 커밋 : 남의 커밋

BioProject01

5명

467 : 82

BioProject02

5명

342 : 330

autobiox는 연구 프로젝트 두 개를 묶은 작업 공간이고 루트 자체는 git 저장소가 아닙니다. 그 안의 두 저장소에는 남이 쓴 커밋이 412개 있습니다. 서비스 사용자는 아니고 공동 연구자이지만, 제 코드베이스에서 다른 사람 손이 닿은 유일한 곳입니다.

Step 3. 프로토타입을 넘는 요소의 코드 존재 여부

강의가 꼽은 네 가지(디자인, 보안, 로그인, 예외 처리)를 코드에서 셀 수 있는 형태로 바꿨습니다. 자작 저장소 7개와 클론 1개를 대상으로 돌렸습니다.

pat = {'env': r'os\.environ|getenv|process\.env|dotenv',
       'auth': r'\b(oauth|jwt|login|authenticate|Bearer|api[_-]?key)\b',
       'except': r'^\s*(except\b|catch\s*\()',
       'logging': r'logging\.|logger\.|getLogger|console\.error'}

저장소

코드 파일

환경변수

인증

except

로깅

테스트

CI

VeriVar

158

43

9

70

8

37

1

econ-radar

9

16

11

18

0

0

3

paper-analysis-harness

26

6

0

71

2

0

1

admet-split-audit

26

0

0

22

0

0

0

paper-radar

3

2

0

2

0

0

1

citation-verifier

6

0

0

2

0

1

0

paper-production-harness

2

0

0

0

0

0

0

econ-radar의 인증 11건을 열어 보니 전부 뉴스레터 발송 API에 붙이는 헤더였습니다.

econ-radar/scripts/send_email.py:65:  req.add_header("Authorization", "Token %s" % API_KEY)

내가 외부 서비스에 로그인하는 코드이지, 남이 내 서비스에 로그인하는 코드가 아닙니다. 사용자 로그인을 구현한 저장소는 0개입니다.

배포 준비물도 셌습니다.

항목

값

.env.example 같은 설정 견본

0 / 8

LICENSE

3 / 8

Dockerfile, vercel.json 같은 배포 설정

0 / 7 (자작 기준)

결제 코드

0건

Step 4. 1주차 과제 산출물의 보유 여부

이번 주 과제가 설계 문서이므로, 제 프로젝트에 그런 문서가 있는지부터 세었습니다.

문서

자작 저장소 7개 기준

PRD

0건

아키텍처

0건

디스커버, 인터뷰 기록

0건

작업 목록(TASKS)

0건

검증 게이트(GATE)

0건

design.md라는 파일이 세 군데 있어 잠깐 걸렸는데, 열어 보니 전부 디자인 시스템 문서였습니다. 강의가 말하는 설계 문서와 이름만 같고 다른 것입니다.

README도 봤습니다. 4주차에 "누구를 위한 서비스냐"에 답하지 못한 것이 남아 있는지 확인하려는 것이었습니다.

항목

값

README에 사용 대상을 적은 저장소

0 / 8

README가 아예 없는 저장소

2개 (econ-radar, paper-radar)

README 분량 최대

admet-split-audit 852줄

852줄짜리 README가 있는 저장소에도 그 852줄 어디에도 누가 쓰는 것인지가 없었습니다.

Step 5. 배포 자동화의 실행 횟수

멈춘 것만 세면 한쪽으로 기울 것 같아 반대쪽도 쟀습니다.

gh run list --repo kakyungkim/econ-radar --limit 400 --json createdAt,name,conclusion

저장소

9/16 이후 실행

성공

워크플로

econ-radar

32회

32

텔레그램 매일, 이메일 매일, 주간 발행

kakyungkim.github.io

20회

20

Jekyll 빌드와 배포

paper-radar

2회

2

텔레그램 주간

합계

54회

54

15일 동안 54번 돌았고 실패가 0건입니다. 23기에 만들어 둔 발송 파이프라인이 지금도 매일 나갑니다. 다만 수신자는 저장소 문서에 적힌 약 20명이 마지막 기록이고, 이번에 새로 재지는 않았습니다.

Step 6. 로컬과 원격의 분리 판정

로컬만 보고 "멈췄다"고 잘못 쓴 적이 있어서, 이번에는 git fetch 먼저 돌리고 판정했습니다.

git -C ~/projects/econ-radar fetch -q origin && git -C ~/projects/econ-radar status -sb
## main...origin/main [behind 115]

저장소

로컬과 원격의 차이

econ-radar

115커밋 뒤처짐

paper-radar

1커밋 앞서고 16커밋 뒤처짐

kakyungkim.github.io

10커밋 뒤처짐

paper-production-harness

6커밋 앞서고 6커밋 뒤처짐

로컬 사본만 봤다면 econ-radar를 8월 7일에 멈춘 저장소로 적었을 텐데, 원격은 오늘 날짜로 돌아가고 있습니다.

Step 7. 23기에 적은 계획의 재확인

citation-verifier를 다시 열었습니다.

find ~/projects/citation-verifier -type f -not -path "*/.git/*" \
  -exec stat -f "%Sm %N" -t "%Y-%m-%d" {} \; | sort

파일 12개의 수정 시각이 전부 2026-06-20입니다. 커밋은 1개, 작업 트리는 깨끗하고 원격 저장소도 없습니다. 오늘 기준 102일이 지났고, 4주차에 이 저장소를 계속 대상으로 삼을지 다시 묻겠다고 적은 뒤로는 47일이 지났습니다. 그 사이 아무 파일도 열리지 않았습니다.

결과와 배운 점

측정 결과

2026-09-30 기준, ~/projects와 깃허브 계정 kakyungkim을 대상으로 측정했습니다.

항목

값

~/projects 폴더

19개 (git 저장소 8개, 그중 1개는 외부 클론)

깃허브 저장소

18개

외부에서 열리는 주소

3개 중 살아 있는 것 2개

그중 서비스가 아닌 것

블로그 1개, 목업 1개

공개 저장소 전체 스타

1개 (해커톤 저장소 하나에 전부)

14일 조회수가 0인 저장소

13 / 18

사용자 로그인 코드

0개 저장소

설정 견본(.env.example)

0 / 8

결제 코드

0건 (23기와 동일)

PRD, 아키텍처, 디스커버, 작업 목록, 검증 게이트

각 0건

README에 사용 대상 명시

0 / 8

9/16~9/30 배포 자동화 실행

54회, 실패 0

남이 쓴 커밋(autobiox 두 저장소)

412개

citation-verifier 파일 12개

전부 2026-06-20, 102일 경과

배운 점

  1. 운영은 돌아가는데 사용자가 없습니다. 15일에 54번 성공한 파이프라인과 스타 1개가 같은 계정에 있습니다. 23기에 "배포와 출시는 다른 말"이라고 적었는데, 이번에 재 보니 더 정확한 표현은 발행과 사용이 다른 말이라는 쪽입니다. 저는 매일 내보내고 있고, 받는 쪽에서 무엇이 일어나는지는 재 본 적이 없습니다.

  2. 인증 코드가 있다고 로그인이 있는 것은 아니었습니다. 인증 관련 매치가 20건 나왔을 때 "로그인은 어느 정도 되어 있다"고 쓸 뻔했습니다. 열어 보니 전부 제가 외부 API에 키를 붙이는 코드였습니다. 방향이 반대입니다. 강의가 꼽은 네 가지 중 로그인은 0에서 시작합니다.

  3. 852줄 README에도 누가 쓰는지가 없었습니다. 4주차에 "누구를 위한 서비스냐에서 3주 내내 못 나아갔다"고 적었고, 47일 뒤에도 8개 저장소 전부 같습니다. 852줄을 쓰면서도 그 질문을 적는 칸은 두지 않았습니다. 이번 주 과제인 디스커버가 바로 그 칸을 만드는 단계라 순서가 맞습니다.

  4. 설계 문서가 0건이라는 것이 제 작업 방식을 그대로 보여 줍니다. 저는 분석을 먼저 돌리고 문서는 결과를 정리할 때 씁니다. 그래서 README와 HANDOFF는 길고 PRD는 없습니다. 이 방식이 혼자 쓰는 도구에서는 문제가 되지 않았는데, 남에게 줄 것을 만들 때는 화면과 권한을 먼저 정해야 하고 그것을 적을 데가 필요합니다.

  5. 남이 쓴 흔적은 서비스가 아니라 연구 저장소에 있었습니다. 커밋 412개가 공동 연구자들의 것입니다. 제가 "남이 쓰는 것"을 만든 적이 없다고 단정하려다 이 숫자를 보고 멈췄습니다. 협업과 서비스는 다르지만, 남이 들어와 쓰는 규칙과 문서를 제가 이미 써 본 적은 있다는 뜻입니다.

시행착오

  • 결제 코드를 세는 정규식에 toss를 넣었더니 knowledge-site에서 22건이 걸렸습니다. 열어 보니 .quartz/ 아래 빌드 파일이었고, 매치의 정체는 CSS의 stripe(줄무늬)와 카멜 표기 안의 toSs였습니다. 게다가 이 저장소는 제가 만든 것이 아니라 jackyzha0/quartz를 클론한 것으로, 커밋 하나의 작성자가 봇입니다. 설치한 것을 자작으로 세는 실수와 부분 문자열이 걸리는 실수가 한 번에 겹쳤습니다. 자작 저장소만 다시 세니 결제 코드는 0건입니다.

  • 버셀 CLI가 없어서 vercel ls로 배포 전체를 받지 못했습니다. 깃허브 저장소의 홈페이지 주소로 대신했으므로, 깃허브에 연결되지 않은 배포가 있다면 이 측정에 잡히지 않습니다. 확인하지 못한 범위로 남겨 둡니다.

  • 로컬 저장소만 보고 econ-radar를 8월에 멈춘 것으로 적을 뻔했습니다. git fetch 뒤에 보니 115커밋 뒤처져 있었고 원격은 오늘도 돌고 있었습니다. 23기에 같은 실수를 한 적이 있어 이번에는 먼저 받아 왔습니다.

이 측정은 2026-09-30에 제 로컬 ~/projects와 깃허브 계정 하나를 대상으로 했습니다. 버셀 CLI가 없어 깃허브에 연결되지 않은 배포는 포함되지 않았고, 방문자 수치는 깃허브가 제공하는 14일 창에 한정됩니다.

도움 받은 글

  • 클코서비스 1주차 강의 (로미오): "한 사람에게 전달할 수 있는 서비스"라는 4주 목표, 프로토타입을 넘을 때 시간이 드는 네 가지(디자인, 보안, 로그인, 예외 처리), 바이브 코딩이 만드는 다섯 가지 부채, 디스커버에서 인터뷰를 거쳐 설계 문서까지 가는 1주차 범위

  • 런칭 스프린트 1주차와 4주차 사례글 (본인): 프로젝트 14개에 결제 코드 0줄, citation-verifier 파일 12개가 6월 20일 그대로라는 측정. 이번에 47일 뒤의 값을 같은 명령으로 다시 확인했습니다

  • 24시간 AI 서버 4주차 사례글 (본인): 로컬 저장소만 보고 원격 상태를 판정하면 안 된다는 것. 이번 측정에서 git fetch를 먼저 돌린 근거입니다

태그: #클코서비스