문제를 해결하는 방법

문제를 해결하는 방법에 대해 생각해 봤습니다. 먼저 문제가 무엇인지 정확한 진단이 필요할 것입니다. 그리고 그 문제에 대한 대증요법이 아닌 정확한 해결책이 필요할 것입니다.

여러 조직들을 경험해 보면, 문제에 대한 정확한 진단을 하지 못하는 조직은 대부분 역량이 부족한 상태였습니다. 문제 자체를 이해하지 못하기 때문에 그것이 어떤 문제인지 알 수가 없는 상태인거죠. 그런 상태에서 나오는 답이 문제를 해결할 수 있을리 없습니다.

역량을 충분히 갖춰 문제를 잘 진단하는 조직 중에서 이해가 잘 안됐던 부분 중 하나는 문제를 정확하게 해결하는 것이 아니라 일종의 대증요법(?)을 사용하는 것이었습니다.

예를 들면 하드웨어에 예상하지 못했던 exceptional case가 있어서 어렵고 critical한 불량이 발생하고 있는데 뜬금없이 다른 소프트웨어 모듈의 테스트 커버리지를 높이는 그런 것이죠. 전체 불량률을 감소시키는데 의미가 있을 지언정, 정작 문제의 핵심이 되는 부분의 해결에는 전혀 도움이 안되는 방법을 도입하게 되면서 여기에 많은 리소스가 투입되고 문제의 해결은 더 어려워 집니다.

왜 이런 대증요법들이 채택되어 문제의 핵심을 감추고 문제 해결을 더 어렵게 만드는지 관찰을 해봤습니다. 그리고 제가 생각했던 결론은 이랬습니다. 그 문제에 대해 진정한 해결이 목적이 아니라, 이 문제를 통해 내 조직 또는 개인이 취할 수 있는 이득이 어떤 것이냐를 두고 그것을 최대화할 수 있는 방향으로, 그리고 반대로 risk는 최소화하는 방향으로 조직과 사람들이 움직이기 때문이라고 생각했습니다.

합리적인가요? 심각한 문제는 제대로 해결이 되지 않고 있는데 내 조직 또는 개인의 이득만 최대가 되면 합리적인 의사 결정이었던 걸까요? 🤷🏻‍♂️

전 결국 이 “합리적인 의사결정”은 조직 및 개인의 이기주의, 그리고 본질적으로 문제 정의 및 진단을 할 수 있는 역량의 부족에서 온다고 생각합니다. 🥸

이런 문제 해결의 형태는 기술적인 것 뿐 아니라 조직관리 측면 등 여러 부분에서 광범위하게 관찰되었습니다. 잠시 동안은 대증요법에 의해 뭔가 진척되는 것처럼 보이기도 하고, 긍정적인 사람들의 “뭔가 하고 있으니까 잘 될꺼야”라는 메세지 때문에 문제가 해결 된 것처럼 보일 수 있지만, 그 문제가 어떤 것이든 대부분 비슷한 양상이었습니다.

시간이 얼마 걸리느냐의 차이만 있을 뿐, 문제가 정확히 파악되고 해결되지 않으면 그것은 반드시 다시 수면위로 올라옵니다.

…

라고 새벽에 잠이 깨어 초기에 생각치 못한 부분에서 발생한 버그를 고치면서… 😂

요즘은 개발중인 인퍼런스 엔진에 chunked prefill 기능을 넣고 있거든요 😄

끝.