개발자가 원하는 훌륭한 SE
필자 메모 – 개발자가 원하는 훌륭한 SE
window31 (window31@empal.com / www.window31.com)
월간 마이크로소프트웨어 7월호
회사마다, 그리고 개발하고 있는 솔루션마다, 프로그래밍 종류마다, 개발자는 다 존재하지만 SE 파트가 존재하는 경우는 있는 곳도 있고 그렇지 않은 곳도 있다. SE는 무엇일까? System Engineer 의 약자로 “기술지원” 의미로 사용된다. 본래 SE는 서버를 관리하거나 장비를 다루는 등의 업무를 하는 사람을 일컬었지만, 소프트웨어 업계에서 SE는 매뉴얼을 작성하거나 모듈 테스트, 고객사와 컨택포인트가 되는 등의 일을 전담한다. 물론 이런 일들을 개발자가 직접 하고 있는 곳도 많이 있지만, 보통의 개발자들은 이러한 일들을 좋아하지 않으며(혹은 잘 처리하지 못하며 – 코드 작성 외에는 관심없는 개발자도 상당히 많은 편이다) 회사가 커지고 업무가 분담되면서 각 파트에 대한 업무 분리가 이루어질 수 있도록 SE의 필요성이 많이 부각되는 것이 요즈음의 추세인 것 같다. 이때 SE는 실제로 개발 업무는 하지 않지만 컴파일러나 라이브러리의 개념을 이해하고 있어야 하며 최소한의 코드를 파악할 수 있는 수준까지 요구되는 경우도 있다(실제로 개발자 출신도 있다). 그 외에도 솔루션이 해외로 수출되면서 해외 로컬라이징이 필요할 때가 되면, 중국어 일본어 영어 등 외국어가 가능한 SE들이 또 실력을 발휘하기도 한다. 개발, 테스트, 기획, 커뮤니케이션 등 IT업무의 전반적인 사항을 이해하면서 외국어 스펙까지 가능한 인재들이 SE포지션에 위치하면서 개발자들이 코딩에만 전념할 수 있도록 많은 부분에서 서포트 된다.
여기서 개발자들이 원하는 SE와 차라리 없느니만 못하다고 인식되는 SE가 구분된다. 개발자들이 원하는 SE들은 일단 제품에 대한 이해가 빠르고 포괄적인 지식을 담는 모습을 보여준다. 하지만 그렇지 못한 SE는 항상 개발자가 가르켜 주는 것만 알려 하고, 어쩔 때는 가르쳐 준 것도 잊어먹는 경우가 부지기수다. 훌륭한 SE는 제품을 개선시키려는 기획적인 아이디어 창출에도 기여한다. 하지만 그렇지 못한 SE는 현재 제품을 유지하는 것 외에는 관심이 없다. 그나마 유지조차 제대로 못하기도 한다. 뛰어난 SE는 개발자가 만든 코드와 기능에 대해 여러 사고로 접근하며 같은 질문을 반복하지 않는다. 한번 들은 것은 반드시 문서화 한다. 그렇지 못한 SE는 문서화를 싫어하며 시간만 지나면 가르쳐 준 것을 잊어먹는다. 똑 같은 질문을 여러 번 개발자에게 되풀이하여 묻는다. 똑똑한 SE는 개발자가 만든 기능과 코드를 훌륭한 매뉴얼과 소개서로 재탄생시킨다. 하지만 그렇지 못한 SE는 문서 작성시 개발자가 메신저로 한 얘기나 메일로 적어준 내용을 긁어붙히기만 한다. 똑똑한 SE는 한번 발생한 문제나 잇슈 사항은 같은 사건이 일어났을 때 자신의 선에서 해결하지만 그렇지 못한 SE는 같은 문제가 일어나도 매번 개발자에게 묻는다. 개발자는 소스 리빌드 없이 SE선에 좀더 손쉽고 많은 일을 처리할 수 있도록 툴을 새로이 만들어주는 경우가 많다. 이때 훌륭한 SE는 자기 선에서 직접 툴을 개발하거나 아니면 툴 개발 기획을 의뢰하기도 한다. 하지만 그렇지 못한 SE는 항상 개발자가 다 해주기만을 바라며 만들어준 툴도 제대로 사용할 줄 모른다.
이렇게 몇 가지 사항을 예로 들어가며 뛰어난 SE와 그렇지 못한 SE를 구별해 보았는데, 이런 훌륭한 SE라면 어떤 개발자라도 손을 들어 환영할 것이며, 그 SE와 함께 일한다는 것을 업무의 큰 잇점중 하나라고 생각할 것이다. 필자는 뛰어난 SE도 만나보았고, 함량 미달의 SE와도 일을 해 보았다. 뛰어난 SE와는 항상 그가 서포트 해 주었기에 든든했지만, 함량 미달의 SE와 일을 할 때에는 저 사람이 있어서 시간만 더 뺏기고 스트레스 받고 차라리 혼자 하는게 낫겠다는 생각만 되풀이 되었었다. 동료에게 환영을 받지는 못할망정 존재 자체에까지 부정적 인식을 심어주는 그런 취급을 받는다면 그 사람이나 그 관계는 분명히 문제가 있는 상황일 것이다. 메일을 주고받는 외에는 아무 것도 할 줄 모르고, 항상 개발자가 긁어주는 내용만을 답장으로 보내고 몇 년씩 맨날 보던 라이브러리 링크 에러 하나 날때마다 일일히 개발자에게 묻는다면 그 사람과 일을 하려는 개발자는 아무도 없을 것이다. 회를 먹을 때에 무우 채는 실제로 먹는 음식이 되지는 못하지만, 횟감을 돋보이는 역할을 함으로써 그 공헌을 충분히 하고 있다. 테크니컬 서포터도 마찬가지다. 개발자의 업무를 분리시키고 코딩 외적인 작업을 자신의 영역에서 훨씬 더 훌륭하게 처리한다면 그것은 회보다 훨씬 더 맛나고 우아해 보이는 무우 채가 될 것이다. 따라서 SE라는 포지션 자체가 서포터로서 공격보다는 수비의 역할이라 상대적으로 덜 부각되어 보일 수 있지만 어떤 수비를 하느냐에 따라 그 포지션은 가치의 경중이 크게 바뀔 수 있을 것이다. 누구나에게 인정받고 훌륭한 평가로 가치가 부각되는 SE는 어떤 개발자라도 어떤 회사라도 환영할 수밖에 없다.
