SW 개발이 좋은 사람

키보드만 사용하던 어느 날,

마우스란 것이 세상에 나타났고, 

컴퓨터로 그림 그릴 때 사용하는 것인 줄 알았다.

개발을 할 때에는 빠른 속도로 타이핑을 하고, 마지막에 엔터키를 탁 치는 맛이 있었다.
(지금도 그런 개발자를 간혹 본다)

군대를 제대하고 복학하니,

대부분의 사람들이 윈도우 3.0과 함께 마우스를 사용하고 있었고,

학교 실습실에서는 마우스 볼을 빼가는 문제로 골머리를 앓았다.

그러던 어느 날 광마우스가 나타났고,

누군가는 마우스 볼 빼가는 문제가 해결되었다고 좋아했다.

누군가는 광마우스는 너무 가벼워서 사용하는 기분이 안 난다고 사용하지 않았다.

그리고, 학교 실습실에서는 마우스가 통째로 사라지는 문제가 생겼다.

마우스가 몇 천 원짜리가 되면서 훔쳐가는 사람은 사라졌고,

어느덧 선이 사라졌다.

게임 할 때 반응속도가 느리다고, 선을 사용하는 사람도 있고

배터리가 내장되어서 무겁다고 불평하는 사람도 있었다.

그리고, 어느덧 버튼 사이에 휠(wheel)이 끼어들더니, 상하 스크롤을 할수 있게 되었다.

그렇게 하루 종일 마우스만 누르면서 일하고 있다.

오래 되었다.

터치 패드처럼 마우스 전체가 터치되고,
상하좌우스크롤되는 맥북용 마우스를 몇 일 사용하고서

등산 중에 

반대편에서 산을 내려 오던 사람이 내 앞에 가던 사람에게 내려가는 길을 물었다.

그러자 익숙한 듯이 간단하게 대답했다.

“가다가 왼쪽으로 내려 가세요”라고 말했고,

물어보던 사람은 “왼쪽이요?”이라고 다시 물었다.

“가다가 첫 번째 길에서 왼쪽으로 가도 되고, 두 번째 길에서 빠져도 됩니다.”라고 말하고 다시 걸어 갔다.

첫 대답을 듣고 순간적으로 "왼쪽이 맞나?"라는 생각이 들었다.

길을 묻고 답할 때 흔하게 하는 실수로

가는 사람의 입장에서는 왼쪽이지만, 반대로 오는 사람의 입장에서는 오른쪽 일 수 있기 때문이다.

왼쪽이 맞았다.

상대의 입장에서 답변한 것이었다.

상대를 배려하는 마음씨에 감탄하면서 여러 가지 생각이 들기 시작했다.

다른 사람과 대화를 하다 보면, 항상 나의 입장에서 이야기 하게 된다.

내가 아는 건 상대도 안다고 생각하고 말하거나

단어만 뱉어놓고 아예 알아서 뭔가를 해주길 원하는 등

상대의 입장에서 이야기 할 때 보다, 나의 입장에서 이야기 하는 것이 대부분 일 것이다.

좀 심한 사람은 자신이 편한 데로 이야기 하고,

“재는 왜 그러는지 모르겠다”라는 말을 자주 하기도 한다.

직장 생활이나 갑과 을의 관계에서는 아주 흔하게 봤었다.

그렇게 길을 조금 더 갔다.

어느 길로 갈까 싶어서 표지판을 보다 그만 웃고 말았다.

직진을 하면 정상으로 가고, 우측으로 빠지면(내려 올 때는 왼쪽이 된다.) 

아까 물어보던 사람이 원하는 길이 되는 것이다.

길을 물어보던 사람은 갈림길을 조금 전에 지나쳐 왔고

자신이 지나친 건지 아직 도착하지 않은 것인지 몰라서 물었던 것 같았다.

길을 제대로 아는 사람이 있었다면 되돌아 가서 내려가라고 했을 것이다.

그러면 한 10~20분 정도 시간을 줄였을 것이다.

더욱이 이 갈림길로 내려가면 계곡이 있어서 쉬어가기 좋다.

(몇일전 쏟아진 폭우로 계곡의 물이 정말 좋았다.)

지나쳐서 내려가는 길은 능선을 따라 걸어가야 해서 그늘이 별로 없고 덮다.

30~40분을 가야 왼쪽으로 빠지는 길이 나오기 때문에 계속 왜 왼쪽에 길이 없지라면서 내려갔을 수도 있다.

그날찍은 사진

조금의 잘못된(?) 대화로,

목표는 이루었지만 시간과 즐거움을 제법 많이 놓친 것이다.

“지나온 것 같기도 하고, 아닌 것 같기도 한데...”라며 질문을 했다면 좀더 조심스런 대답이 있지 않았을까?

첫 번째 왼쪽으로 내려가는 길은 30~40분을 걸어가야 나오기 때문에 답변이 조심스러워 졌을 수도 있을 것이다.

답변하던 사람이나 뒤에 있던 나도 제대로 길을 좀더 알았거나 (지식이 더 있었거나)

답변을 길게 했더라면 어떠했을까 하는 생각도 들었다.

“한 40분 쭉 내려가시면, 왼쪽으로 내려 가는 길이 보입니다. 그 길을 따라 가시면 되요”

40분뒤에 내려가는 길이 나온다는 말을 들었다면 지나쳤다는 생각을 했거나,

자신의 생각과 다른 답변에 질문했던 사람이 이상하게 생각해서 더 상세하게 질문했을 것이고, 

다른 결과가 나올 수도 있었을 것이다.

답변을 듣고 얼마나 더 가야 하냐를 물어봐도 좋았을 것이다.

일을 하다 보면 이와 같은 서로간의 대화 문제로 항상 많은 문제가 생겼다.

몇 년 전에 SI 개발을 하면서 있었던 일이다.

어떤 기업의 시스템 구축을 하기 위해, 분석 회의를 진행하고 있었다.

해당 기업의 임원 분이 계속 엑셀 다운로드 기능이 있어야 한다고 강조 했다.

어떤 기능을 이렇게 만들어야 한다고 이야기 하고 나면, 

리스트 부분에서는 꼭 엑셀 다운로드도 있어야 한다고 강조 했다.

엑셀을 참 좋아하는 분이라고 생각하다,

어느 날 잡담 중에 지나가는 말로 “왜 그렇게 엑셀 다운로드를 모든 기능에 넣습니까?”라고 물어봤다.

“데이터가 언제 사라질지 모르니, 개인이 등록한 정보는 엑셀로 다운받아서 보관하게 해줘야 합니다.”

다른 회사에서 일하다 이직하고 처음 맡은 SI라며 

이전 회사에서는 자주 데이터가 없어지는 문제가 생기거나, 저장 공간 문제로 데이터를 삭제한다고 했다.

데이터 베이스에 데이터가 저장되면 누군가가 삭제할 수 없고, 

개인이 등록한 정보는 개인이 관리하는 기능(myPage)에서 한 눈에 볼 수 있다고 설명했고, 

엑셀 다운로드는 줄이기로 했었다.

고객은 자신의 사정과 상황에 따라 말을 하고,

개발자는 상세한 이유를 모르니 말한 데로 개발을 한다.

그렇게 시간이 지나면 안해도 될 일을 하거나,

처음엔 사소한 것들이 프로젝트 후반기로 가면 눈덩이처럼 커져서 큰 문제가 되기도 한다.

SW 개발은 내가 나에게 발주하는 상황보다,

고객이나 직장 상사와 같은 타인의 요청에 의해 이루어 지는 경우가 더 많다.

타인에 의해 진행되기 때문에

제대로 된 개발과 빠른 개발을 하기 위한 가장 중요한 기본 능력은 대화 능력인 것 같다.

왼쪽인지 오른쪽인지 각자의 위치에서 방향을 이야기 해서 힘들 수 있고,

서로 가지 않은 길을 가다 보니 경험 부족등으로 이리 저리 방황할 수도 있다.

이런 문제를 해결하는 건 서로가 서로에게 계속 물어보고 답변해 가는 것일 것이다.

하지만 현실적으로는 각자의 일이 바쁘거나, 사람이 싫거나, 대화가 싫어서 등으로 그러지 못하는 것 같고,

그렇게 아주 먼 길을 돌아가는 걸 많이 봤다.

계곡에 발 담그고 앉아서

HTML의 VIDEO 태그로 지정한 동영상이 모바일 기기에서 재생되지 않는다는 연락을 SI 개발팀으로 부터 받았다.

1년전쯤 인터넷에서 검색하여 정리한 자료에 따르면,

웹브라우저에서 동영상을 제대로 보려면 웹브라우저에서 해당 동영상의 압축 코덱을 지원해야 한다는 것이었다.

안드로이드의 크롬에서는 문제가 없었다.

안드로이드의 삼성 브라우저에서는 MP4 파일을 H264로 생성할 때 baseline 1.3으로 해야 한다고 한다.

아이폰의 사파리에서는 플레이가 되어야 했지만 되지 않았다.

다시 인터넷으로 자료를 찾아보니 또 다른 방식으로 작성해야 한다고 했다.

문제의 동영상을 확인하니 baseline 2.0으로 생성한 파일이라, 다시 작성하라고 말했다.

그리고, 아이폰은 안되는 것 같으니 국내에서 많이 사용하는 안드로이드를 선택하라고 말했다.

둘다 지원되려면 미디어 서버를 구축하거나 두개의 동영상을 생성해서 처리하라고 말했다.

SI 개발팀 팀장이 이해가 되지 않는다며 해당 동영상을 코덱별로 테스트 해보고, 좀더 찾아보겠다고 했다.

그리고, 다음날 직접 접근하면 코덱과 관계없이 안드로이드와 아이폰에서 재생된다는 것을 찾았다.

보안을 위해 첨부한 파일은 웹 폴더가 아닌 다른 폴더에 저장하고

Java 프로그램에서 해당 파일을 읽어서 전송해 주는 방식에 문제가 있다는 것이었다.

해당 파일을 웹으로 직접 접근하면 문제가 없었다.

내가 틀린 것이었다.

일을 하다 보면 틀릴 수도 있고, 맞을 수도 있다.

하지만 회사 내에서 나름 기술을 책임지고 있는 사람이 틀린 것이고, 나태한 태도에 부끄러웠다.

SI 개발팀 팀장의 접근법은 원래 내가 사용하던 방법이다.

뭔가 문제가 생겼을 때는 누군가 맞다고 이야기해도, 전에 내가 해 봤어도 처음부터 하나씩 해봐야 한다.

동영상 코덱은 웹브라우저에서 지원해야 한다는 편견으로 제대로 테스트 해보지 않고,

간단한 검색만 하고, 원래 안되라며 넘어갔다.

더욱이 검색한 자료에 아이폰의 사파리는 H264를 지원한다고 직접 정리했는데

Baseline 3.1으로 해야 한다는 다른 검색 결과를 보고 그냥 안 된다고 말한 것이다.

상반되는 결과가 있으면 한 번 더 확인해야 했었고, 맘에 걸렸지만 넘어갔다.

삼성 웹 브라우저도 삼성 매뉴얼에서 확인했지만 1년이 지난 내용이었다.

1년전에 정리했지만, 조사한 자료가 몇 년 된 것들이었다.

바빠서 자료를 제대로 조사하지 않았었고 나중에 보강해야 지라며 넘어갔었던 것이다.

Java로 파일을 읽어서 다운로드 하는 것도, 혹시 라는 생각만 하고 이런 저런 일로 핑계대며 확인하지 않은 것이다.

코덱에만 신경을 썼다.

결과는

잔뜩 흐린 날 혼자 부끄러운 하루를 보내는 것이었다.

하루 종일 흥겨워하며 돌아다니는 누군가를 봐야했다.

개발자가 하면 안 좋은 일 중에

가장 첫번째는 준비 되지 않은 개발자가 팀장이 되는 것 일 것이다.

개발을 잘 하는 것과 좋은 리더 (팀장)이 되는 것은 당연이 다른 것이고, 많은 사람들이 말하는 것이다.

배틀스타 갤럭티카(Battlestar Galactica)라는 미드를 보면(시즌 2, 에피소드 17 -The Captain's Hand 참고)

유능한 엔지니어(개발자)가 준비 없이 리더가 되면 조직을 어떻게 말아 먹는지를 잘 보여준다.

다음으로, 하지 말아야 하지만 가장 흔하게 하는 일이 신입 개발자 교육인 것 같다.

중소업체에서는 신입 개발자 교육을 관련 업무의 선배가 진행하게 되는데, 도제식으로 진행하는 경우가 많다.

군대의 사수/부사수처럼 진행하는 경우가 가장 흔할 것 같다.

모든 것이 낮선 신입에게 어떤 것을 가르쳐도 큰 효과가 없고, 여러가지 이유로 아예 기억 조차 못 하는 경우가 허다하다.

그러다 보면,

"아까 말해줬는데", "어제 말해줬는데", "왜 아직도 못하냐", "이런 것도 못하냐"며 짜증을 내게 되고 점점 감정이 격해진다.

가르치는 개발자는 짜증내는 빈도가 늘어나고,

교육 받는 개발자는 반감이 늘어나거나 기가 죽는 것을 많이 봤다.

그리고, 가르치는 사람의 입장에서는 아주 많은 지식을 전달하거나 어려운 지식을 전달하는 것이 아니라고 생각하기 때문에

"이런것도 못해요", "생각 좀 해요" 등의 언어 폭력이 발생한다.

개발을 잘 하는 것과 잘 가르치는 것은 아주 다르다.

전문 교육자가 가르쳐도 제대로 받아들이는 학생이 몇 명 없는데,

비교육자인 개발자가 어떻게 잘 가르칠 수 있을까?

개발자 컨퍼런스나 세미나에 가면 쉽게 볼 수 있는 장면이 전문 용어만 남발하며 혼자서 발표하는 것이다.

한 교수님이 후배 교수나 학생들에게 자주 하신 말씀이 있다.

강의 내용을 학생들이 이해하지 못하면 그건 내용을 제대로 설명하지 못한 교수 잘못이라고 하셨다.

그 분 말씀대로 모두 교수 잘못은 아니겠지만,

상대가 제대로 이해 하지 못했다면 내 설명에 문제가 없는지 고민해봐라는 뜻일 것이다.

교육에서 가장 중요한 건 자존감이라고 한다.

스스로 찾아서 노력할 수 있는 자존감이 중요하다고 하는데,

그 자존감도 무너뜨리고, 회사에 대한 마음도 무너뜨리는 것이 아닐까한다.

교육에 미숙한 선배와 업무에 미숙한 신입끼리 진행되는 교육속에 서로에 대한 부정적인 생각만 커지는 것 같다.

적응하지 못하고 떠난 1년차 개발자와

떠난 개발자를 대신해 입사한 신입 개발자를 교육하는 모습을 보며

두명의 대리가 있었다.

160cm 언저리로 키도 비슷하고, 축구를 즐기는 취미도 비슷했다.

한 명은 7년이라는 직장 생활을 한 회사에서 보냈고

다른 한명은 다른 회사에서 1년 정도 일하다 경력으로 입사해 6년째 둘이 친구로 지냈다.

한 회사에만 있은 대리는 충청도라서 그런 거야 라는(?) 말과 함께 모든 것이 느리고 느긋하다.

다른 한 대리는 항상 적극적이고 경쟁적이기도 했다.

한 회사에서 시작해서 인지, 시작하는 모습을 기억하는 사람들과 함께 지나칠 정도로 친했고,

누가 무슨 말을 하든 예란 말과 함께 넘어가기 일 수 였다.

때로는 그 위의 과장이나 차장이 말을 심하게 할 때도 있지만 이내 웃으며 넘어갔다.

다른 한 대리는 누군가 자신에 대해 조금이라도 부정적이면 가시를 곤두세우는 성격이었다.

(나이가 약 20년 정도 차이 나는 나에게도 마찬가지였다.)

한명은 나무라면 그냥 자신의 잘못이고

한명은 나무라면 따질 건 다 따진 후에 자신의 잘못을 부정하는 것이 대부분이었다.

그래서 직원들이 둘을 대하는 태도가 달랐다.

한명은 편하고, 다른 한명은 모두 불편해 했다.

다른 한명은 다른 대리에게 그렇게 하지 말라고, 그러니 모두가 널 무시한다고 충고했지만

둘은 그렇게 각자의 성격대로 살았다.

어느 날, 팀장이 조금 더 회사에 있었던 대리를 조그만 프로젝트의 PM으로 임명했다.

그리고, 다른 대리는 다른 주임에게 저 친구가 있는 이상 모든 기회는 그 친구에게 먼저 갈 것이고,

이 회사에서 나는 두 번째 기회만 있다는 말을 하며, 친구가 소개한 회사로 떠나갔다.

6년간 많은 직원이 입사하고 떠나갔다.

그 속에 남아 있는 이 친구는 묵묵이 일을 했고, 앞으로도 그렇게 할 것이다.

과연 둘 중 어떤 대리가 회사에 더 도움이 되었고,

자신의 삶에 충실했는지? 더 나은 사람인지 알 수 없다.

참 다른 두 개의 개성과 삶이 있었다.

회사를 떠나고 내 생일이라고 내가 좋아하는 달달한 커피와 간식 세트 쿠폰을 보내온 걸 보면서….

배틀스타 갤럭티카(Battlestar Galactica)라는 미국 SF 드라마를 약 10년만에 다시 보기 시작했다.

Flight of The Phoenix (시즌 2, 에피소드9)을 보던 중에

드라마 내용이 직장 생활과 겹쳐지며 이런 저런 생각이 들기 시작해서 몇 가지 정리하고 싶은 생각이 들었다.

Flight of The Phoenix에서는 오랫동안 강력한 적(Cylon)을 피해 도망 다니는 반복되는 삶이 그려지는데,

지친 병사들은 서로에게 도전적인 태도를 취하게 된다.

오래된 장비들은 자꾸 문제를 일으키고, 서로를 탓하며 짜증내는 가운데, 이러한 태도는 상관에게도 망설임이 없어진다.

그러던 중 갑판장 (Chief)은 자신에게 문제가 있다고 생각하고, 해결 방법을 찾던 중에 새로운 비행체 제작을 시작한다.

처음에는 모두 부정적이라 업무 시간 이후에 혼자서 시작한다.

당연하지만 여러 어려움을, 여러 사람들이 참여하면서 새로운 비행체를 완성하고 갈등을 풀어간다는 것이 주요 내용이다.

서로가 서로를 도전적으로 대하는 모습에,

그리고 그 모습을 (강력한 적에 대항하기 위해) 어쩔 수 없이 참고 대해야 하는 모습에 직장 생활이 겹쳐졌다.

같은 자리, 같은 사람, 같은 일…

5년, 10년 반복되는 직장 생활이 그대로 표현된 것 같았다.

서로의 이해 관계에 의해 떠나지 못하는 자와 떠나 보내지 못하는 모습이 똑같아 보였다.

다른 점은 문제의 해결 방법인 것 같다.

드라마에서는 우주에서 다른 곳으로 갈 데가 없지만, 현실에서는 퇴사를 하는 경우가 대부분 일 것이다.

드라마에서는 퇴사 없이 해결하는 방법으로 새로운 프로젝트의 시작을 제시하였다.

모든 것이 익숙하고 오랜 된 것에, 무엇인가를 새로운 것이 만들어 진다는 것이 활력이 될 것 같다.

SW 개발 업종에서는 보다 도전적인 내부 프로젝트 참여나, 개인적으로 진행하는 개발 프로젝트가 지친 직장생활에 활력이 될 수 있을 것이다.

특히, SW 개발자는 고객이나 직장 상사의 지시에 의해 개발을 하는 을의 입장인 경우가 많다.

자신이 생각하고 자신이 자신에게 지시하는 개인 프로젝트가 오랜 직장 생활(Flight of The Phoenix)을 유지할 수 있는 방법 중 하나가 아닐까 싶다.

누군가 같이 하면 더 좋을 것이고, 그것이 오픈 소스를 하는 의미 중 하나가 아닐까 한다.

Flight of The Phoenix이 자신의 임무에 충실한 직원들의 이야기라면,

이후의 에피소드(ep 10 이후)에서는 말 안 듣는 부하들 이야기가 많이 나온다.

아폴로와 스타벅이 대표적이다.

상명하복을 중시한다는 군대에서 두 사람은 드라마 내내 상관을 무시하고, 상관과 싸운다.

하지만 아이러니 하게도 가장 유능한 조종사로 그려진다.

상관인 제독의 명령에 따르지 않고 단독으로 움직여 부활선의 존재와 같은 중요한 정보를 얻기도 하고 (Resurrection Ship, ep 11),

페가수스 함장의 잘못된 판단을 막기 위해 고군분투 한다 (The Captain's Hand, ep 17).

(The Captain's Hand는 유능한 엔지니어가 별도의 교육 없이 리더가 되면 조직을 말아 먹을 수 있다는 교훈을 주는 것 같다.)

회사에서도 유능한 직원일수록 상사의 말을 잘 안 듣는다.

자신이 옳다고 생각하는 일을 하기 때문으로, 불평도 많고 말도 많다.

주어진 일에 대하여 납득이 되지 않으면 일을 하지 않기도 한다.

이들이 상사가 되면 현실에서는 엄청난 고통이 따르기도 한다.

영화나 현실이나 모두들 조직의 목적을 위해 움직이는 것으로 협력하는 방법을 찾는 것이 중요하고 해결 방법은 없어 보인다.

그냥 자신들의 길을 가면서 충돌하기도 하고 협력하기도 할 뿐…

다만, 스타벅은 자신이 상관에게 했던 행동을 그대로 돌려받는다.

술 주정뱅이 부함장이라며 무시하고 따르지 않았던 스타벅은,

자신이 리더가 된 후 갈등하는 상황에서 부하에게서 주정뱅이니 무능력자니 하는 말을 들으며 무시 받는다 (scar, ep 15).

적(scar)을 잡기 위해 부하에게 기회를 제공하는 장면에서는,

제아무리 뛰어난 능력의 상관이라도 목표를 이루기 위해서는 부하 직원을 밀어줘야 하는 것이 상관이 아닐까 라는 생각이 들었다.

이외에도 부드러운 리더쉽의 윌리엄 아다마 함장, 꼰대 스타일의 사울 타이 부함장, 독선적인 헬레나 케인 제독, 자신 만을 위해 사는 가이우스 발타 등

다양한 캐릭터가 모두 때로는 실수하고, 때로는 싸우고, 때로는 도우면서 드라마가 진행되어 간다.

다양한 캐릭터가 모두 때로는 실수하고, 때로는 싸우고, 때로는 도우면서 직장 생활이 진행되어 간다.

팀장과의 관계가 힘들어 부서 변경을 한 직원 때문인지,

갈등 속에 자신의 발전을 위해 이직하는 직원 때문인지,

이렇게 우주를 배경으로 하는 SF 드라마가 직장 생활을 표현 한 것 같다 (특히 시즌 2).

몇 개월 전에 가족들과 같이 어떤 모임에 참석하고 다같이 저녁을 먹으러 갔다.

저녁을 먹는 중에 유명한 국회의원이 식당에 들어왔다.

앉아서 식사를 하던 사람들이 일어나 한 명씩 그 국회의원과 악수를 했고,

우리 딸도 일어나 90도로 인사를 했다.

사람에 가린 것인지, 악수를 하다가 못 본 것인지 그냥 지나쳤고 딸은 시큰둥하게 내 무릎 위에 앉았다.

사람들이 길게 늘어서 앉아 있는 상황에 한쪽 끝에서 국회의원이 이야기를 했고,

우리는 반대쪽 끝에 앉아 있었다.

모든 사람들이 국회의원의 말을 경청 하는데,

맑고 청아한 목소리가 날카롭게 퍼졌다.

“아이, 시끄러워”

딸이 자기 인사를 안 받아줘서 삐진 것을 표시한 것이었다.

딸의 인사를 안 받아준 것을 아는 이쪽 사람들은 웃었고,

상황을 모르는 국회의원 근처의 사람들은 순간 멈칫하다가 이야기를 이어갔다.

자기를 무시했다고 생각하니 나름의 복수(?)내지는 의견을 표시한 것 같았다.

4살짜리도 무시 받았다는 생각에 감정이 상한 것 같았다.

그런데, 자기 생각이 강한 어른이면 어떨까?

무시 받고 참는 사람은 어떤 생각을 하는지 궁금해졌다.

무시 받고 복수하는 악인들 이야기들도 생각났다.

내가 무시 받은 적을 떠올려도 봤고, 내가 남을 무시했던 기억도 찾아봤다.

SW 개발을 하면서

하나 더 안다고 남을 무시하고

모른다고 무시당하는게 흔하다는 생각으로 이어졌다.

이전에 많이도 남을 무시한 것 같다.

다행이 나이가 들면서 최근 몇 년 동안에는 그런 기억이 없는 것 같다 (기억 못할 수도…).

실수한 신입을 크게 나무라는 과장을 보며

10년 이상 경력의 두 개발자가 있었다.

한 명은 세심하고 이것 저것 따져가며 일하고,

또 한 명은 바보스러우리 만치 둔하고 자기 중심적인 개발자였다.

세심한 친구는 문서를 잘 챙기고 관리에 능하지만 개발 실력은 조금 부족했다.

다소 둔한 친구는 관리보다는 개발에 능했다.

세심한 친구는 멀리서 다른 사람들이 주고 받는 대화도 들을 만큼 주변 환경에 민감했고,

둔한 친구는 자신 외에는 관심이 없었다.

자료: http://cdn0.lostateminor.com

세심한 친구는 남에게 질문하거나 도움 받는 것을 피해를 준다고 생각하는지,

매우 조심하고 정중하게 이야기 하는 대신, 자신이 도와 줄 때는 다소 심하게 말하기도 했다.

둔한 친구는 자신이 조금해보고 할 수 없다고 여겨지면 남의(주로 나) 일도 못할 만큼 도움을 요청하고 괴롭혔다.

도와 줄 때는 뿌듯해 하는 것이 느껴졌다.

세심한 친구는 PM을 하면 직원들을 잘 챙겼지만 작성한 코드에 전혀 신경 쓰지 않았다.

둔한 친구는 프로젝트 중에 자신은 휴가를 가면서, 문제가 터지자 휴가간 개발자를 복귀 시키기도 했다.

세심한 친구는 논리적으로 설명하며 직장 상사에게도 대들다가, 결정 나면 자신의 마음과 달라도 조용이 투덜거리면서 조용히 있었다.

둔한 친구는 자신이 이해하지 못하면 계속 질문하고 대들었다.

심지어 어떤 일로 사장이 자신을 무시한다는 생각이 들자 항의 메일을 보내기도 했다.

나와 코드 구현 방식에 대하여  이야기 하다 격해진 적도 많았다.

둔한 친구는 별로 어울리는 직원이 없었고, 조용이 있다보니 회의시간만 되면 졸았다.

세심한 친구는 둔한 친구를 미워했고, 공개적인 자리에서 망신을 주기도 했다.

자료: http://cdn0.lostateminor.com

두 사람에 대한 직원들의 평가는 극명했고,

어느 날 사장님과 잡담 중에 두 사람에 대한 논쟁이 생겼다.

사장님이 둔한 친구에 대하여 안 좋은 감정을 그대로 표현했고, 나는 반대의견을 제시하였다.

나에게 세심한 친구나 둔한 친구나 둘 다 똑 같은 나쁜 직원이라는 말에 놀라워했다.

세심한 친구는 자신이 이로운 위치에 있다고 생각할 경우 행동이 매우 거칠고 안하무인이고,

일을 시키려고 해도 자신의 모든 상황을 따지고 거부하기도 하며,

때로는 일을 받는 게 아닌 도와 준다는 개념으로 행동하려 드는 단점이 있었다.

둔한 친구는 투덜대기는 해도 시키는 일을 모두 조용이 처리했다.

쉽게 일을 받다 보니 한동안 대부분의 외부 프로젝트는 둔한 친구가,

내부 관리는 세심한 친구가 처리 하는 식으로 다소 불공평하게 운영되었다.

사장님이 둔한 친구는 혼자 따로 논다고 지적했다.

세심한 친구는 부하 직원들을 잘 가르치기도 하지만 윽박지르고 잔소리도 심하다고 이야기 했다.

둔한 친구처럼 친화력이 떨어지는 건 어쩔 수 없는 개인적인 부분이라고 이야기 했다.

PM을 하면서 혼자만 휴가간 것은 자신이 팀장이 아닌데 같이한 직원에게 맘대로 휴가 가라고 말하기 어려웠고,

생색용 말은 하기 싫어서였던 것이라고 했다.

휴가자를 복귀시킨 것은 사고친 당사자이고, 자신이 모르는 부분이라 어쩔 수 없었다고 했다.

일 시키기 힘들고 각자의 방식으로 나를 대하며, 나를 힘들게 하는 두 직원 모두

나에게는 나쁜 직원이었다.

그렇게 시간이 흘러 회사 사정이 안 좋아 지면서, 둔한 친구는 구조조정 대상으로 회사를 떠났다.

말렸지만 되돌릴 수 없었고, 떠나는 둔한 친구를 배웅하는 사람은 많지 않았다.

자료: https://pixabay.com

다시 1년이 흘렀고

둔한 친구는 제법 괜찮은 회사를 잘 골라서 좋은 조건으로 직장 생활을 시작했다.

여기서 미움받는 것보다 새로 시작하는 것이 좋다는 생각과

그 친구 경력으로 좋은 회사에 갈 수 있다는 확신(취업 사이트를 검색해 봤다.)이 있어서 찬성했지만

남아 있는 사람이 힘들 거라는 걱정 때문에 반대도 했었다.

둘이 나눠서 하던 PM을 세심한 친구 혼자서 하고, 늘어나는 외부 프로젝트에 짜증내는 빈도가 늘기 시작했다.

세심한 친구는 자신이 여유롭게 할 수 있는 만큼만 하는 직원이라 나에게 일이 오기 시작했다.

실제로는 일을 못해서 물어봤다는 것을 조금은 알게 된 것 같았다.

그리고, 여러 가지 이유가 있었지만 오랜만에 프로젝트 개발 일정에 지연이 생겼다.

둔한 친구가 나간 뒤, 프로그램 구현 방법과 관련한 논쟁을 해 보지 못했다.

자신이 이해하지 못하면 이해할 때까지 질문하던 사람이 사라지니 논쟁을 벌일 이유가 없어졌다.

업무 중에 논쟁하던 우리 모습을 보며 사이가 안 좋다고 생각할 만큼 짜증나게 이야기 했었다.

회사 생활을 하다 보면 경쟁하기도 하고 미워하기도 한다.

하지만 두 마리의 소 이야기처럼 누가 더 일을 잘한다고 평가할 필요도, 미워할 필요도 없다고 생각한다.

다양한 사람이 다양한 능력을 잘 어울려서 자신들의 목적을 달성하기 위한 조직이 회사라고 생각한다.

나와 다른 것은 나쁜 것이 아니고 그냥 다른 것이고,

두 사람은 성격이 다른 것 뿐이었다고 생각한다.

(두 마리 소의 이야기는 단점 지적에 대한 우화로 이야기가 단순하다.

좀 더 깊게 따지고 보면 좀 더 잘한 소가 많이 먹을 수도 있고,

조금 부족한 소가 젊은 때는 잘했지만 나이가 들었을 수 있다.)

자료: http://m.inven.co.kr/

어릴적 많은 사람을 배척했던 경험이 지금은 마음 한켠에 무겁게 남아 있다.

내 눈에 가시 같다고 가시 뽑듯이 미운 사람을 치우면 속이 시원할 것 같았지만,

그 사람의 빈자리는 어떤 형태로든 누군가가 감당할 몫이 되었다.

배척 당했다고 무조건 무능하거나 잘못 된 것도 아니였다.

언젠가 이 말을 세심한 친구에게 해주고 싶지만 그 친구는 동의하지 않을 것이다.

(며칠전 낮에 둔한 친구가 잘 지낸다는 말을 세심한 친구가 들을 수 있도록 다른 사람에게 말했다.)

둔한 친구와 추석 안부 인사를 하고나서 ...

개발자가 되기 위해 공부하던 한 대학생이

웹 개발의 기초라는 게시판을 제작하는 것은 하겠는데

간단한 웹 사이트 하나를 못 만들겠다고 말했다.

출처: pxhere.com

그래서

개발은 잘하는데(?), 일은 못하는 상태 같다고 말했다.

반대로, 현재 일하고 있는 회사 직원들은

개발 능력은 뛰어나지 않지만

내외부 프로젝트를 별문제 없이 완료하니

개발은 잘 못하는데 일은 참 잘하는 개발자라고 말했다.

SQL도 제대로 못 만드는 직원이

제법 복잡한 웹 사이트를 혼자서 만들기도 했다.

(기존 소스를 참고해서)

출처: blog.aladin.co.kr

이 둘의 차이는

하나의 프로젝트를 해본 사람과 안 해본 사람의 차이 같다.

잘 하든 못 하든,

하나의 프로젝트를 혼자서 해본 사람은

개발하는 과정이 (일하는 방법이) 머릿속에 그려지고

어떻게든 풀어나가지만

처음 하는 사람은 배가 산으로 가는 경험을 하게 될 수도 있다.

비슷한 예(?)로,

토익 점수는 높은데, 영어로 대화하지 못하는 것과 비슷한 것 같다.

외국인과 대화를 하지 못하는 이유 중 하나는 대화를 많이 안했기 때문일 것이다.

외국인과 자주하다 보면 자연스럽게 회화가 될 것이다.

SW 개발도 이와 같다고 생각한다.

출처: pixabay.com

기초가 매우 중요하지만

꿩 잡는 게 매라고

어떻게든 개발해내고,

그 개발에서 나오는 자신에 대한 믿음이 중요하다고 생각한다.

출처: pxhere.com

한 개발자가 한탄하는 말투로 이야기 했다.

며칠 전 고객이 웹 페이지에 출력되는 오류 메시지 중 톰캣 버전이 출력되는 것을 없애달라고 했단다.

인터넷 검색으로 어렵게 찾아서 수정해 줬더니

수정한 걸 본 고객이

그게 아니라면서 오류가 나면 오류 안내 페이지(404 not found)가 나오게 해달라고 했다는 것이다.

똑바로 이야기 했으면 한 번에 할 일을 괜히 시간 낭비했다고 말했다.

출처: https://commons.wikimedia.org

이야기가 끝나자 마자 그 개발자가 잘 못한 것이라고 말했다.

고객은 SW 개발을 잘 모르고 말을 하기 때문에,

고객의 의도를 파악해서 일하는 게 개발자의 능력이라고 말했다.

더욱이 웹 보안 상 오류 메시지를 웹 페이지에 그냥 출력 하면 안 된다.

이런 일은 흔하게 발생한다.

개발자는 대부분 항상 을이기 때문에,

고객이든 직장 상사든, 동료와 협력하든 누군가의 지시나 요청에 의해 일을 하게 되고

상대의 의도를 제대로 파악하지 못하면 본인이 손해를 보게 된다.

또, 이렇게 일이 엇나가면 서로에 대해서 불평하고 비난하다가 불신만 쌓여서

SW 개발이 어려워지는 것이 아닌가 한다.

다른 예로, 나에게 머리카락을 자르는 일은 참 어려운 일이다.

외모에 별로 관심이 없어서 아는 지식이 없다.

어릴 때는 그냥 짧게 깎았고,

나이가 들어서는 인상이 부드러워 보이고 탈모도 감춰야 해서

머리카락을 길게 하려는데

어떻게 깎아달라고 말해야 하는지 아직도 모른다.

머리카락을 기르기 시작하고는 한 달에 한번씩 고통(?)이었다.

출처: http://riflessiacconciature.com/servizi-capelli/

B 클럽 미용사는 조금만 말을 잘 못해도 무조건 짧게 깎았다.

심지어 제대로 깎은 후에 어떻게 말하면 된다는 말을 듣고 기억해서 다음 번에 이야기 했지만 소용없었다.

그러다 아내와 그 친구들이 좋다고 강조한 동네 미용실을 갔는데

최근 몇 년간은 편하게 미용실을 다니고 있다.

처음 몇 달은 이런 저런 요구 사항을 떠듬거리면서 말했고

미용사는 깎은 후, 맘에 드는지를 확인했다.

그 후로는 알아서 깎아주기 때문에 퇴근길에 잠깐 들리면 된다.

좋은 미용사(동네 미용사)와 안 좋은 미용사(B 클럽 미용사)의 차이는

나의 의도를 이해해서 머리카락을 깎아주고

나를 기억해 주는 것이라고 생각한다.

SW 개발도 이와 같다고 생각한다.

진정한 개발 능력은 개발 년차나 알고리즘 작성 능력이 아니라

상대가 원하는 것을 제대로 구현해 주는 것이지 않나 싶다.