Haru's scribblings

아니! 여러분들은 개발자라니깐요.

(Haru) — Fri, 10 Nov 2006 13:43:35 +0900

아니! 여러분들은 개발자라니깐요.

작성자 : Lancers(안 재우)

데브피아와 같은 커뮤니티에서 왕성하게 활동하던 시절에 비하면 훨씬 적긴 합니다만, 지금도 가끔 이런저런 질문을 받기도 합니다. 전혀 모르는 사람으로부터 메일이 올 때도 있고, 지인(혹은 실수로 가르쳐준 OTL)으로부터 메신저로 물어볼 때도 있고, 아주 가끔은 전화로 물어보는 사람들도 있습니다.
옛날에는 바쁘다는 핑계로 씹어버리기도 했습니다. 저한테 메일을 보냈는데 답을 받지 못하셨던 분들에게는 이 자리를 빌어 죄송하다는 말씀을 드립니다.

그런데 말이죠..(자, 변명과 핑계의 시작입니다. ^^)

바빠서 그런 경우는 있지만, 그런 질문들 중 일부는 답을 할 수 없거나 답을 해주고 싶지 않아서 그런 경우도 많습니다. 이번 글은 일부 개발자들(적어도 자기는 개발자라고 주장하는 사람들)의 잘못된 질문 습관을 지적해보도록 하겠습니다.

more..

얘기를 풀어나가기 위해 한가지 비유를 들어보도록 하겠습니다.
마침 제가 아침에 출근할 때 보니, 주차장 옆 차에 실내등이 켜져 있더군요. 운전자가 끄는 걸 깜빡하고 내린 거겠죠? 요걸 보고 이번 글을 설명할 아이디어가 떠올랐습니다. ^^

2년 차 운전자 A씨의 이야기
이 차는 차를 운전한지 2년 차 된 A씨 소유입니다. A씨는 운전은 하지만 사실 차에 대해서는 잘 모릅니다. (음.. 예전 모 CF의 광고문구네요.) A씨는 작년에 타던 중고차를 처분하고 이번에 M 사의 최신 자동차를 구입했습니다. 남들이 하는 걸 보니 멋져 보여서 차에 사제 HID도 달고, 오디오 튜닝도 했습니다.
다음 날 A씨는 급한 약속이 있어서 가족과 함께 어딘가로 가기 위해 차의 시동을 걸어봅니다. 어라? 멀쩡하던 차가 시동이 안 걸립니다. 몇 번 시동을 걸어보다가 자기 나름대로는 보닛도 열어봤습니다만 도대체 뭐가 뭔지, 시동이 왜 안 걸리는지 하나도 모르겠습니다. 아내는 바쁜데 이게 뭐냐고 구박하고, 애는 덥다고 에어컨 틀어달라고 빽빽 울어대기 시작했습니다. 나름 유명회사의 최신 자동차를 비싸게 주고 샀는데 차가 말썽이 생기니 짜증이 이만 저만 나는 게 아닙니다.
일단 보험회사에 전화를 했는데 긴급출동 서비스 제공 대상 고객이 아니랍니다. 기억을 더듬어 보니, 보험 가입 첫해인 작년에는 긴급출동 서비스를 가입했었는데 올해 자동차 보험을 갱신하면서 어차피 잘 안 쓰는 거 같아서 보험료 아낀다고 긴급출동 서비스를 빼버렸던 게 기억이 납니다.
일반 카센터에 전화를 할까 했지만, 돈이 많이 들어갈 것 같아서 무섭습니다. 어찌할까 발을 동동 구르다가 문득 근처에 사는 아는 후배 중에 자동차에 대해 좀 아는 B가 있다는 것이 기억이 나서 전화를 합니다.

A씨 : "야, B! 나 지금 되게 급한데 차가 시동이 안 걸려. 빨리 와서 좀 해결해줘!"
B씨 : "예? 음.. 제가 지금 바로는 안되고 30분 내로는 갈 수 있습니다만.."
A씨 : "아씨, 급하다니깐! 빨리 와!"
B씨 : "... 네.. 알겠습니다."

결국 불쌍한 후배 B가 바로 달려왔습니다.

B씨 : "어디가 문제죠?"
A씨 : "몰라, 어제까지 되던 놈이 안되네. 빨랑 시동 좀 걸어봐!"

잠시 후 B는 배터리가 방전되었다는 것을 찾아냅니다.

B씨 : "배터리 방전이네요."
A씨 : "그래서? 어떻게 해야 되는데?"
B씨 : "다른 차랑 점프 케이블로 연결하면 시동이 걸릴 겁니다."
A씨 : "그래? 그게 어딨어?"
B씨 : "일단 제 차에 있습니다. 앞으로 또 이런 일이 있을지 모르니 선배님도 하나 구입하시고, 어떻게 하는지도 한번 보시죠."
A씨 : "난 그런 거 몰라. 그냥 자네가 해결해줘."
B씨 : "..."

결국 B씨가 혼자 점핑을 해서 시동을 걸어줍니다.

A씨 : "아, 드디어 걸렸네!"
B씨 : "선배님 그런데 이 차 말입니다. 아무래도 전기장치가 좀 불안한 거 같은데요. 특별한 증상 같은 거 없으셨나요?"
A씨 : "아아, 나중에 얘기하자구. 내가 급해서~"

A씨는 서둘러 가족들을 태우고 떠납니다.

가족들과 볼 일을 마친 A씨는 또다시 시동이 걸리지 않는 것을 발견합니다.
또다시 B에게 전화를 했지만 이번에는 B가 전화를 받지 않습니다.
결국 A씨는 카센터에 전화를 했고, 출장 기사가 왔습니다.
그런데 이번에는 점핑으로도 시동이 걸리지 않아서 결국 견인을 하게 됩니다.
카센터에서 점검 결과 배터리가 완전히 나가 버렸다고 합니다.
문제는 아무래도 불법으로 장착한 사제 HID와 오디오 때문인 것 같습니다.
결국 A씨는 견인비와 배터리값으로 많은 돈을 지출하게 됩니다.
그리고 마음 속으로 다시는 M사의 자동차는 사지 않겠다고 굳은 결심을 합니다.

A씨의 이야기에 담긴 것은?
A씨 얘기를 읽으면서 재밌으셨습니까? 여기에 숨겨져 있는 A씨와 일부 개발자들의 공통점을 짚어내 보도록 하겠습니다.

1. 과정보다는 결과를 중요시한다.
A씨는 시동이 걸리지 않은 원인, 시동이 걸리지 않는 문제를 조치하는 과정에는 전혀 관심없이 빨리 차를 몰고 약속장소로 가야 한다는 결과에만 집착했습니다.
이렇듯 질문의 상당 부분들은 ‘문제에 대한 해결 요청’인 경우가 많습니다. 일단 문제는 터져 있는 상황이고, 빨리 해결 못하면 위에서 쪼아댈테고.. 그러다 보니 문제를 최대한 빨리 해결하는 것에 관심이 있지, 문제가 발생하는 원인이 무엇이며 그 원인을 제거하거나 회피하기 위해서 어떤 과정을 거쳐서 처리해야 한다는 것에는 관심이 없습니다.

2. 문제가 발생하는 것에는 항상 계기가 있다.
뭔가 문제가 발생해서 오는 질문들 중에 가장 황당한 질문은 "어제까지는 됐는데, 갑자기 오늘 아침부터 갑자기 안 됩니다. 어떻게 해야 되나요?"라는 것입니다. 흠, 컴퓨터나 소프트웨어가 갑자기 오늘부터 삐진 걸까요? ^^
아니 땐 굴뚝에 연기가 날 일이 없듯이, 어제와 오늘 사이에는 분명히 무슨 일이 있었던 것입니다. 문제는 그 일들에 대해 대수롭지 않게 생각하고 난 아무것도 손댄 것 없다고 주장해버린다는 것입니다.
예전 고객 사이트들에서 실제로 이러한 질문들이 있었습니다. 멀쩡하게 잘 돌아가던 프로그램이 있고 손댄 것도 아무것도 없는데 오늘 아침부터 안 된다는 것입니다. 어제와 오늘 사이에 다른 작업을 한 것이 없냐고 물어도 절대 없다고 시치미를 떼었기에 문제를 찾는데는 상당한 시간이 소요되었습니다. 결국 찾아낸 문제의 원인은 그 전날 퇴근하면서 설치한 XP 서비스팩 2 때문이었습니다.

3. 문제에 대해 충분히 설명을 하지 않는다.
"우리 사이트에서 갑자기 결제 오류가 나는데 어떻게 해야 되나요?"
실제로 달랑 이 한 줄을 메일로 보내고 해결해달라고 하시는 분이 계셨습니다. 저를 전지전능한 신으로 착각하시나 봅니다. -_-;;
문제가 있을 때는 문제가 발생하는 상황에 대해서 정확하게 기술해야 합니다. 또한 여러분은 일반 사용자가 아닌 개발자입니다. ‘갑자기 결제 오류가 나는데 해결해 달라’는 질문은 일반 사용자가 하는 질문이지, 개발자가 하는 질문이 아닙니다. 기본적으로 개발자는 발생하는 오류에 대한 정보를 수집하기 위해 최선을 다해야 합니다. 다음은 개발자가 수집해야 할 최소한의 정보라고 생각되는 것을 나열한 것입니다.

- 정확한 오류 메시지의 내용은 무엇인가?
- 오류가 발생되는 것으로 추정되는 소스 코드 위치는 어디인가?
- 이 오류를 발생시키기 위한 상황은 무엇인가? 오류를 재현하려면 어떻게 해야 하는가?
- 이 오류가 특정 컴퓨터/서버/네트워크 위치에서만 발생하는가?
- 정상적으로 작동하던 때와 오류가 발생하는 시점 사이에 변경된 것은 무엇인가?

4. 문제를 해결하기 위한 스스로의 노력
적어도 개발자라면 문제가 있거나 과제가 주어졌다면 그것을 해결하기 위해 자기 스스로 최대한 노력을 해야 합니다. 물론 남이 해결해 주는 게 시간 상으로는 더 단축이 될 수도 있겠지만, 적어도 자기가 직접 노력을 해보고 나서 해봐야 하지 않을까요?
상당수의 질문들은 도움말을 몇 분만 찾아보면 얻을 수 있는데다가, 인터넷이 발달한 요즘처럼 좋은 세상에는 네이버 지식인과 구글 검색만으로도 상당수의 답을 얻을 수 있습니다. 옛날에는 모든 해답이 MSDN에 다 있었지만, 요즘은 구글에 다 있더군요. 애인이랑 식사할 맛있는 스파게티 전문점을 검색하는데는 자신의 시간을 투자하면서 문제를 해결하기 위해 자료를 검색하는 건 왜 스스로 하지 않나 모르겠습니다. 구글에서 5분이면 찾을 수 있는 것을 물어볼 때, 나 귀찮으니깐 니가 대신 검색해서 내놔라 라는 말 밖에 되지 않습니다.
또한 많은 개발자들이 문제가 발생했을 때 디버깅조차 제대로 해보지 않는 경우가 많습니다(특히 웹 개발자들의 경우). 디버깅을 해보면서 조금만 추적해보면 금새 답이 나오는데, 전체 코드도 아닌 쪼가리 코드만을 주고 해답을 찾아내라고 던지시더군요. 그때마다 제 머리 속에서는 코드 텍스트를 머리 속에서 컴파일해가면서 실시간 디버깅(?)을 해야 합니다. 제발 디버깅 한번이라도 해보세요!

5. 적절한 사람에게 적합한 질문을 하라.
역시 제가 받은 황당한 질문 시리즈 중 하나는 비주얼 스튜디오 좀 주시거나 구할 수 있는(구매한다는 의미가 아니죠?) 곳을 알려 달라는 것입니다. 아, 그보다 더 황당한 것도 있습니다. 어떤 분은 비주얼 스튜디오 싸게 살 수 있는 방법이 없냐고 물어보시더구요. -_-;; 비주얼 스튜디오 설치하다가 CD가 에러가 난다는 분들도 계시고... 심지어 몇번째 장이 에러나는데 그거 하나만 구워서 보내줄 수 있냐고..
저는 MS 소프트웨어 판매 유통업에 종사하고 있지도 않고, MS 기술지원부서에 근무하고 있지도 않습니다. 제품은 소프트웨어 판매하는 곳에서 구매하시면 되고, 돈이 없으시면 알아서 능력껏 어둠의 경로에서 구하세요. 그리고 제품 설치에 대한 질문은 MS 기술지원부서에다 하셔야지 왜 저한테 하시는지.. (불법사용자라서 그럴까요? -_-;;)
어떤 분은 SQL 서버에서 데이터 마이닝을 하는 방법에 대해서 저한테 물어보시더구요. 안타깝게도 저는 DB 전문가가 아니랍니다. 답을 해드리고 싶어도 몰라서 못해드린답니다.

6. 멋도 모르면서 남들이 좋다고 하면 다 따라서 한다.
일단 개발자라고 하면 비주얼 스튜디오는 깔아야 한다고 생각하는 분들이 많더군요. 또 깔아도 항상 최상위 버전(2005의 경우 Team Suite)를 깔아두시더라고요.
개발 툴이나 기술이 일단 남들이 하는 거면 그것이 자기한테 적합한지, 자신이 하고자 하는 것에 맞는지 살펴보지도 않고 무조건 다 따라 하는 사람들이 있습니다. 정확한 목적의식없이 할려니 의욕도 안 생기고 헤매기 십상입니다.
사실 개발자라는 직업 자체가 그렇습니다. IT 열풍과 미친 정부 덕에 IT 인력을 양산해 냈지만, 개발자는 단순히 밥벌이를 위해서라면 참으로 힘들고 괴로운 직업이거든요. 먹고 사는 게 목적이라면 이것 말고 다른 방법을 얼른 찾아보시는 게 빠를 겁니다.

7. 문제가 생기면 남 탓부터 한다.
요즘 작업을 하다 보면 개발자 혼자 원맨쇼로 작업을 하는 게 아니라 여러 명이 공동 작업을 하는 경우가 많습니다. 그러다 보면 남이 짠 소스나 모듈을 가져다 붙여서 작업을 해야 하는 경우가 많은데, 문제가 생기면 정확한 문제의 원인이 무엇인지 찾아서 해결하는 게 아니라 이 문제가 나 때문에 발생한 게 아니라는 걸 찾아내는데 주력하는 사람들이 있습니다. 거참, 당신 잘못이 아니라 다른 사람 잘못이라는 걸로 판명 낸다고 해서 문제가 해결되나요? 일단 문제를 해결해놓고 범인이 누군지 찾는 건 나중에 해야죠.
저희 회사가 하는 일이 개발 프레임워크와 같은 공통 모듈을 만드는 작업을 많이 하다 보니 이러한 일을 부지기수로 겪습니다. 개발 프레임워크를 가져다 개발하면서 문제가 생기기만 하면 프레임워크 탓으로 돌리더군요.
모 사이트에서 작업하면서 O사의 컴포넌트를 가져다 사용한 적이 있었습니다. 저희 쪽에서는 그 컴포넌트를 좀 더 쓰기 쉽게 래핑해서 개발 프레임워크 내에 집어넣었습니다. 그런데 사용하다 보면서 갑자기 문제가 발생했습니다. 발생한 시점은 O사의 컴포넌트를 최신 버전으로 교체하고 난 이후였고, 열심히 디버깅해본 결과 최종적인 오류는 O사의 컴포넌트 내부에서 발생하는 것으로 판명되었습니다. 당장 이전 버전으로 롤백을 하면 문제는 없겠지만, 최신 버전에 포함되어 있는 기능이 필요하기에 당장 결정할 수는 없는 상황이었습니다. 그래서 문제를 O사에 문의했습니다. 유사한 문제가 발생한 적 있는지, 아니면 이를 수정할 수 있는 방안이 있는지. 워낙 급한 문제라서 바로 긴급 기술지원을 요청했고, O사 엔지니어가 왔더군요. 이 엔지니어는 오자마자 시스템이나 코드는 열어보지도 않고 무조건 절대 자기 회사 컴포넌트에서 문제가 발생할리가 없다고 주장하더군요. 일단 보기라도 하고 말하라고 했더니 잠시 살펴본 후에 이번에는 래핑하는 프레임워크 코드가 잘못 되었다고 주장하더군요. 프레임워크 안의 코드는 그들이 제공하는 예제 코드를 그대로 가져다 쓴 것이었습니다. O사 엔지니어는 자신들이 제공하는 예제를 돌리면 문제가 없으며 너희가 분명히 어딘가 코딩을 잘못 했을거다라고 하더군요. 그래서 아예 그럼 당신이 직접 그 예제를 가지고 돌려보라고 했습니다. 도대체 뭘 하는지 모르겠지만 몇 시간을 예제 가지고 끙끙대고 있더군요.
그러다 엔지니어가 온지 무려 6시간 만에 자기들 컴포넌트의 문제인 것 같다고 시인하더군요. 우리가 원하는 건 문제의 해결이지 누구 잘못인지를 따지는 것이 아닌데, 자기들 문제라고 시인하는데 무려 6시간이 소요되었습니다. 그래서 디버깅을 통해 빨리 문제를 분석하고 해결해줄 수 있냐고 했더니 한번 알아보겠답니다. 언제까지 해결하겠다는 것도 아니고 알아보겠다니, 정말 미치는 노릇이죠!
결국 이 사람을 믿느니 직접 찾아보는게 낫겠다고 싶어서 열심히 인터넷을 검색한 결과 유사한 문제를 여러 건 찾아냈고, 당장 해결되는 버전은 없지만 이를 피하기 위한 Workaround가 있다는 것을 알아냈습니다.
교통사고 부상자가 있을 때 부상자를 구호하는 게 우선이지 누가 가해자고 누가 피해자를 따지는 게 중요한 게 아닌 것과 똑같습니다.

8. 별거 아닌 습관 속에서 문제가 발생할 수도 있다.
A씨가 차에서 내리기 전에 실내등을 껐는지만 확인했다면 당장 시동이 걸리지 않는 문제는 없었을 겁니다(아, 물론 근본적인 원인일 수 있는 불법 튜닝은 빼고). 이와 같이 개발자의 사소한 습관 때문에 엄청난 문제가 야기될 수 있습니다.
예를 들어 저는 while 루프를 작성할 때는 가장 먼저 루프를 탈출하는 코드부터 작성합니다. 깜빡하고 빼먹어서 자칫 잘못하면 무한 루프가 되어 버릴 경우가 있기 때문이죠.
실제로 모 사이트에서 이런 일을 본 적이 있습니다. 개발자들이 중구난방으로 쓰던 코드를 통합 모듈로 작성해주고, 통합 모듈을 사용하도록 기존 코드를 수정하라고 했습니다. 수정하는데 시간은 좀 걸리지만 문제점을 격리시킬 수 있으니까요. 그런데 개발자 한 명 중에 유난히 이 작업을 귀찮아 하는 사람이 있었습니다. 공교롭게도 통합 모듈을 적용해서 사이트를 돌렸는데, 갑자기 웹 서버의 CPU가 100%을 치면서 사이트가 죽었다가 살아나는 현상이 생기더군요. 불평이 많던 개발자가 바로 통합 모듈 때문이라면서 온갖 비난을 쏟아내더군요. 한참 문제를 찾아본 결과 특정 페이지에서 특정 조건 시에만 문제가 발생한다는 것을 찾아냈습니다. 열심히 코드를 디버깅 해본 결과, while 루프에 탈출문이 없어서 무한 루프를 돌고 있더군요. 어처구니 없게도 이 코드를 작성한 개발자는 불만이 가장 많고 문제가 생기자마자 목청껏 떠들던 바로 그 개발자였습니다. 참 민망했겠죠? ^^

9. 문제는 예방하는 것이 최선이지만, 소를 잃더라도 외양간을 고치자.
어쩌면 A씨가 긴급출동서비스만 넣어두었다면 좀 더 시간과 비용을 절약할 수 있었을 겁니다. 또한 점프 케이블을 준비해두고 점핑하는 방법을 알았다면 좀 더 나았겠죠.
사전에 문제를 예측해서 예방하고, 문제가 발생했을 때 이를 최대한 빨리 해결하는 방법을 수립해두는 것은 중요합니다. 또한 문제 해결 방법을 알고 나면 다음에 동일한(혹은 유사한) 문제가 발생했을 때 스스로 대처할 수 있도록 숙달해두는 것 역시 중요합니다.
저는 한 번 물어본 질문을 다시 물어보는 사람을 참 싫어합니다.

10. 그래도 가장 중요한 것은 사람으로서의 예의이다.
위의 사례에서 보면 A씨는 자기의 문제를 해결하는데 급급해서 상대방의 입장을 전혀 고려해보지 않는 무례한 행동을 많이 합니다. B씨 입장에서는 앞으로 A씨를 대하는 것이 절대 예전처럼은 되지 않을 겁니다.
질문 메일을 받다 보면 이처럼 다짜고짜 용건만 말하고 빨리 답을 달라고 강요하는 사람들이 있습니다. 이런 경우, 참 답을 주기 싫지요. 답을 줘도 고맙다는 얘기를 듣는 건 하늘에 별 따기입니다.
고객 센터에 질문하는 것도 아니고, 누군가에 도움을 요청할 때는 자신이 누구인지를 밝히면서 양해를 구하고 이러한 상황인데 도와주시면 감사하겠다고 정중하게 말하는 것이 최소한의 예의가 아닐까 합니다. 이런 메일이라면 최소한 도와주지 못하더라도 답장은 쓰게 되더라구요.
예전에 어떤 분은 제가 7년 전에 어딘가에 올려둔 소스를 보고 나서, "님이 올린 소스 잘 봤는데, 내가 이런 이런 기능이 필요한데 추가해서 빨리 보내주세요."라고 딱 한 줄을 보내오셨습니다. 제가 답을 했을까요? ^^
마찬가지로 맞춤법, 띄어쓰기도 엉망이고, 어법에도 맞지 않는 글을 보내오는 경우도 그렇습니다.

맺으며
여러분들께서는 어떠십니까? 무엇보다 여러분들은 일반 사용자가 아니라 개발자라는 점을 잊지 마세요.

* 본문의 작성자인 안재우님은 현재 닷넷엑스퍼트의 책임 컨설턴트로 근무하고 있으며, .NET 아키텍처 및 컨설팅과 관련한 일을 하고 있다고 한다.

* 블로그 출처 : http://sosobox.com/267

정말 고개를 끄덕이게 한다...적어도 나에게는...
고마운 글이다. =)

가을 바람, 낙엽, 가을 빛...으로 가는 길

(Haru) — Thu, 09 Nov 2006 20:46:00 +0900

more..

로모 첫 롤, 첫 현상...첫 스캔

(Haru) — Tue, 07 Nov 2006 21:14:54 +0900

more..

그냥 마구 잡이로 회사 주변을 돌아 다니면서 찍어봤다.
첫 롤을 찍으면서 느낀것들...

지이익~지이익~ 필름 감는 소리가 즐겁다~! >_<
뷰파인더가 너무 작다...-_-
(현상한 후)에게? 사진의 중심은 어디에? ㅡ_-;;
거리조절 완전 어렵네...가까이에서 찍으면 안되는 기계구나...쩝.
오..수전증도 없는 내가 흔들리는 사진이...;
모든 사진이 'like a LOMO' 가 되는 것은 아니였구나...ㅡㅠㅡ
그래도 재미있다. =)

- Lomo LC-a, Fuji X-Tra 400, Epson 4490

EPSON PERPECTION 4490 PHOTO (필름 평판 스캐너)

(Haru) — Tue, 07 Nov 2006 18:51:47 +0900

필름 카메라를 사면 스캐너는 꼭 사리라고 마음 먹고 있었다.
무엇보다 필름 관리는 정말 힘들기 때문이다. 디지털 데이터도 날려 먹기 쉽지만 현상된 필름을 관리하기 보단 수월하다.
필름 스캐너는 현상된 네거티브/포지티브 필름을 디지털 이미지와 해주는 장치를 말한다.
필름 카메라에 잼뱅이인지라 '로모'로 인해 여러가지 공부가 됐다.

필름이란

(1) 필름의 구조
흔히 사용하는 주광용(晝光用, daylight type) 칼라필름은 일반 태양광(6000。K)아래서 사진을 촬영하면 정상적인 컬러 밸런스로 발색하도록 만들어진 필름으로 셀룰로이드 베이스에 색의 3요소인 적감유제(赤感乳劑), 녹감유제(綠感乳劑), 청감유제(靑感乳劑)가 발라져 있다. 여기에 다시 황색 필터 층, 헐레이션(halation)방지층, 보호막 층으로 구성되어 있으며, 두께는 0.3mm 정도다. 한편, 리버설필름(reversal film)은 현상 후에 투명(transparency)양화가 되는 필름으로 황색 발색제(yellow coupler), 적갈색(magenta) 발색제, 청록색(cyan)발색제가 발라져 있으며 현상 도중 제2의 노광(露光)에 의해 화상을 반전(反轉)하도록 되어 있다.
한편 우리가 가장 많이 사용하는 네거티브 필름(negative film)도 구조는 같으나 제2의 노광(露光)을 하지 않고 상층은 노랑, 중간층은 적갈색, 하층은 청록색으로 발색(發色)하게 된다. 불꽃놀이 등을 촬영하는 데 사용하는 인공조명용 필름인 텅스텐 타입(tungsten type) 필름은 색온도가 3200∼3400。K로 맞추어져 있다. 코닥필름의 경우 텅스텐A형(3400。K), 텅스텐B형(3200。K)로 구분되며 이 필름을 주간(晝間)에 사용하게 되면 색 부족으로 파란색으로 나타난다.

(2) 필름의 감광도 film sensitivity
감광도(感光度)란 필름이 빛에 반응하는 속도를 말한다. 가장 일반적인 것은 ISO(international standard organization) 100이다. 이는 ASA(미국공업표준규격) 100과 동일하다. 100보다 수치가 낮으면 저감도 필름(ISO 25, ISO 50, ISO 64)이라 하고 100보다 수치가 큰 중감도 필름(ISO 100, ISO 200), 고감도 필름(ISO 400, ISO 800), 초고감도 필름(ISO 1000, ISO 1600, ISO 3200 등이 있다. 고감도 필름의 사진은 순간 타이밍이 빠른 사진을 찍는 데 유리하며, 플래시(스트로보) 없이 피사체를 찍는데 유리하다. 그러나 고감도 필름은 인화를 했을 때 입자가 거칠어진다. 자동 카메라의 경우 ISO 200의 필름을 사용을 권하는 일이 많은데, 이는 카메라가 작고 가벼워 촬영시 흔들림이 커지는 것을 막는 효과가 있다. 그러나 확대된 사진을 인화하면 화질이 떨어지는 약점이 있다. 그러나 8×10인치 이상으로 확대하지 않는 경우 큰 문제는 없다. 저감도 필름의 사진은 인화했을 때 사진 입자가 곱고 재질감이나 원근감을 표현할 수 있으며, 특히 사진을 확대 인화할 경우 사진입자가 거칠어지는 것을 줄일 수 있다. 따라서 입자가 고운 사진을 얻으려면 필름의 크기가 큰 중형 카메라에 저감도 필름을 사용하여야 한다.

(3) 필름의 종류
필름의 종류는 색의 표현에 따라 흑백필름(black and white film)과 칼라필름(color film)으로 나누며, 포지티브 필름(positive film, reversal film, 일명 슬라이드 필름)과 네거티브 필름(negative film)으로 분류한다. 포지티브 필름은 촬영한 후 영상을 바로 볼 수 있어 양화(陽畵) 필름이라고 하며, 네거티브 필름은 상이 거꾸로 나타나므로 음화(陰畵)라고 한다. 음화는 사진의 상태를 파악하기 곤란하다. 우리가 가장 많이 접하는 필름은 ISO 100의 네거티브 필름이며, 환등기를 통해서 보는 필름은 포지티브 필름이다.

(4) 포지티브 필름과 환등기
슬라이드 필름은 네거티브 필름보다 고가이고, 인화(프린트)비도 비싸다. 그러나 슬라이드 필름은 네거티브 필름보다 색입자가 치밀하여 사진을 인화하면 색재현력이 우수하다. 또한 필름을 현상했을 때 촬영자가 직접 사진 상태를 확인할 수 있는 장점이 있고, 네거티브 필름에 비해 장기보관(약 50년)이 가능하며, 환등기(slide projector)에 필름을 넣어 비추어 볼 수 있는 장점이 있다. 물론 네거티브 사진도 슬라이드 필름으로 제작할 수는 있다. 이 경우 화질은 떨어진다. 포지티브 필름은 네가필름보다도 적정한 노출이 필요하다. 참고로 네거티브 필름은 ± 1 stop(조리개 한칸) 이상의 경우도 조절할 수 있으나 포지티브 필름은 반(半) 스톱만 조절할 수 있다. 따라서 적절할 노출의 사진을 얻으려면 ±을 가감하여 2, 3장의 사진을 사진을 촬영하는 수고가 필요하다. 또한 환등기에 필름을 넣어 교육용으로 사용하려 하거나 감상하려면 가로사진이 조작상 유리하다.

(5) 필름 패키지 정보
필름의 포장지에는 필름에 관한 몇 가지 정보가 적혀있다. 따라서 필름에 적힌 상품명, 현상요금이 인화가격에 포함되었는지의 여부, 인화용·슬라이드용 또는 흑백·칼라용의 구분, 촬영커트수, 유효사용기간, 바코드와 넘버를 살펴볼 필요가 있다. 특히 유효 사용기간을 꼭 체크해야 한다. 유효사용 기간이 지난 필름을 사용하면 빛바랜 사진으로 인화(프린트)되기 때문이다.

(6) 필름의 보관
카메라와 필름은 고온다습한 환경을 피해서 보관해야 한다. 장기간 사용하지 않고 있는 필름은 완전 밀폐시킨 후 냉동실에 보관하는 것이 바람직하다. 또한 촬영이 끝난 필름은 가능한 빠른 시간 내에 현상해야 한다. 사용한 필름은 사용하지 않은 필름에 비해 변질이 빨라 색재현에 문제가 생긴다. 고감도 필름은 X-ray 검사때 필름이 변질될 수도 있다. 이런 사태를 막으려면 필름을 손에 들고 통관대를 통과하는 것이 바람직하다.

가격은 일반 스캐너에 비해 고가이다.
필름 스캔이 되는 스캐너는 두가지가 있는데, 필름만 전용으로 하는 스캐너와 일반 스캐너에 필름 홀더를 이용해서 필름을 스캔할 수 있는 평판 스캐너가 있다.
필름 전용 스캐너는 뛰어난 이미지 처리와 무엇보다 속도가 빠르다는 장점이 있다. 하지만 나같은 라이트 유저가 사용하기에는 너무 고가이다.(기본적으로 쓸만하다고 평가하는 스캐너가 60만원 이상이다.)

몇가지 알아보고 선택한 것이 엡손의 4490이다.
처음 보면 크기를 보고 앗 소리가 난다. 크다...;
다자인은 나름 깔끔한 모습을 보여 준다.

종류 : 평판형 컬러 이미지 스캐너
문서 크기 : A4, US Letter
광학 해상도 : 4800 DPI x 9600 DPI(with Micro Step)
픽셀/라인 : 122,440 픽셀(광학 해상도 6 lines CCD)
출력 해상도 : 50~6400 DPI, 9600, 12800 DPI
픽셀 깊이 : 외부 16비트/픽셀/컬러, 내부 16비트/픽셀/컬러
스캔 속도 : 흑백 A4 17초, 컬러 A4 16초
필름 스캔 : 포지티브 2400 DPI 41초, 네거티브 2400 DPI 43초
필름 홀더 : 35mm strip film x 12 frames(35미리 필름 1줄 당 6프레임 2줄을 스캔)
35mm mounted film x 4 slide(슬라이드 필름 4장)
120x220 중형 필름 (최고6 x 12 cm) 1장
인터페이스 : USB 2.0
규격 : 272(너비) x 475(깊이) x 113(높이)mm

그리고 엡손의 'Digital ICE' 기능이 저가형 중 지원되는 스캔이다.
'Digital ICE'란 2개의 램프로 2번 스캔하여 필름 표면의 먼지나 흠집을 제거해 주는 기능이다.
'Digital ICE' 기능을 키면 스캔 속도는 몇배로 느려지지만 출력된 결과물은 정말 깨끗해 진다.
포토샵으로 보정하는 것보다 자연스러운 느낌으로 출력을 할 수 있다.

솔직히 속도는 너무 느려서 답답한 편이다. 동일한 해상도록 스캔을 하면 'Digital ICE'기능 을 껐을 때는 10 프레임 스캔 시 15분 이내, 기능을 키면 약 한시간 가량 걸린다.

출력 옵션은 2000 DPI 이상(10x15cm의 엽서사이즈를 출력할 것을 고려해서)으로 'Digital ICE' 기능을 키고 각각의 미리보기 이미지를 보고 수정 후 출력한다.
기본 스캔 프로그램에서 전체 일괄 보정및 옵션 사항 선택은 안되는 것 같다.

다음은 '로모'로 찍은 사진을 현상소에서 스캔 받은 이미지와 간단 비교이다.

Fuji 필름 현상소에서 스캔한 이미지

4490으로 스캔한 이미지

결론 적으로 4490의 스캔한 이미지가 주관적으로는 좋아 보인다. 내가 원하는 색감으로 약간의 색감 조정을 했기 때문인 것 같다. 코엑스 Fuji 필름 현상소에서 스캔 받은 이미지는 왠지 색감이 조금 틀리다. 보정하지 말라고 했는데...

여하튼 스캔 속도와 약간의 소음 빼고는 무척 마음에 든다. =)

The Heart Of Life(John Mayer)

(Haru) — Fri, 03 Nov 2006 14:57:03 +0900

John Mayer(1977년생) 2001년에 데뷔했다. 그냥 나타났다고 한다...
2006년 9월 새앨범이 발표되었다.
아래 곡을 들어 보면 알겠지만 목소리...정말 좋다.(물론 목소리 뿐만아니라 연주, 작곡, 작서 모두 뛰어나다.)
그와 같은 목소리를 가지고 있다면 노래를 누군가에게 더 많은 사람에게 들려 주고 싶은 마음이 간절할 것 같다.
음악은 약간은 컨트리 느낌에 팝정도로 들린다. 편안한 음악이 대부분이며 얼터너티브 적인 음악을 하는 가수이다.
와..이런 목소리의 사람이 옆에서 노래를 불러 준다면 얼마나 행복할지...음악을 들으며...상상해 보세요. =)

The Heart Of Life - John Mayer

Gravity - John Mayer