App Store 첫 등록은 CI/CD가 있어도 절반은 수동이었다
CI/CD로 TestFlight 업로드까지 자동화해두고, App Store 첫 등록도 명령어 몇 줄이면 끝날 줄 알았다. 그런데 App ID를 만드는 첫 단계부터 fastlane produce가 막혔고, 결국 웹 UI에서 하나씩 눌러 등록했다. 자동화가 어디서 멈추는지, 그리고 준비 단계에서 나를 붙잡은 사소한 오류들을 순서대로…
CI/CD로 TestFlight 업로드까지 자동화해두고, App Store 첫 등록도 명령어 몇 줄이면 끝날 줄 알았다. 그런데 App ID를 만드는 첫 단계부터 fastlane produce가 막혔고, 결국 웹 UI에서 하나씩 눌러 등록했다. 자동화가 어디서 멈추는지, 그리고 준비 단계에서 나를 붙잡은 사소한 오류들을 순서대로…
취미(부업…)로 만든 Flutter 앱에 fastlane + GitHub Actions로 배포 자동화를 붙였다. 결과부터 말하면, Android는 실제로 Google Play internal 트랙 업로드까지 완주해 파이프라인이 로컬 기준으로 완전히 검증됐다. iOS는 아직 Apple Developer 계정(돈…ㅠㅠ) 확인 단계에서 멈춰 있어 문법 검증까지만 마친 상태다 한쪽은…
Kafka를 처음 붙일 때 가장 헷갈리는 지점은 대개 컨슈머 쪽이다. “서버를 여러 대로 늘렸는데 왜 같은 메시지를 두 번 처리하지?” 또는 반대로 “왜 한 서버만 메시지를 가져가고 나머지는 노는지?” 같은 질문이 그렇다. 답은 거의 항상 컨슈머 그룹 설정에 있다. Kafka에서…
카프카를 처음 배울 때 가장 많이 헷갈리는 지점은 “토픽에 메시지를 넣었는데 왜 순서가 뒤죽박죽으로 나오지?”다. 답은 카프카의 저장 구조에 있다. 카프카 클러스터는 브로커라는 서버 위에, 토픽이라는 논리 단위를 두고, 그 안에 파티션이라는 물리 단위로 메시지를 나눠 저장한다. 이 세 겹을…
두 서버가 직접 데이터를 주고받게 만들면 언젠가 문제가 생긴다. 받는 쪽 서버가 잠깐 죽으면 보낸 요청은 그대로 사라지고, 응답을 기다리는 동안 보낸 쪽 서버의 성능도 같이 떨어진다. 아파치 카프카(Apache Kafka)는 이 문제를 “중간에 메시지를 대신 보관해 주는 저장소”를 두는 방식으로…