개발 아키텍트 컨셉 : 도메인 주도 개발

Domain Driven-Design 개념잡기

'넌, 개발도 한 번 안 해 보고 무슨 설계냐'라고 딴지 걸 수도 있겠다. 그것보다 '넌, 코딩 말고는 신경 쓰고 싶지 않은 개발자이면서 뭔 설계냐'라고 반박을 당하면, 이것은 개발자로서 시작을 안 한 것만 못하다(자신의 경력과 잠재력이 엄청 제한된다, 손메즈)라고 말할 수 있다. 프로그램을 개발하는 데서 가장 중요한 것은 뭐라고 생각하는가?

개발 능력? 수학능력? 알고리즘 적용 능력? 다 중요하다. 하지만 본인이 개발하려는 시스템의 요구 사항을 잘 이해하지 못하면 개발하나 마나다. 코딩이나 개발 능력만 치면, 인도나 저임금 국가에 잘하는 인력이 넘쳐난다. 코드 작성 기술은 그러한 인력에 돈을 주고 살 수 있다. 전 세계 어디에 가도 코드를 작성할 줄 아는 사람은 저렴한 가격으로 구할 수 있다. 요즘은 소프트웨어 개발자의 가치를 코드 작성 능력으로만 평가하지 않는다. 회사나 고객의 요구 사항을 '기술적인 해결책'으로 풀어내는 역량이 있어야 능력을 인정받을 수 있다(손메즈, 2017).

즉 자신이 만드는 시스템의 요구 사항을 잘 이해해야만 좋은 개발자가 될 수 있다. 이 말은 고객이나 이해 당사자와 대화하고 해결할 도메인 지식을 갖추고 문제를 이해할 수 있어야 한다는 뜻이다(손메즈, 2017).

주기를 계속 반복하여 소프트웨어를 개발해야 하는 애자일(Agile, 민첩한) 환경에서는 이 점이 특히 중요하다. 매일 혹은 매주 고객이나 이해당사자와 대화하는 시간을 보낼 것이라 예상해야 한다. 이 점은 해당 분야(Domain)에 종사하는 고객이나 이해당사자 간의 의사소통이 원활히 이루어져야 한다는 말이다. 이것이 사실 개발자에게 가장 까다로운 소프트 스킬(코딩 같은 특정한 업무 능력을 칭하는 하드 스킬과 달리 모든 업무에서 보이지 않지만 업무가 진척되기 위해서 갖춰야 하는 소양) 중 하나이다.

필자가 잘 치는 호통 말고 소통을 잘하기 위해서는 그럼 무엇이 필요한가? 일단 전문가답게 보여야 한다. 그리고 실제로 전문가여야 한다고 생각한다. 전자에 대한 필자의 견해는 이전에 긁적였던 글(‘감정’)을 통해서 조금은 납득했으면 좋겠고, 후자는 일단 요구사항의 수준이 현 개발 시점에서 어느 정도인지도 모르고 요구사항만을 늘어놓은 명세서(Project spec)에 대해서는 듣고 피드백하고 또 듣고 피드백해야 하므로 필자의 이 글이 참조할 만도 할 것 같다.

소프트웨어 업계에서 '도메인 주도 설계'라는 방식이 화자 되곤 하는데, 이것을 이해하는 정도는 직군마다 천차만별이기 때문에 핵심에 대해서는 다음 섹션부터 개관하겠다.

참조

1) 존 손메즈(2017), Career Skill : 완벽한 개발자 인생 로드맵, 한국판 역자 이미령(2019). 서울 : 도서출판 길벗(주).