사용자가 똑똑해지도록 돕는 착한 도구 만들기

강규영 | 엔씨소프트 오픈마루 스튜디오 웹 서비스 개발팀
alankang@openmaru.com

스프링노트를 보면 고전적 위키에 비해서는 더 화려하지만 흔히 보는 위지윅(WYSIWYG: What You See Is What You Get) 편집기에 비하면 생소한데 이런 형태의 기획이 나온 배경이 궁금합니다.
스프링노트 팀은 위키가 잠재력이 높지만 블로그만큼 널리 쓰이지 않는 것은 초기 학습 비용 때문이라고 판단했습니다. 그래서 위키의 본질에 충실하면서도 쉽게 배워 쓸 수 있게 만드는 데 집중했습니다. 위키, 특히 초창기 위키들의 중요한 특징 중 하나는 글을 쓸 때 문서의 외양보다는 내용에 집중할 수 있도록 도와준다는 점입니다. 따라서 사용하기 쉽게 하기 위해 위지윅 편집을 지원하면서도 외양을 꾸미는 것보다는 의미를 충실히 담아내기에 좋은 문서 편집기를 생각하게 되었던 것이죠.
또 한 가지 고려한 것은 기존 웹 위지윅 편집기들이 깔끔하지 않은 HTML 문서들을 만들어 낸다는 점이었습니다. 웹 표준을 지키지 않거나, 기계적으로 검사해 보면 표준을 지킨 것으로 나오지만 실제로는 의미에 맞지 않게 태그를 쓰는 경우가 많습니다. 예를 들면 들여쓰기를 하기 위해 블록 인용(blockquote) 태그를 쓰는 것 등이 대표적인 문제입니다. 스프링노트 편집기는 이러한 문제를 어느 정도 해결하였고, 의미적으로도 올바른 XHTML 문서를 만들어줍니다.

어떤 서비스들에서 영향을 받으셨나요.
어떤 서비스로부터 영향을 받았다기보다는 초기 베타 사용자들로부터 영향을 받았다고 하는 게 맞을 것 같습니다. 스프링노트는 개발 초기부터 베타 사용자들의 피드백을 받으면서 개발했기 때문에 초기 비공개 베타 버전과 현재의 스프링노트는 상당히 다른 모습이었습니다. 예를 들면 초창기에는 위지윅이 아닌 버전도 있었고, 한 화면에 편집기가 두 개인 버전도 있었죠.

엑스퀘어드 개발에 사용한 오픈 소스 프로젝트들은 어떤 기준으로 고르셨나요.
초창기 스프링노트 프로젝트에서는 편집기를 직접 개발할 생각은 하지 않았고, 별 고민 없이 제일 유명한 오픈 소스 편집기를 골랐습니다. 처음에 고른 것은 FCKeditor로 가장 유명하고 널리 쓰이는 위지윅 편집기입니다. 그러다가 같은 팀의 동료 개발자가 TinyMCE를 추천했습니다. TinyMCE 또한 매우 유명한 오픈소스 HTML 편집기죠. 살펴 보니 확장하기도 좋고 소스도 깔끔해 보여 한동안은 TinyMCE가 스프링노트 편집기로 쓰였습니다.
하지만 문제가 생겼죠. 스프링노트는 ‘항상 편집 모드’라는 게 있어서 편집 모드와 읽기 모드가 거의 똑같이 보여야 하는데 이를 잘 지원하지 못했고, 자동 저장 기능을 구현하려면 현재 편집중인 문서를 주기적으로 유효화(validate)하여 서버로 전송해야 하는데, TinyMCE는 유효화를 수행할 때 마다 시간이 오래 걸려 문서 작업이 뚝뚝 끊어지는 문제가 있었습니다.
결국 이런 저런 문제 때문에 TinyMCE를 포기하고 밑바닥부터 새로 만들기 시작했습니다. 물론 밑바닥이라고 해서 아무 라이브러리도 안 쓴 것은 아니고요, 유명한 자바스크립트 라이브러리인 Prototype은 사용했습니다. Prototype을 선택한 이유는 두 가지인데, 첫째, 브라우저 호환성 문제를 어느 정도 감춰줄 하부 라이브러리가 필요했고, 둘째 Prototype에는 자주 쓰이는 코드를 짧게 줄여 쓸 수 있도록 도와주는 다양한 유틸리티 함수들이 있었기 때문입니다. 비슷한 일을 해주는 다른 라이브러리가 아니라 Prototype을 선택한 이유는 그것이 가장 널리 쓰이는 라이브러리이고, 널리 쓰이는 라이브러리일수록 안정적일 것이라고 생각했기 때문입니다.

어떤 프로그래밍 기법을 유용하게 활용하셨나요.
특별한 것은 없습니다. 굳지 꼽자면 객체지향 프로그래밍입니다. Ajax 개발의 큰 난점 중 하나는 브라우저마다 서로 다른 코드를 작성해야 할 일이 많다는 점인데요, 이 문제는 특히 편집기 제작에 필요한 기능(DesignMode)을 사용하고자 할 때 더욱 커집니다. 자칫 잘못 접근하면 if/else가 사방팔방에 도배되기 쉽죠. 하지만 이러한 상황은 객체지향 프로그래밍을 적용하기에 딱 좋은, 매우 교과서적인 상황이기도 합니다. 브라우저 공통 부분은 상위 클래스로 만들고 브라우저에 특정적인 부분은 하위 클래스로 만들면 if/else 남발이 거의 없어지고(turn conditionals into polymorphism refactoring) 소스 길이도 짧아지죠. 함수형 프로그래밍 스타일 또한 즐겨 썼는데요, 특히 트리 탐색이나 재귀적 데이터 수집 등을 수행하는 제네릭(generic) 함수들을 만들어 놓고, 이를 조합하여 다양한 HTML DOM 조작 기능을 편리하게 구현할 수 있었습니다.

처음부터 공개를 염두에 두고 개발하셨나요.
그렇기도 하고 아니기도 합니다. 스프링노트 팀(혹은 오픈마루 스튜디오)은 초기부터 프로젝트 개발 과정(process)을 최대한 투명하게 공개하는 것을 목적으로 하고 있었고, 만들어진 서비스 자체도 초기부터 개발자 API를 지원하고 다양한 표준을 적극적으로 도입하는 등 개방성을 매우 중요하게 생각하고 있었습니다. 소스 코드 공개도 개방, 소통, 참여라는 가치를 실천하는 한 가지 방법이라고 생각할 수 있을 것 같습니다.
처음부터 “스프링노트의 편집기 코드를 공개해야지”라고 구체적으로 계획한 것은 아니지만, 결과물 전부 혹은 일부를 가능하면 이른 시기에 오픈 소스 프로젝트로 만드는 것에 대해 어느 정도 공감대를 가지고 있었습니다. 앞으로도 오픈마루에서 여러 가지 오픈 소스 프로젝트가 시작될 것입니다.

공개를 위해 어떤 작업들을 진행하셨나요.
편집기 안에 여러 기능이 있는데 그 중에서 스프링노트에서만 필요로 하는 기능들은 스프링노트로 밀어냈습니다. 예를 들어 ‘*’를 입력하고 글을 쓴 후 엔터를 치면 ‘*’가 자동으로 ‘•’로 바뀌는데 엑스퀘어드를 가져다 쓰려는 모든 곳에서 이런 기능을 원하지는 않을 수도 있으니까요.
이러한 기능을 스프링노트로 뺄 때 단순히 분리만 한 것이 아니라, 엑스퀘어드 쪽에 확장점(extension point)을 만들면서 분리하는 방식으로 접근했습니다. 결과적으로 단축키, 자동 완성, 자동 변환, 컨텍스트 메뉴, 템플릿 처리기 등 다양한 확장점을 가지게 되었습니다.

“만들수록 버그가 늘었다”는 말을 하신 적이 있는데 개발의 어려움을 익살스럽게 표현한 것인가요, 아니면 실제 상황이었나요.
100% 유머는 아니었습니다. 웹 개발은 브라우저 별 특성 등 여러 이유 때문에 플랫폼 자체가 견고하지 못한 편입니다. 그 중에서도 웹 편집기 개발은 상당한 ‘오지(奧地)’ 입니다. 편집기의 어떤 기능을 구현한다는 게 기존 브라우저 기능을 막고 그 위에 기능을 덧붙이는 성격인데, 기존 브라우저 기능에 워낙 문제가 많아 기본 기능을 막지 않고 그냥 두면 그 자체가 버그처럼 보이는 경우가 많습니다.
더 어려운 문제는, 일관적이고 논리적인 구현 방식이 항상 사용하기에 편리한 것은 아니라는 점인데, 이를테면 특정 상황에서 캐럿을 어떤 위치에 두고 delete를 눌렀을 때 어떻게 작동해야 하는가에 대해 사용자마다 의견이 다르고, 같은 사용자라고 하더라도 상황에 따라 다른 작동을 기대하는 경우가 있습니다. 이러한 다양한 예외를 하나씩 처리하지 않고 무조건 “일관적으로 작동하도록” 만들어버리면 이 또한 버그로 인식됩니다.
버그를 줄이는 게 생각보다 쉽지 않지만 TDD나 BDD를 적용하며 계속 테스트 커버리지를 높여가고 있기 때문에 상황이 점점 나아지고 있습니다. 버그가 발견되면, “그 버그가 고쳐지지 않으면 실패하는 테스트 케이스”를 먼저 만들어 놓고, 버그를 수정합니다. 이런 식으로 접근하면 한 번 나타났던 버그가 다시 나타나는 문제를 어느 정도 막을 수 있고, 시간이 흐름에 따라 테스트 커버리지가 점점 높아진다는 장점이 있습니다.

Ajax 개발은 정말 ‘가시밭길’일까요.
Ajax라는 것 자체가, 여러 브라우저에서 그럭저럭 잘 돌아가고 있는 기능들을 버무려 놓은 그런 기술이다 보니, 태생적으로 여러 난제가 있습니다. 하지만 점점 나아지고 있습니다. 브라우저들이 계속 발전하고 있고, 기능이 부족하거나 구현이 조악한 과거 버전의 브라우저는 사라져가고 있으며, Ajax를 위한 라이브러리나 프레임워크, 각종 IDE가 쌓여가고 있습니다.
문제는, 엑스퀘어드는 그런 것들의 혜택을 많이 못 받는 영역에 있다는 사실이죠. 편집기를 만들 때는 브라우저의 디자인 모드라는 것을 이용하는데 일단 디자인 모드로 들어가면 기존 라이브러리들이 오작동하는 경우도 있고, 최신 브라우저라고 하더라도 디자인 모드로 전환되면 예전 브라우저처럼 동작하는 등 몇 가지 문제가 있습니다. 해외의 몇몇 개발자는 브라우저 디자인 모드를 쓰지 않고 편집기를 개발하려는 시도를 하고 있습니다. 마우스를 클릭했을 때 캐럿이 깜박거리는 것이나, 텍스트를 선택하는 등의 로직을 모두 다 자바스크립트로 만드는 것이죠. 꽤 괜찮은 방법 중 하나인 것 같습니다만 다양한 국가별 언어 입력기(IME - 한글 입력기 등)를 구현해야 하는 문제 등 몇 가지 문제가 있어 보입니다.

브라우저 호환성 문제는 상당한 스트레스일 것 같은데……
브라우저 종류별로 서로 다른 엔진을 쓰는데 디자인 모드의 경우 특히나 호환성 문제가 많습니다. delete를 눌렀을 때 모든 브라우저에서 똑같이 동작하게 한다거나, 파이어폭스에서 작성한 문서를 인터넷 익스플로러에서 열었을 때 똑같이 보여야 한다거나 하는 등 여러 브라우저에서 편집기가 정확히 동작하도록 만드는 게 상당한 스트레스죠. 몇몇 문제는 단순히 브라우저 호환성을 넘어서서 OS 차원으로 내려가기도 합니다. 예를 들어 같은 파이어폭스라도 윈도와 맥과 리눅스에서 제 각각으로 동작하는 경우가 간혹 있습니다. 단축키 처리가 대표적인 예죠.

자바스크립트에 대한 편견이나 자바스크립트 커뮤니티 규모가 프로젝트 참여자 확대에 장애가 될 수 있다고 보시나요.
그럴 것 같습니다. 한국뿐만 아니라 세계적으로도 자바스크립트에 대한 편견이 있습니다. 자바스크립트에 대한 편견 이전에 웹 프로그래밍 자체에 대해서도 편견이 있죠. 일례로 “개발을 10년이나 했는데 왜 아직도 웹을 하세요?”라거나, “자바스크립트는 장난감 언어 아닌가요?”라는 말을 종종 듣습니다.
자바스크립트는 사실 좋은 언어입니다. 지난 9월에 ‘Ajax 월드 컨퍼런스 & 엑스포’에 다녀왔는데, 자바스크립트 계의 요다(Master Yoda)라 불리는 Douglas Crockford의 강의를 인상 깊게 들었습니다(http://www.openmaru.com/171). 그는 자바스크립트가 많은 장점과 단점을 함께 가지고 있는 언어라고 말하며, 단점을 피하고 장점을 잘 살려 쓰면 자바스크립트 안에 숨어있는 정말 좋은 언어를 재발견할 수 있을 것이라고 말하는데 깊게 공감합니다. 그는 일전에 “자바스크립트: 세상에서 가장 많은 오해를 받은 프로그래밍 언어”라는 글을 쓰기도 했죠. 하지만 Ajax 덕분에 자바스크립트에 대한 인식이 서서히 변하고 있는 것 같아 다행입니다. 다양한 커뮤니티도 생기고 있고요.

앞으로 로드맵은 어떻게 되나요.
단기적으로는 사파리 3 - 웹킷(WebKit) 지원을 향상시키는 것과 개발자들이 엑스퀘어드를 받아서 바로 붙일 수 있게 스킨(skin)을 좀더 마련하는 것, 확장할 때 참고할 수 있는 예제와 문서를 보충하는 것입니다.
장기적으로는 접근성 향상과 확장점 추가입니다. 야후에서 공개한 HTML 편집기를 보면 자바스크립트가 동작하지 않거나 구형 브라우저에서도 최소한의 글쓰기를 할 수 있도록 되어 있는데, 엑스퀘어드도 이런 측면을 지원하고자 합니다. 또 툴바 등의 인터페이스에 대한 키보드 네비게이션을 지원하는 것도 중요합니다.
확장점도 계속 늘려갈 생각입니다. 지금 생각하는 것 중 하나는 매크로 기능입니다. 웹 문서 안에서 실행되는 코드(예: 유튜브 동영상 재생 코드)를 문서에 삽입할 수 있게 하는 것이죠. 또 하나는 에디틀릿(editlet)입니다. 편집기 안에 작은 편집기를 임베드하는 것인데요. 워드 안에 엑셀 표를 집어넣을 수 있는 것과 비슷합니다. 에디틀릿을 통해 표, 수식, 이미지 편집을 개선할 수 있을 것 같습니다. 매크로와 에디틀릿이 제대로 구현되면 이를 기반으로 하여 마이크로포맷을 좀 더 잘 지원할 수 있습니다. 이를테면 캐럿이 이동하다 특정 영역에 들어갔는데 그 영역이 특정 마이크로포맷으로 인식되면 그 마이크로포맷을 편집할 수 있는 에디틀릿이 뜨는 것이죠.

리더로서 사용자와 개발자들이 어떤 가치를 얻기를 바라시나요.
드림위버나 나모웹 에디터 같은 훌륭한 편집기들이 양질의 웹 문서를 생산할 수 있게 해주지만 이러한 도구는 극소수의 웹 컨텐츠 저작자들만 사용할 수 있습니다. 대부분의 최종 사용자는 게시판이나 블로그 등에 글을 쓰는 과정을 통해 웹 문서를 만들어내는데, 웹 문서의 대다수는 이렇게 생성됩니다. 하지만 현재의 위지윅 편집기들은 대부분 깔끔하지 못한 문서를 만들어내죠. 엑스퀘어드가 각종 게시판과 블로그 등의 글쓰기 도구로 많이 보급된다면 표준을 준수하고 의미적으로도 올바른 웹 문서가 인터넷에 많이 쌓일 것입니다. 이러한 양질의 문서가 많아지면 인터넷이 더 유용한 공간이 될 것이고, 마이크로포맷 기반 분산형 검색 등 다양한 시도를 해볼 수 있을 것입니다.

프로젝트를 하면서 개인적으로 얻은 성과 중 기억에 남는 것은 무엇인가요.
첫째는 자바스크립트를 배운 것입니다. 전에는 주로 자바로만 개발을 했고, 다른 언어들은 취미로 잠깐씩 만져보는 수준이었는데, 이번에 본격적으로 자바스크립트를 하게 되면서 그 덕분에 동적인 언어를 본격적으로 느껴 볼 수 있었습니다. 자바스크립트는 동적이면서 함수형 프로그래밍을 할 수 있고 프로토타입 기반 객체지향언어라는 점 등 다양한 면에서 자바와는 다른 느낌입니다. 둘째는 “얻은 성과”라기보다는 “앞으로 얻게 될 것이라고 기대하는” 것이 있는데요, 바로 오픈 소스 프로젝트 경험 그 자체입니다. 그 동안은 간헐적으로 패치나 보내고 이메일로 질문이나 몇 번 하는 수준에서 참여했던 프로젝트가 몇 개 있을 뿐이었는데, 엑스퀘어드를 계기로 오픈 소스 문화를 본격적으로 접해볼 수 있게 되기를 기대합니다. (그런 의미에서) 개발자 분들의 많은 참여를 바랍니다. 아직은 혼자라서 외로워요.

JSSpec에 대해서는 어떤 계획이 있으신가요.
JSSpec은 엑스퀘어드를 개발하는 과정에서 만들어진 부산물 같은 것인데요, 처음에는 엑스퀘어드 테스트 자동화에 TDD가 아닌 BDD(Behavior Driven Development)를 적용해보고 싶었습니다. 자바스크립트용 BDD 프레임워크를 몇 가지 써 봤는데 여러 가지로 미흡하여 그냥 직접 만들었습니다. 만들어 놓고 보니 그럭저럭 괜찮아 오픈 소스화하였는데, 예상 외로 관심을 받고 있습니다. 최근에 mootools라는 자바스크립트 라이브러리의 테스트 프레임워크로 채택되기도 하고 미국, 일본 등 해외 사이트에서 종종 인용되고 있습니다.
앞으로의 계획은, 일단 엑스퀘어드 테스트 자동화를 하면서 그에 따라 필요한 기능을 추가하는 식으로 조금씩 발전시키고 싶고, 틈이 나면 풀 스택 BDD(Full-stack BDD) 지원, 자동 테스트(이를테면 최근에 실패한 테스트를 자동으로 다시 테스트하는 기능) 같은 것을 구현해 보고 싶습니다.

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

가장 영감을 받은 코드는 무엇인가요.
최근에 본 것 중에는 Functional Javascript라는 것을 들고 싶습니다. 자바스크립트에서 함수형 프로그래밍을 지원하지만 문법이 좀 지저분합니다. 이것을 아주 간단한 아이디어로 개선한 것인데 다음 프로젝트에서 꼭 써보고 싶습니다.
몇 년 전에 봤던 자바 코드 중 워드 커닝엄의 FIT(Framework for Integrated Test)이 매우 인상 깊었는데요, 특히 자바 코드 기준 150줄짜리 HTML 파서가 참 재미있었습니다.

자기 소개에 ‘지적 역마살이 있다’고 썼는데 문자 그대로 정처 없이 떠도는 것인지, 가고자 하는 곳이 있는지 궁금합니다.
정처 없이 떠도는 것은 아니고 정해진 레퍼토리가 있습니다. 진화생물학, 진화심리학, 심리철학, 컴퓨터 사이를 계속 도는 거죠. 요즘에는 진화심리학(및 인지과학) 분야의 지식을 사용자 인터페이스에 적용하는 일에 흥미를 느끼고 있습니다. 스프링노트 혹은 엑스퀘어드에 이러한 부분들을 반영할 수 있으면 좋겠습니다.

[강규영 소개] 이런 저런 잡다한 주제에 관심이 많아 지적 역마살이 낀 점을 제외하면 평범한 개발자다. 엔씨소프트 오픈마루 스튜디오 웹 서비스 개발팀에서 근무 중이며 틈틈이 개인 위키를 운영하고 있다.

[지난 인터뷰 보기]