티스토리 뷰

기술만 보는가?

조금 시간이 지났지만, 지금 다니는 회사에서 SI 프로젝트를 마무리 할 때 즈음 면접을 한번씩 봤었다. 지금 내 위치가 어떤 정도인지 평가 받는 것도 있고, 해당 회사에 한번 가보고 싶어서 면접을 본것이었다. 물론 이직할 자신감이 없다면 그러한 면접을 보지도 않았겠지만... SI 프로젝트를 PL로써 진행하면서 이런 저런 많은 경험이 쌓였고 인정까지 받아 자신감이 넘쳐 흐른것도 있었다.


문제는 그렇게 면접을 본곳을 죄다 떨어졌다. 면접은 죄다 못 봤다. 그중 한곳에서 본 면접을 경험으로 글을 이어 써보려고 한다.


프론트엔드 개발자를 뽑는다고 했었고, 내 나름대로 대기업 사이트 중 경영관리 업무의 큰 서비스 하나를 PL로 전체 프로세스 및 DB 설계, 화면 템플릿 (Reactjs), API 설계 등 모든 것을 주도적으로 진행 했고, 심지어 Reactjs를 도입해서 프론트 엔드 개발에 나름 할 수 있다고 생각했었다.


그리고, 면접에 가면 나에게 이런것들을 물어볼 줄 알았다. 프로젝트를 어떤식으로 진행했는지, 문제는 어떤 식으로 해결 했는지 등. 사실 경력 내용을 보면 프론트 엔드 개발 자체에는 결격 사유가 없다고 생각했었다.


첫 질문이 이랬다.


'클로져 패턴이 뭔지 아세요?'


물론 그게 뭔지는 안다. 물론 유려하게 클로져에 대한 정의를 말하지 못한것 같다. 

그때 당시 내가 말했던 것은 '자바스크립트에서 클래스 개념이 없어 이를 유사하게 구현하기 위해 사용되는 것이다.' 였다. 그리고 이후 계속적으로 자바스크립트에 대한 문제를 내는 것이었다. 내심 당황하기도 하고, 자존심이 상하기도 했다. 


대부분 아는 것이지만 정의를 내리라고 하니 잘 안되는 것이 태반이었다. 내가 그것을 잘 사용하고 있다고 해도, 정의를 제대로 하는 건 아니었던 것이었다.


내 면접 태도도 썩 좋지 않았나 보다. IIFE 패턴, 믹스인 패턴, ECMA6 등등 계속 이런것만 물어보니 이제 그런거 물어보지 말고 다른 쪽을 물어보라고, 내가 어떤식으로 프로젝트를 진행했는지 어떤식으로 커뮤니케이션을 했는지. 근데 그분들은 그런쪽에는 관심이 없는 것 같았다. 그래서 내가 마지막에 이런말을 했는데, 개발할 때 패턴 대부분은 구글링해서 힌트를 얻어 다들 하시지 않냐. 라고 했었다.


물론 그러한 패턴들, 정의 내용을 다 공부를 했었는데 누가 그것을 오랜 시간동안 기억을 할 것인가. 어떻게 사용했는지 검색할 때 어떤 키워드로 검색해서 찾아 쓸건지 그것만 기억나지...


이후, 여러 업체들이 채용공고를 한번쯤 유심히 살펴 봤는데, 생각외로 기술적으로 풍부한 경력이 있는 인원들을 뽑으려는 것 같았다. 필수사항에 적혀있는 내용들은 하나같이 많은 경험을 가진 인재를 원하는 것 같고, 정말 그런 사람들이 많이 있나? 그런데 그렇게 사람을 못 구하는 것 같더라. 만날 사람없다고 다들 그러니.


힙 개발자, 컨퍼런스 주도 개발

나는 생각외로 신기술 중독자를 많이 봐왔다. 이러한 사람들중 나쁜 몇몇의 경우는 자신이 아는 것에 대해 특권을 가지는 냥 그 기술에 대해 모르는 사람을 내려다 보는 행위를 하는 것이다. 그러면서 이번에 나온 이 신기술이 아마 대부분의 문제를 해결할 수 있는 마스터키가 될 것이다! 이런 말로 무조건 도입을 원하는 사람들이다. 문제는 신기술을 사용하려면 거기에 따르는 러닝커브가 존재하고, 이슈가 생겼을 때 처리할 수 있는 방안 찾는거 자체가 어려울 것은 뻔한 일이다.


이런 말로 그런 신기술을 쓰지 않고 지금 내가 잘하는 것으로 하겠다고 하니, SI 프로젝트만 하더니 그런거 못하는거 아니냐 라는 소리 들었을 때 정말 어이가 없었다. 스프링 프레임워크를 기업에서 가장 많이 쓰는 이유는 많은 사람들이 사용하니 많은 이슈 해결 히스토리가 쌓였고 경험 가진 사람도 많기 때문이다. 생산성에 도움이 되니 사용하는 것이다. 다른 제품이 월등하게 성능이 좋고 사람도 구하기 쉽다면 누가 그걸 안쓰겠는가? 기업도 이윤창출을 최고로 보는 곳인데... 파이선에 장고? nodejs에 express? 물론 공부도 해봤고, 기회가 된다면 쓰고 싶다. 하지만 그런 사람들 쉽게 못구하는데 어쩌라고... 혼자 다 개발할 수 는 없지 않는가?


혼자 공부하고 준비하여 진행하는 개발자보다 보수적이고 잘 움직이지 않는 개발자가 더 많다. PL 업무를 하면서 처음에 좌절했던것은 바로 여기였다. 


'내가 생각하는 개발자는 이게 아닌데...'


기술 잘아는 사람은 정말 일을 잘할까?

다시 기술로 넘어와서, 기술을 잘 아는 사람은 정말 일을 잘 할까? 글쎄, 내 생각은 아니올시다. 개발은 홀로 하는 것이 아니다. 많은 사람들이 한개 프로젝트를 위해 달리는 것이다. 물론 홀로 혼자서 진행한다면 뭐 알아서 하겠지 할 수도 있지만 그것 또한 아니될 말이다. 서비스든 사내용 개발이든 뭐든 분석부터 유지보수까지 이어지는 것이다. 이 모든것을 혼자 할 수 는 없다. 누군가는 물려 받고 누군가와 나눠서 하는 것이다.


삼국지의 여포처럼 혼자 일당백을 한다고 해도, 그 사람이 없다면? 그 사람이 나간다면? 어떻게 될 것인가. 기업은 이러한 리스크를 알아야 하고 해결 할 수 있는 방안을 자체적으로 가지고 있어야 한다. 그래서 안정성을 찾는것이고 대체를 쉽게 할 수 있는 방안으로 개발을 진행하는 것이다.


그래서 코딩 스타일 가이드가 나온것이고, 소프트웨어 공학에서 이론적으로 설명을 하는 것이다.


결국 IT도 사람이 하는 일 - 대화

여러명이 프로젝트를 수행한다면, 당연히 관리가 필요하다. 왜냐하면, 커뮤니케이션 문제가 발생하기 때문이다. 나는 A를 원해서 파트너에게 A를 만들라고 말했더니 B를 만들어내어 다시 개발하는 이러한 이슈들은 IT 업무를 하는 사람들이 자주 격는 문제일 것이다. 나는 모든 개발의 이슈는 이 대화에서 나온다고 생각하고, 반대로 대화가 활발하고 잘 이뤄지는 프로젝트일 수 록 이슈 발생이 적어진다고 생각한다.


비단 IT가 아닌 어떠한 업무도 대화가 중요한 요소라고 생각한다. 결국 내가 말하고자 하는 요지는 좋은 사람은 대화를 잘하는 사람인 것이다. 이 대화라는 것이 재미있는데, IT 업무에서 대화를 잘하기 위해서는 기본적으로 IT의 기초 지식이 깔려 있어야 한다. 그리고 하는 업무에 대해 이해도가 있어야 한다. 새로운 사업이든 새로운 기술을 사용한다면 그에 대한 공부를 해야 한다. 그리고, 주변 사람들 혹은 리더와 이야기를 자주 나눌 수 있어야 하며, 이슈가 발생하면 혼자 감추지 말고 부끄러운 일이래도 공개할 수 있어야 한다.


내가 생각하는 시니어 개발자 (a.k.a 뽑아야될 사람)

사무직도 IT도 다를것이 없다고 생각한다. 경력이든 신입이든 그 프로젝트를 이해하고 진행하는 것에 시간이 들것이고, 어느정도 적응 기간이 지난 다음 수행하는 건 사람의 역량에 따라 다를 것이라 생각한다. 이 역량은 업무의 적성부터 많은 것들이 요인을 가지고 정해지겠지만, 어떠한 프로젝트든 잘 진행했던 능동적인 사람이라면 곧 따라 잘 할 것이라 생각한다. 그리고 대화를 하는 것을 두려워 하지 않고 정확한 요지를 잡아 이야기 할 수 있는 사람이다.


능동적이라고 해서 활발해야 하는 것이 아닌 중요한 포인트를 잘 집어서 서로 이야기 할 수 있는 사람이면 된다는 것이다. 또한, 문제를 해결 할 수 있어야 한다. 대화를 통해 문제를 해결 할 수 있지만, 이러한 대화를 하기 앞서서 당면하는 문제를 해결할 수 있게 나름 계획을 짜고 이를 공유하고 대화를 해야 한다.


마지막으로, 작은 부분은 주니어 개발자보다 몰라도, 전체 그림을 그릴 수 있는 사람이다. A라는 기능을 만들어! 라고 할 때 누구나 만들 수 는 있겠지만, B 서비스를 만들어! 라고 한다면 분석/설계부터 개발까지 그리는 사람은 주니어 개발자가 아닐 것이다. 많은 경험들이 쌓여 만들 수 있는 그림일 것이다. 물론 자신이 잘하는 것으로 개발도 할 수 있어야 한다. (못하는 부분은 사람을 쓰면 된다. 이러한 사람을 다룰 수 있으면 금상첨하.)


이러한 사람들이 시니어 개발자라고 생각한다. 그리고 이러한 사람들을 뽑아야 한다 생각한다.

(근데 이러한 사람들도 잘 없다...)

댓글
댓글쓰기 폼