#concurrency

2편 끝에서 살짝 언급했던 함정 이야기로 시작할게요. publish 직전에 발을 걸리게 한 바로 그 함정이요. OSS의 createS3Storage가 기존 프로젝트 webpack 위에서 처음으로 돌아간 날이었어요. 빌드는 멀쩡히 통과했어요. 그런데 storybook을 열어보니 콘솔에 이런 게 뜨더라고요. fs.promises.writeFile. 처음엔 황당했어요. 우리는 그런 코드를 짠 적이

1편에서 어댑터 세 개를 그렸다면, 2편은 그걸 들고 실제로 옮긴 이야기예요. 기존 프로젝트에서 25개 commit, OSS repo에서 20개 commit이 나왔어요. 숫자만 보면 평범한 리팩토링 같은데, 사실 이 분리 작업에서 가장 중요했던 결정은 순서였어요. 한 줄로 적자면 — OSS 본체 코드를 만들기 전에, 기존 프로젝트 안에서 먼저 어댑터 모양으로 갈아엎었다. 처음엔 그럴 생각이

사내 storybook에서 굴러가던 Visual Builder를 npm으로 분리하기로 했어요. 결과만 먼저 말하면 @bdmakers/visual-builder@0.1.1이라는 회사 OSS로 떨어졌고, 기존 프로젝트에 남은 빌더 관련 코드는 300줄 남짓이 됐어요. 분리하기 전에 기존 프로젝트에 박혀 있던 양이 8,400 줄이었으니까, 8,100 줄 정도가 라이브러리 쪽으로 넘어간 셈이죠. 그

여러분, 4편의 제목을 한 줄로 다시 적어볼게요. "파이프라인은 끝의 일." CI/CD 글을 쓸 때 자주 빠지는 함정이 있어요. 파이프라인을 시작에 두는 것 — 마치 파이프라인 설계가 운영 디자인의 출발점인 것처럼 쓰는 거죠. 저희 팀에서는 반대로 봅니다. 코드(13편)가 이미 정직한 동작을 보장하고, 그 다음에야 파이프라인이 그 위에 얇은 한 겹을 덮어요. 그 한 겹의 일은 단순합니다 —