2012/01/02 19:50
RL.P rogramming
저는 개발자입니다.
본격적으로 개발자로 일을 하기 시작하면서 가장 많이 다루었던 언어는 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. 결론.
동적언어는 생산성이 좋다. 하지만 그 짧은 코드를 만들어내는 시간이나 노력은 정적 언어와 큰 차이 없더라. 그냥 가장 알맞는 라이브러리가 있는 언어를 골라 쓰자.. 정도 되겠습니다.
읽어주셔서 감사합니다.
본격적으로 개발자로 일을 하기 시작하면서 가장 많이 다루었던 언어는 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. 결론.
동적언어는 생산성이 좋다. 하지만 그 짧은 코드를 만들어내는 시간이나 노력은 정적 언어와 큰 차이 없더라. 그냥 가장 알맞는 라이브러리가 있는 언어를 골라 쓰자.. 정도 되겠습니다.
읽어주셔서 감사합니다.
2012.01.02. By RL.P
