Heart’s Develop Inside

Post 1.

@ 영국 IT 개발자, 윤모씨와의 인터뷰

국내 회사랑은 회사가 노동자를 대하는 복리후생 자체가 다르다.
출퇴근은 알아서 8시간이고, 일이 밀리면 업무시간을 늘리는 게 아니라 스케쥴을 늘린다.
휴가, 보너스 등등… 뭐 하나 복리후생에서 빠뜨린 게 없다.

유럽 국가들 자체가 ‘노동자들이 살만한’ 나라니까, 어쩌면 그들에게는 당연한 것일지도 모르겠다.
한국? 국가 발전 얘기만 나오면 나오는 얘기가 ‘기업할 만한 나라’ 이니 애초에 비교가 불가능…

음… “영어 공부 어떻게 시작해야되지?”

Post 2.

@ IT 기업들 말 많던데 우리 회사 자랑좀 하겠습니다

음… 그래도 그나마 웹 2.0 회사들 중에는 이런 회사들도 있구나 싶다.
하지만 이 회사를 내 커리어 패스로 잡자… 라고 결심하는 것은 또 다른 이야기…
“그래도 큰 회사나 유명한 회사로…” 라는 머릿속 울림을 거부하기가 쉬운 일은 아닐 것이다.
사람이라면 가질 만한 편견이랄까…

다행히도 몇몇 국내 포털 기업들은 대외 홍보 자료를 보았을 때(물론 그것으로만 판단하기는 좀 그렇지만…) 개발자가 일하기 괜찮은 환경이라고 느껴져서 ‘개발자가 원하는 직장’의 여러 요소를 만족하는 말 그대로 ‘좋은 직장’ 인 것 같다.
물론 그만큼 들어가기 쉽지 않지만…-_-;; 결국 이게 문제인가?

어찌됐던 기업 규모도 크고 이름 알려졌는데 환경도 괜찮은 기업들이 한두군데라도 있으니…
개발자로써 천만다행이다.

한편으로는, 지금 좋은 환경을 자랑하는 벤처 웹 2.0 회사들이 성공가도를 달려서 포털 기업처럼 규모도 커지고, 환경도 좋은 기업들이 많이 늘어났으면 좋겠다.

내가 다시 취직전선에 서는 날에 그런 회사가 몇 군데가 있을지… 기대해 보아야겠다.

나도 리눅스 잘 모르는데, 회사에 나만큼 아는 사람이 없어서(…) 회사 메일 서버를 교체하는 일을 하게 되었다.

기존
메일 서버가 Resource Temporarily Unavailable 을 내뱉으면서 fork를 거부해주는 덕분에 운영 자체가 불가능한
상태였다.(하루를 꼬박 원인을 찾았지만 제대로 된 해결방안도 없고 인터랙티브 스타트업도 안되고 해서 포기…)
다행히도 메일/FTP 서비스는 수행되고 있었다. 다들 관심이 없다보니 가만히 있었으면 몰랐을 것이고, 주말에 출근해야 됐기에 기분이 썩 좋지는
않았지만… 서버가 폭주하거나 사용자를 변경하거나 하는 일로 언젠가는 해야 할 일이니까(어차피 나 말고는 할 사람도 없고 할 수 있는 사람도 없다) 교체 작업에
착수했다.

어쨌던 출근했고, 새로운 PC와 기존 메일 서버를 작업
공간으로 옮겼다.
미리 페도라 6를 서버로 설치하고 기본 메일 서버 설정을 간단히 해 둔 상태였기에 새 PC에는 복구 작업만 필요…(’뇌를 자극하는 레드햇 페도라 리눅스 서버&네트워크 책’을 참고했다. 레퍼런스 용으로 정말 괜찮다.)

우선 기존 서버의 메일박스를 확인해봤는데, 메일들이 남았다. 하지만 root로 ftp 접속이 불가능해서 백업이
당장은 불가능한 상태였다. 마운트로 새 메일 서버로 옮기고 백업하기로 결정…

새 메일 서버에 기존 메일 서버 하드를 끼우고 실제 작업 시작…(작업은 모두 root 권한으로 작업)

mount -t ext2 /dev/hdb(n)
/mnt/hdb 로 기존 메일 서버 하드의 모든 파티션을 하나하나 뒤지기로 했다.

먼저 home 디렉토리가 있는 파티션을 찾아 ls로 리스트를 뽑았다. 계정 리스트를 추출해야 되었기 때문이다.
이 중에 정리가 안된(퇴사자) 분들의 계정은 리스트에서 제외했다.
뽑아낸 계정 리스트대로 adduser 계정명 을 수행해서 새 메일 서버에 계정을 우선 생성했다.

그 다음, aliases 파일과 mbox 파일들을 백업 디렉토리로 옮기고(1차 백업) mbox의 유저/그룹을 chown/chgrp로 내 계정으로 변경한 다음, ftp로 내 로컬 PC로 다운로드 받았다.(2차 백업)

이후, mbox 파일들에 대한 처리를 시작했다. 우선 /var/mail/로 mbox 파일들을 복사하고, 정리를 한번 거쳤다. 다음 mbox 파일에 맞게 파일 접근모드를 변경(chmod 600 *)해 주고, 각 mbox 파일에게 맞는 계정을 찾아서 소유자 변경(chown -v 계정명 mbox명), mail 그룹으로 그룹 변경(chgrp -v mail *) 해 주었다.
이것으로 mbox 파일들에 대한 작업은 끝…

다음으로, aliases 파일을 수정했다. 리눅스 버전이 차이가 많이 나서 그런지 기본적인 aliases 파일 내용이 좀 달랐다. 그래서, 기존 메일 서버의 aliases 파일을 열어서 회사의 메일 aliase에 대해 정리를 한번 하고 내용을 복사한 다음, 저장하고 newaliases 로 반영…

간단한 테스트를 수행해 보았다. 외부 메일 계정으로도 메일을 송수신해보고, alias를 사용한 메일 발송도 해 보았는데 가볍게 성공!!
임시로 할당한 IP를 기존 메일 서버 IP로 바꿔치기하고, 메일 서버 자리로 PC를 옮겼다.
이렇게 하는 데 한 3시간 정도 걸린 것 같다.(실제 퇴근은 aliases 정리 작업때문에 좀 더 늦었지만…)
리눅스 설치 및 메일 설정까지 포함하면 4~5시간 정도는 걸린건데…
근데 이렇게 정리해 보니 정말 별 거 없다. 역시 알면 쉽지만, 찾아가면서 하면 고생 고생 고생…

이제 메일 서버 관리 좀 해방되고 싶다~!!

ps. 보너스로 사양도 많이 업글한 겸 해서 스팸어쌔신도 설치하고 설정했다. 이제 스팸 넘 많이 들어온다는 소리 좀 안 들었으면 좋겠다. ㅜ.ㅜ

@ 성당과 시장 한글번역

원문 : 성당과 시장 by Eric S. Raymond

디씨인사이드 프로그래밍 갤러리에서 어떤 분이 추천하시길래 한번 읽어 보았다.
워드에 내용을 붙여 넣으니 한 2~30장 정도 될 정도로 양이 많았기에 읽기를 포기하려고 했는데, 오픈소스에 대한 이야기이기에 읽기를 시작, 마지막 장을 넘길 때에는 ‘읽기 잘 했구나’ 하는 생각이 들었다.

‘성당과 시장’은 오픈소스의 대표주자 격인 리눅스의 성공, 그리고 Raymond의 성공적인 오픈소스 프로젝트인 fetchmail의 시작과 프로젝트
진행 과정을 세세하게 전달하면서, 19가지의 체크 포인트를 제시한다.
(체크 포인트는 맨 아래에 정리…)

글의 제목이 ‘성당과 시장’인 이유는, 프로그램의 개발 모델 두 가지를 이야기의 기반으로 깔고 있기 때문이다.
‘성당’을 건축하듯이 작고 프로페셔널한 그룹이 조심스럽게 만드는 프로그램 개발 모델…
‘시장’처럼 매우 소란스럽고 서로 다른 의견과 접근방법이 난무하는 프로그램 개발 모델…

이 글은 ‘시장’의 지지자 입장에 서서 ‘시장’이 ‘성당’에 비해 갖는 우위를 보여 주는 데 집중하고 있다.
‘시장’이 갖는 특징인 다른 의견과 접근방법, 소란은 활용에 따라 든든한 서포터, 아이디어 뱅크 등이 된다는 것…
‘성당’ 모델의 닫힌(막힌) 프로젝트 개발에서는 기대할 수 없는 부분이다.

그렇다면, ‘성당’ 모델이 ‘시장’ 모델에 비해 갖는 우위는 무엇일까?
이런 시각에서 쓰여진 글이 한 번 보고 싶어지는 글이다.

[체크 포인트]

1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작한다.
   (Every good work of software starts by scratching a developer’s itch.)
2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다.
   (Good programmers know what to write. Great ones know what to rewrite(and reuse).)
3. “가지고 있는 것을 버릴 계획을 세우라 : 언젠가는 버리게 될 것이다.
   (Plan to throw one away; you will anyhow. - The Mythical Man-Month, Chap 11)
4. 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다.
   (If you have the right attitude, interesting problems will find you.)
5. 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다.
   (When you lose interest in a program, your last duty to it is to hand it off to a competent successor.)
6. 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
   (Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.)
7. 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라.
   (Release early. Release often. And listen to your customers.)
8. 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.
   (Given a large enough beta-tester and co-developer base, almost every
   problem will be characterized quickly and the fix obvious to someone.)
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다.
   (Smart data structures and dumb code works a lot better than the other way around.)
10. 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다.
    (If you treat your beta-testers as if they’re your most valuable
    resource, they will respond by becoming your most valuable resource.)
11. 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이 편이 더 나을 수도 있다.
    (The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.)
12. 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다.
    (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.)
13. (설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다.
    (Perfection (in design) is achived not when there is nothing more to add, but rather when there is nothing more to take away.)
14. 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다.
    (Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.)
15. 어떤 종류든 게이트웨이 소프트웨어를 만들려고 한다면 데이터스트림에 가능한한 최소한의 조작만 가하라 — 그리고 수신자가 강제로 하게 하지 않는다면 정보를 *절대로* 잘라버리지 말라.
    (… the data stream as little as possible — and *never* throw away information unless the recipient forces you to!)
16. 언어가 튜링-컴플리트 하지 않다면 구문상의 유연성이 필요하다.
    (When your language is nowhere near Turing-complete syntactic sugar can be your friend.)
17. 보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다. 가짜 비밀들에 주의할 것.
    (A security system is only as secure as its secret. Beware of pseudo-secrets.)
18. 재미있는 문제를 풀어보고 싶다면 자신에게 재미있는 문제를 찾아 나서는 것 부터 시작하라.
    (To solve an interesting problem, start by finding a problem that is interesting to you.)
19. 개발 조정자가 최소한 인터넷만큼 좋은 매체를 가지고 있으며 강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있다면 한 명 보다는 여러명의 리더가 필연적으로 더 낫다.
    (Provided the development coordinator has a medium at least as good as
    the Internet, and know how to lead without coercion, many heads are
    inevitable better than one.)