생각의 시작
대학교 1학년 전공 개론 시간 첫 수업 때, 교수님이 한 질문이 있습니다.
공학(Engineering)이 뭐냐?
다들 기술적인 관점에서 답을 할 때, 그 교수님은
공학은 돈을 벌기 위한 과학기술
이라고 말을 했습니다.
당시에는 굉장히 세속적이라고 생각하고 속으로는 동의하지 못했던 기억이 납니다.
지금 생각해보면
순수과학과 응용과학의 차이를 이해하지도 못한 채 공대로 진학한,
제 자신의 무지에서 온 생각이 아니었나 싶습니다.
이 글에서는 그런 공학을 수행하는 Engineer에 대해서 적어보고자 합니다.
첫 직장에서 저는 대형 선박에 출장을 자주 갔었습니다.
그 때마다 선박입구의 보안담당자는 저에게 왜 왔냐고 물어봅니다.
주저리 주저리 설명하면 십중팔구는 못 알아 들었고,
승선을 위해서 따로 상관과 연락을 하는 등 많은 어려움이 있었습니다.
그러다가 마법과도 같은 단어를 알게 되었습니다.
바로
I'm a technician
이였습니다.
그 말 한마디면 그냥 들여 보내 주었습니다.
왜냐면 배의 장비들을 수리하러 온 사람으로 알 기 때문입니다.
조금 더 경험이 쌓이면서
그들이 말하는 Technician의 뜻도 조금씩 알게 되었습니다.
선박에서 말하는 Technician은
단순히 주어진 매뉴얼대로 장비를 교체하고, 설정해주는 사람을 뜻했습니다.
그걸 안 이후로는 자존심 상 Technician이라는 말을 쓰지 않았습니다.
뭘 쓸까 하다,
제 명함에 적힌 영문직함 Senior Engineer의 Engineer를 쓰기 시작했습니다.
I'm an engineer
도 큰 문제없이 통과가 가능했고,
저는 첫 직장을 그만두기 전까지
스스로를 Engineer라고 부르며 출장을 다녔습니다.
그 경험 이후로 저는 Engineer에 대해 많은 생각을 하기 시작했고
나름대로 정의한 Engineer에 대해서 한번 적어 보려 합니다.
정의
두 번째 직장에서 저의 영문 직함은 Principle SW Engineer였고,
현 직장에서도 동일합니다.
앞의 Priciple이니 SW니 이런걸 다 빼고 보면,
산업 도메인을 완전히 바꿨음에도
저는 여전히 Engineer입니다. Engineer는 무엇을 하는 사람일까요?
그 대답은 두 번째 직장에서 익숙해진 단어 Solution에 있었습니다.
회사의 대표는 항상 우리 회사는 Product가 아닌
Solution을 제공하는 회사라고 강조했습니다.
고객에게 단위 Product를 제공해주는 것을 넘어서,
고객의 문제를 해결하기위한 종합 선물세트와 같은
Solution을 제공할 수 있어야 된다고 말을 했습니다.
비니지스적인 관점에서 Solution에는 서비스가 포함되기 때문에
단순히 Product를 판매하는 것 보다
더 많은 수익을 낼 수 있기 때문에 한 발언일 겁니다.
비지니스는 재쳐두고 여기서 중요하게 볼 부분은 바로
고객의 문제를 해결하는 Solution입니다.
Engineer는 바로 Solution을 제공하는 사람입니다.
그 관점에서 Engineer를 아래와 같이 정의합니다.
Engineer는 고객이 가진 문제를 기술적으로 해결하고, 대가를 받는 직업
고객의 문제를 의학적으로 해결하고 대가를 받는 사람이라면,
그 사람은 의사일 것입니다.
고객이 존재하지 않는 자연의 문제를 해결하는 사람이라면,
그 사람은 과학자일 것입니다.
Engineer는 반드시 문제를 가진 고객이 있어야 합니다.
그리고 Engineer는 그 문제를 해결할 방법을 찾을 수 있어야 합니다.
마지막으로 Engineer는 문제를 해결할 기술을 가지고 있어야 합니다.
고객, 문제해결, 기술 이 3가지에 대가를 포함하여 이 4가지를
저는 Engineer를 정의하는 4가지 요소라고 생각합니다.
이 4가지 요소에 대해서
제가 중요하다고 생각되는 Engineer의 자질을
한번 언급해보고 마무리할까 합니다.
고객
고객은 문제를 가지고 있고, 그 문제를 해결해 줄 수 있는 사람에게
대가를 제공할 수 있는 사람입니다.
Engineer는 항상 이 고객을 상대할 수 있어야 합니다.
고객은 사람이기에, 즉 Engineer는 사람을 상대할 수 있어야 합니다.
소통 능력이 필요하다는 말입니다.
비단 소통능력 뿐만 아니라 전달력, 설득력, 협상력
수많은 소프트 스킬이 필요합니다.
사무실에서 일하는 SW Engineer가 간과하는 부분 중에 하나일 것입니다.
평생 개발만 하면 될거 같지만,
아쉽게도 세상은 우리에게 사람과 부딪히게 만들고
이런 능력을 요구합니다.
문제 해결
Engineer는 고객의 문제를 해결해야 합니다.
문제해결을 위해서는
문제 정의 - 분석 - 방안수립 - 실행 - 피드백 등의
단계를 따르게 됩니다.
많이 들어는 봤겠지만, 사실 이런 프로세스를 따른다기 보다는
대부분 경험에 의거하여 방안을 수립하고 시행할 겁니다.
그 자체도 나쁘지는 않지만,
경험에 의거한 Solution은 사람과 함께 사라진다는
치명적인 문제가 있습니다.
문제 해결 기술이 전수되기 위해서는
반드시 위 프로세스에 의거한 문서가 필요합니다.
10년동안의 경험으로 100을 가진 Engineer가 그만두면,
새 Engineer는 다시 10년 동안 노력해야 동일한 수준으로 갑니다.
하지만, 100을 정리한 문서가 있다면, 2~3년 내 도달이 가능하고
새롭게 150, 200을 만들수 있습니다.
저는 이것을 인류의 진화라고 봅니다.
다소 거창하지만, 결론은 Engineer는 문서화를 잘해야 합니다.
기술
건설을 보면, 설계업체, 시공업체가 나누어진 것을 볼 수 있습니다.
설계업체는 문제를 해결하는 Solution을 제시한 Engineer라고 본다면,
시공업체는 실제 Solution을 수행해는 Engineer일 겁니다.
Solution 수행에 있어 중요한 부분은 바로 기술입니다.
기술은 손으로 갈고 닦아진 능력입니다.
개발자도 열심히 손으로 코딩하죠.
건설은 2개가 분리되어 있다지만,
SW업에서는 대부분 시공에서 출발하여 설계를 하는 방향으로 가게 됩니다.
얼마만큼 기술을 많이 습득했냐가
좋은 설계를 낳는다는 부분은
따로 설명하지 않아도 다들 알겁니다.
대가
마지막으로 대가입니다.
연봉/인센티브 당연히 잘 받아야 됩니다.
세속적이다할 수 있으나
Engineer는 끊임없이 자신의 가치를 시험하고
인정해줄 수 있는 곳을 찾아다녀야 합니다.
위에 설명한 모든 능력들이 좋아야 대가를 많이 받겠지만,
반대로 대가를 많이 받는 Engineer를 능력이 좋다고 고객이 생각합니다.
마무리
Engineer는 수많은 사람의 명함에 적힌 직무입니다.
아마 대부분은 이 단어의 의미에 대해 그렇게 생각해보지 않을 것입니다.
제 경우는 나이가 들수록,
제가 하는 일에 의미를 부여하고 싶고
제가 하는 일을 누군가에게 설명하고 싶어지기에
이런 저런 생각을 하는 시간이 자연스레 많아져
이런 글까지 적어보게 되었습니다.
누군가에게 본인의 업에 대해서 이런 시각도 있구나 하고,
봐준다면 그것 만으로도 큰 의미가 있지 않을까 싶습니다.
감사합니다.
