레인레테 :: 작은 달팽이집속 바다.

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'을 사용하는 것을 포기했답니다.

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




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

저는 개발자입니다.

본격적으로 개발자로 일을 하기 시작하면서 가장 많이 다루었던 언어는 C#이고, 그 외에 보통 소소한 인하우스 프로그램들은 보통 그때그때 상황에 맞춰서 개발 환경이나 언어를 선택합니다.

이번에는 간단하게 URL을 파싱할 일이 있어서 Python을 이용해 보았는데요. 이때 느꼈던 점을 간략히 서술해 보려고 합니다.


I. 왜 Python 이었을까.
굉장히 단순합니다. 좀 더 Python 을 배워보고 싶었고, 구글에 URL 파싱이라고 쳐보니 가장 흔하게 나오는 자료가 Python의 모듈 중 하나인 BeautifulSoup이었기 때문입니다.

저는 무언가를 개발할 때, '가능하면 남들이 한 삽질 따라하지 말자.' 주의기 때문에 , 다른사람들이 어떤 식으로 문제를 해결했는지 꽤나 오래 살펴보는 편인데요. 
BeautifulSoup 같은 경우에는 '쉽고 편하다'라는 점. 그리고 일관된 메뉴얼이 있어서 좀 삽질을 덜하겠다 싶었습니다.

II. 그럼 왜 C#이 아니었을까.
왜 익숙한 닷넷 플래폼이 아니었을까요?

C#에서는 URL을 파싱하는 방법이 굉장히 많습니다.
System.URI 클래스를 사용할 수도 있고, 
mshtml COM을 이용할 수도 있으며,
심지어는 WebBrowser 컨트롤을 이용해서 읽어올 수도 있습니다.
물론 XML 클래스를 이용하는 방법도 빼놓을 수 없겠죠.
게다가 삽질 가능하다면  String을 파싱해서 HTML 트리를 만든 다음 하나씩 분해할 수도 있습니다.

... 이 많은 방법 중에 어떤게 저에게 맞는 방법인지 찾는 것도 사실은 일입니다. 다 작동한다는건 알겠는데, A 방법은 ㄱ작업시 불편하고 , B 방법은 ㄴ 작업이 아예 불가능하거나 리플렉션까지 이용해야 한다면, 이건 만드는 시간보다 어떤 도구를 선택할 지 고르는 시간이 더 오래 걸릴 것 같았습니다.

인하우스 프로그램이 아니라 외부에 납품하거나 공개하는 거였다면, 저는 좀 삽질을 해서도 c#을 사용했을지도 모르겠지만, 어차피 나만 쓰는데 굳이 돌아갈 필요는 없겠다 판단했습니다.

III. 그래서 뭘 느꼈을까.

1. 테스트가 엄청 많이 필요하다.
Python은 동적 언어이기 때문에, 말 그대로 '실행시켜' 보지 않고서는 어떤 결과가 나올 지 예측하기가 좀 어렵습니다.
정확히 말하면 어떤 '타입'이 튀어나올 지 알기 힘들죠.
정적 언어는 그 특성상 (대부분의) 변수나 함수가 타입이 정해져 있는 데 반해, 동적 언어는 단순히 '튜플을 반환한다' 정도입니다.
이 튜플이 어떤 특성을 가지는지는 그냥 '컨벤션' 에 따르는 경우가 많고, 그렇기 때문에 실제 데이터를 넣고 실행시켜 보지 않는 한 내가 원하는 정확한 결과가 나올 지 알 수가 없더군요. 
그래서 실제로 코드를 만들어내는 시간보다 코드를 일일이 쪼개서 테스트하는 시간이 더 오래 걸렸습니다. 
물론 정적 언어로 개발할 때도 테스트는 신물이 날 정도로 합니다만, 이건 그런 수준이 아닙니다. 코드몇글자 바꿔놓고 테스트해보고, 또 테스트해보고, .. 를 반복합니다. 


2. 코드 길이는 압도적으로 짧다.
실제로 코드 길이는 압도적으로 짧습니다.
Python의 모듈들이  동적으로 이루어지고, 언어 문법 자체가 훨씬 다이나믹하기 때문에, 굳이 필요없는 부분은 잘 들어가지 않습니다.
저도 사용하기 전까지는 크게 못느꼈었던 부분인데, 막상 사용해보니 그렇더군요.
한 눈에 전체 구조가 보일 정도로 코드가 짧아집니다.
즉, 환경이 짧은 코드를 장려하기에 더욱 코드가 짧아지는듯 합니다. 

3. 자료구조. 그리고 함수. 
C#을 쓸 때는 '자료구조'와 '함수'를 서로 맞춰야 합니다.
일관되게 Object형이나 String 형으로 써 버린 다음 사용시에 캐스팅을 한다면 할 말이 없지만, 언어단에서 장려하는 문화가 아니기에 사용이 꺼려집니다. 
그리고 이러한 구조를 잡는 것이 훨씬 '단단한' 느낌이 들기도 하죠.
반면 Python을 사용할 때는 자료구조는 거의 생각하지 않습니다. 
선언부에 타입을 적지 않기 떄문에, 그냥 내가 뭘 할지만 생각하면 됩니다.
함수가 완성되고 나면 어쩐지 저절로 반환 타입이 정해진 느낌이 들 정도로, 논리 흐름에 집중할 수 있습니다.
보통 정적 언어에서는 Scalar Type 과 Collection Type은 완전히 다르게 처리해야 합니다만, 동적 언어는 그런 부담이 적습니다.
하나가 변경되었을 때 나머지 코드가 변경되는 양이 압도적으로 작기도 하죠. 
대신 사용할 때 조심해서 사용해야 하는 단점은 있습니다.


4. IDE 의 부재
개인의 편차는 있을 것입니다만 Eclipse, Visual Studio 등을 비롯한 IDE는 개발하기에 정말 좋습니다.
특히 저는 닷넷 개발자니까 당연히 Visual Studio 제품군을 사용하는데, 이건 단순히 IDE 라고 부르기에 미안할 정도로 훌륭합니다. 
반면 동적 언어 진영은 여전히 IDE가 부실합니다. 
인텔리센스, 자동 리팩토링, 빌드 자동화, 버전 관리 시스템과의 일체성, 거의 완벽에 가까운 디버깅 환경 등 정적 언어에서는 IDE 가 굉장히 잘 발달해 있습니다.

반면 동적 언어들은 IDE가 그리 좋지 않습니다. Eclipse에 붙어있는 PyDev도 그닥 훌륭한 수준은 못되는것 같고, Scite는 개발환경이라기 보다는 그냥 텍스트 편집기 수준 정도입니다.

이게 그럴수밖에 없는게, 동적 언어는 말 그대로 '동적'이기 때문에, 실제로 프로그램이 돌아가기 전까지는 이 메서드가 실제로 있기는 한 건지, 혹은 잘못된 부분이 발견되었을때는 어떻게 해야 할 것인지에 대한 메타 정보가 거의 전무합니다. 그렇기 때문에  모든게 결정되어 있는 정적 언어와는 전혀 다른 환경이 나올 수 밖에 없죠.

... 사정은 이해합니다만, 굉장히 편리한 환경에서 개발하다가 이런 환경에서 개발하라고 하면, 도대체 이건 왜 안돼지? 이건 왜? 심지어는 조사식도 이렇게 불편한가? 등등 불만만 막 터져 나옵니다. 


게다가 이건 디버깅도 사실상 어렵습니다.
중단점을 찍는것 까진 좋은데, 변수가 실제로는 그냥 포인터일 뿐 값을 들고 있는게 아니라서 조사식을 일일이 계산합니다. 
거기까지도 좋은데, 그럼 연산을 못하는 함수 프로퍼티는 그냥 무시하면 될 텐데, 그걸 어떻게든 계산을 해 보겠다고 애를 쓰더니 ... IDE가 죽어버리는 황당함도 생깁니다.

대체 뭔지.
 
5. One Way.
사족으로 이건 Python의 특징일지도 모르지만, 한가지 일을 해치우는데는 한가지 방법밖에 없다.. 라는 원칙은 의외로 굉장한 도움이 됩니다. 어떤 Reference를 찾아봐도 거의 동일한 답이 나온다는 것이고, 그 Reference가 내 상황에 맞는지만 판단하면 되니까요.


IV. 결론.

 동적언어는 생산성이 좋다. 하지만 그 짧은 코드를 만들어내는 시간이나 노력은 정적 언어와 큰 차이 없더라. 그냥 가장 알맞는 라이브러리가 있는 언어를 골라 쓰자.. 정도 되겠습니다.



읽어주셔서 감사합니다.