문제를 해결하는 방법
어릴 적 PC 게임을 했다.
인터넷이란게 없던 시절, 직접 데스크탑 로컬에 설치하는 게임이었다. 플로피 디스크 여러 장을 번갈아 끼우며 인스톨하던 낭만이 있었다. 당시 몇 가지 게임을 했었는데, 그 중 Command and Conquer라는 게임이 기억난다.
전략 시뮬레이션 이라고 부르면 되려나. 쉽게 말해 전쟁을 지휘하는 내용이다. 자원을 들여 각종 무기들을 생산하고, 그 무기들을 적재적소에 배치 및 교전하여 승리를 가져오는 그런 게임이었던 걸로 생각한다. 아닐수도 있다. 워낙 오래되어 기억이 흐릿하다.
Command and Conquer 제목이 마음에 들었다. Command and Conquer 라는 제목에서, 어린 나는 뭔지 모를 쾌감을 느꼈었나보다. 어떤 무기를 어떻게 생산하고 어디에 배치하라고 ‘명령’을 내리면, 교전을 통해 아군은 승리하고 ‘정복’ 했다. ‘정복’한다는 단어가 주는 어감이 어쩐지 폭력적이지만, 인생은 싸움으로 무언가를 정복해가는 과정의 연속이라고 생각했다. 당시엔 그만큼
어렸다.
IT서비스를 기획운영 하면서, '당신은 무슨 일을 하는 사람입니까?' 라는 질문을 종종 듣는다.
그럴 때마다 나는, '문제를 해결하는 사람입니다' 라고 대답하곤 했다. 기능 추가/개선, 고도화, 운영, VoC 모두 '문제를 해결하는 일'이다. '기능 개선'이 무슨 문제 해결인가요? 라고 묻는다면, 그것 또한 결국 그 근본은 ‘문제 해결’이다. 문제가 없다면 개선할 기능은 존재하지 않기 때문이다.
개선 포인트가 없는 '궁극의 서비스'는 절대 존재하지 않는다. 시대가 변하고 환경이 변하며 사용자의 요구사항은 늘 바뀌기 마련이다. 요구사항이 바뀌었는데, 시스템이 그걸 따라가지 못한다면 그건 '문제'다. 시스템은 사업 모델과 수익 환경에 따라 진화해야 한다. 변하는 건 당연한 일이다. 그래서 문제는 필연적으로 발생한다.
그렇다면 문제를 해결하기 위한 방법에는 어떤 것이 있을까. 일을 시작한 초기에는 Command and Conquer가 맞는 줄 알았다. 시스템에 커맨드를 날리면 해결이 된다고 생각했다. 무작정 달려들어서 전쟁을 시작했다. 일단 앉아서 떠오르는대로 일을 했다. 문제가 크던 작던 상관없었다. 일단 교전을 시작한다. 뭐라도 하면 언젠간 해결이 되겠지 라고 생각했다. 닥치고 일단 돌격. 그런데 이상하게 해결이 되지 않더라. 안개속을 헤매며 뛰어다니다가, 지쳐 나가떨어지기 일쑤였다.
그렇게 일을 하다 보니 방식이 서서히 바뀌었다. Command and Conquer 에서 Divide and Conquer 로.
divide and conquer (분할과 정복)
소프트웨어 개발 방법론 중의 하나인 'divide and conquer algorithm'. 프로그래밍 과정에서 큰 문제를 두개 이상으로 쪼개어 해결할 수 있을 만큼 간단하게 만든 후, 그 작은 문제들의 솔루션을 결합하면 결국 큰 문제가 해결된다는 방법론이었다. 나는 개발은 전혀 모른다. 하지만 어쩐지, 일에서, 인생에서 써먹을 수 있는 방식이라고 생각했다.
실제로 일을 하며 문제를 처음 맞닥뜨리면 굉장히 막연하고 손대기 힘들다. 실체 파악이 쉽지 않아 형태가 모호한 문제가 대부분이다. 의욕만 가지고 달려들어보지만 해결은 커녕 일이 점점 복잡해지기만 한다. 잘하고 싶은데 그게 잘 안된다. 그러니까 어쩐지 싫고, 모른척 하고 싶다.
하지만 그 본질을 가만히 들여다 보면 큰 덩어리 하나가 눈에 띈다. 여기까지가 어렵다. 하지만 일단 큰 덩어리를 찾아내어 하나의 문장으로 표현했다면 거의 다 된거다.
그럼 그걸 나눈다. 나눌 수 있는 만큼 문제를 나눈다. 단, 비슷한 유형으로 나누는 것이 중요하다. 그래야 리스트가 나열된다. 그림그리기, 땅파기, 신발신기, 노래부르기 이런 식의 중구난방식 타입은 나눠도 일하기 어렵다. 차분히 앉아서 외부협력/내부조율, 기획/개발, FE/BE/TABLE, 분석/설계/개발/테스트/배포 등등 아무튼 비슷한 유형의 문제들로 나눈다. 종이에 연필로 적어도 좋다. 기록하면 뇌가 편하다.
비슷한 유형이나 타입의 하위 문제로 잘게 나눴다면. 순서대로 차근차근 처리한다. 담당자를 지정해도 좋고, 스스로 해도 좋다. 중요한 건 나눠진 태스크가 명확하냐는 것이다. divide and conquer 작은 문제를 하나씩 해결하다보면 성취감을 느끼며 성장할 수 있다. 무엇보다, 당면한 문제를 정복할 수 있다.
가끔 업무 지라에 티켓을 생성하시는 분들을 보면, 너무 거대한 문제를 티켓 하나로 만들어 놓고 머리를 부여잡고 힘들어하신다. ‘ㅇㅇㅇ 시스템 고도화’ 같은 제목인데, 이런건 그 누구도 해결할 수 없다. 수십명을 회의실로 불러모아 저런 제목의 티켓을 화면에 띄워놓고 '일단 방법을 찾아보자'고 한다. 될 리가 있나.
비슷한 유형의 작은 티켓으로 최대한 작게 나누어야 한다. 리더. 시키는 사람부터 나눠진 태스크들을 머리에 어느정도 그려놓고 실무자들과 이야기해야 한다. 그래야 싸움에서 이긴다. 작은 전투에서 이겨야 전쟁에서 승리하고, 그래야 문제를 정복할수 있다.
프로젝트도 마찬가지다. 'ㅇㅇ ㅇㅇ 구축 프로젝트' 라고 이름만 거창하게 만들어놓고 만만한 PM을 불러다가 해보라고 시킨다. 이게 뭐냐고 물어보면 시키는 상위직책자는 정작 설명을 못한다. 화이트보드에 대충 그림을 그려가며 설명하지만 그게 맞는지 긴가민가 하다. 본인도 잘 모르니까. 명확하지도 않은 프로젝트를 저한테 왜 시키시는거냐고 재차 물어보면, 상위직책자는 '몰라. 나도 위에서 시키니까 전달하는거야. 뭘 해야 되는지는 니가 알아봐야지' 라고 답한다. 의욕이 생길리가. 동기부여는 딴 나라 이야기다.
이렇듯 덩어리가 큰 문제는 의사전달이 어렵다. 파악이 쉽지 않으니, 시키는 사람도 지시받는 사람도 무슨 소린지 모르고 떠든다. 서로 힘들고 괴롭다.
divide가 우선이다.
시키는 사람부터 어느정도 divide 된 리스트를 가슴에 품고 있어야 한다. 적어도 큰 줄기라도. 그래야 실무자들이 전투에서 이긴다. ‘그냥 싸워서 이겨!’ 라고 무지성으로 명령하면 몰살당한다. 자잘한 전투에서 이겨야, 전쟁에서 승리하고 conquer 할 수 있다.
어려운 문제 때문에 골머리를 썩히고 있다면, divide and conquer를 기억하자.
작은 문제들의 해결이 하나씩 모여 , 결국 큰 문제는 자연스럽게 사라질 것이다.
지금 당신이 해결해야 할 문제는 무엇입니까.
부디 나눠서, 정복하길 빕니다.
