저는 자바밖에 할 줄 모르는데요?
훌륭한 목수는 자신의 도구를 언제 써야 하는지 잘 알고 있다.
> 能書不擇筆 [능서불택필]
글씨를 잘 쓰는 이는 붓을 가리지 않는다는 뜻으로, 경지에 오른 사람은 도구나 재료에 구애받지 않고도 자기 실력을 충분히 발휘할 수 있음을 이르는 말
좋은 말이다. 명필은 붓을 가리지 않는다.
붓에 대한 이해가 매우 높아져서 도구나 재료에 구애를 받지 않는다는 것이다. 능서불택필의 메타포는 장인을 꿈꾸는 모든 이에게 적용될 수 있다. 붓과 명필, 개발자와 산출물.
개발하다 보면 때론 익숙하지 않은 일을 할 때가 있다. 서버 개발자가 앱을 만든다던가, 앱 개발자가 서버를 구축한다던가. 경험해보지 못한 도메인을 개발하는 것과 같이, 낯선 상황에 처하게 되면 판단을 위한 기반 지식이 부족할 때가 있다. 그렇다 하더라도 개발자들은 자원을 효율적으로 활용할 수 있어야 한다. 모든 자원은 결국 비용이다. 지금 내가 개발을 하는 시간과 미래의 내(혹은 다른 사람)가 개발하는데 쓰이는 시간 모두 중요하기 때문이다.
칠리 페퍼로 쓰는 칠리페퍼. (먹을거 가지고 장난 치면 엄마한테 등짝 스메싱)가끔 모든 일을 하나의 언어로만 하는 개발자를 만날 때가 있다. 예를 들어 자바(자바야 미안해). 자바로 배치 작업도 만들고, 리눅스 시스템 프로그램도 만들고, 자바로 자바 파일을 만들어 컴파일하기도 한다. 하나의 언어에 대한 이해도가 높은 것은 좋은 일이다. 하지만, 내가 사용하는 언어의 적용범위가 어느 정도인지 아는 것은 개발을 하는 데 있어서 보다 나은 의사결정을 하는데 도움이 된다. (그래서 HTML로 안드로이드 앱 만들 수 있어요?)
HTML은 프로그래밍 언어가 아니다.언어마다 특징이 있다. 특정 플랫폼에 귀속되거나, 다른 언어에 없는 특별한 기능이 있는 경우, 생태계가 잘 구성되어 있어서 프로젝트 초기에 빠른 생산성을 보여주는 언어들도 있다. 혹은 대형 엔터프라이즈 운영에 적합하거나, 해당 기술을 할 줄 아는 사람이 많아 대체인력을 구하기 쉬운 언어도 있다.
개발자에게 언어는 도구다. 도구는 주어진 목적에 부합하도록 디자인되어있다. 명필은 크고 넓적한 평필로도 가녀리고 여린 글씨를 쓸 수 있다. 작고 얇은 세필로 거대한 현판 글씨도 쓸 수 있다. 명필은 붓을 가리지 않지만 상황에 가장 적합한 붓을 선택하여 글씨를 쓴다. 개발자에게 프로그래밍 언어도 마찬가지다. 프로젝트 완수에 적합한 언어를 선택해야 한다.
어떤 경우에 문제가 될까?
언어와 기술은 각자의 선택이고, 특정 언어를 비하하거나 싫어하지 않음을 미리 밝힌다.
실질적인 예를 두 개 들어보자.
1) 눈을 떠보니 대규모 다중 사용자 온라인 롤플레잉 게임의 서버를 개발해야 한다. 나는 ruby를 잘 하기 때문에 ruby로 짤 수 있을 거라고 생각한다.
2) 해커톤에 왔다! 급변하는 요구사항을 맞춰서 개발하려는데, 나는 C++을 주로 다룬다! 그래서 C++로 서버를 만들려고 한다.
각 요구사항에는 제약사항과 제한사항들이 있다. 요구사항 기저에 있는 문제를 정확히 파악하고 언어와 기술을 선택해야 한다.
1) 의 경우 멀티쓰레드와 네트워크에 대한 높은 이해, 높은 처리량을 요한다.
2) 의 경우 짧은 시간 내에 높은 수준의 구현물을 작성해야 한다.
어떤 기술을 사용하든 결국 구현이 가능할 수도, 가능하지 않을 수도 있겠지만, 어떤 기술이 더 적합한지 판단하고 선택하는 것이 매우 중요하다. 다른 개발자와 협업을 할 때에도 중요한 부분 중 하나이다. ‘내가 이 기술밖에 못하니 이걸로 합시다' 보다, ‘이 기술이 이러한 이유 때문에 저희 서비스에 더 적합할 것 같은데, 어떠신가요?’ 가 더 설득력 있어 보이지 않은가?
일반적인 선택을 하지 않았다고 해서 틀린 것은 아니다. 다만 더 좋은 대안이 있고, 그에 따른 대가는 나와 나의 팀이 받을 수도, 애꿎은 사용자가 치를 수도 있다.
최적의 선택을 하기 위해서
가능한 문제를 정확히 파악해야 한다. 1) 의 경우, 어느 정도 수준의 계산이 몇 초 안에 끝나야 하고, 얼마나 많은 양을 처리해야 하는지, 2) 의 경우, 짧은 시간 안에 변경사항들에 대응하면서 산출물을 완성해야 한다.
사실 1), 2)의 예에서 기대했던 답은 게임 서버는 C++로 작성하고, 해커톤에서의 개발은 ruby로 작성하는 것이었다.
문제의 보편적인 해답을 찾기 위해서는 슬프게도 많이 알아야 한다. 아래 링크는 몇 년 전부터 유행하는 ‘developer roadmap’이다. front-end, back-end, devops 밖에 없지만 insight를 넓히기엔 충분할 것 같다.
각 명칭들과 요소에 대해선 찾아보거나 어떤 건지 알아보면 좋다. - 개발자 로드맵(2018년 버전)
다른 사람들은 비슷한 문제를 어떻게 풀었는지 찾아보는 것도 많은 도움이 된다. 보편적인 해답과 최적의 해답은 다를 수 있으나, 왜 보편적인 선택을 했는지 최적의 답을 찾아가면서 넘어야 할 새로운 문제점은 무엇인지 확인하면서 지식의 영역을 넓힐 수 있을 것이다.
개발자는 늘 공부해야 한다. 심지어 1950년대에 나온 COBOL과 Fortran도 새 버전과 새 표준이 나오고 있다. 우리가 처한 환경도 변화하고 언어도 변화한다. 언어가 변화함에 따라 다루는 도구들도 변한다. 혹은 도구 덕분에 언어가 변화하는 경우도 있다.
‘자고 일어나니 새로운 기술이 쏟아져 나온다.’라는 말이 있다. 이것은 참이다. 라틴어권의 상당수 나라들은 우리와 낮과 밤이 다르다. 우리가 자고 있을 때, 그들은 무언가를 생산하는 시간이다. 당연히 많은 뉴스, 라이브러리들의 버전업은 우리가 자는 동안 일어난다. 쏟아지는 정보 속에서 나와 관심 있는 정보들을 찾아서 모으다 보면, 점점 옥석을 가리는 눈이 트일 것이다.
개발자들 마다 관심사와 주된 업무 환경은 다를 것이다. 같은 언어의 개발자라도 서비스하고 있는 도메인에 따라서 언어를 바라보는 시각은 천차만별이다. 나와 비슷한 사람, 나와 비슷하지 않은 다양한 분야의 사람들과 교류하면서 다양한 의견을 듣는 것이 좋다. 이렇게 교류하다 보면 ‘당연히' 이렇게 풀겠지 라는 상식이 깨질 때가 있다. 혹은 나의 ‘당연함'이 타인에게 도움이 될 수도 있다.
문제에 대한 고민의 깊이가 깊어질수록 보이는 시야가 달라지고, 그때그때 최선의 답이 다를 수 있다. 그래서 항상 최선의 답이 무엇인지 고민해야 한다. 프로젝트 말미에 '아 이렇게 했으면 좋았을걸!'이라는 생각이 들면 다행이다. 그동안 그만큼 성장한 것이고, 성장한 지점을 느꼈다는 거니까. 잊어버리지 않게 회고를 하는 것도 좋다.
한 가지 언어를 고집하기보다는 상황에 맞춰 적절한 언어와 도구를 선택하자.
QnA
프로젝트에서 잘못된 기술 선택으로 개발 속도가 더뎌진 경험이 있으신가요?
하루 안에 웹앱을 구축해야 하는 해커톤에 참여한 적이 있어요.
서버 구축을 위한 기술 셋을 선택하는 자리가 있었는데, 자바/스프링으로 구성하자는 의견이 나왔었어요. 그분께 가장 익숙한 스킬셋이었기 때문인데, 저의 생각은 조금 달랐었어요. 스프링을 능숙하게 다룰 수 있는 사람들도 거의 없었고, 설정할 것이 많아 빠르게 build-up 하기 어려울 것 같다는 생각이 들었거든요.
다행히도 우리는 의견 교환에 적극적이었고, 프로젝트에 조금 더 적절한 언어와 프레임워크를 선정할 수 있었습니다.
상황에 맞는 기술을 선택하는 것도 중요하고, 설득하고 설득당할 준비가 되어 있는 것도 중요한 것 같아요.
짧은 시간 내에 빠르게 만들기 위해서 official하지 않은 라이브러리를 이용해서 개발했었어요.
시간이 한참 지난 후에 보니, 버그를 내포하고 있었고 확장도 어려워 결국 새로 개발하게 되었습니다.
라이브러리 없이 직접 개발해보니 구현 난이도가 높지 않았고, 그때까지 유지보수에 쏟은 시간이 더 많이 걸렸다는 것을 깨닫게 되었습니다.
고민에 대한 시간을 더 들였더라면, official하지 않은 라이브러리를 사용하지 않았을 것이고, 유연하게 확장할 수 있지 않았을까요?
커버 이미지 출처 : 석산 선생님 혁필화 https://twitter.com/cornersinfo/status/827031964456677376/photo/1
