스택노트

새벽 1시 반, .aab 파일을 플레이 콘솔(Play Console)에 끌어다 놓고 출시 비율 칸에 5를 쳤다고 생각했는데, 화면엔 50이 박혀있더라고요. 그 자리에서 자동화를 결심했습니다. 다행히 출시 직전 검토 화면에서 잡아서 사고로 이어지진 않았는데, 그 순간 식은땀이 흐르는 걸 보면서 "이건 사람 손에 맡길 일이 아니다" 싶었어요. 그 다음 주말에 깃허브 액션(GitHub Actions)으로 옮겨놓은 워크플로를 약 4개월 굴려본 기록을 풀어볼게요. 결과적으로 한 분기 동안 출시 비율 오입력 사고는 0건이었고, 릴리스 1회당 손이 가는 시간은 18분에서 30초로 줄었습니다. Play 콘솔 수동 배포의 함정 — 왜 자동화가 필요했나수동 릴리스는 PR 리뷰를 아무리 빡빡하게 돌려도 마지막 한 발이 사람..

지난주에 태그 묶음 화면 새로 짜는데, 가로 스크롤로 뒤쪽 칩이 잘려나가더라고요. 결국 Compose 1.11 FlexBox API 로 줄바꿈 지점을 통째로 갈아엎었습니다. Row + horizontalScroll 로 칩 12개 깔았더니 생긴 문제QA 검수가 들어왔는데, 가로 스크롤 끝에 숨어 있는 필터 칩 4개를 사용자가 인지 못 한다는 리포트가 올라왔습니다. 화면 폭이 좁은 기기에서는 12개 칩 중 절반이 오른쪽 너머로 사라져 있는 상태였어요. 요구 조건은 단순했습니다. 화면 폭에 따라 자동 줄바꿈, 칩 간격 8dp, 줄 간격 12dp 유지. 말로 풀면 한 줄인데 코드로 옮기는 부분이 매번 발목을 잡았습니다. FlowRow·SubcomposeLayout 으로 우회하던 한계처음에는 FlowRow 를 ..

금요일 오후, Gson 으로 파싱한 객체 필드가 전부 null 로 찍히는 걸 보고 멘붕이 왔습니다. 범인은 빠뜨린 @field: 네 글자였어요. 데이터 클래스에 @SerializedName("user_name") 만 깔끔하게 박아두고 "이러면 알아서 되겠지" 했던 게 화근이었습니다. 컴파일러는 그 어노테이션을 생성자 파라미터(param) 에만 붙여놨고, Gson 은 필드(field) 만 스캔하니 둘이 영원히 만날 일이 없었던 거지요. 코드를 다 뒤져도 잘못된 부분이 안 보이니까 더 답답하더라고요. 이런 use-site target 사고는 코틀린(Kotlin) 으로 자바 라이브러리를 붙여 쓸 때 한 번씩 다 겪는 통과의례인 것 같습니다. 그날 야근의 복기 겸, Kotlin 2.4 에서 안정화된 @all 까..

SwiftPM 의존성을 붙였다고 Swift API 를 그대로 쓸 수 있는 게 아니더라고요. struct 도 async 도 코틀린 쪽에선 깡그리 사라집니다. KMP iOS 모듈 하나 굴리고 있는데, 코틀린(Kotlin) 2.4.0(이달 초에 stable 로 풀린) 에 들어온 swiftPMDependencies DSL 을 지난 주말에 사이드 브랜치로 한 번 붙여봤어요. 코코아팟(CocoaPods) 졸업 시기가 코앞이라 더 이상 미룰 대목도 아니었고요. 막상 붙여보니 "Swift 패키지를 의존성으로 바로 먹는다"는 헤드라인이 실제로는 절반쯤만 맞는 얘기였습니다. KMP iOS SwiftPM 의존성, swiftPMDependencies DSL 첫인상build.gradle.kts 안에서 cocoapods 블록을 ..

kotlinx.serialization으로 갈아탄 진짜 이유는 성능이 아니었어요. 벤치마크에 따라 Moshi가 비슷하거나 약간 앞서는 경우도 있다고 합니다. 그럼에도 정리한 데에는 다른 이유가 있었습니다. 작년 가을 즈음이었어요. 안드로이드 앱은 Gson, 백엔드 모듈은 Moshi, 결제 응답 일부는 수기로 파싱하는 코드가 한 프로젝트 안에 같이 굴러가고 있었습니다. 같은 DTO를 세 번 정의하고 있다는 사실을 깨달은 순간, 더는 못 미루겠더라고요. kotlinx.serialization을 택한 첫 번째 이유, KMP 공유 모듈결정타는 KMP 공유 모듈을 만들기 시작하면서였습니다. commonMain에서 네트워크 응답 DTO를 같이 쓰려고 했는데, Gson과 Moshi 둘 다 JVM에 종속된 라이브러리거..

지난주 동기 모임에서 "아직도 거기 있어요?"라는 말을 들었습니다. 웃으며 넘겼는데, 집에 와서 6년치 손익계산서를 진짜로 펼쳐보게 되더라고요. 개발자 평균 재직기간이 글로벌 3.5년 안팎이라고 알려져 있고, 한국 IT는 그보다 더 짧다는 이야기가 자주 잡힙니다(원티드 2025 개발자 리포트 등에서 비슷한 흐름이 보입니다). 그 기준에서 보면 6년은 통계적 예외예요. "안주한 거 아니냐"는 시선이 따라붙는 자리이기도 합니다. 근데 감정으로 답하면 끝이 안 나더라고요. 그래서 자산과 부채로 나눠서 진짜 숫자를 쳐봤습니다. 한 회사 오래 다니는 개발자가 쌓은 자산 3가지첫 번째는 도메인 지식이에요. 신규 입사자가 3개월 걸려야 파악할 수 있는 결제 모듈의 예외 처리 히스토리를, 저는 30분이면 설명할 수 있..

외울수록 일을 못하는 영역이 있고, 외우지 않으면 시니어가 못 되는 영역이 따로 있습니다. 6년을 굴러보니 그 경계선이 보이기 시작했어요. git reset 옵션은 6년차도 매일 검색합니다솔직히 고백하자면 어제도 git reset --soft랑 --mixed 차이를 검색했어요. tar -xvzf의 옵션 순서도 매번 헷갈리고, HTTP 409랑 422를 언제 써야 하는지도 잠깐 멈춥니다. 근데 이게 부끄러운 일은 아니에요. 스택 오버플로우(Stack Overflow)가 발표한 2024년 개발자 설문에서 응답자의 93%가 한 달에 여러 번 사이트를 방문한다고 합니다. 같은 설문에서 AI 도구를 쓰는 이유로 '생산성 향상'과 '학습 속도'가 70% 안팎으로 상위에 잡혔다는 결과도 있고요. 인지 부하 이론에서 ..

샤워하다 버그 해법이 떠오르는 건 천재라서가 아닙니다. 퇴근에 실패했다는 신호지요. 샤워하다 if문이 떠오르던 토요일 아침얼마 전 토요일 오전 9시였어요. 샤워기 아래에서 갑자기 머릿속에 "어제 그 결제 모듈, await 빠뜨렸나?" 하는 생각이 스쳤습니다. 수건도 제대로 안 두르고 노트북을 열었어요. IntelliJ를 켜고, git pull, 브랜치 확인, 코드 다시 읽기. 결국 두 시간이 사라졌습니다. 그리고 발견한 사실은 await가 잘 들어가 있었다는 것. 황당하더군요. 월요일 아침, 평소보다 훨씬 피곤한 상태로 책상에 앉으면서 깨달았습니다. 저는 주말 내내 "쉰" 게 아니었어요. 머릿속 IDE를 띄워둔 채로 이틀을 보낸 셈입니다. 코드를 잘 알게 될수록 끄기는 더 어려워지더라고요. 자이가르닉 ..

주니어 멘토링 1년 동안 가장 많이 성장한 건 멘티가 아니라 저였어요. 가르치려 준비하는 과정에서 제 사고 과정의 구멍이 다 드러나더라고요. 5년 넘게 손에 익은 코드 패턴이었는데, 옆자리 신입이 "이거 왜 이렇게 돼요?" 한마디 던졌을 때 5초 넘게 입이 막혔습니다. 그제야 알았어요. 제가 "안다"고 생각했던 것들 중 절반은 그냥 "익숙한" 것에 불과했다는 사실을요. "이거 왜 이렇게 돼요?" 주니어 멘토링 첫 3개월의 침묵첫 달 즉답률을 노션에 적어보니 후배 질문에 즉답 못한 비율이 38% 정도 나왔습니다. 5년간 손에 익은 기술을 "관습이에요" 한 마디로 넘겼고, 그게 부끄러워 그다음엔 그냥 PR 위에 손 얹고 "이렇게 고치세요" 식으로 마무리했어요. 마이크로매니징이라기보다는 도망이었어요. 이걸 심..

지난주 금요일 밤, AI가 30분 만에 뽑아낸 결제 모듈 코드를 저는 6시간째 읽고 있었습니다. 그러다 문득 무서워지더라고요. 분명히 작성 속도는 압도적으로 빨라졌는데, 제 퇴근 시간은 더 늦어졌어요. "내가 코드를 짜는 사람이 맞나?" 라는 질문이 그날 밤 머리에서 안 떠났습니다. 6년차 개발자 AI 생산성 역설, 결제 모듈에서 만났습니다상황은 단순했어요. 사이드 프로젝트 결제 모듈 초안을 클로드 코드(Claude Code)에 맡겨봤거든요. 30분 만에 환불·취소·부분 결제까지 분기가 다 들어간 코드가 떨어졌습니다. 문제는 그 다음이었어요. 도메인 규칙에 맞는지, 트랜잭션 경계가 어디서 깨지는지, PG사 응답 코드 매핑이 맞는지를 한 줄씩 확인하다 보니 6시간이 지나 있더라고요. METR 이라는 연구기..