Interview review 2017 #12, final

Interview review 2017
1. 원격 지원 및 보안 솔루션 제품 개발 회사
2. Unity를 이용한 인테리어 디자인 앱 개발 회사
3. 의료 분야 외국계 회사
4. AR/VR 교육 컨텐츠 앱 개발 회사
5. 쇼핑몰 회사
6. 반도체 정보 수집 솔루션 + 파견 회사
7. VR 플랫폼 개발 회사
8. 지방에 있는 솔루션+SI 회사
9-1. 웹툰 플랫폼 회사
10-1. 스타트업
11. Data Visualization + 반도체 모니터링 회사
9-2. 다시 웹툰 플랫폼 회사
10-2. 다시 스타트업 회사

---------------------

이제 마지막 회사 그러니까 지금 다니고 있는 회사 버넥트에 대한 얘기이다. 지금 회사는 내가 지원한 것도 아니고 헤드헌터를 통한 것도 아니었고 지인이 알려준 것도 아니었다.

지금 글을 쓰고 있는 시점에서 대략 2년 전 1년간 운영중이던 C# 온라인 프로그래밍 강의를 할 때가 있었다. 온라인으로 코드 작성하고 설명도 하고 하면서 참여한 사람들에게 질문/답변을 받는 그런 모임이었고 거기서 여러 사람들을 많이 만나고 좋은 인연이 된 분들도 몇 있었다.

그 인연이 된 사람 중에 하나가 지금 내 옆자리에서 같이 개발을 하고 있는 사람이다. 어느날 내 온라인 강의에 참여하고 싶다고 해서 몇 번 들었던 사람이었는데 이름만 봐서는 남자인 줄 알았다. C#에 관련된 얘기 말고도 유니티와 최적화에 대한 얘기도 했었고, 나 역시 유니티 프로젝트를 2년 넘게 한게 있어서 이것 저것 알려주고 했었다.

그러던 어느날, 그 어느날은 10번 스타트업 회사에서 연락이 1주일이 넘어 2주일 째가 다 되어가던 어느 날이기도 했다. 자신을 버넥트에서 일하는 개발자고 사람을 구하고 있는데 C#에 대해 잘 아시는 것 같고 유니티 경험이 많아서 입사 제의를 한다는 메일을 받았다. 사실 버넥트라고 하길래 사이트 들어가서 보니까 증강현실, 가상현실쪽 하는 회사였고 유니티를 다룬다고 해서 대충 그런 기술을 사용하는 회사 정도로만 봐왔는데 이렇게 메일을 받고 보니 한번 어떤 회사인지 알아봐야 겠다는 마음이 들었다. 다음날 9번 회사에서 대표님은 마지막으로 잘 생각해 보고 빨리 연락 달라고 했지만 내가 거절을 했고, 그 거절 전화를 한 몇 시간 후에 10번 회사의 대표님한테도 이러저러한 부분 때문에 안맞아서 채용을 못하겠다는 메일을 받았다. 이 때만 해도 많이 아쉽긴 했는데, 2년이 지난 지금 다시 돌이켜 보면 그 스타트업 회사는 안가는게 맞지 않았나 하는 생각도 든다. 왜냐하면 그 회사가 아직도 뭐 하고 있는지 잘 모르기 때문이다.

일단 회사 정리는 이정도로 하고 버넥트에서 제안을 해 와서 면접을 보겠다고 했고 이력서를 다시 잘 정리해서 보내줬으면 좋겠다고 해서, 유니티 프로젝트 한 거에 Leap motion하고 Kinect 써서 제스처로 하려고 한 부분을 더 추가해서 이력서를 보냈다.

며칠 후 면접 날짜가 잡혔는데 회사가 이사를 가기로 해서 이사를 간 후에 면접을 봤으면 좋겠다고 다시 회신이 왔고 알겠다고 했다. 그 이사를 가기로 한 위치는 지금 위치에 앞 건물이었고 아주 오래되고 허름한 빌딩 건물이었다. 화장실 상태도 별로 좋지도 않았고, 특별히 출입문에 벨 같은 것도 없어서 물리적인 노크를 해야 할 정도로 건물 상태가 안좋았는데 사무실 크기에 비해 사람이 적었고 이사온지 얼마 안되서 그랬는지 조금 어수선한 부분도 있었다. 바로 옆 회의실에서 면접을 진행했고, 생각보다 많은 인원이 면접에 들어왔다.

그 때만 해도 회사에 사람은 대표님을 포함해서도 총 9명이었고 면접 때 들어온 사람이 대표님과 나한테 면접 제의를 한 개발자를 포함 총 5명이 들어왔으니 전 직원의 1/2이나 들어온 셈이었다.

우선 마음에 안들었던 점 부터 얘기하면

• 자기소개 해보라고 한 점
• 특별한 코딩 테스트나 깊이 있는 기술 면접이 진행되지 않은 점

이었다.

자기소개 해보라고 할 때만 해도 인상이 썩 좋지는 않았는데 심층 기술 면접 역시 진행되지 않았다.

대신 다른 점에서 좋은 인상을 받았는데

• 다양한 개발자 포지션에 해당하는 서버, 유니티 클라이언트, 안드로이드 네이티브 클라이언트였고 따로 웹 개발자도 있던 점
• 회사에 생각보다 다양한 포지션에 사람들이 있었다는 점이었고, 각 포지션에 관련된 개발 경험을 얼마나 해봤고 하려는 의지를 물어봤다는 점
• 사실 작은 회사다 보니 여러 포지션과 여러 경험을 한 사람을 원한 것 같았고 안드로이드 쪽 빼고 C++이라던지 서버쪽, 클라우드 서비스, 유니티 최적화 작업 및 문제 해결 방법, 하드웨어 dependency가 있는 개발 경험 등 폭넓게 물어봤던 점

이었고 대략 내가 경험해 본 부분을 물어와서 잘 얘기를 했던 것 같다.

그리고 기술 면접이 진행 된 후에 대표님과 바로 연봉에 대한 얘기와 회사에 대한 자세한 설명 그리고 질문/답변의 시간이 충분히 주어져서 회사에 개발자들의 수준과 앞으로 해야할 일들에 대한 것도 잘 이해가 되었다.

결과적으로는 나중에 면접 끝나고 나올 때는 괜찮다는 인상으로 변했는데, AR 관련된 기술적인 연구 개발을 진행할 것이라는 점, 리모트 솔루션과 다양한 SI 과제를 진행할 것이라는 점, 내가 해줬으면 하는 역할과 내가 하고 싶어하는 일이 맞아 떨어진 점 등이었다. 연봉 협상도 함께 진행됐는데 사실 마지막에 받았던 연봉의 수준은 아니었지만, 전 회사에서 경험해 봤던 스타트업 + 기술 기반 개발 + 작고 열정이 있는 팀 + 내가 기여할 수 있는 부분이 명확했다는 점에서 만약 일을 하자고 제안을 하면 이후 면접 스케줄은 취소하고 여기서 일해야겠다는 생각을 했다.

며칠 후 채용하기로 했다는 연락을 받고 버넥트에 입사를 했으며, 이후 일정이 잡혀 있던 면접 스케줄은 취소했고 이후 면접 제의가 들어왔던 연락은 모두 거절했다.

면접도 사실 경험치인 것 같다. 자주 보다 보면 내가 원하는 회사, 바람직한 회사가 눈에 들어오게 되고, 이상한 회사 재미 없을 것 같은 회사가 저절로 필터링이 되어가는 걸 경험적으로 알 수 있게 된다.

물론 면접을 보러 다니는 과정은 피곤하지만, 그래도 내가 즐겁고 재밌게 일할 회사를 찾아 나간다는 믿음을 가지면 면접 진행하는 과정속에서 얼마든지 만족할 만한 회사를 찾아 다닐 수 있다는 게 내 생각이다.

회사에서 하는 일을 잘 하는 게 자신의 개발 실력을 증명해 주지는 않는다. (2)

회사에서 하는 일을 잘 하는게 자신의 개발 실력을 증명해 주지는 않는다 (1)

---------------------------

그러면 실제 개발 실력이라는 것이 어디에서 오는 것인지 생각해 보자. 실력이라는 게 구체적으로 뭘 말하는 것인지 부터 인지해야 한다. 한자 그대로 실제 힘이라는 뜻이다. 좀 더 풀어서 말해보면 실제로 갖추고 있는 힘이나 능력 정도를 얘기하는 것일 것이다. 물리적인 힘은 눈에 보이기도 하고 어느 정도인지에 대한 감이 오는데, 소프트웨어를 개발하는데 나오는 실력이라는 건 눈에 보이지도 않을 뿐더러, 주니어 개발자가 만들던 시니어 개발자가 만들던 만들어 놓은 결과물의 차이가 크게 없어 보인다면 실력을 가늠하기가 쉽지 않은 건 사실이다.

Not 코드를 짤 줄 아는 능력, but 코드를 볼 줄 아는 능력

잘 모르는 사람은 이게 실력이라고 생각할 수 있는데 오히려 코드를 볼 줄 아는 능력이 실력일 가능성이 높다. 왜 그런가 하면 주력 언어가 있고 익숙하면 어느 정도 좋은 개발 도구의 도움을 받아 어느 정도까지는 코딩이 가능한데, 그 이상은 사실 좋은 코드가 있는 구글의 도움을 받아야 하는게 사실이다. 남의 코드를 가져와서 짜는게 실력이 아니라고들 하지만 남의 코드를 가져오기 전에 볼 줄 아는 혜안을 가졌다면 가져와서 붙여넣고 만들어 나가는 건 큰 문제가 아니라고 본다. 즉 코드를 가져오는 능력의 기본은 코드를 볼 줄 아는 능력이 뒷받침 되어야 한다는 뜻이다. 또한 코드를 볼 줄 아는 능력을 갖추고 있다는 건 문제를 해결하는 방법을 알고 있거나 찾고 있다는 뜻이기도 하다.

Not 동작하는 코드에 대한 만족, but 품질을 결정하는 요소를 실천하는 능력

역시 잘 모르는 사람은 동작하는 코드를 짤 줄만 알면 되고, 그 코드가 크게 문제가 없다면 그냥 두는 걸로 만족한다. 하지만 동작하는 코드만 짤 줄 아는 능력은 이 바닥에 들어온 사람이라면 당연히 해야 하는 걸 했을 뿐이다. 즉, 동작하는 코드를 짜지 않고는 일이던 뭐던 진행이 안되기 때문에 당연한걸 해 놓고 당연하다고 하면 어떻게 반응해야 할지 잘 모르겠다. 동작하는 코드를 짰는데, 그걸 잘 다듬고 보듬어 줘서 이후 테스트가 엄격하게 통과가 되는 원칙을 잘 지키는 코드로 만들어 나갔는지 혹은 유지보수와 기능 추가가 유연한 설계를 바탕으로 만들어진 코드였는지에 따라 소프트웨어 품질이 결정된다. 그러니까 이런 품질에 대해 고민하지 않고 만족하는 개발자는 실력이 있다고 보기 어렵다는 얘기다.

Not 회사에서 해야 하는 일에 대한 성과, but 개인이 정말 해보고 싶은 걸 해본 결과

실무 경력은 사실상 실무 경력일 뿐이다. 관련된 업무를 경험해 봤고 해 봤으니 동종 업계에서 하는 비슷한 일을 잘 이해하고 해낼 수 있는 것 정도가 전부인 것이다. 업무 프로세스 이해를 잘 해서 일을 잘 해 나가는 능력은 사실상 개발 실력하고는 크게 상관이 없다. 단, 일을 해 나가면서 조금씩 다른 구현을 시도해 보고 다른 설계를 해서 평소에 알고 있던 방법 외에 이런 저런 실험도 해 보고 하면서 진행했다면 괜찮을 수 있는데, 지금 알고 있는 범위 내에서 해야 하는 일만 했다면 그 이상을 보지 않고 일을 해 왔다는 것이고, 그건 개발 실력이 향상되지 않았다는 뜻이기도 하다. 진짜 실력을 키워 보려면 자기가 따로 해보고 싶은 쪽의 분석, 설계라는 단계를 잘 거치고 문서화를 잘 해 놔서 개발을 진행해 본 경험이 있어야 조금 더 많은 걸 볼 수 있다는 뜻이다.

그러면 정말 실력은 어디서부터 오는 것일까?

보통 회사에서 하는 일은 개발, 그러니까 기능의 구현에 많은 초점이 맞춰저 있는데 문제의 해결력 보다는 구현의 방법에 대한 스킬만 늘어날 뿐이고 누군가 문제를 주면 해결을 하지 못한다. 더 나가서 해결 못할 뿐만 아니라 그걸 자기가 해야 하는 일이 아니라고 생각한다. 그럼 누가 하느냐? 기획자가 해야 할 일이라고 한다. 기획자? 기획자는 개발을 하는 사람이 아니다. 오히려 문제를 만들어내는 사람이지 해결하는 사람이 아니다.

그런 문제를 해결하는 사람은 소프트웨어 개발자가 해야 할 일이며, 문제가 주어지면 잘 이해하고 분석해서 소프트웨어로 어떻게 만들면 좋을 지에 대한 설계는 사실 훈련을 많이 해야 한다. 단순히 코드를 잘 짜는 게 실력이 아니라는 뜻이다. 그런 분석 설계에 대한 훈련을 해서 그 문서를 도출해 내고 그걸 바탕으로 개발을 진행해 보면 다시 분석, 설계가 잘 되어 있는게 중요하다는 걸 뼈저리게 느끼게 된다. 이쯤에서 분석 설계에 들여야 하는 시간이 코딩하는 시간보다 많아야 한다는 걸 깨닫게 된다면 말 그대로 소오름이 돋을 것이다.

그래서 내가 정의하는 개발 실력이란

"주어진 혹은 해결해야 할 문제를 잘 분석하고
그걸 소프트웨어로 잘 만드려면 어떻게 해야 좋을까 하는 고민을 자신의 경험과 역량을 모두 쏟아내서 설계를 잘 해 내고
버그와 문제가 없는 코드를 작성해서
예상한 기간 내에 만족할 만한 수준의 결과를 내고
이후 추가 기능 개발 혹은 버그 수정이 잘 될 수 있도록
퀄리티 있는 소프트웨어 제품을 만들어 내서
이 소프트웨어를 쓰는 사람의 만족도를 높이고
계속 사용할 수 있는 소프트웨어로 만들기 위해 생명을 불어 넣을 수 있는(엔지니어링을 할 수 있는) 능력"
이라고 얘기하고 싶다. 아홉줄에 걸쳐서 썼는데 코딩 얘기는 한 줄 밖에 없다는 점에 주목하자.

분석은 문제 해결 능력에 가깝다. 실제 만들어 내야 하는 소프트웨어 요구에 대한 내용을 잘 이해하고 정리해서 소프트웨어로 만들어 낼 수 있도록 각을 잴 수 있는 능력이 요구된다. 이게 사실 제일 어렵다. 여기에서 실력이 가늠되기도 하는데 세상의 많은 문제를 소프트웨어 시스템으로 만들기 위한 요구를 분석해 내는 경험을 많이 하는 수 밖에 없다. 이건 경험치로 가늠할 문제지, 공부의 양으로 가늠할 수 있는 문제는 아니라고 본다.

설계는 사실상 소프트웨어를 만들기 이전에 잘 만들어 놔야 할 시스템 구성, 모듈간의 통신, 잘 정의되어야 하는 명세, 실제 데이터의 구성, 프로세스에 따라 데이터가 어떻게 흘러가는지에 대한 내용, 사용해야 하는 라이브러리나 프레임워크, 그걸 기반으로 지켜야 하는 기본적인 원칙, 테스트를 해야 하는 방법, use case, GUI 화면 인터페이스 등 소프트웨어를 개발하는데 필요한 모든 요소 대한 걸 몽땅 만들어 놔야 하는데 있다.

이 두 가지를 잘 하면 코드로 소프트웨어를 만들어 나가는 건 본인 역량 껏 해 나가면 된다. 주니어는 조금 더딜 것이고 시니어는 경험자이므로 상대적으로 빠르게 만들어나갈 수 있다. 이게 실력의 차이 아닌가? 라고 생각된다면 여태 내 글을 잘못 읽은 것이다. 주니어는 상대적으로 분석, 설계에 대한 경험이 없기 때문에 분석, 설계에 대한 결과를 잘 못 뽑아낼 가능성이 높고 잘 못 만든 설계서로 날고 기는 코드로 짜 봤자 원하는 소프트웨어의 기능을 만들어 내지 않았거나 못했다면 엄한테 힘쓴 꼴 밖에 되지 않기 때문이다. 여기서 구현에 관련된 부분 예를 들면 리액티브 프로그래밍 기법으로 짰느니 객체지향적인 방법으로 짰느니 하는 얘기를 해 봤자 아무 쓸모도 없다는 얘기다.

<흔히 볼 수 있는 생명주기에 대한 그림, 이런 그림을 이해하는게 실력하고 상관이 없다고 생각하는가? 그러면 진짜 소프트웨어를 이해하고 만들어 본 경험이 없을 가능성이 높다고 본다.출처: Introducing Systems Analysis, Design & Development Concepts>

전공자라면 소프트웨어 공학을 배웠을 것이고 거기에서 필요한 요소가 뭔지는 다들 배웠을 것이다. 이제 코드를 잘 짜는 능력만을 개발 실력이라고 착각하지 말고 전체 소프트웨어 생명 주기를 잘 이해하고 세상 혹은 내가 만들어 낸 문제를 훌륭한 소프트웨어로 만들려면 어떻게 하면 좋을지 고민해 보자.

나는 이걸 잘 해낼 수 있는 개발자가 진짜 실력을 갖춘 개발자라 보고 싶다.

사수가 꼭 필요하다고 생각하는 사람들에게

보통 이 바닥에서 사수라고 하면

• 같이 일하는 사람인데 업무 프로세스를 이해하고 먼저 하고 있던 사람
• 같이 일하는 사람인데 업무에 필요한 기술에 대해 경험해 보고 잘 아는 사람 (실제 아닐 수도 있는 건 함정)
• 같이 일하는 사람인데 그 업무를 같이 진행하거나 다른 업무를 하더라도 기술적으로 뭔가 나에게 알려줄 수 있는 위치에 있는 사람 (대부분 여기에 해당)

이런 사람일 것이다.

<사수-부사수의 정석
출처: 국방홍보원 블로그>

개념은

군대에서 사전적 의미로 총을 쏘는 사람인데 보통은 2인 1조 경계 근무에서 지시하는 사람: 사수, 지시를 받는 사람: 부사수에서 사수를 의미하는 것이다. 그래서 보통 경험이 있는 선임들이 이제 경험을 쌓아야 하는 신병과 함께 조를 이루어서 일에 대해 배우고 경험하고 또 문제 생기면 감싸줄 수 있는 사람이다 보니 일반 사무실에서도 같은 개념으로 쓰고 있다.

그런데 개발에서는 일단 사수가 있는게 좋다라는 의견에 반대하는 편이다. 물론 사수가 있다면 일도 배우고, 자신의 부족한 부분을 보고 배울 수 있는 walk-through 개념으로 받아들이면 일 하기가 한결 수월하다는 점에서는 좋을 수 있다. 그게 개발이 아닌 쪽 그러니까 군대나 기타 다른 일에는 한 조로 움직여서 동일한 업무를 수행하니까 맞는 개념인데, 개발은 같은 개발을 둘이 동일하게 하지는 않는다. 

즉, 보통은 같은 프로젝트 내에서 일을 해도 큰 부분에 일부분을 맡아 개발을 하던가 아예 다른 모듈이나 파트 (예를 들면 프론트, 백엔드)를 맡게 되는 경우가 많으므로 사수한테 배운다라는 것이 잘 되지 않을 경우가 많다는 것이다.

그러면 "어차피 프로젝트는 달라도 같은 팀 내에서라면 같은 기술을 쓸 텐데 그러면 기술이라도 배울 수 있는 거 아니냐?" 라고 생각할 수 있다. 좋은 개발 문화가 정착된 회사라면 코드 리뷰나 포스트 모멘텀 발표, 페어 프로그래밍 등을 통해 공유하고 배우고 할 수 있는데, 거의 보통은 자기 할 일 바쁘다 보니 대충 찾아봐야 할 키워드 정도만 공유하고 알아서 찾아서 해야하는 일이 더 빈번하게 일어난다. 그리고 보통 사수라 불리는 사람들은 바쁜 사람들이기 때문에 신입들에게 세세한 관심이나 케어를 해주기가 힘들다.

결국 사수가 하는 역할은 같이 일 하는 사람인것 뿐인데, 조금 업무를 먼저 해본 사람 + 기술적으로 먼저 실무에 써본 사람인 것 뿐이고 삽질 방지를 위한 키워드 던져주기 + 가이드 역할 정도가 사수 역할의 전부라 할 수 있다. 또 업무 프로세스 익히는 것도 신입의 경우도 대략 3~6개월 정도면 사수가 안알려줘도 자연스럽게 파악이 가능한 부분이기 때문에 사수가 굳이 알려주지 않아도 된다.

오히려 사수가 있을 경우 내가 개발하는 일에 더 방해가 될 가능성도 있는데, 방치형 사수일 경우는 문제가 없으나 오지랖 부리는 사수일 경우는 갈굼 + 쓸데없는 관심 + 삼천포로 빠지는 잡담으로 인해 오히려 일 하는데 방해가 되기도 한다. 갈구는 사수라도 있는게 좋다라는 이상한 생각을 가진 사람도 있는 걸 봤는데, 절대 도움되지 않으며 어차피 그 사수도 사수한테 배운게 아니라 자기가 구글 검색이나 별도 스터디를 통해서 알게 된 걸 알려주는 거 정도 밖에 안되므로, 꼭 사수한테 배울 필요도 없다.

결론은

사수한테 뭔가 배워야 겠다는 생각 보다는, 내가 알아서 배워서 사수나 팀원들과 함께 목표를 달성하기 위한 일에 집중하고 그 일원으로써 노력하는 모습을 보여주는게 훨씬 좋다는게 내 생각이다.

단 한명의 개발자가 있다고 하더라도 스스로 주늑 들어서 사수가 있어야 한다는 생각에 사수를 정하고 본인 스스로 부사수를 자청하지 말고 각각의 동등한 입장에서 함께 일하는 co-worker 개념으로 생각하고 일하는게 맞다고 본다.

단 한가지 예외 사항이라면, 회사에 직원 중에 개발자는 아무도 없고 나 혼자 개발자라면 문제가 있을 가능성이 높다. 애초에 그런 회사에 들어가면 혼자 개발 관련된 걸 모두 혼자 해 나가야 하기 때문에 방향성을 잃을 가능성이 높다. 최소한 내가 개발이 뭔지 알고 일 진행을 어떻게 하는 지 알아서 개발의 방향성은 잃어버리지 않는다고 하더라도 개발을 잘 모를 가능성이 높은 영업, 디자인, 대표 등등의 사람들에 의해 개발일이 쉽게 휘둘리는 건 시간 문제기 때문에 그런 곳은 비추한다.