원문: https://philipotoole.com/a-prayer-for-distributed-systems-developers/ (Translated by Google Gemini)

16년이 넘는 시간 동안 저는 전체 스택을 오르내리며 소프트웨어를 작성했습니다. 제 경력 초기에 저는 특수 임베디드 장치를 위한 부트 ROM 소프트웨어를 작성했습니다. 이런 종류의 프로그래밍은 컴퓨터가 정말로 어떻게 작동하는지에 대해 많은 것을 가르쳐주었습니다.

대부분의 프로그래머는 컴퓨터가 어떻게 작동하는지 안다고 생각하지만, 그들은 단지 소프트웨어가 어떻게 작동하는지 알 뿐입니다. 이 프로그래머들은 인터럽트 서비스 루틴이 어떻게 호출되는지, 컴퓨터가 두 숫자를 어떻게 더하는지, 마이크로프로세서가 다음 명령어를 RAM에 어떻게 로드하는지 정말로 알지 못합니다. 하지만 괜찮습니다. 그럴 필요도 없고, 관심도 없습니다.

그래서 저는 여러 해 동안 임베디드 소프트웨어를 작성했지만, 상승 기류에 휩쓸린 풍선처럼 소프트웨어 스택 위로 떠올랐습니다. 한동안 커널 공간에서 지내다가, 몇 년간 사용자 공간에서 머물렀고, 가장 최근에는 엄청난 소프트웨어 스택의 꼭대기에 서게 되었습니다. 하지만 임베디드 소프트웨어만 작성하는 것은 시스템에 대해 거의 가르쳐주지 않으며 — 그렇게 높은 스택을 내려다보면 정신이 아찔해질 수도 있습니다 — 아래를 내려다보지 말라고 하듯이.

하지만 그 스택 꼭대기에 서서 아래를 내려다보니, 그동안 제가 보아온 두 가지 유형 — 그리고 어쩌면 세 번째 유형 — 의 소프트웨어 엔지니어링에 대해 생각하게 되었습니다.

유형 1 소프트웨어 엔지니어링#

제가 이제부터 설명할 것을 유형 1 소프트웨어 엔지니어링이라고 부릅시다.

임베디드 소프트웨어가 그 예입니다. 입력 조건이 매우 제한적이므로, 소프트웨어가 매우 높은 수준으로 정확하다는 것을 보여주기가 훨씬 쉽습니다. 하드웨어에 매우 가깝기 때문에 동작이 정확하게 측정된 구성 요소에 가까이 있는 이점을 누립니다. 제 경력 동안 저는 수천 개의 어셈블리 명령어를 작성했으며, 이는 CPU 레지스터에서 읽고 썼습니다. 이 명령어들은 항상 정확히 같은 시간(기술적으로는 같은 수의 클럭 사이클)에 실행되었습니다. 읽기-수정-쓰기 주기의 응답성을 모니터링한다는 생각은 프로그래머의 관점에서는 명백히 말도 안 되는 이야기입니다(마이크로프로세서 설계자에게는 그렇지 않겠지만요!).

임베디드 시스템이 실행될 때 — 디지털 비디오 레코더와 같은 더 큰 시스템도 — 다소 수학적인 느낌이 듭니다. 신호가 들어가고, 신호가 나옵니다. 버튼이 눌리고, 디스플레이가 바뀝니다. 제약이 있고, 특정 사고방식으로 이어집니다. 도전 과제는 여전히 중요합니다. 시스템은 종종 물리적으로 매우 작고, 하드웨어는 종종 고도로 맞춤화되어 있으며, 도구는 상대적으로 적습니다. 때로는 오실로스코프를 사용하여 소프트웨어를 디버그해야 하는데 — 제가 해본 일입니다.

하지만 프로그래밍 문제 — 제품 — 은 종종 완료 지점에 도달하여, 그 시스템은 완성되었고 모든 상황에서 어떻게 동작할지 안다고 말할 수 있습니다.

유형 2 소프트웨어 엔지니어링#

이제 제가 유형 2라고 부르는 것에 대해 이야기해 봅시다.

유형 2는 대규모 분산 시스템을 프로그래밍하고 설계하는 것을 포함합니다. 함수 호출은 국가 간 연결을 통해 여러 네트워크 홉을 포함할 수 있습니다. 지연 시간은 구성 요소 전체에 분산되어 있으며, 외부 서비스에 대한 호출은 마이크로초가 걸릴 수도 있고, 몇 분이 걸릴 수도 있습니다. 하위 시스템은 실패 직전일 수 있지만 괜찮아 보일 수 있습니다. 이런 종류의 소프트웨어 설계는 대규모 컴퓨터 시스템에 대한 쉬운 접근의 출현과 함께 오늘날 훨씬 더 널리 퍼져 있습니다.

제 경험상 이러한 시스템을 엔지니어링하는 방법은 단 하나뿐입니다. 프로그래밍에서 배운 모든 것을 활용한 다음, 시스템 엔지니어가 되는 것입니다. 모든 속성은 측정되고 모니터링되어야 하며, 모든 동작은 시간을 재고 기록되어야 합니다. 피드백 루프에 대해 배워야 합니다. 이는 실제 기계 공학과 훨씬 더 유사합니다. 이 모델에서는 소프트웨어의 작동 매개변수가 선택되고 — 종종 지속적으로 변경되며 — 시스템이 어떻게 수행되는지에 주의를 기울이고 필요에 따라 매개변수를 수정함으로써 결정됩니다. 견고한 설계를 지속적인 측정 및 분석과 결합하고, 이를 시스템 운영에 다시 반영하는 것 — 이것이 제가 유형 2 소프트웨어 엔지니어링이라고 생각하는 것입니다.

이상적으로는 유형 2는 유형 1의 상위 집합입니다. 그러나 유형 2 엔지니어링은 운영 특성이 변화의 유일한 원동력이 되고, 시스템이 왜 그렇게 작동하는지 이해하려는 시도 없이 이루어질 때 무너집니다 — 이를 유형 3 소프트웨어 엔지니어링 또는 더 간결하게 추측이라고 부릅니다. 이는 종종 시간이 부족하거나, 팀이 스트레스에 시달리거나, 시스템이 실패 직전일 때 발생합니다.

분산 시스템 개발자를 위한 평온을 비는 기도 라 부르면 될까요?

신이시여, 제가 바꿀 수 없는 것을 받아들이는 설계 능력을 주시고,

제가 바꿀 수 있는 것을 바꾸는 코드를 주시고,

그 차이를 알 수 있는 측정 지표를 주소서.