제목이 분할정복 알고리즘인데 사실 알고리즘에 대한 이야기를 하려는 것은 아니다. 개발자를 하면서 여러가지 알고리즘들이 있지만 실생활에 그리고 일을하는데 있어서 그리고 개인 생활에서 생기는 여러가지 문제를 해결하는데 가장 많이 도움이 되는 것은 분할 정복에 대한 개념이었다.

실제로 알고리즘 자체가 어떻게 돌아가는지는 그렇게 중요하지 않고, 작게 나누고 그걸 해결한다는 개념 자체를 아는게 중요하다. 생각보다 우리가 접하는 하나의 문제라는건 대부분 여러가지 복합적인 문제와 그로 인한 현상들로 이루어진 경우들이 많다. 이런 경우 문제의 해결을 위해서 나는 분할정복 전략을 도입하곤 한다.

예를 들면,

인식된 문제 : 인테리어 진행이 마음에 들지 않는다.

• 현상 : 인테리어 진행이 마음에 들지 않아서 기분이 좋지 않다.
• 실제 문제 :
  • 마감미팅에 대한 공유가 되지 않았다.
  • 생각했던 주방내 특정 서랍장이 마음에 들지 않는다.
• 액션:
  • 마감미팅 공유 요청
  • 특정 서랍장 변경 요청

이런 문제에서 보면 결국 인테리어의 문제로 내가 불편함 감정을 느끼지만 그것을 해결하는데 현상과 문제를 분리해서 보면 결국 해야하는 액션(action)이 명확해지고 그것을 행함으로써 빠르게 현상이 해결이 된다.

인식된 문제 : 타 업체와 일이 잘 안되서 짜증이 난다.

• 현상 : 일이 진행이 안되는것 같아서 답답하다.
• 실제 문제 :
  • API가 문서와 맞지 않는다.
  • 요청을 하면 너무 늦게 답이 온다.
• 액션
  • 최대한 빨리 응답을 달라고 요청한다.

문제마다 다르겠지만 어떤 문제들은 내가 해결할 수 없는 영역들에 있는 문제들이 있다. 예를 들어 위의 API 문서와 실제 스펙이 맞지 않는 문제는 타 업체의 문제고 내가 해결할 수 없는 영역에 있기 때문에 그 문제를 해결하기 위해서 에너지를 쓰지 않는다. 이렇게 문제들을 분리하다 보면 집중해야하는 문제의 포인트에 대해서 좀 더 잘 알수가 있다.

개발자라서 그런지 모든 문제를 이런식으로 해결하게 되는것 같다. 작게 나누고 그것이 다른 문제와의 dependency는 없는지 파악하고 없다면 해결하고 있다면 다시 파악하고 이런식으로 진행하게 된다.

그러나 분할정복 전략은 문제 해결전략이지 문제에 대한 공감을 도와주진 않는다. 실생활 도입시 어떤 문제를 빨리 해결해야할때 도움이 되지만, 문제에 대한 공감이 필요할때 사용하면 역효과. 공감은 완전 다른 문제라고 생각한다.

상대방의 마음을 달래줘야할때는 그냥 들어주고 공감해줘야 한다.