2005년 04월 27일
프로그래머의 자부심.
프로그래머는 자부심이 강해야 한다고 생각한다.

프로그래머는 도자기 장인이 맘에 들지 않는 도자기는 깨버리는 것과 같은 장인정신
즉, 내 도자기에 대한 자부심이 필요하다.

국보급 도자기 만든다고 해서 장인이고 서민 도자기 만든다고 해서 장인이 아닌 것은 아니다.

그 차이는 공장에서 찍어낸 도자기냐 손수 만들었느냐로 나누어지며 손수 만들었더라도 잘못된
도자기를 깨버리지 않는다면 장인이라고 부를 수 없다.

단지 실력을 떠나 자부심 여부가 프로그래머냐 아니냐를 나눌 수 있다고 본다.

내가 작성한 코드 한줄이 소중하며 내 코드가 잘 못 되었음을 알았을때 도자기를 깨듯 코드를
교체하는 것이 프로그래머가 아닐까.

코드 들여쓰기는 신경도 안쓰고, s1,s2 같이 대충대충 변수명 작성하며 공개소스나 가져다 쓰는 사람들.
직접 만들었다고 하나 몇년전 코드와 현재 코드가 전혀 발전 및 변화가 없고 새로운 것을
찾지도 않으며 새로운 것을 가르쳐줘도 듣지 않고 거부하는 사람들.
이들은 프로그래머가 아니다.

꼼꼼한 들여쓰기, 네임센스 뛰어난 변수명, 비록 성능이 떨어질지 몰라도 손수 작성한 코드,
좀더 발전된 기술을 알았을때 적용 및 성능이 떨어지는 코드에 적용하여 보완, 시간이
갈수록 발전되는 코드를 만드는 당신은 프로그래머다.

QBasic으로 만들던 Java로 만들던 중요한 것은 언어가 아니다.(비록 언어의 한계가 있다지만)
영어로 소설 쓰던 한글로 쓰던 둘다 작가고 베스트 셀러가 될 수도 있다.

진정한 프로그래머들이여 자부심을 가지고 일하자.



[투덜투덜...]
나 솔직히 반성해야 한다. PHP언어를 하고 있는 지금 JSP프로그래머에 꿇리는 느낌이다.
이론적으로는 아니라는 것을 알고 있음에도 주변의 환경이 JSP프로그래머의 가치가 더 높다.
이럴줄 알았으면 JSP하는 건데 하는 생각을 가지고 있다. 그렇다고 회사에서는 PHP하는데
JSP 할 수도 없고 ㅡㅡ; 짱난다. 언제쓰게 될지 모르는 JSP를 공부하자니 찝찝하고 안하자니
꿇리는 느낌이다. PHP5에서 놀고 싶은데 회사는 PHP4에 묶여있고 흑흑...
내 마음대로 하라면 PHP5 서버를 한대더 구입해서 쓰고 싶은데.


[기쁨...]
예전 다음 아고라에 올라왔던 글중 '대한민국 IT에는 미래가 없다. 그런데 난 즐겁다.' 라는
글에 대한 포스팅을 올린 적이 있었는데 최근 이 글에 대한 댓글이 하나 올라왔다.

'대한민국 IT에는 ...' 글을 보고 좌절했다가 나의 포스팅을 보고 다시 웹을 바라보게 되었다는
댓글이 올라왔다. 나의 글이 누군가에게 도움이 되었음이 기쁘다.
by -A2- | 2005/04/27 10:52 | IT 이야기 | 트랙백(1) | 덧글(14)
트랙백 주소 : http://ani2life.egloos.com/tb/1250648
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from 아크몬드의 롱혼블로그 at 2005/05/04 10:46

제목 : 고도로 엔지니어화된 사람들의 일곱가지 습관
[고도로 엔지니어화된 사람들의 일곱가지 습관]이란 처음 2천만 달러가 언제나 가장 힘들다(The First $20 Million Is Always the Hardest)의 저자인 포 브론슨이 스티븐 코비를 풍자하여 만들어 낸 이야기입니다. 2번과 3번을 제외한 모든 항목이 저에게 해당한다고 생각합니다..^^; 아래의 항목들 중에서 자신과 어느 정도 유사한지 비교해 보세요. 1. 자신의 이기적인 면에 관대하다. 2. 장님이 되어야 시력이 좋아진다. 3. 먹이를 주는 손을 물 뿐 아니라 자기 손도 문다......more

Commented by yser at 2005/04/28 18:32
이런 말이 있습니다.
쉬운 길을 어렵게 갈 것이냐 아니면 어려운 길을 쉽게 갈 것이냐.
php 든 jsp 든 필요성에 따라 선택하면 됩니다. jsp? 그건 할 때가 되면 그 때 하면 됩니다. 모름지기 한 우물 잘 파는 사람이 다른 우물 들어가도 잘 팝니다. 이것은 진실이지요.

따라서 고민하실 필요가 없습니다. jsp 몸값이 높은들, 그것이 절대적인 가치 판단의 기준은 되지 않습니다. php 로도 된다면 그걸로 하면 됩니다. 굳이 jsp 알 필요가 없어요. 필요하면 그 때 가서 배우면 되는 겁니다.
Commented by yser at 2005/04/28 18:48
간만에 p*psc**l 검색하다가 a2 님이 쓴 클래스 글을 보았는데, 저는 사실 저기 답글들에 꽤 수긍하는 편입니다. 유닉스의 철학에서도 말하듯이 작고 단순한 것이 아름다운 것처럼, 가볍고 간편한 것이 스크립트 언어에 어울릴 때가 많습니다. 클래스는 때때로(또는 종종) 단순한 것을 복잡하게 만듭니다. 그런 면에서 보자면 jsp 같은 건 단순한 걸 복잡하게 할 가능성이 많습니다. 만드는 사람의 능력에 달린 거지만, 사실 환경이 그 운명을 어느 정도 결정지으니까요.. (php 가 너무 쉬웠기 때문에 일어났던 문제들을 생각하면..)

아마 전에 클래스 얘기 했더니 다들 필요 없다 그런 식으로 사람들이 대해서 서운하다고 하셨던 게 저 글이 아닐까 하는데, 잘 설계되어서 압축성이 있고 유연한 객체를 만들지 못한다면 그냥 구조적 기존 방식이 더 낫다고 생각합니다. 그 “잘 만드는 것”이 어려운 것을 알기에 저러한 답글들이 달린 게 아닌가 하네요.. 요는 정말로 필요한 곳이 아니라면 굳이 어렵게 할 필요가 없다는 것.. 따라서 열등감에 시달릴 필요도 없습니다. 그냥 자기 기술을 더 연마하고 기술 외의 면으로 눈을 돌리는 연습을 합시다. ^^
Commented by -A2- at 2005/04/28 22:56
yser// 말씀 감사합니다. 님 말씀처럼 무조건적인 클래스의 사용은 안쓰느니만 못합니다. 그런데 반대로 무조건적으로 php에 클래스는 필요없다고 주장하는 것도...

저는 연구하는 열린 생각을 원합니다.
php에 클래스를 써야한다 말아야 한다를 떠나서 php를 객체지향적으로 개발해보겠다는 것에서 발전된 생각이 나오는 것 아니겠습니까.

php로 GUI 만든다는 글도 보았고, 프레임워크를 만든다는 글도 보았습니다. 저도 나름대로 엔진을 만들고 그 엔진 위에서 프로그램들이 동작하는 개념을 도입해 보았습니다.

이런 여러 개발방법을 이야기하고 연구하고 싶은데 1년전 코드나 1년후 코드나 똑같은 프로그램이나 찍어내면서 클래스는 필요없네 하는 소리는 듣고 싶지 않았습니다.
Commented by -A2- at 2005/04/28 22:56
처음에는 클래스, 게시판, 모듈등 만들어서 공개하고 싶었는데 생각 꽉막힌 사람들에게 공개해봤자 아무 필요가 없다는 것을 느끼고 회사전용으로 개발하고 있습니다.

자바스크립트가 html문서의 객체에 node방식으로 접근하는 것에 아이디어를 얻어서 저도 node개념을 도입한 xml파서(?) 클래스를 나름대로 개발해봤습니다. 그리고 지금도 곳곳에 쓰고 있구요.
비록 해외 pear보다는 떨어질지 몰라도 제 나름대로 개발했습니다.

하지만 그들의 생각과 답변은 만들고도 공개하고 싶은 생각이 들지 않게 합니다. 그들에게는 해외에서 만든 pear라는 클래스를 알아줘도 국내 개발자들끼리는 클래스는 필요없다고 주장하기 때문입니다. 자신이 하기 싫으면 말 것이지 필요없다는 주장을 통해서 타인의 연구성과와 그 연구자료를 보고 개발해 보려는 사람의 의지를 꺽는것은 국내 프로그램 기술발전의 질을 떨어뜨리는 것이라 생각합니다.
Commented by yser at 2005/04/29 02:05
저는 클래스를 쓰면서 최근 이러한 생각을 하고 있습니다.
잘 설계된 객체를 다루면서 쓰면 편리한데, 항상 그걸 어디까지 구현하느냐가 문제입니다. 조금만 더하면 더 멋진 게 될거 같은데, 그러다보면 점점 구현은 커지고 코드도 비대해지고.... 바로 그런 함정을 조심해야 할 것 같습니다.

작고 간소하며 명료한 구현과 유연한 설계를 하고픈데 항상 이것은 현실적인 시간이라는 문제와 맞물리죠. 이것의 균형을 잡는 게 힘들달까요.. ..뜬구름 잡는 소리군요 ^^;
Commented by yser at 2005/04/29 02:13
그리고 코드의 효율성 문제인데... 사실 어플도 마찬가지로 잘 돌아간다면 굳이 몇 년이 지난들 그걸 또 수정할 필요는 없을 거 같습니다. 아무리 순차적인 막 코딩으로 이루어놓은들 그것이 잘 작동하고 더이상 개선의 여지가 없다면 그걸로 된게 아닐까 해서요. 가끔 설계를 하다보면 새로운 더 좋은 개념이 첨가되는데 저는 이 때를 가장 경계합니다. 추가하면서 생길 부담과 문제에 신경을 곤두세우거든요. 최적화도 어설픈 최적화를 하면 그게 버그의 원인이 되고요..

간단하게 클래스화 하는 예를 들면 함수를 그냥 호출하고 지역변수 주고 받는 거로 해결하던 것이, 객체가 되면서 생각해줘야 할 고려점이 더 많아지는 걸 발견하곤 합니다. 객체적으로 생각하는 개념이 그렇게 쉬운게 아닌가봐요.. 물론 일부에선 유용히 쓰고 있습니다. 그리고 공개된 소스는 우리나라 특성상, 그리 높은 질을 기대하기 힘듭니다. 분명히 제대로 개념 박힌 개발자가 짠 소스는 잘 되어 있을 겁니다. 다만 혼자서 설계하고 만들고 배포하는.. 그러한 소스의 경우는 그 태생적 한계로 인해, 결국 전체 수준이 낮아보이는게 아닐까.. 싶네요. 외국은 혼자보다는 여럿이서 해서 공개하는 경우 많잖아요..
Commented by yser at 2005/04/29 02:19
그리고 답변을 했던 사람들 중에 과연 그들 중 얼마나 객체지향 개념을 제대로 적용해 보고 많이 경험한 자가 있을진 모르겠으나, 적어도 객체화... 라는 것에 따르는 위험을 알고 있기에 그런 말이 있다고 보여졌구요. 부정적이긴 하나 사실이기도 하니까요. 저도 사실 진정한 객체화..이런 건 모릅니다. 그저 구현된 명세를 통해 코딩을 할 뿐이지... 이것은 2차원 DB 쓰던 개념에서 3차원 DB 개념을 배우라는 것만큼 어려운 게 아닌가 싶기도 합니다. 뭐 나름대로의 의견들이... 글이라는 딱딱한 매체를 통해 전달되어 그런 거라고 생각합니다. ^^; 감정이라는 것 전달이 정말 쉽지 않죠...

그리고 전 pear 는 전혀 안써봤는데, 소스를 대충 봤더니 뭐가 그리들 큼직한지... 별로 쓰고 싶지가 않더군요;; 그냥 가볍게 돌아가는 걸 만들어 쓰는게 낫겠다 싶던데... 스크립트에 있어서 속도는 제 2의 생명이 아닐지.. ^^;
Commented by yser at 2005/04/29 02:28
마지막으로, 만약 누가 제게 어떤 걸 만들어달라고 한다면... 그리고 그것이 제가 스스로 흥미진진하게 투신(?)할 프로젝트가 아니라면... 저는 클래스를 가급적 쓰지 않는 방향으로 할 것입니다. 설계에 투자하는 시간과, 잘 설계되지 않았을 경우 떠받는 부담을 느끼기 싫어서요. 그래서 그냥 구조화 구현으로 간단하게 하는 걸 선호할 거 같습니다.
Commented by yser at 2005/04/29 02:28


시간이 충분하고 취미로서 영위할만한 개발 분위기라면 도입을 진지하게 고민해 보겠으나.. 아니라면 그냥 종이에 잠깐 개념 그려보고 바로 코딩 GO 랄까요 ^^;; ..다만 제가 만들고 싶은 것에는 혼신의 노력을 기울여 설계하고 코딩할 것입니다. ..다만 이러다보니 하나의 결과물이 작년말부터 아직까지 이어져 오고 있지요.. -_-; 코딩 두 줄 하고 팔짱 끼고 노려보고 종이에 상황 그려보고 그러다 지치면 게임도 하고 놀고 자고 -_- 푸헐.... 어제도 클래스 화 해놓은 스킨 파싱 부분이 덜 객체화 되었다는 걸 발견하고 이놈을 우찌 뜯어 고칠까 고민하다 텅빈 메소드 두 개 추가만 해놓았습니다. 구현 할지 안할지도 못 정한 채... -a-;; 잘 쓰면 좋은데... 고거이...참 힘들어유.. 만약 p*p~ 가 취미로 학술적 개발을 하는 광장이었다면 충분히 진보적인 의견들을 보셨을겁니다. ^^ 항상 문제는 개발자에게 있어 시간 그리고 열정~ orz
Commented by 최영락 at 2005/10/04 11:46
상당히 일리가 있고, 일언이 있다.
하지만 공장에서 만들 도자기의 그 무엇인가가 있음을 깨닫는다면, 프로그래머가 장인일 필요을 못 느낀다..
이는 무엇을 말하는가?
우린 엔진니어와 장인 즉 기능인이자 예술가이 도공을 구분하는 능력이 없다는 것이다.
즉 기능인 영어로 엔진니어는 만들어야할 제품에 대한 정해진 목표와 그리고 그 제품의 뭄질에 대한 것등을 정한다. 자기 만족감이 아닌 그리고 자기 만족적 제품을 다른이가 이해하고 만족 타인의 대리 만족감과 황홀감을 주어야만 하는 완전 무결을 목적으로 하는 예술인이자 기능공인 도공 흔히 장인이라(여기에는 도공만을 포함하는 개념은 아니다 한 예일 뿐...)는 존재인과는 구분 되어진다.
Commented by 최영락 at 2005/10/04 11:47
즉 프로그래머는 기능인 즉 엔진니어 왜 이렇게 표현해야 할까?
기능인은 곧 기름쟁이 즉 쟁이라는 우리말에 대한 자부심이 없는 대다수의 우리을 탓하지만 난 기능인 즉 쟁이다. 개발자다. 이게 맞는 자부심이다. 난 장인이 아닌 쟁이다. 즉 쟁이와 장인을 서로의 목적 부터 다른다 자기 만족을 통해 타인의 만족감과 황홀감을 유도해야하는 목적과 정행진 공정과 정해진 기간 정해진 성능 정해진 품질을 이루어야할 목적 이는 확연히 다른 목ㅈ벅이다...
Commented by 최영락 at 2005/10/04 11:48
예술가이어야 하는 것음 프로그래머들의 자만심이다.
자기 만족감과 항홀감을 만들어야하는 예술인들은 없다.
컴퓨터 아티스트가 아니기에..
아마도 코딩의 예술의 경지에 이룬 많은 이들의 ㅗ딩을 보면 황홀하지만 그것은 매우 오래된 옛말이다.
나도 한때 그런 경지를 바로보고, 개발하였지만 어느 순간 왜 ㅣ국 등 선진국의 개발자보다 낮은 수준의 급여인가? 왜 그들보다 깊이가 떨어진단 소릴 듣는가...
Commented by 최영락 at 2005/10/04 11:48
도공은, 무슨 장인은 그런 경지는 하나의 전공과 그것의 예술적 가치등 예술로서의 그 무엇인가가 있지만 프로그램이나것은 즉 소프트웨어는 그것이 존재할 이유도 그런 가치를 지여서도 되지 않느다.
사용자를 위해서 편리해야 하고, 안정 되어야하고, 성능이 평균적 성능에 부합해야만 하는 여러 품질 규약에 맞아야만 하는 그런 것이 소프트웨어이며 프로그래머로서의 할 일 그래서 다양 다식하는 현 우리나라의 현실은 지옥의 경지에 가깝고, 불행히도 저임금이란 공식이 떨어진다.
Commented by 최영락 at 2005/10/04 11:48
절대적 저임금이란 것이 아닌 그 노동의 질과 노동의 량 그리고 미래 지향적 일임에도 불구하고 보통의 직업과 구분 되는데도 불구하고 그 수준에 비해 다소 높다는 이유로 우리의 프로그래머는 자신들의 노력에 비해 자신들의 기술 순준에 비해 임금은 낮고, 또한 발전 엔진을 스스로 버리거나 썩게 한다.
즉 다양 다식은 그런 악순환을 만든다.
이 일을 다양하다. 한일은 많다. 그렇지만 하나의 소 분야에서도 십수년간 한일도 많고 그 하나의 분야에서만도 또 더 많은 다양함을 보게 된다. 인생을 짧다 그것의 깊이 들어감으로도 더 많은 것을 이해하고 발전 시ㅣㄹ수도 있다 이런 간단한 이치는 우리 현실에서는 아무 이유 없이 바로 무너져, 얇팍한 예술인으로 전락한다.. 프로그램머는 절대로 예술인 장인이어서는 않된다..
예술인 장인은 고뇌하는 고차원적 존재임에 틀림이 없다. 그러나 쟁이는 생활인이고, 보통인이며, 다른이에 비해 기술적 가치의 지혜자이다. 따라서 장인과는 다른 이유로서 자부심을 가져야하고 다른 깊이를 지여야만 한다. 하나의 소 분야에서도 그런 경지는 무수히 많고 깊이를 더해야만 가능한 일이다,,,,,,

:         :

:

비공개 덧글



<< 이전 페이지 | 다음 페이지 >>