76. 워크어라운드 (Workaround)

⚠️ 이 문서는 ITIL(IT Infrastructure Library)의 사고 관리(Incident Management) 프로세스에서, 시스템 장애의 근본적인 원인(Root Cause)을 아직 찾지 못했더라도 일단 고객의 비즈니스 피해를 막기 위해 서비스를 강제로 재개시키는 **임시 우회 조치인 '워크어라운드'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 서버가 갑자기 뻗었을 때 코드를 분석해 버그를 고치는 '영구적 해결책(Permanent Fix)'이 아니라, 단순히 서버를 재부팅하거나 보조 서버로 트래픽을 돌려 일단 화면이 뜨게 만드는 '응급처치'다.
  2. 가치: 고객 입장에서는 서버가 왜 죽었는지 원인을 듣는 것보다 '지금 당장 결제가 되게 해주는 것'이 백 배 중요하다. 워크어라운드는 SLA(서비스 수준 협약) 위반에 따른 막대한 배상금과 비즈니스 중단(Downtime)을 최소화하는 최우선 방어선이다.
  3. 기술 체계: 사고(Incident)가 발생하면 1차 지원팀(L1 Helpdesk)이 매뉴얼에 등록된 워크어라운드를 즉시 적용해 불을 끄고, 이후 문제 관리(Problem Management) 팀이 넘겨받아 며칠이 걸리더라도 근본 원인을 추적하는 이원화 체계를 이룬다.

Ⅰ. 사고 관리(Incident)의 목표: '근본 원인'보다 '복구'가 먼저다

운영 환경에서 버그를 잡겠다고 시간을 끄는 것은 최악의 행동이다.

  1. 사고(Incident)와 문제(Problem)의 분리:
    • ITIL에서는 사용자가 겪는 시스템 중단 현상을 **사고(Incident)**라고 부르고, 그 사고를 일으킨 숨겨진 코드 버그나 하드웨어 결함을 **문제(Problem)**라고 분리한다.
  2. 사고 관리의 최우선 목표:
    • 사고 관리팀의 유일한 목표는 "최대한 빨리 서비스를 정상 상태로 돌려놓는 것"이다. 의사가 응급 환자가 실려 왔을 때 병의 원인을 연구하기보다 당장 피부터 멎게 하는 지혈 작업과 같다.
  3. 워크어라운드의 개입:
    • 메모리 누수(Memory Leak) 버그 때문에 3시간마다 서버가 뻗는다면, 소스코드를 고치는 데 일주일이 걸린다. 이때 "일단 매 2시간마다 스크립트로 서버를 자동 재부팅시킨다"는 워크어라운드를 적용하면 고객은 장애를 느끼지 못한다.

📢 섹션 요약 비유: 달리는 배에 구멍이 나서 물이 들어올 때(장애 발생), 배를 조선소로 끌고 가 철판을 용접(근본 원인 해결)하는 것이 아니라, 일단 선원들이 물통으로 물을 퍼내며 테이프로 구멍을 막아(워크어라운드) 배가 가라앉지 않게 목적지까지 가는 응급조치입니다.

Ⅱ. 대표적인 워크어라운드 사례와 적용

우리가 흔히 쓰는 운영 꼼수들의 대부분이 워크어라운드다.

  1. 서버/데몬 재시작 (Restart):
    • "껐다 켜보세요"는 IT 업계 최고의 워크어라운드다. 원인 불명의 캐시 꼬임이나 스레드 데드락 상태를 강제로 초기화하여 즉시 서비스를 살려낸다.
  2. 라우팅 우회 (Failover):
    • A 데이터센터의 결제망이 먹통이 되었을 때 굳이 A 센터의 라우터를 고치고 앉아있지 않고, 즉시 B 데이터센터로 트래픽을 100% 우회시키는 조치다.
  3. 기능 비활성화 (Feature Toggle/Degradation):
    • 쇼핑몰 메인 화면의 '실시간 추천 상품' 모듈이 무거워 전체 사이트가 느려진다면, 일단 해당 추천 모듈 화면만 보이지 않게 꺼버리고 메인 쇼핑 기능만 살리는 조치다.

📢 섹션 요약 비유: 고속도로(A서버)에 낙석 사고가 나서 길이 막혔을 때, 굴착기를 불러 바위를 치우기(영구 해결) 전에 일단 차들을 국도(우회 경로)로 돌려보내어 교통 체증을 풀어주는 경찰관의 수신호와 같습니다.

Ⅲ. KEDB (Known Error Database)와 위험성

임시방편이 영구적인 해결책으로 둔갑하는 것을 막아야 한다.

  1. KEDB (알려진 오류 데이터베이스):
    • 워크어라운드로 장애를 넘겼다면, 그 증상과 임시 조치 방법을 지식 문서(KEDB)에 반드시 기록해야 한다. 그래야 다음번 야간 당직자가 같은 에러를 봤을 때 허둥대지 않고 즉시 스크립트를 실행할 수 있다.
  2. 기술 부채 (Technical Debt)의 누적:
    • 워크어라운드의 가장 큰 위험은 "어? 껐다 켜니까 며칠째 잘 돌아가네?" 하고 개발자들이 근본 원인 분석(Root Cause Analysis, RCA)을 포기하고 영원히 재부팅 스크립트에 의존하는 것이다.
  3. 문제 관리(Problem Management)로의 이관:
    • 따라서 워크어라운드로 급한 불을 끄고 나면, 해당 티켓은 반드시 문제 관리팀(L3 엔지니어)으로 이관되어, 근본 원인이 포함된 영구적 패치(Patch)가 릴리스될 때까지 끝까지 추적 및 관리되어야 한다.

📢 섹션 요약 비유: 진통제(워크어라운드)를 먹고 충치 통증이 사라졌다고 해서 치과 치료를 미루면 나중에 이를 통째로 뽑아야 하는 큰 사고(기술 부채)가 터집니다. 진통제는 치과에 가기 전까지만 먹고, 반드시 의사(문제 관리팀)에게 근본 치료를 받아야 합니다.