IT업계는 다른 직종보다 유독 빠르고 격렬하게 변화합니다. 좋든 싫든 개발자는 쏟아지는 기술을 마치 유행처럼 받아들이며 이를 활용하여 더 나은 결과물을 만들어야 하는 숙명을 가지고 있습니다. 그런데 당장 우리의 시선으로 보기에는 변화를 감지하기는 어려울 수 있습니다. 갑자기 한순간에 모든 게 바뀌거나 천지가 개벽되는 드라마틱한 변화가 생기지는 않기 때문입니다. 하지만 다양한 분야에서 작은 부분에서 발전된 기술들이 발생하고 이런 변화들이 모아지면서 가랑비에 옷이 젖어가듯 기술의 발전 속도를 감지 못한 개발자는 도태될 수 있습니다. 불과 40년 전인 1980년도까지만 해도 타자원이라고 불리던 타이피스트(typist)라는 직업이 존재하였습니다. 이들은 사무실에 한편에 자리 잡아 타이핑하여 업무에 필요한 문서를 제작하는 기술직이었습니다. 하지만 얼마 안가 IBM사의 16비트 PC가 세계적인 베스트셀러가 되었고 컴퓨터가 발 빠르게 도입되었습니다. 개인용 컴퓨터가 보급되면서 문서를 작성하는 중요한 업무였던 타자원들의 일은 회사원이 갖추어야 할 기본 능력이 되면서 현재는 사라진 직업이 되었습니다.

제가 처음 개발 프로젝트로 참가하였던 사이트는 ASP(Active Server Pages)라는 언어로 구성되어 있었습니다. 당시에 운영하기 쉬운 윈도 서버에 무료로 구성되어 있던 이 스크립트 엔진은 간단한 홈페이지를 만들기에는 최적화된 기술이었습니다. 그리고 상대적으로 쉬운 난이도의 문법으로 개발자들이 쉽게 적응하여 빠르게 개발할 수 있어서 각광받는 서버 언어였습니다. 하지만 보안의 문제와 대형 사이트를 만들기 어려운 성능의 한계도 있었지만 후속작인 웹 애플리케이션 프레임워크인 닷넷(ASP.NET)이 출시되고 마이크로소프트가 ASP의 대한 지원을 중단하기 시작하면서 점점 도태되어 사라지는 언어가 되었습니다. 불과 10년이 안 되는 세월 동안 많은 회사가 선택했던 언어는 점점 자취를 감추기 시작했습니다. 물론 아직도 이 언어로 만든 사이트가 존재하며 아직도 ASP 전문 개발자들이 존재하지만 좁아진 채용 시장과 낮은 대우의 처우로 고민을 현장에서 듣고는 합니다. 이처럼 개발자들에게 새로운 기술에 대한 학습은 선택은 아닌 필수입니다.

학습은 거북이처럼 매우 느리고 느리게

학교에서 전교 1등이 되고 싶다면 해야 할 일은 무엇일까요? 네 바로 공부입니다. 그렇다면 좋은 프로그래머가 되고 싶다면 해야 할 일도 역시 공부입니다. 좋은 개발자가 되고 싶다면 혼자만의 학습시간은 꼭 필요합니다. 날마다 새로운 언어와 개인 포트폴리오를 수정하며 발전해 나가는 건 당연한 일입니다. 그런데 코딩 공부는 좀 더 세심하게 주의해야 할 부분이 있습니다. 학습 속도입니다. 가끔 후배 개발자들의 학습 과정을 들여다보면 너무 단순하고 순식간에 끝나버리는 걸 볼 수 있습니다. 마치 만화책일 읽듯 책을 읽고 샘플 소스를 한번 실행하고는 학습을 완료했다고 생각하는 방식입니다. 혹은 구글에서 게시판 만들기 검색어로 찾은 코딩 파워 블로거의 소스를 다운로드하여 테스트하듯 로컬 컴퓨터에서 한번 실행한 다음 소스코드를 눈으로 한번 훑어보고 학습을 다했다고 착각하는 경우가 많습니다. 누군가 만들어 놓은 소스를 리뷰하는 수준은 학습이라고 할 수 없습니다. 개념을 이해하는 학습이 필요로 합니다.

코딩 학습은 의도적으로 매우 느리게 진행하는 것이 좋습니다. 보이는 소스는 단순하게 몇 줄에 불과 하지만 그 안에 숨은 로직과 변수들 하나마다 상위 클래스의 로직을 찾아보고 다양한 함수 사용법과 다양한 각도로 살펴보는 것이 매우 중요합니다. 그리고 해당 언어에 대한 만든 이 가 누군지부터 역사와 철학까지 배워 보는 것을 추천합니다. 이렇게 상세하게 깨닫지 못한다면 한번 검색해본 것에 지나지 않습니다. 제대로 학습하도록 노력하세요. 간단한 예제도 큰 파이로 바라보고 소스코드 한 줄 한 줄 깊이 파고 들어가야 합니다. 더 이상 파헤쳐 볼 것이 없을 때 즈음에 다음 라인으로 넘어가는 느리고 집요한 학습 방법이 필요합니다. 이런 집중된 방법을 통해 코딩 근육을 길러야 합니다.

프로와 아마추어의 차이

새롭게 출시된 프로그래밍 언어에 대한 리뷰를 작성하기 위해 A4 용지 두 장 분량의 프로그래밍 원문을 번역한 적이 있었습니다. 짧은 영어 실력 덕분에 모르는 단어는 사전을 찾아보고 이해 가지 않는 문장은 구글 번역기와 파파고를 사용하여 도움을 얻었지만 그래도 도저히 해석되지 않고 어려운 부분은 해외에서 개발자로 일하고 있는 친구에게 전화하여 물어보면서 일주일 동안 밤낮으로 헤매 번역을 완료한 기억이 있습니다.

저는 당연히 번역가가 압니다. 그렇기 때문에 분량에 비해 오랜 시간이 걸려 작업했지만 이상할 건 없었습니다. 왜냐하면 이 분야에서는 저는 '아마추어' 이기 때문입니다. 만약 번역을 전문으로 하는 사람이 이 문서를 번역했다면 제가 소비한 시간의 10프로 미만을 사용하여 빠르게 작업을 완료할 수 있을 것입니다. '프로'이기 때문입니다. 프로와 아마추어를 나누는 기준은 저마다 다릅니다. '집중력'이라고 하는 사람이 있기도 하고 '돈'을 버는 여부를 기준으로 나누기도 합니다. 프로그래머에서 프로와 아마의 차리를 말한다면 저는 '속도'라고 생각합니다. 좀 더 명확히 말하면 프로젝트를 완성하는 시간이 얼마나 걸리는가에 대한 속도라고 말하고 싶습니다.

실무에서는 토끼처럼 빠르고 빠르게

처음 신입 개발자로 입사했을 때 당시 선임이었던 선배의 조언을 공유하고 싶습니다. '모든 개발자는 윈도우를 만들 수 있다. 다만 차이점이 있다면 능력 좋은 개발자는 짧은 시간 안에 만들 수 있을 것이고 당신이 만들면 100년이 걸리는 차이뿐이다.'라며 해준 충고 해준 기억이 납니다. 당시에는 어떤 의미인지 정확히 이해하지 못했지만 지금은 어느 정도 이해할 수 있는 훌륭한 조언이었습니다.

이걸 좀 풀어서 해석해보면 코딩은 누구나 할 수 있지만 실력이 좋은 개발자 일 수록 정확하고 빠르게 개발을 완성할 수 있다는 뜻입니다. 현업에서 일하다 보면 거북이처럼 코딩하는 사람이 종종 있습니다. 한 번은 이직한 개발자가 유지보수 한건을 한 달 동안 문제를 해결하지 못하고 있는 것을 30분 만에 대신 처리해준 기억이 납니다. 조금만 더 시간을 주었다면 스스로 해결할 수 있었겠지만 프로가 모인 현업에서는 거북이 코딩을 언제까지 도울 수 없는 노릇입니다. 실무는 정확하고 빠르게 프로젝트를 완수하는 것이 목표여야 합니다. 아마추어가 출전하는 마라톤은 완주의 목적이 있지만 올림픽 마라톤 경기는 시간을 단축하여 세계 신기록을 세우고 1등을 하는 목표를 합니다. 현업에서도 마찬가지입니다. 모든 프로젝트는 납품일자가 있습니다. 기간을 맞추지 못하면 비용이 발생하고 서비스 오픈의 차질이 발생합니다. 이는 명백한 프로의 세계이기 때문입니다. 개발자라면 학습하고 있는 아마추어보다 빠르고 정확하게 오류 없이 코딩이 가능할 수 있도록 실력을 만들어야 합니다.