스택노트

금요일 오후, 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 이라는 연구기..

같은 기능을 양쪽으로 짜봤더니 클린 빌드가 6분 48초 vs 4분 12초. Koin이 38% 빨랐는데, 그래도 안 갈아탔습니다. 수치만 보면 갈아타는 게 답인데, ROI 계산을 한 바퀴 돌리고 나니 답이 달라지더라고요. 지난 한 달 동안 사이드 모듈 하나를 양쪽으로 풀로 짜서 같은 화면, 같은 의존성 그래프를 깔아두고 빌드 시간·APK·콜드 스타트를 다 찍어봤거든요. 그 과정에서 정리된 판단을 6년차 안드로이드 개발자 입장에서 풀어볼게요. Hilt 멀티모듈 18개에서 빌드 시간이 도마에 오른 자리작년 가을부터 모듈을 쪼개기 시작해서 올해 봄에 18개를 찍었습니다. 모듈 8개 시절 3분 20초였던 클린 빌드가 7분 10초까지 늘어났어요. KSP가 모듈마다 의존성 그래프를 다시 생성하는데, 저희 프로젝트에선..

에러를 던지지 마세요. 값으로 들고 다니세요. try/catch를 줄였더니 오히려 에러가 또렷하게 보이기 시작했어요. 지난 5월에 사이드 프로젝트 피드 화면을 새로 짜다가, 어떤 실패든 화면엔 "일시적인 문제가 발생했어요" 한 줄로 뭉개지는 걸 봤습니다. 401인지 네트워크 끊김인지 JSON 파싱 실패인지 구분이 안 됐어요. 안드로이드 스튜디오(Android Studio) 로그캣(Logcat)을 한참 들여다본 뒤에야 깨달았는데, 문제는 catch 블록 안이 아니라 catch 블록이 받는 타입이었습니다. try/catch와 kotlin.Result가 '알 수 없는 오류'를 만드는 이유catch (e: Exception) 한 줄로 묶으면 retrofit2.HttpException(401)이든 JsonData..