정리 노트

초보에서 고급까지, 웹으로 프로그래밍 배우기

초급편 : 문법 배우기

■ 웹사이트 제작 A부터 Z까지 ‘생활코딩’

■ 따라하면서 배우는 웹프로그래밍 ‘코드카데미’

■ 어린이용 코딩에서 아이폰 앱 개발 연습까지 ‘코드닷오아르지’

중급편 : 예문 익히기

■ 검색한 코드를 웹에서 테스트한다, ‘런어블’ 

■ 코드계의 지식iN ‘스택오버플로우’

고급편 : 실전 연습

■ 프로그래밍 실력을 측정해 보자, ‘해커미터

■ 프로그래밍 전문 온라인 강의, 유다시티 & 코세라

출처: http://www.bloter.net/archives/176582

개발자에게 추천하는 서적

OKKY에서 활동하시는 개발자님이 만든 서적 리스트입니다.

유용할것 같아서 링크를 가져왔습니다.

https://docs.google.com/spreadsheets/d/1sQQmSalRUcPXFz8uJodAcxrad_19oHAlvCSj35VVX3c/edit?usp=docslist_api

출처:http://okky.kr/article/327965

[펌]개발은 암기과목이 아니다

가끔씩 질문 게시판에 들러 글을 읽다보면 오류 내용을 통째로 복사해서 붙여 넣고 "이런 오류가 생겼는데 어떻게 해야 하나요?" 와 같은 식의 질문이 너무 많은 것 같아 안타까운 마음이 듭니다.

개발은 절대 암기로 배울 수 있는 영역이 아닙니다. 어떤 메시지가 나오면 어떤 부분을 고치면 된다는 식의 사례를 많이 외운다고 디버깅 능력이 높아지지는 않습니다.

프로그래밍 과정에서 발생하는 오류 메시지는 복사해서 검색을 하라고 나오는 것이 아니라 읽고 원인에 대해 생각하라고 제공되는 것입니다. 디버깅이 이런 경우에 이렇게 고치고 저런 경우에 저렇게 고치는 공식을 외워서 적용하는 과정이라면 오류 사전 같은 게 벌써 나왔겠지요.

예를들어, 커넥션 풀을 사용하다 "Connection Pool Exception: Cannot get a connection, pool error Timeout waiting for idle object"와 같은 오류를 접했다면, 가장 먼저 할 일은 복사해서 구글에서 검색하거나 질문 답변 게시판에 "이런 오류 났는데 어떻게 해야되요?"라고 묻는 것이 아니라 오류 내용을 읽어보는 것입니다.

그래서 '커넥션 풀', '타임아웃', '아이들 객체' 같은 개념들이 어떤 의미를 가지는지 이해하려고 노력하고, 안되면 관련 문서를 찾아보는 과정을 거치는 것이 정상입니다.

'커넥션 풀'이 무슨 개념이고 왜 사용하는지를 이해했다면 아마도 '아이들 객체'가 대기 상태의 데이터베이스 연결을 뜻함은 어렵지 않게 유추할 수 있을 것입니다. 스택트레이스를 읽을 줄 안다면 해당 오류가 'commons-dbcp'라는 커넥션 풀 라이브러리에서 발생하는 것임도 알아볼 수 있을테니 필요하면 해당 라이브러리의 프로젝트 페이지에 찾아가 문서를 참조할 수도 있을 것입니다. (인터넷 검색은 보통 스택트레이스를 통째로 검색하는 게 아니라 이런 경우 'dbcp'라는 키워드로 프로젝트 페이지를 찾을 때 쓰는 것입니다.)

이렇게 기본 개념들을 다시 정리했으면 이젠 왜 그런 문제가 생겼는지 연역적 추리를 통해 원인을 찾아보면 됩니다.

타임아웃이 될 때까지 대기 상태의 연결을 얻지 못하고 포기했다는 건 어떤 경우에 발생할까 생각해보면 어렵지 않게 '모든 연결이 타임아웃 시간 동안 사용 중인 경우'가 원인임을 유츄할 수 있습니다. 그럼 다음 단계로, 어떤 경우에 타임아웃 시간 동안 연결을 항상 사용하게 되는 지 고민해보면 대략 다음과 같은 논리적 '경우의 수'가 발생하는 것을 알 수 있습니다:

1. 연결을 한 번에 너무 오래 사용하는 경우
2. 커넥션 풀이 예약하는 연결 갯수가 지나치게 적은 경우.
3. 지나치게 짧은 시간 동안 대기하는 경우.

이런 경우 이해가 가지 않으면 머릿속으로 비슷한 경우를 형상화하거나 비유해서 이해해보는 것이 도움이 됩니다. 예컨대 커넥션 풀의 자원 관리 모델은 은행을 방문해서 대기표를 받고 업무를 보는 것과 비슷합니다.

은행 업무를 보기 위해 들렀다가 사람이 너무 많아서 점심시간 내내 기다리다 되돌아갔다면 이유가 무엇이었을지는 아마 은행 사진을 찍어서 게시판에 질문하지 않아도 누구나 쉽게 이해할 수 있을 것이라 생각합니다.

점심시간이라는 정해진 기간이 타임아웃 기간이고, 은행 창구가 얻으려는 리소스, 즉 데이터베이스 연결이고, 해당 지점 창구의 갯수가 커넥션 풀의 크기('max idle')라면 앞서 발생한 오류의 원인이 되는 경우의 수를 직관적으로 이해할 수 있을 것입니다:

1. 연결을 한 번에 너무 오래 사용하는 경우 -> 예) 진상 고객.
2. 커넥션 풀이 예약하는 연결 갯수가 지나치게 적은 경우 -> 창구나 담당 직원 부족.
3. 지나치게 짧은 시간 동안 대기하는 경우 -> 바빠서 빨리 사무실도 돌아가야하는 경우.

이렇게 경우의 수까지 추출했다면 그 다음으로는 실제 지금 프로젝트가 어느 경우에 해당하는지 검증만 하면 됩니다. 1번의 경우라면 정말 오래 걸리는 질의가 있는지, 혹은 질의는 짧게 끝나도 연결을 닫지 않아 계속 사용 중 상태로 남아있는 경우가 있는지 찾아보면 되겠지요.

사실 이번 오류의 예는 얼마전 실제로 이곳 질문 게시판에서 읽은 사례입니다. 질문자는 역시 오류 메시지만 복사해서 질문을 올렸고 이에 대한 답은 "'removeAbandoned' 속성을 설정하면 되더라" 였습니다.

DBCP 라이브러리의 'removeAbandoned' 속성은 연결을 일정 시간 닫지 않았을 때 이를 강제로 해제하는 속성입니다. 이는, 앞서 말한 경우의 수 중 1번의 경우, 또 그 중에서도 질의가 오래 걸리는 것이 아니라 개발자가 연결 해제를 잊었을 경우에만 적용될 수 있는 해법입니다. 그나마도, 정상적인 해결 방법은 해당 부분을 찾아서 연결 해제 코드를 넣는 것이기 때문에 임시 방편이나 미봉책에 불과하다고 할 수 있습니다.

이는 비유를 하자면, 내가 은행 지점장인데 점심시간에 사람이 붐벼서 고객 불만 사항이 많은 경우에 덮어 놓고 "한 사람당 창구는 3분씩만 쓰게 하라"고 강제하는 것입니다. 실제로는 창구를 하나 더 열거나 창구 하나 잡고 한 시간씩 떼를 쓰는 진상 고객 한 명만 처리하면 될 문제를 덮어놓고 "창구가 붐비면 이용 시간을 제한한다"는 '해법'을 공식처럼 적용한 결과입니다.

그럼에도 불구하고 이런 식으로 문답이 오가는 것은 질문자나 답변자 모두 올바른 디버깅 방법을 이해하지 못하고, 그냥 어떤 오류가 발생하면 어떻게 대처한다는 단편적 지식을 많이 쌓으면 개발 능력이 높아질 것으로 기대하는 잘못된 인식을 가지고 있기 때문입니다.

그런 습관이 생긴 경우 흔히 보는 현상이 무작정 아무 것이나 바꾸어 보는 것입니다. 검색해서 해결이 안되면 지푸라기라도 잡는 심정으로 개발 환경도 새로 설치해보고, 어제는 된 것 같은데 오늘부터 안된다면 어제자 소스로 롤백해보기도 하는 식으로 시간 낭비를 하는 것은 흔하게 볼 수 있습니다.

역시 은행 지점의 예로 비유를 하자면 사람이 많아 불만이 접수되면 일단 인테리어도 바꾸어보고 그런 문제가 없는 지점과 직원들도 서로 교체해보고 하는 식의 쓸데없는 시간 낭비를 하는 것입니다.

혹시 해당 질문 답변 글을 쓰신 분들이 이 글을 보시고 기분이 상하셨다면 죄송합니다만, 저는 단지 해당 사례가 바로 기억에 떠올라서 예시로 들었을 뿐 이는 그 분들만의 문제도 아니고 그 분들의 잘못이라고만 할 수 있는 것도 아니라고 봅니다.

이 곳의 질문 답변 게시판만 봐도 단순히 오류 내용 복사해 붙여넣고 내용을 이해하려는 어떠한 노력 없이 "이런 오류가 생겼는 데 어떻게 하나요?"하고 물어보는 글은 너무도 흔하게 접할 수 있습니다. 그리고 "이 것 저 것 다해봐도 안되요", "어제까진 됐는데 갑자기 안되요", "이클립스도 다시 깔아봤어요" 같은 절박한 푸념도 쉽게 보는 내용입니다.

제 생각에 이는 신입 개발자의 자질보단 그런 신입 개발자를 키워내는 시스템의 문제가 더 크지 않나 싶습니다. 개발자를 양성하는 학원은 많지만 개념이나 접근 방법을 제대로 가르치기보단 단 시간에 스프링 MVC 예제 따라해보기 같은 식으로만 수업을 진행하니 정작 중요한 내용은 수박 겉핥기 식으로 넘어가게 된 것이 아닌가 생각합니다.

또한 실무에서도 회사들이 면접에서 "스프링은 써봤어요?" 같은 걸 물어보지 디버깅을 어떻게 하는지, 객체지향을 얼마나 이해하고 있는지 같은 근본적인 지식을 따지지 않기 때문에 개발자로 입문하는 분들이 무턱대고 준비없이 완전히 이해하지 못하는 코드를 따라 치는 연습만 하니까 원래 개발은 그런 식으로 하는 것이다라는 착각을 하게 되는 게 아닌가 싶습니다.

정리하면, 개발은 원리를 이해하고 이를 적용해서 문제를 해결하는 최적의 답을 찾는 과정이지 '스프링-마이바티스' 같은 정해진 답 하나를 반복 숙달해서 아무데나 가져다 쓰는 단순 반복 작업이 아닙니다.

또한 디버깅은 문제의 원인을 연역적 사고 과정을 통해 찾아내는 절차이지, 결코 "A의 오류 메시지에는 B로 대응"과 같은 공식을 찾아 적용하는 작업이 아닙니다.

혹시라도 그런 식의 잘못된 접근 방법으로 개발에 입문한 신입 개발자분들이 계시면 지금부터라도 올바른 방법이 무엇인지 고민해 보셨으면 좋겠습니다.

그래서 앞으로는 질문 답변 게시판에 "이런 오류가 났는데 도와주세요" 같은 글보다는 최소한 "이런 오류가 났는데 메시지에서 이런 개념이 이해가 가지 않습니다" 또는 "이런 오류는 이럴 때 발생하는 것 같은 데 다른 경우가 있을까요?" 같은 최소한의 사고 과정이 드러나는 질문을 보다 많이 볼 수 있게 되었으면 좋겠습니다.

출처:http://okky.kr/article/311337

이글을 보고 많이 반성하게 되네요. 저또한 문제에 대한 정확한 해결분석보다 문제 대한 빠른 해답을 찾을려고 하는 경향이 있는데 앞으로 이런 습관을 고치려고 노력해야겠다는 생각이드네요.

이상하게 한국 남자들은 사진을 찍을 때 잘 웃지 않는다. 그런 점에서는 기자 또한 마찬가지. 왠지 사진 찍으면서 웃으면 나답지 않은 사진이 나와 버릴 것만 같은 생각이 들어서 무의식 적으로 입을 다물게 된다. 분위기 있게 찍으려면 근엄한 표정을 지어야 할 것 같은 생각이 들기 때문이기도 하다. 하지만 막상 사진을 보면 근엄하게 찍어봐야 못생긴 얼굴 어디 안 간다. 차라리 웃으며 찍은 사진이 그나마 남들 보기에 기분이라도 좋다.

어쩌면 우리는 프로그래밍에 임할 때에도 너무 근엄하게 혹은 너무 진지하거나 책임감에 억눌려 있는 것은 아닐까? 마이루비닷넷(http://myruby.net)이란 블로그를 운영하고 있는 강문식 씨는 특집 6부에서 그러한 개발자들의 문제점들을 해소하는 것이야말로 개발 고수로 가는 길이라고 제시해 주고 있다.

한 달이 멀다하고 쏟아져 나오는 새로운 기술들. 개발자는 정말 배우고 익혀야 할 기술들이 너무나 많다. 어찌 생각하면 이런 일들은 개발자들에게 부담으로 느껴진다. 짜증나고 지겨운 현업에 어렵고 복잡한 새 기술들을 더해야 하니 그럴 만도 하겠다. 하지만, 강문식 씨는 오히려 그것들을 즐기는 법을 터득한 고수다.

5년 전부터 운영해 오고 있는 그의 블로그가 바로 그 증거다.

그는 새로운 기술이 나올 때마다 그것들을 이용하여 작고 재미있는 애플리케이션을 만들어본다. 아주 작고 간단하게 만들 수 있는 애플리케이션들이기 때문에 만드는데 많은 시간과 노력을 들일 필요는 없다. 단지, 새 기술에 자신의 아이디어를 더하여 무언가 창조해 낸다는 것이 중요한 것이다. 이러는 과정에서 새 기술에 대해 이해하고 익히게 되는 것은 당연한 일. 하지만, 여기에 또 한 가지 그만의 비법을 더함으로서 재미삼아 만든 새 애플리케이션에 생명이 더해진다. 바로 블로그다. 자신이 만든 것들에 대한 정보와 소스코드를 몽땅 블로그에 공개하여 그것을 다른 사람들에게 전파하고, 자신이 미처 생각지 못했던 것들에 대한 피드백을 받으며 자신의 아이디어를 성장시켜 가는 것이다.

이렇게 성장한 아이디어는 강문식 씨 자신의 업무에 도움을 주기도 하고, 새로운 프로젝트에 적용되기도 한다. 새로운 기술이 나올 때마다 스트레스 없이 자신의 취미를 즐길 수 있고, 미리미리 습득해 둔 신기술은 누구보다 트렌드에 빠른 개발자로 그를 성장시키고 있다. 말로 내뱉기는 쉽지만 실천하기는 어려운 일이기에 지난 5년간 그가 블로그를 통해 또 커뮤니티를 통해 쌓아온 일들의 가치가 더욱 크게 느껴지는 것일 터다.
****************************************************************************

프로그래밍은 재미있다. 그 이유를 꼽자면 여러 가지가 있겠지만, 우리보다 훨씬 먼저 이에 대해 이야기한 사람이 있으니 그의 글을 인용해보자. 프레드 브룩스(Frederick P. Brooks, Jr)는 『The Mythical Man Month』에서 프로그래밍이 재미있는 이유를 다음과 같이 말했다.

무엇인가를 만드는 일, 즉 프로그래밍은 창조의 즐거움을 준다. 그리고 이렇게 만든 결과물이 다른 이에게도 유용한 것이 되므로 보람과 기쁨을 느낄 수 있다. 또한 정교한 퍼즐 문제를 풀기위해 몰입하고, 끝내 이를 풀어냈을 때 느낄 수 있는 희열도 있다.

이런 느낌은 독자들도 경험해봤을 것이다. 그리고 항상 무언가를 배우고 있다는 기쁨도 빼놓을 수 없다. 프로그래머의 일상은 단순 반복이 아니기 때문이다. 마지막으로 비교적 다루기 쉬운 수단을 가지고 일하는 즐거움이다.

대부분 공감할 수 있는 내용들이다. 프로그래밍은 본디 재미있는 일이다.

필자가 프로그래밍을 처음 접한 것은 초등학생 때였다. 학원을 더 오래 다닌 형들이 배우는 C 언어가 엄청 대단해 보이던 시절이었다. GW-Basic 화면에 PLAY 명령과 함께 EDCDEEE2DFEDC4처럼 알 수 없는 코드들을 입력하면 익숙한 음악이 연주되던 그 프로그램이 정말 신기하고 재미있었다. 그리고 LINE, CIRCLE 등의 명령으로 그려지는 그래픽은 아름답기까지 했다.

그 때부터였다. 프로그래밍 세계에 중독된 것이 말이다. 다들 그런 경험이 한번쯤 있을 것이다. 내 손으로 처음 만든 프로그램이 잘 돌아갈 때의 그 즐거웠던 경험은 잊을 수 없다. 독자 여러분도 이런 생각이 들지는 않는지 모르겠다. 지금 혹시 어떤 이유에서건 개발이 즐겁지 않다면, 그 때를 잠시 떠올려보면 어떨까? '그 때 참 재미있게 프로그래밍 했었지, 실력도 많이 늘었던 것 같아.'라고 말이다.

어떤 일을 하건 마찬가지겠지만, 특히나 프로그래머는 즐겁게 일해야 한다. 개인적인 소망은 모든 개발자들이 프로그래밍을 처음 접하던 그때의 즐거움을 계속 간직할 수 있으면 좋겠다.

코드는 프로그래머의 생각을 비춰주는 거울과도 같다. 즐겁게 행복하게 개발해야 더 나은 제품이 나온다. 지금부터는 즐거운 프로그래밍을 위해 필자가 종종 활용하는 방법을 몇 가지 소개해볼까 한다.

새로움 더하기
작년 초의 일이다. 스프링노트 서비스 개발을 시작한지도 꽤 되어서인지 이제 슬슬 개발에 익숙해지기도 하고, 또 일부 코드는 자신을 리팩토링 해달라며 나쁜 냄새를 조금씩 풍기기 시작했다. 당시 스프링노트 소스는 단위 테스트도 부족해서, 매번 불편함을 느끼고 있었다. 이 불편함이 쌓이면 안 될 것 같기도 했고, 개인적으로도 분위기 전환이 필요하다고 느꼈다.

그래서 현재 개발 중인 코드에 조금 새로운 시도를 해보기로 결정했다. 당시 많이 쓰이고 있던, 단위 테스트 라이브러리인 xUnit 대신, BDD 프레임워크인 RSpec(http://rspec.rubyforge.org/)을 활용해 기존 코드에 스펙을 붙이고, 또 새로 추가되는 기능은 BDD를 따르기 시작했다.

처음 해보는 RSpec 코딩은 무척 즐거웠다. 그리고 테스트 커버리지 툴인 rcov로 자주 테스트 커버리지를 측정하며 목표 수치(90%)에 조금씩 다가갔다. 지금 돌이켜서 생각해보니, 적절한 시점(프로젝트가 지겨워질 만한)에 새로움을 더해 업무 속도도 떨어뜨리지 않고, 개인적인 수련도 하고, 코드 품질도 올라가는 일석삼조의 효과를 거둔 것 같다.

자신만의 도전과제 만들기
필자는 항상 프로젝트를 시작할 때 그 프로젝트팀의 성공 외에도 개인적인 도전 과제(개발자로써)를 부여하는 편이다.

예를 들면, 윈도우 애플리케이션을 개발할 때에는, 당시에 익숙했던 MFC(Microsoft Foundation Class Library) 대신, 처음 사용해보는 WTL(Windows Template Library)을 도입해서 장단점을 확인해 보았다. 또 PHP를 이용해 개발하는 프로젝트에서 MVC 프레임워크를 직접 만들어 보기도하였다.

그렇게 함으로써 조금 더 프로젝트의 열정을 가질 수 있게 되었다. 현재는 스프링노트 프로젝트의 테스트 커버리지 수치를 100%로 계속 유지하며 개발해보는 실험을 재미있게 진행하고 있기도 하다.

이미 진행 중인 프로젝트가 있다면, 거기에 약간의 새로움을 가미해보길 바란다. 그렇다면 더 즐겁게 일할 수 있을 것이다. 물론 그 새로움이란, 자기계발과 프로젝트에 모두 도움이 되는 것으로 선택하는 것이 좋다. 그리고 작은 목표(기왕이면 측정 가능한 것)도 도움이 된다. 예를 들면 코드 품질을 나타낼 수 있는 몇 가지 방법(Code Metrics)을 적용할 수 있을 것이다.

작은 아이디어 구현하기
기존 프로젝트에서 새로움을 쉽게 찾지 못한다면, 가끔은 완전히 다른 프로젝트를 시도해 보는 것도 좋다. 그러기 위해서는 평소에 생각나는 아이디어, 한번쯤 만들어보고 싶은 프로그램을 위키 등에 정리해두는 것이 도움이 된다. 메모를 할 때는 간단한 아이디어 설명과 왜 만들어보고 싶은지, 만들면 얼마나 걸릴지를 대략적으로 적어두는 것이 좋다.

그러면 나중에 여유가 생겼을 때 이 페이지를 열고 아이디어 목록 중 하나를 골라서 만들어볼 수 있어서 좋다. 거창한 프로젝트보다는 작은 장난감 프로그램이나 프로토타입을 만드는 것이 적당하다. 예를 들어 <화면 1>은 필자가 최근에 적은 아이디어 메모다.

<화면 1> 아이디어 메모의 예

그리고 어느 날 집중력이 떨어지는 느낌이 들어 위키에서 이 아이디어를 꺼내서 직접 구현해봤다. <화면 2>는 이렇게 구현된 애플리케이션이다. 내가 직접 사용할 프로그램이라 스펙이 명확하고, 크기도 작아서 예상했던 대로 한 시간 안에 충분히 만들 수 있었다. 하지만 지금까지도 잘 사용하고 있는 유용한 프로그램이기도 하다. 물론 코코아 프레임워크를 이용해 처음 만들어본 프로그램(예제가 아니라)이라는 면에서도 새로웠다.

<화면 2> <화면 1>의 아이디어로 만든 애플리케이션

'작은 아이디어 구현하기'는 내가 평소에 해보고 싶었던 것을 직접 만들어보는 것이므로 즐겁다. 그리고 짧은 기간에 작은 성공을 통한 성취감도 맛볼 수 있다. 현재 업무에 지치고, 피곤해서 일이 손에 잡히지 않는다면 작은 아이디어 구현하기를 통해 새로운 에너지를 얻을 수 있다.

새 시대의 장난감, 오픈API
최근에 구현한 또 다른 아이디어는 슬러거(Slugger, http://myruby.net/pages/391476)라고 이름 붙인 블로깅 툴이다. 이 프로젝트가 재미있었던 점은 일반적인 웹 애플리케이션과 달리, 데이터베이스를 전혀 사용하지 않고 만든 순수 매시업 애플리케이션(Mashup Application)이라는 점이다.

슬러거에서 블로그 포스트와 환경 설정 등은 스프링노트에 저장하고, 각 포스트에 대한 사용자의 댓글은 미투데이에 저장했다. 그 결과 두 서비스의 장점을 모두 취할 수 있었다. 평소에 계속 글감을 만들어두었던 스프링노트의 글들이 바로 블로그 포스트로 노출되어 편하기도 하고, 이 글이 미투데이에서 유통되어 그 무섭다는 무플도 피할 수 있었다.

결과뿐만 아니라, 과정에서도 데이터베이스를 설치하고 호출하는 것보다 쉬운 방법으로 이미 잘 만들어진 OpenAPI를 사용해 개발에 필요한 시간을 단축할 수 있었다. 현재 필자의 블로그에서도 사용하고 있는 슬러거는 고작 100여 줄의 코드로 4시간 동안 만든 것이다.

매쉬업 애플리케이션이 좋은 이유는 소위 말하는 맨땅에 헤딩을 피할 수 있기 때문이다. 좋은 기능들을 웹 서비스 형태로 노출하는 웹사이트가 많으므로 이를 잘 선택해 활용하면, 만들 때도 재미있고, 꼭 만들어보고 싶은 가치에 집중할 수 있다. 물론 이 편이 더 만들기도 쉽다. 그리고 매쉬업을 만들면 기존 서비스를 사용하던 사용자가 함께 따라온다. 따라서 더 빠르고 많은 사용자들의 목소리를 들을 수도 있다.

이렇게 만든 애플리케이션을 오픈 소스로 커뮤니티에 공개하면 이 프로젝트는 더 큰 생명력을 얻게 된다. 그리고 여러 면에서 내게 도움이 되는 피드백을 받을 수도 있다. 슬러거의 경우, 직접 설치 매뉴얼을 만들어주신 분도 있었고, 필자의 소스에서 레일스의 새로운 면을 배울 수 있어서 좋았다는 분도 있었다. 이처럼 여러 사람들에게 관심을 받을 수 있는 것도 개발자의 즐거움 중 하나다.

즐거운 언어, 루비
필자와 친하게 지나는 한 선배가 프로그래밍을 잘하려면 매년 새로운 언어를 하나씩 배우라고 조언을 해준 적이 있다. 이 말은 여러 언어를 통해 다양한 관점을 가지라는 의미일 것이다. 필자가 최근 주로 사용하고, 좋아하는 언어는 루비(Ruby)다. 루비를 통해 개발의 재미를 많이 느꼈는데, 그래서 이 글에서도 잠깐 소개해볼까 한다.

루비가 가진 모토는 '프로그래머의 단짝 친구'고, 개발자인 마츠는 루비를 기계가 아닌 프로그래머 자신을 위해 만들었다고 말한다. 이 말은 문법이 친근하다는 의미이기도 하지만, 필자는 개발자를 키우는 언어라는 의미로 받아들인다. 루비는 말랑말랑한 문법 때문에 표현력이 뛰어나다.

그래서 한 가지 로직을 가지고도 정말 다양한 방식으로 표현 가능하다. 그리고 코드 가독성이나 미적인 면(Code Beauty)을 중시하는 커뮤니티의 분위기 덕분에 항상 내가 작성한 코드보다 더 나은 코드를 찾아볼 수 있다. 그래서 개발자에게 지속적인 자극을 주고, 여기서 힌트를 얻은 개발자는 더 나은 코드를 작성할 수 있게 된다. 이것이 개발자를 키우는 언어라는 표현의 의미다.

그리고 특별히 더 즐거운 이유는 커뮤니티의 생동감 넘치는 분위기 때문이기도 하다.

최근 커뮤니티에서는 루비 2.0과 레일스 2.0이 활발하게 개발되고 있고, 이에 대한 열띤 토의도 오가고 있다. 말하자면 루비 커뮤니티는 건강하다. 이런 커뮤니티를 지켜보고 그 일원이 되는 것도 즐거운 경험이다.

나는 프로그래머라서 행복하고 즐겁다. 그리고 내 동료 프로그래머들도 모두 즐거웠으면 좋겠다. 즐겁기만도 부족한 시간들이다. 마지막으로 한 말씀 드리자면

"현재를 즐기세요. 그러면 어느새 수퍼 개발자가 되어 있을 거예요!" @

스프링노트 OpenAPI

스프링노트(http://www.springnote.com/)는 위키 기반 인터넷 노트 서비스다. 이 서비스는 REST 방식의 OpenAPI를 제공하고 있어서, 개발자들이 다양하게 활용할 수 있다. API를 활용하여 쉽게 페이지 리소스를 만들고 읽으며 쓰고, 지울 수 있다. 혹시 레일스 개발자라면 2.0에서 추가될 액티브 리소스의 장점을 스프링노트에서 체험해볼 수도 있다(SpringnoteResources라는 액티브리소스 Wrapper 라이브러리를 배포하고 있다). 자바나 PHP를 포함한 다양한 언어에 대한 바인딩이 있고, 없더라도 HTTP에 대한 이해만 있으면 어렵지 않게 API를 호출할 수 있다. 자세한 도움말은 http://dev.springnote.com/를 방문해보길 바란다. 스프링노트 OpenAPI를 활용한 매쉬업이 많이 나올 수 있기를 기대한다.

<화면 3> 스프링노트 개발자 페이지

출처:http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=5044&MAEULNO=28&no=38156&page=1

 

넷플릭스는 전세계에 유료 가입자만 5700만명에 이르는 명실상부한 세계 최대 유료 동영상 스트리밍 서비스다.

넷플릭스는 한 달에 적게는 7.99달러만 내면 영화와 TV 프로그램과 같은 영상 콘텐츠를 맘껏 볼 수 있는 온라인 동영상 스트리밍 서비스다. 명실상부한 세계 최대 사업자로, 유료 가입자만 5700만명에 이른다. 원래 미국에서 시작된 서비스지만, 가입자 5700만 중 1800만명이 해외 구독자다. 넷플릭스는 앞으로도 미국 방송 업계 석권을 넘어 해외 시장 개척에 적극 나서 성장세를 이어나갈 기세다.

“인터넷 + 영화 = 넷플릭스”

‘넷플릭스’라는 이름은 인터넷(NET)과 영화(flicks)에서 따왔다. 리드 헤스팅즈가 넷플릭스를 창업할 당시부터 인터넷으로 영화를 유통할 생각을 꿈꾸고 있었기 때문이다. 하지만 처음부터 스트리밍 방식으로 콘텐츠를 유통한 것은 아니다. 1997년 넷플릭스는 비디오와 DVD를 우편·택배로 배달하는 서비스로 시작했다. 인터넷 스트리밍까지 사업을 확장한 건 그로부터 10년 뒤인 2007년이다.

넷플릭스는 1997년 DVD 대여 서비스로 시작했다. <사진: 위키피디아>

블록버스터를 파산시키다

리드 헤스팅스 넷플릭스 창업자

“창업자는 반드시 반대를 보는 관점(contrarian view)을 가져야 한다.” - 리드 헤즈팅스 넷플릭스 창업자

1997년 리드 헤스팅즈가 DVD 대여 서비스로 넷플릭스를 시작했을 당시 이미 미국엔 부동의 업계 강자가 있었다. 비디오 대여 체인 1위 사업자였던 블록버스터다. 블록버스터는 비디오를 빌려보는 문화가 막 움트던 1980년대를 타고 성장했다. 2005년 기준으로 미국에만 점포가 5500곳이 있었을 만큼 시장 지배자였다. 하지만 치고 올라오는 넷플릭스에게 결국 왕좌를 내주고 지난 2013년 파산했다. 골리앗 블록버스터를 상대로 신생기업이었던 넷플릭스가 어떻게 시장 구도를 뒤엎어 버렸을까.

답은 ‘역발상’에 있었다. 블록버스터의 운영 방식은 국내 비디오 대여점과 비슷했다. 빌려간 비디오를 약속한 기간 안에 반납하지 않으면 연체료를 무는 식이었다. 넷플릭스의 전략은 아예 달랐다. 연체료를 아예 없애버렸다. 그 대신 넷플릭스는 구독료를 받기 시작했다. 월 사용료를 받고 비디오를 반납했을 때 다른 비디오를 보내주는 식이니, 장기 연체하는 고객이 생길 염려도 없다.

미국 방송 산업의 역사를 새로 쓰다

넷플릭스는 OTT(Over The Top, 셋톱박스를 넘어서는) 서비스다. OTT 서비스는 별도의 셋톱박스 없이 인터넷을 통해 볼 수 있는 TV다. 최근 미국에서 OTT는 기존 콘텐츠 유통 구조를 바꾸고 있다는 평가를 받는다. 수백 개의 케이블TV 채널이 지상파 이상의 영향력을 갖고 있는 미국 시장에서 인터넷과 모바일 등을 통한 OTT 서비스들이 빠른 성장세를 보이며 기존 방송사들을 위협하고 있다. 그 행렬의 가장 앞에 있는 기업이 바로 넷플릭스다.

넷플릭스는 과거 블록버스터 시장을 잠식해 나갔던 것처럼 기존 지상파 방송과 케이블TV의 역할을 대체하고 있다. 지난 2013년에는 미국 최대 케이블방송 <HBO>의 가입자 수를 넘어섰다. 넷플릭스는 또한 돈을 지불하고 영상을 구독하는 서비스 가운데 미국에서 제일 많이 쓰는 플랫폼이다. 에릭슨이 지난 2014년 미국에서 주문형 동영상(VOD) 서비스를 이용하는 소비자 비율을 조사했더니, 넷플릭스 이용자가 전체의 50%에 달했다.

넷플릭스 성장세를 견인한 주된 요인으로는 싼 가격을 꼽는다. 넷플릭스는 한 달에 최소 7.99달러만 내면 콘텐츠를 무제한으로 즐길 수 있다. 케이블 유료 방송 서비스 이용료는 한 달에 최소 50달러 정도이니, 3~4배는 비싸다. 게다가 케이블방송은 셋톱박스가 달린 TV 앞에서만 봐야 한다는 불편함도 있다. 하지만 넷플릭스는 윈도우 PC와 매킨토시, X박스360, 플레이스테이션3, 닌텐도 위, 애플TV, 아이패드, 아이폰, 구글TV 등 다양한 시청 환경을 지원한다.

최근에는 경쟁력이 단순히 가격에만 있진 않다. HD나 4K 등 화질 면에서도 기존 방송 플랫폼들의 장점을 흡수하고 있는 모양새다. 차세대 TV로 거론되는 4K 해상도의 초고화질TV(UHDTV)에 대처하는 일이 기존 케이블 채널보다 상대적으로 쉽기 때문이다. 넷플릭스는 전송 시스템만 적용하면 되기에, 이미 몇몇 콘텐츠에서는 4K 스트리밍을 시작했다. 하지만 케이블 채널은 UHD 방송 전송을 위해 셋톱박스뿐 아니라 전송망도 손봐야 하는 난관이 있다.

빅데이터를 활용한 추천 알고리즘

넷플릭스의 성공요인으로 꼽히는 것이 정교한 추천 알고리즘이다.

아마존의 스트리밍 서비스인 ‘아마존 인스턴트 프라임’에 제공되는 콘텐츠 수는 8만종이 넘는다. 올레TV와 같은 국내 IPTV들도 보통 10만종 이상이다. 하지만 전세계 유료 가입자 5천만명이 즐기고 있는 동영상 스트리밍 서비스 최강자 넷플릭스가 보유한 콘텐츠 수는 채 1만종도 되지 않는 것으로 알려져 있다. 10분의 1 수준의 콘텐츠 수로 어떻게 가입자를 사로잡을 수 있었을까. 비결은 ‘추천 알고리즘’이다.

적은 영상 콘텐츠로 사용자 만족도를 높이기 위해 빅데이터를 적극 활용하는 게 넷플렉스의 전략이었다. 넷플릭스가 2000년도에 내놓은 사용자의 취향을 정확히 파악해서 보고 싶은 영상을 추천해주는 알고리즘은 넷플릭스를 지금의 자리에 있게 해준 일등공신이다. 넷플릭스는 시청자에게 영상마다 별점을 매기게 한 뒤 평점을 기반으로 그 시청자가 선호하는 영상들 사이의 패턴을 분석해 그 다음에 볼 영상을 미리 알아맞힌다.

넷플릭스의 알고리즘은 적은 콘텐츠를 효율적으로 사용할 수 있게도 해줄 뿐 아니라 광고 효과라는 엄청난 이득도 있다. 콘텐츠 제작사 입장에선 자신들의 잠재 시청자에게 더 잘 도달할 수 있기 때문이다. 실제로 관심이 있는지 없는지도 확실치도 않은 대중을 상대로 광고비를 쏟는 것보다 넷플릭스 알고리즘대로 정말 그 영상을 볼만한 시청자에게 추천을 해주는 게 훨씬 효과적일 것이다.

그래서 넷플릭스는 추천 알고리즘에 투자를 아끼지 않는다. 추천 알고리즘을 더 정교화하기 위해서 추천 알고리즘 대회인 ‘넷플릭스 프라이즈’를 2006년부터 3년 동안 개최하기도 했다. 넷플릭스는 이 대회에서 추천 알고리즘의 정확도를 10% 향상시킬 수 있는 팀에 100만달러, 우리돈으로 10억원이 넘는 상금을 내걸었다. 최근에는 한발짝 더 나가 컴퓨터가 마치 사람처럼 생각하고 배울 수 있도록 하는 기술인 ‘딥러닝’도 도입했다.

빅데이터를 활용한 컨텐츠 기획/제작

넷플릭스가 자체 제작한 드라마 ‘하우스 오브 카드’

넷플릭스는 콘텐츠를 유통하는 플랫폼으로만 유명하진 않다. 성공한 콘텐츠 생산자이기도 하다. 넷플릭스는 2012년부터 콘텐츠를 제작사에서 구매해 제공하는 걸 넘어 자체적으로 콘텐츠를 만들어내기 시작했다. 빅데이터 강자인 넷플릭스는 콘텐츠를 만들 때도 빅데이터를 활용했다. 넷플릭스는 미국 시장 안에서 구독자의 선호도를 철저히 분석한다. 기획부터 주인공 섭외, 배급까지 전반에 걸쳐 빅데이터 분석을 활용한다.

대표적인 사례가 [하우스 오브 카드]다. 이 작품은 1990년에 영국 <BBC>에서 제작된 같은 이름의 드라마를 원작 삼아 리메이크했다. 넷플릭스는 데이터 마이닝을 통해 시청자의 성향을 파악한 뒤 그들이 원하는 연출 스타일이나 좋아할 만한 배우 등을 예측해 섭외했다. 분석은 적중했다. [하우스 오브 카드] 시즌1이 공개된 뒤 시청자 가운데 85%가 만족했다. 또한 에미상 3관왕의 영예를 안았을 만큼 대중성과 작품성 모두 인정받았다.

[하우스 오브 카드]가 대박나며 콘텐츠 제작사로 성공적으로 연착륙한 넷플릭스는 [오렌지 이즈 더 뉴 블랙], [마르코 폴로] 등 콘텐츠 제작사로서의 행보에 더욱 열을 내는 모습이다. 투자도 아끼지 않는다. 최근 넷플릭스가 선보인 [마르코 폴로]는 여태껏 나온 TV 드라마 가운데 가장 제작비를 많이 쓴 축에 속한다고 <뉴욕타임즈>는 전했다. [마르코 폴로]의 10편 제작비는 9천만달러에 이른다. 우리돈으로 1천억원이 넘는 거액이다.

“최종적으로 넷플릭스는 세계 최대 콘텐츠 제작사가 될 것이다.” - 테드 사란도스 넷플릭스 최고 콘텐츠 책임자

참고자료

· 넷플릭스의 빅 데이터(Big Data), 인문학적 상상력과의 접점, 조영신 SK 경영경제연구소 수석연구원
· 오! 넷플릭스가 일깨워준 질문들, 미디어토핑(http://mediatopping.com/2015/01/21/oh-netflix-nothing-but-netflix/)
· [IT탐구영역] 넷플릭스, 블로터(http://www.bloter.net/archives/219437)
· 미국 콘텐츠 산업 동향, 한국콘텐츠진흥원 미국사무소

출처:http://navercast.naver.com/contents.nhn?contents_id=82499

몇 달 전 투자도 많이 받고 주목도 받고 있는 한 스타트업 대표로부터 질문을 받은 적이 있다. 개발 일정이 의도한대로 끝나지 못한 책임을 누가 가져가야 하느냐에 대한 질문이었다. 나는 주저 없이 그것은 일정을 제대로 계획하지 못한 프로젝트 매니저와 회사의 책임이 가장 크다고 말했다.

하지만 그 대답을 들은 대표는 별로 탐탁지 않아했다. 그의 생각은 어느 그룹이든 열심히 하는 개발자들도 있는 반면에 요령을 피우는 개발자도 있지 않냐는 것이다. 그런 개발자들의 잘못도 매니저가 가져간다는 것은 부당하다는 것이었다

이런 생각이 이 회사의 대표만의 생각은 아닐 것이다. 대부분의 비즈니스 사람들은 개발자들이 태만하거나 능력이 월등하지 못할 경우에 일정에 차질이 생길 수 있다고 오해를 하는 경우가 많다. 결국 이런 오해로 서로에 대한 신뢰관계를 무너뜨리고 같은 목표와 비전을 가지고 일하는데 있어서 큰 장애가 되고 만다.

개발자들은 느리지 않았다.

실제 프로젝트의 통계를 살펴보면 대부분의 개발 프로젝트는 개발자들의 능력보다도 어떤 의사결정이 늦어지거나 테스트 프로세스가 미흡할 경우의 이유로 늦어지는 경우가 더 많다. 이것을 뒷받침 해주는 데이터가 Sprintly라는 회사에 의해서 발표되었다.

Sprintly는 애자일 기반의 프로젝트 관리 툴을 제공하는 회사로 클라우드 환경에서 많은 개발 팀들이 그 툴을 이용하고 있다. 때문에 그들의 툴을 사용하고 있는 개발팀들의 데이터들을 통해서 특정 패턴들을 발견할 수 있었다.

먼저 개발자들이 티켓을 처리하는 속도가 결코 느리지 않았다는 것이다. 그들은 굉장히 다양한 회사들의 개발 프로젝트들을 조사하였다. 그들은 약 75%의 티켓 즉, 업무 리스트들이 평균 175시간에 해결되는 것을 추출해낼 수 있었다. 즉, 전체 프로젝트가 완료되는 시간에 비추어 굉장히 짧은 시간이었다. 

두 번째로는 실제로 티켓의 개발이 시작 되기 전에 티켓이 수정되거나 우선순위를 조정하기 위해서 굉장히 많은 시간을 보내는 경우가 많았다. 이것을 칸반 이라는 애자일 방법론에서는 리액션 타임이라고 부르는데 주로 티켓을 만들고 우선순위를 정하기 위해서 걸리는 시간을 이야기 한다.

마지막으로 그들의 데이터를 통해서 실제 각각의 업무가 “완료” 단계의 상태에서 “배포준비”로 가는데 까지 시간이 꽤 오래 걸린다는 것을 볼 수 있었다. 이 데이터가 의미하는 것은 실제로 개발된 스펙이 원하던 것인지 검토하고 다시 수정하는 시간이 오래 걸린다는 것이다.

그렇다면 왜 실제 개발 프로젝트가 지연되고 느려지는 것일까?

업무의 잦은 스위칭

먼저 개발자들을 느리게 하는 것은 한꺼번에 다양한 일을 처리해야 하는 경우이다. 즉, 처리해야 할 우선순위가 바뀌거나 먼저 처리해야 될 우선순위의 업무가 생겼을 경우이다. 개발자가 아니고서는 이해하지 못하는 사실이 있다. 

만약 A라는 업무를 50% 정도 완료한 뒤에 B라는 업무를 진행했다고 하자. B의 업무를 진행하고 A를 다시 진행한다며 그 업무는 과연 50%일까? 다른 업무에 머물러 있는 시간과 업무 성격에 따라서 적어도 70% 정도의 업무가 될 때가 많다. 

다양한 실험을 하고 알고리즘을 개발하는 업무라면 더더욱 그 업무에만 집중하는 것이 효율이 좋다. 실제 리드 개발자들은 다양하게 업무들을 스위칭하며 일하는 경우가 많다. 코드리뷰를 수행하고 짝 프로그래핑 그리고 여러 미팅을 다니게 되는데 이런 개발자가 실제 핵심 모듈을 개발하는 역할까지 수행해야 한다면 그 생산성을 보장받기가 어렵다.

조엘 스폴스키 또한 이것에 대한 자신의 의견을 피력한 적이 있다. 

불분명한 요구사항

실제 요구사항들은 지나치다 싶을 정도로 자세하게 작성 되어야 한다. 만약 개발자들이 그 요구사항을 이해하고 있지 않다면 어떻게 개발이 가능할 것인가? 실제 많은 프로젝트들을 보더라도 개발을 시작할 때 보다 자세한 스펙들을 작성하는 경우가 상당하다.

그리고 더 중요한 것은 제품에 대한 책임 결정권자가 그 기능에 대해서 정말 심각하게 고려하지 않은 경우가 많다. 그럴 경우에 개발자들은 왜 이 기능이 사용자에게 필요한지에 대한 이해가 없이 시작한 개발은 결코 창조적인 아이디어가 나올 수 없을뿐더러 그들 스스로도 개발자인지 아님 코더인지에 대한 정체성에 혼란이 오기 마련이다.

요구사항에서는 적어도 기능에 대해서 어떤 기능을 누가 왜 필요한지에 대한 이야기를 풀어내야 하고 더불어 다양한 상황에 대한 테스트 케이스들을 작성해주어야 하는 것이 가장 기본적인 스펙이 된다.

여기서, 요구사항이 터무니 없이 추상적이라면 그것은 더 세부적으로 나눠서 작성해야 한다는 뜻이 된다.

요구사항들의 변경

마지막으로 개발자들에게 있어서 가장 큰 불만 중 하나는 실제 업무가 시작된 뒤에 그것이 다시 바뀌는 경우이다. 개발자들이 변경하는 것 자체를 싫어하는 것은 아니다. 비즈니스 전략과 반응에 따라서 얼마든지 스펙은 변경될 수 있다. 하지만 그런 구체적인 사유와 데이터가 아닌 단지 시작 전에 정확하게 분석하지 못해서 오는 변경이라면 분명 시간적으로 낭비가 되는 것이다. 

물론, 개발자들은 정신적인 데미지도 함께 느끼면서 내가 만드는 것이 없어지거나 바뀔 수 있다는 불안감 때문에 코드 퀄리티에도 영향을 주게 될지도 모른다.

실제 개발을 시작하기 전에 중간 레벨 정도의 목업 프로토타입만 먼저 구현하는 것도 한가지 대안이 될 수 있을 것이다. 포켓웍스(Pocketworks)의 토빈 해리스(Tobin Harris)는 다음과 같이 이야기 했다.

이런 잦은 변화가 수반될 수 있다는 점에서 애자일 방법론에서 이야기하는 짧은 주기를 통해서 만든 결과물을 리뷰하고 다시 일정을 조정한다는 것은 큰 의미가 있다.

매니저들은 개발자들이 성공적으로 그들의 개발 역량을 잘 발휘할 수 있는 환경을 제공해줄 책임을 가지고 있다. 먼저 개발자들에게 딜레이 된 개발일정을 불평하기 보다는 먼저 그들 스스로 자신이 제공한 일정과 환경에 대한 책임을 먼저 생각해 보면 어떨까? 

성공적인 개발팀을 만들기 위해서는 명확한 비전이 공유되어야 하고 비즈니스 사람들과 같은 목표 아래 프로젝트가 진행되어야 할 것이다. 개발자들 또한 자신의 할 일을 줄이기 위해서 토론하고 일하기 보다는 그 목표를 같이 만들어가기 위한 적극적인 참여가 필요하다. 왜냐하면 우리는 코더가 아니라 창작물을 다루는 개발자들이기 때문이다.

필자가 6년전 처음으로 영국의 개발문화를 체험하기 전에는 한국 출신 개발자라는 자부심이 있었다. 종종 한국 개발자들은 여러명이 해야 할 작업을 혼자서 처리하는 다재 다능한 개발자로 비유되어왔다. 타이트한 일정 속에서도 야근을 감수하며 어떤 플랫폼이나 언어를 만나도 두려워하지 않는 이들이라는 이미지도 강했다. 그래서 하루에 8시간씩만 일해온 영국 보다는 하루 최소 10시간 이상을 개발에 전념해 온 한국의 개발자들이 당연히 나을 것이라고 생각했다. 

하지만 정작 외국 개발문화를 체험하면서 한국에서 쌓아온 경럭에 대한 자신감은 사라졌다. 영국에서 고급 개발자들에게 거는 기대와 한국에서 고급 개발자들에게 거는 기대가 확연히 달랐기 때문이다. 6년전 필자는 7년 정도의 실무 경력이 있었기에 당연히 시니어 레벨이나 개발 팀을 이끄는 리드개발자가 되지 않을까 싶었지만 그들의 기준에서는 턱없이 부족한 실력이었다. 

한국에서 개발자 실력이라고 하면 개발 속도와 임무완수 여부에 초점이 맞춰지는 경향이 많다. 즉, 적어도 실력있는 개발자는 일정을 밀리지 않고 잘 끝낼 수 있어야 한다. 하지만 영국에서 실력 있는 개발자라고 하면 주니어 개발자들이 막힌 문제들을 잘 풀어 줄 수 있어야 할 뿐만 아니라 속도보다는 얼만큼 코드를 객체지향 관점에서 적재적소의 패턴들을 적용하며 잘 작성할 수 있느냐로 평가된다. 

이 차이를 실감하면서 기존에 내가 생각했던 슈퍼 개발자의 능력과 방향이 조금 잘못되었다는 것을 느낄 수 있었다. 그렇다면 실무에서 20~30년 이상의 개발경력을 가지는 백발 개발자는 어떻게 커리어를 쌓아 왔을까? 

먼저 개발 분야의 전문성 레벨을 드라이퍼스 모델(Dreyfus Model)에 비교해 보자. 이 모델은 80년대 초 드라이퍼스 라는 두 형제에 의해 발표된 것으로 어떤 기술을 습득하는데 있어 거치게 되는 진화과정을 5단계로 나누고 있다. 5단계는 초급자(Novice), 초중급자(Advanced Beginner), 능숙자(Competent), 숙련자(Proficient) 그리고 전문가(Expert)로 분류된다. 

초급자는 언어와 개발 도구에 대해 경험이 전무한 초급 개발자에 해당한다. 때문에 어떤 매뉴얼을 따라 결과를 만들어 내는 것은 가능하지만 혼자서 창의적으로 코드를 작성하기 어려운 단계로 분류할 수 있다. 

매뉴얼이 없이 어느정도 개발이 가능한 단계가 바로 초중급자다. 어려운 로직이 아닌 범위 안에서 자유롭게 코드를 작성할 수 있는 단계다. 능숙자는 언어와 툴에 대해서 모두 익숙해진 단계이고 어떤 프로그램 로직이라도 원하는 결과물을 만들어 내는 것이 가능하다. 

능숙자까지는 소스 품질이 외국이나 한국이나 큰 차이가 없다.하지만 국내의 경우 품질보다는 결과를 더 중시하는 문화 때문에 숙련자로 성장해야 된다는 필요를 느끼지 못하는 경우가 많다. 즉, 5~7년이 지나면 개발자 레벨이 평준화된다고 이야기하는 것을 종종 듣는 것과 같은 맥락이다. 

하지만 능숙자와 숙련자는 만드는 결과물이 같지만 그것을 어떻게 만들었는지에 대해서는 분명한 차이가 있다. 보다 많은 예외 상황들을 고려하고 향후에 확장될 수 있는 가능성들을 검토해 보다 언어적으로는 객체지향적이고 또 관점지향적인 설계가 가능한 것과 더불어 시스템이나 플랫폼적인 설계도 가능하게 되는 단계이다. 많은 개발 패턴들을 알고 있고 실제 어떤 상황에서 적용하면 좋고 안 좋은지에 대한 이해가 있는가?그렇다면 숙련자 레벨이 된 것이다. 

숙련자 레벨을 넘어서게 되면 전문가 레벨로 가게 되는데 주로 외국에서는 개발자들의 코드를 리뷰하는 아키텍트가 바로 여기에 해당된다. 아키텍트의 역할은 주로 소프트웨어 품질을 관리하는 것이다. 그런만큼 숙련자들이 할 수 있는 실수들을 줄여줄 수 있는 능력을 가지고 있어야 한다. 즉 ,그들이 하게 되는 실수들을 미리 경험해보고 다양한 경우에 대한 설계 노하우를 갖고 조언할 수 있어야 한다. 

이렇게 전문가로 가는 길을 방해하는 것은 국내의 잘못된 개발문화 때문일 것이다. 하지만 그렇다고 이런 문화에 저항하지 않고서는 전문가의 커리어를 걷기 어렵다. 즉, 빠르게 결과를 전달하는 개발 문화에 순응하여 자기계발을 멈추게 되면 그 개발자는 능숙자에서 발전하지 못하고 정체될 수 밖에 없다. 이렇게 되면 개발자의 슬럼프가 시작되는데 이 단계에서 적성과 다르게 관리자로서의 커리어를 받아들이는 경우를 많이 보았다. 

지금 나의 위치는 어디인가?혹시 능숙자에서 성장이 멈추어 있는 자신의 커리어에 대해서 고민하고 있지는 않은가? 그렇다면 조금 더 예술적인 코드를 만드는 것에 투자해 보는 것은 어떨까? 한 예로 DRY(Don’t Repeat Yourself), KISS(Keep It Simple Stupid)와 같은 마인드 셋으로 SOLID와 같은 개발패턴들을 공부해 보는 것이다. 그리고 현업에서 직접 적용해보면서 상황에 따른 장단점들을 연구해보길 추천한다. 아무리 좋은 패턴이라고 하더라도 환경에 따른 다양한 상황 앞에서는 모두 완벽할 수 없기 때문이다.

Zdnet Korea에 기고한 글입니다.