개발도 EQ다

"글로 전달하지 못하는 것은 말로도 못한다." 소통에 대한 개인적인 철학이다. '말'이라는 건, 뱉는 사람은 쉽다. 그러나 뱉는 사람의 생각이 제대로 듣는 사람에게 전달되게 하는 것은 매우 어려운 일이다. 1. 내가 가지고 있는 생각을 나열한다. 2. 결론적으로 하고자 하는 말을 정리한다. 3. 결론이랑 관계없는 생각은 모두 제거한다. 4. 결론을 먼저 그리고, 관련된 생각을 중요도 순서대로 작성한다. 5. 문장을 간결하게 바꾼다. 6. 듣는 사람 입장에서 다시 읽어보고 불필요한 단어와 문장을 지운다. 글을 잘 써야 할 때는 위 6단계를 거치지만, 매번 그러지는 못한다. 귀찮고, 시간도 많이 걸리니까. 하물며 글을 쓸 때도 그런데, 말할 때는 어떨까. 위 6단계는 커녕, 즉시 떠오르는 생각을 말하는 게 대부분이 아닐까. 제일 중요한 건 6번이라고 생각한다. 언젠가 아버지께 '보고서 잘 쓰는 방법'을 여쭤본 적이 있다. 아버지의 답변은 이랬다. "집 앞에서 담배피는 아저씨 붙잡고, 보고서 읽어보라고 해라. 이해하시면 잘 쓰는 거고 아니면 못 쓴거다." 요는 쉽게 쓰라는 것. 이후에 ppt를 잘 작성하는 방법을 여쭤본 적이 있다. "발표를 듣는 사람 입장에서 궁금해할만한 것만 적어 넣어라." 발표 자리를 흔히들 발표자가 하고 싶은 말을 하는 것이라고 생각하겠지만, 진짜 잘하는 발표는 듣는 사람이 궁금해할 내용을 말하는 것이라고 한다. 소통에 대한 나의 의견을 한줄로 정리하면 이렇다. "상대방을 이해하고, 상대방이 관심있을 내용을 얘기한다." 결국 소통을 잘하려면 EQ가 높아야한다. 개발도 마찬가지다. 코드를 작성하다 보면, 작성자만 편한 코드를 작성하게 된다. 이후에 작성자의 코드를 보게 될 누군가를 고려하며 짜는게 쉽지 않다. 여러가지 요소가 있겠지만, 특히 인터페이스를 정의할 때, EQ능력을 활성화해야 한다. 예를 들어, front 단에서 다음과 같은 상황이 있다고 가정해보자. 상위 컴포너트에서 하위 컴포넌트가 첫번째일 경우 왼쪽 border line을 그리라고 데이터를 넘겨준다. 이때, 작성자는 인터페이스로 isFirst 라고 정의하고 true를 넘겨줄 수 있다. 하위 컴포넌트에서는 isFirst이면 왼쪽 border line을 그리는 것이다. 나름 논리가 있다. 다만, 제3자 입장에서는 다소 난해하다. 제3자 입장에서 보면 이렇다. "isFirst를 보고는 음 첫번째를 나타내는 것이군, 첫번째 일 때 뭔가 하겠는데? 그게 뭐지?" 인터페이스만 보고도 그걸 가지고 뭘 할 수 있는지 알 수 있으면 더 좋을 것이다. 더 구체적으로 정의하면 좋겠다. border line에 대한 정의니 대략 이런식으로 전달할 수 있겠다. borderline: "left" | "both" | "right". 이제 인터페이스만 보고도 이 파라미터가 어떻게 쓰이고 내부에서 어떤 동작이 있을지 예측이 가능하다. isFirst는 첫 번째에 해당하는 속성에 따라 여러가지 값이 바뀌는 것을 예상하고 만들었을 수 있다. 하지만 그 경우에도 각 경우에 따른 구체적인 파라미터를 전달하는게 제 3자의 입장에서는 더 이해하기 편할 것이다. 코딩도 결국은 소통이고, 소통을 잘하는 방법 중 하나로 읽는 이, 듣는 이의 입장에서 작성하는 것이 있다. 코드를 작성하다 보면, 너무 작성자 입장에서 쉬운 코드를 작성하는 경향이 있다. 코드 푸쉬 하기 전에, 제 3자 입장에서 인터페이스의 파라미터만이라도 한 번 더 체크해보는 게 어떨까.