[斷想] 문제해결의 기술(The Art of Problem Solving)

아, 정말 오랜만에 글을 쓴다.

2022년 7월, 이직하게 되었다. 이직을 하고나면 항상 업무의 전체 구조를 파악하고 개선점을 판단할 수 있을 때까지 달려나간다. 세상 관심사에 모두 신경 끄고 무조건 앞으로만 달리는 스타일이다 보니 또 열심히 달려오느라 지난 한 달 정도는 세상이 어떻게 돌아가는지도 모르고, 본인의 취미가 뭐였는지도 모르는 시간을 보냈다. 당연히 책도 읽지 못했고, 글도 쓰지 못했다. 어느덧 첫 번째 월급을 받고 나니 이제야 조금 정신이 들어 8월엔 다시 책도 읽고 글도 쓰기 시작해야 겠다 싶다.

어느 회사에 가나 비슷한 양상이 있다. 분명히 누군가도 최선을 다해서 업무한 거 같은데 왜 그런 결정을 한 건지 의사결정 구조를 볼 수 없거나, (해당 업무의 전문가라면 하지 않을 선택들이 있기에) 어디선가의 위력에 의해 의사 결정된 흔적이 보이거나, 본인에게 전문성이 없는 업무 같은데 할 수 있다는 착각에 빠져 안 하느니만 못하게 어질러 놓은 경우들에 대한 결과들이다.

그런 상태를 만든 사람들의 의도나 실력을 의심하거나, 악의적인 평가를 할 필요는 없다. 그들도 그 업무를 진행하던 시점에는 선의를 가지고, 그 상황에 맞게 최선을 다한 것이라 믿기 때문이다. 그러니 비난하거나 원망하는 마음을 가질 이유도 없다. 다만, 필자의 짧은 식견으로 판단하기에 그런 상태가 된 것은 항상 문제 해결 방식에서 뭔가 하나를 빠뜨렸기 때문이라 생각한다.

문제 해결이라는게 다들 스스로 자기만의 스타일대로 방식을 설정하고, 수행하는 분야다보니 어디 좋은 방법론이 있다거나, 무엇이 옳은 지에 대한 고민을 잘 하지 않게 되는거 같다. 필자도 그랬고. 그래서 다들 그냥 자기 스타일대로 문제를 해결하는 게 오히려 현실에서는 문제가 되는 거 같달까. 필자 역시 그렇게 자신만의 스타일을 고수하다가 어느 순간 문제 해결 분야의 경지 대해 고민을 했고, 그 길을 따라 공부하다보니 브레인스토밍 전문가들도 만나고, 나이차이 많이 나는 어르신들도 만나 그들 방식의 문제 해결 방법론들을 배울 수 있었다. 그리고 정리했다. 필자 나름대로 생각하게엔 진리에 가까운 그 무엇인가를 찾았기에.

그러나, 필자는 문제 해결 분야의 전문가가 아니기 때문에 여태까지는 굳이 필자가 정리한 내용을 블로그에 공개하지 않았었는데, 나이 들어감에 대한 긍정적인 소회에서 밝힌 바와 같이 이제 나이 들었음에 대한 생각을 정리하고, 나이들었음을 인정하기로 했으니 굳이 철학을 감추어둘 필요는 없다는 생각이 들었다. 왜냐하면, 이제 남이 뭐라 그래도 여태껏 이렇게 잘 살아왔고, 앞으로도 이렇게 살거란 생각이 들었으니까. 그래서 필자가 오래전에 스스로 정리해뒀던 ‘문제 해결(Problem Solving)’이라는 것에 대해 정리해서 블로그에 이야기해야겠다 싶었다.

사실 이 글의 소제는 몇 년 전에 정리해서 개인 메모에 넣어둔 내용인데 이번 기회에 정리를 좀 해서 공개해야 겠다 싶었다. 누군가 보기에는 필자의 이 포스팅이 충분치 않다고 생각하거나 반론이 있을 수도 있다. 상관 없다. 필자는 스스로 깨달은 바에 대해 정리한 것이니까. 다시 말하지만, 여지껏 이렇게 살아왔고, 아마 앞으로도 이렇게 살것이기 때문에. 누군가에겐 이 글로 도움을 줄 수 있기를 바라며 필자의 정리를 써내려본다.

본격적으로 문제 해결이라는 명제를 논하기 위해 이 포스팅의 제목을 뭐로 할까 5초 정도 고민하다가, 「The art of software testing」을 따라 해 보자~ 싶었다. 그 책에 설명된 핵심들 만큼이나 아주 간략하고 명확하게 문제 해결에 관해 설명할 수 있을 거 같다는 자신감이 있어서다. 그래서 포스팅의 제목은「문제 해결의 기술(The art of problem solving)」로 정했다.

사실, 문제 해결이라는 건 간단하지만 조그만 인식의 전환이 필요하다. 그리고 한번 깨달으면 그 뒤로는 스스로 연습해서 익숙해지는 과정이 좀 필요할 뿐, 한번 몸에 익히면 자전거를 타거나, 수영을 하거나, 섹스를 하는 거처럼 완전히 체화(體化)된다. 긴 시간 동안 사용하지 않는다고 해도 절대 몸에서 기억해낸다. 그러니, 누군가 지금 필자의 포스팅을 읽고 ‘세련된 문제 해결 능력을 갖추고 싶다’라는 생각을 했다면, 본 포스팅을 읽은 후 꼭 본인의 버릇이 되도록 체화하려 노력하는 과정을 거치시기를 권장한다. 한번 체화되면 자연스럽게 그렇게 되기 때문에 편리하고, 마음이 아주 편해진다.

자, 문제 해결이라는 건 단편화시키면 사실 아주 쉽다.

우리는 배고프면 밥을 먹는다. 「배가 고프다」라는 문제를 해결하기 위해서는 「밥을 먹는다」라는 문제 해결 방법을 찾아 그 행위를 수행하면 된다. 근데, 조금만 더 깊이 생각해보면 단순히 그걸로 끝나지 않음을 알 수 있다. 조금만 더 깊이 있게 생각해보자. “밥 먹는다”라는 표현은 단순히 먹는 행위를 말하기보다 정확히는 아래의 흐름을 말한다.

배가 고프다 → 음식 재료 확보를 위해 장을 본다 → 장 본걸로 요리를 한다 → 식사를 한다 → 치운다

이 내용을 프로세스로 단편화 시키면 아래와 같다.

프로세스	행위
문제 인식	① 배가 고프다.
문제처리를 위한 사전 행위	② 장을 본다.
해결 준비	③ 요리를 한다.
문제 해결	④ 식사를 한다.
후처리	⑤ 치운다. ……………………………………………

너무 당연한 이야기이지만, 또 너무 당연한 이야기라서 이게 맞는 프로세스인지 의심하는 사람도 있을 거다. 그래, 이해한다. 그래서 이게 맞는 프로세스임을 증명하기 위해 한 번 더 다른 예를 들어보자. 더 이해가 잘되는 예제일 거라 생각한다. 이번엔 대변을 보는 시나리오를 상정해 보자.

프로세스	행위
문제 인식	① 배가 아프다. 대변이 나올거 같다.
문제처리를 위한 사전 행위	② 화장실의 위치를 찾는다.
해결 준비	③ 화장실로 가서 변기가 있는 공간으로 들어간다.
문제 해결	④ 대변을 배출한다.
후처리	⑤ 화장실 물을 내리고, 나와서 손을 씻는다.

만약 본인이 이런 상황인데, 대변을 본 후 물을 내리지 않았다고 치자. 대변을 배출한 본인은 속이 시원하니 대변-배출이라는 문제를 해결한 거 같겠지만, 다음 사람은 그 화장실 칸에 들어가서 이렇게 외칠 거다. “어떤 놈이 똥 싸고 물을 안 내렸어!!”

자, 이제 쉽게 이해될거다. 문제를 해결하기 위한 행위의 주체자인 본인은 ‘대변을 배출한다’라는 문제 해결에만 집중했고 해결했으니 문제가 해결됐다고 생각했다. 하지만, 그다음 사람은 그 변기를 이용한 전 사람의 대변을 배변하는 행위에 대해 “물을 내리는 것”까지가 프로세스의 완료라고 인식하는 것이다.

즉, 「문제 해결을 위한 모든 행동은 단순히 문제 해결 단계에 초점을 맞추기보다는 문제 해결을 위한 전체 프로세스 관점에서 행위를 바라보아야 한다」는게 필자가 문제해결과 관련하여 말하고자 하는 바다.

쉽게 말해, 배가 고파 밥을 먹었으면 치우는 거까지가 밥을 먹는 거고, 화장실에서 똥을 쌌으면 물을 내리고 손을 씻어야 해당 행위가 완료된다는 소리다. 같은 맥락으로, 업무를 진행했으면 그 업무를 문서로 정리하는 거까지가 업무의 종료이다. 그냥 이슈를 눈앞에서 처리했다고 끝난 게 아니다. 모든 업무의 끝은 문서화 혹은 기록을 남겨 다른 사람이 이해할 수 있게 해 주는 데서 끝이 난다. 이는, 단순히 보고하기 위한 용도의 문서가 아니라, 해당 업무를 10년 뒤에도 이해할 수 있도록 하는 문서를 의미한다.

업무하다 보면 바빠서 가끔 깜빡 잊고 놓치는 부분이 있을 수도 있다. 그러나, 가끔이 아니면 문제다. 만약 대부분의 업무 기록에서 의사결정 과정을 찾는 게 불가능하거나, 업무가 단일 업무 형식으로 기록되어 있고 전체 스토리를 읽을 수 없는 경우라면 이는 전부 문제 해결 역량 미흡에서 생기는 이슈들이다. 그리고, 진짜 문제는 이런 정보의 미흡함이 쌓여서 그 모호함 자체가 조직의 문화가 되기도 하는 부분이다.

사실…… 이건 프로세스라고 부르기도 뭐한 너무 당연한 내용이다. 근데, 너무 당연하다 보니 일을 잘 처리하려고 노력하는 순간에는 오히려 정상적으로 인지가 되지 않거나, 문제 해결이라는 그 자체에 너무 집중하다 보면 전체 프로세스를 보지 못하는 실수가 발생하곤 한다. 그래서 항상 모든 상황에서 전체 구조를 파악하려 애써야 하는 거다.

그런걸 보고 정황-기반, Context Driven이라 하지 않던가!
필자는 정황 기반 학파(Context Driven School)가 말하는 방식을 따른다.

이는 또한 소프트웨어 개발자라면 누구나 흔히 알고 있는 SDLC(Software Development Life-Cycle)와도 일치한다.

프로세스	행위
문제 인식	① 사용자 혹은 사업에 필요 사항 혹은 이슈가 발생한다.
문제처리를 위한 사전 행위	② 요구사항을 분석하고, 설계한다.
해결 준비	③ 요구사항에 기반하여 기획한다.
문제 해결	④ 구현하고, 테스트한다.
후처리	⑤ 배포하고, 운영한다.

보시는 바와 같이 이 프로세스는 필자가 창조한 게 아니다. 원래 있던 현상들을 필자가 분석해서 「문제 해결이라는 틀에 맞추어 정리한거 뿐」이다. 원래 세상 모든 일이 이렇게 진행되는 거다. 아니, 되어야만 하는거다. 그냥 전부 다 콩으로 메주 쑤고, 쌀로 밥 짓는 소리다. 아주 쉽고 간단하며, 당연한 소리란 의미다. 자꾸 강조하지만, 뭘 잘하려고 하다 보면 이 당연한 것들을 잊게 된다. 그래서 자꾸만 뭔가 특별한 방법을 찾고 기술을 찾아 적용하려고 하게 되는데, 그럴 필요 없다. 그냥 당연한 일들을 당연하게 생각하고, 당연하게 수행하면 세상 거의 모든 문제는 해결된다. 항상 그렇지만 기본기가 제일 중요하다.

당연한 걸 당연하게 하는 것, 이게 바로 「문제 해결 기술, The art of problem solving」의 핵심이다.