생각 프레임워크

우리가 정해진 규격에 따라 개발하기 위해 프레임워크를 사용하는 것처럼, 사고에도 프레임워크를 활용하면 좋습니다. 저의 커리어 전반에서 가장 큰 영향을 미친 요소는 개발 공부, 개인/팀 프로젝트, 커뮤니티 활동, 독서가 아니라 바로 "생각 프레임워크"입니다. 생각 프레임워크는 문제로 가득한 세상을 살아가는 데 전반적으로 영향을 미치며, 성공 경험과 의사결정 경험을 통해 더 큰 문제를 해결할 수 있는 역량을 키워 선순환을 만들어 냅니다.

개발자라면 "프레임워크"라는 용어는 익숙할 것입니다. 그러나 "생각 프레임워크(Framework Thinking)"는 생소하게 들릴 수 있습니다. 저 역시 별다른 생각 없이 사용하던 방법론이 누군가에게는 "생각 프레임워크"라는 용어로 불린다는 사실을 알게 되었습니다.

조금 거창한 예시로 BCG Matrix가 있습니다. 이 개념은 『맥킨지 논리력 수업』이라는 책에서 접한 것으로, 기업이 보유한 사업들을 분류하기 위한 방법론입니다. 이는 경쟁력과 성장률을 기준으로 측정하는 방식입니다. 이 개념을 머릿속에 익힌 사람은 대화를 나누거나 자료를 검토하며 해당 기업의 사업이 캐시카우인지, 미래 먹거리인지, 혹은 자원을 낭비하는 사업인지 파악할 수 있습니다.

이렇게 사고의 방법론을 개인의 문제 해결 방식으로 적용해 보겠습니다. 아마도 자신의 문제 해결 방식을 곰곰이 생각해 보면 아래와 같이 한두 문장으로 정리할 수 있을 것입니다.

• 문제를 최대한 작은 단위로 쪼개고, 하나씩 해결해 나가며 큰 문제를 해결합니다.
• 현상에 대한 패턴을 찾아 비슷한 패턴의 문제 해결 방식을 적용하여 해결합니다.
• 가설을 세우고 이를 검증하는 피드백 루프를 돌리며 문제를 해결해 나갑니다.

훌륭합니다. 이러한 방식으로 문제를 효과적으로 해결해 왔다면, 이미 뛰어난 생각 프레임워크를 활용하고 있는 것입니다. 저 역시 저만의 생각 프레임워크를 보유하고 있습니다.

Problem-Defined Regression Framework

저는 문제를 해결할 때 사용하는 저만의 생각 프레임워크를 가지고 있습니다. 주변 동료들과 대화를 나누거나 회의를 진행하며 의견을 제시할 때, 관련 문서를 작성할 때, 혹은 실무에서 지식을 적용할 때 모두 이 프레임워크를 사용합니다.

BCG Matrix처럼 멋진 이름을 붙이고 싶어서 Problem-Defined Regression Framework라는 이름을 지어 보았습니다.

• "Problem-Defined"는 문제 정의가 가장 중요한 과정임을 나타내고자 했습니다.
• "Regression"은 어떤 단계에서든 문제 정의로 돌아가 불필요한 문제 정의를 배제하는 것이 중요함을 강조하기 위함입니다. 이를 간단히 소개하면 아래 그림과 같습니다.

문제 정의

모든 사고의 시작은 문제 정의입니다. 문제 정의는 최근 몇 년간 배운 용어 중 단연코 가장 강력한 개념입니다. 문제를 정의한다는 것은 제가 해결해야 할 문제가 무엇인지 스스로 명확히 규정하는 과정입니다. 이 과정은 보통 한두 문장으로 정리될 정도로 간단하지만, 그 결론을 도출하기 위해서는 문제와 고객에 대한 공감, 현재 상황에 대한 인지, 그리고 이를 뒷받침할 수많은 데이터가 필요합니다.

문제 정의는 이 문제 해결 피드백 루프의 출발점입니다. 문제 정의를 잘하면 후속 과정들의 난이도가 크게 달라집니다. 잘못된 문제 정의는 허공에 주먹을 휘두르는 쉐도우 복싱과 같고, 잘 정의된 문제는 유효타로 이어져 상대를 쓰러뜨릴 수 있는 날카로운 통찰력을 제공합니다. 혹시 문제의 복잡도를 낮추라는 의미로 오해될까 봐 말씀드리자면, 문제 정의의 핵심은 진짜 문제를 찾아내는 것입니다. 유명한 방법론으로는 5-Whys가 있습니다.

문제를 정의할 때 주의해야 할 점은 문제의 추상화 수준입니다. 문제의 추상화 수준이 높아질수록 그 해결에 대한 복잡도는 피보나치 수열처럼 기하급수적으로 증가합니다. 예를 들어, UN이라는 조직이 정의한 문제는 "세계 평화"입니다. 조직의 문제 정의인 만큼 추상화 수준이 높지만, 이 문제를 해결하려면 온 세상을 통달한 철학자 한 트럭을 동원해도 어려울 것입니다. 반대로 실무에서는 문제를 날카롭게 정의하면 간단하고 빠르게 해결할 수 있습니다.

그래서 저는 문제 정의 과정을 매우 중요하게 생각합니다. 실무에서도, 면접에서도 항상 문제 정의를 강조하며 이 용어를 적극적으로 활용해 의사소통합니다. 예를 들어 다음과 같습니다:

• 문제 정의가 포함된 문서가 있습니까?
• 무엇이 진짜 문제입니까? 이건 단순한 현상이 아닌가요?
• 문제 정의를 보면 이 방법으로는 문제를 해결할 수 없을 것 같습니다.
• 고객 문제로 보기에는 근거가 부족해 보입니다.
• 정의된 문제가 해결되었다고 판단할 수 있는 지표는 무엇입니까?
• 사용자가 브라우저의 다른 탭에 있을 때 애플리케이션에 할당된 메모리 해제 문제를 문제 정의로 제시하셨는데, 어떤 점을 확인하고 그렇게 정의하셨습니까?

이러한 표현은 팁이라 할 수 있습니다. "문제 정의"라는 용어를 활용해 대화를 진행하면 이야기가 잘 정리되고 문제에 집중할 수 있습니다. 산으로 흘러가는 대화를 정상화할 수 있는 힘이 있습니다. 문제 정의는 아무리 강조해도 지나치지 않은 용어입니다.

브레인스토밍

문제가 정의되었다면, 다음은 이를 어떻게 풀어낼지 다각도로 검토해야 합니다. 이 과정에서 브레인스토밍의 역할은 단순합니다. 문제 해결을 위해 떠오르는 모든 아이디어를 모아보는 것입니다. 저는 개발자이지만 기술적인 해결책만 제시하는 것이 아니라 운영, 기획, 디자인, 인프라 등 다양한 관점에서 접근하는 것이 중요하다고 생각합니다.

너무 황당하거나 비현실적이지 않다면 잠정적인 해결책으로 간주하고 모든 아이디어를 기록해 둡니다. 생각나는 대로 적을 때 머릿속에 부정적인 필터가 작용하여 많은 아이디어가 걸러진다면, 그 아이디어의 재평가나 다른 아이디어와의 시너지 가능성을 원천적으로 차단하게 됩니다.

특히 이 과정은 개인적으로 수행하기에도 적합하지만, 팀원들과 함께 문제를 풀어나가는 것이 더 유익합니다. 아무리 뛰어난 사고력을 가진 사람이라도 한 사람의 아이디어에는 한계가 있으며, 편향될 가능성도 있습니다. 혼자 진행한다면 결과를 팀원들과 공유하고 피드백을 받는 것도 좋은 방법입니다.

브레인스토밍의 마지막 단계는 지금까지 나온 여러 문제 해결 방법 중 가능성이 낮은 아이디어를 제외하고, 가능성이 높은 아이디어를 보강하는 과정입니다. 이 단계에서 가능성이 없어 보이는 아이디어라도 다른 방법론과 결합해 시너지를 낼 수 있으며, 때로는 해결 방법을 찾기 어려운 난관에 부딪힐 수도 있습니다. 후술하겠지만, 이런 난관을 마주하면 "문제 정의" 단계로 돌아가는 것을 추천합니다. "이 문제는 해결할 수 없다"라고 성급히 결론짓기보다는 문제 정의가 잘못되었는지 의심해 보는 것이 좋은 의사결정 방법론입니다.

우선순위 부여

이제 브레인스토밍을 통해 다양한 문제 해결 방법이 제시되었습니다. 이 정도면 어떤 방법을 선택해 바로 실행해도 큰 문제는 없을 것입니다. 그러나 모두가 알고 있지만 명시적으로 언급하지 않는 개념이 있습니다. 바로 제한된 리소스로 최대의 이익을 얻는 효율입니다. 예를 들어, 1부터 100까지 더하라는 문제에 대해 단순히 하나씩 더할 수도 있지만, 꼬마 가우스의 방법을 사용하듯 효율적인 접근이 필요합니다. 따라서 우선순위는 매우 중요합니다.

우선순위를 정할 때 고려해야 할 두 가지 개념은 확률과 효율입니다. 브레인스토밍 단계에서 여러 방법을 나열했지만, 그 방법이 실제로 유효한지는 검증이 필요합니다. 예를 들어, 페이지 내 파편화된 대시보드 그래프가 데이터를 겹쳐 볼 수 없게 한다는 고객 문제를 해결하기 위해 5가지 지표를 특정 라이브러리를 활용해 하나의 2차원 그래프로 보여준다는 아이디어를 제시했다고 가정해 봅시다. 그러나 그 라이브러리가 그런 기능을 제공하지 않고, 커스터마이징도 엄격히 제한되어 인터페이스를 추가할 방법이 없다면, 이 방법은 현실적으로 성공할 확률이 낮습니다.

따라서 우선순위를 정할 때는 각 방법이 문제를 해결할 확률과 그로 인해 얻을 수 있는 효용을 고려해야 합니다. 확률은 그 방법이 성공할 가능성을 의미하며, 효용은 성공했을 때 얼마나 큰 가치를 제공하는지를 나타냅니다. 예를 들어, 어떤 방법은 성공 확률이 낮더라도 성공 시 큰 성과를 낼 수 있다면 도전해 볼 만한 가치가 있습니다. 반대로, 성공 확률이 높아도 효용이 미미하다면 우선순위에서 밀릴 가능성이 높습니다.

이 과정에서 중요한 것은 균형을 유지하는 것입니다. 너무 위험한 방법만 추구하면 실패 확률이 높아지고, 너무 안전한 방법만 선택하면 혁신적인 해결책을 놓칠 수 있습니다. 그러므로 팀의 리소스, 시간, 목표 등을 종합적으로 고려해 적절한 균형점을 찾아야 합니다. 예를 들어, 고객 문제를 해결하기 위해 2차원 그래프를 도입하는 대신 기존 그래프를 재정렬해 가독성을 높이는 방법은 성공 확률이 높고 효용도 어느 정도 보장된다면, 더 현실적인 우선순위로 선택될 수 있습니다. 이렇게 우선순위를 정하는 것은 단순히 아이디어를 나열하는 데서 끝나는 것이 아니라, 실행 가능성과 가치를 기준으로 실행의 첫걸음을 내딛는 과정입니다.

의사결정

의사결정은 우선순위가 매겨진 여러 방법 중 최종적으로 어떤 방법을 선택할지 결정하는 단계입니다. 이 과정은 단순히 확률과 효용만을 따지는 것이 아니라, 실행 가능성, 비용, 시간, 팀의 역량 등 현실적인 요소들을 종합적으로 판단해야 합니다.

예를 들어, 브레인스토밍에서 나온 방법 중 하나가 확률과 효용 면에서 뛰어나더라도, 이를 실행하려면 팀이 새로운 기술을 익힐 시간이 필요하거나 예산이 초과된다면 실현 가능성이 낮아질 수 있습니다. 반대로, 비용이 적게 들고 팀의 기존 역량으로 바로 실행할 수 있는 방법이라면 효용이 조금 낮더라도 더 현실적인 선택이 될 수 있습니다. 예를 들어, 대시보드 문제를 해결하기 위해 새로운 라이브러리를 도입하는 대신 기존 도구를 활용해 그래프 배치를 최적화하는 방법이 팀의 상황에 더 적합할 수 있습니다.

의사결정을 내릴 때는 스스로에게 다음과 같은 질문을 던져보는 것이 유용합니다:

• 이 방법이 성공할 확률은 얼마나 됩니까?
• 성공했을 때 얻을 수 있는 효용은 무엇입니까?
• 이 방법을 실행하는 데 필요한 리소스(시간, 비용, 인력 등)는 충분합니까?
• 팀의 역량과 경험으로 이 방법이 실현 가능합니까?
• 이 방법이 실패했을 때 감당할 수 있는 리스크는 무엇입니까?

이 질문들을 통해 각 방법의 장단점을 객관적으로 평가하고, 최종적으로 가장 적합한 방법을 선택해야 합니다. 예를 들어, 새로운 2차원 그래프 도입은 효용이 높지만 팀의 기술적 한계로 인해 실패 리스크가 크다면, 기존 그래프 개선 방안을 선택하는 것이 더 합리적일 수 있습니다. 의사결정은 직감에만 의존하지 않고, 고객 피드백, 데이터, 팀의 의견 등 구체적인 근거를 바탕으로 한 합리적인 판단이어야 합니다. 이렇게 선택된 방법은 다음 단계인 실행으로 이어지며, 문제 해결의 실질적인 시작점이 됩니다.

문제 재정의

이 방법론에서 가장 큰 위험은 문제 정의를 잘못하면 그 뒤의 모든 논의가 무의미해질 수 있다는 점입니다. 잘못된 문제 정의는 엉뚱한 지도를 들고 길을 찾는 것과 같습니다. 아무리 열심히 걸어도 목적지에 도달할 수 없습니다. 따라서 문제 해결 과정에서 "이상하다"거나 "답이 나오지 않는다"는 느낌이 들면, 즉시 문제 정의로 돌아가 재검토하는 것이 필수적입니다.

문제 재정의는 처음부터 다시 시작하는 것이 아니라, 브레인스토밍, 우선순위 부여, 의사결정 과정에서 얻은 정보와 경험을 바탕으로 문제를 더 정확하고 구체적으로 정의하는 작업입니다. 예를 들어, 대시보드 그래프 문제를 해결하려 했지만 브레인스토밍에서 나온 방법들이 모두 비현실적이거나 우선순위 부여 후에도 해결 가능성이 낮게 느껴진다면, 애초에 정의된 문제가 잘못되었을 가능성이 큽니다. 이때 "고객이 정말 원하는 것은 데이터 가시성인가, 아니면 다른 문제인가?"라는 질문을 던지고, 고객 피드백이나 데이터를 다시 확인하며 문제를 재정의할 수 있습니다. 예를 들어, 문제 정의가 "그래프가 겹쳐 데이터를 볼 수 없다"에서 "고객이 원하는 핵심 데이터를 한눈에 볼 수 없다"로 바뀐다면, 해결책의 방향도 달라질 것입니다.

문제 재정의가 특히 유용한 상황은 다음과 같습니다:

• 브레인스토밍에서 나온 방법들이 모두 실행 불가능하거나 비현실적일 때
• 우선순위를 정해도 어느 방법도 문제를 효과적으로 해결할 것 같지 않을 때
• 의사결정을 내리고 실행 중 예상치 못한 장애물이 나타날 때

문제 재정의를 통해 처음 놓쳤던 중요한 요소를 발견하거나, 문제를 더 구체적으로 좁혀 실행 가능한 수준으로 만들 수 있습니다. 예를 들어, "대시보드 그래프 문제"가 사실 "데이터 로딩 속도 문제"와 연결되어 있다면, 이를 재정의함으로써 전혀 다른 해결책(예: 서버 최적화)이 떠오를 수 있습니다. 이는 문제 해결의 효율성을 높이고 불필요한 리소스 낭비를 줄이는 데 큰 역할을 합니다.

마치며

생각 프레임워크는 단순하지만 강력한 힘을 지니고 있습니다. 저는 이 프레임워크를 사용하며 큰 도움을 받은 사람 중 하나입니다. 특히 "문제 정의"라는 개념을 이전에 다니던 조직에서 배우고 이를 발전시켜, 문제를 항상 이 틀 안에서 사고하고 해결해 왔습니다. 그 결과, 제가 문제 해결 과정에서 사용하는 문장들의 패턴이 손에 꼽을 정도로 단순해졌습니다.