유연성이 SW개발에 왜?

많은 사건이 있었던 하루였습니다. 상상도 하지 못했던(?) 일이 벌어진 날, 회사에서는 조직 개편이 있었습니다. 제가 속한 조직도 변동이 있어서 뒤숭숭합니다만 속히 안정돼서 기술적인 이야기들도 (보안 위험이 없는 한에서...) 풀어보고 싶습니다.

오늘은 "유연성"에 대한 이야기를 공유해보려고 합니다. 제가 하는 이야기들은 제가 겪었던 몇몇 회사 및 조직에 대한 이야기라서 꼭 지금 제가 몸담고 있는 회사에 대한 이야기만은 아닙니다.

개발 프로젝트를 진행하다 보면, 항상 (유연성이 요구되는) 잡음이 발생하는 문제들을 겪습니다. 보통 이런 문제들입니다.
"개발 언어는 무엇으로 할 것인가?"
"어떤 아키텍처로 할 것인가?"
"우리의 workflow는 어떻게 할 것인가?"

사실 이런 문제는 유연성과 큰 관련이 없어야 하는 질문들 같습니다. 명확한 답이 있어야 할 것만 같거든요. 이 문제를 해결하기 위한 최적의 시스템 아키텍처가 무엇인가? 우리 팀의 최고 효율을 낼 수 있는 workflow가 무엇인가? 우리 시스템에서 가장 빠른 속도를 낼 수 있는 개발 언어로 어떤 것을 선택할 것인가? 등등이요. 정답이 있을 것 같아서 그걸 찾아내고 싶지 않나요? 그래서 각 candidate의 비교를 통해 장단점을 파악하고, 점수화하여 합리적으로 선택을 할 수 있을 것만 같은 질문들입니다.

그런데, 문제는 이러한 비교가 항상 합리적으로만 되지는 않는다는 것이죠. 그리고 잡음이 발생합니다. 왜 단순하게 장단점 비교를 통해 쉽게 해결되어야만 할 것 같은 문제들이 그렇게 되지 않나를 관찰해 봤는데 그 이유는 아주 단순했습니다.

먼저 성향과 성향의 충돌입니다. 아키텍처 같은 경우 "최적"이라고 생각되는 그런 근사한 것이 있을 것만 같습니다만 알고 보면, 아키텍처라는 것은 trade-off로 똘똘 뭉친 덩어리입니다. 거기에 아키텍트의 성향이 알게 모르게 굉장히 많이 녹아들어 가기 때문에, 합리적으로 비교한다는 것이 굉장히 어렵습니다. 마치 짜장과 짬뽕의 대결이라고 할까요? 거기에 이 문제의 난이도가 더 높아질 때가 있는데, 그 문제를 정확히 이해/분석할 수 없는 사람들이 아키텍처를 만들면 그야말로 막말대잔치가 되는 것입니다.

성향과 성향이 충돌하면서, "반드시" 이 문제는 이렇게 풀어야만 한다라는 의견들이 대립합니다. 제삼자의 입장에서 관찰하면 굉장히 웃기기도 하고 재밌습니다. "우리의 바다"라는 다큐멘터리에 나오는 폴리네시아 깊은 바다에 사는 거대한 수컷 혹돔들이 힘을 과시하기 위해서 서로 박치기를 해대는 모습 같거든요. 하지만 내가 그 충돌 당사자일 때는 세상에 그렇게 분통 터지고 심각한 문제가 없죠.  "이걸 왜 이해를 못 해!!"

이러한 문제들이 결국 합리/논리를 가장한 성향의 대립이다라는 것을 깨닫지 못했을 때에는 어떻게든 이 논리를 이해시키기 위해서(이기기 위해서) 각종 이론들과 자료들을 찾아보고, 실험하고 논쟁하고.. 그래서 많은 시간을 쏟고 스트레스받고 그랬던 것 같습니다.

그런데 어느 순간 깨달았습니다. 어떤 문제를 정확하게, 100% 분석해 내는 사람은 없고, 문제 자체를 정확히 분석하는 것뿐 아니라, 프로젝트가 진행되면서 인력 증감을 정확하게 예측해 내거나, 시장의 변동을 귀신처럼 맞히거나 하는 사람은 없다는 것이죠. 결국 그렇게 박치기 쿵쿵 해대면서 도출해 낸 결론은 예측 못했던 어떤 부분들 때문에 어느 시점에서는 "수정"되어야만 한다는 것입니다. 그렇게 박 터지게 논의할 시간에 프로토타입을 만들어 보는 게 천 배는 나았던 거죠.

수정이 필요한 것을 알아차린 시점이 빠를수록, 수정 부분이 적을수록, 당연하게도 수정에 필요한 노력이 적었습니다. 수정하지 못할 경우, 경쟁사 대비 열세가 되거나, 시장에서 환영받지 못하기 때문에 그런 선택지는 없었습니다.

결국 코드 자체가 변경에 굉장히 유연해야 하고, 아키텍처의 장단점을 매우 빠른 단계에서 확인해 볼 수 있는 것이 필요한데, Agile software development에서 말하는 그런 것들이 실제로 굉장히 유용했습니다. 기존에 우리가 해왔던 한 번에 완벽한 설계를 해내고, 단계별로, 모듈별로 나눠서 개발을 해 나가는 것은 굉장히 유연성이 떨어져서, 변경이 필요한 시점을 너무 뒤늦게 알아차리게 되며, 초기 설계 단계에서 굉장히 많은 시간을 쓰고, 개발 비용이 엄청나게 많이 들어가는 선택이라는 생각이 들었습니다.

그렇다면 모듈화를 잘하고 유지보수성을 극대화하는 아키텍처를 가져가면 되나? 는 아닙니다. 그것은 결과로 나타나는 것이지 그것 자체가 지향점이면 안됩니다. 정말로 가장 중요한 부분은 조직의 문화가 그러한 유연성을 가져갈 수 있는 분위기여야만 하고, 개발자들의 마인드 역시 그러한 유연성을 가져야 합니다. 사고 자체가 경직되어 있고 단방향 해결책만 고려하는 사람이 어떻게 유연한 설계를 할 수 있을까요. 실패하는 것에 대한 책임만을 강조하는 조직에서 어떻게 빠르고 작은 실패들을 해가면서 유연하고 점차 탄탄해지는 제품을 만들어 나갈 수 있을까요. 우리가 만들어 낸 답이 정답이 아니면 빨리 수정하면 되죠. 이미 답이 아닌 것을 알았는데 한탄만 하고 있으면 문제가 저절로 해결되나요. 조직문화, 사람, 그리고 그것들을 할 수 있는 인프라, 이 3가지가 모두 필요합니다.

마지막으로, 이 문제가 정말 어려워지는 시점은 단순히 코드와 연관될 때가 아니라, 사업과 관련될 때입니다. 이 제품이 시장에서 환영받을 것인가? 환영받기 위해서 필요한 기능들이 무엇인가? 그러한 질문들에 대한 대답에 의해서 조직의 방향이 전환되고 그 방향으로 가기 위해 많은 리소스가 들어가기 때문입니다. 개발과 달리 아직 사업에 대해서는 어떠한 것이 효과적인지 알아내지는 못했습니다. 굉장히 많이 고민해 봤는데 답을 내기 쉽지 않더라고요. 엔지니어들은 대부분 이 문제에 대한 답을 이렇게 합니다.
"좋은 기술로 좋은 제품을 만들면 시장이/고객이 알아주지 않을까?"

전 아닌 것 같거든요.

끝.