안드로이드 앱을 처음으로 스토어에 올려봤어요. 커밋 로그를 보면 이렇습니다.

2026-08-09  Initial commit: add stock calculator app and design mockup
2026-08-21  Play 테스트 트랙 게시

첫 커밋과 첫 업로드 사이가 12일이에요. 그 사이에 앱을 만들고, AdMob을 붙이고, 결제를 넣고, 서명 키를 만들고, 스토어 콘솔에 올렸습니다. 전부 처음 해보는 일이었어요.

먼저 솔직하게 밝히고 시작할게요. 이 글을 쓰는 시점에 앱은 아직 테스트 트랙에 있습니다. 공개 출시는 안 했어요. 그러니 이건 “출시 성공기”가 아니라 “빈손에서 스토어 콘솔까지 가는 데 뭐가 필요했나”의 기록입니다.

이 시리즈는 네 편이에요.

1. 무엇을 만들었고, 무엇을 안 만들었나 — 지금 이 글
2. 기획과 설계 — HTML 목업으로 빠르게 시작하고, 제때 놓아준 이야기
3. AdMob 붙이기 — 광고 세 종류와 동의, 그리고 계정 정지를 피하는 법
4. Play Store에 올리기 — 서명, 등록정보, 콘솔에 안 가는 법

첫 편인 이번 글에서는 무엇을 만들었는지, 그리고 그보다 훨씬 중요했던 무엇을 안 만들기로 했는지를 이야기할게요.

시작은 제 불편이었어요

주식이 물렸습니다. 더 사면 평단가가 내려간다는 건 아는데 얼마까지 내려가는지는 모르겠더라고요.

예를 들어 72,500원에 20주를 들고 있고 지금 가격이 58,000원이라고 해볼게요. 여기서 15주를 더 사면 평단가가 얼마가 될까요? 계산기 앱을 열어서 곱하기 두 번, 더하기 한 번, 나누기 한 번을 해야 나옵니다.

(72,500 × 20 + 58,000 × 15) ÷ 35 = 66,285.71…

그런데 계산하고 나면 진짜 궁금한 게 남아요. “66,000원까지 내리려면 몇 주를 더 사야 하지?”

이건 역산이라 계산기로는 못 풉니다. 손으로 식을 세워야 해요.

x = q₁(p₁ − t) / (t − p₂)

이걸 매번 종이에 쓰고 있는 저를 발견한 날, 앱을 만들기로 했습니다.

만든 것 — 두 가지 질문에만 답합니다

“물타기 계산기”라는 이름을 붙였고, 하는 일은 딱 둘이에요.

물타기 — 이렇게 사면 평단가가 어디까지 내려가나 목표 평단가 — 거기까지 가려면 얼마나 더 사야 하나

여기에 딸린 게 몇 개 있습니다. 계산 결과를 저장하고 종목별로 모아 보는 이력, 500,000 ÷ 69,000 같은 식을 그대로 칠 수 있는 계산기 키패드, 그리고 라이트/다크 모드와 열한 개 언어.

여기까지예요. 기능 목록이 이게 전부입니다.

기획의 절반은 안 만들 것을 정하는 일이었어요

만들다 보면 자꾸 붙이고 싶어져요. 실제로 세 번 흔들렸고, 세 번 다 안 하기로 했습니다. 나중에는 저장소 README에 아예 “하지 않는 것” 절을 따로 뒀어요.

시세 연동을 하지 않습니다

“현재가를 자동으로 가져오면 편하지 않나?” 당연히 편하죠. 그런데 시세는 초 단위로 바뀌고, 무료로 안정적으로 받아올 방법이 마땅치 않습니다.

손으로 넣게 하면 화면에 늘 낡은 숫자가 뜹니다. 그리고 낡은 시세로 계산한 수익률은 그냥 틀린 수익률이에요.

틀린 손익은 없는 것만 못합니다.

게다가 한 번 이 선을 넘으면 “그럼 실시간은?” “그럼 알림은?”으로 끝없이 갑니다. 2주짜리 프로젝트가 아니게 돼요.

보유 자산 관리를 하지 않습니다

앱에 “종목”이라는 개념이 있어요. 삼성전자에 계산 두 건, 카카오에 한 건, 이런 식으로요. 그런데 이 종목은 증권사 계좌와 연결되지 않습니다. 보유 수량도 평단가도 들고 있지 않아요.

이름과 아이콘과 목록에서의 자리, 그게 전부입니다.

이유는 하나예요. 계산은 가정이니까요. “이렇게 사면 어떻게 되나”를 굴려본 것이지 실제로 산 게 아닙니다. 종목이 “내 자산”을 뜻하게 두는 순간, 저장된 기록이 “내 계좌 현황”처럼 읽히고 사용자는 앱이 모르는 것을 안다고 믿게 돼요.

그래서 이력 화면 발치에 이 한 줄이 늘 적혀 있습니다.

실제 매매가 아닌 계산 기록입니다

서버를 두지 않습니다

계정도 로그인도 동기화도 없어요. 기록은 기기 안에만 있습니다.

편의를 포기한 것이지만 얻은 게 있어요. 개인정보 처리방침에 “계산은 이 기기를 떠나지 않습니다”를 그냥 사실로 적을 수 있습니다. 지킬 수 없는 약속을 적는 것보다 이쪽이 훨씬 낫고, 무엇보다 개인 개발자가 남의 금융 데이터를 서버에 들고 있는 건 감당할 일이 아니더라고요.

2주 동안 무슨 일이 있었나

커밋 로그를 그대로 옮기면 이렇습니다.

앞의 열흘은 만드는 시간이었고, 마지막 이틀이 올리는 시간이었어요.

그런데 체감상 그 이틀이 앞의 열흘만큼 길었습니다. 서명 키, 광고 단위, 결제 상품, 등록정보, 스크린샷, 정책 설문. 코드를 짜는 일이 아니라 절차를 통과하는 일이라 검색으로도 잘 안 나오더라고요.

그 이틀 이야기가 이 시리즈의 3·4편입니다.

작업을 끝내고 보니

다음 글은 만드는 쪽 이야기예요. Figma 대신 HTML 목업 한 장으로 시작한 이유와, 혼자 만들 때 합의할 상대가 없다는 문제를 어떻게 풀었는지를 다룹니다. 그리고 그 목업을 왜 나중에 놓아줬는지도요.

👉 2 — 기획과 설계 - Figma 대신 HTML 목업으로 시작했고, 나중에 놓아줬어요