

회사 기술에 대한 백서 비슷한 것을 한번 만들어보고 있다. 결국 이 제품은 제대로 돌아가지 않는 서비스, 혹은 좀 아픈 서비스를 복구해 주거나 복구 방법을 알려주는 역할을 하게 될텐데, 이 부분이 임상의학과 좀 닮은 구석이 있다는 생각이 들었다.
몸이 안좋을 때를 생각해 보면 겉으로 발현되는 어떤 현상(증상)이 있고, 그 증상을 분석하기 위해 간단한 것이든 복잡한 것이든 어떤 검사와 관찰을 거친다. 그리고 현상의 원인이 무엇인지를 추측하거나 알아내고, 이에 맞는 치료를 하게 된다. 이 때 이 치료는 상황에 따라 일단 증상 자체를 완화하는 대증치료가 있을수도 있고, 실제 증상의 원인을 찾아 제거하는 치료도 있을 수 있다.
인터넷 서비스의 운영도 비슷한데, 현상이 존재하고(컨테이너가 뜨지 않는다, 응답속도가 느리다 등등) 이것을 관찰하는데서 운영이 시작된다. 관찰가능성(O11y) 자체를 높이는 것도 중요한데 이는 별론으로 하고, 현상을 분석하기 위해 로그도 보고 여러가지 서비스 메트릭도 보며 실제 원인을 알아낸다. 만약 전면장애와 같은 상황이라면 일단 서버를 스케일아웃 하거나 전 버전으로 롤백하는 등의 적절한 대증치료가 먼저 필요할 수 있다. 혹은 코드의 어느 부분이 잘못되었는지, 환경설정의 어느 부분을 고쳐야 하는지 해결책을 제시할 수도 있을 것이다.
그런 느낌으로 어떤 프레임워크가 없을까 정리하다가 의학에서 사용되는 SOAP 노트라는 것을 이번에 알게 되었는데,
S (주관적): 환자가 보고한 증상, 병력, 가족력 등 주관적 정보
O (객관적): 진찰, 검사 결과, 생체 징후 등 객관적 데이터
A (평가): 가능한 진단, 감별 진단 목록, 상태 평가
P (계획): 검사 계획, 치료 방법, 경과 관찰 계획
이것을 조금 바꾸어 제품의 아키텍쳐에 그대로 녹여낼 수도 있겠다는 생각이 들었다. 그리고 이런 케이스노트들이 점점 풍성해지면 더 넓은 범위의 장애를 커버할 수 있게 될 것 같다.