Specification Language
그동안 글이 뜸했었네요. 최근에 이직을 하게 되어서 정신이 없기도 했었고 (그런 것 치고는 3월 이후로 글이 없긴 했네요 :) ) 회사노트북만 사용하면서 글을 쓸 환경을 만드는 게 여의치 않았기도 했네요. 웹 브라우저를 켜고 바로 글을 쓸수 있는 환경이 아니라 haskell도 설치해야 하고, static site generator도 컴파일 해야 하고, 키도 만들어야 하고, 이미지 파일 싱크도 해야 하고 여러 복잡한 준비과정이 필요하다 보니 아예 처음부터 발걸음이 떼지지 않았다고 할까요?
얼마 전 날 잡고 작업을 했습니다. 이미지는 구글 드라이브에서 싱크하던 걸 아예 도메인을 새로 파서 이미지는 따로 CDN 을 통해서 불러오게 바꿨구요. 회사 노트북 보안 단계도 한단계 낮춰서 [Homebrew][]를 사용할 수 있게 해뒀네요.
이런 과정을 거치고 나니 무언가 글을 하나라도 써야겠다는 의무감이 좀 생깁니다. 그래서 오늘은 지인들과 모여서 이야기 했던걸 풀어놓을까 합니다.
이전 회사에서 일할 때에는 문서를 작성할 상황이 많지 않았는데, 이직을 하고 난 후 문서 작성, 그중에서 스펙문서(Specification)를 작성하는 경우가 많네요. 회사 분위기가 다르다보니 일하는 방법도 많이 다르네요. 제가 영어권 사람이 아니다보니 스펙 문서를 쓰는게 항상 부담이 많이 됩니다. 말도 제대로 못하는 외노자인데, 문서로 다른사람을 이해하게 하는 글을 써야 하는게 정말 어렵더라구요.
영어권 사람들과 스펙을 보완하고 수정해 가는게 정말 기나긴 시간이 걸립니다. 하드웨어 디자인은 순식간에 만들었는데, 문서를 보완해가다보니 두달이 지나도 문서가 완성될 기미가 안보이더라구요. 그러다 보니 힘들기도 하고, 지치기도 하고, 무슨 좋은 방법이 없을까 지인들과 이야기를 하게 되었네요.
그런 부분을 해결할 방법을 찾아보게 되면서 자연스레 영어 기술을 효과적으로 하는
방법을 궁리하기 시작했습니다. 가장 중요한 것은 표현을 제약하는 것이더군요.
스펙을 작성하거나 읽다보면 항상 접하는 조동사가 몇개 있는데, 이런 조동사는
스펙에서 정해진 의미로만 쓰인다고 암묵적으로 합의 되어 있습니다. 그 조동사는
shall, should, may 등이 있는데, 강제(mandatory)하는 것에서부터 점점
추천(recommendation)하는 것까지 표현하려고 사용됩니다. shall은 반드시 지켜야
하는 조건을 이야기하지요.
이게 어디서 나왔는지 알아보니, IETF RFC 2119에서 제안된 내용이더군요. 그런데 이 RFC를 만들 때 왜 조동사만 정의 했을까 의문이 들더군요. 이 제안을 할 때 문서의 작성 규칙이나, 아니면 다른 부분까지 제한하는 것은 왜 하지 않았는지 궁금해집니다.
그래서 그런 규칙을 만들어야 하나.. 고민하면서 이야기 하다보니, 차라리 Esperanto 언어같이 단순한 규칙을 가지고 하나의 단어가 하나의 뜻만을 가지고 있는 언어로 기술하는 것도 낫겠다.. 라는 생각도 해보고, 그러면 Esperanto와 1:1로 매칭되는 단어사전을 이용해서 그 단어만 가지고 영어로 기술하는 것도 괜찮지 않을까? 하는 이야기도 했네요.
그러다 링크를 하나 받았는데, 이미 20년 전에 그에 관해 토의가 꽤 있었더군요. 꽤 다양한 스펙 언어가 이미 공개되어 있었네요. 대략 훑어보니 저희가 의도한 것과 비슷하게 단어와 표현법을 제약하는 게 주된 방법인 것 같습니다.
그중에 Attempo Controlled English가 꽤 눈길을 끕니다. 이제 문서를 읽어보기 시작하는데, 저희의 의도와 비슷한 말을 하고 있다보니 더 관심이 가나봅니다.
제 메니져에게 지나가는 듯이 말했더니, 아니나 다를까 영어 네이티브인 메니져는 아무런 관심이 없군요. 영어로 글을 쓰는게 물 흐르듯이 되다보니 이런 것에 관심이 갈 리가... 그래서 그런지 ACE도 스위스 취리히 대학에서 만든거군요.
역시 영어 네이티브가 아니여야 이런 궁리를 하는거구나... 싶네요.