애자일, 린, ITIL을 함께 쓰는 실행 시스템

방법론을 고르는 순간, 이미 승부가 갈린다

많은 팀이 서비스를 만들다가 이상한 전쟁에 빠진다. 누군가는 "우리는 애자일해야 한다"고 말하고, 누군가는 "운영 안정성을 위해 ITIL을 따라야 한다"고 말한다. 또 다른 사람은 "린 스타트업으로 검증부터 하자"고 주장하고, 디자이너는 "사용자 공감이 먼저"라고 말한다. DevOps 담당자는 "배포 자동화 없이는 다 소용없다"고 말한다.

놀랍게도 모두 맞는 말이다. 문제는 누가 더 옳으냐가 아니다. 지금 우리가 마주한 문제가 어떤 종류의 불확실성을 갖고 있느냐다.

최고의 IT 서비스 팀은 유행하는 방법론을 종교처럼 믿지 않는다. 그들은 방법론을 도구 상자처럼 다룬다. 못을 박을 때 망치를 쓰고, 나사를 조일 때 드라이버를 쓰듯이, 고객의 마음을 모를 때는 디자인 씽킹을 쓰고, 시장 반응을 모를 때는 린 스타트업을 쓰며, 구현해야 할 것이 비교적 명확해졌을 때는 애자일을 쓴다. 빠르게 안정적으로 내보내야 할 때는 DevOps를 쓰고, 서비스가 실제 고객의 업무와 삶에 깊이 들어갔을 때는 ITIL 4의 서비스 관리 원칙을 붙인다.

이 장의 핵심은 단순하다. 최고의 팀은 하나의 방법론을 따르지 않는다. 문제에 맞는 운영 리듬을 설계한다.

발견–검증–개발–릴리스–운영–학습의 가치 흐름

IT 서비스는 아이디어에서 끝나지 않는다. 화면을 만들었다고 끝나는 것도 아니고, 배포했다고 끝나는 것도 아니다. 고객이 서비스를 발견하고, 가입하고, 사용하고, 문제를 겪고, 지원을 받고, 다시 돌아오는 전체 흐름이 서비스다.

그래서 실행 시스템은 다음과 같은 하나의 가치 흐름으로 이어져야 한다.

여기서 중요한 것은 흐름이 직선이 아니라는 점이다. 좋은 서비스 팀은 "발견이 끝났으니 검증으로 넘어가고, 검증이 끝났으니 개발로 넘어간다"처럼 일하지 않는다. 운영 중 발생한 장애가 새로운 발견이 되기도 하고, 고객지원 티켓이 다음 실험의 출발점이 되기도 한다. 릴리스 이후의 사용 데이터가 백로그를 바꾸고, 회고에서 나온 병목이 아키텍처 개선으로 이어진다.

이때 ITIL 4의 관점은 특히 유용하다. ITIL 4는 예전처럼 무거운 프로세스를 강요하는 틀이 아니라, 조직의 구성 요소가 함께 가치를 만들고 전달하는 서비스 가치 시스템, 즉 SVS를 강조한다. 이 시스템은 원칙, 거버넌스, 서비스 가치 사슬, 관리 관행, 지속적 개선이 서로 연결되어 고객 가치로 이어진다고 본다¹. 다시 말해 ITIL 4는 애자일과 DevOps를 누르는 상위 규칙이 아니라, 그것들이 서비스 운영 안에서 길을 잃지 않도록 돕는 공통 언어에 가깝다.

디자인 씽킹은 답을 찾기 전에 문제를 의심한다

서비스 실패의 가장 비싼 원인은 개발 실패가 아니다. 틀린 문제를 너무 잘 해결하는 것이다.

예를 들어 팀이 고객에게 "어떤 기능이 필요하세요?"라고 묻는다. 고객은 "자동 리포트 기능이 있으면 좋겠어요"라고 답한다. 팀은 석 달 동안 멋진 자동 리포트 기능을 만든다. 그런데 출시 후 사용률이 낮다. 왜일까? 고객이 정말 원한 것은 리포트가 아니라 "회의 전에 상사에게 혼나지 않을 만큼 상황을 빨리 파악하는 것"이었기 때문이다.

디자인 씽킹은 여기서 멈춰 세운다. "정말 리포트가 문제인가? 아니면 의사결정 직전의 불안이 문제인가?"라고 묻는다. 공감, 문제 정의, 아이디어 발산, 프로토타입, 테스트라는 흐름은 사용자의 말 뒤에 숨은 맥락을 찾기 위한 장치다. 디자인 씽킹과 DevOps를 함께 쓰는 접근에서도 공감과 문제 정의는 빠른 개발 이전에 사용자가 실제로 겪는 문제를 이해하게 해주는 핵심 단계로 설명된다².

디자인 씽킹을 쓸 때의 비밀은 멋진 워크숍을 여는 것이 아니다. 사용자의 하루 속으로 들어가는 것이다. 사용자가 언제 불안해하는지, 어디서 멈추는지, 무엇을 엑셀로 우회하는지, 어떤 순간에 동료에게 도움을 요청하는지 봐야 한다. 그 장면을 발견하면 기능 목록이 아니라 서비스의 진짜 약속이 보인다.

린 스타트업은 믿음을 실험으로 바꾼다

문제를 찾았다고 해서 바로 대규모 개발을 시작하면 안 된다. 문제처럼 보이는 것이 실제 구매 의사로 이어지는지, 사용자가 행동을 바꿀 만큼 강한지, 우리 방식의 해결책이 경쟁 대안보다 나은지 확인해야 한다.

린 스타트업의 핵심은 "빠르게 만들자"가 아니다. 더 정확히는 가장 위험한 가정을 가장 싸게 검증하자다.

팀이 새로운 B2B SaaS를 만든다고 해보자. "중소기업 인사팀은 채용 자동화에 돈을 낼 것이다"라는 가정이 있다. 여기서 가장 위험한 부분은 자동화 기술이 아니다. 정말 돈을 낼 만큼 고통이 큰가, 구매 결정권자가 누구인가, 기존 엑셀과 채용 플랫폼을 버릴 이유가 있는가다. 이때 완성품을 만드는 대신 랜딩 페이지, 수동 운영, 컨시어지 MVP, 클릭 가능한 프로토타입, 사전 계약 제안으로 검증할 수 있다.

이 책에서는 앞서 MVP보다 MVS, 즉 최소 실행 가능한 서비스의 관점을 강조했다. 여기서도 마찬가지다. 검증해야 할 것은 기능이 아니라 서비스 약속이다. 사용자가 "편리하네요"라고 말하는지보다 "언제부터 쓸 수 있나요?", "우리 팀에도 적용할 수 있나요?", "가격은 얼마인가요?"라고 묻는지가 더 중요하다.

애자일은 빠른 코딩이 아니라 빠른 정렬이다

가설이 어느 정도 검증되면 이제 구현의 리듬이 필요하다. 이때 애자일이 등장한다. 하지만 애자일을 "매일 스탠드업 하고, 2주 스프린트 하고, 지라 티켓 옮기는 것"으로 이해하면 절반만 본 것이다.

애자일의 진짜 힘은 짧은 반복을 통해 팀의 생각을 계속 맞추는 데 있다. 제품 책임자는 고객 가치와 우선순위를 설명하고, 디자이너는 경험 흐름을 구체화하며, 개발자는 기술 제약과 가능성을 드러낸다. QA와 운영 담당자는 나중에 터질 문제를 미리 말한다. 이 과정에서 백로그는 단순한 할 일 목록이 아니라 "우리가 지금 가장 가치 있다고 믿는 선택의 순서"가 된다.

애자일은 불확실성이 높은 구현에 강하다. 요구사항이 조금씩 바뀌고, 고객 피드백에 따라 화면이 조정되며, 기술적 난관을 해결하면서 방향을 수정해야 할 때 효과적이다. 하지만 애자일만으로는 충분하지 않다. 스프린트가 아무리 빨라도 배포가 수동이고, 장애 대응이 즉흥적이며, 변경 영향 분석이 없다면 빠른 개발은 빠른 혼란이 된다.

그래서 애자일 다음에는 반드시 DevOps가 붙어야 한다.

DevOps는 속도와 안정성을 동시에 노린다

DevOps는 개발팀과 운영팀을 한 방에 앉히는 조직 개편이 아니다. 더 본질적으로는 고객에게 가치를 전달하는 경로에서 대기, 수작업, 책임 공백을 줄이는 방식이다.

코드가 작성된 뒤 테스트되고, 빌드되고, 보안 검사를 통과하고, 배포되고, 모니터링되는 전체 흐름이 자동화될수록 팀은 더 자주, 더 작게, 더 안전하게 변경할 수 있다. 작은 변경은 문제가 생겼을 때 원인을 찾기 쉽고, 롤백도 쉽다. 반대로 석 달치 변경을 한 번에 배포하면 장애가 났을 때 어디서 불이 시작됐는지 찾기 어렵다.

디자인 씽킹과 DevOps를 연결하면 더 강력해진다. 디자인 씽킹은 고객이 원하는 것이 무엇인지 묻고, DevOps는 그것을 빠르고 안정적으로 전달하는 방법을 제공한다. 한 자료에서는 디자인 씽킹이 고객 중심의 출발점을 만들고, DevOps가 품질을 유지하면서 시장 출시 속도를 높이는 데 초점을 둔다고 설명한다³. 이 둘을 함께 쓰면 "빨리 만들었지만 아무도 원하지 않는 것"과 "좋은 아이디어였지만 너무 늦게 나온 것"을 동시에 피할 수 있다.

DevOps의 핵심 지표는 배포 횟수만이 아니다. 변경 실패율, 복구 시간, 배포 리드타임, 장애 감지 시간, 고객 영향 범위까지 함께 봐야 한다. 속도는 안정성을 갉아먹는 핑계가 되어서는 안 되고, 안정성은 변화를 막는 명분이 되어서는 안 된다.

ITIL 4는 브레이크가 아니라 안전한 고속도로다

ITIL이라는 말을 들으면 어떤 사람은 두꺼운 문서, 느린 승인, 끝없는 프로세스를 떠올린다. 실제로 오래된 방식의 ITSM은 빠른 제품 팀에게 답답하게 느껴질 수 있다. 하지만 ITIL 4는 훨씬 유연한 방향으로 진화했다. 현대 ITSM은 경직된 절차보다 비즈니스 가치, 리스크 완화, 고객 경험, 지속적 개선을 강조하며, 애자일과 DevOps 환경에서도 적용 가능한 유연한 프레임워크로 설명된다⁴.

ITIL 4를 제대로 이해하려면 다음 한 문장을 기억하면 된다.

ITIL 4는 빠른 팀을 느리게 만들기 위한 통제 장치가 아니라, 빠른 팀이 고객 신뢰를 잃지 않게 만드는 운영 기준이다.

예를 들어 결제 서비스에서 배포 속도가 빠른 것은 중요하다. 그러나 결제 실패, 중복 청구, 개인정보 노출이 발생하면 속도는 아무 의미가 없다. 이때 변경 관리, 릴리스 관리, 인시던트 관리, 문제 관리, 서비스 수준 관리는 팀을 괴롭히는 행정 절차가 아니라 고객 신뢰를 지키는 안전장치가 된다.

다만 모든 변경에 같은 수준의 승인을 요구하면 안 된다. 버튼 색상 변경과 결제 정산 로직 변경을 같은 절차로 다루는 순간, ITIL은 가치 시스템이 아니라 병목 시스템이 된다. 좋은 팀은 변경을 위험도에 따라 나눈다. 낮은 위험의 표준 변경은 자동 승인하고, 중간 위험의 일반 변경은 가벼운 리뷰를 거치며, 높은 위험의 긴급하거나 중대한 변경은 명확한 승인과 롤백 계획을 요구한다.

서비스 유형에 따라 리듬을 다르게 설계하라

모든 서비스에 같은 실행 방식이 맞을 수 없다. 신생 AI 서비스, 쇼핑몰 UX 개선, 은행 내부 정산 시스템은 전혀 다른 리스크와 불확실성을 갖는다. 따라서 운영 리듬도 달라야 한다.

혁신형 서비스는 아직 고객 문제와 시장 반응이 불확실하다. 이 경우 긴 로드맵보다 짧은 실험, 빠른 프로토타입, 작은 사용자군 테스트가 중요하다. 디자인 씽킹과 린 스타트업의 비중을 높이고, 애자일은 실험 결과를 빠르게 구현하는 방식으로 붙인다. ITIL 관행은 최소한의 변경 기록, 장애 대응, 보안 기준부터 가볍게 시작하면 된다.

사용자 경험 개선형 서비스는 이미 사용자가 있고, 병목과 불만이 데이터에 남는다. 이 경우 고객 여정 분석, 사용성 테스트, A/B 테스트, 백로그 정제가 중요하다. 애자일과 DevOps의 반복 개선 능력이 중심이 되고, 운영 데이터가 다음 우선순위를 결정하는 연료가 된다. 예를 들어 가입 전환율이 떨어지는 구간, 검색 실패율이 높은 화면, 고객센터 문의가 반복되는 기능이 다음 스프린트의 출발점이 된다.

규제·보안·안정성이 중요한 절차형 서비스는 실험 속도보다 예측 가능성과 리스크 통제가 중요하다. 의료, 금융, 공공, 정산, 인증, 보안 인프라가 여기에 가깝다. 이 경우 변경 승인, 릴리스 캘린더, 감사 로그, 권한 관리, 사고 예방, 서비스 수준 관리의 비중을 높여야 한다. 그렇다고 느리게만 가야 한다는 뜻은 아니다. 자동화된 테스트, 배포 파이프라인, 표준 변경, 사전 승인된 운영 절차를 만들면 통제와 속도를 동시에 얻을 수 있다.

백로그와 인시던트는 같은 세계에 있어야 한다

많은 조직에서 제품 백로그, 로드맵, 릴리스 계획, 변경 요청, 장애 티켓, 고객지원 문의, 회고 액션 아이템이 서로 다른 도구와 회의에 흩어져 있다. 이러면 팀은 열심히 일하지만 학습하지 못한다.

최고의 실행 시스템에서는 이 모든 것이 하나의 운영 루프로 연결된다.

장애가 발생하면 인시던트 관리가 즉시 서비스를 복구한다. 하지만 여기서 끝나면 같은 장애가 반복된다. 문제 관리는 근본 원인을 찾고, 그 결과는 기술 부채 백로그나 아키텍처 개선 과제로 들어간다. 고객지원 문의가 반복되면 단순 응대 매뉴얼만 고치는 것이 아니라 UX 개선 백로그로 전환한다. 릴리스 후 특정 지표가 나빠지면 회고에서 배포 프로세스, 테스트 범위, 기능 가정까지 다시 본다.

이 연결이 만들어지면 백로그의 품질이 달라진다. 백로그는 더 이상 이해관계자의 소원 목록이 아니다. 고객 피드백, 운영 데이터, 장애 분석, 사업 목표, 기술 리스크가 함께 반영된 의사결정 장부가 된다.

팀이 매주 봐야 할 질문은 어렵지 않다.

• 고객이 가장 자주 막히는 지점은 어디인가?

• 최근 장애와 문의는 어떤 구조적 문제를 가리키는가?

• 이번 릴리스는 고객 가치와 운영 안정성에 어떤 영향을 줬는가?

• 다음 스프린트에서 반드시 줄여야 할 리스크는 무엇인가?

• 자동화하면 반복 비용이 크게 줄어드는 일은 무엇인가?

이 질문들이 회의실에서 반복되면 조직의 신경망이 바뀐다. 팀은 더 이상 기능을 찍어내지 않는다. 서비스를 학습시킨다.

조직 성숙도에 따라 도입 순서를 바꿔라

방법론 도입에서 가장 위험한 말은 "우리도 한 번에 제대로 하자"다. 한 번에 제대로 하려는 조직일수록 대개 아무것도 제대로 못 한다. 성숙도에 맞지 않는 프로세스는 근육이 아니라 족쇄가 된다.

초기 조직은 가벼워야 한다. 복잡한 ITSM 체계를 만들기보다 고객 인터뷰, 간단한 실험, 칸반 보드, 주간 회고, 기본 모니터링부터 시작하는 편이 낫다. 이 단계의 목표는 완벽한 절차가 아니라 학습 속도다. 단, 아무리 초기라도 장애 연락 채널, 서비스 소유자, 배포 기록, 최소 보안 기준은 있어야 한다.

성장 조직은 연결이 필요하다. 사용자가 늘고 팀이 커지면 머릿속으로 관리하던 일이 깨지기 시작한다. 이때 CI/CD, 자동 테스트, 제품 지표, 고객지원 태그 체계, 릴리스 노트, 온콜 규칙, 장애 회고를 붙여야 한다. 서비스가 여러 팀으로 나뉘기 시작하면 소유권과 인터페이스가 중요해진다. 서비스 성숙도 모델은 코드 품질, 보안, 신뢰성, 관측 가능성, 소유권 같은 기준을 통해 여러 팀의 품질 편차를 줄이는 데 도움을 줄 수 있다⁵.

대규모 조직은 거버넌스가 필요하다. 하지만 거버넌스는 "승인권자가 많아지는 것"이 아니다. 좋은 거버넌스는 무엇을 자동화하고, 무엇을 위임하며, 무엇을 반드시 검토해야 하는지 구분한다. ITSM 성숙도 평가는 현재 조직이 어디에 서 있는지 객관적으로 파악하고, 운영·전술·전략 개선 방향을 세우는 출발점으로 활용될 수 있다⁶. 대규모 조직일수록 변경 관리, 서비스 수준 관리, 공급업체 관리, 지식 관리, 지속적 개선 체계를 명확히 해야 한다.

실행 시스템을 설계하는 간단한 공식

이제 하나의 공식으로 정리해보자.

공감으로 문제를 발견하고, 실험으로 가정을 검증하고, 반복 개발로 가치를 만들고, 자동화로 전달하고, 서비스 관리로 신뢰를 지키고, 운영 데이터로 다시 배운다.

이 공식은 멋져 보이지만 실제 현장에서는 매우 구체적인 행동으로 바뀌어야 한다. 월요일에는 고객 피드백과 운영 지표를 보고, 화요일에는 우선순위를 조정하며, 수요일과 목요일에는 작은 단위로 만들고 테스트한다. 금요일에는 릴리스하거나 실험 결과를 정리하고, 장애와 문의에서 나온 학습을 다음 백로그에 넣는다. 매월 한 번은 로드맵을 다시 보고, 분기마다 서비스 수준과 기술 부채, 보안 리스크, 조직 병목을 점검한다.

좋은 실행 시스템은 팀을 바쁘게 만드는 시스템이 아니다. 중요한 일을 놓치지 않게 하는 시스템이다.

방법론은 이름이 아니라 리듬이다. 리듬이 맞으면 작은 팀도 거대한 조직처럼 일하고, 리듬이 틀리면 거대한 조직도 작은 장애 하나에 흔들린다. 최고의 IT 서비스는 천재 한 명의 번뜩임으로 만들어지지 않는다. 고객의 문제를 발견하고, 검증하고, 만들고, 배포하고, 운영하고, 다시 배우는 리듬을 매주 반복하는 팀이 만든다.

그리고 어느 순간 고객은 느낀다.

"이 서비스는 계속 좋아지고 있다."

그 말이야말로 실행 시스템이 제대로 작동하고 있다는 가장 강력한 증거다.

참고

¹How ITIL 4 Aligns with Agile, DevOps, and Lean Practices?

²Can You Combine Design Thinking with DevOps?

³How design thinking can supercharge DevOps work

⁴Ultimate guide to ITIL 4: Guiding principles and practices

⁵What is Service Maturity?

⁶ITSM Maturity Models: Your Roadmap to Service Excellence