Twitter 어디선가 “혁신은 기술에서 나오는 것이 아니라 생각의 전환에서 온다”는 얘기를 보았다. 굉장히 부당한 주장이라는 생각이 들었다. 마치 기술은 사람의 생각이 아니라는 것 같다. 사실 딱 그런 소리다. 어째서 기술은 사고의 한 과정, 방식이 될 수 없는가?
기술은 사람의 생각이다. 기술의 발전은 모두 사고의 전환이다. 기술도 치열한 사고의 과정이다!
기술이 생각이 아니라고 당연스레 여기는 것은 추상화된 것들을 피상적으로만 접하고 그것의 숨겨진 진실에 관심이 없는 사람들의 흔한 착각이다. 하지만 사람이 이뤄낸 것들 가운데 사람의 생각이 아닌 것이 없다. 그런 사람들에게 기술은 사람이 이뤄낸 것이 아니라 하늘에서 뚝 떨어진 신탁 기계 같은 것이다.1
원래 도시에서만 산 사람들은 물을 기는 법을 모를 뿐 아니라, 왜 물을 길어야 하는지도 모르기 때문에, 도시에 존재하는 상수도 시스템이 엄청난 문명의 혜택이라는 것을 알지 못한다. 경험하지 못한 것에 대해 (인간 인지 기관의 특성 때문에) 어쩔 수 없이 착각을 하는 것은 물론 어쩔 수 없는 일이긴 하다.
하지만 저렇게까지 당당하게 주장하는 것은 역시 거부감이 들 수밖에 없다. 가끔 기술이라는 단어에 거북해질 때가 있는데 그 이유를 생각해보면 저런 것이 아닌가 한다. ‘기술’이라는 단어에 다루고 싶지 않은 생각들을 격리시켜 담고, 그것들은 생각할 게 아니라고 여기는 것처럼 느껴지는 것이다.
-
사실 엔지니어들도 이런 착각을 많이 한다. 예를 들어 소프트웨어 엔지니어는 하드웨어적인 발전을 시간이 자연스럽게 해결해주는 신탁 기계로 취급하는 경향이 있다. 하지만 모든 하드웨어 역시 다른 모든 기술과 마찬가지로, 세상의 하드웨어 엔지니어가 다 죽거나 하면 더이상 발전하지 않는, 그저 사람이 이뤄낸 것들 중 하나일 뿐이다. ↩
프로그래밍도 어느 정도 그런 게 있긴 하지만, 디자인은 특히 심한 것이, 눈으로 보이는 분야다 보니 비전문가도 자신이 어느 정도 디자인을 보는 눈이 있다고, 혹은 나름대로 공부한 영역이라고, 아니면 그 이상으로 자신이 전문가 수준의 견해가 있다고 착각하기 쉬울 것 같다.
디자인 작업을 하고 싶어하는 사람은 아무도 없지만, 다들 한 다리씩 걸쳐서 훈수를 해주고 싶어서 입이 근질근질 해지는 것이 바로 디자인이다.
디자이너들 일하기 참 힘들겠다. 디자인 전공도 안한 클라이언트, 상사, 주변 동료들이 디자인 좀 안다고 착각하면서 훈수 두는 것들 일일히 하나씩 다 디펜스하면서 작업 결과까지 내려면.
(그래도 프로그래밍은 그런 면에서 꽤나 다행이다. 이것도 눈에 보이는 프론트엔드 쪽은 비슷한 면이 많지만, 백엔드 쪽은 장벽이 있다보니 아무나 섣불리 참견하지 못한다.)
서베이와 뉴스의 중요성
빨리 만드려면 올바름을 놓아야 한다. 올바르게 만드려면 느림을 감수해야 한다. 빠르면서 올바르게 만들기 위해서는 이미 올바르게 구현한 것을 갖다 쓰는 것밖에 답이 없다. 이미 올바르게 구현한 것이 무엇이 있고 그걸 어떻게 써야 “올바르게” 쓰는 것인지 학습하기 위해서는 시간이 걸린다. 빠른 시간 안에 학습할 필요 없이 올바른 것을 갖다 쓰려면 평소에 그런 것들이 뭐가 있는지 알아둬야 한다. 결국 평소에 좋은 뉴스 소스1를 확보하고 꾸준히 모니터링하는 것이 중요하다. 평소에 해둔 서베이가 생산성과 품질에 주는 영향은 매우 크다. 하지만 그러한 혜택을 누리는 당사자들 외에는 누구도 그러한 것의 중요성을 깨닫지 못하며, 이렇게 글로 쓴다 해도 와닿는 법이 없다.
소프트웨어 마에스트로 멘티들이나 학교 후배들이 자주 묻는 질문 가운데 “어떻게 해야 실력을 키울 수 있나요?”에 대한 나의 몇 안 되는, 하지만 몇년동안 반복적으로 해왔던 대답 가운데 하나지만2 그들 중에 이 얘기를 귀담아듣는 사람은 매우 적다. 전혀 와닿지 않기 때문인 것 같다. 다만 저 말을 귀 기울여 듣는 몇몇 친구들은 실력이 매우 빠르게 크는 걸 볼 수 있었다.
클리앙 들어가는 것은 이제 좀 줄이고 그 시간에 Hacker News를 잠깐 훑어보는 것이 더 유용할 것이다.
-
내가 추천하는 주요 뉴스 소스는 Y Combinator에서 운영하는 Hacker News. ↩
-
또 다른 대답 중 하나는 “컴퓨터 책은 고전 아니면 읽지 말고 그 시간에 네가 자주 쓰는 오픈 소스 소프트웨어의 코드를 읽어라”인데 이것도 별로 귀담아 듣는 친구들은 없었던 것 같다. ↩
이번에 StyleShare에서 엔지니어링 블로그를 시작했다.
반갑습니다. 스타일쉐어 개발팀이 엔지니어링 블로그를 시작합니다!
위의 동영상은 스타일쉐어 서비스 메인 레파지토리의 Code Swarm입니다. 각각의 큰 아이콘들은 저희 팀의 개발자이고, 이리저리 돌아다니며 뭉치는 여러 파편들은 저희 프로젝트 코드의 변화를 의미합니다. 역사가 짧은 스타일쉐어 팀이지만 그 사이에 많은 작업이 있었답니다.
스타일쉐어 개발팀이 서비스를 만들면서 접할 다양하고 유익한 정보들과 재미있는 이슈들을 앞으로는 이곳에서 여러분과 공유하려 합니다.
패션 트렌드는 스타일쉐어에서, 스타트업 엔지니어링 트렌드는 바로 이곳에서 확인하세요.
StyleShare’s GitHub에서 저희 팀의 오픈소스 프로젝트도 둘러보세요. 물론, 여러분의 기여도 언제나 환영합니다.
— 스타일쉐어 개발팀 막내 김현준
이제 앞으로 뜬구름 잡는 소리만 여기 내 개인 블로그에서 하고, 좀더 구체적이고 실무적인 내용은 StyleShare 엔지니어링 블로그에서 하게 되지 않을까 한다. 첫 글은 우리팀 막내가 했다. 엔지니어링 블로그 URL은 다음과 같다:
http://engineering.stylesha.re/
Flask, Werkzeug, Jinja2 등을 만든 Armin Ronacher가 블로그에 Python 3에 대한 생각을 올렸다. 급진적인 주장은 별로 없고 뭐 다들 알만한 사람들은 아는 내용이지만 전체적으로 잘 정리되어 있으니 관심 있는 사람들은 전문을 읽어보면 되겠다. 여기에는 개인적으로 인상깊었던 부분만 인용해보겠다.
“Always complaining, not doing anything”. There is just so much stuff I would love to see Python go but at the end of the day, I’m a user of Python more than a developer.
세상에 Python 사용자는 많지만 Python 언어 구현을 해킹하는 사람은 매우 드물다. Python 사용자는 항상 Python 언어의 디자인에 대해 이러쿵 저러쿵 떠들지만 세상을 위해 실질적으로 코드를 기여하지는 못한다.
But the real reason why I loved and adored Python was the fact that I was looking forward to each new release like a child to Christmas. The small things and improvements blew my mind. Even benign things like the fact that you can now specify a starting index for the enumerate function made me appreciate a new release of Python. And all that with a strong focus of backwards compatibility.
지금까지의 Python은 어느 정도 하위 호환성을 지키면서 점진적으로 진화해 왔다. 초기 디자인은 나쁠지 몰라도, 시간이 지나면서 “잘못된 결정들”은 하나 둘 고쳐져 나간다. Python 언어의 가장 중요한 부분은 언어 자체가 아니라 PEP 같은 언어 개선 프로세스이다. 나도 강하게 동의하는 부분.
조금 더 내 생각을 적자면…, 세상에는 C++나 Java와 같은 위원회 언어라는 것이 존재한다. 하지만 그 반대편에는 Perl이나 Python과 같이 “언어를 쓰는 사람이 곧 언어의 디자인에 기여하는” 커뮤니티 언어들도 존재한다. 어떤 언어가 더 좋은지 얘기하기는 힘들다. 하지만 어떤 언어 디자인 프로세스가 더 좋은지는 명백하다. 1995년 첫 Java의 디자인은 1991년 첫 Python의 디자인보다 전체적인 면에서 대체로 더 훌륭했다(고 생각한다). 2011년 12월 현재, 일반적인 Java 코드는 IoC로 점철되어 있으며 Python은 제너레이터와 코루틴을 사용한다.
Python 3 is in the spot where it changed just too much that it broke all our code and not nearly enough that it would warrant upgrading immediately. And in my absolutely personal opinion Python 3.3/3.4 should be more like Python 3 and Python 2.8 should happen and be a bit more like Python 3. Because as it stands, Python 3 is the XHTML of the programming language world. It’s incompatible to what it tries to replace but does not offer much besides being more “correct”.
결국 Python 3와 XHTML은 비슷한 운명을 가지고 있다. 대체하려 하는 대상과 호환되지 않는 주제에 더 “올바르길” 요구하면서 제공하는 것은 별로 없다.
Python is not “too big to fail”. Python can become unpopular very quickly. Pascal and Delphi became niece languages even though they were amazing even after the introduction of the .NET framework and C#. They were ruined by mismanagement more than anything else. People still develop in Pascal, but how many are starting new projects in it? Delphi does not work on the iPhone, it does not run on Android. It’s not well integrated into the UNIX market. And if we’re honest, in some areas Python is already losing track. Python used to be sufficiently popular in computer games but that ship has sailed a long time ago. In the web community new competitors arrive on a daily basis and if we like it or not, JavaScript is becoming more and more an ubiquitous scripting language that challenges Python.
Delphi did not adjust quick enough and people just jumped on the next technology. If 2to3 is our upgrade path to Python 3, then py2js is the upgrade path to JavaScript.
Python 3가 현재의 방향을 고수하면 Delphi처럼 될 것이다. 안 쓰이는 것은 아니지만 새로운 프로젝트에서 Python을 선택하는 일은 적어질 것이다.
