한날의 낙서 [Hannal's scribbling]

들어가며

예전엔 그다지 신경쓰지 않았는데, 전자우편(email, 이메일)을 메신저 수준으로 쓰면서, 아니, 지금은 메신저보다 전자우편에 더 비중을 두다보니 전자우편을 보낼 때 여러 가지를 신경 쓴다. 틀(양식)이나 수신할 사람 지정 등이 그렇다.

예전에 다니던 회사에서 신청자에 한해 매달 사내 직원 교육을 했었는데, 한 번은 주제가 비즈니스 이메일(업무 전자우편)이었다. 그때 들었던 내용나 인터넷을 통해 이리 저리 접한 자료, 그리고 내 경험을 정리해서 공유해본다.

제목

종이 편지와 다른 점 중 하나는 바로 제목이다. 종이 편지를 쓸 때는 대체로 제목을 쓰지 않지만, 전자우편은 기본 항목이나 마찬가지이다.

전자우편 제목은 내용에 대한 주제여야 한다. 대체로 제목에 인사말을 넣는 실수가 많다. “안녕하세요, 누구님. 한날이라고 합니다” 라고 쓰는 것이다. 전자우편 보내는 목적이 인사나 안부를 묻는 것이라면 상관없지만, 그게 아니라면 제목엔 전자우편을 보내는 목적(주제)을 담아야 한다. 예의 없어 보이는 것 같아서 제목부터 공손히 인사하려는 애틋한 마음을 이해 못하는 바 아니나, 이런 전자우편은 “안녕하세요. 좋은 투자 정보가 있어 연락 드립니다”라는 제목으로 날아오는 광고 전자우편(스팸 메일) 취급 받기 쉽다.

본문

전자우편 본문은 단락 세 개 정도가 적당하다고 한다. 실제로 대다수 전자우편 도구(software)나 웹서비스에서 전자우편을 열어보면 단락 세 개 정도가 한 화면에 잘 보인다. 물론, 한 단락당 문장이 3~5줄이다.

첫 번째 단락은 짧은 인사말과 함께 본론, 즉 전자우편을 보내는 목적(주제)을 쓴다.

안녕하세요, XXX님. 한날입니다.

며칠 전에 전화통화로 간단히 얘기 나눴던 책 후원에 대해 보다 자세한 계획서/제안서를 보내 드리며, 간단하게 소개를 해봅니다. 검토 후 답장을 바랍니다.^{참고 1)}

두 번째 단락은 주제에 대한 설명을 쓴다.

저는 기술 전문 서적이 아니라면 한 달에 책을 여섯 권 읽습니다. 가끔 다른 일이 생겨 느리게 읽는 경우도 있으니 일주일에 한 권이 안정감 있는 양이며, 서평을 쓰면 주요 온라인 서점에서 추천 서평으로 뽑힙니다. 또한, 매주 토요일에 모여 책을 읽는 독서 모임도 운영하고 있어 후원 효과도 높일 여지가 있습니다.

세 번째 단락에선 전자우편을 마무리한다.

보다 자세한 내용은 첨부한 문서에 있습니다. 그럼 답장을 부탁하며, 좋은 하루 보내세요.

상황을 가상으로 만든데다 다소 딱딱한 내용이라서 어색하기 그지없다. -_-;

이런 구조가 정답은 아니다. 전자우편은 종이편지보다 소통/교류 빈도가 높기 때문에, 더 간단하게 쓸 수도 있다. 더욱이 잘 받았다는 식으로 확인 통보를 하는 것이라면 한 문장으로도 본문을 쓸 수 있다. 심지어 제목에 할 말을 다 썼으니 본문은 쓰지 않는, 일명 “냉무(내용없음)” 신공을 발휘하기도 한다. 같은 조직 안에서 소통 효율이 중시될 때 보통 그렇다.

다만, 중요한 것은 본론이나 목적, 주제를 앞에(위에) 쓰느 게 좋다는 건 변치 않는다.

본문 글꼴

본문 글꼴은 컴퓨터 모니터에서 깔끔하게 보이는 것이 좋다. 가장 흔히 쓰이는 글꼴은 굴림체이며, 영문 전자우편이라면 Arial 이나 Sans serif 를 많이 쓴다고 한다. 크기는 10~12 픽셀이/포인트를 권장하는데, 전자우편 도구나 서비스마다 단위가 다르다. 그냥 마음 편하게 전자우편 서비스나 도구에서 기본으로 제공하는 글씨 크기라고 보면 된다.

가끔 필기체 느낌이 나거나 바탕체, 궁서체 같은 글꼴을 쓰는 사람이 있는데, 이런 글꼴들은 컴퓨터 모니터에서 읽기 안좋으므로 안쓰는 게 낫다. 물론, 종이로 인쇄해보면 괜찮은 글꼴이지만, 사람들 대다수는 전자우편을 일일이 종이로 인쇄해서 읽지 않는다.

영문 전자우편을 쓸 때 주의해야 할 점은 강조 표시이다.

• 굵게 표시
• 색깔(보통은 빨간색)
• 대문자

영문에서 강조를 할 때는 위와 같은 방법으로 쓴다. 근데 말을 아주 강조한답시고 위 세 개 중 몇 개를 조합하는 경우가 있는데, 영문권 사람들이 이런 강조 표시를 보면 “아, 대단히 중요한가 보구나”라고 생각하기 보다는 “뭐, 이런 무례한 사람이 있담? 어디다 대고 고함질이야” 라고 생각한다고 한다. 귀에다 “중요한 말이니까 귀 열고 내 말 좀 처들으라고!!!!!!!!!!!!!” 라고 외치는 것과 같다고 한다. 그러니 위 세 개 중 하나만으로 강조하는 것이 좋다.

수신자, 참조, 숨은참조

의외로 수신자(TO), 참조(CC), 숨은참조(BCC)를 잘 모르는 사람이 많다.

수신자(to)는 이름 그대로 내가 전자우편을 보내려는 대상, 즉 꼭 읽어야 하는 사람이다.

참조(CC : Carbon Copy)는 전자우편을 참조해서 받을 대상이다.

숨은참조(BCC : Blind Carbon Copy)는 참조자로 전자우편을 받되, 수신자와 참조자들은 알 수 없게 감추는 것이다.

예를 들어 총무팀 중 사무용품 구매 담당자에게 사무용품 구매를 물어본다고 하자. 이 경우, 수신자는 구매 담당자이다. 그리고 총무팀 팀장도 이 사실을 알아야 한다면 참조자로 넣는다. 총무팀장에게 물어보는 것이라면 그도 수신자로 넣어야겠지만, 그게 아니라면 참조자로 넣는다. 그런데 구매 담당자와 총무팀장이 자꾸 내 전자우편을 못본 척 무시하기 일쑤이다. 그래서 우리 팀장이 이 상황을 몰래 지켜볼 수 있게 하고 싶다면, 우리 팀장을 숨은참조(BCC)에 넣는다. 보낸이와 수신자와 참조자는 받은 전자우편 내용에 그 전자우편을 받는 사람들이 나타나지만, 숨은참조자는 이들에게 나타나지 않는다.

예전에 공동구매를 진행한 적이 있는데, 공동구매 참여자들은 무슨 이유에서인지 자신을 드러내지 않기를 바랐다. 그래서 공동구매 공지 전자우편을 보낼 때 수신자는 나 자신으로 하고, 공동구매 참여자들은 전부 숨은참조로 해서 보냈다. 이러면 전자우편 받는 사람은 나만 나타나기 때문에 익명이 보장된다. (뭐 이상한 걸 공동구매한 것도 아니었다. -_-; )

답장과 전체답장, 전달

답장은 전자우편을 보낸 사람에게만 답장 전자우편을 보내는 것이다. 전체답장은 해당 전자우편을 받는 모든 사람, 그러니까 수신자(to), 참조자(CC) 모두에게 답장을 하는 것이다. 숨은참조자는 받지 않는다.

답장을 하면 대체로 제목 글머리에 Re 라는 낱말이 붙는다. Re: 나 [Re:] 이런 식이다.인데, 이는 Reply 를 줄인 말로써Reply 줄임말로 알려져 있는데 실제로는 그렇지 않다고 한다^{참고 1)}. 보통은 전자우편 답장을 나타내는 관례로 쓴다.

업무로 전자우편을 주고 받을 때는 대체로 “전체답장”을 누를 때가 많다. 그래서 수신자와 참조자가 명확하게 드러나지 않아서 받는 사람은 자신한테 보낸 것인지, 참조하라고 보낸 것인지 혼란을 줄 수 있다. 어떤 사람은 자신을 수신자로 넣은 전자우편 위주로 읽기도 하는데, 무심코 전체답장을 눌러서 전자우편을 받아야 할 사람이 읽지 않고 놓치는 경우가 생기기도 한다(실제 겪은 일이다). 그러므로 전체답장으로 전자우편을 보낼 때 수신자와 참조자를 구분해주는 것이 좋다.

하지만 사람들 대부분은 수신자와 참조자를 구분하지 않고, 그냥 “전체답장” 단추를 눌러 전자우편을 보낸다. 사실 나도 그렇다. 그러므로 전자우편 본문에 수신자와 참조자를 따로 언급해주면 좋다.

• 필독 : 한날, 개똥이
• 참조 : 아니마

이런 식으로 말이다.

전달(Forward)은 말 그대로 보냈거나 받은 전자우편을 다른 이에게 그대로 전달(Forward)하는 것이다. 전달하는 전자우편은 그 본문이 인용문처럼 들어가며, 글머리엔 Fwd: 라는 낱말이 들어간다.

요즘 취미삼아 장난감을 만들고 있다. 이번 주 안에 끝내려는 건 책 장난감이다. 좀 더 거창한 장난감, 그러니까 서비스였는데 역량과 준비 부족을 느끼며 장난감으로 격하(?)시켰다. 필통이라는 훌륭한 방향성을 가진 서비스에서 제공하는 책읽기 서비스와 좀 비슷하다. 책을 읽으며 쌓는 적바림들을 컴퓨터로 관리하려고 시작한 이 기획을 어느 덧 3년 동안 묵혀왔는데, 이제는 도저히 참을 수 없는 상황에 이르러서 칼을 빼어든 것이다(칼 뺀지 반 년 돼간다…).

이미 비슷한 서비스가 있는데 굳이 직접 만들어서 고생할 필요 있나 생각이 들기도 하지만, 내 기획을 또 한 해 넘겨 묵히며 죽일 순 없다는 오기도 들어서 만들지 않을 수가 없더라. 지향점이 저 서비스와 다른 점도 큰 이유이다. 내가 만들고자 하는 건 “책 많이 읽는 도서관 사서 같은 서비스”이기 때문이다.

어쨌든 만들고 있다. 작동 환경은 웹이다. 파이썬용 웹 프레임워크인 django 로 뒷단(back-end)을 만들고 있으며, XHTML 1.0과 CSS, 그리고 javascript 로 앞단(front-end)을 만들고 있다. 일부 있어보이는 조작 체계(Rich Interface ? 하하)는 javascript 로 처리하는데 이를 jQuery에 맡겼다. 책 정보는 Aladdin (알라딘)에서 제공하는 검색 Open API를 이용하고 있다.

파이썬과 django

django 는 아직도 우리나라에 쓰는 사람이 많지 않다. 관련 자료도 적다. 얼마 전에 연재를 마친 날로 먹는 Django 웹 프로그래밍 강좌는 여러 모로 많이 부족한데도 이 강좌가 그나마 볼만한 문서처럼 되고 있는 실정이다. ㅜㅜ 물론 영문 자료는 참 많지만, 아무래도 부담이 가는 것은 사실이다.

그런 부담을 걷어내면 django 는 정말 훌륭한 웹 프레임워크이다. 현재 배포 중인 안정판인 0.96은 참 불만스럽지만, 곧 정식 발표되는 1.0은 시험판인 지금 것도 꽤 편하고 강력하다. 더욱이 파이썬이라는 언어가 강력하고 매력 있어서 개발이 참으로 즐겁다.

좋은 점 몇 가지를 꼽으라면 관리자(admin) 기능과 모델(model) 기능, 이용자 인증 모듈, 그리고 꽤 작고 직관성 높은 django 구조를 들 수 있다. 관리자 기능, 이용자 인증 모듈은 내가 무척 좋아하는 기능으로 이 둘 덕분에 개발 기간이 크게 줄어들었다. 관리자 기능은 rails(레일스)에서 scaffold 와 비슷한데 그보다 더 실용성 있고 강력하다. 개발 초기부터 개발 완료 후 운영 과정에까지 쓸 수 있다. 이용자 인증 모듈(기능)은 이용자 추가, 관리, 인증 기능을 따로 만들 필요가 없어 좋다. 이게 의외로 손이 가는 부분이라서 이용자 인증부를 다 만들때까지는 연계되어 돌아가는 다른 부분 개발이 난감할 수 있는데, django 에서 제공하는 이용자 인증부를 쓰면 바로 적용할 수 있다.

파이썬이 갖는 장점 덕에 django 가 더 좋은 점도 있다. 파이썬은 코드 예외성이 무척 적은 언어이다. 파이썬 언어 철학 자체가 문제를 해결하는 방법은 최소화 하기 때문이다. 그래서 파이썬에서는 같은 일을 하는 코드를 짰을 때, 누가 그 코드를 쓰더라도 대체로 비슷하게 생겼다. 쉽고 간결한 코드, 그리고 문법(들여쓰기 같은 문법 강제성은 종종 귀찮음을 일으키곤 하지만) 덕에 개발 자체가 즐겁다. 고작 15kb 로 알라딘에서 책 정보를 가져와서 DB에 저장, 이용자 인증(로그인 등), 책 검색, 책 소유/읽음/관심 여부를 표시하는 기능들을 예외처리(Exception)까지 해서 만들었다. django 에서 제공하는 편리함도 무시할 순 없지만, 파이썬 언어 자체가 가진 특성이 가장 큰 영향을 미쳤다.

누가 짜더라도 대체로 비슷한 코드가 나오는 코드 예외성이 적은점은 인터넷 검색으로 자료를 찾을 때 매우 좋다. 고수가 짠 소스 코드든 아니든 상관없다. 파이썬으로 문제를 해결하는 방법은 거의 비슷하여 초보자가 공부하고 자리잡기 좋다. 성향이나 취향이 이유겠지만, 난 루비스러운 코드를 짜기 위해 정작 루비 언어 철학을(인간 중심 프로그래밍?) 위배하는 코드들이나, 문제를 해결하는 다양한 방법을 언어 철학으로 삼는 펄(perl)의 암호같은 코드는 초보자가 공부하기에 썩 좋지 않다고 생각한다.

이렇듯 파이썬과 django는 초보자가 다루기에도 좋고 초기 시연판(prototype)을 만들기에도 아주 좋다. 파이썬이라는 언어가 가진 가볍고 간단함, 그리고 django 가 가진 가벼움과 명료함을 버무리면 장난감 만들기 정말 좋은 환경이 탄생한다. 물론 대형 서비스에서도 쓸 수 있겠지만, 내가 그런 서비스를 직접 개발하진 않으니 무어라 말을 할 순 없다. ^^;

jQuery

jQuery는 prototype javascript framework 못지 않게 많은 인기와 사랑을 받고 있는 Javascript framework 이다. 조금 써보니 정말 강력하고 편해서 꽤 많이 만져온 prototype js 로 돌아가고 싶지 않을 지경이다.

jQuery 장점은 강력한 기능이나 성능을 들 수 있다. 기능은 워낙 많은데다 부족하거나 없는 기능은 확장기능(plug ins) 형태로 보충할 수 있다. 손이 많이 들어가는 귀찮은 작업들을 이미 다양한 확장기능으로 만들어 제공하고 있다. 기능이 많으면 덩치가 커서 느리거나 둔하지 않을까 걱정이 될 수도 있지만, jQuery의 많은 부분들이 prototype js 를 성능으로 제치고 있으며, 높은 성능으로 유명한 dojo 나 extjs 와 비교를 해도 크게 뒤처지지 않는다.

뿐만 아니라 jQuery 소스 코드를 보면 주석이 정말 잘 달려 있어서 Javascript 에 깊게 파고 들어 공부할 사람에게도 많은 도움을 준다. 나처럼 의심 많은 사람은 대체 이건 내부에서 어떻게 돌아갈까? 생각을 하며 내부 소스를 들여다 보는데, 친절하게도 코드 대부분에 주석이 달려 있어 조금만 시간을 들이면 흐름을 이해할 수 있다.

일관성 있는 문법도 마음에 든다. prototype js를 보면 어떤 것은 객체여서 생성 할당(instance)을 해야 하고, 어떤 것은 함수라서 바로 실행이 가능하다. 또한, 각 기능부(component)가 별도 객체처럼 나뉘어져 있어서 혹 같은 이름을 쓰는 기능부가 있는 라이브러리를 쓸 경우 충돌을 일으키거나 혹은 이것이 prototype js의 것인지 아닌지 구분하기가 까다롭다. 그에 반해 jQuery 는 jQuery 라는 이름으로 대동단결 되어 있다.

간단히 예를 들자. hannal 이라는 엘레먼트를 마우스로 끌어다 놓을 수 있는 조작(control) 기능을 제공한다고 치자(prototype js 와 jquery 둘다 그런 기능을 제공하는 확장기능을 써야 한다). prototype 은

new Draggable(’hannal’);

이런 식이다. jquery는

$(’#hannal’).draggable();

이렇다. 기능부 쪼개는 장점을 이해 못하는 것은 아니나, 어떤 일을 하려는 대상인 객체(object)를 기준으로 코드를 구현하는 jQuery의 문법이나 코드가 좀 더 일관성 있다.

아쉬운 점은 자료 대다수가 영문이라는 점이다. jquery.com 에서 제공하는 문서들과 예제들이 워낙 잘 되어 있어서 굳이 강좌같은 연재글이 아니더라도 쓰는 데 불편함은 없지만, 기본부터 차근 차근 익히고 싶은 사람에겐 우리말/글 자료가 별로 없는 점은 아쉽다. 하지만 최근에 인사이트 출판사에서 jQuery in Action 번역서를 출간해서, 가뭄에 단비를 내려주고 있다. jQuery를 쓰고 싶은데 영어가 부담되던 이라면 꼭 이 책을 사서 접하길 권한다.

두 번째 아쉬운 점은 장점이기도 한데, 상당히 빠른 판올림을 들 수 있다. 빠른 판올림 때문에 예전에 코드가 문제를 일으킬 가능성이 좀 있다. 실 예를 들면, jQuery in Action 원서는 jQuery 1.2.1판을 기준으로 쓰여져 있는데, 1.2.1판에는 jQuery 선택자(selector)에 contains 라는 메소드(method)가 있지만, jQuery 최신판인 1.2.6판에서는 이것이 메소드가 아닌 필터(filter)가 되어 해당 메소드가 존재하지 않는다. 하지만 번역서에서는 옮긴이께서 보완하셨다고 한다. 만세~

이외 jQuery에 대한 얘기(특히 prototype js와 비교하는 얘기)는 내가 Prototype에서 jQuery로 옮긴 이유라는 글을 보길 권한다. jQuery 특징을 잘 나타내고 있다.

---

예전 같으면 정말 손이 많이 가는데다 성능도 보장되지 않아 지레 포기하던 많은 것들을 요즘엔 django 와 jQuery 를 이용해서 아주 편하고 간편하게, 그것도 어느 정도 성능이 보장되는 환경에서 처리하고 있다. 물론 이 둘이 아니더라도 php 나 ruby 언어를 서버 환경으로, 그리고 dojo 나 prototype js 등을 클라이언트 환경으로 하여 성능과 편리함을 취할 수 있다.

이들 모두 개성있는 좋은 도구들이다. 하지만 이런 저런 장난감을 다양한 도구로(php(cakephp), ruby(rails), python(django, turbogears), prototype js, yui, jQuery) 만들어보고 만져본 느낌은 나한텐 역시 django 와 jQuery 가 짱이라는 것이다. ^^

덧쓰기 : 당연한 말이지만 이는 어디까지나 개인 성향과 취향에 따라 다르다.