대부분의 프로젝트가 건너뛰는 질문
도구에 디렉터리가 생길 무렵이면 이미 누군가 '이건 서비스다'라고 정해둔 뒤야. 근데 그걸 정한 기억이 있는 사람은 거의 없어. 프레임워크랑 같이 오고, 템플릿이랑 같이 오고, 튜토리얼이랑 배포 대상이랑 같이 오거든. 그리고 아래쪽 전부가 그걸 전제하니까, 그 전제는 끝까지 시험대에 안 올라가.
소리 내서 물어볼 값어치가 있는 질문은 좁아. 아무도 미리 안 정한 순간에, 이것한테서 답을 받아야 하는 게 있나? 있으면 항상 떠 있어야 하고, 그건 서비스야. 모든 호출이 하나도 빠짐없이 '사람이 돌리기로 했다'로 거슬러 올라가면 가용성은 애초에 요구사항이 아니었고, 포트는 반대편에 아무것도 없는 비용이야.
포트가 실제로 얼마인가
만드는 값은 하찮고, 그게 요점도 아냐. 진짜 비용은 존재하기 시작한 다음부터 붙어서 안 떨어져:
- 관리할 생명주기 — 부팅 때 떠야 하고, 죽으면 다시 살아나야 하고, 밑에 깔린 런타임을 올려도 버텨야 해.
- 생사 질문 — 언젠가 누군가 '이거 떠 있냐'고 물어야 하고, 그럼 헬스 엔드포인트가 필요하고, 그걸 읽는 것도 필요해.
- 지켜야 할 주소 — 예약된 번호 하나, 피해야 할 충돌 하나, 누가 여기 닿을 수 있냐는 결정 하나.
- 암묵적 계약 — 이게 제일 비싸. 닿을 수 있는 건 언젠가 반드시 의존 대상이 되고, 두 번째 호출자는 허락을 안 구하고 와.
마지막 비용 때문에 이 거부가 취향이 아니라 규칙으로 적혀 있어. 서비스가 된 배치 도구는 기능을 얻은 게 아냐. 자기가 동의한 적 없는 기대를 가진, 끝을 모르는 미래 호출자 무리를 떠안은 거야.
정직한 반대편
서비스가 나쁘다는 얘기가 아니고, 그런 척하는 강의는 쓸모가 없어. 서비스가 필요한 진짜 방아쇠는 말하기 쉬워. 독립된 클라이언트 여럿이 같은 답을 필요로 할 때. 지연이 중요해서 프로세스 뜨는 시간조차 못 봐줄 때. 상태를 호출자들 사이에서 공유하고 조율해야 할 때. 네 통제 밖의 뭔가가 일을 시작시킬 때. 이 중 하나만 걸려도 그 값은 번 거야. Beacon 은 하나도 안 걸려. 호출자는 정확히 하나고, 분 단위 렌더 앞에서 기동 시간은 의미가 없고, 상태는 디렉터리 하나고, 모든 실행은 사람에서 시작해.
이걸 어디든 가져갈 수 있는 교훈으로 만드는 건 추론의 순서야. "이건 무슨 형태여야 하지?"에서 시작하지 마. "누가, 언제 일을 시작시키지?"에서 시작해. 형태는 그 답에서 떨어져 나오고, 가끔은 서비스가 나와. 실패는 질문을 건너뛰는 거야. 기본 답은 항상 예스고, 비용은 항상 영구적이니까.