공통 패키지 하나 바꿨더니 21개 앱이 배포되는 문제

26년 06월 01일

공통 패키지의 의존성 전파

이날은 배포 인프라를 고친 날이었다.

공통 패키지 파일 하나를 바꿨는데, 배포 추론이 21개 앱을 잡았다.

실제로는 5개만 배포하면 됐다.

이 문제를 고치면서 알림 기능도 마무리했다.

교육 플랫폼은 모노레포다.

여러 앱이 공통 패키지를 공유한다.

공통 패키지에 있는 컴포넌트를 하나 고쳤다.

근데 배포 추론이 21개 앱을 배포 대상으로 잡았다.

원인은 의존성 전파다.

공통 패키지를 의존하는 모든 앱이 배포 대상이 된다.

근데 실제로는 그 컴포넌트를 쓰는 앱은 5개뿐이다.

나머지 16개는 그 컴포넌트를 안 쓴다.

근데 추론은 “공통 패키지가 바뀌었으니까 전부 배포”라고 판단한 거다.

문제는 공통 패키지의 barrel export에 있었다.

인덱스 파일이 그 컴포넌트를 내보내지 않는다.

그래서 일부 앱은 깊은 경로로 직접 import하고 일부는 로컬 복사본을 쓴다.

추론은 인덱스를 통한 정상 import만 잡으니까, 깊은 경로랑 로컬 복사본을 놓친다.

놓치니까 안전하게 전부 배포로 가는 거다.

추론 정확도 올리기

해결은 두 단계로 했다.

첫 번째는 추론에 베이스네임 검색 단계를 추가하는 거다.

기존에는 import 경로 매칭만 했다.

여기에, 각 앱의 소스 코드에서 변경된 파일의 베이스네임을 검색하는 단계를 넣었다.

깊은 경로로 import하든 로컬 복사본을 쓰든, 파일 이름으로 찾으면 잡을 수 있다.

이렇게 하니까 21개에서 5개로 줄었다.

실제로 그 컴포넌트를 쓰는 앱만 배포 대상이 됐다.

명시적 허용 목록

두 번째는 명시적 허용 목록을 추가하는 거다.

자동 추론은 정확해졌지만, 그래도 휴먼 에러가 있을 수 있다.

그래서 사용자가 배포 가능한 앱을 명시적으로 지정할 수 있게 만들었다.

허용 목록에 있는 앱만 배포된다.

추론이 10개를 잡아도, 허용 목록에 5개만 있으면 5개만 배포된다.

자동 추론이랑 명시적 제어를 같이 쓰는 거다.

이 허용 목록은 요구사항 검증을 두 번 통과했다.

첫 번째에서는 검증이 부족하다는 지적이 나와서 JSON 파싱 검증이랑 경로 검증을 추가했다.

두 번째에서 통과했다.

알림 문구 수정

배포 인프라 외에 알림 기능도 마무리했다.

알림 도움말 문구를 수정했다.

카카오톡 알림 발송 실패 시 문자로 대체 발송된다는 내용을 추가했다.

그리고 에러 아이콘을 디자인 시스템 컴포넌트로 통일했다.

유효성 검사 UX도 개선했다.

발송 일수를 안 설정했으면 저장 버튼을 비활성화했다.

“최소 하나는 설정해라”는 에러 메시지 위치도 옮겼다.

문구 오타

배포 과정에서 문구 오타도 발견했다.

“이전에”가 아니라 “이후에”가 맞는 거였다.

코스 시작일 기준으로 설정한 날짜 이후에 알림이 발송되는 건데, “이전에”로 되어 있었다.

발견하고 수정해서 다시 배포했다.

이런 오타는 기획서를 꼼꼼히 안 읽으면 놓친다.

“이전”이랑 “이후”는 한 글자 차이인데 의미가 완전히 반대다.

세 번 배포

이날 같은 기능을 세 번 배포했다.

첫 번째는 21개 앱으로. 두 번째는 단일 앱으로 수동 지정.

세 번째는 오타 수정. 세 번 배포하는 건 비효율적이다.

근데 버그가 나올 때마다 잡고 배포하는 게 맞다.

쌓아두면 나중에 한 번에 잡기 어렵다.

마무리

이날의 핵심은 배포 추론을 정확하게 만드는 거였다.

공통 패키지 하나 바꿨다고 21개 앱을 배포하면, 리소스가 낭비되고 피드백이 느려진다.

정확하게 5개만 배포하면 빠르고 효율적이다.

자동 추론을 개선하면서 동시에 명시적 제어도 넣었다.

자동만 믿으면 휴먼 에러를 못 잡는다.

명시적만 쓰면 번거롭다.

둘을 같이 쓰는 게 가장 안전하다.

그리고 barrel export를 안 쓰는 import 패턴이 문제를 만들었다.

공통 패키지에서 컴포넌트를 내보낼 때, 인덱스를 통해서만 내보내면 추론이 쉽다.

근데 깊은 경로로 직접 import하면 추론이 어렵다.

import 패턴의 일관성이 인프라에도 영향을 준다.