DataCook DataCook

CI가 초록불이라 그날은 마음 편히 퇴근할 뻔했습니다.골든 테스트가 전부 통과했고 exit 0이 떨어졌으니까요.화면 캡처를 자동으로 뽑는 파이프라인이었는데, 로그 맨 아래 초록색 체크를 보고 저는 "오늘 치는 끝났다" 하고 노트북을 덮었습니다.그런데 다음 날 아침, 캡처한 PNG들을 확인하려고 폴더를 열었더니 파일은 있는데 죄다 빈 깡통이었습니다.크기가 몇 바이트짜리, 아무것도 안 그려진 이미지들이 줄줄이 있었습니다.이미 초록불을 믿고 반나절을 넘긴 뒤였습니다.초록불이 거짓말을 한 건 아니었다폴더를 열었을 때 처음 든 생각은 캡처 코드가 깨졌나였습니다.그래서 캡처를 만드는 위젯 테스트를 로컬에서 직접 돌려봤죠.근데 로컬에선 멀쩡한 PNG가 잘 나왔습니다.그럼 CI에서만 다른 건데, 하고 로그를 줄 단위로..

카메라 미리보기 화면을 처음 붙이던 날이었습니다.위젯을 올리고 앱을 켜자마자, 화면 대신 새빨간 에러 화면이 앱을 뒤덮었습니다.컨트롤러가 초기화되기 전에 미리보기를 그리려다 null을 만난 겁니다.이상했던 건 코드 순서상으로는 분명히 초기화를 먼저 호출해뒀다는 점이었습니다.위에 초기화를 적고 아래에 미리보기를 그렸는데, 왜 아래가 먼저 실행된 것처럼 구는지 한참 갸웃했습니다.처음엔 제가 initState와 build 순서를 헷갈렸나 싶어 코드를 몇 번이나 다시 읽었죠.코드는 위에서 아래로 읽히지만 하드웨어는 그렇지 않다에러 메시지를 다시 읽어보니 컨트롤러가 아직 준비되지 않았다는 이야기였습니다.반신반의하면서 initialize() 앞뒤와 build 맨 위에 print를 하나씩 심어봤습니다.로그가 찍힌 순..

금요일 오후였습니다.안드로이드 QA를 전부 통과시키고, 이제 iOS 심사용 빌드만 올리면 주말이라 홀가분한 마음이었습니다.빌드를 올리고 커피 한 잔 내리러 갔다 왔더니, 삼십 분쯤 사이에 크래시 리포트가 여러 건 쌓여 있었습니다.심사 리뷰어가 앱을 켜자마자 특정 화면에서 앱이 닫혔다는 내용이었습니다.같은 코드, 같은 Dart 파일인데 안드로이드에서는 개발 내내 단 한 번도 안 났던 크래시였습니다.순간 등이 좀 서늘했습니다.심사에서 이렇게 터지면 그대로 반려니까요.재현이 안 되는 크래시를 로그로만 쫓았다제일 곤란했던 건, 그 크래시를 제 손에서 재현할 수가 없었다는 점입니다.회사 테스트용 아이폰은 마침 다른 사람이 쓰고 있었고, 제 앞엔 시뮬레이터뿐이었는데 시뮬레이터에서는 아무리 눌러도 멀쩡히 돌았습니다...

"위젯은 얼마든지 쪼개도 된다"는 말을 어디선가 읽고, 그 말을 좀 순진하게 믿었습니다.어느 날 저녁, 한 화면의 build 함수가 너무 길어 눈에 거슬려서 리스트 화면 하나를 스무 개 가까운 작은 위젯으로 잘게 나눴습니다.카드, 배지, 썸네일, 가격 라벨, 심지어 구분선까지 전부 별도 클래스로 뽑아냈죠.코드는 눈에 띄게 읽기 좋아졌고, 저는 그날 꽤 뿌듯한 채로 잤습니다.그런데 다음 날 아침 실제 기기에서 스크롤을 내려보니 예전보다 오히려 손끝에 뚝뚝 걸렸습니다.분명히 더 잘게 나눴는데 더 느려진 겁니다.쪼갤수록 느려진다는 게 말이 되나처음엔 제 눈을 의심했습니다.위젯을 나누는 건 공짜에 가깝다고 배웠으니까요.그래서 엉뚱한 데를 먼저 팠습니다.const를 빠뜨린 위젯이 있나 싶어 눈에 보이는 생성자마다..

설정 화면에 알림 토글 스위치 하나를 붙이는 작업이었습니다.정말 스위치 하나였는데, 저는 습관처럼 전역 provider부터 만들었습니다.StateNotifierProvider를 선언하고, 상태를 담을 클래스를 만들고, on/off 메서드를 붙이고, 그걸 위한 파일을 따로 뺐습니다.스위치 하나에 파일이 세 개 늘었습니다.코드리뷰에서 질문 하나가 돌아왔습니다."이 토글 상태, 이 화면 밖에서 읽는 데가 있어요?" 잠깐 멈칫했습니다.없었습니다.저장은 스위치를 누르는 순간 바로 서버로 보냈고, 다른 화면은 그 값을 화면에 들고 있을 필요가 없었습니다.그 질문 하나에, 제가 작은 상태에 큰 도구를 얹고 있었다는 게 드러났습니다.큰 도구가 항상 안전한 건 아닙니다전역 상태관리를 기본값으로 쓰면 마음이 편합니다.나중..

"그거, 적용됐어요." PR 설명란에 저는 그렇게 적었습니다."여백 줄인 거 반영했습니다"라고, 스크린샷 한 장까지 붙여서요.캡처 폴더에 있던 화면 이미지를 하나 끌어다 놓았고, 슥 봤을 때 맞는 것 같아서 더 들여다보지 않았습니다.리뷰가 돌아온 건 그날 오후였습니다."이거 지난주 화면인데요." 짧은 한 줄 아래, 리뷰어가 여백이 그대로인 부분을 네모로 표시해 두었더라고요.붙인 이미지를 다시 열어 보니 정말 예전 화면이었습니다.새로 찍었어야 할 캡처를, 저는 폴더에 남아 있던 옛날 파일로 붙여 놓고 "됐다"고 말하고 있었던 겁니다.얼굴이 조금 화끈했습니다.그날 배운 건 단순합니다.UI 작업에서 "적용됐어요", "잘 보여요" 같은 말은 그 자체로는 증거가 아니라는 것.화면이 정말 바뀌었는지는 제 말이 아니..

CI 화면이 온통 초록이었습니다.unit도, widget도, 골든 테스트까지 전부 통과.마음 놓고 그날 오후 빌드를 실기기에 올렸습니다.그런데 빈 상태 화면을 여니 안내 문구 끝 두 글자가 카드 밖으로 삐져나와 있었습니다."게시물이 아직 없어요" 정도의 짧은 문장이었는데, 오른쪽 모서리에서 잘려 있었습니다.다른 기기로 바꿔 껴 봐도 마찬가지였습니다.이상했습니다.그 화면은 바로 그 오버플로를 막으려고 골든 테스트를 붙여 둔 화면이었거든요.테스트는 방금도 초록이라고 했는데, 실기기는 깨졌다고 보여주고 있었습니다.테스트 로그를 다시 훑어도 실패한 항목은 없었습니다.초록불과 잘린 두 글자를 번갈아 보는데, 둘 중 하나는 분명 거짓말을 하고 있었습니다.골든 테스트의 초록불은 "이 위젯이 테스트 환경에서 이렇게 그..

"목록에서는 좋아요가 12개인데, 상세로 들어가면 11개로 보여요." 아침에 열어 본 제보에는 스크린샷 두 장이 나란히 붙어 있었습니다.같은 게시물, 같은 계정, 다른 숫자.목록 카드의 하트 옆에는 12, 상세 화면 상단에는 11.처음엔 별거 아니라고 생각했습니다.캐시가 잠깐 엉킨 거겠거니 하고 상세에서 아래로 당겨 새로고침을 했는데, 상세만 12로 바뀌고 목록은 11에서 꿈쩍도 하지 않았습니다.반대로 목록을 새로고침하면 이번엔 목록만 따라오고 상세가 뒤처졌습니다.그때 등이 살짝 서늘해졌습니다.어느 쪽을 새로고침하든 나머지 하나가 늘 뒤처진다는 건, 캐시가 엉킨 게 아니라 이 숫자의 주인이 둘이라는 신호였거든요.이건 상태관리 패키지를 무엇으로 고르느냐의 문제가 아니었습니다.같은 의미의 값을 두 곳에서 각..