개발자가 익혀야 할 업무스킬

훌륭한 프로그래머의 기본은,
단연코 “기술에 대한 폭넓은 이해와 풍부한 개발경험”입니다.

하지만 회사에 들어가면, “업무 스킬(Business Job Skill)”도 중요해지게 됩니다.
디자이너와의 회의, 상사보고 등등이죠.

1. Why, What = 업무스킬

일반적으로 많은 개발자들이
How(어떻게 해야 구현이 될 것인가?)에 대해서 정통합니다.

하지만, What(최종적으로 무엇을 만들고 있나?)이나
Why(왜 이것을 만들고 있나?)에 대해서는 무관심하죠.

What, Why 는 전략과 사업의 영역이기 때문입니다.
개발자들은 “내가 알아야 할 기술이 아니다.”라고 생각합니다.

하지만, 혼자 골방에 틀어앉아 개발할 게 아니라면,
어느 시점에 누구와 무슨 이야기를 할지,
어디서 이야기 해야 할지 이런 “업무 스킬”이 매우 중요합니다.

특히 기술의 깊이가 중요한 사업일수록,
개발자의 역할도 중요해지는데,
개발자가 아니면 이해하기 힘든 문제들이 여기저기 발생됩니다.

2. 업무스킬 = 성과 스킬

하지만, 이런 상황에서 사업팀과 원활하게 이야기하는
개발자를 본 적은 거의 없습니다.

문제가 조기에 발견되지 못하고 늦게 포착되고,
문제가 수습되지 않아 피해를 크게 보게 되죠.

힘들게 얻었던 교훈이 있습니다.
“기획자와 개발자 간의 세계는 산과 바다처럼 완전히 서로 다른 세계다.”

알고리즘에 충실한 개발자들은,
성격상 훌륭한 업무 스킬을 갖기 어렵습니다.
그래서 삽질을 많이 하죠.

개발자도 회사라는 조직에서 생존하려면,
이 “업무스킬”을 익히는 게 필수입니다.

정리해봅니다.

3. 혼자서 일하지 마라.

개발자가 Why와 What에 무관심하다면 어떤 일이 벌어질까요?

모여서 일할수록 일이 더 안되거나 틀린 결과물이 나옵니다.

“체계가 좀 있다면…” 이라고 많은 사람들이 바라지만,
시스템이란게 쉽게 만들어지지 않죠.

만들어질 때까진 협업이 안됩니다.
그래서 시스템이 만들어지지 않죠.
악순환이 계속 됩니다.

전체가 부분의 합보다 커지려면,
“소통”을 통해 부족한 부분을 메꿀 수 있어야 합니다.

이런 협업 문화가 성공해야만,
사람을 뽑은 것이 회사의 능력으로 갑니다.

협업문화가 형성이 되지 않으면,
회사의 업무능력은 영원히 1명어치입니다.

4. 소통의 기본

“업무스킬”의 기본은 “소통”에서 시작합니다.
사내에서 사용하는 가장 일반화된 “소통”은, “말하기”와 “메일쓰기” 입니다.

하지만, 더 중요한 게 있습니다.
바로 “누구(who)와” 입니다.

수직적 조직구조가 익숙한 우리나라 개발자들은, 자기 팀장하고만 소통하려 합니다.
그 밖의 “소통”은 예외 케이스라고 생각합니다.

하지만 일을 제대로 하려면
자기일에 대한 Why를 이해하고, 문제를 식별하여,
매니저의 매니저, 동료와도 소통해야 합니다.

이건 매우 중요합니다.
소통은 “전달이 짧을수록”, “넓어질수록”, “빈번할수록”.
그 힘이 커집니다.

개발 용어로 말하자면 이렇습니다.

스스로를 Component 화 하세요.
Interface를 열어 Communication 하세요.
그래서, Throughput 을 높이세요.

더 많은 Business Logic을 수용하기 위해서,
Interface 를 다양하게 만드세요.

JSON,XML로도 통신하고 Socket으로도 통신하세요.
Business Call 에 종속적인 상위 Class 별로 Overriding Function 을 만들고,
Return Type 을 달리하십시요.

5. 문제를 해결하기 위해서는

“암묵지”를 “형식지”화하고,
이를 “지혜”로 바꾸어야 합니다.

용어가 좀 어렵죠?

개발자가 오랜 경험을 통해 쌓은 지식처럼,
주관적이고 경험화되기 힘든 지식을 “암묵지(지식)”라고 합니다.

반면, 형식화되고 외부에서 관찰이 가능한 지식을 “형식지”라고 합니다.

아래는 형식지의 종류를 나눈 것입니다.

“암묵지”를 “형식지”화 시키면,
“소통”이 가능한 문서나 무엇이 만들어집니다.

명확한 의견이 없으면, “소통”할 수 없습니다.
“소통”하기 전에 “의견”을 만들어야 합니다.

피드백이 원하는 형식이 아니라면 “소통”에 실패합니다.

일반적으로 개발자가 보유한 지식은 “사물지”이거나 “사실지”입니다.
하지만, “업무스킬”의 출발은 “방법지”이어야 합니다.

협업이란 문제를 해결하는 과정이기 때문에,
“사실지”를 늘어놓아봐야 의미가 없습니다.

어떻게 할지 “방법”을 이야기해야 업무가 됩니다.
문제를 해결하려면 “방법”이라는 구체적인 행위가 더해져야 합니다.

물론 일을 하다보면 “소통”에도 에러가 존재합니다.
이 에러와 “방법지”를 가미해서 “지혜”를 만듭니다.

“지혜”는 상황에 따라 달라지는 해법입니다.
“지식”에 머무르지 않고
“지혜”화하는 것이 “업무스킬”의 궁극이 아닐까 합니다.

6. 비즈니스맨의 “업무스킬”

아래는 일반적인 비즈니스맨을 위한 “업무스킬” 가이드입니다.
IT 도 100년, 200년의 역사가 쌓이면 아래와 같이 도표가 생기지 않을까요?

즉, 업무기술도 나름 체계화된 지식입니다.
설명에도 기술이 필요하고,
제안에도 기술이 필요합니다.

회사나 조직 속에서 일을 한다면, 전문 기술을 배우는 것 외에
일반 회사생활을 위한 “업무스킬”을 익히는 것이 필수입니다.

하지만, 짧은 IT역사로 인해 이런 건 참고할만한 교재가 없습니다.
틀려도 다른 산업군에게서 “업무기술”을 벤치마킹할 필요가 있습니다.

아래 글은 마케팅이란 용어를 써서 “업무스킬”의 중요성을 이야기한 글입니다.
6년이나 지났지만, 지금 읽어보아도 전혀 어색하지 않은 글입니다.

물론 현재상황과 상이한 부분도 있습니다.
하지만 일하는 방법은 여전히 그대로입니다.

그건 업무는 사람이 하는 것이기 때문입니다.
사람은 변하지 않죠.

완전 추천하는 글입니다.
꼭 읽어보세요.

– “프로그래머, 10년 후를 위한 필수지식 마케팅”(2004.4.6 Zdnet Korea)

끝.