변화에 열려있는 개발자가 되자

개발자가 변화에 열려 있을수록 좋은 아키텍처가 만들어집니다.

이런 케이스는 어떻게 처리해야 하나요? 아직 미정이라고요? 기획이 철저하지 않으면 개발 착수 못해요.

혹시 주변에서 개발자가 이렇게 얘기하는 것을 들어본 적이 있으세요? 저는 기획서 혹은 요구 사항 기술서가 치밀하지 않아서 아직 개발할 수 없다고 얘기하는 개발자를 몇 번인가 본 적이 있습니다.

요구 사항 기술서를 보면 제품이나 기능의 실체가 보이기 전까지 어떤 것은 자세하게 정리되어 있는 반면, 어떤 것은 덜 치밀하게 정리되어 있는 것은 꽤 흔한 일입니다. 실체가 보일 수록 점점 상세 내용이 더 구체화되는 것이죠. 너무나 자연스러운 현상입니다.

다시 위의 사례로 돌아가서 여러분께 질문 드려 봅니다. 요구 사항 기술서가 치밀하게 작성되어 있지 않다면 정말 개발에 착수할 수 없을까요?

저는 그렇지 않다고 생각합니다. 꼭 구현해야 할 기능들이 최소한으로 기술되어 있고, 대략의 비즈니스 논리가 정리되어 있다면 개발에 착수할 수 있다고 보는 것이죠. 아마도 누군가는 이렇게 물어보실 겁니다.

그럼 나중에 요구사항이 추가되거나 비즈니스 논리가 바뀌면 어떻게 하려고요?

애석하게도 소프트웨어는 애초에 변화를 전제하고 고려해야 합니다. 더 이상 변화가 없는 소프트웨어는 이미 그 생애주기를 다 한 상태일 겁니다. 게다가 한 번 생각해 보세요. 처음 생각한 해결책이 최선의 해결책일까요? 물론 그럴수도 있습니다. 하지만 처음부터 최선의 선택을 하려고 힘을 팍 주는 것 보다, 지금 딱 필요한 만큼의 선택을 하는 게 더 경제적인 접근이지 않을까요? 물론 매번 구조나 큰 틀을 흔드는 변화를 다 수용하자는 얘기는 아닙니다. 구조나 큰 틀에 채워진 세부 사항은 언제든지 바뀔 수 있음을 고려해야 한다는 것이죠. 구조나 큰 틀을 흔들어야 한다면 팀 차원에서 원점에서부터 생각해 보는 게 좋습니다. 꼭 구조를 흔들어야만 하는 것이 맞는지, 터무니 없는 것을 하려는 것은 아닌지 말이죠.

물론 구조나 큰 틀 또한 유연하게 만들 수 있습니다. 우리가 만드는 소프트웨어는 대개 외부로부터 입력을 받고, 그 입력을 변환하여 비즈니스 논리를 담당하는 영역(Domain)에서 처리하고 외부에 다시 응답합니다. 때로는 처리된 내역을 저장소(Storage)에 영속(Pesistent)시키기도 하고요. 이 때 각 영역을 적절히 구분하고 느슨하게 연결시키면, 어느 한 영역의 변경이 최대한 그 영역에 국한되기 때문에 다른 영역에 파급되는 것을 줄일 수 있습니다. 즉, 변화를 훨씬 수용하기 좋아지는 구조가 잡히는 것이죠. 반대로 각 영역이 강하게 연결되면 한 영역의 변경이 전체 구조에 영향을 미칩니다. 굳이 현실 세계에 비유해 보자면 방문 하나 교체하려다가 방문이 기둥에서 도저히 떨어지지 않아 기둥 째로 교체하게 되는 웃지 못할 일이 일어나는 것과 비슷합니다.

컴퓨터 공학에서는 이를 한마디로 이렇게 표현하기도 합니다. 무려 1974년에 처음 등장한 표현입니다.

높은 응집도(High cohesion)와 느슨한 연결(Loosed coupling)

혹시 너무 당연한 소리를 하고 있다고 생각하시나요? 네, 맞습니다. 애초에 소프트웨어 개발의 기본 미덕은 이렇듯 변경과 변화에 열려 있습니다. 다시 한번 강조해 말씀드리지만, 한 번 만들어진 소프트웨어는 그 생애주기를 다할 때(혹은 시장에서 더 이상 가치를 인정받지 못해 쇠락할 때)까지 계속 변화하는 게 숙명이거든요. 제가 좋아하는 표현이기도 합니다만, 좋은 아키텍처는 중요한 결정을 최대한 미룰 수 있는 아키텍처라는 말이 있습니다. 중요한 결정을 미룬다는 의미인즉슨, 변화를 점진적이지만 적극적으로 수용하고 발전시켜 나간다는 의미입니다.

왜 좋은 구조와 아키텍처를 고민 하시나요? 그 본질은 변화를 적극 수용하고자 하는 태도에 있음을 상기해 보시면 좋겠습니다.