회사밖생존기 ** 저는 대치동의 한 학원에서 개발 프리랜서로도 일하고 있습니다. 직원수는 60여명 정도 되는것 같은데 여기서 엔지니어는 저 혼자 뿐입니다. 처음에는 외주개발자로 개발 업무만 원격으로 진행하는 것으로 시작을 했습니다. 현재는 비즈니스 오너와 일주일에 한번 30분에서 1시간정도 미팅을 갖고, 이 시간에는 개발 방향 보고나 의사결정이 이루어지고 있습니다. 기술적인 내용은 거의 없고 대부분 비즈니스적인 의사결정과 서비스 기능적인 부분입니다.
** 처음에는 의뢰인이 원하는 방향을 따라가기만 했습니다. 표면적으로는 저는 보수를 받고 개발 산출물을 전달해주기만 하면 되는 것이었으니까요. 그때에는 그들의 문제를 주로 경청했습니다. 의뢰인이 정의한 문제를 잘 이해하는것이 문제를 잘 정의하는 것과 동일하다고 생각했으니까요.
** 일하는 방식을 새롭게 도입할때에는 이 일을 누가 해야하는지 애매한 지점이 생깁니다. 예를 들어 학원 선생님과 엔지니어인 제가 제품을 만든다면 포스터는 누가 만들것인가? 홍보는 누가할 것인가와 같은 문제인거죠. 조금더 도메인 집약적으로 가보면 방대한 문제와 콘텐츠를 어떤 방식으로 분류할 것인가에 대한 내용도 나오기 마련입니다. 이러한 애매한 지점에서 실행속도는 느려지기 마련입니다. 둘 다 방관하는게 가장 진전이 없는 방식이고, 전통 조직 쪽에서 사람을 사용해서 진행하는게 느린 방식이고, 엔지니어링 쪽에서 기술적으로 진행해주는게 가장 빠른 방식일 것입니다.
** 엔지니어에 대한 역할이 많이 바뀌고 있는 것 같습니다. 예전에는 백엔드나 프론트엔드와 같은 기능적인 역할로 엔지니어를 정의 했다면 Problem Solver나 FDE와 같은 목표지향적인 역할로 엔지니어를 정의하게 되는 것 같습니다. 이러한 과정에서 저마다의 방식으로 FDE와 같은 용어를 정의 하는 것 같습니다. (이하 FDE라고 하겠습니다.)
** 입체적인 작품을 보면 내가 서있는 위치에 따라 작품의 모습이 다르게 보이는 것처럼, 엔지니어의 역할이 조금더 입체적으로 변하면서 FDE를 바라보거나 정의하는 내용이 조금씩 다른 것 같습니다. 서로가 보는 뷰는 다르겠지만 FDE가 기존의 엔지니어링 문제를 정의하는 것에서 벗어나 비즈니스 문제를 정의해야 한다는 것에는 이견이 없을 것입니다.
** 이러한 기대감 속에서 FDE는 문제정의능력이 뛰어나야 한다고 말하고, “나는 경험이 많아서” “나는 엔지니어라서” 이 역할에 적합합니다라는 글을 종종 보게 됩니다. 그렇지만 제 생각에는 문제정의는 능력이 아니라 방법입니다. 따라서 특별히 잘하는 사람과 못하는 사람의 차이가 크지 않습니다. 바꾸어 말하면 문제를 정의하는 방법만 올바르다면, 우리는 모두 제대로 문제를 정의할 수 있기 때문입니다. 그리고 그 방법은 직접 그 일을 해보는 것 외에는 없습니다.
** 제가 이 전통적인 조직에 완전히 동화되기는 어렵겠지만, 저는 여기서 문제를 분석하고, 입시콘텐츠를 제작하며, 수능을 공부하고 학원 운영 시스템을 조작해보고 있습니다. 그리고 이러한 경험을 바탕으로 서비스와 필요한 도구들을 만들어 내고 있습니다. 여전히 방향을 잘못잡거나 이해관계나 타임라인을 조율하는게 어렵긴 하지만 오늘 정보통신 서비스 수익을 전통적인 업체에 안겨주었습니다. 이 금액이 10배 100배가 되어서 전통적인 조직이 사업을 다각화하는 성공사례로 자리잡기를 기대합니다.