Everyday I have the Blues

  VPN, Virtual Private Network의 개념을 이해하기 위해서는 먼저 Private Network에 대한 이해가 있어야 하며, 그 후에 VPN과 일반적인 Private Network의 차이를 통해 어째서 앞에 Virtual이라는 단어가 붙게 되었는지를 이해해야 한다.

  Network는 쉽게 여러 대의 컴퓨터(컴퓨터와 기타 커뮤니케이션 가능 장치를 포함하여 이하 노드라고 표현)들이 연결된 망이다. 노드들은 다양한 방식으로 연결되어 있으며 상호간에 커뮤니케이션이 가능하다. 한 노드가 전 세계의 임의의 다른 노드와 통신할 수 있고, 이러한 커뮤니케이션 집단에 포함되는데 특별한 제약이 없다면 이 이 네트워크를 Public Network, 즉 일반적으로 말하는 인터넷이라고 한다.

  Private Network는 용어에서부터 알 수 있듯이 Public Network와 반대되는 개념이다. Private Network는 망에 포함되지 않은 노드는 Private Network상의 노드와 임의로 통신할 수 없다. 이런 Private Network를 사용하는 이유는 첫 째로 보안을 들 수 있는데, 사내의 중요한 정보가 담긴 서버가 Private Network에 포함되어 외부에서 접근 자체가 불가능하다면, 이 정보는 서버가 Public Network에 연결되어 있을 때보다 상대적으로 안전하다고 말할 수 있다.

  우리의 목적은 VPN에 대한 이해이기 때문에, VPN의 등장 배경인 Private Network의 한계에 대해 생각해 보아야 한다. Private Network의 가장 쉬운 예는 집안에서 공유기로 연결된 노드들의 집합이다. 이 경우 모든 노드들은 물리적으로 연결되어 있으며 새로운 노드를 추가하기 위해서는 또 다른 물리적 연결을 추가해야 한다. 회사에서 사용하는 사내 망의 경우도 일반적으로 물리적인 연결이 있는 경우가 대부분이다. 바로 이것이 Private Network의 한계이다.

  사내에서 구축된 Private Network의 경우 사무실에 출근하여 사용하기에는 아무런 문제가 없다. 그러나 쉽게는 출장부터, 낮은 확률로 자연재해로 인한 재택근무까지 사무실에 출근하지 못하고 업무를 진행해야 하는 경우는 많다. 이 때 업무에 사용해야 하는 데이타는 회사의 Private Network에 포함된 서버에 들어있고, 업무를 진행해야 하는 직원은 회사 밖에 있다. Private Network를 확장하기 위해 회사에서 집까지 케이블을 끌어와야 할까. 그것도 좋은 방법이라고 생각한다면 정신과 상담을 추천한다. 이런 요구에 의해 나온것이 Virtual Private Network, 즉 가상의 Private Network를 구축하는 것이다.

  Private Network는 보통 Public Network에 연결된 하나의 노드가 존재하고 보통 이것을 라우터라고 부른다. 그리고 Private Network에 속한 노드가 외부와 통신을 시도할 때에는 모든 패킷이 이 라우터를 통과하게 되고, 규칙에 의해 허용되지 않은 패킷은 라우터에 의해 걸러진다. VPN은 Private Network 외부에 있는 노드가 인증을 통해 라우터에 연결하고, 이 라우터가 내부 노드들에게 연결을 중계해주어, 이 노드가 Private Network에 포함된 것 처럼 동작할 수 있도록 해준다.

  Private Network가 Public Network에 비해 상대적으로 안전한 이유는, 외부에서의 연결이 불가능하기 때문이다. 보안이 필요한 데이타는 Private Network에 포함된 서버에 들어있으며, 모든 통신이 이 사내 망 안에서 이루어지므로, 패킷이 외부로 노출되지 않는다. 따라서 스니핑 등으로부터 안전하다.

  그러나 VPN을 사용하는 경우 결국 외부에 존재하는 노드가 사내 망에 연결을 시도하며, 보안이 필요한 데이타가 라우터를 통해 밖으로 나오게 된다. 이 경우, 데이타는 스니핑으로부터 더이상 안전하지 않다.

  그렇다면 이 보안의 역설을 해결하기 위해서는 무엇을 해야할까. 가장 널리 사용되는 방식은 Private Network를 벗어나는 모든 패킷을 암호화 하는 것이다. 그러면 악의적인 누군가가 스니핑을 시도하더라도 암호화된 패킷만을 볼 수 있으며, 우리의 데이타는 다시 안전해진다.

  일반적으로 외부의 노드 A가 Private Network 내의 노드들과 통신하기 위해 라우터와 맺는 연결을 '터널' 이라고 표현한다. 모든 데이타는 이 터널을 통해서 전송되며, 암호화의 대상은 이 터널을 통과하는 패킷이다. 일반적으로 메신져 등이 막혀있는 회사에서 몰래 메신져를 사용하기 위해 SSH 터널링을 이용하기도 하는데, 이와 같은 개념의 터널이다.

  리눅스, MacOSX를 포함한 일반적인 OS들은 터널을 구현하기 위한 새로운 NIC를 제공하는데 이것을 보통 TUN이라고 한다. 이름부터가 Network TUNnel에서 온 것으로 분명히 터널을 위한 것임을 알 수 있다. TUN은 물리적인 카드가 존재하지 않는 소프트웨어로 구현된 가상의 네트워크 인터페이스로, TCP/IP 프로토콜 상의 Layer3을 에뮬레이션 한다. 이러한 TUN 인터페이스의 사용에 대한 매뉴얼은 리눅스 커널 문서에 포함된 tuntap.txt가 가장 좋은 것으로 생각된다.

  리눅스 커널 문서에서는 tun 인터페이스를 열고, read/write 를 하는 방법이 설명되어 있으나, 구체적으로 이를 이용하여 터널을 구현하는 방법은 나와있지 않다. 이에 대한 매뉴얼로 다음 링크를 추천한다.

    >>  http://backreference.org/2010/03/26/tuntap-interface-tutorial/

  VPN을 위한 암호화 알고리즘의 선택은 자유다. 다만 중요한 것은 암호화를 위한 key의 보호인데, key가 노출되면 모든 암호화는 무용지물이기 때문이다. 따라서 어떤 암호화 알고리즘을 사용하는지, 암호화 방식이 어떻게 되는지에 대한 이해보다 오히려 안전한 key 교환을 위한 프로토콜을 이해하는 것이 더 중요하다고 생각한다.

  오픈소스 VPN솔루션인 OpenVPN은 OpenSSL을 사용하며, SSL handshake 프로토콜은 안전한 key 교환을 위한 훌륭한 레퍼런스라고 생각한다. 일반적인 암호화 알고리즘들은 symmetric key(대칭키) 방식을 사용하는데, 이는 암호화와 복호화에 동일한 key를 사용함을 의미한다. 따라서 이 key가 보호되지 않은 회선을 통해 전달된다면 이후의 모든 암호화는 무의미하다.

  SSL handshake는 이러한 key 보호를 위해 RSA를 사용하는데, 이는 비대칭키 방식으로 암호화에 사용되는 key와 복호화에 사용되는 key가 다르다. 따라서 암호화에 사용되는 키가 노출되어도 데이타가 바로 노출되지는 않는다. 다만 암호화에 사용되는 공개키와 복호화에 사용되는 비밀키에 함수관계가 존재하므로, 공개키로부터 비밀키를 알아낼 수 있다. 그러나 또한, RSA는 큰 수의 소인수분해가 어렵다는 점을 이용한 것으로, 공개키로부터 개인키를 계산해내는데 많은 시간이 걸린다.

  SSL handshake 프로토콜은 단순하지만, 핵심은 RSA에 있다. 서버는 자신의 공개키를 클라이언트에 전송하고, 클라이언트는 랜덤한 premaster key를 생성하여 서버의 공개키로 암호화하여 다시 서버로 전송한다. 그리고 premaster key로부터 서버와 클라이언트가 각자 동일한 알고리즘으로부터 key를 생성하면 서버와 클라이언트가 동일한 key를 소유하게 된다.

  VPN은 터널을 구성한 후, 터널 사이의 통신을 암호화 하는 것이 핵심이다. 또한 모든 통신이 터널을 통해 VPN 서버를 거쳐가므로, 서버로부터 나가는 패킷은 모두 안전하다는 가정이 필요하다.

현재 계획중인 포스트는 두 개로, 하나는 VPN(Virtual Private Network), 또 하나는 시리즈물로 포스팅할 멀티미디어 프로그래밍 가이드 입니다.

VPN은 최근 소소하게 알바하면서 알게된 내용을 잊지 않기위해 기록하는 정도로 정리할 것이고, 멀티미디어 프로그래밍 가이드는 좀 구체적이면서 길게, 프로그래밍에 대한 배경 지식은 있으나 멀티미디어 프로그래밍은 처음인 입문자를 위한 시리즈물로 계획중입니다. 그냥 맨땅에 헤딩하는 것 보다는 뭔가 베이스로 볼만한 코드가 있어야 쓰는 사람, 보는 사람 모두 편할걸로 생각되서, android의 멀티미디어 시스템인 stagefright를 예제로 사용할 생각입니다.

남들이 보면 뭐 대단히 멀티미디어에 대해 잘 아는 것처럼 보일지도 모르겠으나 사실 아는거 쥐뿔도 없는 초짜가 블로그질좀 해보겠다고 쓰는거. ㅡ_ㅡ

여튼 작심삼일 하지 않고 꾸준히 글 쓸 수 있도록 노력하려고 마음먹는 중.

  lambda를 지원하는 언어는 많다. 새삼 이제와서 C++이 lambda를 지원한다고 할 때 그냥 '아, 그렇구나' 하고 넘어갈 법도 한 문제다. 그리고 내가 선호하고 좋아하는 많은 언어들(python, vala 등)도 lambda를 제공한다. 내가 이제와서 lambda에 대해 고민하는 것은 과연 lambda의 효용이 무엇인가 도저히 모르겠어서이다.

  일단 lambda가 무엇인지부터...

  본 주제로 넘어가기 전에 lambda가 무엇인지부터 보고 넘어가자.

  쉽게 말해 lambda는, 이름없는 함수다. 예를 들어보자.

ex1) python

ex2) vala (anonymous method)

 (a) => { stdout.printf ("%d\n", a); }

  파이썬에서는 함수 자체가 역시 객체다. 즉 파이썬에서의 lambda는 lambda 문으로 정의한 호출 가능한 함수 객체를 리턴하는 것이다. vala 역시 마찬가지의 개념으로 => 문법에 의해 함수 객체를 리턴한다. 다만 vala에서는 anonymous method라는 용어를 사용하지만 결국은 같은 개념이다.

  lambda를 사용하면 함수의 파라미터로 함수 객체를 - C라면 함수 포인터가 될 것이다 - 주고 받아야 하는 상황에서 따로 함수를 정의하지 않고, 바로 파라미터 내에서 lambda를 이용해 객체를 생성, 전달할 수 있다. 그렇지만 단지 이런 용도라면 구지 언어에서 lambda라는 기능을 제공해야 할 이유가 있을까.

  미리 말하지만, 이 포스트는 lambda를 사용하는 이유에 대해 설명하는 글이 아니다. 나는 아직까지 그 해답을 얻지 못했으며, 또한 일반적인 경우에 lambda의 사용을 최대한 피하는 편이다. 그럼에도 소위 최신 트렌드를 따라가는 수많은 언어들이 - 심지어는 C++ 마저! - lambda를 앞다투어 지원하는 것에는 무언가 이유가 있을테지만, 난 아직 그것을 모르겠다.

  매우 단순하다. 앞서 말한 lambda의 정의 자체가 내가 생각하는 바람직한 코드의 형태와 맞지 않기 때문이다. 컴퓨터가 할 수 있는 일은 매우 한정적이기에, 나는 이름을 짓는다는 것에 상당한 의미를 부여하고 있다. 변수의 이름을 정하는 것, 함수의 이름을 정하는 것이 개발자가 코드에 할 수 있는 최초의 권리라고 생각한다.

  lambda라는 것은, 개발자 스스로 이름 짓기에 대한 권리를 포기함으로써 코드의 가독성을 떨어뜨린다. 재미삼아 하는 short coding이라면 lambda만큼 유용한게 없겠지만은 코드는 짧다고 좋은게 아니기 때문이다. 코딩의 대부분은 코드를 쓰는 것이 아니라 읽는 것이기에, 나는 lambda의 사용을 지양한다.

  그렇지만 너무나 많은 언어들이 lambda를 지원하고 있다. 파이썬의 하위도, C++ 위원회와 비야네, 그리고 수많은 똑똑한 사람들이 어떠한 합리적인 판단하에 lambda라는 기능을 넣었으리라 생각한다. 아무리 생각해도 최소한 나보다는 똑똑하고 경험많은 그들이 내가 생각한 문제를 생각하지 않았을리는 없을 것 같고, 그렇다면 이름짓기의 권리를 포기하면서라도 얻고 싶은 무언가가 있을테다. 하지만 난 그것을 모르겠다.

  사실 내 생각에는, lambda를 사용하는 사람들중 많은 비율이 그저 습관적으로 사용하는 것일 거라고 생각한다. lambda를 사용함으로 인해 그저 함수 정의를 한번 덜 할 수 있는 편리함에 빠진 것이다. 그렇지만 다시 생각해보면 과연 그로인해 불필요한 코드가 줄지도 않았을테고, 결국 이름만 짓지 않았을 뿐 새로운 함수를 정의한 것은 마찬가지라는 것이다.

  나는 lambda의 불필요함에 대해 말하기 위해 이 포스트를 작성하는 것이 아니다. lambda를 가치있게 만드는 무언가를 찾기 위한 노력이다. 이 누추한 블로그에 오는 사람이 많지 않다는 것도 알고, 이 포스트를 읽을 사람도 얼마 되지 않는다는 것도 알지만, 여기저기서 앞다투어 내놓는 lambda 지원이라는 이 기능이, 진정으로 프로그래밍 언어에서 갖는 의미가 무엇인지에 대해 누군가 답을 주었으면 하는 바람이다.

  TDD는 어렵다. 리팩토링도 어렵다. 많은 부분에 있어서 TDD를 시도하지만 스스로 도대체 어떤 테스트를 만들어야 할 지 몰라 그냥 진행할 때도 많다. 테스트 작성이 쉽지 않으면 당연히 리팩토링도 어렵다. 그러나 TDD와 리팩토링은, 나에게 있어서는 그나마 쉬운 agile method에 속했다. 개인적인 실천이 가능하기 때문이다.

  오늘의 세미나를 계기로 가장 많이 생각해보게 된 주제는 '고객참여'와 'code ownership'이다. 각각의 주제에 대해 생각도 정리해볼 겸 간략하게 요약해보자(세미나 내용의 요약이 아니라 내 생각의 요약이다).

  1. 고객참여

  개발 프로세스에 고객을 참여시키는 것이다. 이 고객참여에는 여러가지 난관이 존재한다. 첫 째로, 고객이 참여하기를 원하지 않는 경우다. 약간의 게으른 고객을 예로 들 수 있겠는데(아마 정부쪽 과제가 이렇지 않을까 싶다), 신경도 안쓰고 있다가 마지막에 완성된 결과물만을 받기 원하는 경우다. 이 부분에 대해 고객참여가 개발에 필수적이라고 생각하는 내 이유는, '고객은 스스로 무엇을 원하는지 모르기 때문에 항상 확인시켜줘야 할 필요가 있다'는 것이다. 이럴 경우, 고객을 개발에 참여시키기 위해 어떻게 고객을 설득하느냐가 또 문제가 된다. 하지만 얘기가 길어질 것이므로 여기까지.

  두 번째, 고객이 적극적으로 참여하지만 의도한 대로 움직이지 않는 경우다. 이 경우는 개인적으로 심각한 악례가 좀 있는 편인데, 고객(갑)이 개발사(을)를 '노예'로 취급하는 경우가 많다. 개발자의 출퇴근까지 관리하기를 원하고, 하물며 문제가 없는 상황에서도 개발자의 퇴근을 기분나빠한다. 구체적인 실례를 들자면, 얼마전까지 내가 투입되었던 과제에서는 고객이(고객사의 직원들이) 번갈아가며 개발자들을 감시하고 혹시나 퇴근하지 않았는지 확인한다. 매일매일 다음날 아침 해 뜰때까지 과중한 업무가 반복되는걸 고객이 당연하게 여기고 그것을 요구한다.

  아무리 agile에서 제시하는 실천사항중에 잦은 릴리즈와 지속적인 test, 빠른 피드백이 있다지만, 주말포함 일주일에 5번씩 하는 릴리즈와 QA팀의 쉴 새 없는 검증, 개발자들의 실시간 응답을 기대하는 고객과는 일하는게 너무너무 힘들다. 실제로 나는, QA에서 언제든지 문제를 올리기만 하면 바로바로 응답하기 위해 상시대기하며, 문제가 하나라도 올라올 경우 실시간으로 응답하고 디버깅하면서, 또한 각각의 문제 수정이 이루어질때마다 곧바로 다시 QA가 검증에 들어가고, '검증 - 수정 - 릴리즈'의 반복이 밤샘으로 하루밤만에 5~6번씩 반복되는 과제에서 일했다. 또한 앞서 말했든 그러한 매일이 일주일에 최소 이틀, 많으면 5일까지도 발생했다. 고객이 그러한 것을 원했고, 고객이 원하는 일정은 언제나 '당장' 이었다. 고객은 필요 이상으로 적극적으로 개발에 참여하면서, 특정 모듈의 일정이 지연되면 그 모듈의 담당 엔지니어의 이름까지 거론해가며(내가 많이 당했다) 마녀사냥을 했다. 이런 고객과는 agile에서 말하는 '진짜' 고객참여는 이루어지기 힘들다.

  이러한 상황이 나에게는, 특히나 나의 두 번째 경험과 같은 고객과 함께 일해야 할 때, 어떻게 agile을 실천할 수 있을지가 매우 도전적인 과제다.

2. Code ownership의 확산

  오늘의 세미나에서 인상깊었던 문구중에 하나가 'That's not my job'이다. 회사가 한 사람 한 사람에게 professionalism을 요구할 때 발생할 수 있는 문제다. 한명의 엔지니어가 특정 모듈에 대해 너무 강한 ownership을 갖게되면, 그 모듈을 벗어나는 순간 그 일은 내 일이 아닌것이 된다. 오늘의 세미나에서 나왔던 말은 아니지만 개인적으로 인상깊게 느꼈던 문구중에 하나가 'who's wrong이 아니라 what's wrong을 고민하라' 였는데, 엔지니어가 모듈별로 ownership이 분산되면 문제가 발생했을 때 마녀사냥 - who's wrong? - 이 이루어지기 쉽다. 이는 엔지니어 개개인을 매우 방어적으로 만들고, 의견제시를 주저하게 만든다.

  Non-agile한 상황, 그러니까 팀이 code ownership을 함께 공유하지 않는 경우 발생할 수 있는 또 하나의 문제는, 누구도 ownership을 갖지 않은 문제가 발생했을 때이다. 이런 문제는 기술적으로 해결이 쉽든 어렵든 불필요한 회의를 하게 만든다. 그리고 모두가 외친다. That's not my job. 앞서 언급한 문제와 동일하다고 생각할 지 모르지만 여기에는 한가지 추가적인 쟁점이 있다. 결국 문제는 문제이고 누군가는 해결해야 한다는 것이다. 그 이야기는 즉, 누군가는 추가적인 일이 부과된다는 것이다. 이런 상황에서는 일반적으로 해결책에 대한 아이디어를 먼저 제시한 사람이 문제를 떠안게 된다. 사람은 대부분 - 테레사 수녀같은 예외도 있겠다 - '나만' 고생하는 것을 싫어한다. 누군가 한명이 해결책을 제시하면 함께 숙고하고 발전시키기 보다는, '아, 그럼 되겠네. 말 꺼낸 사람이 해야지'가 되어버리는 것이다.

  팀이 code ownership을 공유하는 경우는 이런 문제가 없다. 전체 코드에서 '내 코드'는 존재하지 않는다. 마찬가지로 '남의 코드' 또한 존재하지 않는다. 모든 것은 '우리의 코드'이며 '우리의 문제'이다. 이런 분위기는 의견 제시를 자유롭게 만든다. 내가 제시한 의견이 나를 불편하게 하지 않는다. 다른사람이 제시한 의견에 오류가 있다면 문제를 해결하기 위해 들어야 할 '내 노력'이 추가된다. 따라서 나는 항상 다른 팀원의 의견을 숙고하고 더 나른 방법이 없는지 고민해야 한다.

  Code ownership이 팀 전체로 확산될 경우, 또 하나의 이득이 있다. 일반적으로 소프트웨어 엔지니어는 학습의 욕구가 강하다. 많은 경험을 해보아 고민없이 해결할 수 있는 문제는 별로 선호하지 않는다. 하나의 큰 시스템은 다양하고 복잡한 문제가 혼합되어 있기 때문에, 팀이 함께 모든것을 공유할 경우 이런 엔지니어 각각의 학습욕구를 충족시킬 수 있다.

  Code ownership의 확산을 위한 방법으로, review되지 않은 코드는 repository에 merge되지 않도록 하는 시스템(e.g. gerrit)을 사용하는 것도 가능할 것 같다(Thanks to 재원). 팀이 함께 코드리뷰할 시간을 정기적으로 가지고, 팀이 동의한 코드가 repository에 merge되게 한다면 팀원 '개인의 죄'는 사라진다. 시스템에 문제가 발생했을 때 팀의 누구도 '너 때문이야' 라고 말하지 못한다. 그 코드에 대한 리뷰의 책임이 모두에게 있었기 때문이다.

  코드리뷰는 귀찮다. 코드리뷰가 귀찮아서, '컴파일 되네? 돌려봐. 잘 돌아? 뭐 대충 멀쩡한거 같네. OK'와 같은 상황이 발생 할 수 있다. 이를 위해 떠오르는 해결방안은 역할 돌리기다. 아주 작은 스텝으로, 팀원은 코드를 교환한다. 어제는 내가 계산기의 덧셈연산을 만들었다면(물론 이정도로 작은 단위로 움직이진 않겠지만), 오늘은 다른사람이 곱셈을 만든다. 내일은 나눗셈을 만들기로 했다면, 누가 내일 나눗셈을 만들어야 할 지 모르므로, 오늘의 곱셈 리뷰에 모두가 적극적으로 참여해야 한다.

  그러나 이 방법은 위험을 동반한다. 엔지니어라면 누구나 동의하지만 코딩이 매일매일 잘 되는 것이 아니다. 따라서 어제 리뷰를 열심히 했더라도 오늘 내가 맡은 부분에 진척이 없을 수도 있다. 그리고 그것이 내일 누군가에게 돌아갈 것이라고 기대한다면, 팀원은 다시 게을러 질 수 있다. 코드리뷰는, 여전히 어려운 문제다.

3. Pair Programming

  서론부분에서 언급하진 않았지만 agile에서 협업의 대명사는 pair programming이다. 오늘의 세미나에서는 다른 팀원에 비해 performance가 뛰어난 일부의 팀원이 pair programming을 거부할 경우 어떻게 할 것인가에 대한 질문이 있었다. 패널들의 다양한 의견이 있었지만 패널의 의견은 배포되는 세미나 자료를 통해서 다시 볼 수 있을거 같아 여기서는 내 생각을 정리하도록 한다.

  일단 performance가 뛰어난 팀원이 pair programming을 거부하는 이유를 생각해보자. 가장 큰 이유는 pair programming으로 인해 자신의 개발속도가 더뎌진다고 느끼는 것이다. 혼자하면 더 빠를텐데, 파트너가 고민하는 사이 자신은 모든 답을 내어놓을 수 있고, 코딩도 내가 더 빠르다. 파트너의 '왜 그렇죠?'라는 질문이 반복될 경우 짜증을 느낄 수도 있다.

  그러나 한가지 다행인점은, 진짜 못된 사람은 별로 없다는 것이다. 정말 성격이상이고 독불장군이라 pair programming은 죽어도 못해먹겠다고 주장하는 사람은 거의 없다. 일반적으로는 혼자 작업하는 것에 비해 갑갑함을 느끼고 짜증날 뿐이다. 이 경우에는, 적어도 내 생각에는 해결책이 있다.

  먼저 임의로 경험많고 performance가 뛰어난 팀원을 senior, 그렇지 못한 팀원을 junior라고 표현하자. 소프트웨어는 기술적으로 변화가 심한 분야라서, senior라 할 지라도 모든 것을 알고있는 엔지니어는 없다. junior는, 아무리 경험이 부족하더라도 정말 아무것도 모르지는 않는다. 일반적인 경우 정말 아무것도 모른다면 엔지니어도 아닐 뿐더러 한 회사에 들어가는 것 자체가 불가능 했을 것이라고 보는게 옳다. 따라서 내가 제시하는 한 가지 방법은, senior를 그가 경험하지 못한 부분을 작업하고 있는 junior에게 붙이는 것이다. 이 경우 구지 pair programming을 언급할 필요는 없다. '안해본 거지만 당신은 실력이 좋으니깐 잘 할거야. 좀 도와줘'라고 말한다면, '나는 다른사람 도와주는 것 따위엔 흥미 없어요'라고 말할 사람 몇 되지 않는다. 진짜로 그런 사람이 있다면, 아무리 performance가 좋더라도 차라리 팀에 없는것이 이롭다.

  말했듯이, 일반적으로 소프트웨어 엔지니어는 학습욕구가 매우 강하다. performance가 뛰어난 엔지니어라면 더욱 그러할 것이라고 예상할 수 있다. 학습욕구가 강하지 않았다면 실력이 좋을 수는 없는것이니까 말이다. '안해본 거지만 당신은 실력이 좋으니깐 잘 할거야. 좀 도와줘'라는 말은 senior 엔지니어에게 후배를 도와주겠다는 선의와 함께, 호기심을 자극할 수 있다. 소프트웨어는 언제나 경험해 보지 못한, 신기술에 목말라하는 사람들이기 때문이다.

  그리고 이런 조합이 이끌어내는 또 하나의 장점이 있다. 나같이 성격 참 부담없고 맘 편한 사람은 문제가 없을지 모르지만, 전문분야의 senior를 붙여준다면 junior 엔지니어는 시험치는 기분을 느낄 수도 있다. 그리고 필요 이상으로 의존하게 된다. 어차피 내가 생각한 것보다 더 나은 훌륭한 아이디어를 이사람이 언제나 가지고 있을 것이라 무조건 적으로 믿어버린다면, pair programming의 의미가 사라진다. 아무리 실력 좋은 엔지니어라 하더라도, 처음 해보는 것이라면 이것저것 모를 수도 있다는 생각이 오히려 junior를 편하게 만들어 줄 수도 있다. 이는, 자유로운 의견 제시와 토론으로 이어질 것이다.

  여기까지가 오늘의 세미나에서 나에게 던져진 생각할 과제였다. 하나하나 어렵지 않은 주제가 없으니, 역시 많은 사람들의 아이디어와 토론이 필요해 보인다.