!원문 캡처 · deadparrotbbs.com

기술 분야에서 ‘지루하다’는 말은 대개 오래되고 보수적이며 시대에 뒤처졌다는 뜻으로 쓰인다. 하지만 인프라에서는 오랫동안 쓰여 작동 방식과 고장 유형이 잘 알려진 시스템을 지루하다고 부르는 것이 칭찬일 수 있다.

오래됐다고 언제나 더 낫다는 뜻은 아니다. 교체해야 할 낡은 기술도 있고, 비용이나 운영 중단 우려 때문에 남아 있는 시스템도 있다. 중요한 구분은 기술이 정말 수명을 다했는지, 아니면 충분히 성숙했는지다.

새 기술에는 드러나지 않는 비용이 따른다

새 프레임워크는 개발을 빠르게 할 수 있지만 빠르게 변하는 생태계에 의존하게 만들 수 있다. 새 서비스는 운영을 단순하게 하면서도 특정 공급업체에 종속시킬 수 있다. 새 프로토콜은 유용한 기능을 제공하는 대신 도구, 모니터링, 교육, 문제 해결 지식을 새로 요구할 수 있다.

이런 점이 새 기술을 나쁘게 만들지는 않는다. 다만 기능 목록만으로는 비용을 모두 파악하기 어렵다는 뜻이다. 시스템이 평소와 장애 상황에서 어떻게 작동하는지 아는 예측 가능성은 중요하다. 부하를 받을 때의 동작, 잘못된 입력의 처리, 백업과 복구 방법, 업그레이드 후 벌어지는 일을 알고 있다면 운영의 불확실성을 줄일 수 있다. 인프라에서는 기능을 하나 더하는 것보다 불확실성을 줄이는 일이 더 가치 있을 때가 많다.

성숙한 도구에는 축적된 지식이 있다

오래 널리 쓰인 도구는 문제와 해결 방법이 잘 기록돼 있는 경우가 많다. 메일링 리스트 글, 버그 보고서, 포럼 토론, 설명서, 책, 스크립트와 예제가 있고, 같은 장애를 이미 겪어 본 관리자가 있다.

이런 축적된 지식은 제품 비교표에 나타나지 않지만 기술의 일부다. 20년간 쌓인 문서와 경험을 갖춘 도구에는 새 프로젝트가 단기간에 만들 수 없는 것이 있다. 실제 시스템에서 사용될 때 어떤 일이 벌어지는지에 대한 기록이다.

성숙한 도구는 장단점과 한계, 주의할 지점도 비교적 잘 알려져 있다. 새 시스템은 실제 경험보다 기대가 앞서는 기간을 거치기도 한다. 기술적으로 인상적인 소프트웨어라도 10년간 운영했을 때 무엇이 드러날지는 아직 알 수 없다. 어떤 지식은 축적되는 데 시간이 필요하다.

안정된 프로토콜은 호환성을 지탱한다

이메일과 DNS는 오래됐고, HTTP도 새롭지 않으며, SSH는 수십 년간 Unix와 Linux 관리에 쓰여 왔다. 그렇다고 쓸모가 사라진 것은 아니다. 다양한 운영체제와 공급업체, 도구, 기기가 널리 알려지고 구현된 규칙을 따르기 때문에 서로 통신할 수 있다. 호환성이 없는 시스템을 다뤄 보면 이런 가치를 실감하게 된다.

독점 서비스는 처음 도입하기 쉬울 수 있지만, 그 경계는 대개 소유자가 정한다. 반면 안정적이고 개방적으로 구현된 프로토콜은 특정 애플리케이션이 사업을 계속해야만 유용한 것이 아니다. 개별 프로그램은 사라져도 정보를 주고받는 능력은 남을 수 있다.

예측 가능한 시스템은 관리와 복구가 쉽다

정상 상태가 무엇인지 알면 모니터링이 쉬워지고, 한 번에 바뀌는 변수가 적으면 문제를 찾기 수월해진다. 복구 절차도 이전에 시험해 본 적이 있다면 더 수월하다.

잦은 변경은 이런 작업을 어렵게 만들 수 있다. 빠른 출시와 지속적 배포 덕분에 보안 수정과 버그 해결을 빠르게 제공할 수 있지만, 변경 자체가 운영 환경의 일부가 된다. 의존성이나 API가 바뀌거나 서비스 정책이 달라지면 오늘 안정적으로 작동하던 시스템이 다음 달에는 다르게 동작할 수 있다. 각각의 변경은 합리적일 수 있어도, 누적되면 환경을 이해하고 지원하기가 어려워진다.

시스템을 충분히 오래 그대로 두고 깊이 이해할 수 있다는 데에도 실용적 가치가 있다. 그렇다고 변화를 멈춰야 한다는 뜻은 아니다. 보안 문제는 해결해야 하고, 하드웨어는 고장 나며, 소프트웨어는 수명을 다하고, 표준과 요구사항도 바뀐다. 교체가 추가 복잡성이나 위험을 감수할 만큼 중요한 문제를 해결하는지가 관건이다. 익숙하다는 이유만으로 계속 유지할 필요도, 새롭다는 이유만으로 교체할 필요도 없다.

성숙한 기술도 유지보수가 필요하다. 안정된 프로토콜은 신중하게 확장해야 할 수 있고, 오래된 시스템도 보안·성능·호환성·유지보수성을 객관적으로 평가해야 한다. 지루한 기술은 오래 살아남았다는 사실만이 아니라 맡은 일을 계속 잘 해낼 때 자리를 인정받는다.

복잡성은 그만한 이유가 있어야 한다

추가되는 복잡성이 어떤 문제를 해결하는지 물으면 많은 기술 선택이 명확해진다. 트랜잭션이나 관계형 데이터, 동시 접근, 복잡한 질의가 필요하다면 데이터베이스가 텍스트 파일보다 낫다. 실제로 작업 부하를 분산해야 한다면 분산 시스템이 적합하다. 유연성이나 지역적 도달 범위, 빠른 확장이 로컬 운영보다 중요하다면 클라우드 인프라가 유용할 수 있다.

반대로 작은 내부 서비스가 현대적 아키텍처라는 이유만으로 컨테이너, 오케스트레이션 계층, 관리형 데이터베이스, 모니터링 플랫폼, 인증 서비스와 외부 연동을 갖추기도 한다. 각 요소는 따로 보면 타당할 수 있지만, 전체 시스템은 처음 해결하려던 문제보다 이해하고 유지하기 더 어려워질 수 있다. 위험은 복잡성 자체가 아니라 운영 부담을 정당화할 만큼의 이득 없이 복잡성이 늘어나는 데 있다. 지루한 시스템은 움직이는 부품과 예상 밖의 상호작용이 적어 성공하는 경우가 많다.

소비자 기술에서는 새로운 기능과 더 나은 화면, 빠른 하드웨어, 개선된 인터페이스가 매력의 일부일 수 있다. 인프라는 다르다. 좋은 인프라는 대개 배경으로 물러난다. 사람들은 DNS, 인증, 백업, 라우팅, 저장장치나 데이터베이스 서버를 아침 내내 신경 쓰기보다 맡은 일을 하길 원한다.

끊임없이 관심을 요구하는 인프라가 기술적으로 흥미롭다고 해서 좋은 인프라인 것은 아니다. 다른 시스템과 사람이 의존할수록 신뢰성, 유지보수성, 예측 가능한 동작이 더 중요하다. 잘 알려진 운영체제와 데이터베이스, 표준 프로토콜, 20년간 문서가 축적된 도구를 고르는 일은 진보에 저항하는 태도가 아닐 수 있다. 불필요한 불확실성보다 익숙한 동작을 택하는 결정일 수 있다.

새 기술을 실험할 여지는 여전히 필요하며, 그에 따른 혼란을 감수할 가치가 있는 새로운 아이디어도 있다. 핵심은 변화를 피하는 것이 아니라 인프라의 우선순위가 제품 시연이나 취미 프로젝트와 다르다는 점을 아는 것이다. 성숙하고 안정적이며 호환되고 이해하기 쉬운 기술이 맡은 일을 잘하고 있다면, ‘지루하다’는 말은 흠이 아닐 수 있다. 인프라에서는 바로 그런 기술이 필요할 때가 있다.