공공 정보서비스 운영자에게도 전략이 필요한 이유 — 『좋은 전략 나쁜 전략』 독후감
공공 정보서비스 담당자가 『좋은 전략 나쁜 전략』을 읽고 핵심 문제 진단, 자원 집중, MVP 검증과 운영 지식 이전의 원칙을 실무 경험에 대입해 정리했다.
『좋은 전략 나쁜 전략』을 읽기 전까지 전략은 경영진이나 컨설턴트가 다루는 거창한 개념이라고 생각했습니다. 회사의 방향을 정하고 조직 전체를 움직이는 사람들에게는 필요하지만, 이미 만들어진 정보서비스를 운영하고 개선하는 실무자와는 조금 거리가 있는 말처럼 느껴졌습니다.
그런데 책을 읽으며 지난 업무를 하나씩 떠올려 보니 생각이 달라졌습니다.
새로운 기능을 만들 것인지, 이용자가 불편해하는 기존 기능부터 고칠 것인지 결정하는 일. 여러 기관에 한꺼번에 적용할 것인지, 일부 기관에서 먼저 검증할 것인지 선택하는 일. 한정된 개발인력과 예산을 어디에 집중할지 판단하는 일. 이 모든 것이 전략이었습니다.
좋은 전략은 멋진 목표를 많이 적는 일이 아니었습니다. 지금 가장 중요한 문제를 정확히 찾고, 그 문제를 해결할 곳에 자원을 집중하는 일에 가까웠습니다.
- 책 제목: 전략의 거장으로부터 배우는 좋은 전략 나쁜 전략
- 저자: 리차드 럼멜트
- 출판사: 센시오
- 독서 기간: 2026년 8월 9일 ~ 8월 17일
전략은 목표가 아니라 문제 진단에서 시작한다
공공 정보서비스를 운영하다 보면 개선해야 할 일이 끝없이 생깁니다.
통계 화면을 더 보기 좋게 만들 수도 있고, 새로운 기술을 적용할 수도 있습니다. 이용자 편의를 위한 부가서비스나 AI 기능도 생각해 볼 수 있습니다. 모두 있으면 좋은 기능입니다.
하지만 시스템이 존재하는 근본적인 이유부터 생각하면 우선순위는 달라집니다. 이용자가 핵심 업무를 정확하고 안정적으로 처리할 수 있어야 하며, 오류가 발생했을 때 원인을 찾고 복구할 수 있어야 합니다. 기본 기능이 불편하거나 불안정한 상태라면 화려한 부가 기능을 추가해도 좋은 서비스라고 말하기 어렵습니다.
책을 읽으며 전략의 출발점은 “무엇을 더 만들까?”가 아니라 다음과 같은 질문이어야 한다고 느꼈습니다.
- 지금 이용자가 가장 크게 겪는 문제는 무엇인가?
- 그 문제는 기능 부족 때문인가, 복잡한 절차 때문인가, 안내 부족 때문인가?
- 문제를 해결하면 누구의 일이 얼마나 나아지는가?
- 지금 가진 인력과 예산으로 가장 효과적인 방법은 무엇인가?
문제를 제대로 진단하지 않으면 새로운 기능은 쉽게 목적이 됩니다. “사업계획에 있으니까”, “과업서에 적혀 있으니까”, “요즘 AI가 중요하니까”라는 이유만 남고, 정작 누구의 어떤 문제를 해결하는지는 흐려질 수 있습니다.
이용자가 원하는 것은 의외로 화려하지 않았다
최근 한 개선사업을 준비하면서도 비슷한 경험을 했습니다. 처음에는 새로운 기술을 활용한 기능이 눈에 잘 들어왔습니다. 기술적으로도 흥미롭고, 사업의 성과를 설명하기에도 좋아 보였습니다.
하지만 실제 연계 업무를 수행하는 개발자들의 이야기는 달랐습니다. 그들이 필요로 한 것은 더 실질적인 개발 가이드였습니다.
데이터가 어떤 관계를 가지는지, 어떤 방식으로 조회하고 연결해야 하는지, 실제 연계 과정에서 어떤 오류와 예외가 발생하는지처럼 현장에서 바로 활용할 수 있는 정보가 부족하다는 의견이었습니다.
새로운 기능과 실무 가이드를 모두 만들 수 있다면 가장 좋습니다. 그러나 자원은 항상 한정되어 있습니다. 그렇다면 “새 기술을 적용했다”는 사실보다 현재 이용자가 겪는 문제를 무엇이 더 직접적으로 해결하는가를 기준으로 우선순위를 정해야 합니다.
때로는 AI 기능 하나보다 잘 정리된 가이드 문서 한 권이 현장에 더 큰 도움이 될 수 있습니다. 이미 정해진 계획이라도 실제 문제와 거리가 멀다는 사실을 알게 되었다면 방향을 바꾸는 것이 오히려 좋은 전략일 수 있습니다.
전략은 정답이 아니라 검증해야 할 가설이다
책에서 특히 인상 깊었던 부분은 전략을 하나의 가설로 보는 관점이었습니다.
전략에는 미리 정해진 정답이 없습니다. 현재 상황을 해석하고 “이 방향으로 움직이면 문제가 해결될 것”이라는 가설을 세운 뒤, 실행 결과로 맞는지 확인해야 합니다.
시스템 개선도 마찬가지입니다. 개발자에게 기능 목록만 전달해서는 부족합니다.
- 왜 이 기능이 필요한가?
- 누가 어떤 상황에서 사용하는가?
- 적용 후 무엇이 좋아져야 하는가?
- 효과를 무엇으로 확인할 것인가?
이 질문에 답할 수 있어야 개발자도 단순히 화면과 기능을 구현하는 사람이 아니라 같은 문제를 해결하는 동료가 될 수 있습니다.
가설은 틀릴 수 있습니다. 그렇기 때문에 불확실한 서비스를 처음부터 큰 규모로 만드는 것은 위험합니다. 최소한의 기능과 대상에서 먼저 실행해 보고, 실제 이용자의 반응과 운영 부담을 확인한 뒤 확대하는 편이 낫습니다.
요즘은 이를 MVP나 시범운영이라는 말로 표현하지만, 핵심은 단순합니다. 작게 시작하면 실패의 비용을 줄이고, 배운 내용을 다음 결정에 반영할 수 있습니다.
크게 시작했던 사업을 돌아보며
몇 년 전, 관련 업무를 충분히 경험하지 못한 상태에서 규모가 큰 기능개선 사업을 맡은 적이 있습니다. 짧은 인수인계를 받은 뒤 여러 과업을 동시에 추진해야 했습니다.
사업은 이미 움직이고 있었기 때문에 요구사항 분석, 설계, 개발은 계속 진행됐습니다. 하지만 과업이 만들어진 배경과 해결하려는 문제를 충분히 이해하지 못하니 개발 내용을 구체적으로 검토하거나 방향을 제시하기 어려웠습니다.
서비스를 연기하면서까지 많은 시행착오를 겪었지만, 운영단계에서 돌아보면 여전히 이런 질문이 남았습니다.
그래서 이 서비스는 누구에게 어떤 도움이 되었는가?
이 질문에 명확하게 답하기 어렵다는 것은 “무엇을 만들 것인가”는 정해져 있었지만 “왜 만들어야 하는가”에 대한 진단은 부족했다는 뜻이었습니다.
그때로 돌아간다면 처음부터 여러 대상을 상대로 크게 추진하지 않을 것입니다. 한 곳에서 최소한의 기능으로 먼저 구축하고, 실제 편의성과 운영 부담을 확인한 뒤 확대했을 것입니다. 과업서에 적혀 있다는 사실이 그 과업의 필요성을 자동으로 보장하지는 않기 때문입니다.
이 경험은 실패했다는 자책보다 다음 사업에서 사용할 판단 기준으로 남았습니다. 되돌리기 어려운 결정일수록 문제를 더 깊게 살펴야 하고, 가능하면 작은 범위에서 먼저 검증해야 합니다.
시스템보다 오래 남아야 하는 것
공공 정보시스템은 영원하지 않습니다. 정책과 제도가 달라지면 다른 시스템과 통합되기도 하고, 역할이 축소되거나 새로운 체계로 전환되기도 합니다.
그렇다면 운영 중인 시스템의 성공을 얼마나 오래 존속했는지만으로 판단할 수는 없습니다. 오랜 기간 축적한 업무규칙, 데이터 구조, 예외처리, 장애 대응, 기관별 연계 경험을 다음 체계에 제대로 넘기는 것도 중요한 성과입니다.
새 기능을 계속 추가하는 것만이 시스템을 발전시키는 방법은 아닙니다. 언젠가 역할이 바뀔 가능성이 있다면 안정적인 운영을 유지하면서 다음 체계가 같은 시행착오를 반복하지 않도록 지식과 경험을 정리하는 일이 더 중요한 전략이 될 수 있습니다.
결국 공공 정보서비스의 목적은 특정 시스템 자체를 오래 유지하는 데 있지 않습니다. 이용자에게 더 나은 서비스를 제공하고, 공공의 업무가 안정적으로 이어지도록 만드는 데 있습니다.
앞으로 지키고 싶은 세 가지 원칙
『좋은 전략 나쁜 전략』을 읽고 앞으로 업무에서 지키고 싶은 원칙을 세 가지로 정리했습니다.
1. 되돌리기 쉬운 일은 빠르게 실행한다
방향이 명확하고 실패해도 쉽게 원상복구할 수 있는 일은 지나치게 오래 검토하지 않습니다. 빠르게 실행하고 결과를 확인합니다.
2. 새로운 서비스는 작게 시작한다
처음부터 모든 기능과 대상을 포함하면 운영비용뿐 아니라 시행착오의 비용도 커집니다. 최소한의 범위에서 가설을 검증하고, 효과가 확인되면 단계적으로 확대합니다.
3. 왜 하는지 설명할 수 없는 일은 다시 검토한다
누구의 어떤 문제를 해결하고 무엇이 어떻게 좋아지는지 설명할 수 있어야 합니다. 이미 계획된 일이라도 의미가 약하다고 판단되면 방향을 바꿀 수 있어야 합니다.
세 가지 원칙은 결국 하나로 이어집니다.
되돌리기 쉬운 결정은 빠르게 실행하고, 되돌리기 어려운 결정은 충분히 진단한 뒤 작게 검증하고 확대한다.
전략은 실무자의 일이다
이 책은 쉽게 읽히지는 않았습니다. 기업과 국가 수준의 사례가 많아 처음에는 내 업무와 거리가 있다고 느꼈습니다. 하지만 실제 경험을 하나씩 대입하면서 전략은 경영진만의 일이 아니라는 것을 알게 됐습니다.
기능 하나를 개발할지 말지 결정하는 것, 새로운 기술과 이용자가 요청한 개선사항 사이에서 우선순위를 정하는 것, 여러 대상에 한꺼번에 적용할지 일부에서 먼저 검증할지 선택하는 것 모두 전략입니다.
좋은 전략은 계획을 많이 만드는 일이 아닙니다. 가장 중요한 문제를 찾고, 해결 방향을 정하고, 한정된 자원을 집중해 실제 행동으로 옮기는 일입니다. 그리고 전략이 가설이라면 실행 결과를 보고 방향을 바꾸는 것까지 전략에 포함됩니다.
앞으로 새로운 기능이나 사업을 검토할 때 가장 먼저 “왜 하는가?”를 묻고 싶습니다. 답이 명확하고 되돌리기 쉽다면 빠르게 실행하고, 불확실하다면 작게 시작해 검증하고, 의미가 없다면 이미 정한 방향이라도 바꿀 수 있는 실무자가 되고 싶습니다.
함께 읽을 글:
썸네일 사진: Long Chung의 Unsplash 이미지
이 포스팅이 가치 있었나요?
여러분의 평가는 콘텐츠의 품질을 결정하는
가장 핵심적인 데이터가 됩니다.
실시간 익명 데이터로 수집되어 블로그 운영에 반영됩니다.