당신의 Architecture Diagram은 거짓이며 회의에 있는 모든 사람이 그것을 알고 있다
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you’ve already provided) here? Once I have it, I’ll keep the source link at the top and translate the rest into Korean while preserving all formatting, markdown, and technical terms.
다이어그램 망상
아키텍처 다이어그램은 기업 신화가 되었다. 우리는 현실을 문서화하기 위해서가 아니라, 현실이 우리가 바라는 모습이 되길 상상하기 위해 만든다. 그것은 소프트웨어 시스템을 위한 인스타그램 필터와 같다.
마지막으로 검토한 시스템 다이어그램을 떠올려 보라. 그것은 다음을 보여주었는가:
- 아직도 Oracle 11g에서 실행되는 레거시 데이터베이스(마이그레이션은 “다음 분기에 계획됨”)?
- 실제로는 급한 마감 때문에 6개월 전부터 세 개의 서비스를 임시로 합쳐 놓은 마이크로서비스?
- 이제 시스템 기능에 필수적이지만 안전하게 제거하는 방법을 모르는 “임시” Redis 캐시?
- 스테이징에서는 완전히 다르게 동작하는 인증 서비스?
물론 아니다. 그런 세부 사항은 “구현 구체사항”에 해당한다.
실제 아키텍처는 프로덕션 로그에 있다
실제 아키텍처를 보고 싶나요? Visio를 보지 마세요. 오류 로그를 보세요.
시스템의 진정한 설계는 실패 패턴, 실제로 중요한 병목 현상, 그리고 문제가 생기면 모든 것을 무너뜨리는 의존성에서 드러납니다. 매주 화요일 오후 2 시에 최대치에 도달하는 데이터베이스 연결 풀은 어떤 다이어그램보다도 당신의 아키텍처에 대해 더 많은 것을 알려줍니다.
제가 참여한 프로젝트에서는 아름다운 서비스‑mesh 다이어그램이 깔끔하고 독립적인 서비스를 보여주었습니다. 현실? 서비스 A는 서비스 B 없이는 동작할 수 없었고, 서비스 B는 어디에도 문서화되지 않은 공유 파일 시스템에 비밀리에 의존하고 있었습니다. 그 파일 시스템이 가득 차면, 우리 “마이크로서비스” 절반이 카드 하우스처럼 동시에 무너졌습니다.
Why We Keep Drawing Lies
그것은 악의적인 것이 아니다. 이 다이어그램들은 목적을 가지고 있지만, 우리가 주장하는 목적은 아니다.
아키텍처 다이어그램은 열망 문서이다. 그것은 우리가 만들려고 하는 시스템, 혹은 우리가 만들고 있다고 생각하는 시스템을 나타낸다. 새로운 팀원을 온보딩할 때 필요한 정신 모델을 제공하는 데 유용하다. Oracle 11g 문제에 대해 알 필요가 없는 이해관계자와 소통하는 데도 도움이 된다.
하지만 우리는 지도와 영토를 혼동했다.
회의실 연극
모든 아키텍처 검토에서 진행되는 스크립트는 다음과 같습니다:
발표자: “여기 자동 페일오버가 포함된 고가용성 설정이 있습니다…”
다른 사람들: “자동 페일오버”가 4시간 동안 수동 개입이 필요했던 그때를 생각하고 있다.
용감한 사람: “지난달 결제 서비스에서 발생한 이슈는 어떻습니까?”
발표자: “아, 그 문제는 해결되었습니다. 다음 슬라이드.”
다른 사람들: 아직도 미해결 티켓이라는 것을 알고 있다.
이것은 생산적이지 않습니다. 연극일 뿐입니다. 우리는 모두 다이어그램이 정확하다고 가장하고 있습니다. 왜냐하면 이를 지적하면 우리가 준비가 안 된 상태임을 인정해야 하기 때문입니다.
더 나은 앞으로의 길
- 새로운 것을 만들기 전에: 이상적인 상태를 보여주는 다이어그램을 만드세요. 이를 사용해 잠재적인 문제를 식별하고, 트레이드‑오프를 논의하며, 목표에 맞추세요. 그리고 나서 보관하세요.
- 기존 시스템에 대해: 현실 그대로의 “as‑is” 다이어그램을 만들어 추한 진실을 보여 주세요. 기술 부채, 우회 방법, 실제 데이터 흐름을 포함하세요. 상황이 변할 때 업데이트하고, 예정된 시점에 업데이트하지 마세요.
- 이해관계자를 위해: 기술 구현이 아니라 비즈니스 역량에 초점을 맞춘 간소화된 뷰를 만들세요. 그들은 여러분의 열두 개 마이크로서비스를 알 필요가 없으며, 주문이 처리되고 고객에게 청구된다는 사실만 알면 됩니다.
- 새 팀원에게: 먼저 목표 지향적인 다이어그램을 제공하고, 두 주가 지나면 실제 다이어그램을 보여 주세요. 맥락이 중요합니다.
불편한 진실
당신의 프로덕션 시스템은 어떤 다이어그램도 포착할 수 없을 정도로 더 지저분하고, 복잡하며, 상호 의존적입니다. 이것은 실패가 아니라—소프트웨어 개발 자체입니다.
제가 아는 최고의 설계자들은 이 복잡성을 회피하지 않습니다. 그들은 이를 문서화하고, 측정하고, 점진적으로 개선합니다. 그들은 특정 청중을 위한 특정 목적을 수행하는 다이어그램을 만들며, 아무도 만족시키지 못하는 보편적 진리 문서는 만들지 않습니다.
다음에 아키텍처 리뷰에 참석할 때, 모든 실제 의존성, 모든 공유 자원, 그리고 모든 기술 부채를 포함한다면 다이어그램이 어떻게 바뀔지 물어보세요. 방이 불편해지는 모습을 보고, 실제로 무엇을 만들고 있는지에 대한 진정한 대화를 시작하세요.
작업 항목
내일 다음을 수행하세요:
- 현재 아키텍처 다이어그램을 가져와 실제 운영과 일치하지 않는 모든 구성 요소를 빨간색으로 표시합니다.
- 부분적으로 정확한 항목은 노란색으로 표시합니다.
- 정말 정확한 부분만 초록색으로 유지합니다.
다이어그램이 대부분 빨간색과 노란색이라면, 축하합니다—몇 달 만에 정직하게 행동하고 있습니다.
이제 더 나은 것을 만들기 시작할 수 있습니다.