블로그 이미지
레인레테
연락처 : rainlethe@rainlethe.com 영혼을 잃어버리다.

calendar

      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29      
2012/01/09 12:34 RL.P rogramming
1. 맨땅에 개발하던 시대.
아주아주아주아주 먼 옛날. 
소형 컴퓨터라는 것이 방 하나를 꽉 채울 만큼 큼직했던 시절.
디버깅이라는 것이 실제로 진공관 사이에 끼어 죽어있는 벌레를 처리하는 것이었던 때에 모든 개발자들은 컴퓨터 작동에 필요한 모든 논리를 처음부터 만들어내야 했어요. 

자동차를 만들 때마다 고무를 녹여 타이어를 만들고, 철을 녹여서 엔진을 만드는 격이었죠.


2. 라이브러리가 등장하다.
그러다가 누군가가 이런 생각을 했어요. 
그럼 미리 고무를 잔뜩 녹여서 타이어를 만들어놓으면, 자동차를 조립하기 편하겠네?
그래서 많은 개발자들은 일일이 고무를 녹이는 대신 타이어를 파는 가게에서 바퀴를 사다가 끼기만 하면 되었어요. 
자동차를 만드는 시간은  획기적으로 단축되었고, 모든 개발자들은 이것이 마법이라고 생각했어요. 

이런 타이어 같은 것을 '라이브러리' 라고 해요. 미리 만들어진 부품을 가져다가 쓰는거죠.


3. 프레임워크의 시대가 도래하다.
이렇게 타이어를 팔던 가게가 번성하던 어느 날, 새로운 자동차가 필요해진 A씨는  이런 생각을 했어요. 
'내가 왜 자동차를 만드는데 이 모든 부품을 다 알아야 하는 걸까? 그냥 조립이 다 되어 있으면 안되는걸까?'
그래서 A씨는 엔진, 타이어, 핸들 등이 다 붙어있는 자동차를 만들어 팔기로 했어요. 
이 자동차를 구매하는 사람들은 '색깔' 이나 '선루프'  등의 옵션만 선택하면 되게 된 거죠. 

이렇게 '자동차'를 만들기 위한 '꼭 필요한 부품들이 미리 조립되어 있는 것' 을 프레임워크라고 합니다.

이런 식으로 컴퓨터 프로그래밍은 발전되어 왔답니다.

더이상 사람들은 자동차에 대해서 정확히 어떤 구조로 굴러가는지 알 필요 없이 엑셀레이터를 밟으면 굴러가고 브레이크를 밟으면 멈추며, 핸들을 돌리면 방향이 바뀐다는 것만 알면 되는거죠.

참 아름다운 세상이에요.


4. 문제가 생겼을 때는 어떻게 하지?
끝!
.. 이라고 하면 참 아릅답고 행복했을 때지만, 현실은 그렇지 않아요. 
여느날처럼 자동차로 출근을 하던 B씨는 갑자기 달리던 자동차가 덜컥 멈추는 황당한 사태를 맞이하게 되었어요.
자동차에 대한 지식이라고는 운전하는 법과 라디오 켜는 법밖에 모르던 B씨에게 이건 낭패였죠.

그래서 B씨는 '인터넷'이라는 이름의 친구에게 다급하게 전화를 합니다. 
'인터넷'은 자기가 알고 있는 지식을 총 동원해서 B씨를 도와주려고 하지만
B씨는 도대체 왜 자동차가 멈추었는지 알 길이 없었기 때문에 설명하기가 너무 어려웠어요.

결국 B씨는 '인터넷'에게  '고렙 개발자' 라고 하는 이름의 자동차 수리가게를 소개받았죠.


5.  결국 구조를 다 알아야 하네?! 
'자동차 수리가게' 에서는 B씨에게 '엔진오일도 없고 미션 상태도 좋지 않네요.' 라고 말을 해 줬어요.
그렇지만 B씨는 자동차 안에 왜 엔진오일이 필요한 건지, 미션이라는건 도대체 무엇인지 알 수가 없었어요.
그냥 '고쳐주세요' 라고 말하는 수밖에 없었죠.

그리고 생각했어요. 
'아. 정상적인 상태일때는 미리 조립되어 있는 것이 참 편리하지만, 문제가 생기면 결국 기본 구조를 다 알아야 하는구나.'


6. 제조사에서는 어떻게?
이런 상황을 자동차 제조 회사에서도 모를리가 없죠. 
그래서 자동차 회사에서는 '최신 자동차 조립기술'에 맞는 '최신 전자제어장치'를 집어넣기로 했어요.
엔진오일이 없으면 계기판에서 경고등이 나오는 장치에요. 
이제 더이상 B씨는 엔진오일이 없어서 자동차가 달리다가 멈추는 일은 없을 꺼에요! 

.. 물론 여전히 미션의 상태는 확인할 수 없겠지만요. 

또 시대가 바뀌면서 자동차가 그냥 운송수단에서 레져로 바뀐다는것을 자동차 회사는 간파했어요.
그래서 자동차의 시트를 푹신하게 바꾸고, 크루즈 기능을 넣어서 자동 운전이 가능하게 만들었죠. 
즉, 이 회사는 '자동차'라는 프레임워크와 그걸 만드는 기본 재료인 '시트'를 통채로 다 맞춰서 바꾸는 거에요. 

이런걸 제일 잘하는 회사 이름은 마이크로소프트에요.

웹 여행을 할 때 쓰는 자동차 "ASP.NET" 을 시대에 맞춰서 "ASP.NET MVC 나 ASP.NET AJAX" 로 변신시키고, 
데스크탑에 코어가 여러개 달린 컴퓨터 시대가 도래하자 "패러럴" 기능을 아얘 언어에 통합시켜 버렸답니다. 

덕분에 운전자들은 '크루즈' 기능을 어떻게 쓰는건지 배워야 했지만
대신 일정한 속도로 달릴 특정 상황에는 엑셀레이터를 안밟아도 되는 편안함을 얻게 된 거에요. 


7. 튜닝 한번 해볼까?

멋쟁이 C씨는 자신의 자동차가 다른 자동차들과 똑같아 보이는게 싫었어요. 
그래서 자동차 문이 옆으로 열리는 대신 위로 열리게 개조를 한 거에요.

그런데 자동차 문을 바꿔놓고 보니 멋지기는 한데, 자동차가 달릴때 자꾸 바람소리가 들려와요.
알고보니 자동차회사가 이 자동차를 설계할 때 초정밀 계산기로 계산해 둔 자동차가 달릴때  외부 바람에 대한 마찰역학계수를 C씨는 몰랐기 때문이었어요. 

결국 C씨는 위로 열리는 문을 뜯어내고 다시 옆으로 열리게 개조하는 수밖에 없었습니다. 

이렇게 프레임워크는 '구조상 하위호환성을 유지하면서 업그레이드하는 것'은 멋쟁이 C씨가 할 수 있는 일이 아니었네요. 자동차 회사만 가능하군요. 


8. 낡았어. 바꿔야겠어. 
오랫동안 차를 잘 타고 다니던 'D' 씨는 이 차가 시대의 흐름에 맞지 않는다고 느꼈어요. 
주위 친구들은 다들 최신 기종인 'Ruby on rails" 를 타고 다니는데 자신만 'Structs' 를 타고 다니는건 촌스러워 보였거든요. 
그래서 이 차가 자신에게 맞나 한번 타보기로 했어요.
아니 그런데 이게 뭐에요.
핸들은 오른쪽에 있는 데다가 기어가 핸들 옆에 붙어있고, 심지어는 크루즈 모드도 없어요. 게다가 더욱 더 이해할 수 없게  여기는 뭐에 쓰는지 모를 '에어 브레이크'라는 기능도 있다는 거에요. 
D씨는 도대체 이걸 어떻게 운전하는지조차 알 수 없어서 친구들에게 물어봤지만, 친구들은 '우왕 이게 킹왕짱 익숙해지면 완전 편해' 라고만 할 뿐이었어요.
물론 몇몇 친구들은 적극적으로 나서서 'Ruby on Rails' 에 익숙해지는데 도움을 줬지만, 이미 'Structs'에 익숙해신 D씨는 도저히 이해할 수가 없는 것들 투성이었죠.
결국 D씨는  '옛것이 좋은 것이여' 라는 말을 남긴 채   'RoR'을 사용하는 것을 포기했답니다.

이렇게 프레임워크는 한번 익숙해지면, 다른걸로 갈아타기가 너무 힘든 경우가 많아요. 각 프레임워크는 각 프레임워크를 관통하는 철학이 있거든요. 




조금은 프레임워크에 대해서 이해가 가시나요? 


2012.01.09. By RL.P
저작자 표시 비영리 동일 조건 변경 허락
posted by 레인레테
2011/02/14 09:30 RL.T hink.
















초보자 (보통 뉴비라고 부르는) 들이 아무리 애를 써도

구루를 따라잡을 수 없는 이유.

구루들이 개발을 잘 하는데는 여러가지 이유가 있다.

그중 한가지, 그리고 절대적인 이유가 바로

'경험'이다.

수많은 문제를 풀어가며 쌓인 경험들,

 그 많은 경험이 쌓임에 따라서 쌓인 내공이라는 것은

절대로 초보자들, 그리고 그 구루보다 실력이 없는 사람들이

쉬이 따라잡을 수 없는 것이다.


그런데 이 내공이라는 건 대체 뭘까?

어떤 Domain Specific한 문제에 있어서

구루의 내공은 절대적인 힘을 발휘한다.

Domain Specific이라는 것은 꽤나 다양한 의미를 지니는데,

예컨데 개발 플래폼일 수도 있고,

언어에 대한 지식일 수도 있으며,

개발 방법론에 대한 사유일수도 있다.

물론 특정 분야에 대한 전문적인 지식을 포함해서 말이다.


초보자들이라고 해도

개발 플래폼에 대해서 남들에 비해 세배 더 열심히 공부하고,

언어에 대한 지식은 도서관을 섭렵했으며,

개발 방법론에 대해서는 이름만 대면 하루종일 썰을 풀 수도 있고,

심지어는 특정 분야의 종사자도 혀를 내두를 만큼 빠삭할 수도 있다.

그런데 왜 초보자들은 절대로 구루의 내공을 따라잡을 수 없는걸까?



우리는 절대로 남의 코드를 읽지 않는다.

사실 현업에서 일하면서 남의 코드를 읽을 일은

기존에 다른 사람이 만들어놓은 소스코드를

버그 혹은 수정사항의 발생으로 유지보수할 때 뿐이다.

이렇게 (어쩔수 없이) 타인의 코드를 읽어야 할 때에도

대부분의 사람들은 그저 자신과 코딩 스타일이 다르다는 이유로

투덜거리고는 한다.

물론, 실제로 쉽게 풀 수 있는 문제를 굉장히 지저분하게 풀어놓은 경우도 있으나

이 또한 기존에 개발을 했던 개발자의 사유의 산물이다.

이렇게  기존 사람이 문제를 풀기 위해서 밟아온 과정은

 전혀 이해하려고 하지 않은 채,

그저 스타일이 다르다는 이유로, 쉬이 이해할 수 없다는 이유로

그 코드는 '쓰레기' 취급을 받는다.


언제나 프로그래밍은 결과 지향적이기 때문인지도 모른다.

과정이야 어쨌든 사실 엔드 유저에게 보이는 모습은

그냥 결과물로서 말한다.

개발자들도 어차피 최종 산출물을 뽑아내야 하는 사람들이기에

더더욱 결과물로서 말한다.

그들은, 끊임없이 사고한다.

그리고 절대로 그 사고를 타인과 나누지 않는다.

소스코드를 읽어보면 알겠지만

History가 그대로 남아있는 소스는 대부분 없다.

그저 알고리즘 수정. 이런 주석만 붙어있을 뿐이다.

이런건 SVN같은 형상관리 프로그램으로 관리하면 된다지만,

미안하지만 SVN의 History Source를 읽는 케이스는

이 버그가 대체 누구의 잘못인가를 따지기 위한 상황 말고는 못봤다.


무언가를 배우기 위해 가장 빠른 방법은

다른사람이 어떤 과정을 밟았는지에 대해서 보고, 따라하고, 습득하고,

고쳐나가고, 직접 만들어보고, 내것으로 만드는 것이다.

우리는 , 보고, 따라하고, 습득하고, 고쳐보고..는 모두 다 생략한채로

언제나 자신의 취향이 100% 반영된 바퀴를 새로 발명한다.

그리고 기뻐한다.



서점에 가면 수많은 자기개발서와 성공서들이 쌓여있다.

그런데 유난히 IT 분야에는 그저 영웅 만들기에만 치중할 뿐, 이런건 거의 없다.

이것이 실용학문의 한계라고 하기에는 뭔가 우습다.

원래는 사유학문인 경제분야에서는 이런책이 끝도 없이 쏟아져 나오는데,

실용학문인 IT분야는 그저 자신의 방법론만 설파할 뿐

그 방법론이 어떠한 사고과정을 걸쳐 펼쳐졌는지는 절대 말하지 않는다.



Agile에서는 말한다. ProtoType을 만들고,서서히 뜯어고쳐라.

한국의 현업에서는 말한다. ProtoType을 만들어라. 그리고 프로젝트 종료.



IT는, 절대로 타인의 경험을 공유하지않는다.

소스포지등에 보이는 수많은 프로젝트들 중에서

그 많은 소스코드들 중에서

자신이 개발하는 분야에서 1등인 오픈소스 프로그램의 소스코드를

읽어본 사람은 몇이나 될까.


다른사람의 생각의 과정과 그 결과물이 도출된 원인을 배우지 않는 한,

뉴비는 스스로 깨달아갈 뿐, 절대로 구루의 옆에 설 수 없다.


2011.02.14. By RL.T

관련글
[RL.T hink.] - 지식 권하는 사회..슬프다.

저작자 표시 비영리 동일 조건 변경 허락
posted by 레인레테
2009/07/27 22:23 RL.R ead
겸손한 개발자가 만든 거만한 소프트웨어겸손한 개발자가 만든 거만한 소프트웨어 - 6점
신승환 지음/인사이트
오랫만에 읽을만한, 소프트웨어 분야에 관한 이야기.


1. 들어가면서.

난 사실은 뭐 그다지 이런 책들을 신뢰하지는 않는다.

적어도 한국에서 나온 책들은 신뢰하지 않는다.

이건 내가 뭐 외국책을 선호하기 때문도 아니고 ,

그렇다고 해서 우리나라 책들이 질이 떨어져서도 아니다.

단순하게 말하면, 우리나라 책들은

'너무 초보자들을 대상으로 쓰여져 있다.' 라는 점 때문에

나는 우리나라발 책들은 거의 신뢰하지 않는다.

특히 이런 '소프트웨어 전반에 관한 아우르는 이야기'들은

국내의 실력있는 개발자들분께서는 다들 바쁘셔서인지

아니면 노하우라서 공개하기 어려운 것인지는 모르겠으나,

참. 볼만한 책 안나온다.

오죽하면 나같은 듣보잡 블로거에 정보를 찾으러 오는 사람이 하루에 100여명이나 될까.


여하튼간에 이 책, 겸손한 개발자가 만든 거만한 소프트웨어는

이런 어처구니없는 수준에서 약 반걸음 더 나아간 것으로 보인다.

물론 저자분께서는  나보다는 훨씬 훌륭한 실력을 가지고 계시고

배울 점이 많은 분이라고 사료된다.

다만 말을 전하는 사람과 말을 듣는 사람의 입장은 다를수밖에 없기에,

나는 말을 듣는 사람으로써 어느정도 비판적 견지를 가지고 이야기를 풀어감을 양해 부탁드리며.


2. 변두리 이야기.

이분 전작 보면 아시겠지만,

위키북스에서 나온 '도와주세요! 팀장이 됐어요' 는 사실 좀 모자란 책이었다.

아마 생각키로는 임백준씨 스타일의 책을 시도했던 것 같은데

사실 내공이 모자라서라기보다는 그저 글을 써본 약력이 서로 다른 관계로

서로 다른 스타일의 책이 나오지 않았나 싶다.

하지만 역시 사람은 발전하기 마련인건지

아니면 위키북스의 가볍고 읽기 쉬운 시리즈와는 다르게

조금은 더 진중한 무게를 다루는 인사이트의 책이라서 그런지는 잘 모르겠으나

적어도 전작보다는 억지도 덜하고, 내용도 훨씬 깊이있다.

그래서 별 세개.

3. 내용.

뭐 구구절절이 말해봤자 구차하기만 하니까 짧게 요약하자면,

광의의 의미로써의 개발자들 - 소프트웨어 개발에 참여하는 모든 사람들 - 은

사용자를 알아야 하고 ,

그 사용자를 알고 유저를 위해 움직이는 소프트웨어 개발을 위해서

우리가 할 수 있는 Agile한 방법론들을 열거해 놓았다.

내용면적에서는 꽤나 훌륭한 것이

외국의 책을 그대로 베껴서 한국 저자가 썼답시고 내놓는 책들이 아주 가끔 보이는데,

이책은 그런 부류는 아니다.

굉장히, 여러 분야에 대해서 섭렵하고 공부한 후에

이걸 소프트웨어 개발에 어떻게 끌고올것인가에 대해서 나름 저자의 성찰이 보인다.


4. 그외의 이야기.

이책 솔직히 별로 안비싸다. 정가가 16800원인데, 

알라딘에서 세일해서 15,120원에 팔고 있다.

개인적으로 15000원 남짓으로 사기에는 절대 후회하지 않을 책이라고 생각한다.

막말로 술한번 안먹고, 담배 한갑 덜 사는 생활 몇일만 하면

충분한 금액이다.

식사할 때는 몇만원짜리 레스토랑도 웃으면서 가는만큼

뇌를 배불려줄 책에도 그정도까진 아니더라도 어느정도는 투자해야 하는 것 아닐까?


5. 알아두어야 할 점.

이런책 열심히 읽고 실천하지 않는다면, 그건 이미 글러먹은거다.

읽고, 느끼고, 생각하고, 필요를 깨달아서 움직여라.

여기 있는 내용이 정답이라고 이야기하는 것이 아니다.

다만 타인의 사고의 정수가 모여져 있는 곳이 책이라고 한다면,

타인이 어째서 그 사고의 결론에 이르게 되었으며,

나라면 어떻게 할 것인가에 대해서 진지하게 고민해라.


6. 참고도서.

이런 부류의 책들은 의외로 꽤 많은데,

대표적으로 Head First  Softwere Development라는 책이 있고,

그 외에도 영원한 고전이라고 불리는 맨먼쓰 미신등

몇가지 부류가 있으니 읽어보고 참고해보면

지식을 키우는데 도움이 되리라 생각한다.



덧.
태그쓰다가 눈치챘는데, 이거 제목이 왜이렇게 긴거야?

겸손한 개발자가 만든 거만한 소프트웨어 ..라니.

2009.07.27. by RL.R



http://www.rainlethe.com2009-07-27T13:22:500.3610
posted by 레인레테
2009/06/22 16:16 RL.D aily
안녕하세요.

정중하게 IT 종사자분들께 도움을 요청합니다.

현직 프로그래머(개발자라고 쓰고 코더라고 읽는다) 인데요.

다름이 아니라

요몇달 들어서 너무 실력이 정체되어 있다는 생각이 들어서요.

뭐 지나치게 낙후된 실력이다보니(...)

더 떨어질 게 없어서 그 부분은 그다지 크게 걱정 안합니다만

분명히 올라갈 길은 헤아릴 수 없을 만큼 높이 있는데

하나도 진척되지 않는 것 같아서 ...
 
어떻게 해야 할 지 싶어서 도움을 요청합니다.


내가 이쪽에 적성이 안맞는건가..하는 생각도 들고,

전공도 아니었는데 괜히 뛰어들었나..라는 생각도 들고,

뭐 기타등등 ..그렇습니다.


뜸금없이 실력이 신처럼 되게 해 주세요..이런건 바라지도 않고요.

뭔가 제가 직업으로 삼기 전

허접하지만 즐겁게 만들었던 그시절로 돌아갈 수는 없겠지만

최소한 어떻게 하면 내자신이 스킬업하는 기분을 느낄 수 있을까 싶어서,

혹은 다시한번 뭔가를 배우는거에 대한 즐거움을 느낄까 싶어서,

다른분들은 이럴때 어떻게 하시는지

혹은 현재의 실력이 되실때까지 어떤 과정을 지나오셨는지

도움을 나누어주시면

너무 감사하겠습니다.


굳이 프로그래밍 쪽이 아니어도 좋습니다.

기획도 좋고, 디자인도 좋고, 개발도 좋고, 관리도 좋고, 

 어떤것이든 관계없으니 삶의 노하우를 나누어주실 분 혹시 계신가요??


혹 나누어주실 내용이 없으시더라도

읽어주신 것만으로 너무 감사합니다.  ^^


2009.06.22. By RL.D
저작자 표시 비영리 동일 조건 변경 허락
posted by 레인레테
prev 1 next