프로그래밍에 대한 오해

  • Post author:
  • Post category:
  • Post comments:16 Comments
  • Post last modified:February 8, 2020

여러분 중 몇몇 분은 남들도 할 수 있는 프로그래밍에 지치고 회의를 느끼는 것 같았습니다.

그럼, 도대체 남들도 쉽게 좇아할 수 있는 거 익혀서 뭐하나요?

전산학과 세미나 Digital Value Design의 김기응 조교수님께서 쓰신 프로그래밍에 지친 분들에게..에서 발췌한 내용이다. 이 대목에서 당황했다는 걸 고백하지 않을 수 없다. 전산학과 학생들이 이렇게 생각하고 있다니. 아하, 이제야 몇몇 사람들이 보였던 반응이 이해가 된다. 정년이 짧다던가, 연봉이 낮다던가 하는 이유를 대고 다른 분야로 진출하는 건 아쉽지만 어쩔 수 없는 부분이었다. 환상적인 실력을 보여준 동기가 한의대로 진학했을 때, 안타깝긴 했어도 잘 되길 빌어주었다. 그런데 지난 8개월 간 이야기 나눈 사람들 중 일부가 무언가 다른 걸 해보겠다고 했을 때는 기분이 좋지 않았다. 내 일도 아닌데 괜히 열을 내는 경우도 있었다. 이제 그 이유를 알겠다. 그들의 마음 속에 있는 프로그래밍 경시 태도를 어렴풋이나마 느꼈던 탓이다.

현업에 몸을 굴리고 나서 깨달은 게 있다면, 비전이나 참신한 아이디어만큼 중요한 것은 없다는 사실이다. 더불어 또 다른 깨달음을 얻었는데, 프로그래밍 실력이 뒷받침되지 않으면 아이디어를 실현하는 데 고생할 가능성이 다분하다는 것이다. 기존 자연어 검색 엔진을 획기적으로 개선할 수 있는 아이디어가 떠올랐다고 하더라도, 머리 속에 든 멋진 생각을 프로토타입으로 제작해서 증명해내지 못한다면 어떨까? 자연어 처리와 같은 오늘날의 많은 전산학 분야에서는 이론적 가능성을 수학적으로 보이는 것만으로는 충분치 않은 경우가 많다. 물론 돈이 많아서 뛰어난 개발자를 고용할 수 있다면 문제는 해결될테지만, 그렇게 운 좋은 경우가 드물다는 건 누구나 안다.

프로그래밍이 중요하다고 해도 익히기 쉽다면 사실 이런 논의가 필요하지 않을거다. 물론 현실은 남들도 할 수 있는 프로그래밍에 지친 전산학도의 생각과는 전혀 다르다. 오늘날 가장 널리 쓰이는 프로그래밍 패러다임 객체지향은 어떨까? 객체지향 프로젝트에 직접 참여해보기 전에는 참 쉬워보인다. 객체지향은 매우 훌륭한 개념이지만 아쉽게도 이제서야 제 자리를 찾아가는 중이다. 객체를 처음 선보인 Simula 67이 1960년대에 나왔다는 걸 생각하면, 어이없는 일이다. 그러나 사실이다. 이 분야에서 뼈대가 굵은 겐도형조차 OOP! Oops에서 객체지향이 이론처럼 잘 되지는 않는다고 증언한다. 이렇게 객체지향 패러다임이 의외로 발전하지 못한 데는 여러가지 이유가 있다. 개인적으론 C++ 같은 객체지향 언어의 탈을 쓴 C 언어가 널리 퍼진 탓이 크다고 생각한다. Java, C#, Ruby와 같은 순수 객체지향 언어가 인기를 얻는 요즘에야 비로소 제대로 된 객체지향 프로젝트가 무엇인지 고민할 수 있는 여건이 마련되었다.

순수 객체지향 프로그래밍 언어를 사용하더라도 여전히 프로그래밍은 어렵다. 한가지 이유를 대자면, 객체 모델링이 생각보다 어렵기 때문이다. 자동차란 대상이 있다면, 자동차가 하는 역할도 있다. 대상과 역할을 각각 객체와 메써드로 구현하면 끝이다. 이론적으론 너무나 간단하다. 하지만 현실에선 객체를 정의하는 것조차 쉽지 않다. 자동차는 수없이 많은 부품으로 이뤄져 있다. 어디까지 객체로 나누어야 하나? 엔진, 배기구 정도면 충분할까? 아니면 나사와 볼트까지 객체로 구현해야 할까?

프로그래밍이 어려운 이유가 20가지는 떠오르지만, 이쯤에서 더 중요한 이야기를 해보자.

사회에 진출하면 여러분은 소프트웨어 설계자가 되기 때문에 프로그래밍 안한다?

얼마 전에 모 대기업에서 소프트웨어 공학 관련 일을 하시는 분의 강연을 들었다. 비효율적인 개발 프로세스를 개선하는 작업의 총책임자였는데, 강연 도중 황당한 이야기가 흘러나왔다. 여러분과 같이 머리 좋은 사람을 데려다가 코딩에 투입하면 안 되죠. 설계 같은 고급 업무에 넣으니 걱정 말아요. 마이크로소프트 같은 회사에선 막 대학 나온 신입을 프로젝트 관리자로 고용하곤 한다. 일반적인 인식과는 달리 프로젝트 관리자는 기술을 세세히 알 필요가 없다. 그들이 해야 할 일은 기술을 관리하는 게 아니라 사람을 관리하는 것이기 때문이다. 하지만 아키텍트는 사정이 다르다. 대졸 신입을 설계 업무에 투입한다는 건 어불성설이다. 그가 매우 뛰어난 프로그래임을 이미 증명했다면 몰라도.

자동차 모델링 문제로 돌아가보자. 엔진까지 객체로 나눌까? 아니면 나사까지 모델링해야 할까? 정답은 상황에 따라 다르다이다. 문제는 상황이 뭐냐라는 점이다. 지금이 세세한 모델링이 필요한 순간인지, 그렇지 않으면 과감하게 나아가도 되는 상황인지 어떻게 알 수 있을까? 문제를 한번에 해결해 줄 은탄환은 없다. 최선의 방법은 되도록 많은 경험을 쌓는 것이다.

이렇게 말해도 어떤 몽상가들은 여전히 내 생각은 달라라고 할 것이다. 그들은 프로그래밍 실력과 설계 능력에는 별다른 상관 관계가 없다고 주장할지 모른다. 마틴 파울러는 객체지향 필독서로 꼽히는 리팩토링의 저자 중 한명이며, 컨설턴트이자 아키텍트이다. 최근에는 디자인 패턴 분야에 큰 관심을 보이고 있다. 루비 온 레일스의 가장 큰 장점 중 하나로 꼽히는 액티브 레코드의 개념을 처음 제시한 사람이 바로 마틴 파울러였다. 그런데 그는 탄탄한 프로그래밍 실력을 갖고 있다. 그가 최근 쓴 글을 보면 자바 뿐만 아니라 루비와 같은 새로운 언어도 적극적으로 사용하고 있음을 알 수 있다. 자바나 루비의 개발환경 설정과 같은 저수준 작업에 대한 내용도 언급하고 있다. 아직도 매우 적극적으로 프로그래밍을 하고 있다는 걸 의미한다. 새로운 아이디어를 내놓기 위해서는 실질적인 문제가 무엇인지부터 파악해야 한다. 그러니 프로그래밍을 제대로 경험하지 못한 풋내기가 아키텍트가 될 수는 없는 노릇이다. 아키텍트가 되기 위해 프로그래밍 경험을 많이 쌓아야 하는 것은 물론이거니와, 환경이 계속 변하기 때문에 아키텍트가 돼서도 어느 수준 이상은 프로그래밍에 발을 담그고 있어야 한다. 물론 풋내기라도 명함에 아키텍트를 적어넣는 건 자유이긴 하다.

몽상가들은 상아탑에서 자라지만, 아키텍트는 현업에서 성장한다.

결론

프로그래밍은 남들도 할 수 있는 영역이 아니다. 탄탄한 실력을 가진 프로그래머와 마주쳐 보면 몸으로 알게 될 것이다. 어중간한 실력으로 프로그래밍에 대해 알 건 다 안다라고 말하는 사람이 10명이 있어도 뛰어난 프로그래머 한명을 당해낼 재간이 없다. 이건 로버트 L. 글래스가 소프트웨어 공학의 사실과 오해에서 오래 전에 알린 사실이다.

아키텍트와 같은 고급 인력이 되고 싶다면 프로그래밍 실력부터 차근차근 쌓아나가야 된다. 핵심을 짚어낼 수 있는 능력은 경험으로부터 온다.

Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.
0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

16 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback
17 years ago

개발자로 돌아가기

좋은 프로그래머가 되기 이전에
좋은 아키텍트가 될 수 없다는 말에 동의합니다.

제가 그런 생각으로 대기업 남들이 보기에 좋은 자리를 뛰쳐 나와서
다시 개발자 생활을 하려 하고 있습니다.

codewiz
17 years ago

너무 멋진 글 잘 읽었습니다.
저도 완전 공감하는 내용이네요. ^^

최재훈
17 years ago

저녁 늦게 쓴 글이라 오타나 부족한 점이 눈에 띄어서 살짝 수정했습니다.

RE ASP.NET: 좋은 직장을 뒤로 하고 나서는 게 정말 어려운 일인데, 결단력있으시네요. 그나마 몇년 전보다 전체적으로 실력있는 개발자가 살아가기 편해진 듯 합니다. 학원 등에서 어중간한 인력이 유입되는 정도가 눈에 띄게 준 것도 있고, 회사 측에서도 그 폐혜를 인지한 탓도 있는 듯 합니다. 앞으론 더 나아지겠죠. 부디 원하시는 자리를 찾으시기 바랍니다.

RE codewiz: 마음에 드신다니 다행이네요. 운동하고 돌아와서 안 그래도 피곤한데 저녁 늦게 글을 써서 감정적으로 쓴 게 아닌가 걱정했었습니다. ^^

haneul
haneul
17 years ago

ㅎㅎ 좋은 글 잘 보고 갑니다. 현업에서 배울께 너무 많아서 정신이 없답니다;;

최재훈
17 years ago

저도 빨리 이번 학기 마치고 일하고 싶습니다. ㅎㅎ

maceo
maceo
17 years ago

100% 동의하는 글입니다. 저도 마틴 파울러의 책들(리팩토링, 엔터프라이즈 아키텍쳐 패턴)과 각종 디자인 패턴/아키텍쳐 패턴 책들을 보고 실무에 적용해보려고 골머리를 싸매면서 제대로 된 객체지향 개발이라는게 장난아니게 어렵다는걸 절절하게 느낀바가 있습니다. 그런데 그로부터 몇년이 지난 지금 생각해보면, 아키텍트급 개발자에 대한 수요 내지는 필요에 대한 인식은 여전히 적다는 것, 그리고 IT에 대해 “노가다” “몸으로 떼우는 일” 이라는 인식은 여전하다는게 문제입니다. 저는 그래도 이름대면 알만한 언론사의 기자 경험도 있는데요, 모 회사 면접관은 이런 얘기도 하더군요. 왜 남들이 선망하는 기자를 그만두고 다시 IT를 하려고 하냐고.

사실 친구들을 봤으니 아시겠지만 뛰어난 개발자가 될 수 있는 친구들은 최소한 평범한 의사/한의사도 될 수 있습니다. 최소한 평범한 금융권 애널리스트/펀드매니저도 될 수 있지요. 사회생활이 얼추 8년이 넘어가다보니 느끼는데요, 어느 분야를 가나 사람은 자기의 맥시멈에 가깝게 일하게 되더군요. 하루는 어차피 24시간이니까요. 그러니까 이런겁니다. 어딜가나 고생스러운건 마찬가지라면 사회적으로/금전적으로도 인정받을 가능성이 높은 쪽으로 가는건 너무나 자연스러운 일입니다. 저희 개개인의 힘으로 이런 상황을 타개하기는 힘듭니다. 방법은 무엇일까요. 제가 하는 일의 가치가 정말로 이정도밖에 안되는 것일까요? 참 힘든 상황입니다.

toro
17 years ago

김기응 교수님이라는 분은 회사 경력이 많으시네요. 쓰신 글을 보니 학생들에게 도움이 많이 될 것 같아요. 사실.. 예전에 심규석 교수님 외에는 코딩의 중요성에 대해 얘기한 분이 별로 안 계셨던 기억이 납니다.

최재훈
17 years ago

RE maceo18: 고등학생이나 20대 초반이라면 의사를, 대학 졸업자라면 경영이나 컨설팅을 대안으로 생각하는 것 같습니다. 대체로 사람들은 과거를 기준으로 선형적으로 미래를 예측하는 경향이 있죠. 개인적인 생각입니다만, 제대로만 준비한다면 전산학으로 돈 벌 수 있는 기회가 많을 겁니다. 미래 예측에 대해선 언젠가 한번 정리해보려 합니다.

어쨌든 비즈니스와 기술이 함께 어울려야 성공하는 건데, 기술에 대한 이해가 부족한 경우가 많은 건 분명해 보입니다. 그래도 최근엔 균형 있는 시각을 가진 경영진이 차츰 많아져서 다행입니다. 야근을 줄이는 시도도 꽤 많이 이뤄지고 있구요.

RE toro: SDS와 일한 적이 있다고 듣긴 했습니다. 간간히 말씀하시는 걸 보면, 확실히 실무 경험이 있는 학자라는 생각이 듭니다.

오스카
오스카
17 years ago

정말 제가 하고 싶었던 말을 다 써주신거 같습니다. -0-

최재훈
17 years ago

그렇습니까? ^^

dawnsea
17 years ago

좋은 글 잘 봤습니다.

이 업계에서 아키텍트라고 하면 말잔치에 불과한 경우가 좀 많죠.

코딩을 우습게 보는 것은 전산학원 막 나온 초급 개발자가 SI업체의 말단에 투입되어 어리버리 완결되는 SI프로젝들을 주로 많이 목격해서 그럴 겁니다. 그게 다는 아는데 말이죠.

진짜 아키텍트는 나이를 먹어도 직접 체크인까지 챙겨 하더군요. CVS 뒤져서 개인지도까지 합니다.

헌데, 잡지에나 등장하는 그럴싸한 말잔치로 포장 잘 하는 사람들 많지요. 뭐 세미나 장사도 좋은 사업 아이템입니다 -_-; 기술영업도 기업의 중요한 부분인데 그냥 기술영업이라고 하시지 굳이 아키텍트라면서 개발자들 피곤하게 하면 안 되는데 말이죠.이것도 사농공상문화가 남아 있어서 그런지.

최재훈
17 years ago

하하. 네. 맞습니다. 가끔 세미나 등에 갔다가 ‘사기꾼이네’라면서 돌아나오곤 합니다.

karkata
karkata
17 years ago

개인적으로 클래스 설계 단계에서 가장 큰 즐거움을 찾는 사람입니다.
멋진 아키텍트가 되겠다고 꿈을 가지고 있습죠. (^^; 웃음이 나오네요;;)
가끔 이력서나 이런 부분에 저는 클래스끼리 커플링을 줄이며, 기능 확장을 위한 유연한 클래스의 형태를 어쩌구 저쩌구 하는 부분에 관심이 큽니다. 라고 적고 싶을 때가 있습니다. 근데 실제로 이렇게 적었다면 회사측에서 좋게 봐 줄 곳이 얼마 많은지 궁금하긴 합니다.
단지 자격요건 사항에 나온 것들을 다 할 수 있다고 거짓 나열하는게 나을지도 모르겠습니다.
최근에 모 회사 연구직 쪽으로 면접을 봤었는데, 저보고 기술직쪽이 더 어울린다고 하더군요. 아마도 이력서에 프로젝트 위주로 나열을 해서 그런 것인지도 모르겠습니다. 연구직을 하려면 이 사회에서는 기본적으로 석사라도 나와야 하는 것 같습니다. 첨언을 하자면 그 회사 연구직에는 제가 이끌던 석사출신 팀원이 있습니다 ^^;;

최재훈
17 years ago

작년에 외국계 컨설팅 회사의 인턴직을 얻어보려고 영문 이력서를 작성했었습니다. 먼저 ‘Resume Software Engineer’ 등의 키워드로 이력서 예제를 찾았습니다. 그런데 재미있는 것은 Concept이란 항목을 둔다는 사실이었습니다. Design Patterns, Refactoring, SOA 등을 적어넣었는데, 이런 식으로 이력서를 작성하는 게 널리 퍼져 있더군요.

mosaic
17 years ago

좋은 글 잘 읽었다.
늘 열정을 가지고 진지하게 고민하는 데서 많은 자극 받는다.

최재훈
17 years ago

늙은이의 잔소리지. 큭.