Canonical Form
Canonical Form, 한국말로는 표준 형식이라고 부른다. 일상적인 말로 설명하면 어떤 대상을 “표준적으로 표현”하기 위한 약속이다. 다양한 방법으로 표현된 같은 대상을 하나의 약속된 표현으로 바꿀 수 있다면 이 약속된 표현을 “Canonical Form”이라고 부른다.
어떤 대상을 Canonical Form으로 바꾸는 일을 정규화라고 부른다. 영어로는 Normalization 혹은 Canonicalization 두 단어가 모두 사용되는 것 같다. 예를 들어 데이터베이스에서 말하는 정규화는 Normalization인데 이 역시 데이터의 형식을 Canonical Form으로 바꾼다는 의미를 담고 있다.
좀더 구체적인 예를 들면 파일 경로를 “표준적으로 표현”하기 위한 방법으로 Canonical Path 라는 것이 있다. /foo/bar/../././////baz 와 같은 경로 문자열을 Canonical Path로 바꾸면 /foo/baz 가 된다. //foo//bar//a/..//././//../baz/// 역시 정규화하면 /foo/baz 가 된다. 이처럼 여러 형태로 표현될 수 있는 대상을 비교하려면 대상을 정규화하는 작업이 반드시 선행되어야 한다.
요즘 팀이 커지면서 이런 표준 형식이 중요하다는 생각이 들었다. 좀더 구체적으로는 프로젝트를 시작할 때 우리가 관심있는 데이터에 대해 팀원들이 모두 동의하는 표준 형식을 정의하는 일이 필요하다는 사실을 깨달았다. 그렇지 않으면 나중에 Technical Debt가 엄청나게 쌓이더라. 그리고 다른 동료의 코드를 볼 때 잘 이해가 되지 않는 부분은 서로 생각하는 Canonical Form이 달라서 발생한 경우도 종종 있었다. 내가 무의식적으로 가정한 데이터 형식이 실제로는 다른 사람의 생각과 다른 경우가 많았다.
그리고 이것은 소스 코드에 대해서도 마찬가지이다. 코드를 데이터로 보자는 Lisp 같은 얘기를 하려는 것은 아니다. 프로그래밍 언어에서 표준적으로 사용되는 스타일 컨벤션을 따르자는 얘기이다. PEP 처럼 진짜 표준으로 정해진 경우도 있고, 구글 코딩 스타일처럼 해당 언어에 지배적인 영향을 미치는 특정 기업이 주도하는 경우도 있다. 뭐가 됐든 중요한 것은 일관된 스타일, 일종의 Canonical Form을 생각하며 코드를 작성해야 코드 리뷰 시에 인지적 부하를 줄이는데 도움이 된다는 것이다. 나는 코드의 로직 리뷰에 집중하고 싶지, trailing comma의 유무나 무의미한 공백을 리뷰하고 싶지는 않다.
그래서 이것은 기술적인 영역이기도 하지만 조직적인 영역이기도 한 것 같다. 수학적인 정의가 존재하긴 하지만 그것은 수학의 얘기이고, 우리 팀과 업무 영역에서 필요한 표준 형식은 팀원 혹은 팀 간의 의사소통을 통해 맞춰가야 하는 부분이라고 생각된다.