게시글

기술 문서는 아주 구체적이고 예측 가능한 방식으로 실패합니다. 누군가 한가한 2주 동안 아주 많은 양을 써 놓고, 그러는 사이 시스템이 바뀌고, 아무도 갱신하지 않고, 1년이 지나면 그 문서는 확신에 찬 어조로 틀린 내용을 말하고 있습니다. 그 시점부터는 없느니만 못합니다. 문서를 믿은 사람이 이미 성립하지 않는 정보에 근거해 움직이기 때문입니다. 흔한 대응은 더 많이 쓰자는 압박이고, 그것은 같은 실패를 더 빨리 불러올 뿐입니다. 쓸모 있는 대응은 더 적게 쓰고 무엇을 쓸지 고르는 것입니다. 병목은 쓰는 노력이 아니라 유지하는 노력이기 때문입니다. 어떤 문서가 존재...

개발자 온보딩은 보통 입사 교육이 며칠 걸렸는지로 측정되는데, 그것은 문제의 잘못된 쪽 끝을 보는 일입니다. 정작 중요한 숫자는 따로 있습니다. 새로 온 엔지니어가 무언가를 고치면서 다른 것을 망가뜨리지 않았다고 확신하기까지 얼마나 걸리는가입니다. 대부분의 팀에서 이 값은 며칠이 아니라 몇 달 단위로 측정됩니다. 지연의 원인이 사람인 경우는 드뭅니다. 원인은 시스템의 얼마나 많은 부분이 다른 사람들의 머릿속에만 존재하는지, 그리고 첫 두 주의 얼마나 많은 시간이 그것을 한 번에 하나씩 질문으로 꺼내오는 데 쓰이는지에 있습니다. 추적할 가치가 있는 단 하나의 지표는, ...

가동률 SLA는 약속처럼 보이지만 환불 규정처럼 작동합니다. 공급자는 이 점을 잘 알고 있습니다. 고객은 그렇지 못한 경우가 많아서, 가용성을 샀다고 믿으며 서비스 수준 협약에 서명합니다. 그러나 실제로 산 것은 가용성이 아니라, 그것을 받지 못했을 때 돌려받는 작은 할인입니다. 그것이 반드시 나쁜 거래라는 뜻은 아닙니다. 다만 대부분의 사람이 맺고 있다고 생각하는 거래와는 다른 거래이고, 그 차이는 시스템이 멈추고 누군가 계약서에 뭐라고 적혀 있는지 묻는 순간에 드러납니다. 쓰리 나인은 거의 완벽하게 들리지만 한 달에 43분의 다운타임을 허용합니다. 포 나인은 4분...

소프트웨어 임치는 소스코드를 중립적인 제3의 기관에 맡겨 두는 제도이며, 충분히 합리적인 두려움에 답하기 위해 존재합니다. 핵심 시스템을 만들고 운영해 온 공급업체가 사라지고, 여러분에게는 의존하고 있지만 스스로 유지보수할 수 없는 무언가만 남는 상황 말입니다. 임치 계약은 소스코드를 그 기관에 보관해 두었다가, 그런 일이 실제로 벌어지면 여러분에게 인도하도록 정해 둡니다. 두려움 자체는 정당합니다. 문제는 이 제도가 자주 오해된다는 점이고, 그 간극에서 매년 돈은 나가지만 정작 필요한 날에는 아무 도움이 되지 않는 계약이 생겨납니다....

고정가 계약과 투입 정산 계약 가운데 무엇을 고를 것인가 하는 문제는 대개 리스크에 관한 선택으로 설명됩니다. 그 설명 자체는 옳지만, 바로 다음 단계에서 잘못 다뤄집니다. 발주사와 수행사 모두 리스크가 자리를 옮길 뿐이라는 사실을 잊고, 어느 한쪽을 고르면 리스크가 사라진다고 가정하기 때문입니다. 리스크는 사라지지 않습니다. 고정가 방식에서는 견적이 틀릴 위험을 공급사가 떠안고, 그 위험을 제시 금액 안에 미리 얹어 둡니다. 투입 정산 방식에서는 같은 위험을 발주사가 떠안습니다. 질문은 어느 쪽이 불확실성을 없애 주느냐가 아닙니다. 어느 쪽이 그 불확실성을 더 잘 ...

소규모 팀에서 재해 복구는 대개 아무도 열어 본 적 없는 문서 안의 한 줄로 끝납니다. 백업은 켜져 있습니다, 라는 문장입니다. 그 문장은 사실이지만 어떤 질문에도 답이 되지 못합니다. 되찾은 데이터가 얼마나 오래된 것인지, 복원에 얼마나 걸리는지, 지금까지 누가 한 번이라도 끝까지 복원을 해 본 적이 있는지에 대해 아무것도 말해 주지 않기 때문입니다. 백업을 가지고 있다는 사실과 실제로 복구할 수 있다는 사실 사이의 간격에서 대부분의 장애는 심각한 사고로 바뀝니다. 존재하고, 최신이며, 한 번도 복원해 본 적 없는 백업은 아직 가설일 뿐입니다. 그리고 그 가설을 처...

콘텐츠 프루닝은 검색 최적화에서 가장 직관에 어긋나는 작업입니다. 모든 본능이 페이지가 많아질수록 트래픽도 늘어야 한다고 말하기 때문입니다. 글을 발행하는 일은 자산이 쌓이는 것처럼 느껴집니다. 반대로 글을 지우는 일은 누군가 비용을 치른 결과물을 그냥 버리는 것처럼 느껴집니다. 삭제가 도움이 되는 진짜 이유는 내 사이트의 페이지끼리 서로 경쟁하기 때문입니다. 내 페이지 두 개가 같은 검색 의도를 겨냥하면, 원래 한 페이지에 모였어야 할 신호가 둘로 갈라집니다. 그리고 둘 중 무엇을 보여줄지 판단해야 하는 검색 시스템은 결국 어느 쪽도 고르지 않는 결과로 끝나기도 합...

API 버전 관리 논쟁은 대개 엉뚱한 쪽에서 시작됩니다. 버전 번호를 어디에 둘 것인가 하는 문제 말입니다. 이 주제 전체에서 결과에 가장 영향이 작은 결정이 바로 그것입니다. 정작 중요한 것은 어떤 변경이 애초에 새 버전을 요구하는가이며, 대부분의 팀은 이 지점에서 안이한 쪽으로 판단을 그르칩니다. 순수하게 추가만 했다고 믿는 것을 배포했는데, 어느 클라이언트가 깨집니다. 쓸 만한 사고 모형은 이렇습니다. 여러분의 API는 호출자가 무엇에 기댈 수 있는지에 대한 약속입니다. 합리적인 호출자가 기대고 있던 무언가를 무효로 만든다면 그 변경은 호환성을 깨는 변경입니다....

소프트웨어 제안요청서, 즉 RFP는 원래 여러 공급업체를 나란히 놓고 비교할 수 있게 만드는 문서입니다. 그런데 실제로 오가는 문서 대부분은 정반대의 결과를 냅니다. 해법을 지나치게 자세히 지정해 답변의 폭을 묶어 놓으면서, 정작 가격을 산출하는 데 누구에게나 필요한 정보는 빠뜨리기 때문입니다. 그 결과 자릿수가 하나 차이 나는 다섯 개의 견적이 나란히 도착하고, 형식상으로는 모두 요구에 응답했지만 같은 것을 재고 있는 견적은 하나도 없습니다. 흔한 진단은 공급업체가 말을 흐린다는 것입니다. 가끔은 사실입니다. 그러나 훨씬 더 자주 벌어지는 일은, 문서가 그 안에 담...

소프트웨어 유지보수 비용은 성공한 프로젝트를 열여덟 달 뒤 껄끄러운 대화로 바꿔 놓는 숫자입니다. 구축은 예산이 잡혔고 승인이 났고 납품까지 끝났습니다. 그런데 서비스가 가동된 다음에 벌어지는 일은 그냥 “지원"이라는 한마디로 정리되었고, 누군가 감으로 찍은 금액이 붙었으며, 그 금액은 거의 언제나 너무 적었습니다. 이유는 부주의가 아니라 구조에 있습니다. 구축에는 값을 매길 수 있는 범위가 있습니다. 유지보수에는 범위가 없습니다. 아직 일어나지 않은 일들이 그 범위를 정하기 때문입니다. 취약점이 발견되는 라이브러리, API를 바꾸는 공급업체, 아무도 예상하지 못한 ...