(이)공대생이랑 같이 일하는 문과출신을 위한 지침서

링크 : http://curriq.com/course/18

스타트업이든 벤처든 기업에서든 이공대생, 특히 이공대 출신 개발자와 함께 일을 하는 문과생이 알아두면 좋을 법한 지침이나 행동 방향을 대략적으로 정리. 

우리 나라의 교육 과정이 이과와 문과를 일찍부터 나누다보니 여자와 남자의 사고방식과 행동 패턴이 다르듯 이공대 출신과 문과(상경출신 포함)출신의 사고방식과 행동 양식이 다른 경우가 많다. 특히 프로그램 관련 '개발'이라는 것을 전혀 경험하지 못한 혹은 매우 어설프게 경험한 문과생은 상황이 꽤 심각한 지경. 
그래서 생각나는대로 썼다. 오해하진 말자. 서로를 더 잘 이해하자고 쓰는 것이니. 

참고로 난 개발 안 한지 3년은 되었고 지금은 인터넷 서비스를 기획하는 스타트업 하는 사람이다. 개발자 정서를 잘 이해할 뿐 개발자는 아니다.

STEP1경험한다고 다 아는 것은 아니지만, 경험하지 못하면 절대 모르는 것도 있다.

직관이라는 것과 관련한 고어군님의 좋은 글이 있다. http://blog.gorekun.com/1540 하고자 하는 말은 개발을 경험하지 못한, 혹은 어설프게 경험한(이공대 출신 입장에서는 입문도 하지 못한 수준) 문과생은 '개발'이라는 것을 제대로 이해하지 못할 확률이 매우 높다는 것이다. 개발자의 정서나 언어, 사고방식, 행동양식을 오해하거나 이상한 편견을 갖고 있을 가능성도 높다. 거꾸로, 이과를 나온 이공대 출신의 개발자는 문과 출신의 언어나 사고방식, 행동을 비합리적, 비효율적, 비논리적이라고 폄훼하는 경향이 좀 있다. 이것은 본인도 그렇게 느끼고 있다는 고백과 함께 문과출신이 '성급한 일반화'라고 얘기할 정도로 적은 비율은 아니라는 것을 경험을 바탕으로 밝혀둔다. 이하, 개발 경험이 아예 없거나 입문도 안 되는 수준의 문과 출신이 참고하면 좋을 사항들이다. 어디까지나 대체적으로 이럴 가능성이 높다는 얘기다. 참고: 컴퓨터를 잘 다루는 것과 개발 경험이 있는 것은 다른 문제다. 이미 만들어진 망치를 잘 쓰는 사람과 망치를 만드는 사람의 차이라고 생각하면 된다. Thanks: 오타 수정에 도움을 주신 Minhoryang님 감사합니다:-)

STEP2용어의 뜻을 제대로 이해하고 정확히 사용하려고 애써라 - 오해가 줄어든다.

스스로 잘 이해하지 못하는 용어를 써서 지시/회의 하거나, 처음 듣는 전문용어가 나올 때 아는 척하고 넘어가면 오해가 늘어나고 일이 꼬인다. 업계에서 쓰는 전문 용어는 그 뜻을 정확히 이해하려고 노력하고, 스스로 이해했다고 생각한 용어만 써서 대화하는 것이 좋다. 그래야 무시당하지 않고(대놓고 무시하진 않지만 잘 모르고 떠든다고 생각되면 발언 자체에 무게를 두지 않게된다), 오해해서 벌어지는 오버헤드도 줄일 수 있다. 웹개발과 관련된 일을 하는 문과 출신을 위한 참고 사항: http://www.slideshare.net/yongho/ss-11966428 웹개발과 관련해서 개발자가 쓰는 용어를 이해하면 좀 수월하다. 웹이 아닌 다른 분야도 마찬가지다. 이공대에서 배우는 것은 애매한 것이 별로 없다. 상황에 따라 이렇게도 쓰이고 저렇게도 쓰이는 용어는 없다고 보면 된다. 또는 같은 용어를 업계에 있는 사람이 서로 상이하게 정의하거나 새롭게 해석해서 쓰는 경우도 없다. 예를 들어 parallel processing과 concurrent processing 은 완전히 다른 얘기다. 영어 좀 한다고 사전적 의미로 '대충' 이해하면 안 되는 거다. 컴파일러와 인터프리터는 문과 출신이 볼 때는 그게 그거 아니냐고 할 수 있지만 이건 그냥 다른 거다. Replication도 copy보다 멋있어 보여서 쓰는 용어가 아닌거다. Javascript는 Java에 뭔가 더해진 것이 아니다. Shell은 조개 껍데기를 의미하는 것이 아니고, console은 물리적으로 존재하지 않을 수도 있으며, terminal은 정거장이 아니다. 각 분야마다 사전적인 의미와 다른 의미로 쓰이는 '미리 약속된 정의', 즉 터미놀로지(용어)가 있다. 이를 그들만의 '외계어'로 치부하지 말고 공부해라.

STEP3집중할 때 건드리지 마라.

특히, 코딩하고 있거나 뭔가 개발 문서나 매뉴얼, 책을 찾거나 읽고 있을 때 건드리지 마라. 진짜 어지간히 급하거나 중요한 일 아니면 냅둬라. 일단 집중에 성공하면 생산성이 엄청나게 향상된다. 거꾸로 집중하는 것을 방해하면 '다음에 집중할 마음이 생기기 전까지' 계속 딴짓을 할 가능성이 높아진다. 실제 개발자의 경험담도 참고 하고 http://kimeunseok.com/archives/51 왜 오피스에서 일이 안 되는지, 매니저와 미팅이 문제라고 주장하는 TEDx의 강연도 보고. http://www.ted.com/talks/lang/ko/jason_fried_why_work_doesn_t_happen_at_work.html 집중의 문제는 모두의 문제긴 하지만, 특별히 강조하는 이유는 '프로그래밍' 하는 사람들의 생산성은 '몰입'의 수준과 빈도에 매우 큰 영향을 받기 때문에 그렇다. 진짜로 제대로 집중하면 시간가는 것을 모르고 눈이나 허리 아픈 것도 모른다. '쉬엄 쉬엄 하라'는 말도 때와 장소가 있다. 괜히 신경써 준다고 하는 말이 훼방을 놓는 일일 수 있다. 모니터를 노려보며 코딩을 하고 있거나 매뉴얼/튜토리얼로 추정되는 문서를 보고 있을 때는 좀 냅둬라. (집중하는 척하는 거 아니냐고? 관심법이라도 있는거 아니면 그냥 냅둬라)

STEP4그들이 '쉽게 할 수 있다'라고 말하는 것은 실제로 '쉽다'는 뜻이 아니다.

'필요한 조건이 모두 갖춰져 있으면'이라는 말이 생략된 경우가 많다. 이것은 '내가 이와 관련된 논문이나 매뉴얼을 좀 읽어보고, 테스트할 시간을 좀 가져서 감을 잡는다면' 이라거나 '다른 일 없이 당분간 딱 이것만 하게 해 준다면' 이라거나 '여기서 추가되거나 중간에 수정되지 않는다면' 이라거나 '이걸 잘 아는 사람에게 물어볼 수 있다면' 이라거나 '마침 그와 관련된 책을 사놨는데 책 볼 시간을 좀 준다면' 이라거나 상황에 따라 다양한 말이 생략되어 있는 경우가 많다. 그들은 기본적으로 자존심이 있고, 잘 하는 것이 문제지 해서 안 되는 것은 별로 없다고 생각하는 경향이 있어서 '어렵지 않다'라는 말을 입버릇처럼 하곤 한다. 그렇게 말한다고 해서 실제로 난이도가 낮거나 쉽다는 뜻은 아니다. 그리고 그 일을 몇 시간, 혹은 며칠만에 끝낼 수 있다는 말도 아니다. 예전에 비슷한 것을 해 봤거나, 비슷하게 했던 사람을 안다거나, 비슷하게 한 것을 어디서 슬쩍 본 것 만으로도 그렇게 말할 수 있다. 쉽게 할 수 있다고 한다면 어떤 조건에서 얼마나 걸릴지 확인하도록 하자. 추가 팁: 간혹, '쉽다'고 말하고 정말로 '쉽게' 하는 경우가 있다. 그래서 비슷한 일을 '쉽다'고 인식하고 다음 번에도 '쉬운 일'로 간주하는 경우가 있다. 이것이 정말로 '쉬운 일'인지는 그 일을 해낸 사람의 능력과 스키마(배경지식)을 검토한 후에 판단할 일이다.

STEP5이공대생이 '하면 되겠죠'라고 말하는 것은 실제로 하면 된다는 뜻이 아니다.

이들이 말하는 '하면 되겠죠'는 '효율성이나 리소스를 생각하지 않고 어떻게든 되기만 해도 만족한다면' 이라는 말이 생략되어 있다. 주의할 부분은 조금 더 있는데, 이 말을 하는 상황과 어조가 꽤 중요하다. 이 말에는 약간의 빈정거림이나 무시, 혹은 자포자기나 자괴감이 포함되어 있을 확률이 높기 때문이다. 특히 평소에 Step 2의 '용어' 문제가 걸려서 이미 마음속으로 무시하고 있는 사람에게 이런 말을 하는 것이라면 상당한 수준의 경고로 받아들여야 한다. 그걸 어떻게 아냐고? 짧으면 한 두 주, 길면 몇 달간 얼마나 요구/지시 사항이 바뀌었고 결정이 번복되었고 했던 일을 갈아 엎었는지 짚어보면 바보가 아닌 이상 다 알거다.

STEP6생활 패턴이 불규칙한 경우가 많다.

이는 집중력과도 연관되는데, 한 번 빠지면 타임 워프를 하듯 정신 없이 일을 하고, 체력이 받쳐주지 못해서 반나절 이상 죽어있고... 좀비처럼 멍해 있다가 다시 삘받아서 미친듯이 뭔가 하고... 그런 케이스가 많다. (그래서 좋은 개발자는 체력이 좋은 개발자일수도...) 물론 시간 관리가 잘 되는 케이스도 없지 않다. 뽀모도로 ( http://goo.gl/z359p )같은 시간 관리 기법을 쓰거나, 이에 준하는 자신만의 노하우가 있는 경우도 있다. 그리고 많은 개발자가 시간 관리를 잘 하려고 굉장히 애쓴다. 하지만 그런 노력과 별도로 그냥 일 자체가 몰입을 강제해서, 또는 대부분 본인이 어떻게 할 수 없는 마감시간의 심리적 압박 때문에 생활패턴이 불규칙해지는 경우가 더 흔하다. 대부분 집중될 때 일을 몰아서 하는 경향이 있고 집중이 안 되면 하고 싶은 마음이 들 때까지 다른 일을 하는 경우가 많다. 특히 현실 생활에서의 만족도나 하고 있는 일에서 재미가 떨어지면 자연스럽게 게임, 웹툰, 채팅, 각종 게시판 순회 방문, 영화/드라마/애니 감상 등으로 시간을 쓰게 된다. 간혹 인과관계를 거꾸로 해석하는 경우가 있는데, 저런 딴짓을 많이 해서 일을 안 하는 것이 아니라 일이 재미가 없으니까 딴짓을 많이 하는 거다.

STEP7노는 것처럼 보이는 것이 결론적으로는 자기계발인 경우가 자주 있다.

이공대 출신은 대부분 호기심이 왕성해서 뭔가 하나 잡히면 이리저리 가지를 쳐서 스스로 만족할 때까지 탐구하는 성향이 있다. 이것이 일과 조금이라도 관련이 있다면, 이들이 보내는 시간은 일종의 자기계발일 수 있다. 다만, 문외한이 보기에 그것을 판단하는 것이 애매할 수는 있다. 호기심을 해결하는 과정에서 새로운 도구를 익히거나 기술 트렌드를 따라가거나 없던 능력을 얻곤 한다. http://curriq.com/course/21 에서 '흔한 공대생의 생활'에 링크된 글을 몇 개 읽어보자. 위의 글을 읽고 '이게 뭔 쓸데 없는 짓이야' 라고 생각한다면 당신은 이공대 출신 개발자를 전혀 이해하지 못하는 것이나 다름없다. 개발에 몸담았던 사람이라면 '훗, 이 정도는 나도 할 수 있어. 오히려 이렇게 하는 것이 더 좋지' '오홍, 이런 방법도 있군, 이걸 응용하면 이런 짓도 가능하겠어' '헉, 능력자닷. 난 언제 저런 수준이 되지? 부럽다' 이런 호기심과 잉여로움이 개발자에게 꽤 중요하다. 사실 이런 호기심이 없거나 호기심을 해결할 수 있도록 하는 잉여시간/잉여력이 없으면 자기계발을 할 시간이 절대적으로 부족하다. 구글에서 20% 프로젝트 하고 그런 것이 심심해서 하는 거라고 생각하면 곤란하다.

STEP8좋은 개발자 만나면 고마워할 일이지 좋다고 부려먹을 생각만 하면 안 된다.

개발자의 능력은 천차만별이다. 그리고 개발자의 능력은 거짓말이 어렵다. 일당십, 일당백을 하는 능력자가 실제로 존재한다. 머리도 잘 돌아가고, 성격도 좋고, 경험도 많으면서, 절차탁마 하는 고수가 존재한다. 우연히라도 운이 좋아 이런 개발자랑 같이 일하게 되면 고마워하고 서로 만족할만한 결과물을 내려고 해야지 뽑아먹을 생각만 하면 안 된다. 일당십의 능력자를 평범하게 쓰면 기껏해야 2~3인 분의 일을 할 뿐이다. 받들어 모시라는 얘기가 아니라 소모시키지 않도록 해야 한다는 말이다. 잉여시간이 있기 때문에 일당십, 일당백의 능력을 발휘하고 그런 능력을 유지하는 것이다. 잉여시간을 일에 투입한다고 더 많은 일이 처리되진 않는다. 오히려 부족한 자기계발 시간, 마감 스트레스, 잦은 훼방 등으로 효율이 급격하게 떨어질 수 있다. 한 달에 한 사람의 개발자가 할 수 있는 일을 '1 맨먼쓰(M/M)' 이라고 표현한다. 이 말을 만든 사람은 아마 개발이라는 것을 경험하지 못한 사람일 것이다. 덧: M/M(맨먼쓰)는 한 달에 한 사람의 개발자가 할 수 있는 일이 아니라 한 달에 한 사람의 개발자가 투입됨을 나타낸다고 '리소스' 관점에서 지적해 주신 분들이 있었다. 성취한 결과물의 단위를 투입한 자원으로 환산할 때 사용하는 단위라는 것. 하지만 한 사람이 다섯달을 일한 5M/M과 다섯 사람이 한 달을 일한 5M/M이 차이가 없다고 생각하는 '사고방식'을 표현했다는 점에서 여전히 개발자를 이해하지 못한 말이다. '한 달에 한 사람의 개발자가 할 수 있는 일의 양'이라고 표현한 것은 실제로 M/M을 표현하거나 계산할 때 그렇게 생각하는 사람이 많기 때문입니다. 덧2: M/M은 일반적인 용어라 여러 곳에 사용된다. 하고자 한 말은 이 말이 '(소프트웨어) 개발'에는 적합하지 않은 용어라는 것이다. 혹시 오해 없기를!!