개발자는 어떻게 서비스를 이해하는가? (feat. 인터페이스와 모델링을 통한 의도 드러내기)

안녕하세요. yeTi입니다.
오늘은 안영회 대표님이 쓰신 인터페이스는 왜 모델링의 핵심 개념인가? 를 읽고 요즘에 뜻을 가지고 실험하던 부분들과 연결하여 글로 드러내고자 합니다.

개발자 Agent 는 시간문제이다.

제가 확신을 가지고 믿고 있는 것이 있습니다. 개발자를 대체하는 Agent 의 시대는 곧 온다는 것입니다.

더불어 저도 별 것 아니지만 개발자 Agent 를 위한 작은 부분들을 실험해 나가고 있습니다. gitlab-observer

개발자 Agent 를 만들고 싶다는 뜻을 품고 고민을 해나가자 이런 생각들이 스쳤습니다.

• 개발자는 서비스의 현황을 어떻게 알지?
• 개발자는 어느 부분을 어떻게 고치며 나아갈지 어떻게 알지?
• 개발자는 트러블 슈팅의 지점을 어떻게 알지?
• ...

개발자가 인식할 수 있는 것을 글로 풀어낼 수 있다면 그것은 곧 구현가능하다는 믿음이 생기기 시작했습니다.

개발자는 무슨 것인지 어떤 것인지 어떻게 아는가?

이직이후 3년이라는 기간동안 팀이 쌓아올린 것들을 분석하고 이해하느라 정신없는 나날을 보내면서 개발자가 구현체들을 이해하는 과정을 들여다보는 계기로 삼을 수 있었습니다.

마치 새로운 도시에 이사온 사람처럼, 개발자도 새로운 코드베이스를 처음 마주할 때 비슷한 과정을 거칩니다. 처음에는 큰 그림을 보고, 점차 세부적인 것들을 이해해가죠.

스스로를 개발자로서 우리가 다루고 있는 서비스들을 어떤 방식으로 이해하고 소화해가는지 설명하기가 힘들다는 것을 알게 되었습니다. 이를 알아차리고 지속적으로 다음과 같은 질문을 던지며 하나하나 답을 찾아가기 시작했습니다.

개발자인 나는 각각의 서비스들이 무슨 것인지 어떤 것인지 어떻게 알지?

이슈 상태에서 어디에서 어떤 이유 때문에 이슈가 생긴 것인지 어떻게 알지?

기능 변경의 영향도가 어느 수준을 가지는지 어떻게 알지?

그 과정에 대한 기록을 남기지는 못하여 개념이 자연스럽게 이어지지는 않지만, 스스로 답을 찾아 개념화한 것은 온톨로지를 기반으로 시간의 축으로 토폴로지를 아는 과정이 개발자가 서비스를 이해하는 과정과 유사하다는 생각을 가지고 있습니다.

이것은 무슨 것인가?

개발자가 처음 접하는 서비스를 볼 때 가장 먼저 무엇을 할까요? 저는 이렇습니다.

• README.md 를 읽는다.
• API 명세서를 읽는다.
• 서비스가 다루는 데이터 모델을 본다.

위의 세가지를 함으로써 얻고자 하는 것은 무엇일까요?

• README.md 를 읽는다. : 개발자가 드러내고자 하는 서비스의 의도를 파악한다.
• API 명세서를 읽는다. : 서비스가 상호작용을 통해서 드러내는 역할을 인식한다.
• 서비스가 다루는 데이터 모델을 본다. : 서비스가 다루는 개념을 이해하고 상태를 인식한다.

위의 세가지를 확인함으로써 저는 개발자가 드러내고자 하는 서비스의 의도를 파악하고 해당 서비스가 외부와 소통하기 위해 가지는 역할을 이해하며, 보다 자세하게 서비스가 다루는 개념을 이해하고 다루는 상태를 인식할 수 있게 됩니다.

물론 복잡도에 따라 이해하는 수준에는 차이가 있지만 서비스를 이해하는 큰 방향성에서는 벗어나지는 않습니다.

인터페이스를 다루다

이러한 맥락을 가지고 살아가고 있을 때, 안영회 대표님의 글은 깊은 공감을 만들어냅니다.

구성 요소가 무엇인지가 아니라 구성 요소가 무슨 일을 하는지가 우리가 보는 사물의 특성을 설명해준다. - 모델링과 인터페이스의 상관관계

맞습니다. 구성 요소가 무슨 일을 하는지가 우리가 보는 사물의 특성을 설명해줍니다.

인터페이스는 특정 맥락의 역할이 지닌 책임의 계약을 나타낸다.

이 말은 조금 어렵게 다가옵니다. 대표님의 글에서는 구조적 관점으로 풀어주셨습니다.

제 스스로 쉽게 풀어보면 특정 맥락을 이해할 수 있는 바탕은 도메인(관심 영역)과 이를 구체화하는 사용자 시나리오로 보입니다. 왜냐하면 우리가 다루는 도메인의 맥락에서 상호작용을 보거나 사용자 시나리오 상에서 상호작용의 역할로 인터페이스를 볼 수 있기 때문입니다.

더하여 역할이 지닌 책임의 계약에서 계약이라는 용어가 어렵게 다가옵니다. 숙제로 남겨둬야 겠습니다.

결론

이전에 설계란? I Driven Design with Arrangement 에서 목표가 정렬된 상태에서 나의 의도나 우리의 의도를 드러내어 문제를 인식하고 풀어가자는 말을 했습니다.

이번 글에서는 계속해서 구현 수준에서 의도를 어떻게 드러낼 것인가에 대해 맛보기를 했다는 느낌을 받습니다.

우리가 정의한 사고체계를 풀어내가 위해서는 무슨 것들이 필요한데, 무슨 것들에 뜻을 담아 의도를 드러내는 과정이 모델링이고 모델링을 한 결과로 어떤 것인지를 드러내야 하는데 이를 나타내는 것이 인터페이스이고, 상호작용 관점이 아닌 상태 관점에서 어떤 것인지를 드러내는 것이 데이터 모델링이라는 생각이 들었습니다.

추상화를 하자는 말이지요.

이번 글에서는 풀어내지 않았지만 이 관점도 있습니다. 프로젝트의 레포지토리(git, github, ...) 가 주어졌을 때 우리는 어떻게 의도를 파악해 가는가..

지속적으로 배워가고 있는 한국말로 표현하자면 각각의 아름들의 바탕은 무엇이고 구실과 노릇은 무엇이며 벌어진 사태에서 사건을 마주했을 때 어떤 관점을 가지기를 바라는지 말을 할 수 있어야 합니다.

그런데 이것이 정말 어렵습니다.

관련 글

• 설계란? I Driven Design with Arrangement

참고 자료

• 인터페이스는 왜 모델링의 핵심 개념인가?
• 모델링과 인터페이스의 상관관계