모델링을 통해 구조에 결정적 영향을 주는 요소 찾기
어떻게 하면 모델링을 잘할 수 있을까?
지난 글을 쓴 후에 이번에는 본격적으로 작동 방식Mechanism을 객체의 Collaboration으로 표현하는 예시를 만들 목적으로 cursor에 다음과 같이 명령(채팅)을 내렸습니다.
react 프로그램에서 화면에 나타난 버튼이 go 프로그램과 연동하는 전형적 코드를 만들어 주세요.
그렇게 만들어진 코드가 react 기반 애플리케이션의 Collaboration 모델링 예시로 쓰기에 좋겠다는 생각이 들어 쓰는 글입니다.
코드 분석에 쓰이는 Collaboration 모델링
자신의 작성하지 않은 코드를 파악해야 하는 일이 있습니다. 개발자라면 자주 발생하는 일이죠.[1] 종종 다른 사람이 작성한 코드를 파악하는 일을 '분석'이라고 부르기도 합니다. 이렇게 분석을 할 때도 한 번에 코드를 모두 파악할 수는 없기 때문에 앞서 <모델을 그리기 전에 '생각의 종이'부터 준비하세요>에서 설명한 대로 이번에 분석할 범위나 덩어리를 정하는 일이 효과적입니다. 그러면서 복잡도가 높거나 분량이 많다면 단계적으로 파악해 갈 수 있습니다.
앞서 제가 cursor에 내린 명령이 일종의 분석 범위로 볼 수도 있습니다. 제가 작성하지 않은 코드를 보고 그 결과가 적절하다 판단한 근거는 두 곳에서 찾을 수 있습니다. 첫 번째는 실행 결과에 애초에 예상한 범위와 비슷하다는 사실입니다. 딱 필요한 요소가 있고, 불필요한 요소가 없는 점이죠. 다른 사람이 만든 코드를 파악할 때는 적당한 복잡도를 다루는 일이 중요합니다. 사실 이는 '추상화'라는 사고법의 핵심이기도 합니다.
아래 그림에서 좌측은 cursor가 만든 코드의 실행 결과이고, 우측은 제가 가정한 작동 방식에 대한 대강의 추정입니다.
구조에 영향을 주는 요소 찾아내기
두 번째는 코드의 레이아웃입니다. 제가 추정한 내용과 연결점을 찾을 수 있어야 하는데, 코드가 복잡하지 않고 상상한 역할을 하는 요소로 보이는 코드가 잘 드러났습니다.
const로 지정한 세 개의 요소와 return이 제가 기대한 수준에 부합하는 듯 보였습니다. 저는 react로 프로그래밍을 해 본 경험이 없기 때문에 다음과 같은 질문(채팅)으로 cursor에서 필요한 정보를 확인할 수 있었습니다.
react에서 const 키워드의 의미와 쓰임새를 알려 주세요.
return은 어떤 의미인가요?
분석할 때에도 <모델을 그리기 전에 '생각의 종이'부터 준비하세요>에서 소개한 '진흙에서 구조를 향해From Mud to Structure' 패턴을 적용할 수 있습니다. 막연하게 추정하는 최초의 생각은 마치 진흙 같은 수준입니다. 그러다가 덩어리를 나눠서 생각으로 벽돌을 빚어 보듯이 이런저런 사고 실험을 하는 것이죠.
분석 과정에 작동하는 도메인 지식 혹은 배경 지식
앞서 제가 붉은색으로 표시한 네 가지 덩어리가 생각으로 나눠본 네 개의 덩어리라 말할 수 있습니다. 앞의 두 개는 상태 관리 항목으로 보입니다. 세 번째 const로 지정한 handleClick은 바로 주석에도 설명이 있지만 이름만 보아도 역할이 드러났습니다.
물론, 웹 개발 경험으로 인해 react 경험이 없어도 코드 모양을 보고 그 역할을 추정할 수 있기도 했습니다.
마지막 요소는 return 문인데, 이는 웹 개발 경험이 있어야 짐작할 수 있을 내용입니다. Model–view–controller (아키텍처) 패턴을 아는 사람이라면 react 사용 경험이 없어도 HTML 형태가 주를 이루는 코드를 보고 View 표현을 위한 내용이란 추정을 할 수 있을 것입니다. 하지만, MVC 패턴을 모른다면 쉽게 추정하지 못할 가능성이 높습니다. 그만큼 '분석'이란 일은 해당 영역의 지식 즉, 도메인 지식을 필요로 합니다. 웹에서 구동하는 앱이라면 웹 개발 경험 자체가 도메인 지식의 일부가 됩니다. 도메인 지식이란 표현 대신 배경 지식이라 해도 의미상 차이는 없습니다.
구조에 결정적 영향을 주는 요소 찾아내기
추정에 부합하는 요소들을 찾은 것으로 만족할 수 있을까요? 마치 실험에서 가설처럼 어느 정도는 추정과 부합하는 면들이 있어야 이해가 쉽습니다. 용기를 얻기도 하고요. 하지만, 근본적인 목표는 내가 작성하지 않은 코드를 이해하는 것입니다. 그래서 추정과 일치하는 부분은 이해의 실마리를 제공해 주는 것이죠. 이후의 활동을 단순화시켜 보면 앞서 제가 그린 순차도를 코드로 확인한 내용으로 변경해 보는 식입니다.
이렇게 하다 보면 그 과정에서 배우는 바 그리고 하고 나서 바뀐 이해도로 다시 코드를 관찰할 수 있습니다. 대개 그전에는 모호했던 내용이 확연하게 보이곤 합니다. 어떤 코드가 결정적인 내용인지 알지 못하거나 불분명했던 것이 명확해집니다.
주석
[1] 처음 프로그래밍 언어를 배울 때부터 그런 경험은 피할 수가 없었던 듯합니다. 프로그래밍 언어를 배우는 일 자체가 다른 사람이 작성한 프로그램을 사용하는 일이기도 하기 때문입니다.
지난 어떻게 하면 모델링을 잘할 수 있을까? 연재
3. 모델링을 Actor로 시작한다는 의미는 무엇인가?
5. 사고와 인식과 표현의 주체인 임자로 욕망을 바라보기
6. 모델을 그리기 전에 '생각의 종이'부터 준비하세요
