일관성에게 관심을

프로그래밍 언어를 비롯한 여러가지 도구의 설계에 일관성에 대한 고려는 매우 중요하다. 일관성을 유지하기 위한 노력이 녹아들어 있다면 보다 적은 자원으로 시스템의 전체 모습과 흐름을 머리 속에 유지할 수 있다. 반대로 일관성이 없는 경우, 전체 시스템을 따라가기 위해서 파악해 두어야 하는 문맥이 커진다. 당연한 이야기지만 같은 성능의 도구라면 자원을 덜 쓰는 것이 좋다.

특히 프로그래밍 언어에 일관성이 부족하면 코드를 작성하는데 더 많은 수고가 들고, 만들어진 코드를 읽는 데에는 더 많은 노력이 필요하다. 일관성은 언어의 문법, 기본 라이브러리에 있는 여러가지 이름들, 언어의 커뮤니티나 철학이 만들어내는 여러가지 컨벤션(ex: style guide)들의 충돌 등에 반영된다.

  • 스타일 가이드가 필요한 이유가 이것. A style guide is about consistency. PEP-008
  • 내가 R 을 정말 매우 엄청나게 싫어하는 이유는 일관성이 없기 때문이다.
  • 난 싫어하지만, Java는 일관성 면에서 다른 경쟁 언어(C++?)에 비해 확실한 장점이 있다고 보인다. Verbosity < Consistency 의 공학적 선택을 한 느낌. 대규모 시스템에 Java가 적절한 선택지가 되기 위한 중요한 포인트다.
  • Scheme은 강력한 표현력과 일관성을 유지하기 위해 다른 여러 장점을 희생했다. 학습용 도구에게 일관성은 중요하다. SICP가 scheme을 쓰는 이유.

라이브러리나 프레임웍, API도 프로그래밍 언어 위에 쌓인 높은 추상화 단계의 도구다. 일관성이 깨지면 만든 사람도 그렇지만, 쓰는 사람은 작성자보다 더한 고통을 받게 된다. 모듈이나 함수 이름이 중구난방이라면? 비슷한 일을 하는 메소드가 여기서는 printInfo() 이고 저기서는 printInformation(), 또 다른 곳에서는 print_info(), 혹은 info_print() 라고 이름지어져 있다고 생각해보자. … … 30초간 상상의 시간 … … 혹은 add(10.0, 5) -> 15.0, add(5, 10.0) -> 15 같은 타입 불일치를 생각해보자. 보통은 이런짓 안하지만 C++ 로 삽질하면 의도치 않게 이런 동작을 만들 수도 있다. … … 30초간 또 상상의 시간 … … 이 예들은 좀 극단적이지만, “외울게 뭐 이리 많아” 라거나 “이건 또 왜이러는거야!” 하고 불평이 자주 나오면 이런 비슷한 일들이 일어나고 있을 가능성이 높다.

도구를 익힐 때 뭔가 보이지 않는 벽이 있다고 느껴진다면 Consistency breakage 를 의심해보자. 도구의 문제점을 명시적으로 인지한다면 적당한 workaround 를 찾아낼 수 있을지도 모르니까. 도구를 만들고 있다면 - 추상화 블럭을 만들고 있다면 - 일관성에 대한 세심한 고려를 부탁한다.


  • 일관성을 해치기 가장 쉬운 요소가 이름짓기다. TwoHardThings중 하나로 Naming things 가 괜히 언급되는 것이 아니다.

Comments