코딩할 때 남들도 다 알거라는 착각이 위험한 이유
저는 요즘 닌텐도 스위치 스포츠에 푹 빠져 있습니다. 특히 배구에 빠져 있습니다. 다른 게임들과 다르게 팀워크가 중요하고, 특히 서브를 위한 빌드 업을 해서 공격하는 것이 맘에 들었습니다.
공을 토스하면서 "자 간다!"라고 외칩니다. 이 말을 들은 우리 팀은 무슨 뜻인지 정확하게 이해하고 타이밍에 맞게 서브를 날립니다. 제가 "자 지금부터 내가 너에게 공을 토스해 줄 거야. 네가 편하게 칠 수 있도록 공을 올려줄게. 너는 타이밍을 맞춰서 점프를 한 다음, 상대방의 블락을 피해서 스파이크를 날려!"라고 하지 않아도 됩니다. 짧은 한마디로 제 모든 의도를 전달할 수 있습니다.
이런 일이 가능한 이유는 팀원들간에 공통 기반 지식이 있기 때문입니다. 척하면 척 알아듣는거죠. 이러한 공통 기반은 우리가 커뮤니케이션을 효율적으로 할 수 있는데 아주 큰 도움이 됩니다.
이러한 공유된 믿음은 다른 사람들에 대해서 정확한 가정을 할 수 있게 해주며, 무엇을 할 것인지 정확하게 예측할 수 있게 해줍니다. 서로에 대해 예측 가능성이 높을수록 팀의 성과도 높다는 연구결과가 있습니다. 이걸 다른 말로 하면 투명성이라고도 부릅니다. 서로 알고 있는 지식이 상식처럼 여겨진다면, 투명성이 높다고 볼 수 있습니다.
하지만 이러한 공통 기반은 우리가 생각하는 것만큼 잘 동작하지는 않습니다. 공통 기반은 서서히 손상되고, 오해를 불러일으킵니다. 상황도 바뀌고 목표도 바뀌면 공통 기반을 유지하기 힘들어집니다. 특히 복잡하고 변화하는 상황에서는 더더욱 그렇습니다. 심지어 소프트웨어 개발팀은 공통 기반을 가지고 있는 사람이 바뀌기도 합니다.
다음은 제가 실제로 코드 리뷰를 남긴 사례입니다.
- 바람직한 컴포넌트의 작명 기준
ClickMe 컴포넌트와 Button 컴포넌트명을 지을 때 고민이 되었던 사항이 있습니다.
저는 핵심적인 정체성이 잘 드러나면 될 것 같아서 ClickMe는 굳이 Button이라고 명시하지 않았습니다.
둘 다 버튼을 누르면 조작되고 보여지는 컴포넌트라는 특성이 있지만,
다른 역할을 할 때 컴포넌트 이름을 어떻게 지으면 좀 더 직관적이게 될지 고민입니다.
위 질문에 대하여 다음과 같이 답변을 남겼습니다.
- 이러한 일이 발생하는 이유는 다른 사람들도 내가 이해하는 대로 이해할 거라고 생각하기 때문입니다. 내가 지금 기억하고 있는 것을 미래의 그때에도 기억할 거라고 생각하기 때문입니다.
- 단어라는 것은 다르게 해석될 수 있습니다. 단순한 단어보다는 예를 들어서 설명하는 것이 훨씬 정확하게 전달할 수 있는 방법입니다. 이러한 예시를 우리는 테스트 코드로 작성할 수 있습니다.
- 사람마다 가지고 있는 지식은 다를 수 있습니다. 각자 가지고 있는 지식이 다르기 때문에, 그 사람도 알고 있을 거라고 착각할 수 있습니다.
우리는 공통 기반을 지속적으로 감독하고 수정해야 합니다. 팀원들이 바뀌어도 영향이 없도록 공통 지식 언어를 만들고, 팀의 컨벤션 문서를 만들고 다듬어야 합니다. 또한 코드 리뷰를 통해서 이러한 지식들이 잘 만들어지고 있는지 감독하고 수정해야 합니다. 그리고 코드에 나만 아는 맥락으로 이해할 수 있는 코드를 만들어서는 안됩니다. 그러려면 명확하게 이해될 수 있는 이름, 이를 뒷받침하는 테스트 코드들이 있어야 합니다.