속뜻을 찾아라··· 관리자가 알아둘 만한 개발자 언어 15가지

이들 역시 나름의 정교하고 교묘한 언어로 자신의 마음을 포장하여 전달하곤 한다. 다만 그럴 때 사용하는 언어가 우리가 사용하는 것과 다르기에 종종 오해를 낳는다.

개발자들과 의사소통 할 때 그들의 의중을 파악하고 오해하지 않을 수 있도록, 오늘은 개발자들이 팀 미팅 등에서 자주 사용하는 그들만의 언어와 각 표현이 의미하는 바를 소개한다.



‘비 표준’(Non-standard)
이상적으로 표준이란 한 무리의 사람들이 서로의 행동 양식을 통일하고, 집합적 코드 스택을 만들어 협업해 네트워크 효과를 유발하게 한다. 하지만 까딱 잘못되면 한 무리의 개발자들이 다른 무리를 두들겨 패는 몽둥이로 변신할 수도 있다.

정부 기관에서 통제하는 몇몇 부분을 제외하면, 소위 표준이라는 것들은 사실 ‘표준’이라는 타이틀을 단 평범한 코드들에 불과하다. 그럼에도 어떤 이들은 코드를 가리켜 ‘표준’이라 칭한 후 다른 이들에게 가담하라고 제안한다.

하지만 진짜 중요한 것은 실제로 사람들이 얼마나 그 표준을 엄격히 준수하는지, 또 이러한 표준을 받드는 산업 연합들이 얼마나 우직하게 입장을 고수할 수 있는지다.

개발자들이 어떤 업무 이니셔티브나 툴을 가리켜 ‘비 표준’이라 부를 때, 글자 그대로 진실을 말하고 있을 수도 있다. 예컨대 이미 HTML로 잘 정립된 코드가 엄연히 존재하는데 굳이 이를 버리고 새로운 레이아웃을 사용할 필요는 없을 것이다. 그 새로운 레이아웃이 아무리 훌륭하다 한들 말이다.

그러나 ‘표준’이라고 불리는 것들은 대부분 HTML 만큼의 무게감을 가지고 있지 않다. 때문에 경우에 따라서는 개발자의 ‘비 표준’이라는 말이 단순히 “내 취향은 아니다” 라던지 “우리가 만든 것이 아니다,” 심지어 “우리는 이 사람이 마음이 들지 않는다”를 의미하는 것은 아닌지 생각해 볼 필요가 있다.

‘새로운 표준’(New standard)
새로운 장난감이 생긴 개발자들은 이를 가리켜 자랑스럽게 “새로운 표준”이 될 것이라고 말하는 경우가 많다. 여기서도 표준이라는 단어는 자신의 선택에 대해 확신과 자신감을 주는 일종의 보증서 같은 표현인 경우가 많다.

진짜 경계해야 할 단어는 ‘새로운’ 이다. 어떤 것이 진정한 의미에서 표준이 되려면 시간이 걸린다. 따라서 새로운 무언가가 나타났을 때는 과연 사람들이 이를 표준으로 수용하고 따르는지, 정말로 다른 기업들은 이를 모두 표준으로 채택하고 있는지를 시간을 두고 지켜 봐야 한다. 새로운 표준을 개발했다고 말하는 개발자들의 말이 그럴 듯 하고 사실처럼 들릴지도 모르지만, 과연 정말로 시간을 거쳐 검증 받지 않은 것이 표준이 될 수 있는지 의구심을 가져야 한다.

물론 어떤 것을 가리켜 모두가 도입하고 싶어 하는 새로운 표준이라고 말한다고 해서, 개발자가 악의를 가지고 그런 것은 아니다. 그보다는 기존의 방식을 폐기하려 하거나, 혹은 비난하려 할 때 이런 이야기를 할 가능성이 더 높다.

예컨대 기존에 당신이 일 처리를 하는 방식에 불만이 있으나 이를 말은 못하고 벙어리 냉가슴을 앓다가, 정말 좋아 보이는 새로운 방식이나 툴이 등장한 것일 수도 있다. 어쨌든, 개발자들이 새로운 무언가를 칭찬하고 권할 때는 약간의 경계심을 가질 필요가 있다.

‘1주일이면 된다’(One week)
희망이란 잘라도 잘라도 다시 돋아나는 강인한 새싹과도 같다. 어떤 기능이나 픽스가 쉽게 마무리될 수 있다고 단언하는 개발자가 있다면, 그들이 거짓말을 하거나 허풍을 떠는 것이 아니다. 그들은 진심으로 그 작업이 빨리 끝날 수 있다고 믿고 있다.

문제는 이런 희망과 달리 컴퓨터가 끊임 없이 말썽을 일으킨다는 것이다. 네트워크 문제, 레거시 데이터베이스 문제 등등 일일이 열거하기도 어려울 정도다. 물론 경우에 따라서는 대책 없는 낙관적으로만 이렇게 말하는 개발자들도 있을 것이다. 어느 쪽이건, 개발자가 말하는 “1주일 걸린다”는 사실 한 달, 어쩌면 6주 정도까지 길어질 수도 있음을 기억할 필요가 있다.

‘한 달이면 끝낼 수 있다’(One month)
일반적으로는 일이 얼마나 걸리냐는 물음에 그래도 일주일보다는 한 달이라 대답하는 개발자들이 많다. 하지만 ‘일주일’과 마찬가지로 한 달이라는 대답도 그다지 신뢰할 수 있는 약속은 아니다. 일주일이 한 달이 되었듯, 한 달 역시 4~6개월이 되는 경우가 허다하다.

‘1년은 걸릴 것 같다’(One year)
그렇다면 개발자가 1년이 걸린다고 얘기한다는 건 어떤 의미일까? 이 경우 구체적인 시간은 중요하지 않다. 그는 사실상 ‘이 일은 못 하겠다’고 말하는 것이다. 그 일을 하기 위해서 추가적인 교육이 필요하거나, 어쩌면 자기가 싫어하는 언어로 프로그래밍 하는 것을 다시 배워야 하는 것일 수도 있다.

아니면 (그 동안 몰래 자신이 속한 부서의 자원들을 가져다 쓰거나, 축구 경기에서 우리 부서를 이겼다는 이유로) 눈엣가시였던 다른 부서의 어떤 팀과 협력이 요구되는 작업이기 때문일 수도 있고 말이다.

해당 업무 자체가 아예 불가능한 것이라고 우겨볼 수도 있겠지만, 이런 주장은 설득력이 약하다는 걸 개발자 자신도 잘 안다. 왜냐하면 십중팔구 당신이 개발자에게 요구한 작업은 이미 경쟁사에서도 진행하고 있는 사안일 것이고, 그런 사안에 대하여 ‘불가능’하다고 딱 잘라 말할 수 있는 얼굴 두꺼운 개발자는 별로 없기 때문이다.

따라서 개발자 입장에서는 하기 싫은 업무에 대해 실행이 불가능하다거나, 실용적이지 못하다고 주장할 수 밖에 없는 것이다.

물론 이런 식의 행동은 개발자 뿐 아니라 관료적 조직의 모든 층위에서 빈번히 관찰되는 일이다. 단지 프로그래머들은 외부에서 쉽게 보기 어려운 이상한 세계에 살고 있을 뿐이다. 그리고 이들은 이러한 상황을 이용해 이름도 낯선 이상한 표준이나 소프트웨어 뒤에 숨어 하기 싫은 일을 피해 가고자 할 것이다.

‘스타일’(Style)
누군가 말했다, 이 세상은 스타일이 있는 자와 없는 자 둘로만 나뉘며 그 중간은 없다고. 개발자들도 마찬가지다. 디자이너들이 넥타이 폭이나 치마 길이에 관한 각자의 주관이 있듯, 개발자들도 어떻게 코드를 쓰는 것이 가장 아름다운가에 대한 자신만의 주관을 갖는다.

아마도 가장 유명한 스타일 파시즘은 에어비앤비의 Node.JS 스타일 가이드일 것이다. 규정 19.4에 의하면 개발자는 플러스 사인 앞 뒤로 한 칸씩을 띄워 놓아야 한다. 또한 규정 19.10은 대괄호 안에 띄어쓰기를 금지하고 있으며 19.11은 소괄호 안에 반드시 띄어쓰기를 해야 한다고 규정한다.

이처럼 이들 규정은 조, 항은 물론 앵커 태그까지 달고 있어 규정을 위반한 개발자에게 몇 조 몇 항을 위반하였는지 항의하기 아주 편리하게 되어 있다.

에어비앤비는 고객들의 안전을 보장해 줄 지도 모르는 화재나 도시 계획 구역과 관련한 규제에는 다소 느긋한 입장을 취하면서도, 코드에 띄어쓰기를 얼마나 해야 하는지에 대해서는 아주 엄격한 규정을 집행하고 있는 듯하다(이 페이지와 이 페이지 참조).

코드 작성에 대한 각자의 스타일과 주관을 가지고 있는 것은 문제가 아니다. 단, 자신의 방식을 다른 이들에게 강요할 때 문제가 된다. 실제로 많은 개발자들이 의견이 비슷한 이들끼리 무리를 형성해 ‘코드 스타일’ 전쟁을 벌이곤 한다. 전쟁이라고 해봐야 상대방의 결과물이 “비 표준”이라며 깎아 내리는 수동 공격적 메모 주고받기에 불과하지만 말이다.

“그 팀은 스타일이 촌스러워. 우리가 훨씬 스타일리시 하지.” 쉽게 말해, 개발자가 ‘코드 스타일’ 얘기를 꺼내는 순간 그 다음 말은 거의 신경 쓰지 않아도 괜찮다. 예컨대 상호 운용성 등에 대한 진짜 기술적 문제가 발생했다면 ‘스타일’ 얘기를 꺼내지는 않을 것이기 때문이다. 한편 코드 스타일 자체를 거부하며 고집 부리는 개발자가 있다면 그는 그저 비호감이 되기 위해 열심히 노력하고 있다고 밖에 볼 수 없다.

‘데브옵스’(DevOps)
데브옵스(DevOps)라는 단어는 마치 ‘개발자(Developer)’와 ‘작전(Operations)’의 합성어 같지만, 이는 사실은 코드와 서버 구동을 원활하게 유지하기 위한 프로세스를 일컫는다. 이러한 프로세스는 상당히 복잡해 전문 인력이 요구되고 있다.

그럼에도 불구하고 데브옵스 팀에 업무를 위임하는 프로그래머의 목소리에서 때때로 약간의 우월감이 느껴지는데, 이는 아마 실력 있는 요리사가 테이블 셋팅을 다른 이에게 맡기는 것과 비슷한 감정을 느끼기 때문일 것이다.

프로그래머들은 자신의 임무는 데이터 구조에 대한 독창적이고 좋은 아이디어를 내놓는 것이며 이를 실제로 집행하고 구동하는 것은 다른 이들에게 맡기면 된다는 생각을 가지고 있다. 즉 데브옵스란 개발자들에게 있어 ‘그다지 폼 나지 않는, 하지만 누군가는 꼭 해야 하는’ 일이라고 할 수 있다.

‘API’
시인 로버트 프로스트(Robert Frost)는 프로그래머는 아니었지만, ‘무언가 담을 사랑하지 않는 것이 있어서’(Something there is that doesn’t love a wall)라는 그의 문구는 API를 아주 잘 설명해 준다.

프로그래머들이 API를 좋아하는 이유는 다름아닌 분명한 경계와 그 경계를 넘을 시 결과에 대한 분명한 규칙을 제시해 주기 때문이다. 이처럼 확실한 구분 짓기를 함으로써 API 벽 바깥에 있는 이들은 안에서 일어나는 일에 대해 크게 신경 쓰지 않을 수 있게 되었다.

그렇지만 프로그래머가 말하는 API는 단순한 경계 짓기를 넘어서서 ‘통제’에 관한 것일 경우가 많다. API 벽을 만드는 팀이 API 규정도 정하게 되는데, 이로 인해 API를 남용 하기 위해 ‘비 표준적’수단을 사용하는 개발자들에 대한 불만의 목소리가 나오기 쉽다.

물론 다른 이들은 API 팀에서 정하는 액세스 규칙 및 서비스 조건이 보다 오픈되기를 바랄 것이고, 결국 논쟁이 발생하게 된다. 개발자들 사이에 API에 대한 이야기가 나올 때는 어쩌면 API의 장점에만 집중하는 것이 최선일지도 모른다. 프로스트 역시 ‘튼튼한 담장이 행복한 이웃 관계를 만든다’(Good fences make good neighbors)라고 말했던 것처럼 말이다.

‘임무에 더 적합’(Better suited / The right tool for the job)
개발자들은 프로그래밍 언어 및 그러한 언어를 지원하는 코드베이스를 배우는 데 많은 시간을 보낸다. 개발자들에게는 공부가 곧 실력과 몸값 상승으로 이어지기 때문이다. 때문에 개발자가 자신이 잘 아는 것에 대해 열렬히 변호하는 것도 자연스러운 일이다.

어떤 태스크에 X또는 Y가 ‘더 적합하다’고 말하는 개발자가 있다면, 그는 사실 어느 특정 스택에 보다 깊이 뛰어들기 위하여 오래 전 자신이 내렸던 선택을 그저 정당화하고 있을 확률이 크다.

이럴 때 최선의 대응은 그저 고개를 끄덕이고, 웃으며 동의해 주는 것이다. 설령 의견이 다르다 한들, 굳이 논쟁을 해서 얻을 것이 없다. 현대의 프로그래밍 언어들은 모두 역량 측면에서 비슷한 수준을 보이고 있으며 표면적인 차이만을 보이고 있기 때문이다.

예컨대 파이썬을 사용하는 프로그래머들은 파이썬이 괄호 대신 만입을 사용해 코드를 블록으로 분해할 수 있다는 사실을 자랑스러워 할 것이다. 물론 그렇다고 해서 다음 프로그래밍 프로젝트에까지 파이썬을 사용해야 한다는 것은 아니다.

‘범위 추가’(Scope creep)
모든 프로젝트는 처음에 원대한 꿈을 가지고 시작된다. 그리고 운이 좋으면 50% 정도의 완성률을 보이며 막을 내린다. 그렇지만 얼마나 큰 꿈을 꿀 것인가를 정하는 것은 결코 쉬운 일이 아니다. 지나치게 보수적인 태도를 취하다가는 충분히 이룰 수 있는 것도 성취하지 못하고 끝난다. 반면 너무 비현실적인 목표를 세운다면 결과적으로 무엇 하나 제대로 이루지 못한 채 끝날 확률이 높다.

범위추가(scope creep)라는 표현이 있다. 이 표현은 처음에는 충분히 현실성 있는 목표였던 것이 갈수록 이러저러한 부가적인 목표가 더해지면서 점차 불가능한 무언가로 변질되어 가는 과정을 일컫는다. 자꾸만 새로운 아이디어를 더하려는 매니저에게 브레이크를 걸 때 개발자들이 방어적으로 사용하는 표현이기도 하다.

효과가 있냐고? 그럴 때도 있고 아닐 때도 있다. 매니저가 “우리도 욕심을 좀 내 보자” 라는 표현보다 “이대로 하던지 아니면 그만 두라”고 대응해 온다면 방법이 없다.

‘문화적 적합성’(Cultural fit)
부족 사회를 형성하고 무리 지어 전쟁과 사냥을 일삼던 시대는 이제 머나먼 과거의 일일 뿐이라고 생각하는가? 그렇다면 당신은 아마 개발자들이 ‘기업 문화에 부합하는 인재’라는 표현을 어떻게 쓰는지 모르고 있는 것이다.

이 표현은 사실 “나와 꽤 비슷한 사람”에 다름 아니다. 물론 일각에서는 ‘기업 문화에 부합하는 인재’라는 표현이 특정 인종, 성별을 배제할 때 쓰인다고 보고 있지만, 경우에 따라서는 프로그래밍 언어, API 등을 비롯한 기술적 문제에 대한 논의에 쓰이기도 한다. 누구나 자신이 가장 익숙하고 편안하게 느끼는 기술적 툴, 생각, 방식이 존재하며 이러한 ‘익숙한 영역’ 밖에 존재하는 이들을 가리켜 ‘기업 문화에 안 맞는다’고 표현하는 것이다.

‘리팩토링’(refactoring)
프로그래머가 “실수를 시정하겠다”거나 “당장 모든 것을 뒤엎고 새로 하겠다”고 말한다면 스스로의 무능을 인정하는 것처럼 들린다. 하지만 “리팩토링 하겠다”고 말하는 순간 뭔가 매우 과학적이고 대단한 것을 하는 것 같은 느낌을 준다. 그러니 어느 프로그래머가 실수를 시정함에 있어 이 표현을 사용하지 않을까?

‘피쳐’ vs. ‘버그’
프로그래머가 ‘피쳐(feature)’에 대해 얘기한다면 그것은 (아마도 자신이 직접 썼기에) 코드가 마음에 든다는 뜻이다. 반대로 ‘버그(bug)’에 대한 얘기를 꺼내면 이는 (높은 확률로 다른 팀에서 썼기 때문에) 그 코드가 마음에 안 든다는 얘기다.

생각보다 버그를 찾아내는 일은 프로그래머들에게도 쉽지 않은 작업이다. 코드는 스스로를 정의한다. 어떤 개발자들은 아예 버그라는 것은 존재하지 않는다고 말한다. 그저 아직까지 코드가 쓰여지지 않은 유즈 케이스가 있을 뿐이라는 것이다.

이런 철학적 논쟁에 여러분까지 말려 들어가서는 안 된다. 분명한 것은 목표한 작업을 제대로 끝낼 수 없을 때는 그것이 버그이든 피쳐이든 관계 없이 수정되어야 한다는 사실이다.

‘클루지’(Kludge)
클루지(kludge)란 일을 ‘정석대로’ 처리할 충분한 시간이 없어서 임시 방편으로 도입하게 되는 임시 절차를 가리키는 구어적 표현이다. ‘임시땜빵’이라고도 표현할 수 있겠다. 프로그래머들은 일단 클루지로 일을 처리한 후 코드를 더해 리팩토링하려 할 것이다. 그리고 그 다음 팀은 이 프로그래머의 리팩토링을 클루지로 파악하고 또 다른 리팩토링을 하게 될 것이고 말이다. 그렇게 클루지 싸이클은 돌고 돈다.

‘루저’(Luser)
과거 테크놀로지 커뮤니티에는 기술적인 문제는 관련된 교육을 받은 전문가들만이 다룰 수 있으며 이러한 전문성을 갖추지 못한 ‘루저(luser, 비전문가)’들은 다른 일에 신경 쓰는 게 더 낫다는 거만한 태도가 팽배해 있었다. 그러나 오늘날에는 거의 찾아보기 힘들어 졌다. 테크놀로지 플랫폼의 성공이 그러한 플랫폼을 사용하는 노즈의 숫자로 평가되는 마당에 프로그래머가 그러한 태도를 고수하기란 어렵다.

그렇다고 해도, 테크놀로지에 대해 전혀 아무것도 모르는 일반인들의 삶을 편리하게 만들어 주기 위해 과연 개발자가 어느 정도로 노력해야 하는가라는 질문은 남아 있다. ‘대체 능력도 없는 얼뜨기들을 위해 프로그래머의 귀중한 시간을 얼마나 더 낭비해야 하는 것일까? 그럴만한 가치는 있는 것일까?’라는 의문이다. 이를 결정하는 것은 결국 관리자의 일이다. 이런 결정을 맡겨 놓는다면 JSON 데이터 스트럭처가 정규 표현으로 가득해지는 모습을 보게 될 것이다.

* Peter Wayner는 16권의 기술 서적을 저술한 작가이자 인포월드 전문 기고가다. dl-ciokorea@foundryco.com