개발자와 비개발자의 오작교, 다이어그램

🏗️ 설계 없는 프로젝트는 도면 없는 건축과 같다

소프트웨어 개발 프로젝트 초반에 수많은 개발자들이 겪는 공통된 어려움이 있다. 바로 '설계'다.
설계 없이 프로젝트를 시작하는 것은 도면 없이 건물을 짓는 것과 다르지 않다. 특히 개발에서는 프로젝트가 시작되면 요구사항 변경이나 누락에 유연하게 대응하기가 매우 어렵다.

실제로 사내에서도 UML을 그리는 사람은 CTO를 제외하고 단 한명도 없다. 그럼 이때까지 그려볼 생각을 하지 않았나? 맞다. 그려볼 생각이 없었다.
왜냐면 나의 영역이 아니라고 생각했기 때문이다. "나는 건설현장의 인부1인데 왜 내가 도면을 봐야하지? 나는 JSON이라는 벽돌을 나르기만 하면되는데?" 라고 생각했기 때문이다. 하지만 내생각은 틀렸다. 인부1도 설계도를 볼 줄 알고 고칠줄 알아야한다. 왜냐고? 내가 벽돌을 4층에 가져다 둬야하는데 설계도도 안보고 12층에 가져다 두면 욕을 먹을수 밖에 없기때문이다. 그럼에도 우리는 왜 설계를 하지 않는가?

우리가 설계를 안 하는 핑계들

• "어차피 요구사항 바뀔 건데 뭐하러 그려?"
• "지금까지 고생해서 만든 설계가 무너질까 봐"

설계가 필요한 진짜 이유: 소통

내가 직접 설계를 해보면서 느낀 가장 큰 이유는 ‘팀원과의 소통’이었다.

나는 소통을 좋아하는 사람이다.
팀원뿐 아니라 옆 부서 팀장님과도 친해지고 싶다. 그러려면 서로의 일을 매끄럽게 이해하고, 공통된 언어로 설명할 수 있어야 한다.

그래서 ‘설계 문서’는 기능 구현을 설명하고,
팀과 팀 사이의 커뮤니케이션 오류를 미리 막는 유일한 소통의 도구가 된다.

서로 오해 없이 협업이 잘 되면, 회사 다닐 맛도 나지 않을까?

그렇다면 설계도를 잘보고 잘이해하려면 어떻게 해야하나?
답은 내가 그려보는 것이다. 그 어떤 유우우우명한 개발자도 '설계'를 빼먹는 사람은 없다. 실무에서 설계는 바뀌는 게 당연하다. 문제는 바뀌는 게 아니라, 바뀔 때마다 공유되지 않는 것이다. UML이나 다이어그램은 완벽하지 않아도 좋다. 현재의 방향성과 개념을 공유하고, 팀의 공통 이해를 맞추는 용도로만 써도 충분히 가치가 있다.

🎈 유비쿼터스 언어

팀과 팀, 개발자와 기획자 간의 오해를 사전에 막기 위한 공통 언어다.

예를 들어,

기획자: “주문이 취소되면 환불해줘야 해요”

개발자: “cancelOrder 안에 reversePoints() 넣을게요”

...벌써 어지럽다.

서로 다른 언어를 쓰면 결국 서로 다른 걸 상상하며 대화하게 된다.

이때 reversePoints() 대신 refund()와 같은 비즈니스 용어를 코드에 녹여낸다면?
도메인 전문가도 충분히 이해할 수 있는 코드가 된다.

우리는 컴퓨터만 상대하는 개발자가 아니다.
사람과 함께 일하는 개발자다. 사람과의 대화가 서로 다른 언어로 이뤄진다면, 개발을 했더라도, 유지보수와 추후 협업도 어려워 질 것이다. 이점을 잊지 않고 잘 실천해간다면 회사생활은 어렵지 않을 것이다.

📊 다이어그램

다이어그램에 대해 제대로 생각해본 것은 거의 첨음이아닐까 생각한다. 내가 느낀 다이어그램의 최고의 장점은 내가 구성해둔 코드를 내가 공백일때 다른 개발자가 다이어그램만 보고도 코드의 흐름을 얼추 이해할 수 있다는 것이다. 사실 남이 짜놓은 코드를 이해하는 것은 쉽지 않다.

실제로 내가 회사에서 작업을 할 때도 CTO가 짜주신 코드를 분석하며 간단한 기능을 추가하는 것이 꽤나 오랜시간이 걸린다는 것이다. (내가 못해서 일수도) 이처럼 이러한 문제를 조금이나마 해결하고자 다이어그램이 필요하다는 것을 인지하고 이제는 써먹어야 할 때가 아닐까?

처음으로 제대로된 시퀀스 다이어그램를 작성했다. 그런데 돌아온 피드백은 이것이었다. "이 형태는 레이어드 아키텍처 잖아요? 레이어드 아키텍처를 기획자가 다이어그램을 보고 이해할 수 있을까요?" 머리가 멍했다. 그렇다 사실 모를것이다. 심지어 기획자가 레이어드 아키텍처를 알 이유도 없다. 그럼 어떻게 해야할까? 답은 간단하다. 지금 이 다이어그램을 그리면서 이것을 누구에게 보여줄지를 생각하면된다. 개발자인가? 비개발자인가? 를 생각하면 충분히 그에 맞는 다이어그램을 작성 할 수 있을것이다.

🫠 마치며

사실 1주차 테스트코드를 짜는 시간보다 다이어그램 하나 그리는 시간이 더 오래 걸렸다. 어떤 구조로 표현할지, 어떤 흐름이 더 이해하기 쉬울지, 계속 고민하게 됐다. 어떻게해야 팀원과 소통에서 최고의 다이어그램을 최고의 설계를 할수있을까 생각해보는 시간이었다. 하지만 그 과정 자체가 바로 ‘소통’을 위한 고민이었다고 생각한다.

유비쿼터스 언어를 통해 팀 전체가 같은 그림을 그릴 수 있다.
다이어그램은 혼자만 이해하는 코드에서 팀이 이해하는 구조로 나아가는 시작점이다.

끝.