익명 기고 | ‘개발자가 털어놓는’ 개발자의 비밀 9가지

기업은 애플리케이션 개발을 통해 경쟁력을 크게 강화할 수 있다. 시장을 주도하는 모바일 앱이나 사업에 활기를 불어넣는 제대로 된 맞춤형 코드를 뚝딱 만들어낼 줄 아는 마법사들에게 투자해야 할 이유는 충분하다. 그러나 사실 우리 개발자들이 늘 솔직한 것은 아니다. 우리들 사이에서만 간직하고 싶은 몇 가지 비밀이 있다.

개발자들이 모든 것을 말하지 않는다는 사실은 이해할 만하다. 상대가 상사이기 때문이다. 상사에게 모든 것을 털어 놓지는 않는다. CEO가 의사결정 내용을 이사회에 일일이 알리지 않는 것과 마찬가지다. 그러니 개발자들에게 비밀이 있다고 해서 놀랄 일은 아니다.

회사 입장에서는 모르는 것이 나을 때가 있다. 개발자들이 자바(Java) 업데이트를 숨겨둔 디렉토리는 몰라도 된다. 백업 파일들이 암호화되어 있는 한 비밀번호에는 신경 쓰지 않아도 된다. 개발자들이 쓰던 도구를 마음대로 다른 것으로 바꾸더라도 회사 측에서는 그다지 신경쓸 필요가 없을 수 있다.

그러나 그렇지 않은 예외들이 있다. 이러한 예외들은 경영진과 개발자들의 월급은 물론 회사의 운명을 좌우할 수 있다. 비즈니스에 큰 영향을 끼칠 수 있는 개발자들의 비밀 9가지를 이 글을 통해 폭로한다.

– 개발자들은 생각만큼 잘 알지 못한다
– 기술 부채가 생각보다 훨씬 많다
– 개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
– 개발자들은 자신들의 코드에 심취해 있다
– 개발자들은 유행에 집착한다
– 개발자들은 회사를 발전시키에는 너무 게으르다
– 개발자들은 유지관리보다는 구축을 선호한다
– 모든 앱을 꼭 다시 작성해야 되는 것은 아니다
– 개발자들은 사업 쪽은 잘 모른다

개발자들은 생각만큼 잘 알지 못한다
개발자들은 똑똑한 사람들이다. 그 중에는 진짜 천재들도 있다. 문제는 가끔 잘 모르는 것도 다 아는 척 한다는 점이다.

물론, 프로그래밍의 기초는 훤히 알고 있다. 루프 작성이나 데이터베이스에 질의 보내기 등은 척척 해낸다. 처음 보는 언어나 코드 베이스, 개발 도구를 접해도 기초가 튼튼해서 큰 문제가 없다.

그러나 회사에서 요구하는 것은 기본적인 것이 아닌 경우가 대부분이다. 가령, 기능 흐름을 수정해 달라는 요청이 들어왔을 때, 관련 코드가 실제로 어디 있는지 개발자들이 모르는 경우가 많다. 마침 운이 좋아서 알고 있다고 해도 막상 수정 작업이 쉬울지 어려울지 알 수 없다. 코드를 다운로드하여 몇 줄 새로 써 본 후 어떻게 되나 확인한 후에나 알 수 있다. 일정이 늦어지는 것은 프로젝트 범위가 계속 늘어나기 때문만은 아니다. 애초에 개발자들이 실질적인 업무 범위를 제대로 예상하지 못하기 때문인 경우가 많다.

그렇다고 해서 회의 때 “잘 모르겠는데요?”라는 말을 하는 이는 거의 없다. 어디서부터 시작해야 할지도 모르겠다거나 어떤 도구를 써야 최선인지 감이 안 잡힌다는 말을 듣고 좋아할 상사도 없다. 그러니 개발자들로서는 아무 숫자나 해법을 일단 내놓고 맞아 떨어지기를 빌 뿐이다. 만일 빗나간다면 “플럭스 콘덴서에 과부하가 걸렸다”는 식의 뭔가 있어 보이는 핑계로 둘러댄 후 개발자들이 제일 싫어하는 설명서 공부를 해야 한다.

기술 부채가 생각보다 훨씬 많다
기존 애플리케이션을 손볼 일이 생기면 경영진의 선택은 두 가지다. 개발팀에게 응급조치를 지시하거나 아니면 프로그램 전체 재설계를 지시하는 일이다. 응급조치를 하고 나면 기분도 좋고 비용도 적게 드는 것처럼 보인다. 회사 입장에서는 문제가 즉각 해결되니 좋고 개발자들 입장에서는 회사를 만족시키니 좋다. 회사를 만족시키는 일의 대부분은 개발자들이 좋아하는 일이다.

그러나 이렇게 대충 붕대와 테이프로 감아 놓는 식의 일이 늘어나다 보면 언젠가는 문제가 터지기 마련이다. 애초에 제대로 했어야 할 일임에도 불구하고 미봉책으로 인해 미뤄지는 이런 현상을 가리켜 “기술 부채”라고 부른다.

물론, 정확한 용어는 아니다. 부채를 갚을 필요가 없다. 운이 좋으면 재작업을 하지 않아도 소프트웨어가 계속 실행되기도 때문이다. 그러나 결국에는 중대한 사건이 발생해서 모든 것이 고장 나버리고 좀처럼 쉽게 해결할 수 없는 상황을 맞게 된다.

이러한 일은 가까운 협력업체가 소프트웨어 패키지를 최신 버전으로 업그레이드할 때 주로 발생한다. 갑자기 우리 업체의 코드가 실행이 안된다. 갑자기 모든 것이 고장 나버리고 우리 업체의 코드가 협력업체의 코드와 더 이상 통신이 되지 않는다.

이를 불쌍히 여긴 협력업체가 구형 게이트웨이를 계속 실행시켜 주는 경우도 있지만 그러한 자비는 우리 업체가 협력업체의 매출에 도움이 되는 경우에만 기대할 수 있다. 매출에 전혀 도움이 안되거나 도움이 미미할 경우 협력업체는 가차없이 결별을 선언할 것이다. 그러면 거래도 끊긴다.

개발자들은 흥미를 잃어서 이직 기회만 노리고 있다
회사의 가장 큰 과제는 회사의 코드에 대한 모든 것을 알고 있지만 그 코드로 하는 작업에 흥미를 잃은 똑똑한 개발자의 이직을 막는 것이다. 이 개발자는 문제 해결이나 기능 개선을 뚝딱 해치울 수 있다. 신입 개발자는 머리는 좋을지 몰라도 코드 베이스에 대해서는 아무 것도 모르기 때문에 똑같은 일을 해도 시간이 10배는 더 걸린다.

개발자들이 흥미를 잃는 이유는 셀 수도 없이 많다. 코드 작성 언어가 몇 년 전에 유행이 지난 구식 언어이기 때문일 수도 있고 애초에 코드를 짜느라 고생했던 안 좋은 기억 때문일 수도 있다. 테이블 너비를 조금 늘린다든가 배경 색깔을 좀 더 파랗게 하는 것은 이제 너무 쉬워서 새로운 도전 과제를 갈망하기도 한다.

똑같은 코드 작업을 꾸역꾸역 지루하게 반복해야 하는 개발자들의 고통을 덜어줄 방법은 별로 없지만, 가장 좋은 최신 프레임워크에서 코드를 새로 작성하게 해 준다면 효과가 있을지도 모른다.

시인 에즈라 파운드(Ezra Pound)는 다시 새롭게 하는 것(maket it new)이 시인의 과업이라고 했다. 관리자의 일도 그럴지 모른다. 적어도 개발자들의 이직을 막으려면 그래야 한다.

개발자들은 자신들의 코드에 심취해 있다
‘제가 인덱스오브(indexOf) 기능을 기가 막히게 활용한 거 혹시 보셨나요? 겨우 한 줄짜리 코드지만 쿠키 스트링을 완벽하게 분석해 낸답니다. 시간이 며칠 더 있었더라면 이 엄청난 기술로 세계 기아 문제까지 해결할 뻔 했다니까요?’

이처럼 개발자들은 자신들의 프로그램 기술에 스스로 도취해 있다. 판에 박힌 편안한 일상에 적응했으며 똑같은 어법을 반복해서 사용하기를 즐긴다. 외과 의사에게 찾아가면 모든 병은 수술이 필요하고 망치를 든 목수에게는 모든 게 못 박는 일로 보인다는 우스개 소리가 있다. 개발자도 사용 언어에 관한 한 마찬가지이다. 기술 언어든 객체 지향 코드든 어셈블리 코드든 간에 자기 마음에 드는 솔루션을 편애하고 고집한다. 회사에 의미가 있는지 여부는 안중에 없다. 

최상의 시기에는 이런 것이 문제가 되지 않는다. 좋은 개발자들은 자신들의 구체적인 선택 내용을 신조로 삼지 않는다. 또한 개발자들은 매우 좋은 아이디어에만 심취하는 훌륭한 취향을 대부분 갖추고 있다. 개발자들이 추가로 갖춰야 할 덕목은 여러 프로그래밍 기술 중에 어느 것을 써도 큰 문제는 없다는 것을 인정할 수 있는 유연성, 그리고 완벽한 솔루션은 없으며 훌륭한 기능이나 놀라운 프로그램 기술도 단점은 있게 마련이라는 것을 인정할 수 있는 지혜다.

반면, 최악의 시기에는 한바탕 전쟁을 치를 각오를 해야 한다. 색다른 선택을 하는 개발자들이 악마시되거나 폄하되는 경우가 너무 많다. 관리자들은 신중한 접근이 필요하지만 혼란스러울 때가 있다. 어떤 기술에 대해서 프로그래머들이 아무렇지도 않게 심한 비판을 할 때면 그 기술이 정말 형편 없어서 그러는 것인지 아니면 단순히 색다르기 때문에 그러는 것인지 판단하기 어렵다.

또, 반발하는 개발자들이 뭔가를 알고 있기 때문에 그러는 것인지 아니면 단순히 자신의 업무에 대한 고집을 피우는 것인지 파악할 수 없다면 회사에 최선의 결정을 내리기 힘들다.

개발자들은 유행에 집착한다
‘슬래시도트(Slashdot)에 게시된 새로운 오픈소스 프로젝트 봤니?’, ‘인포월드(InfoWord)에 나온 그 기사 봤어?’, ‘꼭 그 코드 처음부터 다시 짜서 컴파일한 다음에 우리 프로그램에 통합해야 돼. 그럼 전반적으로 실행 속도가 아주 빨라질 거야’, ‘저번 달에 내가 써 줬던 근사한 새 아이디어보다 훨씬 나아’, ‘그건 너무 구식이야. 이미 저번 주에 나온 얘기야. 이거야 말로 진짜야.’

발전은 기술업계의 큰 부분을 차지한다. 기계의 성능을 계속 향상시키는 것은 대체적으로 좋은 것이다. 웨이백 머신(Wayback Machine) 사이트에만 가 봐도 모든 것들이 얼마나 많이 개선되었는지 알 수 있다.

문제는 개발자들의 도가 지나칠 때가 많다는 점이다. 마치 번쩍이는 새 자동차를 보면 정신을 못 차리는 사람들처럼 개발자들 역시 새로운 기술이나 더 좋은 코드를 보면 정신을 못 차리고 빠져들곤 한다. 보기보다 실속은 없는 기능을 일컫는 해커들의 은어인 ‘크롬’(Chrome)이 구글 브라우저의 이름이 된 것은 우연이 아니다.

개발자들이 이러한 충동을 자제하는 것은 쉬운 일이 아니다. 개발자들은 무언가를 향상시킨다는 실용적인 목적 달성에 심취해 있기 때문에 “안 된다”라는 말을 자꾸 듣는 것을 싫어한다. 그렇다고 해서 새로운 아이디어를 다 쫓아다니다 보면 회사에게 무엇이 최선인지 잊어버리기 쉽다. 안 좋은 경우에는 회사의 일부분을 궁지에 빠뜨리기도 한다.

개발자들은 회사를 발전시키에는 너무 게으르다
새로운 아이디어를 다 쫓아다니는 것 보다 안 좋은 행태가 있다. 아무 것도 안 하는 것이다. 너무나 많은 개발자들이 냉소적으로 변한 나머지 아무것도 개선하려 하지 않거나 중대한 업무 결과를 낼 수 있는 새로운 도구를 연구하려 들지 않는다.

사실 유행은 금방 바뀐다. 알고 봤더니 몇 년 전에 나왔던 것을 조금 개선시켜 내놓은 재탕 버전인 경우도 많다. 기존 코드도 아무 문제 없이 잘 돌아가고 있는데 새롭고 개선된 것이라고 해서 무작정 다른 것으로 교체하는 것은 바보 짓인 것도 분명하다. 그러나 발전을 계속 무시하다 보면 자고 일어나 보니 크게 뒤쳐져 있음을 깨닫게 되는 날이 오게 된다.

개발자들은 이러한 나태함을 기술적인 세부 사항에 대한 지나치게 강한 헌신과 자존심으로 포장하는 경우가 많다. 아는지 모르겠지만 멀틱스(Multics)는 윈도우(Windows)보다 훨씬 안전한 최고의 운영체제이며 솔라리스(Solaris) 또한 최고의 유닉스(Unix)다. 진짜 BSD는 또 어떻고? (애플이 내놓은 엉뚱한 버전을 말하는게 아니다. 어차피 아이콘 클릭에 익숙한 맥 사용자들은 외면할 테니 별 성과는 없겠지만). 개발자들은 어릴 때부터 익혀 온 것들이 여전히 최고인 줄로 안다.

이러한 나태함은 남이 개발한 것이라면 거부 반응을 보이는 바람에 발전에 저해가 되곤 하는 NIH(Not-Invented-Here) 현상과 닮아있다. 인터넷에 똑똑한 사람들이 많지만 어쩐 일인지 멋진 아이디어는 죄다 멍청한 사람들이 내놓는 것 같고 우리 스스로 생각해낸 것이 아니라면 할 만한 가치가 없다고 생각하는 것이다.

이를 타파하려면 가끔 의욕에 불타오르는 개발자 한 명을 활용하면 된다. 그가 내놓는 신기술 배포 계획이 사업에는 아무 의미가 없고 아무 것도 변화시키지 못할지라도 사무실에 활기를 돌게 한다는 점만으로도 긍정적이다. 작게나마 개혁을 시도하라. 어쩌면 이를 계기로 회사가 머신러닝이나 사물인터넷 아니면 다른 신기술을 잘 활용하게 될 지도 모른다.

개발자들은 유지관리보다는 구축을 선호한다
필자가 만나 본 팀 가운데 하나는 기존 앱 재개발 작업을 매년 실시한다. 처음 3개월 동안 모든 것을 처음부터 다시 구축한 뒤 죽 지내다가 9월이 되면 차기 년도 재작성 계획을 세우는 식이다.

팀원들은 자신들의 코드에 대한 자부심이 대단하다. 그들의 코드는 잘 설계되어 있고 모듈식이며 대개 “올바른 방법으로” 구축되어 있다. 기술에 대한 자부심은 코드에 드러난다. 대충 꿰어 맞춘 것이 아니라 탄탄하다.

그러나 이러한 접근 방식에는 시간과 비용, 감정적 에너지의 소모가 크다. 이 팀의 규모는 버그 수정과 유지 관리를 전담하는 팀보다 크다. 또한 팀원들은 개선 여지를 항상 고민한다. 이는 큰 비용을 초래하고 번아웃 현상으로 이어질 수 있다.

어떨 때는 개발자들이 뭐라고 하든 간에 프로그램을 구축하고 소수의 개발자를 추려 유지 관리를 맡기고 나머지는 새 프로젝트의 새로운 팀으로 넘기는 것이 최선의 방법이다.

모든 앱을 꼭 다시 작성해야 되는 것은 아니다
개발자들 중에는 ‘올바른 방법으로’ 재설계와 재구축하는 작업을 유독 좋아하는 사람들이 있다. 사실이다. 철저한 재작성을 통해서만 해결 가능한 오류에 대해서는 개발자의 말이 대개 맞다. 100% 맞는 경우도 있다.

그러나 보기 좋다고 해서 반드시 사업에 도움이 되는 것은 아니다. 30년 된 파스칼(Pascal)이나 코볼(Cobol)로 된 코드라도 아무 문제만 없다면 굳이 건드릴 필요가 있을까? 새 기능을 추가한다고 해서 대세에 큰 도움이 될까?

문제는 모든 것이 서로 연결되어 있기 때문에 더욱 심각해진다. X를 고치면 X에 종속된 Y와 Z를 건드리게 되고 마치 연쇄 반응처럼 A, B, C, D에 사소한 오류가 발생하게 된다. 의도는 좋았어도 결과는 참담할 수 있다.

발전이 오히려 상황을 악화시키는 경우도 있다. 기억나는 사례를 소개한다. 어떤 회사는 녹색 화면에 대문자만 나오는 메인프레임 코드를 수십 년째 쓰고 있었다. 유행에 집착하는 까다로운 프로그래머들은 이제 이런 코드는 갈아치워야 한다고 주장했고 관리자는 여기에 굴복하는 바람에 머리카락을 쥐어뜯는 상황을 맞이했다.

새로운 코드는 유행에 충실하고 최고의 최신 오픈소스 라이브러리를 갖추고 있었다. 바이너리 코드는 구형 버전보다 1,000배는 더 나았다. 문제는 속도가 10배는 더 느려졌다는 점이다. 이에 대해 한 엔지니어는 새로운 프로그램의 기능이 훨씬 많기 때문이라고 해명했다. 그러나 그가 말하는 “기능”이란 기껏해야 컬러 배경에 트루타입(TrueType) 폰트를 움직이게 하는 것이 다였다.

개발자들은 사업 쪽은 잘 모른다
데이터베이스와 프로토콜, 새로운 프로그래밍 언어의 세계에 관해서는 엄청 똑똑한 개발자들도 평범한 사람들의 행동에 대해서는 그 이유를 잘 이해하지 못하는 경우가 대부분이다. 즉, 고객을 만족시키고 고객의 지갑이 계속 열리게 하는 전략을 수립하는 데는 적합하지 않다는 뜻이다. 개발자들은 데이터베이스를 다루는 것은 잘할지 몰라도 고객들의 재방문을 유도하는 요소에 대해서는 전혀 감이 없는 경우가 심각하게 많다.

한 가지 좋은 방법은 빅데이터와 성공적인 지표를 활용하는 것이다. 개발자들이 이해하기 좋은 숫자들로 표현되기 때문이다. 빅데이터와 인공지능의 장점은 최전선의 업무 담당자가 후방의 개발자들과 의사소통 가능한 언어적 체계를 만든다는 점이다.

이러한 지표는 더 많이 적극 활용해야 한다. 가공하지 않은 판매 관련 수치는 물론이고 브랜드 충성도, 브랜드 인지도와 같은 것의 측정치도 좋다. 그런 지표가 언제나 완벽한 것은 아니지만 개발자들이 디자인이나 정서적 연결의 중요성을 이해하도록 하는데 데 도움이 된다.

* ‘익명 기고’ 말머리의 기사는 현업의 IT 전문가들이 익명을 전제로 기고해온 글을 편집해 게재한 것이다. 기고한 글이 웹에 게재될 경우 기고자에게 소정의 사례금을 제공한다. 물론 기고자의 익명성은 보장된다. (이 원칙은 IDG 산하 미디어인 인포월드에서 운영하는 것으로, CIO Korea에서는 아직 검토 중이다. – 편집자 주) dl-ciokorea@foundryco.com