사이트를 여는 앱을 만들었더니 설치할 이유가 사라졌습니다.
코딩 도구의 사용량을 매번 사이트에 들어가지 않고 보고 싶다는 것이 시작이었습니다. 그런데 초기 버전은 공식 사용량 페이지를 브라우저로 열어 주는 앱이 됐습니다. 인증을 직접 다루면 위험이 크니 그 부분을 피한 결과였습니다. 빌드는 성공했고 설치도 됐습니다. 다만 사용자 입장에서는 즐겨찾기와 다를 것이 없었습니다. 요구의 핵심은 사이트를 여는 것이 아니라 사용량을 눈에 보이게 유지하는 것이었는데, 기술적으로 어려운 부분을 피하면서 그 핵심까지 같이 잘라 낸 것입니다. 이 프로젝트에서 가장 큰 낭비는 문법 오류가 아니라 요구를 잘못 읽은 데서 나왔습니다.
처음 요구는 페이지가 아니라 상태였다
처음 받은 요구는 사용량을 빨리 확인하고 싶다는 것이었습니다. 이 문장은 두 가지로 읽힙니다.
하나는 사이트에 빨리 접근하고 싶다는 뜻입니다. 다른 하나는 확인하러 가지 않아도 숫자가 보이면 좋겠다는 뜻입니다.
초기 구현은 앞쪽으로 읽었습니다. 그래서 페이지를 여는 앱이 나왔습니다.
정리된 요구는 뒤쪽이었습니다. 앱을 열지 않아도 숫자가 보여야 하고, 홈 화면 위젯이나 알림, 메뉴 막대처럼 상시 표시되는 자리가 있어야 한다는 것이었습니다.
| 같은 요구의 두 해석 | 만들어지는 것 |
|---|---|
| 사이트에 빨리 들어가고 싶다 | 즐겨찾기와 같은 앱 |
| 보러 가지 않아도 숫자가 보였으면 한다 | 위젯과 상시 표시 앱 |
기술적으로 쉬운 쪽으로 축소됐다
페이지를 여는 앱이 나온 이유는 분명했습니다. 인증을 직접 다루면 로그인 처리와 토큰 보관이 따라오고, 실패 가능성이 커집니다.
그 위험을 피하려고 앱이 하는 일을 줄였습니다. 기술적 위험은 실제로 줄었습니다.
다만 함께 줄어든 것이 설치할 이유였습니다. 단순한 제품은 핵심 행동이 적고 명확한 제품이지, 핵심 가치를 제거한 제품이 아닙니다.
이 구분은 도구에 개발을 맡길 때 특히 중요합니다. 요청은 완성하기 쉬운 방향으로 축소되기 쉽고, 왜 이 앱을 설치하는지에 대한 답은 자동으로 지켜지지 않습니다.
먼저 확정했어야 할 것은 최종 화면이었다
다시 시작할 때 처음 한 일은 화면을 그리는 것이었습니다. 사용자가 매일 보게 될 자리에 무엇이 어떤 형태로 떠 있어야 하는지 정했습니다.
표시할 항목과 자릿수, 두 서비스를 함께 볼지 하나만 볼지, 축약해서 보일 때의 형태까지 먼저 적었습니다.
이 화면이 정해지자 필요한 데이터가 정해졌고, 데이터가 정해지자 어떤 경로로 가져와야 하는지가 정해졌습니다.
순서가 반대였을 때는 가져오기 쉬운 데이터에 맞춰 화면이 밀렸습니다. 그래서 매일 보게 될 화면을 먼저 확정하는 것을 규칙으로 정했습니다.
불가능한 요구는 대체안까지 같이 낸다
요구 중에는 그 플랫폼에서 불가능한 것도 있었습니다. 휴대폰 상단 표시줄 안에 원하는 숫자를 직접 넣는 일이 그랬습니다.
이때 불가능하다는 말로 끝내면 요구가 사라집니다. 사용자가 원한 것은 그 자리 자체가 아니라 고개를 돌리지 않아도 숫자가 보이는 상태였습니다.
그래서 상시 알림과 화면 위에 겹쳐 띄우는 작은 표시를 묶어 가장 가까운 형태를 만들었습니다.
불가능한 기능은 초기에 알리되, 원하던 효과에 가장 가까운 대체안을 같이 내는 것을 규칙으로 남겼습니다.
| 요구 | 플랫폼 제약 | 대체안 |
|---|---|---|
| 상단 표시줄에 숫자 넣기 | 직접 넣을 수 없음 | 상시 알림과 겹쳐 띄우는 표시를 결합 |
| 1분마다 갱신 | 배터리와 통신 낭비 | 사용 중에는 자주, 변화 없으면 간격을 늘림 |
| 여러 기기에서 같은 값 | 기기마다 로그인 상태가 다름 | 각 기기가 자기 자격으로 직접 조회 |
기기끼리 연결하는 구조도 접었다
초기에는 컴퓨터가 값을 가져오고 휴대폰이 그것을 받아 오는 구조를 썼습니다. 인증을 한 곳에서만 다루면 되니 편해 보였습니다.
실제로는 조건이 붙습니다. 컴퓨터가 켜져 있어야 하고, 두 기기가 같은 망에 있어야 하고, 주소가 바뀌면 다시 넣어야 합니다.
설정 부담이 사용자에게 넘어간 것입니다. 앱이 자기 데이터 구조를 사용자에게 떠넘긴 셈이 됐습니다.
그래서 각 기기가 자기 안의 로그인 상태를 그대로 재사용해 직접 조회하는 방식으로 바꿨습니다. 표시 앱은 가능한 한 그 기기에 이미 있는 상태를 쓰는 편이 낫습니다.
요구 해석 오류가 가장 비쌌다
이 프로젝트에서 시간을 가장 많이 잡아먹은 것은 코드의 오류가 아니었습니다. 처음에 무엇을 만들 것인지 잘못 읽은 부분이었습니다.
앱을 열지 않고 보는 화면이라는 성공 조건을 처음에 확정했다면 즐겨찾기형 앱은 만들지 않아도 됐습니다.
그래서 기록에 남긴 것은 기술 결론이 아니라 순서였습니다. 최종 화면을 먼저 정하고, 단순한 링크와 실제 기능을 구분하고, 사용자의 강한 반응을 감정이 아니라 요구 정보로 받는 것입니다.
- 매일 보게 될 최종 화면을 먼저 확정한다
- 링크를 여는 기능과 실제 기능을 구분한다
- 불가능한 요구는 대체안과 함께 초기에 알린다
자주 묻는 질문
Q. 왜 페이지를 여는 앱이 실패인가요?
A. 빌드와 설치는 성공했지만 사용자가 얻는 것이 즐겨찾기와 같았기 때문입니다. 요구의 핵심은 사이트 접근이 아니라 보러 가지 않아도 숫자가 보이는 상태였습니다.
Q. 기능을 줄이는 것이 나쁜가요?
A. 핵심 행동을 줄이는 것과 핵심 가치를 없애는 것은 다릅니다. 이번에는 인증 위험을 피하려다 설치할 이유까지 같이 사라졌습니다.
Q. 플랫폼에서 안 되는 기능은 어떻게 하나요?
A. 불가능하다는 말로 끝내지 않고 원하던 효과에 가장 가까운 대체안을 같이 냅니다. 상단 표시줄에 숫자를 직접 넣을 수 없어 상시 알림과 겹쳐 띄우는 표시를 결합했습니다.
확인 자료
- AI 코드 사용량 표시 앱 개발 전 과정 기록 (2026-07-30 최초 작성, 2026-08-29까지 추가)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.