2018.02.28

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

Peter Wayner | CIO

이 세상에 거짓말을 하지 않는 것은 아이들과 광인 뿐이라는 말이 있다. 개발자들이 약간 광인 같은 모습을 보이거나, 아이들처럼 고집을 부리는 일도 있긴 하지만, 기본적으로 개발자들도 자기 마음속에 있는 것을 곧이곧대로 말하지는 않는다.

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

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



‘비 표준’(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은 소괄호 안에 반드시 띄어쓰기를 해야 한다고 규정한다.

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

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

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

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


2018.02.28

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

Peter Wayner | CIO

이 세상에 거짓말을 하지 않는 것은 아이들과 광인 뿐이라는 말이 있다. 개발자들이 약간 광인 같은 모습을 보이거나, 아이들처럼 고집을 부리는 일도 있긴 하지만, 기본적으로 개발자들도 자기 마음속에 있는 것을 곧이곧대로 말하지는 않는다.

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

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



‘비 표준’(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은 소괄호 안에 반드시 띄어쓰기를 해야 한다고 규정한다.

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

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

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

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


X