Interview review 2017 #10-2

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. 다시 스타트업 회사

기술 면접을 위한 노트북을 준비하라고 해서 노트북을 준비해서 약속된 면접날 아침 일찍 갔다. 왜냐하면 그 회사는 인덕원역 근처에 IT 회사들이 모여있는 어떤 빌딩이었기 때문에 가는 시간만 해도 1시간이 넘었기 때문이다. 여기서 그 회사는 내가 지원한 스타트업 회사가 아니고, 스타트업 회사 대표가 다른 회사의 이사이기도 해서 그 "다른 회사"에 온 것이다.

오전 10시까지 가야 하는데 1시간이 넘는 거리라 출근하는 기분으로 또 면접을 보러 가게 되었다. 오랜만에 타보는 9호선과 4호선은 왜이리 사람이 많던지, 일하고 있지 않을 때 출퇴근 시간에 무표정하게 지나다니는 많은 사람들을 보면 나도 빨리 일하고 싶다라는 생각이 든다. 막상 일할 때는 그런 생각이 안든다는 것도 신기할 노릇이다.

면접 장소에는 수석 개발자 분과 팀장 한분만 참석했다. 스타트업 대표님은 이날 출장이 있다고 해서 참석하지는 않았다. 뭐 기술 면접이니 상관 없다고 생각했다. 다시 생각해 보면 보통의 면접 프로세스와는 반대로 진행되고 있다는 걸 알게 되었다. 보통 기술면접 후 임원 면접이 진행되는게 많은데, 이때는 임원면접 후 기술면접이 진행되는 식이었으니까.

어쨌든 간단한 기술적 대화를 나눠보고 C#과 .NET 그리고 Xamarin 등등의 얘기를 하다 보니 수석 개발자 분도 본인이 하고 있는 일에 대해서는 잘 알고 있었지만 일반적인 기법에 대해서는 알지 못하는 것도 있다 보니, "어 그런 것도 있었어요?" 라는 얘기도 나왔다. C# 7.0이 나오면서 튜플이라는게 생겼는데 나는 호기심에 한번 코딩해본적이 있는 걸 얘기해줬는데 그런 반응이 나왔었다.

그리고 본격적으로 코딩 문제를 줬다. 요즘 같으면 REST API로 만들면 쉽게 해결되는 기술을 RPC라는 개념을 들먹이면서 원격에 있는 메소드를 호출하고 결과를 받아오는 프로그램을 여러 기술과 라이브러리를 조합해서 만들어보라는 식이었다. 문제 해결 능력을 측정하는 면에서는 꽤 괜찮은 방식이라고 생각되었고 점심시간 전 까지 대략 3개 정도의 라이브러리를 사용해서 3개의 프로젝트를 만들어 테스트를 진행했다.

시간이 좀 걸리다 보니 점심 시간이 되었고, 점심도 같이 먹게 되었다. 회사 건물 1층에 순대국 집이 있었는데 거기서 순대국 시켜준걸 같이 먹으면서 이런 저런 얘기를 했다. 스타트업 대표님에 대한 얘기도 잠깐 했는데, 이것 저것 하고 싶은게 많은 분이고 공대 나왔지만 사업적인 마인드가 있다는 얘기도 듣게 되었다.

점심을 먹고 또 다시 코딩을 하기 시작했다. 코딩은 회의실에서 혼자 진행했고 인터넷 사용도 자유로웠다. 다만 원격 화면 공유 프로그램을 설치해서 수석 개발자분이 내 화면이 공유되는 걸 지켜보는 식으로 진행되는 기술 면접이었다.

시간이 남으면 UI 까지 개발하는 것도 optional한 요구사항이어서 거의 2년 만에 WPF 프로젝트를 만들고 xaml 코딩을 하기 시작했는데 막상 하려다 보니 인터넷 검색을 상당히 많이 해 가면서 진행하게 되었다. 여기서 문제가 발견되었는데, 수석 개발자 분이 내가 인터넷 검색을 자주 하는 화면과 xaml ui를 코딩하는데 뭔가 잘 안되고 있다는 느낌을 받았는지 나중에 끝나고 xaml 코딩 많이 안해보셨냐는 얘기까지 들었다.

이 시점에서 내가 느낀 건 뭐였냐 하면 실시간 코딩 테스트는 사실상 압박을 주는 상황에서 똑바로 잘 하나 혹은 잘 아냐 측정하는 수준밖에 안된다는 점이었다. 물론 실시간 코딩 테스트를 잘 하면 좋은 인상을 줄 수는 있지만 코딩 테스트 보다는 코드 리뷰 형태로 가는게 더 나은 방식이라고 본다. 어쨌든 실시간 코딩 테스트는 면접자들에게 초초함+압박+긴장으로 인해 제 실력이 안나오는 상황이 연출되기 때문에 안좋은 방식이다.

그렇다고 해서 내가 WPF를 잘 모르고 xaml 코딩을 잘 못하는 사람이 아닌데도 보는 사람의 시각에 따라서 그렇게 비춰지고 평가를 받는다는 점에서도 딱히 좋다는 느낌을 받지 못했다.

어쨌든 거의 하루 종일 코딩하느라 기력이 다 빠진 상태에서 그런 얘기까지 듣고, 최대한 빨리 못한 부분을 완성해서 메일로 달라는 얘기를 듣다 보니 완전 기운 빠지게 되었다. 그 당시에는 제대로 완성해서 보여주고 이 회사에서 일해야지라는 생각이 더 컸으므로 주말까지 시간내서 진행하면 완성할 수 있을 것 같았다.

그렇게 해서 주말까지 작업해서 메일로 제출하고 결과를 기다렸다. 나는 솔직히 될 줄 알았고 결과도 금방 알려줄 줄 알았다. 그런데 주말까지 시간 투자해서 추가 구현 내용까지 진행했는데도 1주일이나 연락이 없어서 심리적 압박감이 이만 저만 든게 아니었다.

그리고 2017년 4월의 어느날 하루만에 참으로 많은 일이 일어났던 날이 있었다.
그 날은 9번 회사, 지금 10번 회사, 이제 마지막인 11번 회사이자 내가 재직중인 버넥트에 대한 얘기를 한꺼번에 할 수 있는 날이기도 하다.

저는 xx개발자입니다. 나를 소개할때 어떤 분류로 하는가.

사람들 마다 내가 무슨 개발자인지 얘기할 때가 있다. 그런데 그 소개하는 방법이 일관적이지 않고 저마다 다르다. 어떤 개발자가 있는지 유형을 한번 살펴보고 올바르고 소개하는 방법에 대해 생각해 보고자 한다.

특정 프로그래밍 언어로 자신을 소개

이게 제일 흔한 방법인데,

"Java 개발자에요."

"Python 개발합니다."

등등으로 얘기한다.

그런데 이 방법에는 문제점이 있는데 프로그래밍 언어로 내가 무슨 개발을 하는지 정확하게 알지 못한다는 것이다.

Java의 경우도 안드로이드 앱 개발을 할 수도 있고 웹 어플리케이션 개발을 할 수도 있다. Python의 경우도 웹 어플리케이션 개발을 할 수도 있고, 인공지능의 CV쪽 개발을 할 수도 있을 것이다. 프로그래밍 언어 기준으로 소개하면 조금 더 질문을 하게 되는 단점이 있으므로 프로그래밍 언어 기준으로 소개를 하기에는 명확하지 않다.

개인적인으로 특정 프로그래밍 언어를 한정지어서 소개를 하면 경험이 없어 보일 수도 있다는 의견이다. 물론 자기가 알고 있는 프로그래밍 언어가 다양하면 "저는 C#도 하고 javascript도 하고, 종종 C++도 하고 필요하면 Swift도 합니다." 라고 해도 될 거 같지만 역시 어느 분야의 개발을 하는지 정확하지 않다는 단점이 있다.

특정 framework로 자신을 소개

이건 두번째로 흔한 방법인데

"Spring framework로 개발합니다."

"React 개발하고 있어요"

"WPF 합니다"

요건 그나마 괜찮은건 특정 프레임워크는 떠오르는 프로그래밍 언어가 있기에 연관지어서 추정이 가능하다. 즉 spring이면 java, react면 javascript, wpf면 c# 이런 식이다. 그런데 이것도 확실하지 않은 건 spring boot도 kotlin으로 할 수 있고 wpf 역시 c#이 아닌 vb.net으로도 할 수 있기에 프레임워크 기반의 소개는 조금 더 구체적이지만 언어가 불명확할 가능성이 조금 있고, 아직 중요한 부분인 어떤 분야에 대한 게 나오지 않아서 어딘가 간지러운데 많이 긁지는 않은 상태이다.

특정 OS, platform, 포지션 등등으로 자신을 소개

"iOS 앱개발 해요"

"프론트엔드 개발자에요"

"서버 개발자입니다"

"웹 퍼블리싱 합니다"

"윈도우 프로그래머입니다"

"e-커머스 플랫폼 개발합니다"

"Unity 개발자입니다"

여기까지 오게 되면 그나마 조금 더 구체적이게 된다. framework 레벨은 궁금하지 않을 수 있으나, 역시 이것도 개발하는 분야에 한정된 얘기이므로 간단하게 얘기하기에는 좋으나 또 더 질문을 해야할 필요성을 많이 느낀다.

특정 도메인이나 기술, 서비스 등등으로 자신을 소개

"텐서플로우 써서 인공지능 개발합니다."

"ERP 시스템 개발하고 있어요"

"증강현실 쪽 기술 개발 하고 있습니다."

"자율주행 임베드 시스템 개발해요"

"회계시스템 유지보수 일 하고 있습니다"

이제 도메인 분야가 나왔다. 일반 사람들도 그렇고, 개발자도 추상화된 개념으로 받아들이기에는 괜찮다. 그런데 개발자라면 이제 이런 일을 어떻게 하고 있는지가 매우 궁금할 것이다. 분야는 정해져 있는데, 어떤 기술 기반으로 어떤 툴을 써서 무슨 언어를 쓰는지 궁금해 진다는 얘기다.

이제 대략의 결론

일반인한테는 대충 얘기해도 잘 모를 경우가 많으므로 상관 없는데, 개발자 끼리는 좀 정확하게 전달하는게 좋지 않을까 하는게 내 생각이다. 그래서 소개를 할 때는 적절하게 프로그래밍 언어 + 기반 OS, platform + 해당 기술이나 도메인 분야 + 활동 범위를 잘 얘기하는게 좋지 않을까 한다.

이런 방법으로 하는 내 소개

"저는 Unity를 써서 AR 기술을 바탕으로 산업현장에서 사용하는 멀티 플랫폼 디바이스 클라이언트 개발합니다. Android, iOS, UWP 환경으로 빌드하고 종종 navtive로도 개발합니다. 서버쪽은 Node나 Swift로 REST API도 개발합니다. 사용하는 언어는 c#, javascript, java, swift 등입니다."

로 하는게 좋은데 역시 말이 길어지므로 나도 역시 대충 대답해준다.

"AR 개발해요"

결론

필요한 사람에게 자세히 소개하는 건 좋은거 같은데, 말이 길어지므로 적당하게 말을 만들어 낸 후에 링크드인 같은 곳에 이력을 잘 적어둬서 나를 소개할 수 있는 링크를 던져 주자가 결론이다. 내가 궁금한 사람은 여길 방문해 보자. 했던 일이 많으니까 구구절절 설명하기도 어렵다.

LinkedIn

한가지 피해야 할 소개는 프로그래밍 언어나 platform 의존적인 소개이다. java 개발, 윈도우 개발, iOS 개발, 프론트엔드 개발 등이다. 이렇게 하면 필연적으로 더 보조 설명이 따라가게 되어 있는 것 같다. 그리고 이제 막 주니어로 시작하는 개발자라면 했던 경험이 적으니까 상관 없는데 10년 이상 한 사람은 10년 내내 한가지 언어와 한가지 플랫폼에서만 개발했을 가능성이 매우 적으므로 잘 소개해야 할 필요가 있다고 본다.

코딩이 어려운 이유? 문제는 공교육식 프레임

코딩, 프로그래밍, 소프트웨어를 개발하고 배우는데 다들 어렵다고들 한다. 이건 전공자, 비전공자 가릴 문제도 아니다. 그런데 처음 배우는 거는 누구나 다 어렵다. 어렸을 때 부터 지금까지 새로운 걸 보고, 듣고, 배우는게 쉬운 사람이 있었던가? 만약 있었다고 자신있게 말할 수 있다면 탁월한 재능을 가진 사람이라고 말하고 싶다.

(이제부터 코딩, 프로그래밍, 소프트웨어 관련된 단어는 개발로 통일해서 얘기한다.)

다시 잘 생각해 보자. 개발을 하는 게 왜 어려운지. 한번 더 잘 생각해 보자. 잘 생각해 보면 어려울 이유가 없다. 개발에 대해 아주 쉽게 설명한 글들이 인터넷에 널려 있고, 특정 기술 관련된 따라하기 책들은 한달이 멀다하고 마구 쏟아져 나온다. 유튜브 동영상도 있고, 같이 공부하는 학원, 학교, 회사 사람들과 함께 하면 어렵지 않은 이유를 찾는게 더 쉽다고 말할 수 있을 정도다. 그런데도 개발 하는 걸 배우는 사람들은 이해하는 것도 어려워 하고 뭔가 잘 와닿지 않아서 어려워 하고, 자신의 학력탓, 비전공자 탓, 나이탓, 수준탓을 하면서 어려워 한다. 어쨌든 어려워 한다는게 핵심이지 않겠는가?

난 이 이유가 어디에서 부터 오게 되었는지 오랜 시간 생각해 왔다. 같은 걸 배우고 하는데 수준차이가 나는 이유도 찾아 봤고, 과외, 온라인 강의 하면서도 찾아 봤다. 최근에 멘토링 하면서도 찾아보고, 인터넷 까페에 올라온 수 많은 게시글에 댓글을 달아 주면서도 많이 생각해 봤다.

그 결과 프로그래밍 하는 걸 어려워 하는 이유는 거의 아래와 같은 내용들로 수렴된다는 결론을 얻을 수 있었다.

1. What의 문제: 뭘 해야 하는지 모른다. 
• 공부를 하는 방법을 모른다. 코딩하는 방법을 알면 잘 하게 될 거라 믿는다.
• 어떤 개발을 하는게 즐겁고 재미있는지 잘 모른다. 이유도 단순히 취업이 잘되는지, 돈을 많이 벌 수 있는지에 집중되어 있다.
2. Why의 문제: 왜 어려운지 판단하지 못한다.
• 내가 이해를 잘 못해서, 책이 쉽지 않아서, 내가 게을러서 등등 핑계는 찾을 수 있는데, 왜 어려운지에 대한 근본적인 의심을 잘 안한다.
• 자신이 가진 궁금증에 대한 해결을 다른 사람에게만 의존하려 한다. why에 대한 생각의 흐름 정리를 스스로 하지 못한다.
3. How의 문제: 어떻게 하는지에 대한 궁금증만 가득하다.
• 하루아침에 뭔가 쉽게 되는게 아닌건데도 되는 방법만 찾고 싶어 한다.
• 거기서 뭔가 조금만 더 고쳐서 해보려고 해도 계속 how to의 문제로만 귀결된다.
• how to에 대한 것만 하고 싶어 하다 보니, what, why에 대한 중요성의 인식이 상대적으로 떨어진다.

여기에 있는 내용을 다시 종합해서 보면 근본적인 학습 방법에 대한 훈련이 안되어 있는게 결론이다. 스스로 궁금증을 가지고 문제를 만들고 해결해 나가는 과정에서 학습하고 그 결과를 문서/사진/동영상 등으로 리포트 하고 review를 하는 활동을 학교에서 잘 하지 않았기 때문이다. 사실 이런 활동들을 해야지 개발을 할 수 있는 훈련이 되는 것이고, 그렇게 해 나가야 조금씩 성장이라는 걸 할 수 있는 건데, 어렵다 => 못하겠다 => 남들한테 물어본다 => 내가 안한다 이런식으로 흘러가다 보니 잘 하고 싶은 생각은 충만한데, 그냥 시간만 흘러가게 된다.

이런 안좋은 마음가짐들은 모두 공교육에서 나왔다고 본다. 공부를 하는 이유는 성적 관리를 위해서이고, 공부를 하는 즐거움은 없다. 또 어떻게 공부하느냐에 대한 문제도 범위가 정해져 있고 방법도 널려 있기 때문에 내가 고민할 필요가 없다. 내가 점수를 내기 위한 시간 투자와 점수를 내기 위한 방법을 잘 아는 학원이나 과외를 받으면 되기 때문이다. 어쨌든 뭔가 문제를 해결하려는 생각의 정리나 리뷰, 발표 이런 활동 위주로 하지 않았으니까 주어진 시험범위 내에 문제를 풀고 점수를 얻어 평가를 받아 등급이 매겨지면 내가 잘 하는 사람이 맞겠지라는 생각만 가득한 것이다. 그렇게 10년 이상을 반복해서 살아온 사람들이 갑자기 그런 패턴이 아닌 활동을 하려고 하니 비단 코딩 뿐만 아니라 어떤 분야를 하던 어려운게 맞을 것이다. 

이제 주어진 범위의 지식을 단기간 알고 있다가 점수를 내는 방식으로 평가를 받는 방법의 공부를 하지 말고

내가 해결하고자 하는 문제를 만들고 그걸 해결해 나가기 위한 탐색, 고민, 분석, 설계, 생각, 정리, 깨달음, 발표, 피드백, 리뷰, 기록을 가능한 수준부터 해 나가 보자.

지금 이렇게 하는게 늦은거 같은데 제가 이걸 할 수 있을까요? 같은 이상한 질문 하지 말고 일단 해보자. 공교육식 프레임을 깨고, 성장을 위한 활동 프레임을 씌우자. 지금 부터 몇 개월 몇 년 후를 돌아봤을 때, 아무것도 안한걸 후회하지 않게 지금 당장 해야 한다.

늦었다고 생각할 때는 진짜 늦은게 맞을 수 있다.

하지만 늦었다고 해서 아무것도 하지 않는건 잘못된게 맞다.

프로그래머가 되기 까지의 회고 (5) - 복학 후 각성할 때 까지

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절
프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지
프로그래머가 되기 까지의 회고 (4) - 군 시절

----

2001년 복학 했을 당시에도 공부를 열심히 하지 못했던 것 같다. 막연한 진로는 게임 프로그래머이긴 했지만 자신이 없었다. 당장 수업듣는 과목들도 자료구조, 마이크로프로세서, 이산수학 등 또 이론적인 과목들 뿐이었고 과제로 내주는 C 언어 프로그래밍은 동기나 후배들꺼 보고 겨우 이해해서 수정해서 내는 수준이었다.

지금은 상상할 수 없지만 그 당시만 해도 강의실에 흔한 빔프로젝터나 PC 같은게 있지 않았었다. 새로 지은 건물에는 구축이 되어 있었지만 80~90년대 부터 쓰던 강의실에는 그런걸 설치해 두지 않아서 누군가 수업시간 전에 빔 프로젝터와 노트북PC를 세팅해야 하는 일을 해야 했다. 물론 과대라 읽고 심부름꾼(시다바리)이라 쓰는 사람이 한다.

사실 과대가 될 생각은 해보지도 못했고 전혀 그런걸 할 생각도 없었는데, 어떤 계기로 인해 졸업할 때 까지 과대 혹은 반장이 되었다.

복학 후 자료구조 첫 수업 시간이었다. 지금도 그러는지 모르겠는데 첫 수업 시간은 대략적인 강의 설명, 리포트, 과제, 시험방식 점수 산정 방법 등등을 설명하고 1시간이 채 되지 않은 시간에 끝냈는데, 그때도 그랬다.

교수님이 대충 설명 끝날 때 쯤에 매 수업시간 마다 빔프로젝터와 노트북PC를 세팅할 사람(호구) 손 들라고 했다. 물론 아무도 손을 들지 않았다. 교수님이 혹하는 제안을 했는데 무려 2만원에 달하는 자료구조 책을 준다고 했다. 그래도 아무도 손을 들지 않았다. 무슨 생각이었는지 그 책을 그냥 갖고 싶다는 생각이 들었다. 그래서 손을 들었는데 바로 당첨되었다.

그후 모든 수업마다 내 동기들과 후배는 이런 일을 할 사람을 찾는 교수님의 눈빛을 보면 "반장~"을 외쳐댔고 그게 내가 되었다. 그렇게 계속 심부름 하면서 다니고 과대도 되었다. 그렇게 졸업할 때 까지 우리 반의 충실한 심부름꾼이 되었다. 기억에 남는건 학교에서 주는 용돈 수준의 과대비와 교수님과 동기 후배들의 잡일 처리였다. 아직도 나를 부르는 동기들의 목소리가 머릿속에 맴돈다. "반장~!"

<얘네들이 하는 말 믿지 마.
왜요?
그냥 믿지마!
저 이미 과대인데요?
빨리 탈출해 어서!
출처: http://young.hyundai.com/magazine/campus/detail.do?seq=16532>

이제 개발 얘기를 해 보자면, 2학년도 마치고 3학년이 되었지만 난 여전히 그저 그런 흔한 컴공생이었다. 과제는 점점 더 어려워지고 있었고 배우는 프로그래밍 언어도 C에서 JavaScript, C++ 등 해야 할 게 더 많아졌다. 더 하기 싫어져서 PC방에서 게임하던가 동아리방에서 놀던가 하는 걸로 시간을 보냈다. 지금 생각해 보면 그렇게 시간낭비를 하지 말았어야 했지만, 그때는 코딩이 너무도 하기 싫었고 코딩 안하는 과목 쪽에 눈을 많이 돌렸다. 소프트웨어 공학이라던가 데이터베이스와 같은 과목들.

그러던 중 프로그래밍에 눈을 조금 뜨게 된 중요한 계기가 몇 있었다. 객체지향 프로그래밍이라고 해서 C++의 class 개념을 추가해 객체지향적인 프로그래밍 과정을 이해하는 과목이 있었는데 초반 과제는 그럭저럭 했다. 그러나 중반 이후가 되니까 class, object 에 대한 이해를 하지 못하면 C언어로 짜듯이 주먹구구식으로 할 수 밖에 없고 결국 할 수 없는 수준이 되다 보니 정말 시간을 내서 이해를 해야 할 시간이 닥쳐오게 됐다.

내가 제대로 모르고 하는 부분이 뭐가 있는지 탐색해 나가다 보니 결국 포인터 부터였다. 그래서 연습하고 이해하고 연습하고 이해하고를 학교 실습실, 집에서 계속 반복해 가면서 이해해 갔다. 변수 이름 앞에 * 붙였다가 뗐다 하면서 오류 나는지 확인하고, 역시 & 붙였다 뗐다 하면서 오류 나는지 확인하고를 계속 반복하면서 알아보고 스스로 깨닫고 이해해 나갔다. 어떤 날은 새벽까지 집에서 그 짓을 하고 있을 때도 있었고 그 동안 스스로 하지 못했던 과제들을 포인터를 쓰고 안쓰고의 차이를 직접 해 보면서 알아 가기도 했다. 학교에서는 오후 늦게쯤 항상 가던 동이리방도 안가고 실습실에 야간 수업 들으러 오는 친구들 수업 시작하기 전 까지 몰입해서 했을 때도 있었다. 이러다 보니 야간반 애들하고도 안면이 트고 친해지는 계기도 되고 야간반 과대랑 졸업여행 계획도 같이 세우게 된 좋은 계기가 생긴것도 덤이긴 했다.

한 2주 지나고 보니 포인터의 규칙이 선명해 지면서 다른 모르는 부분들도 조금씩 이해가 되기 시작했다. Swap 함수가 왜 포인터의 주소로 념겨지는지, 함수의 포인터를 왜 넘겨주는지도 알게 되었다. new를 하면 메모리가 heap에 생기고 포인터 주소를 잃어버리면 어떻게 되는지 등. 학기 마지막 쯤 되니까 이미 1, 2학년 때 배우고 알고 있어야 하는 걸 그제서야 알았다. 사실 남들보다 한참 늦게 알게 된 것이다.

<이런 원리도 모르고 이해도 못한 채 코딩을 했던 시절이 있었다는 것이다.
출처: https://slideplayer.com/slide/5097101/>

목돈도 굴리려면 종자돈을 마련해야 한다는 얘기가 있듯이, 포인터에 대한 개념과 이해라는 종자돈을 잘 챙겨 두니까 이후에 파일 입출력 같은 것들도 목돈 불리듯이 술술 풀리게 되었다. 이 때 부터 내가 스스로 "각성"이라 불리는 상태에 돌입했던 것 같다. 학기 마지막 과제가 자동판매기 시뮬레이터였는데, 그걸 class 구조로 짜 나가면서 이해를 하기 시작했고, 새벽에 후배들과 문자 메시지를 주고 받으면서 설명해 주고 자랑(?)도 하고 그랬다.

그 열기는 여름방학 때에도 계속 이어갔다. 그 당시에는 Win32 API나 MFC로 Window 프로그래밍을 하는게 대세여서 후배들과 학교에 모여 스터디도 하고 C++ 관련된 책도 읽다 보니 STL이나 Effective c++ 같은 책들도 같이 보게 됐다. 2학기가 되고 나서 부터는 왠만한 과제는 스스로 배우고 풀기 위해 시간을 더 쓰게 되었고 어떻게든 혼자 힘으로 해결해 보려고 애썼다.

<Java 수업 시간에 class와 객체지향 개념 조금 알려준 후에 교수님이 과제로 내준 게, 스네이크 게임 만들기였다. 그때만 해도 말도 안된다고 생각했는데, 하다 보면 또 좋은 훈련이 되기도 한다.
출처: 위키피디아 뱀 게임>

교수님들이 내주는 과제는 너무 빡셌지만 그럴 때 마다 해내려고 하다 보니 재미도 생기고 자신감도 생기고 그랬다. 2학기 때는 Java도 했는데, 빡센 Java 과제를 해 나가면서 C++과는 또 다른 객체지향 개념에 대해 이해를 해 나갔고, 2학기가 끝나갈 무렵이 되자 어렴풋이 다음과 같은 느낌을 받았다. 이제 프로그래밍 문법 몰라서 못하는 수준은 아니고 튜토리얼이나 API 문서 같은거 보고 조금 따라 쳐본 후에 계속 API 참고 해 가면서 해 나갈 수준 까지는 됐던 것 같다.

거의 1년이 채 안된 기간 안에 많은 걸 이루어 냈다. 객체와 메모리 덩어리들이 머릿속에서 array, sort로 움직이고 포인팅하는 화살표 선이 이어지는 상상까지 할 수 있을 정도였고, 이제 내가 대학에 온 이유를 실현하기 위한 마지막 힘을 쏟기 위해 3학년 2학기가 끝나갈 무렵 게임 프로그래밍 학원 6개월 과정도 다녔다.

Interview review 2017 #9-2

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. 다시 웹툰 플랫폼 회사

첫 실무 + 기술 + 제안 면접을 끝내고 빠른 시일 내에 임원 면접 일정이 잡혔다. 평일 오전 시간에 잡혀서 출근하는 기분으로 좀 일찍 가서 커피 마시면서 기다리다가 면접 보러 들어갔다.

그런데 커피숍에서 기다리는 중에 대표님으로 보이는 분과 면접 봤던 실장님이 함께 밖에서 담배피우고 들어가는 모습을 목격했는데, 담배 피우시는 분이구나 하고 생각할 때 쯤! 눈 마주치면 어색하겠지, 또 커피숍 들어오면 안되는데 라는 생각에 자리를 잠깐 떳지만 담배만 피우고 들어갔다.

면접 시간 맞춰서 들어가서 대표님과의 첫 면접도 좀 쉽게 풀리는 느낌을 많이 받았다. 사업의 방향과 투자금액 현재까지의 상황 등에 대한 설명도 자세히 들었고, 기술 적인 내용은 실장님이 괜찮다고 하니 믿고, 같이 일해 보면 어떻겠냐는 제안을 받았다. 뭐 사실상 근로계약서만 안썼을 뿐이지 당장 내일부터 일하겠다고 하면 일할 수 있는 그런 분위기였다.

연봉 조건도 조금 쎄긴(?) 하지만 전 직장 연봉 수준으로 맞춰줄 수 있다고 했고, 대표님이 회사 경영을 1년 넘게 하다 보니 그냥 개발만 할 줄 아는 개발자로는 한계가 있다고 판단 CTO 같은 사람이 왜 있어야 하는지에 대한 얘기도 같이 나눴다. 전체적으로 사업 방향에 맞는 기술 선택 및 시스템 구성 그리고 기술적인 스킬과 업무 배분 정도를 할 수 있다면 좋겠다는 얘기도 했다.

여러 가지 얘기를 하다 보니 서비스의 프로토타입 수준을 벗어나 웹 서비스 + 데이터 저장소도 필요로 하는데 아직 로컬 서버로만 구성되어 있다고 해서 클라우드 서비스와 대용량 데이터 처리 기법 정도를 가볍게 얘기해 줬는데 여태까지 클라우드라는 걸 몰랐는지 상당히 관심을 많이 가졌고 필요한 만큼만의 돈을 쓰면 쓸 수 있는 서버 비용에 대해서도 매우 좋아했었다.

하지만 10번 스타트업 회사가 됐으면 하는 기대감이 더 컸기 때문에 일단 알겠다고 하고, 다른 곳 면접도 본 곳이 있어서 연락 드리겠다고 하고 나왔다. 이 시점에서 마음속으로는 10번 스타트업 회사가 안됐을 때? 이 회사는 어떨까에 대한 고민을 조금 했는데 솔직히 10번 회사가 안되리라는 생각은 하지 않았던 것 같다.

10번 회사의 기술 면접이 내일 이었기에 내일 기술 면접 진행하고 이후 결과를 보고 판단해 보기로 했다. 조금 부담스러웠던 건 여기 대표님과 실장님은 빨리 입사해서 주니어 레벨 개발자들을 도와 같이 일했으면 좋겠다는 어필을 너무 했다는 것이였다.

여태까지 수십번의 면접 경험 중에 이렇게 적극적으로 꼭 와서 일해달라는 얘기를 해줬던 회사 대표와 실무자들이 없었던 점을 보면, 여태까지 이 회사가 왜 마음에 드는 경력자를 찾지 못했는지에 대한 궁금증도 함께 들기도 했고 또 한편으로는 기분이 좋기도 했다. 사실 "나 돈좀 주고 일 시켜 주세요" 라는 저자세로 나오는 건 상당히 굴욕적이지만 "돈 줄테니 꼭 와서 일해 주세요"라고 나오는 건 같은 근로계약서를 쓴다고 해도 마음가짐 부터 다를 것 같다.

암튼 이 회사의 두 번의 면접 경험을 통해 얻을 수 있던 건, 사람의 마음을 움직일 수 있는 면접 보는 방식이었고 그게 "여기서 일하고 싶지않아? 어서 와서 일해줘" 라는 좋은 느낌을 받을 수 있는 신기한 면접이기도 했다.

상대적으로 너무 권위적으로 나오고 "뭐 알고 있는지 얘기해봐", "(대놓고 아니라 속으로) 이런 것도 여태 모르는 경력자였어?" 이런 느낌의 압박을 받으면 아무리 그 회사가 돈을 많이 주고 기술적으로 훌륭하다고 하더라도 같이 일하고 싶은 마음이 싹 사라진다는 걸 모든 면접관들이 빨리 깨달아야 하는 부분이라고 본다.

어쨌든 이 회사는 가지 않았지만, 이 회사를 갈지 안갈지의 결정을 했던 이유를 다음 회사들의 면접 결과를 정리해 보면서 얘기해 보려 한다.

마스터의 경지, 그게 있기는 한가?

초급자의 흔한 착각

코딩하는 방법을 이제 막 배우는 입장에 있는 사람들은 흔히 자기가 하고 있는 프로그래밍 언어를 마스터를 해야 한다고 생각한다. 프로그래밍 언어를 마스터 해야 한다는 것도 착각일 수 있지만 그건 논외로 하고 어쨌든 마스터를 해야 한다는게

• 일정 기간을 공부하면 된다는 걸 얘기 하는 건지
• 알고리즘이나 기타 코딩을 빠르고 정확하게 잘 짜는 능력을 얘기하는 건지
• 해결해야 하는 문제를 빠르고 정확하게 인지해서 해결 방법을 아는 걸 얘기하는 건지
• 내가 모르는 걸 물어보면 대답을 잘 해 주고 친절하게 설명해주고 알려주는 사람을 얘기 하는 건지

기준이 없다. 그러니까 그냥 내가 모르는 걸 잘 알고 있는 것처럼 보이거나 나보다 조금 더 오래된 경력을 가진 사람이면 마스터의 경지에 다다랐겠지 생각하는 경향이 있다. 아무도 그런 기준을 정하지도 않았고, 뭔가 좀 잘 하는 사람들이 "내가 XX 프로그래밍 언어를 마스터 했다" 라는 말도 잘 안하는데 우리는 마스터의 경지, 고수 이런 경지가 있는 것처럼 생각한다.

그리고 그 좀 잘 해 보이는 사람에게, 어떻게 하면 잘 할 수 있는지 방법을 알려달라고 하지만, 뭔가 시원하고 가슴에 확 와닿는 대답을 해주는 사람이 없다.

이쯤 되면 빨리, 아 내가 뭔가 착각하고 있구나 라고 판단하고 그 혼란스러운 생각을 벗어 버려야 하는데, 시간이 지나도 자신은 잘 못하는 사람이고 이걸 마스터를 하지 않았기 때문에 삽질하고 있다고 생각한다. 또 이 분야를 마스터를 해야 내가 잘 하는 사람이 될 수 있을 거라는 생각만 계속 한다. 그리고 뭔가 액션을 취하지도 않는다.

언제까지 배우면 마스터를 할 수 있는지

제발 이런 쓸데없는 질문은 이제 그만 했으면 좋겠다. 자신의 학습 능력, 기억력, 사고력, 집중력, 이해력, 판단력 등등 객관적인 데이터나 상황에 대해서는 일절 알려주지도 않고 질문을 하면 대답을 해 줄수가 없다. 심지어 자기 자신도 잘 하는지 못하는지도 잘 모르면서, 이  막연하고 어렵고 힘들어 보이는 프로그래밍 공부를 사람들이 얘기해준 기간만 버텨내면 마스터의 경지에 다다를 수 있는지 알고 싶어하는 것 같다. 항상 그렇다. 이 공부를 언제까지 하면 되는지에 대한 궁금증을 풀기 위해 초급자들이 하는 질문 중에는 아마 부동의 Top 1일 것이다.

그걸 남들에게 물어보면 대답이 천차만별일텐데, 대충 그 대답의 평균 기간을 자기 자신한테 적용해 보면 될 거라고 생각하는 것 같다. 게다가 그 중에 제일 짧은 기간을 얘기해 준 사람의 말을 듣고 스스로 희망고문의 덫을 씌운다. 그래 X개월 하면 나도 잘 할 수 있을 거야라고.

그런데 이 생각을 가진 사람을 잘 살펴보면 공부라는 걸 제대로 해본 사람이 아닐 가능성이 높다. 열심히 해야 하는건 알겠는데 하기는 싫고 부지런 해야 하는 것도 알지만 막상 하기 귀찮고 게을러 지게 되고 핑계거리만 찾아서 자기 합리화만 한다. 그리고 그 막연한 마스터의 경지에 대한 질문만 계속 하는 것이다. 그리고 언젠가 이 고통스러운 시간이 지나면 마스터가 되어 있을 거라고 꿈을 꾸는 것 같다. 그래서 기간에 계속 집착하고 있는 것이다.

• 누구는 학원 6개월을 다니면 될거라고 한다.
• 누구는 독학으로 1년 정도 하면 될거라고 한다.
• 누구는 3년을 했어도 아직 잘 모르는게 있다고 한다.
• 누구는 평생 공부한다는 생각을 가지고 해야 한다고 한다.

누구 말이 맞는 말일까? 누구 말이 맞는 말일까 고민하는 거 부터가 잘못됐다. 그리고 나는 절대 그런 마스터의 경지는 없다고 자신있게 얘기할 수 있고, 그렇기 때문에 기간을 논하는게 무의미하다고 얘기해 줄 수 있다.

그러면 어쩌라는 건지?

일단 답답하고 짜증나는 심정은 이해하나, 이 분야가 아니더라도 뭔가를 잘 하기 위해서는 조금씩이라도 꾸준히 뭔가를 해 나가야 하는게 정답에 근접한 대답이라고 본다.

하루 아침에 갑자기 짠 하고 잘 하는 사람이 없듯, 뭔가 대단해 보이는 짓을 하는 사람들을 잘 살펴보면 계속해서 흥미를 가지고 꾸준히 해 왔던 사람들이라는 얘기다. 사실 본인은 그런 활동을 하지 않았으면서도 그런 마스터의 경지를 찾아 방황하고 있었으니 욕을 한번 들어 먹을만도 하다.

이제 뭔가 느껴지는게 있다면 제대로 차근차근 자신에게 맞는 방법을 찾아 나가는 것이 맞다고 본다. 또 다른 사람의 의견을 들어봐도 좋다. 사람마다 각자 해 왔던 방식이 다르므로 참고 정도만 하는게 좋고, 자기 스스로 맞는 방법을 찾아 나가야 한다. 누구나 꿈꾸는 것은 쉽지만 꿈꾸는 수준에 도달하기 위해서는 작은 실천의 발걸음을 한 발자국이라도 옮겨야 하지 않겠는가?

그래도 가르침을 주십시오! 라는 질문에는 대충 뭘 해야 하는지는 정해져 있긴 한데 잘 하려고 꾸준히 노력하려는 마음과 의지를 탑재한 후 실제 실천을 통해 연습하고, 정리하고, 발표하고, 공유하고, 피드백을 주고 받고, 이해하고 하는 활동들을 해 나가면서

• 내가 이 일에 흥미가 있는지
• 적성에 맞다고 생각하는지
• 성취감 이라는게 있었는지
• 꾸준히 하고 있는지

이런 걸 가끔 돌이켜 생각해 보면서 진행해 나가면 어느 정도 답을 얻을 수 있다고 본다.

최소한 이런 활동을 한 후에 다시 선배들을 찾아가서 마스터의 경지를 물어보자, 질문이 예전과 같이 이상하다고 느껴질 것이며 이제 그 선배들이 했던 이해 안가는 말들이 조금씩 이해가 되기 시작할 것이다.