구독 기능 하나의 무게: 기술 통합의 보이지 않는 복잡성
단순해 보이는 기능
“안드로이드 앱에 구독 기능을 추가하자.”
계획은 단순했다. 사용자들이 프리미엄 기능을 사용할 수 있도록 월 구독 플랜을 만드는 것. 많은 앱들이 하고 있는 일이고, Google Play도 이를 위한 시스템을 제공한다.
얼마나 복잡할까?
펼쳐진 체크리스트
실제로 시작하니 필요한 작업들이 보이기 시작했다:
- 판매 상품의 ID를 앱에 연결 Google Play Console에서 상품을 생성하고, 그 ID를 앱 코드에 연결해야 한다.
- 백엔드에 Google Play Developer API 설정 구독 상태를 서버에서 확인하려면 API 연동이 필요하다.
- Receipt 검증 엔드포인트 구현 사용자가 정말로 결제했는지 서버에서 검증해야 한다. 클라이언트만 믿으면 안 된다.
- 사용자 플랜 관리 로직 누가 어떤 플랜을 쓰고 있는지, 언제 만료되는지, 갱신은 되었는지 관리해야 한다.
여기까지는 예상 범위 내였다. 복잡하지만 필요한 것들이다.
미로의 시작
문제는 환경 변수 설정부터 시작되었다.
Google Play Developer API를 사용하려면 Service Account가 필요하다. 그래서 Service Account Key를 생성하려고 했다.
Google Cloud Console로 이동.
“Service Account Key를 생성할 권한이 없습니다.”
뭐?
권한의 미로
권한을 얻으려면 어떻게 해야 하나?
구글링(아니, 이제는 AI에게 물어보기)을 하니 답이 나왔다.
Google Admin으로 가서 권한을 설정해야 한다.
Google Cloud Console이 아니라 Google Admin. 또 다른 시스템이다.
Google Admin에 로그인했다. 권한 설정 메뉴를 찾았다. 필요한 권한을 추가했다.
다시 Google Cloud Console로 돌아왔다.
이제 되나?
똥개 훈련
이 과정을 반복하면서 든 생각:
“이거 똥개 훈련시키는 거 같은데?”
시스템 A가 말한다: “이거 해” → 권한 없다 → 시스템 B로 가라 → 시스템 B: “여기서 이거 설정해” → 다시 시스템 A로 돌아옴 → 또 다른 권한 없다 → 시스템 C로 가라
끝없는 루프.
AI 시대의 개발
예전 같았으면 어땠을까?
각 단계마다 구글링을 했을 것이다. 스택 오버플로우를 뒤졌을 것이다. 공식 문서를 읽고 또 읽었을 것이다. 하루가 다 갔을 것이다.
지금은 Claude에게 물어본다:
“Google Play Developer API를 사용하려면 어떤 권한이 필요해?” “Service Account Key를 생성할 수 없는데 어떻게 해?” “Google Admin에서 어떤 설정을 해야 해?”
답은 빠르게 나온다. 정확하고 구체적이다.
정보 접근성은 확실히 좋아졌다.
하지만 여전히 피곤하다.
피곤함의 본질
왜 피곤할까?
정보가 없어서가 아니다. AI가 답을 알려주니까.
시스템의 복잡성 자체가 문제다.
Google Play 구독 시스템은:
- Google Play Console
- Google Cloud Console
- Google Admin
- 백엔드 서버
- 안드로이드 앱
최소 5개의 서로 다른 시스템을 오가며 설정해야 한다.
각 시스템은 자체 권한 체계를 가지고 있다. 각 시스템은 다른 UI를 가지고 있다. 각 시스템은 다른 용어를 사용한다.
인지 부하가 크다.
기술 부채가 아닌 생태계 부채
이것은 내 코드가 나쁘거나 설계가 잘못된 것이 아니다.
이것은 생태계의 복잡성이다.
Google이 나쁜 시스템을 만든 것도 아니다. 각 시스템은 나름의 이유로 존재한다:
- Play Console: 앱 배포 관리
- Cloud Console: 클라우드 리소스 관리
- Admin: 조직 권한 관리
문제는 이들이 서로 다른 시대에, 다른 팀에 의해, 다른 목적으로 만들어졌다는 것이다.
그리고 개발자는 이 모든 것을 이해하고 연결해야 한다.
기능 하나의 무게
“구독 기능 하나 추가하면 되지”라고 생각했다.
하지만 그 하나 뒤에는:
- 5개 이상의 시스템
- 10개 이상의 설정
- 20개 이상의 문서
- 수십 번의 시행착오
가 숨어있다.
번아웃의 순간
오늘은 여기서 멈췄다.
진이 다 빠졌다.
코드를 한 줄도 작성하지 못했다. 그냥 권한 설정만 했다.
생산적인 날이 아니었다.
하지만 이것도 개발의 현실이다.
AI는 만능이 아니다
AI 도구들은 정말 도움이 된다. Claude Code 없이 어떻게 개발했을까 싶다.
하지만 AI가 해결할 수 없는 것들이 있다:
- 시스템의 근본적 복잡성 여러 시스템을 오가는 것 자체는 여전히 인간이 해야 한다.
- 권한과 인증의 벽 AI는 권한을 대신 받아줄 수 없다.
- 인지 부하 여러 시스템의 멘탈 모델을 동시에 유지하는 것은 여전히 힘들다.
- 기다림 권한 설정, API 활성화, 전파 시간 등은 단축할 수 없다.
지속 가능한 개발
이런 날이 있다는 것을 인정해야 한다.
생산적이지 않은 날. 진이 빠지는 날. 똥개 훈련하는 느낌의 날.
이런 날은 쉬어야 한다.
억지로 밀어붙이면 번아웃이 온다. 그리고 번아웃은 회복하는 데 훨씬 오래 걸린다.
교훈
1. 기술 선택 시 통합 복잡도를 고려하라
“이 기능이 있네”가 아니라 “이 기능을 통합하는 데 얼마나 걸릴까”를 물어야 한다.
2. 문서상 단순함에 속지 말라
공식 문서는 항상 해피 패스만 보여준다. 실제로는 권한 문제, 설정 문제, 버전 문제 등이 존재한다.
3. 버퍼를 두어라
“하루면 되겠지”가 “사흘 걸렸네”가 되는 것이 당연하다. 특히 외부 플랫폼 통합은.
4. 쉬는 것도 일이다
진이 빠졌을 때 억지로 하는 것보다, 쉬었다가 맑은 정신으로 하는 것이 더 빠르다.
내일
내일 다시 시작할 것이다.
권한 설정은 끝났다. 이제 진짜 구현을 할 수 있다.
그리고 아마 또 다른 문제를 만날 것이다.
하지만 괜찮다. 이것이 개발이니까.
단순해 보이는 기능 하나에도 이렇게 많은 것들이 숨어있다.
그리고 그것을 해내는 것이 개발자다.
오늘은 쉰다. 내일은 다시 싸운다.