L1, L2, L3 기술 지원이란? 현장에서 배운 에스컬레이션 구조

기술 지원 단계 완전 정리: "L1·L2·L3 서포트 엔지니어"

처음 SI 현장에 들어갔을 때 L1이니 L2니 하는 말을 듣고 네트워크 계층 얘기인 줄 알았다. 그게 아니라 기술 지원 단계를 뜻하는 거라는 걸 나중에 알았다. 신입 시절엔 뭔가를 모른다는 걸 모르는 경우가 많다. 주변에서 자꾸 "L1이 처리해야 한다", "L3로 에스컬레이션해야 한다"는 말을 들으면서 맥락으로 배웠다. 지금은 이 구조가 얼마나 합리적으로 설계된 건지 느낀다. 그리고 동시에, 각 레벨이 얼마나 다른 무게를 지고 있는지도.

---

L1 서포트: 첫 번째 관문

L1은 고객이 처음으로 만나는 기술 지원 창구다. 콜센터 기술 지원이라고 생각하면 가장 쉽다. 전화나 티켓으로 문의가 들어오면 가장 먼저 받아서 해결하거나, 못 하면 다음 단계로 넘긴다. 응급실 트리아지 간호사와 비슷하다. 들어오는 환자를 분류하고, 경증은 처리하고, 중증은 전문의에게 넘기는 역할이다.

L1이 주로 다루는 건 자주 반복되는 문제들이다. 비밀번호 초기화, 계정 잠금 해제, 기본 연결 확인, 소프트웨어 설치 안내 같은 것들이다. 스크립트나 매뉴얼에 따라 처리할 수 있는 것들이 많다. 일정 시간 안에 해결 못 하면 L2로 넘기는 게 원칙이다.

현장에서 L1이 잘 작동하려면 절차와 문서가 갖춰져 있어야 한다. 반대로 절차가 없으면 L1 엔지니어가 너무 많은 판단을 해야 하고, 그 판단이 맞지 않으면 고객 불만이 쌓인다. L1의 가치는 속도와 첫 인상이다. 빠르게 응답하고 정확한 분류를 해주는 것만으로도 고객 만족도가 달라진다. 단점은 반복 작업이 많아 소진되기 쉽다는 거다.

L1 역할을 처음 맡았을 때 솔직히 "이건 단순 노동이 아닌가"라는 생각이 들었다. 비밀번호 바꿔달라는 요청을 하루에 수십 번 처리하다 보면 지치기도 했다. 하지만 시간이 지나면서 이 자리가 실제로 얼마나 중요한지 알게 됐다. L1이 문제를 빠르게 분류하고 정확한 정보를 수집해서 넘겨줄수록 L2, L3의 해결 속도가 올라간다. 첫 대응이 엉터리면 전체 지원 사슬이 흔들린다. 이 자리를 발판으로 더 올라가야 한다는 동기 부여가 중요하다.

---

L2 서포트: 기술의 깊이가 시작되는 곳

L1에서 해결 못한 문제들이 넘어온다. L2는 단순 매뉴얼이 아니라 실제 기술 지식으로 문제를 분석하고 해결해야 한다. 지층을 뚫어야 하는 굴착기 같은 존재다. 표면만 긁는 게 아니라 조금 더 깊이 파고든다.

서버 로그 분석, 네트워크 패킷 캡처, 응용 프로그램 설정 문제 해결, 중간 단계의 장애 원인 추적 같은 것들이 L2의 영역이다. 현장에서 이 역할이 특히 바쁜 이유는 L1에서 오는 양도 많고, L3에서 내려주는 복잡한 작업도 받아야 하기 때문이다. 중간에 낀 존재다. 위에서도 아래에서도 압박을 받는다.

L2가 잘 기능하려면 문서화 습관이 중요하다. 해결한 사례를 남겨두면 비슷한 문제가 왔을 때 L1도 처리할 수 있게 되고, 장기적으로는 조직 전체의 대응 능력이 올라간다. 반대로 문서화를 안 하면 같은 문제가 계속 L2로 올라온다.

L2 역할을 처음 맡았을 때 이 부분을 제대로 못 해서 같은 문제를 두 달 동안 반복해서 처리한 경험이 있다. 특정 서버에서 로그인이 안 된다는 티켓이 계속 들어왔는데, 해결하고 나면 다음 날 또 같은 내용이 올라왔다. 알고 보니 설정 파일에 문제가 있었는데, 그걸 고쳐두고 문서로 남기지 않으니까 비슷한 환경의 다른 서버에서 같은 증상이 반복됐던 거다. 그 경험 이후에 무슨 문제를 어떻게 해결했는지 반드시 사내 위키에 기록하는 습관이 생겼다. 기록의 중요성을 뼈저리게 배웠다.

---

L3 서포트: 가장 깊은 곳

L3는 전문가 집단이다. 제품 개발팀, 시스템 아키텍트, 네트워크 전문가, 보안 전문가 같은 사람들이 이 레벨에 있다. L2에서도 못 풀면 여기로 온다. 산에서 조난된 사람을 구조하러 직접 투입되는 구조 전문팀 같은 느낌이다. 아무나 보내지 않고, 필요할 때만 투입된다.

L3가 다루는 문제는 재현이 어렵거나, 근본 원인이 불명확하거나, 코드 수정이나 아키텍처 변경이 필요한 것들이다. 로그 분석 수준이 아니라 소스 코드를 보거나, 시스템 내부 구조를 뜯어보거나, 벤더와 직접 소통하는 경우도 있다.

L3에 준하는 역할을 해야 했던 순간이 있었는데, 새벽 두 시에 운영 서버 장애 원인이 커널 파라미터 문제였던 일이 기억난다. 서버가 갑자기 응답을 안 하길래 로그를 파고들었더니 파일 디스크립터 한도가 가득 찬 상태였다. 프로세스가 열 수 있는 파일 개수 제한이 기본값으로 설정돼 있었던 거다. /etc/security/limits.conf를 수정하고 재기동하면서 해결했는데, 다음날 새벽까지 원인 파악하고 해결하면서 느꼈던 그 쾌감은 아직도 남아있다.

L3의 단점은 희소성에서 온다. 인원이 적기 때문에 한 사람이 지나치게 많은 걸 알아야 하고, 그 사람이 빠지면 공백이 크다. 지식 전수가 안 되는 조직에서는 L3 한 명이 핵심이 되어버리는 리스크가 생긴다. 이른바 '버스 팩터'다. 이 사람이 버스에 치이면 조직이 멈춘다는 뜻의 냉혹한 비유인데, L3 단독 의존 구조는 그 팩터가 1에 가까워진다.

---

세 레벨이 함께 돌아가는 구조

L1, L2, L3는 각각 독립적이지 않다. 피라미드처럼 쌓여있다. 아래가 많이 걸러줄수록 위가 핵심 문제에만 집중할 수 있다. 이 구조가 제대로 돌아가려면 에스컬레이션 기준이 명확해야 한다. 언제 L1이 L2로 넘기고, 언제 L2가 L3를 부르는지 기준이 모호하면 혼란이 온다.

현장에서 이 기준을 명문화하지 않은 팀에서 일한 적이 있다. 결과적으로 L1이 자기 판단으로 L3까지 직접 연락하는 일이 생기고, L3 사람들이 사소한 문제로 인터럽트를 받아서 정작 중요한 작업에 집중하지 못했다. 구조는 있었지만 규칙이 없었던 거다. 절차 없는 구조는 구조가 없는 것과 비슷하다.

이 경험에서 느낀 건 명문화된 에스컬레이션 기준이 단순히 절차 문서가 아니라는 거다. 각 레벨의 사람들이 자신의 역할과 한계를 명확히 알게 해주는 가이드다. 기준이 없으면 능력 있는 L1이 스스로 다 해결하려다가 과부하가 걸리거나, 반대로 작은 문제도 다 위로 던져버리는 혼란이 생긴다. 조직의 건강은 각자가 자기 역할의 경계를 아는 것에서 시작된다.

---

마무리 생각

L1에서 시작해서 L3까지 성장한다는 게 단순히 기술이 늘어나는 문제만은 아니다. 문제를 보는 시야가 넓어지고, 판단의 기준이 생기며, 조직 전체가 어떻게 돌아가는지 느끼게 된다. L1 때 당연하게 받아들였던 에스컬레이션 절차가, 나중에 L3 역할을 해보면서 얼마나 중요한 것인지 역으로 배웠다. 어떤 레벨에 있든 자신의 역할을 명확히 하고, 다음 레벨과 협력하는 구조를 이해하면 팀 전체의 대응력이 올라간다. 그걸 아는 사람과 모르는 사람의 차이가 현장에서 꽤 크다.

---

출처 및 참고 링크

• ITIL 공식 가이드: https://www.axelos.com/certifications/itil-service-management
• 시스코 공식 기술 지원 설명: https://www.cisco.com/c/en/us/support
• ServiceNow IT Support Level 정의 참고: https://www.servicenow.com/products/itsm.html