다들 너무 빨리 답해버리는 설계 질문
제작 대기열이 필요해. 어디다 둘까? 반사적으로 나오는 답은 새 테이블, 기존 테이블에 컬럼 하나, 작업 파일을 떨궈 넣는 폴더, 제대로 된 메시지 브로커. 전부 진짜 선택지고, 하나하나가 누군가의 기본값이야.
고른 답은 그중 아무것도 아니었어. 대기열은 이미 존재하고 이미 읽히고 있던 시스템의 메시지 스레드야. 새 장치가 아예 아니지. 이유엔 순위가 매겨져 있고, 1 등이 내면화할 값어치가 있는 거야. 넘기는 장치가 이미 있다. 작업 세션은 원래 받은 편지함을 읽는 걸로 시작해. 습관처럼. 다른 선택지는 전부 잘 돌아가는 것 옆에 두 번째 전달 장치를 짓는 거고, 그럼 둘 다 지켜봐야 해.
장부의 나머지
1 등 이유가 정리되면 나머지가 빠르게 쌓여. 스레드가 제작 기록이 되니까 논의랑 판정이랑 결과가 한자리에 모여. 대기열 행 하나, 채팅 로그 하나, 커밋 메시지 하나로 흩어지는 대신에. 요청을 닫는 게 곧 출고라서 작업에 깔끔한 종료 사건이 생기고. 스키마 변경은 0 이야. 게다가 대기열을 보는 화면이 이미 두 군데 있어서 뭐가 밀려 있는지 보려고 화면을 새로 만들 일도 없어.
거절당한 쪽엔 실격 사유가 하나 있었는데, 기존의 약점이 새 설계에 어떻게 정보를 줘야 하는지 보여주는 좋은 예야. 다른 유력 후보는 파일 기반 저장소였는데, 잠금이 없고 원자적이지도 않다고 이미 알려져 있었거든. 지금 거기 들어 있는 것들엔 견딜 만한 수준이지만, 제작 대기열을 올릴 자리는 아니지. 네 기존 부품 중 뭐가 약한지 아는 게, 새 하중을 그쪽에서 비껴가게 하는 힘이야.
이 추론이 전부 코드가 아니라 코드 주위의 조직에 대한 거라는 걸 봐. 후보는 전부 기술적으론 됐어. 갈린 건 사람이 실제로 볼 게 어느 쪽이냐, 논쟁이 벌어질 자리가 이미 마련된 게 어느 쪽이냐, 흔들린다고 이미 알려진 게 어느 쪽이냐였어. 절차가 바쁜 한 주랑 부딪혔을 때 살아남느냐를 정하는 기준이 그런 것들인데, 기술 비교표엔 거의 안 올라와.