1인으로 수익화 자산을 여러 개 굴리면 금방 난장판이 된다. 앱 2개, 블로그 5개, 서명키, 계정, API 키가 흩어지면 “그 앱 코드 어디 있지”부터 막힌다. 나는 이걸 하나의 상위 폴더(컨테이너)로 묶어 관리한다. 실제 구조와 그렇게 정한 이유를 공개한다.
컨테이너는 ‘git 저장소’가 아니라 ‘인덱스’다
핵심 결정 하나: 상위 폴더 자체는 git 저장소로 만들지 않는다. 각 코드 자산은 자기만의 독립 저장소로 두고, 컨테이너는 그것들을 담아 인덱싱만 한다. 이렇게 하면 코드 이력이 엉키지 않고, 자산별로 따로 배포·백업·권한 관리를 할 수 있다. 앱 하나를 외주와 공유해도 다른 자산이 딸려가지 않는다.
portfolio/
├── README.md ← 마스터 인덱스 (뭐가 어디 있나)
├── 카탈로그.md ← 각 자산이 '무엇이고 왜'(정체성)
├── app/ ← 앱 자산 (각자 독립 repo)
├── blog/ ← 블로그 운영 문서
├── docs/ ← 공통 문서
└── keys/ ← 서명키 (버전관리 제외, 별도 백업)문서를 두 층으로 나눈다: ‘어디 있나’ vs ‘무엇이고 왜’
인덱스가 하나면 결국 다시 뒤죽박죽이 된다. 그래서 두 문서로 쪼갰다.
- README = 위치 인덱스: 어떤 자산이 있고, 상태가 뭐고, 진입 문서가 어딘지. 표 한 장으로 한눈에. “지금 뭐가 있고 각 상태가 어떤지”를 3초에 파악하는 용도다.
- 카탈로그 = 정체성 문서: 각 앱이 무엇이고 왜 만들었고 뭐가 특별한지. 나중에 “우리 자산 뭐 있지”, “아이디어 섞을 거 없나”의 출발점이 된다.
위치와 정체성을 분리하니, 자산이 늘어도 각 문서가 자기 역할만 해서 안 무거워진다.
비밀은 절대 커밋하지 않는다
서명키(.jks)·서비스 계정·API 키는 컨테이너 안에 두되 버전관리에서 제외하고, 이 기기 바깥에 따로 백업한다. 업로드 키를 잃으면 같은 앱으로 업데이트를 못 올리기 때문에, 이건 타협 없이 지킨다. 실수로 커밋되면 공개 저장소에 영원히 남으니, .gitignore와 별도 백업을 동시에 건다.
규칙 하나가 구조를 지탱한다
자산이 하나둘 늘 때마다 README 표에 한 줄 추가하고 진입 문서(개발현황·인덱스)를 확보한다. “새 걸 만들 때마다 인덱스에 등록”이라는 규칙 하나가, 포트폴리오가 커져도 안 무너지게 하는 뼈대였다. 도구가 아니라 규칙이 관리의 핵심이다 — 폴더 구조는 거들 뿐이고, “등록하는 습관”이 실제로 난장판을 막는다.
이 구조가 실제로 도움 된 순간
구조의 값어치는 자산이 늘 때 드러난다. 최근 새 앱을 이 컨테이너에 편입할 때, README 표에 한 줄 추가 + 진입 문서 링크만으로 정리가 끝났다. 앱 코드는 자기 repo에 그대로 있으니 이력이 안 엉켰고, 문서만 컨테이너가 인덱싱했다. “그 앱 코드 어디 있더라”, “이 키 어느 앱 거지” 같은 시간 낭비가 사라졌다. 진행 상태는 별도 관리 도구로 추적하고, 이 컨테이너는 “무엇이 어디 있나”의 정적 지도 역할만 한다. 역할을 좁게 나눈 덕에 자산이 늘어도 관리가 안 무너진다.