안녕하세요! 그로스로그 입니다!😊 🌱
곧 사용자 테스트에 들어가는 앱, 출시를 앞두고 붙이는 결제 시스템, 그리고 발표를 앞두고 정리한 생각. 세 편 다 아직 끝나지 않은 상태에서 쓴 기록입니다. 3기 10회차 세 편입니다.
3기 10회차, 2025년 7월 말에서 8월입니다. 3기의 마지막 회차예요. 이번에는 내보내기 직전의 기록 세 편이 모였습니다.
01
🎵 Flutter로 시니어 웰니스 사운드 앱 MVP
송지원 님
친구를 돕게 되어 만들고 있는 시니어용 사운드 테라피 앱 개발기입니다.
기능 소개로 시작해 Repository Pattern과 Fallback 전략, 듀얼 오디오 믹싱, 시니어 친화 UI, DB 구조, 성능까지 갑니다.
상태를 처음에 밝혀요. "사용자 테스트는 아직 진행하지 않았지만 곧 진행 예정이며, 1인 개발로 첫 버전을 만들고 있다."
마지막 문단이 솔직합니다.
3기 2·5·8회차에서도 이분의 기록을 소개해드렸습니다. SQL 기초 정리와 이산수학 개념 정리를 하던 분이 앱을 하나 만들고 있어요.
조금 더 들어가 보면
🔀 실패하면 로컬로
구조를 바꾼 이유가 명확합니다.
그래서 Repository Pattern과 Fallback을 붙였어요.
Fallback Repository : 로컬 JSON 로드
API 호출 실패 시 자동으로 Fallback 데이터를 반환
두 개를 준비해두고 앞의 것이 실패하면 뒤로 넘어가는 구조입니다.
이게 시니어용 앱이라는 점에서 특히 맞는 선택이에요. 사용자가 어디서 어떤 네트워크로 쓸지 모르니까요. 지하철이나 병원 대기실처럼 신호가 약한 곳에서 앱이 그냥 멈추면 안 됩니다.
그리고 3기 5·6회차 큐레이션에서 소개해드린 이야기와 이어집니다. UI가 인터페이스만 알고 구현을 모르게 만든 것요. 박상훈 님의 테스트 글, 최준성 님의 OCP 글에 나온 그 구조입니다.
여기서는 그 덕에 셋을 얻었어요. 오프라인 대응, 테스트 용이성, 그리고 환경 전환이요.
.env를 활용했다.ENV=production → Supabase 우선같은 코드로 개발과 운영을 다르게 돌리는 것입니다.
🎚️ 플레이어를 두 개 두기
핵심 기능 구현이 단순합니다.
just_audio 패키지로 플레이어를 2개 두고, 각 볼륨을 독립적으로 조절할 수 있도록 했다. 자연음은 무한 반복하고, 사용자가 슬라이더로 메인/자연음 비율을 조정하면 즉시 반영된다.섞는 게 아니라 두 개를 동시에 트는 방식입니다.
미리 섞어둔 음원을 만들면 조합마다 파일이 필요합니다. 메인 트랙 열 개에 자연음 여섯 개면 예순 개죠. 따로 틀면 열여섯 개면 되고, 비율도 사용자가 정할 수 있습니다.
그리고 못 한 것도 적었어요.
앱이 뒤로 가면 소리가 끊긴다는 뜻인데, 수면·명상용 앱에서는 치명적입니다. 화면을 끄고 쓰는 게 정상이니까요.
이걸 빠뜨렸다고 적어둔 게 이 기록의 성격입니다. 기능 목록에는 "백그라운드 재생 지원"이 있는데, 아래에서 아직 안 됐다고 밝혀요.
👵 큰 글씨만으로는 안 된다
시니어 UI 설계에서 세 가지를 들었습니다.
큰 터치 영역과 직관적인 아이콘
버튼 클릭 시 햅틱 피드백 제공
괄호 안이 재미있습니다. 4단계로 만들어놨는데 줄어들 것 같다고요. 선택지가 많으면 오히려 고르기 어렵다는 걸 알아챈 겁니다.
햅틱 피드백을 넣은 것도 눈에 띕니다. 화면이 잘 안 보이는 상황에서 눌렸다는 걸 손끝으로 알려주는 장치예요. 시각에만 기대지 않는 설계입니다.
그리고 데이터 구조에도 배려가 들어 있습니다.
"좋았다/별로였다"만 저장하지 않는다는 것. 언제 어떤 상황에서 들었는지를 같이 남겨야 추천이 나아지니까요.
📝 원문에서는 이렇게 닫습니다
마지막 문단이 이 기록에서 가장 좋습니다.
아직 개발 걸음마면서 올해 참 여러가지 무리하게 해나가고 있다. 근데 계속 이것저것 해나가다 보면 경험이 쌓이면서 무기로 전환될 날이 오지 않을까 싶다.
"무리하게 해나가고 있다"를 그대로 적었습니다.
3기 2회차에서 이분의 SQL 기초 노트를 소개해드렸어요. SELECT와 ORDER BY를 정리하던 게 몇 달 전입니다. 그 사이에 Repository Pattern과 오디오 믹싱과 PostgreSQL 다대다 관계까지 왔어요.
그리고 마지막 한 줄.
큐레이터 노트
만드는 중에 쓴 기록이라 골랐습니다.
개발기는 대개 끝나고 씁니다. 다 만들고 나서 "이렇게 만들었습니다"로요. 그러면 중간에 뭘 몰랐고 뭘 바꿨는지가 안 남습니다.
이 기록은 진행 중에 썼어요. 그래서 "초기에는 직접 호출했는데 이렇게 바꿨다", "백그라운드 재생을 생각 못했다", "4단계는 줄어들 것 같다" 같은 문장이 있습니다.
3기 2회차의 SQL 기초 정리와 나란히 놓으면 몇 달 사이의 거리가 보입니다. 성장일지가 회차로 쌓이면 그런 게 남아요.
02
💳 앱 스토어·플레이스토어 백엔드 결제 핸들러
이민경 님
정식 출시를 앞두고 스토어 결제를 서버에 붙인 기록입니다.
전체 흐름을 세 단계로 정리했어요. 스토어 → 백엔드 웹훅, 백엔드 → DB, 앱 → 백엔드 조회요.
그리고 설계 원칙을 세 개로 못박았습니다. 멱등성, 검증 우선, 조회 단일화요.
Google과 Apple 각각의 사전 준비와 검증 API까지 적었습니다.
3기 6·8회차에서도 이분의 기록을 소개해드렸습니다. JWT 정리와 무한 순환 참조요.
조금 더 들어가 보면
🔁 앱이 아니라 스토어가 알려준다
흐름 정리가 이 글의 뼈대입니다.
BE → DB : 검증 결과를 기준으로 구독 스냅샷을 upsert
App → BE : 앱은 조회 API만 호출해서 자신의 구독 상태를 가져감
앱이 "결제했어요"라고 알려주는 구조가 아닙니다.
이게 핵심입니다. 앱이 알려주는 방식이면 앱을 조작해서 결제한 척할 수 있어요. 그리고 갱신이나 환불처럼 앱을 안 켠 사이에 일어나는 일은 알 방법이 없습니다.
구독은 특히 그렇습니다. 한 달 뒤 자동 갱신이 될지 안 될지는 스토어만 알아요. 사용자가 애플 설정에서 취소하면 우리 앱은 아무것도 모르고요.
그래서 스토어가 서버로 알림을 보내는 구조입니다. 앱은 결과만 조회하고요.
🔒 세 원칙이 각각 막는 것
세 단어가 각각 다른 사고를 막습니다.
멱등성부터 보면요.
notificationId/notificationUUID)를 유니크 키로 저장해서 중복 처리 방지. 중복이면 즉시 200 OK로 ACK.같은 알림이 두 번 올 수 있습니다. 우리 서버가 응답을 늦게 주면 스토어가 재전송하거든요. 그때 구독 기간을 두 번 늘려주면 안 되죠.
고유 ID를 유니크 키로 걸어두면 두 번째는 저장 자체가 안 됩니다. 그리고 즉시 200을 돌려주는 것도 중요해요. 안 그러면 스토어가 계속 재시도합니다.
검증 우선은 이겁니다.
알림 내용을 그대로 믿지 않는다는 것. 알림은 "뭔가 일어났다"는 신호로만 쓰고, 실제 상태는 스토어에 다시 물어봅니다.
3기 6회차 큐레이션에서 소개해드린 이분의 JWT 정리와 같은 성격입니다. 받은 걸 그대로 쓰지 않고 검증을 거치는 것요.
조회 단일화는 앱 쪽 이야기입니다. 앱이 스토어와 서버 양쪽을 보면 둘이 다를 때 어느 쪽이 맞는지 문제가 생겨요. 서버 하나만 보게 하면 그 혼란이 없습니다.
🍎 두 스토어의 차이
Google과 Apple의 준비 과정을 따로 적었는데, 방식이 다릅니다.
purchases.subscriptions.get(...) 호출로 상태를 받음. 입력: packageName, subscriptionId, purchaseTokenApple :
verifyReceipt 호출(프로덕션 → status==21007이면 샌드박스 재시도). 입력: base64 영수증 + Shared SecretApple 쪽 괄호가 실무 지식입니다.
21007은 "이건 샌드박스 영수증인데 프로덕션에 물어봤다"는 뜻이에요. 테스트 결제와 실제 결제를 URL로 구분하는데, 심사 중에는 애플이 샌드박스로 테스트하거든요.
그래서 프로덕션에 먼저 물어보고 21007이 오면 샌드박스로 다시 묻는 게 애플의 공식 권장 순서입니다. 이걸 모르면 심사에서 결제가 안 된다고 반려당해요.
그리고 응답 처리도 짚었습니다.
latest_receipt_info 중 가장 최신 항목으로 상태 판단영수증에 갱신 이력이 전부 들어 있어서, 그중 최신 것을 봐야 지금 상태를 알 수 있습니다.
알림 받는 경로도 다릅니다. Google은 Cloud Pub/Sub Push를 거치고, Apple은 URL로 직접 받아요. 같은 "구독 알림"인데 인프라가 다릅니다.
📝 원문에서는 이렇게 씁니다
시작과 끝에 감정이 있습니다.
이 과정에서 나는 독점적인 애플 생태계에 큰 환멸을 느꼈는데...그건 다음에 정리해야겠다
"다음에 정리해야겠다"로 미뤄뒀어요.
그리고 자기 몫도 정확히 적었습니다.
설계를 자기가 했다고 하지 않았습니다. 받아서 이해하고 정리한 게 자기 일이라고요.
이게 정직한 기록입니다. 그리고 "이해하고 정리하는" 것도 일이에요. 남이 그려준 구조를 따라 만들려면 왜 그런 구조인지 알아야 하니까요. 이 글에 멱등성과 검증 우선이 왜 필요한지가 적혀 있는 게 그 증거고요.
마지막 한 줄이 짧습니다.
큐레이터 노트
정상 경로 바깥을 먼저 설계한 것이 이 기록을 고른 이유입니다.
결제를 붙일 때 처음 떠올리는 건 "사용자가 결제하면 권한을 준다"입니다. 그런데 이 글의 원칙 셋은 전부 그 바깥이에요. 알림이 두 번 오면, 알림이 거짓이면, 앱과 서버가 다르면요.
3기 6회차 큐레이션에서 조성호 님의 결제 망취소 기록을 1차에서 다뤘다고 언급했는데, 같은 영역입니다. 돈이 오가는 자리는 실패 경로가 본론이라는 것요.
그리고 6회차의 JWT, 8회차의 무한 순환 참조, 이번의 결제. 세 편 다 같은 프로젝트가 커가는 과정입니다. 인증을 붙이고, 엔티티가 얽히고, 이제 결제를 붙여 출시를 앞두고 있어요.
03
🎤 우리는 항상 개발자였다 — 세미나 준비
안정섭 님
그로스로그 세미나 발표를 준비하며 쓴 기록입니다.
발표 주제와 구조, 준비하며 던진 질문들, 전하고 싶었던 메시지를 차례로 적었어요.
발표 흐름이 네 시기로 나뉩니다. 코딩만 잘하면 되던 때 → 협업과 설계 → AI 이후 → 아직 정의되지 않은 미래요.
제목이 곧 결론입니다. "우리는 항상 개발자였다."
조금 더 들어가 보면
🕰️ 자기 커리어가 목차가 되다
발표 구조를 짜는 과정이 적혀 있습니다.
"내 커리어 자체가 콘티"라는 표현이 좋습니다.
그리고 네 시기가 나옵니다.
2. 협업과 설계가 중요해지던 시기(코로나 시기)
3. AI 이후, 맥락을 연결하는 시대(GPT 출시 이후)
4. 그리고 아직 정의되지 않은 미래의 개발자
시기 구분에 개인의 시점이 괄호로 붙어 있습니다. 업계 연표가 아니라 본인이 겪은 순서예요. 그래서 일반론이 안 됩니다.
네 번째가 비어 있는 것도 눈에 띕니다. "아직 정의되지 않은"이라고 두고 답을 안 내렸어요. 발표에서 흔히 마지막에 전망을 넣는데, 여기서는 그 자리를 열어뒀습니다.
🪞 자료를 위한 질문이 아니었다
준비하며 던진 질문 다섯 개가 적혀 있습니다.
나는 왜 이 직업을 계속 하고 싶어하는 걸까?
개발자는 정말 AI에 의해 대체될까?
도구가 발전할수록, 개발자에게 기대되는 것은 무엇일까?
나는 앞으로 어떤 개발자가 되어야 하는가?
그리고 한 줄이 붙습니다.
발표 준비가 자기 정리가 된 경우입니다.
다섯 질문 중 셋이 "나"로 시작합니다. 남에게 설명할 내용을 고르는 게 아니라 자기가 답을 찾아야 하는 것들이었어요.
🧭 변한 것과 변하지 않은 것
전하고 싶었던 메시지가 뒤에 나옵니다.
지금 우리가 겪는 변화는, 잘못된 것도 실패도 아니다. 단지 우리와 시대가 그리고 개발자가 성장하고 있다는 증거다.
"잘못된 것도 실패도 아니다"가 이 발표의 중심 같습니다.
코딩만 하고 싶었는데 회의에 들어가고 기획을 하게 되면, 내가 개발자에서 멀어지는 것 같은 느낌이 들거든요. 그 느낌에 대한 답이에요.
그래서 결론이 이렇게 됩니다.
그리고 제목이 다시 나옵니다.
그래서 나는, 우리는 항상 개발자였다.
변한 것(기술·역할)과 변하지 않은 것(문제를 풀고 싶은 마음)을 갈라놓은 구조입니다. 그래서 "변했다"와 "그래도 같다"가 둘 다 참이 됩니다.
📝 원문에서는 이렇게 씁니다
준비하게 된 계기부터 적었습니다.
"개발자란 어떤 직업일까?" 라는 고민은 예전부터 계속해왔던 주제다. 그 고민을 정리하고 나눌 수 있는 기회가 생겼다는 건, 내게도 하나의 전환점이 될 수 있겠다고 생각했다.
전부터 있던 질문에 자리가 생긴 것이라는 이야기입니다.
그리고 마무리에 이런 문장이 있어요.
"말로만 떠도는 것"에서 "공유할 수 있는 이야기"로.
이게 발표 준비의 값어치를 정확히 짚은 표현입니다. 머릿속에 있는 것과 남에게 전달할 수 있게 정리된 것은 다르니까요. 3기 9회차 큐레이션에서 김영진 님이 "가르치기 위해 더 꼼꼼하게 공부하고 복습하고"라고 적은 것과 같은 이야기이기도 합니다.
큐레이터 노트
코드가 한 줄도 없는 기록이라 골랐습니다.
성장일지에는 기술 글이 많습니다. 그런데 매뉴얼의 선정 기준에도 적혀 있듯, 길이나 기술 함량이 기준은 아닙니다. 남는 게 있는가가 기준이고요.
이 글은 남는 게 분명합니다. 네 시기 구분은 다른 사람도 자기 커리어에 대볼 수 있는 틀이고, "개발자답지 않다고 의심하지 말라"는 문장은 지금 그 고민을 하고 있는 사람에게 바로 닿습니다.
그리고 3기 마지막 회차에 이 글이 있는 것도 우연 같지 않습니다. 이번 회차 세 편이 전부 아직 안 끝난 것을 앞둔 기록인데, 이 글만은 끝난 뒤에 쓴 것이에요. 발표를 마치고 남은 것을 적었으니까요.
💡 세 편을 겹쳐 읽으며
세 편의 결과물이 다릅니다. 앱 하나, 결제 시스템 하나, 발표 하나요.
그런데 셋 다 곧 사람들 앞에 나갈 것을 준비하는 기록입니다.
아직 안 끝난 상태로 적었다
송지원 님은 "사용자 테스트는 아직 진행하지 않았지만 곧 진행 예정"이라고 밝히고 시작합니다. 그리고 백그라운드 재생을 못 했다고 적었어요.
이민경 님은 "이제 곧...정식 앱 출시를 앞두고"로 시작하고, Google과 Apple 준비를 "(진행 중)"이라고 표시했습니다.
안정섭 님은 발표를 마쳤지만 네 번째 시기를 비워뒀습니다. "아직 정의되지 않은 미래의 개발자"라고요.
끝나고 쓰면 이런 문장이 안 나옵니다. 다 되고 나서 돌아보면 못 한 것은 기억에서 지워지고, 진행 중이던 단계는 완료로 적히니까요.
정상 경로 바깥을 먼저 본다
세 편 모두 잘 될 때가 아니라 안 될 때를 설계했습니다.
송지원 님의 Fallback은 네트워크가 안 될 때를 위한 것입니다. 잘 되면 안 쓰이는 코드예요.
이민경 님의 멱등성과 검증은 알림이 두 번 오거나 거짓일 때를 막습니다. 정상이면 아무 일도 안 하고요.
안정섭 님의 메시지도 그렇습니다. "개발자답지 않다"고 느껴질 때를 위한 이야기니까요.
만들 때 시간이 가장 많이 드는 게 이 부분이고, 안 만들면 나중에 가장 크게 터지는 부분이기도 합니다.
내 몫을 정확히 적기
기록 방식에도 공통점이 있습니다. 자기가 한 만큼만 적었다는 것.
이민경 님은 "큰 틀은 유능한 개발팀원 분이 설계해주셨고, 나는 이해하고 정리해서"라고 밝혔습니다.
송지원 님은 "아직 개발 걸음마"라고 적었고요.
안정섭 님은 발표 내용이 "내 커리어"에서 나왔다고 밝혔습니다. 일반론이 아니라 자기 경험이라는 것요.
과장하지 않으면 기록이 오래 갑니다. 나중에 다시 읽어도 그때의 자기가 그대로 남아 있으니까요.
이번 회차에서 가져갈 것
1. 데이터 접근을 UI에서 떼어내기.
Repository로 감싸면 오프라인 대응·테스트·환경 전환이 한꺼번에 풀립니다. 세 가지가 같은 원인이었던 겁니다.
2. 결제 알림은 멱등하게 저장하기.
스토어는 응답이 늦으면 같은 알림을 다시 보냅니다. 고유 ID를 유니크 키로 걸고, 중복이면 바로 200을 돌려주세요.
3. 알림 내용을 그대로 믿지 않기.
알림은 신호로만 쓰고 상태는 스토어에 다시 물어보세요. 앱이 알려주는 결제는 조작될 수 있습니다.
4. Apple 영수증은 프로덕션 먼저, 21007이면 샌드박스.
심사 중에는 애플이 샌드박스로 테스트합니다. 순서를 모르면 결제 안 된다고 반려당합니다.
5. 발표 준비를 자기 정리로 쓰기.
머릿속에 떠도는 생각은 남에게 설명할 수 있게 만들 때 비로소 정리됩니다. 가르치려고 공부하는 것과 같은 이치입니다.
여기까지가 3기 2차 큐레이션입니다. 2025년 3월부터 8월까지, 열 회차에 서른 편을 다시 읽었어요.
3기는 인원이 늘면서 폭이 넓어진 기수였습니다. 첫 회차에서 120만 건 배치 최적화와 1억 건 인덱스 이야기가 나왔고, 중간에 도커·쿠버네티스 스터디가 여러 사람의 노트를 만들었고, 후반에는 오퍼레이터와 GitOps까지 갔습니다.
그러면서도 아두이노를 처음 켜본 기록과 파이썬 오답노트가 같은 자리에 함께 있었어요. 그리고 마지막 회차가 아직 안 끝난 것들로 채워진 것도 좋았습니다. 완성된 결과보다 만드는 중인 사람이 많은 기수였다는 뜻이니까요.
좋은 글 남겨주신 송지원 님, 이민경 님, 안정섭 님께 감사드립니다. 그리고 3기 열 회차를 함께 채워주신 모든 멤버분들께도요! 😊
4기 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 지난 기수의 성장일지를 다시 읽으면서, 그때 소개해드리지 못한 글을 하나씩 꺼내고 있습니다.
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.