요약으로 시작하면 어떨까

실 서비스의 코드는 복잡하다.

노장의 얼굴에 복잡한 주름이 지는 것처럼, 실 서비스의 코드는 다양한 장애와 문제 상황을 겪고 요구 사항을 추가하면서

미묘한 오류까지 해결하고 기워둔 상태로 남아 있을 것이다.

그래서 어떤 개념을 소개할 때 인용하기에는 적절하지 않을 수 있다.

실 서비스의 코드는 복잡하다

입사하고 며칠 후, 스프링의 ㅍ도 잘 모르는 상태에서 실제로 작동하는 서비스의 코드를 보고 이해해야 하는 일이 있었다.

코드는 매우 복잡해 보였고, 클래스 하나에 인터페이스가 하나씩 달려 있는 등...

코드의 복잡성과 양에서 모두 버겁다는 느낌이 들었다.

어떤 클래스의 정의를 찾아 들어가려고 하면 다시 모르는 게 나오고, 또 모르는 게 나오고...

마치 집을 나오다가 지갑을 잊어버려서 들어가고, 지갑을 찾다가 손을 다쳐서 반창고를 찾고,

반창고를 찾다가 옷이 망가져서 바늘과 실을 찾는, 끊임없이 후퇴하는 느낌을 받았었다.

이때 스프링 공식 홈페이지에서 짧은 가이드를 보면서 도움을 많이 얻었었다.

별별 주제가 다 있다

이런 가이드에서 제공하는 간단한 코드를 먼저 보고 나니, 복잡한 실 서비스의 코드가 점점 이해되는 경험을 할 수 있었다.

가장 먼저 @RestController나 @SpringBootApplication 같은 애너테이션이 보였고, build.gradle에서 의존성을 가져오는 부분이 서서히 보이기 시작했다.

어떤 클래스를 이용하면 원하는 JSON 응답을 생성해 내는지 알 수 있었고, 점차 핵심적인 작동 방식을 이해하게 되었다.

이는 요약본을 먼저 보고 긴 글을 보았기 때문이라고 생각한다.

요약본은 중심적인 부분과 세밀한 부분을 분리해서 볼 수 있는 힘을 준다.

소설을 읽을 때 줄거리를 먼저 보면, 장면 묘사는 건너뛰고 핵심 사건만 볼 수 있게 되는 것처럼,

간단한 코드를 먼저 보면 보편적인 프레임워크 로직과 비즈니스 로직을 분리해서 볼 수 있는 힘이 생긴다.

어쩌면 대화를 할 때도 요약을 먼저 전달하는 게 덜 피곤한 방법이 아닐까 싶은 생각을 한다.

두괄식으로 대화할 수는 없을까

개발자들과 어떤 주제로 대화할 때, 종종 산 넘고 물 건너서 결론에 도달하는 경우가 있다.

하나의 작업을 하기 위해서 연관되는 개념을 모두 설명한다거나,

하고 싶은 말을 한꺼번에 많이 하면서 정리가 되지 않는다거나...

이런 대화는 마치 리팩토링이 시급한 코드와 닮아 있다는 생각이 든다.

전자는 마치 추상화 수준이 오르락내리락 하는 코드와 닮아 있다. 주제를 파악하기 위한 인지적 노력이 엄청 들어가고, 청자를 지치게 한다.

후자는 마치 관심사를 분리하지 못한 코드와 닮아 있다. 하나하나 필요한 말이지만 한 번에 전달하다 보니 맥락을 파악할 수가 없다.

밥 아저씨가 추상화 수준이 높게 시작해서 낮게 끝나는 코드를 쓰라고 했었는데,

대화도 처음은 요약으로 시작하고 세세한 이야기를 마지막에 하면 어떨까?

그러기 위해서는 말하기 전에 생각을 많이 다듬어야 하겠지만,

코드가 커뮤니케이션의 수단인 것처럼, 커뮤니케이션도 좋은 코드를 닮아가다 보면 좋아지지 않을까 하는 생각을 해 본다. 🙃