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

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

이런 케이스는 어떻게 처리해야 하나요? 정리된 게 없다고요? 기획서가 철저하지 않으면 개발 못해요.

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

이 글을 보고 있는 당신은 어떤 생각이 드는가? 기획자(혹은 PM, PO)에게 전적으로 잘못이 있다고 생각이 드는가?

흔히 요구 사항 기술서(PRD; Product Requirements Document)에는 꼭 해야 하는 것(Must have), 하면 좋은 것(Should have)이 기술될 수 있다. 그리고 사람의 멘털 모델이 그러하듯 아직 덜 정제된 경우라면 추상화 수준이 제각각이라 각 요구사항 별로 더 혹은 덜 치밀하게 기술되기도 한다.

요구 사항 기술서가 치밀하게 작성되어 있지 않다면 정말 개발에 착수할 수 없을까?

그렇지 않다. 꼭 구현해야 할 기능들이 최소한으로 기술되어 있고, 대략의 비즈니스 논리가 정리되어 있다면 개발에 착수할 수 있다고 본다.

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

이렇게 반문하는 개발자가 있을지도 모르겠다. 애초에 변화가 있을 것을 전제하고 고려해야 한다. 물론 구조나 큰 틀을 흔드는 변화를 얘기하는 것이 아니다. 구조나 큰 틀에 채워진 세부사항은 언제든지 바뀔 수 있음을 고려해야 한다는 것이다. 구조나 큰 틀을 흔들겠다면, 이건 팀 차원에서 다시 원점에서부터 생각해 보는 게 나을지도 모른다.

물론 구조나 큰 틀 또한 유연하게 만들 수 있다. 우리가 만드는 소프트웨어는 대개 외부로부터 입력을 받고, 그 입력을 비즈니스 논리를 담당하는 영역(Domain)에서 해석할 수 있게 변환 및 전달시켜 처리한 후, 때로는 처리된 내역을 저장소(Storage)에 영속(Pesistent)시킨다. 이때 각 영역을 느슨하게 연결시키는 아키텍처가 바람직하다고 이야기되는 이유도, 어느 한 영역의 변경이 최대한 그 영역에 국한되면 변경의 파급을 줄어듬으로써 변화에 유연하게 대처할 수 있기 때문이다. 반대급부적으로 각 영역이 강하게 연결된 아키텍처는 한 영역이 변경되면 전체 구조가 흔들리게 된다.

소프트웨어 개발에서는 이를 다소 추상적인 용어이지만 높은 응집도(High cohesion)와 느슨한 연결(Loosed coupling)이라고 부르기도 한다.

너무나 당연한 소리를 하고 있다고 생각하는가? 그렇다. 애초에 소프트웨어 개발의 기본 미덕은 이렇듯 변경과 변화에 열려 있었다. 왜냐하면 한번 만들어진 소프트웨어는 그 생애주기를 다할 때(시장에서 더 이상 가치를 인정받지 못해 쇠락할 때)까지 계속 변화하기 때문이다.

좋은 아키텍처는 중요한 결정을 최대한 미룰 수 있는 아키텍처라는 말이 있다. 중요한 결정을 미룬다는 의미인즉슨, 변화에 적극적으로 대응할 수 있다는 의미일 것이다.

왜 좋은 구조와 아키텍처에 관심을 갖고 공부하는가? 그것을 왜 적용하려 하는가? 본질은 변화를 적극 수용하고자 하는 마인드셋에 있음을 상기해 보면 좋겠다.