배포가 자꾸 사람을 괴롭힌다면: publish를 ‘플러그인 가능한 동작’으로 바꾼 날 해커톤 마지막 날 오후였다. 누군가 노트북을 돌려 보여주면서 말했다. “앱은 돌아가요. 근데 배포만 하면 끝에서 항상 막혀요. 우리도 웹으로 올리는 publish 하나만… 딱 하나만 넣어주면 안 돼요?” 그 방에는 두 종류의 사람이 있었다. 한쪽은 바로 고개를 끄덕였다. “좋아, 커맨드 하나 추가하자.” 다른 쪽은 얼굴이 굳었다. “그거, 커맨드 하나로 끝나는 일이 아니야.” 나는 그 사이에서, 슬쩍 겁이 났다. 코드를 고치는 일은 익숙한데 배포는 늘 낯설었다. 특히 파이썬 프로젝트에서 배포는 더 그랬다. 어떤 팀은 SFTP로 올리고, 어떤 팀은 대시보드에서 클릭하고, 어떤 팀은 누군가의 로컬 스크립트를 빌려 쓴다. 그 스크립트는 빠르지만, 늘 한 사람의 기억에 의존한다. 그날 기능요청은 “웹 배포”였지만, 실제로 우리를 괴롭힌 건 다른 질문이었다. ‘publish’라는 동작을 어디까지 책임지게 할 건가? 문서에 배포 방법을 적어두면 된다고 생각했는데, 문서는 늘 늙었다. 호스팅 화면이 바뀌고, 인증 방식이 바뀌고, 팀원이 바뀌고, 무엇보다 “배포를 잘 아는 사람”이 바뀐다. 배포가 문서에 붙어 있는 순간, 배포는 기술이 아니라 기억력 시험이 된다. 이 글은 며칠 전 읽은 한 사례에서 시작한다. BeeWare Briefcase가 PythonAnywhere를 publish 타깃으로 붙인 과정과, 그 과정에서 briefcase publish web 이 어떻게 논의되는지를 보면(참고자료), 이 문제가 “특정 호스팅의 사용법”이 아니라 구조의 문제라는 게 드러난다. 그리고 구조를 바꾸지 않으면, 팀은 배포를 할수록 더 느려진다. (링크는 맨 아래에만 모았다.) “그럼 PythonAnywhere는 누가 알아야 하죠?”라는 질문 처음엔 다들 단순하게 생각한다. “PythonAnywhere API로 업로드하면 되지.” 그...
큰 파이썬 레포에서 첫 PR이 무서운 이유: 코드를 고치기 전에 ‘길’부터 봐야 한다 처음 큰 레포를 열었을 때, 나는 코드가 아니라 공기가 무거웠다. 파일이 많고, 디렉터리가 많고, 규칙이 많아 보였다. 어디서부터 손대면 되는지 감이 없었다. 그래도 PR 하나는 해야 하니까, 제일 작은 걸 골랐다. 오타 하나, 로그 한 줄, 그 정도. 그런데 이상하게도 그 작은 변경이 나를 하루 종일 잡아먹었다. 내가 바꾼 건 한 줄인데, 테스트는 수백 개가 돌았고, 중간중간 실패가 났고, 다시 돌리면 또 다른 곳이 깨졌다. 그때부터는 코드가 아니라 ‘길’을 찾는 시간이 됐다. 어디서 실행해야 하는지, 어디서 깨진 건지, 내가 바꾼 게 도대체 어디에 영향을 주는지. 오늘 글은 설치 팁이 아니다. uv가 좋다는 얘기로 시작하지 않는다. 큰 파이썬 코드베이스를 처음 건드릴 때 제일 먼저 필요한 건 도구가 아니라, “지금 내가 어디에 서 있는지”를 알게 해주는 지도다. 본문에는 링크를 넣지 않고, 읽을거리는 맨 아래 참고자료로만 모았다. 그날 10분: 테스트가 터졌는데, 어디가 문제인지도 몰랐다 첫 PR을 올리기 전에 로컬에서 테스트를 돌렸다. ‘전체 테스트’라는 말이 있다면, 나는 그걸 그대로 믿는 편이었다. 그런데 큰 레포에선 그 믿음이 바로 부메랑이 된다. 전체 테스트는 오래 걸리고, 오래 걸리는 동안 사람은 집중을 잃는다. 집중을 잃으면 로그를 대충 읽고, 대충 읽으면 더 대충 고친다. 그날도 그랬다. 실패가 뜨길래 해당 테스트 파일을 열었는데, 테스트가 하는 일이 내가 바꾼 코드랑 전혀 상관없어 보였다. 그래서 다른 테스트로 건너갔다. 또 상관없어 보였다. “내가 뭘 건드린 거지?”라는 질문이 한 시간 뒤에야 제대로 떠올랐다. 그때부터 나는 전체 테스트를 포기했다. 포기라는 말이 좀 거칠지만, 큰 레포에서 포기는 종종 ‘전략’이 된다. 대신 최소한의 확인을 하나 정했다. 이 한 줄을 돌리고 나서야 다음으로 넘어가기로. p...