Monday, December 3, 2018

프로그래머가 되기 까지의 회고 (4) - 군 시절

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

----
뭐 나도 군대라는 곳을 어차피 가야 했었고, 공부하는 것에도 그렇게 흥미가 있지 않았던 데다 집에서도 군대를 빨리 다녀오는게 좋겠다고 해서 자연스럽게 1학년 까지만 다니고 휴학을 한 후에 군대에 지원했다. 그런데 정말 얼마나 지원자가 많았냐 하면 육군 같은 경우는 거의 1년을 대기해야 한다고 했을 지경이었고 그 외에 지원해서 입대하는 다른 공군, 해군의 경우도 몇 개월씩 기다렸다가 입대를 할 수 있었다. 내가 살았던 시대의 흐름이 그렇다 보니 나도 자연스럽게 그렇게 대기를 하고 군대를 가야 했다.

때마침 국가부도의 날이라는 영화가 개봉했고, 영화 리뷰 겸 그 때 나의 상황에 대해 설명한 내용이 있으니 아래 링크를 참조하면 더 좋을 것이다.
https://feelcommonlife.blogspot.com/2018/12/blog-post_3.html

육군은 안될거 같아서 나머지 지원해서 갈 수 있는 것 중에 해군에 지원해서 입대를 했다.  복무기간이 28개월이어서 복학 기간에 맞추려면 최대한 9월 이전에는 입대를 했어야 했고 안그러면 다른 방법을 찾았어야 했는데 다행히 7월에 입대해서 11월 제대하는 복부기간이어서 복학 준비도 할 수 있는 기간에 입대를 하게 되었다.

진해에서 기초 훈련을 받고 병과를 지원해서 나누게 됐는데 그때는 키 순서대로 헌병 데려가고 컴퓨터 관련과는 전산병으로 데려가고, 전자통신 관련 과는 통신병으로 데려가고 그런 식이었다. 난 컴퓨터공학과 다니다가 군대에 오니 뭐 당연하게 전산병이 되게 되었고 전산병 훈련 받는 기간에 정말 놀라운 경험을 하게 되었다.

<왼쪽 부터 겨울 정복, 근무복, 여름 정복이다. 어린 시절 단순하게 이 옷을 입으면 땅바닥을 구르는 훈련을 안할거라 생각해서 해군을 가게 되었는데... 땅바닥을 구르는 훈련 외에 다른 훈련이 기다리고 있다는 사실은 몰랐다.
출처: 해군 블로그 http://blue-paper.tistory.com/>

대학에서 Unix와 C를 한 것도 조금 신기했는데, 그 때 군대에서 전산병에게 교육한 내용은 무려 COBOL이었다. 실제로 구전과 책에서나 봤던 언어였고 실제로 이 언어로 프로그래밍을 한 사람을 찾는게 가능한 일인지도 힘든 그 COBOL. 그게 전산병 교육장 PC 실에 깔려 있었고 며칠 동안 COBOL 프로그래밍을 배우기도 했다. 그때 프로그래밍 했던 COBOL은 영어 문장으로 프로그래밍을 하는 거였고 BASIC과 아주 흡사했다. 필요에 의해서 실습도 하고 공부도 했지만 정작 군생활 내에 써먹어 보지는 못했다. 왜냐하면 실제 내가 군생활을 했던 곳에서는 COBOL을 쓰지 않았고 Visual basic이나 Power builder를 썼기 때문이다. 이 마저도 잠깐 해봤을 뿐이다.

<군 생활 때 워드병 생활을 하면서 열심히 문서 작성했던 워드 프로그램인 아리랑 3.0
출처: http://blog.daum.net/_blog/BlogTypeView.do?blogid=06Txc&articleno=15813762&totalcnt=129>

군 생활 때 전산실에 근무해서 Visual basic을 잠깐 접할 기회가 있긴 했지만, 곧 어른들의 사정으로 인해 어느 부서의 워드병으로 차출되어 거기서 문서작업 하는 일로 제대할때 까지 군생활을 했다. 상병, 병장의 계급을 달고 짬이 차면서 자연스럽게 공부하는 시간이나 자유 시간이 조금 생기게 됐는데, 그 때까지만 해도 개발 공부를 해야 겠다는 생각을 잘 하지 못했다. 이유는 다양했지만 지금과는 달리 그때는 컴퓨터를 쓸 수 있는 시간은 업무 시간이었고 일부러 거짓 보고를 올리고 사무실에서 야근한다고 하지 않는 이상 컴퓨터를 쓸 시간이 없었다. 두 번째는 공부 보다는 외박 나가서 PC 게임 하는 것과 록 음악 듣는 것에 더 심취해 있던 기간이었던 것 같다. 즉 전공 공부나 프로그래밍 공부를 해야 한다는 생각은 있었어도 실천은 못하고 음악 듣거나 외박 나가면 PC 게임 하는 걸로 시간을 보냈다.

제대 하기 몇 달 전 그 당시 인기 있었던 인터넷 정보 검색사라는 자격증이 있었는데, PC에서 객관식 시험을 치면 바로 합격 여부를 알 수 있는 자격증이어서 특별히 컴퓨터에 관심이 없던 사람들도 따곤 했던 자격증이었다. 그런데 사실 개발하는 능력하고는 전혀 상관도 없고 자격증 자체가 공신력이 있는 것도 아니어서 그냥 있으나 마나한 자격증을 따고 아주 잠깐 뿌듯해 했던 기억도 있다.

어쨌든 군 생활 때도 개발 관련된 활동을 하지 않았던 건 사실이다. 엄청나게 능숙한 워드 프로그램 작성 능력, PPT 작성 능력을 자연스럽게 익힌 것과 한글, 영문 타자 속도가 엄청나게 늘었다는 점 (각각 800, 500 타 정도?), 그리고 2벌식도 빠르게 치는게 지루해서 3벌식 타자 연습도 했던 (200타) 그런 시절을 보냈다. 팩트로 얘기하자면 개발과 개발 외에 컴퓨터로 하는 모든 작업의 물리적인 기본 능력만 키운 셈이다.

제대한 후에는 다행히도 복학할 학비를 부모님이 준비해 주셔서 학교에 복학할 수는 있었는데, 군 생활을 했던 3년 사이 쓰던 컴퓨터의 성능이 썩 좋지 않아서 또 컴퓨터가 좋아야 공부를 할 수 있다는 핑계를 대고 좋은 컴퓨터를 마련하고자 복학하기 전 까지 PC 방 알바를 하며 점심 값 제외하고 월 60만원 정도를 벌어 그 당시 살 수 있던 아주 좋은 성능의 PC를 장만했다.

지금 월 60만원에 알바하라고 그러면 미친놈 취급 받겠지만 그 당시(2000년)만 해도 최저 시급 개념도 희미했고 시간당 알바 시급이 대충 2천원 전후였기에 대략 최저시급 정도 받고 일했던 것 같다. 그래도 점심은 꼬박꼬박 사주고 한달에 한번씩 회식도 시켜줬던 PC방 사장님이 고맙기만 했다.

그리고 이제 다시 학교로 돌아갔다.

Friday, October 26, 2018

Interview me

이건 성공하는 프로그래밍 공부법 책에 챕터가 끝날 때 마다 개발자 들의 인터뷰 내용이 있는데, 거기에 있는 인터뷰 질문에 대해 내가 답변한 걸 적어본 것이다.

Q. 간단한 자기 소개 부탁드려요


저는 버넥트에서 AR/VR 기술을 사용하여 제품 개발을 하는 일을 하고 있는 김종필이라고 합니다. 회사에서의 소개는 이렇고 좀 더 폭넓게 소개해 드리면 소프트웨어를 개발하는 걸 업으로 삼고 배우고 익히는 걸 멈추지 않으려 노력 및 실천을 하고 있는 한 프로그래머라고 보면 좋을 것 같네요. 또 제가 중요하다고 생각하는 소프트웨어의 가치를 전파하기 위해 여러 대학생 및 이제 프로그래밍 일을 한지 얼마 안된 친구들과 소통하고 문제를 같이 고민하고 해결해 나가는 일도 같이 하고 있습니다.

Q. 요즘 리얼리티 프로그램이 대세잖아요. 하루 일과를 그냥 가감없이 보여줌으로써 시청자도 같은 감성을 공유하거나 삶을 간접적으로 체험한다거나. 이런 관점에서 하루 일과를 공유해주신다면?


출근은 유연 근무제를 하고 있어서 08:30 ~ 10:30 사이에 출근한 후에 17:30 ~ 19:30 에 퇴근하면 되는 환경입니다. 저는 일찍 출근하고 일찍 퇴근하는 걸 좋아하기에 08:30에 출근합니다. 사실은 아내가 대학원에서 공부를 하고 있기에 집에 일찍 가서 이제 두살 된 딸도 봐야 하는 이유가 더 큽니다. 출근 하기 전에 항상 오늘은 무슨 일을 하고 일을 언제까지 얼마나 해야 하는지 생각합니다. 회사 출근해서 자리에 앉은 다음에 이것 저것 상황 파악하고 하는 것 보다 미리 생각하고 나서 나만의 페이스 대로 일하는 걸 좋아합니다. 현재는 공기업의 연구과제 및 대기업 PoC 과제, 자체 라이브러리 개발 등 여러 가지 일을 하고 있습니다. 기술 베이스가 AR이다 보니 다양한 플랫폼과 다양한 디바이스를 가지고 개발을 하고 있는데요. 태블릿, 스마트폰, 스마트 글라스 등 디바이스의 특성도 있지만, android, iOS 등 플랫폼의 특성도 있기에 이런 환경에서 개발하는 것에 익숙해 져야 하는 것도 있습니다. 주로 하는 업무는 개발이 많고 연구과제 및 테스트도 많이 합니다. 기획팀과 디자인팀과도 협업해야 하기에 종종 회의도 하고, 디자인 시안, 이미지, 문서 등등 많은 걸 공유하며 같은 목표를 달성하기 위해 각 팀이 각자 맡은 바 일을 열심히 합니다.

Q. 프로그래밍 공부를 시작하게 만든 강력한 동기가 무엇이었나요?


PC 게임이었던 것 같습니다. 초등학교 때 컴퓨터 학원에 다니면서 컴퓨터 쓰는 법과 프로그램 짜는 법, PC 게임 하는 것 등, 컴퓨터를 학원에 다니면서 자연스럽게 컴퓨터라는 걸 접했습니다. 중학교 입학 할 때 부모님이 처음 PC를 사주셨는데 그걸로 열심히 게임을 했고 게임을 하다 보니 어떻게 만들어야 하는지 PC 잡지 등을 통해 알아보다가 프로그램 언어를 배워서 프로그램이라는 걸 짜서 실행 파일을 만들면 게임을 할 수 있다는 걸 알게 됐죠. 신기한건 그 때 부터 지금까지 게임을 만들어 본 적 없이 프로그래머의 인생을 살고 있긴 한데, 프로그래머가 되어야 되겠다는 동기는 확실히 PC 게임을 해보고 만들어 봐야 겠다는 생각을 하면서 부터가 맞는 것 같습니다.

Q. 맨 처음 누구나 프로그래밍 공부는 막막할 것 같습니다. 혼란스러웠던 시기의 에피소드를 얘기해주실 수 있는지요?


사실 컴퓨터 학원에서 프로그래밍을 배우긴 했는데 공부를 했다기 보다는 기계적으로 프로그램 짜는 훈련을 했던 것 같습니다. For문 돌려서 별찍기, 국어, 수학, 영어 점수 입력받아서 총점, 평균 구하기, 간단한 수학 문제 및 함수 만들어서 계산하기, 특정 년도와 월의 달력 출력하기 등 제 생각대로 프로그래밍을 했다기 보다는 컴퓨터 학원에서 정해준 문제를 푸는 방법을 익히고 그걸 그대로 프로그램을 짜는 훈련을 열심히 했던 거죠. 10살 부터 했는데 어린 나이에 뭔가 깊이 있게 공부를 했다기 보다는 자연스럽게 컴퓨터 프로그램이라는 형태가 어떤 것이라는 걸 반복 훈련을 통해 알게 되고 습관이 되다 보니 이후에 프로그래밍 하는 것도 아주 막 어렵거나 하진 않았던 것 같습니다. 그러니까 남들과 달리 어린 나이에 프로그래밍을 접한 거라 막막함을 느끼거나 생각할 시간도 없었다고 보는게 맞겠네요.
그래도 질문이 혼란스러웠던 시기니까 그 시기를 얘기해 보면 대학 다니면서 컴퓨터에 관련된 공부할 때였던 것 같습니다. 프로그래밍의 기본 적인 건 이미 알고 있었지만 뭔가 언어적인 특징을 조금 더 공부한다던가, UI 관련 프로그래밍을 할 때라던가 할 때 계속 공부해 나가면서 알아가야 했죠. 누구나 다 어려워 했던 C언어의 포인터의 개념도 공부해서 알았다고 하더라도 제대로 이해해서 활용하기 까지 저 역시 남들과 같이 오랜 시간이 걸렸던 것 같습니다. 또 컴퓨터를 배운다는게 프로그래밍을 배우는게 다 인줄 알았던 저에게 대학에서 공부했던 과정은 저를 더 컴퓨터에 대해 알게 해줬기 때문에 코딩을 잘 하냐 못하냐의 갈등 속에서도 소프트웨어를 만든다는 것에 대한 체계를 잡아 나갈 수 있었던 것 같네요.

Q. 자신만의 프로그래밍 공부법이 있으셨을 것 같습니다. 초창기, 성장기, 그리고 현재 왕성하게 활동하고 있느니 기간, 이 세 기간으로 나누어서 소개해주실 수 있나요?


초창기

대학 다닐 때는 프로그래밍 공부를 계속 해봐야 실력이 는다고 생각해서 방학때 스터디 모임도 하고, 게임 프로그래밍 학원도 다니고 했던 것 같습니다. 또 전공 관련된 책 역시 용돈으로 사서 원서 번역본 할 것 없이 이것 저것 많이 읽고 친구들한테도 빌려주고 했었습니다. 프로그래밍 관련된 지식이라면 모르는게 없어야 한다고 생각해서 계속해서 공부하고 많은 책을 읽어 봤던 것 같네요.

성장기

제가 성장했던 시기는 현업에서 일하고도 한참 지난 후 였다고 생각합니다. 프로그래머가 성장하기 위해서는 많은 경험이 필수적인데 저는 몇 년 동안 많은 경험을 하고도 크게 성장하지 않았다고 생각했었습니다. 그 중에 큰 걸림돌은 한가지 플랫폼과 한가지 언어에 종속적인 일을 쭉 해오다 보니 그랬던 것 같고, 제가 크게 성장할 수 있었던 계기는 기존에 해 왔던 PC용 프로그램이나 앱 개발이 아닌 웹 프로그래밍을 접하면서 부터였습니다. 그리고 그 웹 프로그래밍 경험도 쌓이다 보니까 어느 한가지 결론에 다다르게 되었는데요. 사실 여러 선배 개발자 분들도 아실거라 생각되는데 어떤 시스템과 서비스를 만드는 일에 특정 프로그래밍 언어와 플랫폼이 종속적이어야 하는 이유를 찾을 수 있는지를 생각해 보면 프로그래밍 외에도 알아야 할게 많다는 걸 느끼면서 성장을 했던 것 같네요.

현재

지금은 현업에서 아직도 프로그래밍이 가능할까 싶을 정도의 경력이 쌓여 있는데, 경력이 쌓이고 경험이 많아질수록 점점 더 기본에 충실해야 하고 원리에 대한 깊은 이해가 필요하다는 걸 많이 느끼고 공부하는 걸 멈추고 있지 않습니다. 알고리즘 문제 풀이를 하면서 논리적인 사고를 해야 한다는 걸 계속 느끼고 있고, 여러 플랫폼이 가지는 장점과 철학을 리뷰하면서 왜 이런 라이브러리와 프레임워크가 생기게 되었을까에 대해 만든 사람의 입장에서 이해해 보려고 많은 문서와 책을 읽고 있습니다. 이제는 저의 이런 경험을 후배 프로그래머에게 나눠주고 싶은 마음에 멘토링 활동도 열심히 하고 있습니다.

Q. 프로그래밍 공부에서 알고리즘이나 수학이 중요하다고 하는데요. 꼭 그런가요?


분야가 워낙 다양하다 보니 "그럴 수도 있고 아닐 수도 있다"로 해석될 수도 있지만, 저는 수학이 중요하다고 생각하는 쪽입니다. 웹 응용쪽 개발을 하는 프로그래머는 수학을 몰라도 아름다운 UI와 비지니스 로직 처리를 구현해 낼 수 있죠. 하지만 영상 인식의 분야와 머신 러닝 기반으로 개발을 하는 프로그래머는 관련된 수학 모델 설계와 지식이 필요할 수 있습니다. 그런데 이것도 수학적 지식에서 보면 그런 것일 수 있지만 프로그래밍을 하는 데는 "수학적 지식" 보다는 "수학적 사고 방식 및 논리 전개"가 중요한 것 같습니다. 수학적 지식은 필요할 때 다시 공부해서 적용하면 되지만 사고 방식 및 논리 전개는 자연의 법칙에 대한 이해와 깊은 사고 능력을 훈련하지 않고서는 배울 수 없는 가치이기 때문이죠. 수학을 배운다는 건 지식을 배우는 것도 있지만 사고 능력을 배운다는 차원에서 중요하다고 봅니다.

Q. 프로그래밍에서 중요한 것 세 가지만 꼽는다면 무엇이 있을까요? 세 가지 넘어도 됩니다.


소프트웨어에 대한 본질적인 이해

컴퓨터라는 물건이 어떻게 동작하고 이걸 통해서 뭘 하고 싶어하는 건지 그 근본적인 이해가 반드시 필요한 것 같습니다. 무슨 일이든 기초가 튼튼해야 응용력도 쉽게 길러지는 법이라고 생각합니다. 여기서 컴퓨터에 대한 이해가 하드웨어 지식도 필요하지만 소프트웨어에 대한 지식이 반드시 필요합니다. 프로그래밍이라는 걸 하기 전에 소프트웨어에 대한 이해를 하고 프로그래밍을 하는걸 강력하게 추천합니다.

코드 리뷰

흔히 컴퓨터는 거짓말을 하지 않고 프로그램이 잘못된 건 전적으로 프로그래머의 잘못이라고 하죠. 그런데도 많은 프로그래머들은 컴퓨터가 잘못된 것, 나는 프로그램을 제대로 짰을 것이라는 착각을 합니다. 프로그램을 잘 짜려면 여러가지 요소가 필요한데, 저는 무엇보다도 자기가 가지고 있는 생각의 흐름대로 프로그램을 짰는지 리뷰를 하는게 중요하다고 생각합니다. 코드를 타이핑 할 때는 몰랐던 많은 논리적 오류는 물론이고, 새로운 자신을 발견하고 반성도 하며 더 나은 내가 되는 좋은 계기가 되거든요. 이 훈련이 잘 되어 있으면 꼭 컴파일이나 빌드 작업을 해봐야 검증이 될 거라는 미신을 떨쳐내고 코드 리뷰만으로도 얼마든지 좋은 프로그램을 짤 수 있는 경험을 할 수 있게 됩니다.

장인 정신

프로그래밍을 공부하는 거의 대부분의 프로그래머는 코드를 짜고 동작하게 만드는 것 만이 프로그래머의 역할이라고 생각할 수도 있지만, 범위를 넓혀서 큰 프로그램을 짜고 여럿이 함께 훌륭한 소프트웨어를 만들어 나가는 과정은 동작하는 코드를 짜는 것 만이 전부가 아닙니다. 이 소프트웨어를 쓰는 사람의 요구, 현실 세계에서 요구되는 것들을 해결해야 하는 문제에 대한 분석, 이걸 이해해서 소프트웨어로 옮겨 나가는 논리적인 과정, 실제 가치가 있는 서비스인지 검증하는 절차, 지속적으로 서비스가 가능하고 필요한 추가 요구를 반영해서 더 좋은 소프트웨어를 만들어가는 방법. 이걸 소프트웨어 공학이라고 합니다. 이 분야는 경험적으로도 증명이 되었고 역사적으로도 많은 프로그래머 선배들이 좋은 책을 써 와서 간접적으로도 알 수 있는 지식입니다. 소프트웨어 요구사항의 정확한 분석, 설계, 개발, 테스팅, 유지보수등 소프트웨어를 만드는 일련의 과정을 거친다면 소프트웨어를 쓰려는 사람들이 품질 좋은 서비스와 생산활동을 할 수 있게 됩니다. 프로그래밍 하는 방법 외에도 소프트웨어 엔지니어링 공부가 꼭 필요하고, 소프트웨어의 품질을 높이는 것에 조금 더 신경을 쓰게 되겠죠.

Q. 닯고 싶은 프로그래머가 있나요? 동료도 좋고 유명한 프로그래머도 좋습니다. 그리고 그 이유는?


Robert C Martin 입니다. 소프트웨어에 대한 중요한 철학이 무엇인지를 잘 알고 그걸 알려주신 분이죠. SOLID 원칙, clean coder, 장인 정신 등 프로그래밍 실력이 뛰어나야 함은 물론 그 단계를 넘어 소프트웨어를 바라보는 시선이 어떠해야 한다는 얘기를 명확하게 해 줘서 좋은 것 같습니다. 어느 정도 프로그래밍 스킬은 익힌 것 같은데 소프트웨어를 뭔가 잘 만들어야 겠다는 욕구가 생기기 시작할 때 쯤에 이분의 명서들을 읽어 보면 많은 도움이 되고 많은 가치를 배울 수 있을 겁니다.


Q. 처음 프로그램다운 프로그램을 만든 경험담이 있으신지요? 어떤 프로그램이었나요? 그리고 지금 생각해보면 그 프로그램은 프로그래머 인생에서 어떤 역할을 했다고 생각하나요?


첫 회사에 입사해서 아직 뭐가 뭔지 모르던 시절에 회사 솔루션의 한 부분의 기능을 맡아서 구현하게 되었습니다. FTP 파일과 로컬 파일의 차이점을 비교하고 파일 동기화 기능 등을 구현하는 UI와 파일 diff, FTP 파일 전송 등등의 기능을 구현했죠. 지금은 뭣 모르던 신입때 처럼 우와좌왕 하면서 프로그래밍을 하진 않겠지만, 그 때는 많은 버그와 새로운 기능을 추가하면서 생기는 문제들을 해결하는데 많은 시간을 쏟을 때였습니다. 그리고 그 기능이 담긴 솔루션을 어느 공공기관에 납품을 하게 되었고, 거기서 실제 사용자들이 사용하면서 추가된 또 수많은 버그들과 요구사항 추가 구현 등을 하면서 정말 많은 경험을 했던 기억이 나네요. 짧은 기간에 프로그래밍을 잘했냐 못했냐 보다는, 사용자가 쓸 수 있는 프로그램을 제대로 만드는 능력은 코딩 실력과는 다른 것이라는 값진 경험과 깨달음을 얻었습니다. 대학에서 공부했던 소프트웨어 공학을 실전에서 신입때 경험해 보고 나니 이후에 만들었던 모든 프로그램들은 그냥 기능만 동작하게 만들었던 것 같지 않았습니다. 주어진 기능 구현만이 프로그래머가 해야 할 일이 다가 아니라는 걸 알았던 때였던 것 같네요.

Q. 프로그래머라서 행복할 때는 그리고 불행하다고 생각할 때는?


행복할 때는 쓸모 있는 소프트웨어를 세상에 내 놓았을 때인것 같습니다. 가장 훌륭한 소프트웨어는 처리 속도가 빠르고 기능이 많은 프로그램이 아니라, 사람들이 계속해서 쓰고 지속적인 업데이트를 통해 완벽에 가까운 프로그램을 만들어 나갈 때인 것 같습니다. 그런 소프트웨어를 계속해서 개발하고 사용하는 사람들의 가치를 소프트웨어를 통해 구현해 나갈때가 누구나 행복해 하는 때가 아닐까요?
불행할 때는 근무 시간의 불확실성인 것 같습니다. 단순히 야근이 많아서 일이 힘들다도 포함될 수 있지만, 일의 특성상 근무 장소나 시간의 제약이 거의 없다 보니 새벽에 작업을 진행해서 업데이트를 해야 할 때도 있고, 프로그램이 죽거나 오류가 나는 상황을 빠른 시간안에 해결해야 하는 상황이 닥쳤을 때 법정 근로 시간이 무기력해 지는 시간이거든요. 업무 시간 외에도 해결을 해야 하거나 할 때 종종 생각이 들긴 합니다.

Q. 지나온 과거를 돌이켜볼 때, "아~ 그때로 돌아가면 이런 공부를 좀 하고 싶다"라는 게 있는지요?


일단 미리 공부해야 한다는 차원에서는 딱히 그런 건 없는 것 같습니다. 다 그 나이에 맞는 수준의 공부를 해야 한다고 생각하기 때문에 더 빨리 공부한다고 해서 더 나아지리라는 보장이 없다는게 제 생각입니다.
하지만 선택의 순간에서 다른 선택을 했을 때 아쉬운 건 있는데 대학원 진학을 못했던 것입니다. 그 당시에 저는 취업 보다는 조금 더 공부해서 소프트웨어 공학쪽이나 그래픽 UI 처리 쪽을 더 공부 하려고 했으나 집안 사정 때문에 취업을 할 수 밖에 없는 상황이었죠. 부모님의 바램대로 졸업 전에 취업을 해서 회사 생활을 쭉 해오긴 했지만 마음속 깊은 곳 한쪽에서는 대학원을 진학해 조금 더 연구과제에 대한 공부를 했으면 어땠을까 하는 아쉬움이 조금은 있긴 합니다.

Monday, October 8, 2018

프로그래밍 언어를 잘 아는게 실력 향상에 도움이 되는가?

여러 커뮤니티 사이트와 네이버 까페 등을 가보면서 junior 레벨의 프로그래머가 항상 궁금해 하는 것들이 여럿 있다.
  • 제가 javascript를 열심히 공부하면 서버 개발하는데 도움이 될까요?
  • 제가 java로 네트워크 소켓 프로그래밍은 해봤는데 c#으로 하려면 어떻게 해야 하는 거죠?
  • java 공부를 열심히 하면 취업 할 때 도움 되나요?
  • angularjs를 이용해서 front-end 개발한지 2년 됐습니다. vue.js가 핫하다는데 배우면 이직할 때 도움 되겠죠?
뭔가 다들 중요한 포인트를 놓친 채 프로그래밍 언어 혹은 프레임워크에 의존적인 얘기들만 하고 있다. 더 이상한건 경력이 조금 되는 친구들도 뭔가 다른 영역에 도전하는 걸 많이 두려워 하고, 새로운 걸 도전해 보고 싶기는 한데 생각만 가득한 채 실천도 못한채로 질문을 하는 경우도 많이 있다.

결론 부터 말하면 어떤 특정 프로그래밍 언어나 특정 프레임워크에 의존적인 개발을 하다 보면, 기본적으로 자기가 개발이라는 걸 잘 못하고 있거나 잘 모르고 있다는 전제가 깔려 있을 떄 그런 생각이 들고 질문을 하게 된다. 그리고 이런 걸 질문할 수준이면 자신이 여태까지 개발을 제대로 하고 있었던 건지 되돌아 볼 필요가 있다고 본다.

질문을 하나하나 짚어보면서 분석해 보면

javascript 를 열심히 공부해서 서버를 개발하고 싶다.


우선 javascript를 먼저 배울게 아니라 서버가 하는 역할이 뭐고, 어떤 프로토콜을 써서, 어떤 데이터를 주고 받고, DB에서 데이터를 빠르고 효율적으로 가져와서, 어떤 유용한 결과를 request한 쪽에 줄 건지를 먼저 고민해야 하는게 서버를 개발하는 거라 얘기해 주고 싶다. 그런데 이게 중요하다고 얘기를 해 줘도 자꾸 javascript를 배워야 한다는 생각 먼저 한다. javascript로 된 서버 코드 예제를 분석하고 돌려보고 하면 자기도 서버를 개발할 수 있게 될거라 생각하는 것 같다. 그런데 그런 식으로 하면 처음엔 쉽고 빠르게 되는 것 같아 보여도 결국 내가 처음에 언급한 내용을 되짚어 보면서 구현을 하게 되어 있다. 프로그래밍 언어를 잘 아는게 개발을 잘 하는거라 착각하고 있는 것이다.

java로 네트워크 소켓 프로그래밍은 해봤는데 C#으로는 어떻게 하는 건지 잘 모르겠다.


이 친구는 첫번째 친구보다 더 심각한 상태이다. 최소한 네트워크 프로그래밍을 해야 하는 이유와 네트워크 프로그래밍을 통해 클라이언트와 서버가 뭘 하고 싶어 하는 건지 알고 있다면 프로그래밍 언어를 잘 알고 모르고가 크게 중요하지 않다. 다른 프로그래밍 언어를 경험 안해봐서 그런 것 뿐이지 사실 java나 c#이나 배워서 익히는 수준은 대동소이 하다. 자기가 여태까지 해 왔던 프로그래밍 언어는 익숙하니까 이게 전부인줄 알고 열심히 한건데, 세상에는 같은 동작을 하지만 다양한 다른 프로그래밍 언어로 네트워크 프로그래밍의 비지니스 로직을 구현할 수 있다는 사실을 알아야 한다. 마치 java+spring 프레임워크를 배우는 것 만이 개발자 최종 테크트리의 끝판왕이라 생각하고 다들 미친듯이 java만 한다면 그렇게 java와 spring 프레임워크에 익숙해 지다가 다른 언어 다른 프레임워크를 만나게 됐을 때 뭔가 해볼 생각을 하지 않는다. 그게 문제인 것이다. 다시 생각해 보라 그게 진짜 프로그래머의 모습인지를.

java 공부를 열심히 하면 취업할 때 도움이 되는지


이미 앞에서 설명해서 더 추가로 설명해 보자면, 특정 프로그래밍 언어가 더 취업이 잘 되고 안되고가 정해져 있다면 다들 그 프로그래밍 언어를 하는게 더 득이 되는지 경제학적으로 생각해 보면 된다. 모두 다 취업에 유리한 java만 배웠다고 하면 상대적으로 java를 할 줄 아는 사람이 많아지게 된다는 거고, 대체할 수 있는 프로그래머의 인력 풀도 시장에 많다는 뜻도 된다. "너 아니어도 할 사람은 많다" 라는 말을 들으면 가슴이 아프겠지만 실제로 수요가 그렇게 만들어져 있다면 거기에 탑승한게 잘한건지 아닌지 본인 스스로 판단 가능하다.
그런 시장의 수요가 극단적으로 일어나는 분야를 얘기해 보면 html, css 할 줄 아는 웹 퍼블리셔 분야다. 이 직군에 채용공고를 올리면 하루에 신입 이력서만 30개나 올라온다. 이틀이 지나면 50개가 찬다. 거짓말 아니고 진짜다. 그 중에 CS 전공자는 한명 있을까 말까다. 반대로 OpenCV, Machine Learning 분야에 Python, C++ 할 줄 아는 사람 채용 공고를 올리면 이것도 거짓말 안하고 2~3일에 이력서 1개 올라온다. 그것도 신입으로 올라오는데 그나마 다행인건 CS 전공자가 생각보다 좀 있다는 거 정도다. 상황이 어렇다 보니 취업성공패키지로 취업시켜 준다고 하고 따라하기식 반응형 웹사이트 만들기 몇 달 한거 가지고 취업하려고 하니 취업이 잘 될리가 없다. 남들이 잘 안하는 걸 해보라. 그러면 실력이 형편 없어도 당신을 모셔갈 회사가 있을 가능성이 높다.
또 어떤 기술을 택해서 뭔가 해 봐야 취업이 되는 건 사실이나, 그 기술이 중요한게 아니라 그 기술로 뭘 해봤냐가 더 중요하다는 사실을 잊지 말아야 할 것이다. 로그인 세션 관리, 결제 페이지 연동, 게시판 관리 등등 실제 비니지스 로직을 구현하고 만들어낸 결과물이 뭔지 그 경험을 통해 내가 성취한 업적이 뭔지를 잘 설명하는게 중요한데도 단순히 java라는 프로그래밍 언어를 잘 하면 취업 잘 되냐는 되도 않는 소리를 하면 맥이 빠지는게 사실이다.
또 취업을 하기 위해 java를 열심히 할게 아니라 취업을 하기 위해 java로 프로그래밍 하는 게 적성에 맞고 즐거운지 한번 되돌아 보자. 취업하고 나서 적응 못하고 적성에 안맞아서 괴로운것 보다 내가 정말 하고 싶은게 취업이었는지 IT 기술을 배우고 그걸 익히는게 즐거웠는지를. 이 생각이 들 때가 되면 내가 java라는 기술을 배우고 익혔던게 크게 의미가 없다. 당장 마음이 불안하여 취업을 하는게 목표인 사람들이 생각 못하는 건, 내가 이 직업을 가지고 일하게 되면 즐거울지 아닌지에 대한 것이다.

angularjs를 이용해서 front-end 개발한지 2년 됐습니다. vue.js가 핫하다는데 배우면 이직할 때 도움 되는지


이 친구도 여태까지 웹이라는 걸 잘 생각해보지 않고 회사에서 시키는 대로 열심히 일하다 보니 2년이라는 시간을 보낸 안타까운 케이스인 거다. 이 친구의 신입 시절은 아마 절대 그렇지 않았을 것이다. 회사에서 주어진 업무를 빨리 배우고 익히면 스스로 잘 하게 될거라는 생각에 그냥 열심히 했을 것이다. 심지어 angularjs를 잘 알고 할 줄 아는게 잘못된 점도 아니라는 것이다. vue.js도 사실 해보고 경험해 보면 다른 경험을 할 수 있으니 이직할 때 조금이라도 도움이 되는 건 사실이다. 그런데 프론트엔드라는 것이 angularjs던 vue.js던 뭘 더 잘해야 하느냐가 중요한게 아니다. 프레임워크를 잘 쓴다는게 쓰고 경험해 보면 아는 것이지만, 조금이라도 직관적으로 그리고 조금 편하게 개발해서 생산성이 얼마나 될 것인지, 나중에 수정 및 유지보수가 쉬운지 등등 프레임워크가 가져야 하는 본연의 기능을 잘 훈련하는 것 즉 방법적인 것에 불과하다는 것이다.
그러니까 웹 프론트엔드 개발을 하는데 중요한게 어떤 프레임워크를 잘 쓸줄 아느냐가 아니라 어떤 목적을 가진 사이트를 개발할 거고 거기에 맞게 뭘 적용해서 해야 하느냐가 더 중요하다는 얘기다. 그런데 이미 angularjs를 통해서 웹에 대한 이해 프론트엔드에 대한 이해가 충분히 잡혀 있다면 다른 유사한 프론트엔드 프레임워크가 추구하는 가치가 뭔지, 특징이 뭔지 정도는 찾아보면 알 수 있는 건데도, 또 배워야 한다는 생각을 한다는게 잘못됐다는 것이다. 심지어 언어도 javascript로 같은데도 말이다.
닭 잡는데 소잡는 칼 쓴다는 논어에 얘기도 있듯이 웹 프론트엔드가 하는게 뭔지 한번이라도 조금 더 생각해 보면 angularjs를 잘 쓰냐 vue.js를 잘 쓰냐가 크게 중요하지 않을 수 있다는 뜻이다. 오히려 이런 프레임워크를 쓰는 방법을 익히는 것 보다 각각의 프레임워크가 어떤 작업을 하는데 효과적이고 효율적인지 알아보고 적용할 수 있는 안목을 키우는게 더 중요하다. 그런 안목을 키우는 차원에서 토이 프로젝트로 이것 저것 실험적인걸 해보는 수준이면 크게 나쁘지 않으며, 거기서 다른 프론트엔드 프레임워크와의 차이점을 발견할 수준이면 더 없이 좋을 것이다.
다시 정리하자면 이직할 때 도움이 되는게 vue.js 쓰는 법을 아는게 중요한 것이 아니라 현재 써 왔던 angularjs와 어떤 차이점이 있고 내가 뭘 만드느냐에 따라 어떤 프레임워크를 선택하느냐의 기준을 얘기할 수 있으면 충분히 도움이 될 것이다.

결론


프로그래밍을 오래 하다 보면 점점 특정 프로그래밍 언어 의존적, 프레임워크 의존적, 더 나아가서는 툴 의존적인 경력이 쌓이게 된다. 그런데 그 기간이 길어지면 프로그래밍 능력, 생각하는 능력, 발전적인 능력이 쌓인다기 보다는 일하는 방법에 대한 훈련과 반복되는 익숙함에 시간을 보내게 되어 있다. 그리고 시간이 가면서 스스로 내가 잘 하는지 못하는지 불안해 지지만 쉽게 자신의 손에 익숙한 언어, 프레임워크, 툴을 버릴 자신이 없어진다. 물론 비지니스 로직 처리 하면서 시켜서 해야 하는 일 외에 더 좋은 방법에 대해 고민하고 구현하고 정리해 봤다면 프로그래밍 능력이 조금 좋아질 가능성이 높긴 한데, 대부분 회사 일 하느라 바쁘다 보니 생각은 있어도 실천하기가 쉽지가 않다. 이 상태에서 또 다른 프로그래밍 언어를 배우는게 프로그래밍 능력을 향상시키는 방법이 아님에도 불구하고 다른 프로그래밍 언어를 배우는 것이 나의 개발 커리어도 쌓고 실력이 향상될 것이라고 굳게 믿고 있다. 물론 방법을 어떻게 하느냐에 따라 실력을 쌓을 수 있냐 아니냐가 다를 수 있지만, 그냥 튜토리얼 실행해 보기 책 따라해보기 정도로 깔짝대는 수준으로는 어림없다는 것도 알아야 한다.

기술적으로 프로그래밍의 실체를 접한 친구들은 "실무 일을 열심히 하는 것" = "프로그래밍 실력 향상" 이라는 착각을 하는데, 왜 이런 문제가 발생하는지 진지하게 고민해 보도록 하자. 그리고 이 때가 되면 기술 적인 배움 보다는 조금 더 학문적인 수준에서 접근을 해야 할 필요가 있다. 학문적인 것이라 해서 논문을 쓸 수준의 연구를 하라는 뜻이 아니라 프로그래밍 이외의 것들에 대해 접해보고 생각할 시간을 가져야 한다는 뜻이다. 그렇게 해서 프로그래밍이라는게 어떤 것이고 그것을 통해 어떤 결과를 얻고 싶은 것이며 그 과정 중에 왜 이렇게 코드를 짜야 하는지에 대한 이해를 해야 할 때가 실력이 높아질 수 있는 때이다. 이제 프로그래밍이라는 행위를 왜 하는지, 소프트웨어가 추구하고자 하는 본질이 무엇인지를 조금 더 생각해보자. 여태까지 해 왔던 프로그래밍 언어 의존적, 프레임워크 의존적인 개발을 해 왔던 생각이 많이 달라질 것이다.

Tuesday, September 11, 2018

프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절

----

그렇게 프로그래밍 하는 법을 기억은 하고 있지만 실제로 뭔가 해본 게 없는 체 대학에 입학하게 됐다.
진로 탐색을 하다 보니 컴퓨터공학과가 있다는 사실을 알았고, 게임 잡지나 컴퓨터 잡지를 둘러 봐도 프로그래밍을 하려면 컴퓨터공학과를 나와야 한다는 얘기를 접하다 보니 수능 점수에 맞춰서 컴퓨터공학과가 있는 대학으로 알아보고 진학하게 됐다.

사실은 프로그래밍 하는 거에는 크게 흥미가 있진 않았다. 초등학교때 학원 다니면서 배웠던 걸로 화면에 그림 그리고 적절한 로직을 짜면 되는 거 정도는 해봤기에 그런 것도 있었다. 사실 BASIC에서 짰던 허접한 게임 보다는 중고등학교 시절 열심히 그리고 재밌게 했던 화려한 그래픽의 컴퓨터 게임들을 실제로 만들 줄 아는 게임 프로그래머가 되어야 겠다는 생각을 해서 대학 진학을 한게 가장 큰 이유였다.

여러 학교에 지원했는데 최종적으로 한성대학교에 합격하게 됐고, 아빠 엄마도 나한테 과외 시켜준 적 한번 없고 학원도 제대로 보내주지도 못했는데 서울에 있는 4년제 대학교에 합격했다고 하니 좋아하셨던 것 같다. 난 이때 한성대학교가 서울에 있다는 사실을 처음 알았지만 학교 보다는 뭘 배우러 가냐를 더 비중을 뒀기에 학교 간판에 대해서는 신경쓰지는 않았다. 그러니까 좋은 학교를 먼저 선택한 후에 아무 과나 들어가는 친구들과 나는 목적의식이 다르고 내가 선택한 길이 옳다고 생각을 했다. 그리고 사실 수능 점수로만 따져서 갔다고 했을 때는 조금 더 좋은 학교에 갈 수도 있었다. 입학 후에도 동기들끼리 수능 점수 얘기할 때도 내가 과에서 수능 점수로만 Top5 안에 들었을 정도였으니까. 그때는 대학부심, 과부심 이런게 중요하다고 생각했고 조금 더 좋은 대학에 진학 못한게 아쉽다고 생각할 때도 있었는데, 지금 생각해 보면 조금 더 좋은 대학을 가는게 무슨 의미가 있고, 내가 남들보다 조금 더 잘나고 우위에 있다는 생각이 지금 다시 회고해 봐도 쓸데없는 생각이었다고 본다.

컴퓨터 공학과 라는 곳에 입학을 하다 보니 입학 전에 새 컴퓨터를 장만해야 공부할 수 있다고 엄마한테 얘기했다. 사실 중학교때 쓰던 286 PC는 초등학교 때 컴퓨터학원 다녔을 때 배운거 써먹고 공부하라고 사준 거였다면, 이번에 사준 컴퓨터는 정말로 대학에서 공부하는데 필요한 거라 목적성이 있어 얻게 된 컴퓨터였다. 6년간 잘 써왔던 286 PC에서 그 당시 인기 있던 586 PC로 업그레이드를 했고, 바로 그 PC에서 돌렸던 게임이 286 PC에서 돌렸던 것 보다 너무 잘 돌아서 좋았던 기억도 있다.

그렇게 대학에 가서 컴퓨터 공학과에서 배우는 과목들을 보니, 프로그래밍 수업은 C언어 배우는거 하나 정도였고 나머지는 다 이론적인 거나 수학 관련된 과목들이었다. 논리 회로, 공업 수학, Unix 시스템 이해, 선형 대수 등등의 과목이 있었는데, 수학은 고등학교때 잘 배웠던거 복습 반, 새롭게 배우는거 반 이정도였고 Unix라는 것도 처음 봐서 그때 까지 쓰던 DOS의 명령어들과 다른 것에 흥미가 있기도 했다.

<Unix console window 화면, 지금은 이런 화면으로 컴퓨터를 쓸 일이 거의 없지만 내가 처음에 BASIC으로 프로그래밍 했을 때만 하더라도 이런 화면으로만 썼었다. 지금도 Windows power shell로 unix나 linux system에 ssh로 접속하면 콘솔 화면으로 신나게(?) 컴퓨터를 사용할 수 있다. 문서 편집, 프로그래밍, 심지어 웹 브라우징 까지 모두 cmd로 가능하다!
출처: Unix wikipedia>

난 솔직히 같이 입학한 친구들 중에 프로그래밍에 대해 전혀 모르고 온 친구가 있다는 사실에 많이 놀랐다. 그러니까 나는 컴퓨터공학과에서 프로그래밍을 한다는 거 쯤은 알고 들어왔는데 동기들 중에는 컴퓨터 활용하는 법을 배우러 오는 곳이라고 잘못 이해한 친구도 있었고, 컴퓨터 타자 연습하는거 좋아해서 온 친구, 컴퓨터 조립하는 걸 좋아해서 들어온 친구, 컴퓨터라는 물건을 알고 있긴 했지만 한번도 써본 적도 없는 친구 등등 다양했다. 내가 그나마 조금 나은 케이스였던 것 같다고 그 당시 생각했지만 지금 생각해 보면 역시 부질없는 생각이었다.

가장 중요한 C언어 얘기를 해보면, 수업 시간에 코딩하고 실행하고 결과를 보는 실습을 하는데 그걸 따라가는 친구들이 몇 안됐었다. BASIC 아는 친구는 좀 있었는데, C는 나도 처음이었고 거의 대부분 C는 모른체 그렇게 수업을 들었다. 나도 변수, 반복문, 배열 까지는 BASIC과 큰 차이는 없어 보여 곧잘 따라하고 옆 자리 친구들에게 자랑도 했는데 지금 생각해 보니 그게 뭐 대단한거 했다고 자랑까지 했는지 조금은 부끄럽다.

게다가 C언어 말고 컴퓨터 쓰는 법 자체를 모르는 친구들이 꽤 되다 보니 그런 것도 옆에서 알려주면서 했던 기억이 난다. DOS와 Unix나 명령어는 다르지만 하려고 하는 목적은 같기에 교수님이 알려준 명령어를 잊지 않고 잘 기억했다가 실습시간만 되면 이것 저것 해보는게 재밌었고, 교수님이 뒤에서 지켜보다가 Unix 명령어를 막 쳐가면서 코딩도 하고 이것 저것 하는 모습을 보더니 눈썰미가 있는 학생이라면서 칭찬을 들었던 기억도 있다.

<Unix 실습 시간 외에는 Dos 환경에서 했기 때문에 프로그래밍은 Turbo C를 띄워서 했었다. 지금이야 워낙 IDE가 잘 되어 있어서 마음만 먹으면 얼마든지 쉽게 프로그래밍을 하고 배울 수 있다.
출처: turbo-c.soft32.com>

하지만 자랑질은 거기까지였고 역시나 포인터라는 이해하기 어려운 부분에 들어가면서 부터 그 후에 어떻게 코딩했는지 잘 모를 정도로 공부 안하고 포기했던 것 같다.

지금 대학생들은 안그러겠지만 나 때만 해도 공부하는데 집중한 친구들 보다는 놀고, 술마시고, 연애하는 걸로 입시 스트레스를 푸는 친구들이 많던 때였다. 나도 동아리 활동도 하고 과 친구들과 어울리고 하면서 술도 많이 마시고 많이 놀았었다. 얼마나 놀고 공부를 안했는지 학점 관리가 제대로 안될 지경이었고 F 학점도 있었다.

다시 기억해 봐도 대학 입학하고 첫 해에는 공부를 제대로 한 기억이 거의 없다. 그나마 있는 기억은 내가 남들보다 조금 더 많이 안다고 잘난척 한거 정도다. 결정적으로 그해 말 IMF 사태가 일어나면서 회사들이 줄줄이 부도 파산이 나고, 이제 회사 입사하려는 대학 졸업생 부터 20대 모든 남자들이 IMF 외환위기를 피해 모두 군대에 몰려 있다는 소식이 계속 들려왔다.

Thursday, August 30, 2018

성적 없는 성적표, 그리고 멘토링의 가치

지난 주 성적 없는 성적표라는 책을 읽었다.

성적 없는 성적표
성적 없는 성적표
『성적 없는 성적표』

『4차 산업혁명, 교육이 희망이다』를 펴낸 류태호 교수의 두 번째 저서다. 이전 저서가 4차 산업혁명 시대의 교육을 개괄한 개론이었다면, 『성적 없는 성적표』는 그 연장선에서 역량 중심 교육을 깊이 파고드는 일종의 각론이다. 저자는 먼저 역량 중심 성적표 도입을 준비하는 미국 교육계의 최근 동향을 자세히 설명한다. 그러고는 공교육 시스템의 기원과 미래 교육의 방향을 소개하면서 역량 중심 교육이 전개될 수밖에 없는 이유를 제시한다. 마지막으로 최신 기술을 활용한 교육 플랫폼, 빅데이터에 기반한...
Yes24 출처의 책 이미지와 내용은 위 부분을 참고하면 된다.

내가 지금부터 얘기 하려는 건 이 책에서 언급한 중요 내용이 내가 멘토링 활동을 하고 있는 가치와 일치한다는 점이다.

이 책의 내용은 4차 산업혁명에 대한 얘기와 그에 맞게 교육이 이루어 지려면 역량 중심의 교육이 이루어져야 한다는 주장이 주를 이룬다. 사실 이 책을 읽기 전에 같은 저자의 책 <4차 산업혁명, 교육이 희망이다>를 보고 개요를 파악해야 한다. 물론 나도 이 책을 먼저 읽은 후에 성적 없는 성적표를 읽었다.

여기서 언급하는 역량 중심 교육이 이루어 지려면 여섯 가지의 핵심 내용이 이루어져야 한다는 얘기를 하는데, 사실 책 읽다가 내가 하고 있는 활동의 가치와 너무 부합해서 놀라웠다.

게다가 나도 기존의 교육 방식 말고 프로그래머가 되려는 후배들에게 어떻게 하면 도움이 될 수 있을까를 몇 년 간 시행착오를 겪으며 활동을 해 왔다. 그리고 지금 하는 멘토링 과정에 이르러서야 뭔가 제대로 된 걸 하고 있다는 생각이 들었는데, 그 내용이 류태호 교수의 책에 고스란히 담겨져 있어서 사실 내가 제대로 하고 있구나 하는 느낌이 많이 든 건 사실이다.

역량 중심 교육 여섯 가지 핵심 내용

  • 학습자 중심
  • 과정 위주 평가
  • 수업의 개인화
  • 학습 시간의 자율화
  • 역량 평가의 공정성
  • 연속적인 역량 관리
여기서 역량 평가의 공정성을 제외한 다섯 가지 항목이 내가 하고 있는 멘토링 과정과 맞기에 그 내용을 내 멘토링 소개 페이지에도 업데이트를 했다.


자세한 내용은 위 링크 페이지에 적었기 때문에 한번 보면 좋을 것이다.

어쨌든 이 책을 읽고 느낀 바가 있어, 지금 하고 있는 활동을 꾸준히 그리고 부지런히 할 계획이다.

Tuesday, August 28, 2018

Interview review 2017 #5

Interview review 2017
1. 원격 지원 및 보안 솔루션 제품 개발 회사
2. Unity를 이용한 인테리어 디자인 앱 개발 회사
3. 의료 분야 외국계 회사
4. AR/VR 교육 컨텐츠 앱 개발 회사

-------

5. 쇼핑몰 회사

사실 쇼핑몰로 적었지만 타이틀만 살짝 바꾸면 어느 회사인지 알 수 있을 정도로 손가락 안에 꼽을 수 있는 회사들 중에 하나라는 걸 알 수 있기에 그냥 쇼핑몰이라고 부르겠다.

이 회사는 헤드헌터를 통해 면접을 진행했는데, 헤드헌터한테 먼저 연락온 건 아니고 내가 먼저 job description을 보고 연락을 했고 메일을 주고 받다 보니 그 회사인걸 알게 된 케이스이다.

사실 job description이 꽤나 마음에 들었는데, 이유는 쇼핑몰인데도 내가 주력으로 사용하는 C# 언어를 사용하는데다가 특이하게 xamarin 플랫폼을 사용해서 앱을 개발한다는 내용이 있었기에 호기심이 생겼다. 그리고 제일 중요한건 이 회사에 새로 나온 기술을 사용하는 팀이라면 기존에 있던 팀과 뭔가 다른 조그만 팀일 것 같은 느낌도 있어서 지원하게 됐다.

이력서 역시 회사 포맷에 맞는 이력서를 다시 써서 낼 법도 했는데, 그냥 내 자유 이력서 양식 그대로 진행한 점이 마음에 들었다. 하지만 면접날짜가 잡히기 까지 꽤 오랜 시간을 기다려야 했다.

드디어 날짜가 잡혔고, 그 때는 전 직장을 나와서 프리랜서 생활을 할 때였기 때문에 면접 시간은 편한 시간으로 잡아달라고 해서 오후 3시에 봤다.

회사 건물 1층 입구에서 대기하고 연락을 기다리고 있었는데, 나 말고도 면접을 보는 사람이 몇 있었고 로비에 대기 테이블이 면접자 대기 전용 공간인 것 같은 느낌이었다. 윗층에서 에스컬레이터를 타고 직원인 사람이 한 사람씩 내려와서 면접자를 찾고 같이 올라가는 식이었는데, 나도 곧 이름이 불렸고 면접 안내를 받았다.

6명이 앉으면 꽉 차는 작은 회의실에 대기하고 있으라 해서 몇 분 있었더니 손 코딩 테스트를 진행한다며 종이랑 연필을 줬다. 이건 헤드헌터에게 면접 안내 받을 때도 있던 내용이라 무슨 문제인지 봤더니 신입 개발자 뽑을 때 볼 법한 string 관련 문제 4개 정도가 주어졌다. 아주 어려운건 아니었는데 코드를 적을 수 있냐 없냐 정도를 테스트 한 것 같았다. 그리고 실제 면접 진행 때 코딩 테스트한 수준과 평가 방법에 대해 물어봤는데 어처구니 없는 대답을 들었다. 사실 이 코딩 테스트는 검토하지 않는다고 하길래 왜 그러냐고 다시 물었더니 그냥 절차상 그렇다는 대답을 한걸 보고 뭔가 이상하다는 생각이 많이 들었다. 내가 생각했던 그냥 코드를 적을 수 있냐 없냐 수준으로 코딩 테스트를 한 듯 보였다.

한 30분 정도 코딩 테스트를 진행하고 면접관 두 명과 쓸데없는 자기소개와 경력 위주의 한 일을 얘기하고 업무와 기술 관련된 질문을 하고 답변 하는 식으로 진행했다. 일단 면접관 두 명 중 한명의 태도가 상당히 안좋았는데 이유는 맥북을 들고 와서 계속 뭔가 타이핑만 하고 면접 진행에 집중을 잘 안한다는 점이었다. 그런데 또 웃긴건 면접 기록만 적는 역할만 했다기에는 직무와 관련된 적절한 질문을 하면서 진행했기에 안좋게 보인건 사실이다.

여기서 면접관들 태도 중에 하나 지적해 보자면 사실 면접은 모르는 사람들 끼리 처음 만나는 자리이기 때문에 서로에 대한 관심과 대화에 중심을 둬야 한다고 생각한다. 가끔 노트북PC를 들고와 화면을 쳐다보면서 면접을 진행하는 면접관을 보면 뭔가 잘못돼도 한참 잘못됐다는 느낌이 든다. 면접 평가 같은 건 면접 끝나고 해도 충분하고 노트북에 뭔가를 적을 꺼면 그먄 종이에 펜으로 적어도 되는데 굳이 노트북 PC까지 들고와서 면접에 제대로 집중하지 못하는 모습을 보면 안좋아 보인다. 사실 종이에 펜으로 뭔가 적는 행위도 눈에 거슬리긴 하다.

면접 분위기는 좋다고도 할 수 없고 딱히 나쁘다고 할 수는 없었는데, 경력 관련된 질문은 그럭저럭 괜찮게 넘어갔는데 기술 질문에서 뭔가 포인트를 잘못 짚고 있다는 느낌을 많이 받았다. 그러니까 면접관이 개발자인 것 같긴 한데 기술 질문이 "내가 이정도 알고 있는데, 너는 어느 정도 알고 있냐?"의 느낌으로 진행됐었다. 내가 몰라서 대답 못한 거면 그럴 수도 있다고 넘어갈 수 있지만, 뭔가 그 질문이 중요한건 아닌데도 약간 집요하게 물어보는게 그리 좋아보이진 않았다. 그리고 대답을 잘 해줘도 "뭐 대답이 그정도야?"의 뉘앙스여서 기술 질문의 깊이가 있다면 또 모를까 이 시점에서 그 동안 보여줬던 이 회사의 이미지가 별로라는 느낌을 많이 받았다.

그리고 사람을 뽑는데 필요한 기술 관련된 업무를 물어봤는데, 예상대로 주력 앱은 아니고 서브로 만들어서 지원하려는 앱을 개발하는데 필요한 기술이라고 해서 관심이 있긴 했으나 사실 여기까지 오다 보니 관심이 없어져서 그냥 면접 진행을 끝냈다.

사실 또 실망한 이유 중 하나가 있는데, 퇴사 이유에 대해 집착하지 않았으면 괜찮았을 수도 있었다. 면접관들이 왜 그런거에 관심이 많은지 모르겠지만 이런 질문 받고 얘기하다 보면 회사 다니다 나오는게 정말 죄를 짓는 것 같은 느낌을 많이 받는다. 이력서 상에 특별히 언급한 이유가 궁금하지 않다면 물어볼 거 없어서 퇴사 이유가 뭐냐는 질문은 안 하는게 좋을 것 같다.

면접 끝나고 헤드헌터와도 통화를 했는데, 사실대로 얘기해 줬다. 이 사람들이 면접을 대충 본다는 느낌을 많이 받았고, job description과 달리 기술 질문의 포인트가 뭔가 이상하다. 어쨌든 합격은 안될 것 같은데, 나도 좋은 인상은 못받았다고.

작은 회사라면 모를까 어느 정도 인지도도 있고 큰 회사에다가 회사 문화가 좋다는 얘기까지 들었던 나로서는 이 회사에서 진행했던 면접이 썩 좋지는 않았다.

Tuesday, July 31, 2018

Interview review 2017 #4

Interview review 2017
1. 원격 지원 및 보안 솔루션 제품 개발 회사
2. Unity를 이용한 인테리어 디자인 앱 개발 회사
3. 의료 분야 외국계 회사

-------

4. AR/VR 교육 컨텐츠 앱 개발 회사

음 이 회사도 타이틀만으로도 검색하면 찾을 수 있고, 내 글 내용 중 특이점이 있기 때문에 찾기는 더 쉬울 것 같다. 하지만, 회사 이름을 언급하지는 않을 것이다.

이직 전 Unity 개발 경력이 2년이 되다 보니 아무래도 Unity 관련 회사를 찾아보게 되는 일이 더 많아지게 되었다. 두번째 회사도 그랬지만 게임 분야는 채용 공고가 엄청나게 많지만 게임 분야가 아닌 쪽은 검색해 보면 남는 회사가 손에 잡힐 듯이 필터링 되기 때문에 이 회사도 그런 식으로 지원을 하게 됐다.

우선 스타트업 회사인데 자유로운 분위기와 AR/VR 교육용 컨텐츠 앱을 만드는데 투자도 받고 있고 해서 끌리게 되었다. 아무래도 중견 기업에만 있다가 스타트업에 맛을 들이다 보니 큰 회사가 가기 싫어진 것도 있고, 작은 팀에서 일하는 재미가 있기 때문에 역시 메일로 직접 연락해서 내 소개, 지원 동기, 이력서 링크 등을 보냈다.

하루도 안돼 내 연락처를 알려달라는 회신이 왔고, 통화를 해서 실제 면접 날자를 잡았다. 그쪽에서 무슨 무슨 요일에 외근이 있어서 안되고 금요일날 된다고 했는데, 그 금요일이 세번째 회사 면접보는 날과 겹쳐서 조금 시간 조정을 해서 오후 시간으로 맞췄다.

정자역에서 세번째 회사 면접을 끝내고 다시 지하철을 타고 긴 여정을 했다. 회사는 강북의 어느 대학교 부속 건물에 있는 사무실이었다. 지하철 역에서 살짝 먼 느낌이었는데, 근처에 대학가가 있어서 구경 좀 하고 커피도 마시면서 시간을 보내다가 면접 시간에 맞춰 들어갔다.

이 회사의 CEO는 여자분인데, 아주 젊은 분이었다. 활발한 성격인 것 같아 보였고 무엇보다 내가 하는 얘기에 관심을 많이 가졌다. 그리고 좋았던 건 본인 소개 및 면접관들 소개를 차례로 자세히 했고 무슨 일을 하는지 회사소개 프리젠테이션 까지 했다는 것이다. 물론 그 프리젠테이션은 다른 회사에 가서 하는 영업용 회사소개 내용인데, 보통은 면접보러 온 사람한테 그 정도로 친절한 소개를 하지 않는다는 점에서 본인들이 하는 일에 상당한 자부심을 가진 회사일 거라는 느낌이 들었다.

얘기를 하다 보니 영어 교육용 컨텐츠 앱 개발을 하고 있고 모 대기업과 함께 학교에 시범적으로 운영해서 서비스 할 거라는 얘기를 했다. 나 역시 개발쪽에 온라인 강의를 하고 있고 신입이나 학생들에게 프로그래밍을 알려주는 활동을 하고 있다고 하니, 교육쪽으로 잘 맞을 것 같다고 하면서 아주 좋아했고 나도 그쪽으로 계속 사업이 진행된다면 좋을 것 같다고 얘기를 했다. 불과 몇 시간 전까지만 해도 압박 면접 진행해서 자신감 없게 얘기했던 부분을 이 스타트업 회사에서는 아주 자신감 있게 얘기하고 호응도 이끌어냈다.

면접 진행하다 보니 문제는 개발자가 한명 뿐이었다는 건데, 그나마 경력이 좀 있는 분이 개발을 맡고 있고 개발 요소 보다는 컨텐츠 요소가 많아서 디자이너들 단기 알바를 많이 쓰고 있다는 얘기도 했다. 내가 개발 쪽이다 보니 인력이 더 필요한건 맞냐고 물어보니 앞으로 할 일이 많아서 우리 개발자 한분과 같이 진행하면 좋을 거라고 얘기했다.

상당히 좋은 분위기에서 면접을 진행했고, 바로 CEO와 단독으로 연봉 문제를 얘기했다. 사실 스타트업 회사에서의 경력자에게 연봉이란 민감한 주제라 바로 단도직입적으로 얘기했다. 내가 비록 경력은 좀 되지만 돈을 많이 받으려고 연락해서 지원한 건 아니다. 최소 연봉의 기준으로 생각한 연봉을 얘기했다. 사실 그 CEO가 연봉을 많이 못준다는 밑밥을 깔고 한참 얘기하긴 했지만 결국 내 하한선의 연봉을 최대한(?) 맞춰 보는 걸로 얘기를 했다.

지금 와서 다시 생각해 보니 모든 면접에서 연봉 문제를 꺼낼떄 뭔가 조심스럽게 얘기하면서 경력자에게 줄 연봉이 많이 없다는 얘기를 들으면, 그냥 딜이 안된 거구나 생각해도 좋을 만큼 스타트업에는 정말 돈이 없다는 걸 알았다. 사실 돈은 줄 수 있을 수도 있는데, 얼마나 일을 잘 그리고 많이 할지 판단이 안서기 때문에 계속해서 능력과 어느 정도 연차는 되는데 돈은 조금 줘도 되는 개발자를 계속 찾고 있는 것 때문이라고 본다.

면접을 잘 보고 나와서 이 회사에 됐으면 좋겠다는 생각을 했다. 다시 재미있게 일할 수 있다면 연봉은 어느정도 감수해도 상관 없으니까. 그리고 대기업이 원하는 Unity 개발 말고 우리가 하고 싶은 Unity 개발을 할 수 있다는 점에서 상당히 기대를 했다.

하지만 1주일 후 메일 회신이 왔는데, 함께 할 수 없어서 아쉽다는 내용으로 이 회사와의 인연은 여기까지였다.

Friday, July 20, 2018

Interview review 2017 #3

Interview review 2017
1. 원격 지원 및 보안 솔루션 제품 개발 회사
2. Unity를 이용한 인테리어 디자인 앱 개발 회사

---

3. 의료 분야 외국계 회사

여긴 job search를 하다가 기술 스펙이 window 응용 프로그램 개발이어서 한번 지원해 보기로 했다. 이 회사가 외국계다 보니 지원 사이트가 따로 있었고, 거기에 여느 대기업 지원 사이트와 크게 다르지 않는 수 많은 입력 폼을 입력 하고 이력서를 첨부해서 지원을 했다.

서류 심사 통과 후 사전 인적성검사를 해야 한다면서 메일을 보내 왔는데, 1시간 30분 동안이나 해야 하고 문제 수준도 수능 봤을 때 난이도 뺨칠 정도로 어려움이 있었다. 지금 생각해 보니 외국계던 대기업이던 입사 서류 지원 부터 시험 보는거 까지 쉬운게 없는 것 같다. 신입이던 경력이던 입사 지원 프로세스는 정형화 되어 있다는 것도 불만 요소인데, 신입이야 워낙 지원하는 사람이 많으니 필터링 차원에서 한다 쳐도, 경력은 왜 똑같이 하는 건지 잘 모르겠다. 경력에게 수능 문제 풀게 하는게 크게 의미가 있는건지 대기업 외국계 기업들은 알고 진행하는 것일까?

인터뷰는 분당 정자역 근처에 있는 회사로 회사들이 있는 큰 건물에 어느 층에 있는 회사에서 진행했다. 다니던 회사가 판교쪽이다 보니 신분당선 한 정거장 더 가는 수준이라 거리는 크게 문제되지 않았다. 인터뷰 시간이 애매했는데 12시 40분에 오라는 거 정도였다.

인터뷰는 회사 사무실은 아니고 회의실 전용 층인 듯한 곳에서 안내를 받고 기다렸다가 총 세명의 면접관들과 인터뷰를 진행됐다. 처음 부터 다짜고짜 영어로 자기소개 하라고 하길래 못한다고 하니까 알았다면서 바로 다음 질문으로 이어졌다. 이미 영어 안된다고 한 순간 부터 표정이 안좋았는데 외국계니까 영어를 요구하는 건 당연하다는 생각이 들면서도, 난 여태까지 영어 공부를 왜 안했나에 대한 후회도 좀 들긴 했다. 영어는 일단 건너 뛰고 바로 이력서 상에 기술된 프로젝트 위주로 어떤 기술을 썼는지에 대한 질문부터 시작했고, 무난하게 질문/답변을 진행했다.

그리고 내가 PM, PL 경력이 있다 보니 시스템 설계 경험에 대해 궁금해 했는데, 진행했던 프로젝트 중에 하나를 선정해서 architecture diagram을 그려보라고 시키기 까지 했다. 음, 내가 카카오 면접 이후로 화이트 보드에 뭔가 그려서 설명한건 이번이 두번째지만 사실 이런거 시킬 때는 질문/답변이 계속 오가는 상태로 진행해야 맞다고 본다. 그런데 면접관들은 내 질문에는 그냥 시큰둥 하면서 그림 그려서 설명을 어떻게 해 나가는지를 더 듣고 싶어 했다. 뭔가 일방적이라는 느낌이 강했다. 내가 뭘 잘 알고 있어서 맘에 드는지, 내가 잘 모르거나 틀린 부분이 있어서 맘에 안드는지 관심이 없는 것 같았다.

삼성전자 프로젝트 할 때 문제점과 해결 방법에 대한 설명을 하긴 했지만, 뭔가 좋아하는 눈치는 아니었다. 뭐 니가 그런 일도 했었구나 정도의 느낌. 내가 설명을 잘 못하는 사람이 아닌데도, 내 스스로 설명을 잘 하는지 의심하게 됐는데, 사실 면접관들이 이런 걸 노리고 시킨게 아닌가 하는 생각도 든다.

조금 짜증났던 화이트 보드 그림그리기 + 설명은 그럭저럭 한 것 같은데, 갑자기 A4 용지에 1~30번 까지의 문제가 적혀 있는 종이를 SSG(쓱) 주더니 풀어보라고 한 것도 아니고 아는 대로 설명해 보라고 시켰다.

대략 1~10번은 프로그래밍 개념, OS, 네트워크 등 기본 지식을 묻는 문제였고 11번 이후로는 선형대수, 수학, 알고리즘 관련된 문제였다. 종이에 적힌 문제를 보니 풀 수 없는 문제가 더 많다는 걸 알수 있었다.

뭐 아는 문제에 대한 설명을 할 떄도 역시 내가 잘 하나 틀렸나에 관심은 없고 그냥 설명만 듣고 "네", "알겠습니다" 이정도의 대답만 하는 수준이라 좀 건방지다고 해야 할까? 면접관들이 얼마나 잘난지 잘 모르겠지만 면접 보러 온 사람에 대한 태도가 상당히 좋지 않음을 많이 느낄 수 있었다.

그리고 사실 자신있는 oop에서의 인터페이스, 상속, 추상 클래스 이런 문제도 있길래 설명하면서 이래 저래 눈치를 살펴 봤는데, 역시 "맞다", "아니다"에 대한 대답은 없고 "그런가요?" "...맞나요?" 라고 끊임없이 질문만 해댔다.

나중에 면접 끝나고 긴가민가 해서 검색했는데, 분명 맞게 설명한 건데도 괜히 의심하는 질문은 왜한거지? 라는 짜증만 밀려 들어왔다. 나보다 잘 아는지 모르는지도 잘 모르겠고 그냥 의문형 질문, 그리고 내가 하는 질문에는 까칠한 대답 뿐.

또 퇴사 이유에 대해 집요하게 질문하고 압박이 들어오는데 압박 면접 해보면 알지만 당하는 사람은 엄청 무기력해 지고 피곤해 진다. 그런데 일반적인 질문도 아니고 퇴사 이유에 대한 압박이다 보니 내가 전 회사에서 퇴사를 하지 말았어야 하는 자괴감이 절로 드는 짜증나는 질문을 해대는데, 압박 면접 빨리 사라져야 하는 악습이라고 본다.

그리고 사실 이쯤 되니까 나도 상당히 주늑 들게 되었다. 인터뷰의 기본 자세는 자신감인데, 정말 밝고 명랑하고 자신감 있는 사람도 이 세사람들과 인터뷰 진행하면 정말로 주늑들 수 밖에 없을 것 같다. 대답이 죄다 기운 빠지는 대답들에다가, 자신 있게 설명하면서도 나 자신을 의심하게 하는 싸가지 없는 의문형 질문들. 퇴사 이유에 대한 쓸데 없는 압박 질문 정말 최악이었다.

마지막으로 할말 있냐고 했을 때 내가 준비한 얘기를 했다. 지금 네이버 까페에서 C# 코드 리뷰를 진행하고 있다. 개발이라는게 나 혼자 잘 하는게 답이 아니고, 잘 모르는 사람들도 잘 할 수 있게 도와주고 같이 개발하는게 맞다고 생각해서 몇 개월 째 열심히 활동하고 있다. 이런 얘기를 자신감 없이 얘기했다. 분명 자신있고 자랑스러워 해야 할 얘기인데, 이런 인터뷰를 진행하고 나니 기운이 빠져서 뭔 얘기를 더 하고 싶지 않은 것도 있었다.

정말 어이 없는 건, 처음 부터 나한테 관심은 있었는지 여부이다. 코드 리뷰 얘기가 끝나니까 "네, 알겠습니다."가 전부였다. 어떤 사람을 뽑고 싶은지 뭐에 관심있는지 도통 알 수 없는 면접관들이었다. 다시 생각해 보니 면접관들이 어느 부서 사람이고 뭘 하는 사람들인지 소개도 안하고 들어오자 마자 영어로 자기소개 해보라고 시킨게 떠올랐다. 또 짜증난다.

이날 오후에 또 다른 회사에 지원해서 인터뷰 진행하기로 했는데, 시작이 영 좋지 않았다. 여긴 합격 안될 걸 직감적으로 알 수 있었고, 또 합격 됐다고 하더라도 그런 면접관들이 있는 팀과 같이 일하고 싶은 마음이 들지 않는다.

면접 결과도 엄청 늦은 시간인 3주나 걸려서 메일로 왔는데, 영어로 되어 있었고 내용도 두괄식도 아니고 처음부터 끝까지 다 읽고 문맥을 파악해야 떨어졌는지 붙었는지 알 수 있게 적혀 있었다. 마지막 메일 까지도 짜증이 난다.

Thursday, June 21, 2018

Interview review 2017 #2

Interview review 2017
1. 원격 지원 및 보안 솔루션 제품 개발 회사

---

2. Unity를 이용한 인테리어 디자인 앱 개발 회사

왠지 이렇게 쓰면 이 회사의 범위가 좁혀지기 때문에 맘 먹고 조금 검색해 보면 어느 회사인지 알 수 있을 것이다.

이 회사를 지원하게 된 이유는 게임 개발이 아닌 유니티 경험이 2년 되어 가는 시점에서, 게임 분야가 아닌 유니티 경험자를 원하는 회사를 찾다가 지원한 것이다.
사실 그런 회사를 찾기는 쉽지 않다. 열에 아홉은 유니티 쓴다 그러면 전부 게임 개발이니까. 이 회사는 사람인이나 잡코리아 같은 사이트에 채용 공고가 등록된 건 아니었고 로켓펀치에 채용공고가 있어 직접 메일로 내 소개와 함께 지원 이유를 밝혀서 보냈다.

하루가 지나지 않은 시점에 메일이 바로 회신 되었는데, 메일 내용에는 연락처가 적혀 있었고  차 한잔 하면서 직접 만나서 얘기를 해보자는 내용이 있었다. 나 역시 지체없이 바로 회신해서 평일 저녁에 약속을 잡고 찾아 갔다. 강남의 주택가 골목에 있는 회사였는데, 사실 사무실 건물이 아니어서 찾기가 쉬운 위치는 아니긴 했다.

아주 조그만 사무실에 늦은 시간 까지 LOL을 하는 회사 직원을 뒤로 하고 2층에 따로 마련된 사무실 공간에서 1:1 인터뷰를 진행했다.

사실 인터뷰 진행하는 분위기는 아니었고 그냥 호구조사+관심분야+사생활 잡담 식으로 뒤섞이면서 진행했는데, 그 와중에서도 서로 원하는 목적은 명확하게 얘기해서 인터뷰 자체는 잘 진행됐다고 본다. 즉, 쓸데없는 자기소개는 이력서에 있으니 건너 뛰고 정말 필요하고 알고 싶은 얘기 위주로 진행됐다는 것이다.

나의 여태까지의 경험에 의하면 이런 식의 인터뷰 진행이 아주 만족도가 높고 그 회사에 대한 생각을 조금이라도 더 하게 되는 것 같긴 하다. 왜그런가 하면 딱딱한 분위기의 인터뷰는 회사에 대해 알게 된다기 보다는 면접관의 준비된 질문에 대답하는 식으로 흘러가기 때문에 내가 알고 싶어하는 정보를 알 수 있는 시간이 많이 주어지지 않는다. 또 인터뷰를 다 진행하고 면접관이 마지막에 하고 싶은 말 있냐고 물어보면 인터뷰때 긴장해서 대답한게 마음에 너무 걸려 딱히 생각나는게 없어 하는 경우도 있고, 있어도 그냥 없다고 대답하고 빨리 끝내는 경우도 있기에 그런 것이다.

인터뷰는 만족스러웠지만 연봉 문제에서 조금 걸림돌이 있었다. 나는 솔직히 현재 연봉과 원하는 연봉의 하한선 까지 제시를 했지만, 이 회사가 워낙에 영세하다 보니 그 정도 돈을 줄 만한 여력이 없다는 걸 어떻게든 돌려 말하는 걸 듣고, 안될 것 같다는 느낌이 들었다. 여기서 다시 생각해 볼 건 내가 연봉을 높여서 받겠다는 생각이 전혀 없고 오히려 하한선을 제시 했음에도 불구하고 그 정도 돈 주고 경력자를 원하지 않는다는 건, 낮은 연봉에 야근도 잘 하고 똘똘한 친구를 구해서 일시키고 싶다는 걸 알 수 있는 부분이라고 본다.

그런데 이제 막 사업을 시작하는 영세한 스타트업에서 경력자가 없이 젊은 친구들끼리 모여서 으쌰으쌰 하는건 좋은데, 그 이후에 전략적으로 필요한 사람이 누구인지를 잘 생각해 봐야 한다.

나는 두 사람이 필요하다고 생각되는데
  1. 개발 경험이 풍부하면서도 전체적인 시스템을 설계할 수 있고 해당 시스템의 요구사항 분석 능력까지 가진 개발자와
  2. 만들려고 하는 서비스를 가지고 영업과 마케팅 전략을 수립해서 수익을 얻을 수 있게 경험적으로 움직일 줄 아는 사람
이 필요하게 된다.

서비스의 기획력이 좋으면 금방 대박이 날 거라고 환상을 가지는 사람이 있는데, 그 서비스를 제대로 만들 수 있는 경험 있는 사람과 그런 좋은 기획의 서비스가 시장에서 수익으로 창출할 수 있게 만들어 주는 경험 많은 사람이 필요한데도 그냥 열심히 잘 만들면 좋은 날이 올거라는 위험한 생각을 버려야 한다.

어쨌든 인터뷰의 결론은 경력자는 쓰고 싶은데 싼 맛에 쓸 사람 구해요 였기 때문에 아니나 다를까 이틀이 지난 후에 변명아닌 변명의 글과 함께 아쉽다는 메일을 받게 됐다. 나 역시도 어쩔 수 없다는 식으로 젠틀하게 회신 보내고 끝이 났는데, 돈이 아닌 능력을 파악하고 우대해 줄 수 있는 스타트업 회사가 있긴 있을까? 라는 생각을 조금 더 생각해보게 되는 인터뷰였던 것 같다.

다음은 가장 최악의 인터뷰였던 세번째 회사 이야기이다.

Sunday, June 17, 2018

Interview review 2017 #1

내가 진행했던 인터뷰에 대한 리뷰이다.

아토리서치에 입사하기 전 인터뷰에 대한 내용은 아래 링크들을 참고하면 되고

면접에 대한 이야기 (1)
면접에 대한 이야기 (2)
면접에 대한 이야기 (3)
면접에 대한 이야기 (4)
면접에 대한 이야기 (5)
면접에 대한 이야기 (6)
면접에 대한 이야기 (7)
면접에 대한 이야기 (8)

지금부터 얘기하려는 건 지금 재직중인 버넥트에 입사하기 전 인터뷰 했던 회사들에 대한 이야기이다.

예전 글에도 썼던 것 같은데, 한참이나 지난 후에 인터뷰를 했던 경험에 대한 리뷰를 하는 이유는 다음과 같다.

  • 그 당시에 느끼는 인터뷰 후의 감정들은 사실 매우 객관적이지 않다.
  • 그렇기에 올바른 판단 위주의 후기라기 보다는 쓸데없는 이유와 핑계가 난무하는 후기가 될 가능성이 높다.
    • 예1) 자기가 잘못 얘기하고 잘 몰라서 대충 얘기해 놓고 면접 떨어지면, 어차피 그 회사 갈거 아니었어 라는 자기 합리화
    • 예2) 난 정말 열심히 준비하고 아무 문제 없이 인터뷰 진행한거 같은데 왜 떨어진거지? 이해가 너무 안되서 밤잠을 설쳐 가면서 그 회사를 욕하고 있는 자신을 발견
  • 결국 자신이 부족했던 회사가 잘못했던 올바른 판단은 격해진 감정이 사그러든 이후에 하는게 좋다는게 내 생각이다.
마지막으로 면접 == 인터뷰를 같은 의미로 매우 혼용해서 적었으니 거부감 없이 봤으면 한다.
---

1. 원격 지원 및 보안 솔루션 제품 개발 회사

다니던 회사를 그만 두기로 서류에 사인을 한 시점 부터 바로 회사들을 찾아 봤고
빠른 시간에 연락이 와서 빠르게 일정을 잡아 인터뷰를 진행한 첫번째 회사이다.

회사는 구로 디지털단지의 매우 흔한 xx테크노타워 건물에 있는 곳이었다.
다니는 회사에는 면접 보러 간다고 얘기하고 오후 반차도 아닌 그냥 조퇴 느낌으로 나와서 오후에 찾아가서 진행했다.

면접관들은 나보다 나이가 많았고 한 분은 PM 한 분은 이제 백발이 성성하게 자라나고 계신 50대 이상 으로 보이는 개발자 분이었다.

난 처음에 나이 많으신 분이 개발을 하고 있으니 좋은 회사일 수도 있구나 하는 생각을 했다. 그런데 나중에 생각해 보니 회사가 오래되면 그냥 일하다 보니 나이를 먹을 수도 있구나 라는 생각도 하게 되서, 어느게 진실인지는 모를 일인 것 같다. 적어도 내가 이 회사 사람들하고 일을 안해봤으니까.

어쨌든 인터뷰 진행은 상당히 평이했으며 제일 하기 싫은 자기소개를 시켜서 하는 것 부터 시작했는데, 이제는 자기소개 하라고 그러면 즐기면서 할 수 있을 정도로 하라고 그러면 신나게 떠들 수 있다.

이유는 몇 개월간 온라인으로 코드리뷰 및 강의를 진행한터라 매주 강의에 들어오시는 분들에게 자기소개를 기계적으로 한 것도 있어서 자연스럽게 진행된건 좋았다고 본다.

면접관들 자꾸 면접보러 온 사람한테 자기소개 해보라고 시키는데, 자기소개는 시켜서 하는게 아니라 내가 누군지 알려주고 싶을 때 내 자의적으로 하는게 자기소개라는 걸 알았으면 좋겠다.

자기소개의 시간이 끝나고 자연스럽게 경력과 하던 일에 대한 Q/A를 진행했는데, 사실 그런거 몇 마디 주고 받아 보면 관심있어서 질문한건지 아닌지 눈치를 챌 수 있게 되는데 내가 진행한 프로젝트와 기술들에 대해 별로 관심이 없어 보였다.

더 이상하게 생각되는건, 이 회사에서 개발하는 제품군도 windows 프로그램이고 여러가지 언어와 framework을 사용하고 있다고 얘기했고, 나도 한가지 언어 한가지 framework으로 하는 것 보다는 여러 가지 시도 해 보고 적용하는게 재미라고 까지 얘기 했는데도 관심이 없었다는 건 그냥 한번 불러서 뭐하는 사람인지 알아보려고 부른 것 같은 느낌이라는 것이다.

나도 솔루션 제품 개발을 한다길래 관심있게 물어보고 개발자들이 주로 어떤 일을 하는지 (신규 기능 or 유지 보수), 규모는 어느 정도인지 물어봤는데 뭔가 신나게 개발하고 있는 것 같은 느낌은 아니었다. 기존 제품에 대한 버그 수정이나 약간의 기능 추가를 해서 잘 굴러가게 만드는 게 중요하다는 식으로 얘기해서 나도 그 쯤에서 그만 물어봤다.

스타트업 회사에서 느껴봤던 신나는 느낌 그런게 오래된 회사에서 어떤 팀에서 느껴질 수 있는 거라면 그 팀에 가보는 것도 나쁘진 않을 것 같다고 생각했는데, 딱 봐도 그냥 재미없어 보이는 일들을 하고 있길래 대충 마무리 짓고 나왔다.

연봉이야 엄청난 연봉을 제시하지 않는 이상 합격이던 아니던 크게 상관하지 않았었고 이틀뒤에 바로 불합격 됐다고 문자로 친절하게 알려줬다. 빠른 기간안에 친절하게 문자로 알려줬다는 것만으로도 매너는 있구나 정도로 생각한 회사였다.

난 회사에서 면접 진행하자고 사람 불렀으면 최소한 관심있는 모습을 보여줘야 하는게 면접 보러 오는 사람에 대한 예의라고 본다. 뭐 압박 면접 안하고, 음료 대접하고 면접비 주고 이런게 면접보러 온 사람에 대한 예의가 아니라, 그 사람이 가지고 있는 기술 그에 대한 생각을 조금 더 자세히 물어봤으면 좋겠다는 뜻이다.

Interview라는 영어 단어를 조금 생각해 봐도 그런 뜻이 담겨 있다는 걸 알 수 있는데도, 귀찮은 면접관들은 대충 물어보고 질문 몇 번 하다가 아니다 싶으면 짜증나는 표정 짓고 하는거 눈에 다 보인단 말이다. 그러니까 진짜 inter하게 view를 진행해서 사람을 좀 더 잘 파악할 노력을 했으면 좋겠다.

이직을 위한 첫 인터뷰 부터 마음에 들지 않았는데, 상상을 초월한 어처구니 없는 면접이 계속 진행될줄은 이때까지는 몰랐었다.

Thursday, May 31, 2018

소프트웨어 개발 활동 #1 - 과외

과외를 하게 된 계기


타이틀을 소프트웨어 공학으로 할까 하다가 공학이라는 단어가 들어가면 거부감이 강하게 들까봐 개발로 바꿨다.

어쨌든 새로운 시리즈로 글을 써보려 하는데 table of contents는 아래와 같다.


  1. 소프트웨어가 뭔지 모르는 사람들이 코딩에 대한 질문을 하고 있는 걸 볼 때의 안타까움

그런데 다시 생각해 보니 첫 글은 내가 활동을 시작한 이후 느꼈던 생각에 대한 글이라 시간 순서는 지금 이 글이 먼저다. 시간 순서가 중요한 게 아니라 내가 어떤 활동을 하고 있느냐가 중요하니까.

과외를 하려고 마음을 먹게 된 계기는 새로운 개발의 욕구가 생길 때라고 봐야 할 것 같다. 그 욕구는 내가 항상 개발일을 하고 있을 때도 느끼는 거지만 회사에서 하는 일이 좀 쉽고 재미가 없는데다가 의외로 시간이 많이 남아서 딴짓을 하게 되는 시간이 많아질 때를 얘기하는 것이다.

여기서 딴짓에 대해 오해할까봐 덧붙이면, 딴짓이 개인적인 사사로운 웹서핑이 아니라 개발 관련된 글, 최신 트렌드 검색 및 개념 정리 그리고 그에 따르는 적절한 프로토타이핑 코딩 연습 및 공부를 얘기한다. 일이 없으면 스스로 능력을 개발하는 시간에 투자하는게 프로그래머의 숙명이 아니겠는가?


<한 프로그래밍 과외 공고, 화려한 스펙에 왠지 움츠러든다. 물론 난 저정도 수준은 아니다.
출처: 인벤>


첫 시작을 하다


그래서 시간이 많이 남으니 소프트웨어에 대한 가치를 전파하기 위해 처음엔 과외를 생각했다.

이유는 과외를 하면 개발 하는데 힘들어하는 사람들에게 1:1로 알려줄 수 있을 뿐 아니라 개발이라는게 코딩이 다가 아니고 소프트웨어라는게 뭔지 이해를 시켜 주면서 내 경험과 시행착오에 대한 가이드를 같이 해주면 좋지 않을까 해서다. 물론 돈을 조금 벌면서 할 수 있다는 것도 이유 중 하나다.

그리고 과외비도 아주 비싸게 책정하지 않고 시간당 1~2만원 선에서 1주일에 한번 2~3시간을 생각했다. 내 주력 언어인 C#으로 뭔가 하려는 사람들은 전부 windows application을 만들어서 원하는 특정 기능을 구현하고 싶어하는 사람들이었기 때문에 여러 까페와 구글 검색을 통해 연락한 사람 몇 명에 대해 오프라인 및 온라인 과외를 진행했다.

제일 궁금한게 과외 수입일 텐데 사실 과외 시간만 투자해서 시간당 돈을 벌면 나름 괜찮을 거라 생각하겠지만 만나서 얘기하지 않을 때도 준비하고 확인하고 하는 시간을 별도로 써야 하기 때문에 생각만큼 많은 돈을 벌 수는 없다. 그냥 용돈 조금 버는 수준으로 생각하면 된다.

그런데 지금은 돈 안받고 활동한다, 사실 소프트웨어 개발 알려주고 돈 받는게 돈을 번다는 목적에서는 의미가 있을 수도 있지만 돈 주는 사람의 입장에서는 과외를 통해 개발을 배운다기 보다는 돈을 줬으니 자기가 개발 하려는 기능에 대해 이것 저것 시키는 쪽으로 변질이 된다. 결국 진행하다 보면 과외가 아닌 갑을관계 방향으로 흘러가기 때문에 돈 보다는 일 하는게 재미가 없게 된다.

쉽게 얘기하면 일로 변질된 과외는 가르치는 보람은 둘째치고 목적 자체를 상실했기 때문에 과외비가 아니라 프리랜서 단가에 상응하는 돈을 받아야 의미가 있다는 뜻이다. 하지만 과외비의 암묵적인 상한선은 정해져 있어 이를 악용하는 사람들이 있다. 그래서 대신 일 해주는 과외 안하는 대신에 돈도 안받는다.


이제 돈을 안받는다는 걸 알게 되었으니 취업, 진로, 문제 해결이 아닌
멘토, 조언, 공동 작업을 원하는 분은 아래 링크를 참조하고 연락하면 된다.
https://jongfeel.github.io/Software/

물론 글 내용에 취업, 진로, 문제 해결 내용이 들어가면 회신 안간다.
나중에 회신 안준다고 뿅뿅하는 사람 있을 까봐 미리 알려준다.


후기


다시 돌아와서 계속 이런일이 반복되고 진행되다 보니 과외는 돈 번 것 보다는 결과가 썩 좋지 않았기 때문에 더 이상 하지 않기로 했다. 여기서 결과가 좋지 않았다는 건 돈을 많이 못벌었다는 뜻이 아니라 내가 생각하는 소프트웨어 개발의 가치에 대한 전파가 잘 안됐다는 뜻이다.

사람의 마음이 간사하기에 처음 과외 할 때와 나중에 끝날 때 쯤 마음이 같은 사람은 여태까지 한 사람도 못봤다. 애초에 과외를 의뢰하는 사람의 의도는 아주 저렴한 돈으로 사람을 구해 일을 시키려는 것이기 때문이다.

그런 사람들에게 소프트웨어에 대한 얘기를 해봤자 이해도 잘 못할 뿐더러 이해하려고도 하지 않는다. 이유는 딱 하나 밖에 없다. 과외를 받는 사람은 돈을 쥐고 있기 때문에 뭔가 과외를 포장한 갑질이라는게 본인 스스로 허용이 된다는 걸 알게 되는 것 같다. 결국 과외 선생님이라고 부르고 을이라 쓰는 사람에게 뭔가 이런 저런 얘기를 듣고 싶어하지 않는다.


몇 가지 사례



#1, C#을 배워 주식 트레이딩 프로그램을 만들 수 있게 도와달라는 사람.


처음에 만날 때 C# 인강도 보고 해서 트레이딩 프로그램 만들고 있고 개발을 잘 모르니까 알려주면 열심히 배우겠다고 해서 진행했다.
두번째 만날 때 까진 C# 문법과 구현 테크닉 들을 알려줬는데 그 다음부터는 점점 자기가 만들려는 프로그램에 대한 설명을 조금씩 하기 시작하더니 만드는 방법에 대해 계속 물어보는 식으로 바뀌어 갔다. 정신을 차려 보니 어느샌가 내가 주식에 대해 공부를 하고 있었고 그 사람이 만들려는 프로그램을 만들어 줘야 하는 일로 변질된 걸 깨닫고 빠르게 그만 뒀다. 의도가 상당히 불순했기에 소프트웨어에 대해 1도 모르는 사람에게 필요없는 말을 떠든 셈이 됐다.


#2, C#을 잘 몰라 기초부터 차근차근 배우고 싶어하는 사람


이 친구는 실무에서 프로그램 개발하는 현직 개발자인데도 C#을 잘 모른다기에 상당히 의아했는데, 알고 보니 개발이라는 타이틀만 가졌을 학교 연구실에서 교수님의 갑질을 받아가면 일을 하는 친구였다. 그렇다고 석사 박사 과정을 하는 학생도 아니고 엄연한 직원인데 교수가 마치 학생 대하듯 갑질 하는 것 보고 기가 찼다.

지잡대 대학에서 일어나는 일이라 생각할 수 있지만 서울의 유명한 S대학에서 벌어진 일이다. 어쨌든 이 친구도 수업 몇 번을 진행하다 보니 슬슬 만들고자 하는 프로그램 얘기를 조금씩 하기 시작했다. 벡터값으로 3D 그래픽 렌더링 하는 걸 만들고자 했는데, 이 친구는 정말 C#을 배워서 그래픽 프로그램을 개발하고 싶어했지만 교수님의 갑질이 그 친구를 통해 나한테 전달이 됐고, 뭔가 일을 시켜서 해보면 되지 않겠냐는 듯이 얘기했다고 했다. 그 친구는 스스로 직원을 채용해서 일을 시켜야 하는 걸 알았기에 이쯤에서 과외를 그만 두는게 좋겠다고 했다.
지금 생각해 보면 착한 건데, 일을 할 수준이면 과외가 아니라 직원을 뽑는게 맞다고 판단해서 그랬던 것이다. 이 케이스도 크게 보면 결국 과외로 포장된 일 떠넘기기로 변질이 된 것이다.


결론


그래서 과외는 그만두고 온라인 코드 리뷰 모임을 하는 걸로 도전을 해보기로 했다.

Sunday, May 27, 2018

정보처리기사 후기

뜬금 없이 정보처리기사라니 하겠지만 그 동안의 히스토리를 쭉 정리해보려고 한다.

정보처리기사 자격증을 여태까지 취득하지 않은 이유


대학 다닐 때 졸업을 위해 학교에서 제시한 선택지가 3개가 있었는데

  • 설계프로젝트 과목 B학점 이상 이수
  • 정보처리기사 자격증 취득
  • 논문
이렇게 였는데, 논문은 거의 대부분 하지 않았고 설계프로젝트 과목을 이수하거나 정보처리기사 자격증을 따거나 했다.
사실 부지런한 친구들은 정보처리기사 자격증 공부도 하고 설계프로젝트 과목도 이수하고 한 친구들이 있었는데 난 자격증이 그리 중요하지 않다고 생각해서 공부하지는 않았고 나중에 공무원할때 가산점 주니까 그때 해도 늦지 않을거라는 생각에 따지 않았다.

그리고 사회생활을 14년 간 하면서 자격증을 딸 이유도 없었고, 그게 있다고 해서 나한테 크게 이득이 되는 일이 있거나 하지 않았다.

정보처리기사 자격증을 따려고 마음 먹은 계기


그렇게 작년까지 일을 열심히 했다가 회사 대표님과 프로젝트 얘기를 하던 중 이런 얘기를 들었다.

"종필님 어차피 기사 자격증 있으시니까 단가 책정할 때 문제는 없을 것 같아요"

그때 빨리 "저 자격증 없어요" 라고 했어야 했는데, 우물쭈물 하다가 말할 타이밍을 놓치게 됐고 졸지에 기사 자격증을 취득하고 실무 경력 13년이 있는 개발자가 되어 버렸다.
그래서 자격증 따 놔야 하나 라는 생각을 조금 하다가 정보처리기사 시험에 대한 검색을 해 봤다.

사실 이때까지만 해도 자격증을 따고 싶다는 생각이 없었다.
대표님한테는 그냥 자격증 없다고 얘기하면 되는 거였고, 프로젝트에 투입하는 인력이야 다른 인력으로 대체해서 넣어도 되는 거였으니까.

그런데 최근 정보처리기사 자격증의 난이도가 급상승해서 실기 합격률이 10~20% 정도밖에 안되는 아주 어려운 시험으로 변했다는 나무위키의 글을 보고 얼마나 어렵게 바뀐거길래 합격률이 이런가 궁금해서 자격증에 도전해 보기로 마음을 먹었다. 그리고 실제 실무에서는 아무 짝에도 쓸모 없는 자격증인데, 이걸 공부하는게 의미가 있는 건가 알아도 볼겸 시험을 보기로 한 것이다.

나무위키에 나온 실기 합격률의 가파른 변화

정보처리기사 필기 준비


시나공 책을 사 놓고 처음부터 쭉 훑어 봤는데 학교 다니던 시절에 배운 내용이 거짓말 처럼 쭉 나열이 되어 있었고 10년이 넘는 세월에도 컴퓨터 관련 기본 지식들에는 변화가 없구나 하며 시작을 했다. 기출 문제들도 어처구니 없는 수준으로 나와 있어서 과연 이렇게 딴 자격증이 무슨 소용이 있나 싶을 정도였다.

<요 책으로 열심히 공부를 했다. 그리고 합격한 다음날 중고로 바로 팔아버렸다.
출처: Yes24>

내용 보고 기출문제 보고 하는 식으로 공부했는데 운영체제와 데이터 통신에서 쓸데없이 많이 외워야 하는 기술 용어들을 제외하고는 기출문제 위주로 봐도 큰 문제가 없을거라 생각해서 한 2주 정도 공부한거 같다.

그리고 정말 평가를 이런 식으로밖에 할 수 없나 라는 생각이 많이 들었다. 요즘 같은 시대는 얼마나 많이 알고 있냐를 평가하는 게 아니라 알고 있는 걸 어떻게 써야 하고 어떻게 생각을 해야 하냐로 평가하는게 맞는 건데, 시험의 수준이 이정도니까 쓸모 없는 자격증이라고 하는거 아닐까? 라는 생각이 많이 든다.

어쨌뜬 필기 시험의 소감은 대학다닐때도 그랬지만 내가 잘 하고 좋아했던 분야는 소프트웨어 공학 쪽이어서 그 과목에서 높은 점수를 받았고, 나머지 과목들도 과락이 안되는 수준에서 점수를 받아 합격할 수 있었다.

정보처리기사 실기 준비


실기 역시 시나공 책을 사서 쭉 문제를 푸는 방식으로 했다. 하다 보니 알고리즘 푸는 건 코드에 빈칸 채우기 수준이라 따로 안봐도 될거 같았고 신기술동향에 외워야 할게 너무 많아서 머리 터지는 줄 알았다.

실기 시험도 이런 식으로 평가하는게 아니라 실제 프로그램 짜는 걸로 좀 바꾸는게 좋을 것 같고, 신기술동향 문제도 답맞추기 형태가 아니라 이런 기술이 어떤 영향을 미치고 뭘 의미하는 건지에 대해 서술하는게 좋을 것 같다는 생각이 든다.

사실 필기는 뭐 그렇다 쳐도 실기 시험은 그러지 않아야 하는데 실기도 크게 다르지 않다는 점에서 계속해서 이 자격증을 따는게 큰 의미가 없다는 생각을 많이 했다.

시험 보는 날 문제 다 풀고 확실한 것만 점수를 매겨보니 50 점 정도밖에 안되서, 부분 점수를 받는다고 해도 60점이 넘을까? 라는 생각을 했다. 확실한 점수로만 해도 합격 점수는 아니니 좋은 경험 한 셈 치고 다음 실기 시험을 준비해야 겠다는 생각을 했다.

그러다 지난 주 금요일인 5월 25일이 합격자 발표일이었는데 합격됐다고 문자가 왔다. 이게 뭔일이지? 하고 사이트 가서 확인해 보니 생각보다 높은 점수인 69점을 받았다고 되어 있었다.

나무 위키에 다시 확인해 보니 내가 봤던 2018년 1차 시험은 갑자기 난이도 하락해서 합격률이 53.8% 라고 하는데, 다행이라고 해야 하는 건지 아니라고 해야 하는 건지 잘 모르겠다. 사실 난 합격의 의의보다는 이런 자격증 따는데 난이도가 왜 이따위인지 그리고 이 자격증 시험을 위해 공부하는게 의미가 있는지를 알아보려고 한 거였기 때문이다.

결론


이 자격증이 정말 자격이 있는지를 증명하는 방법인지를 다시 한번 생각해 볼 필요가 있다. 내 블로그를 본 사람 중에 "너는 실무 경력이 10년이 넘었고 전공도 컴퓨터공학이니 자격증 시험 보는게 쉬운거 아니냐?" 라고 할 수는 있다.

그런데 실무에서 일을 잘 하는 것과 자격증 시험을 위해 공부를 하는 건 다른 차원의 일이라는 걸 알아야 한다.

사실 자격증이 없어도 개발일 하는데 아무 지장이 없다. 그런데도 공공 프로젝트에서 노임 단가를 책정할 때는 어김없이 자격증 취득 여부에 따라 초급인지 아닌지가 결정이 된다. 우스개소리로 빌게이츠가 한국에 와서 공공프로젝트 단가를 받으면 초급 단가를 받아야 한다는 얘기가 있다. 

나는 이제와서 자격증을 땄고, 이제 공공 프로젝트에 노임 단가에서 특급기술자 단가를 받을 수 있게 되었다. 그런데 이게 내 개발능력이 특별히 갑자기 상승한다던가, 없던 능력이 특별히 생긴다던가 그런 건 아니다. 특급기술자 단가로 돈을 받을 수 있다는 것만 알려주는 것일 뿐 자격증 유무와 개발 실력은 전혀 상관이 없다는 뜻이다.

그러므로 K뿅뿅 너네들은 정말 쓸데없는 자격증 가지고 단가 측정하는 짓 하지 말고, 합리적이고 현실적인 단가를 측정하기 위한 노력을 좀 하길 바란다. 단, 앞장서서 나서는 짓좀 이제 그만하고, 여태까지 열심히 일하고 있는 사람들과 앞으로 일할 청년들에게 개발을 잘 할 수 있게 방해나 하지 않았으면 한다. 정보처리기사 자격증 정말 방해된다 이것들아.

Monday, April 30, 2018

프로그래머가 되기 까지의 회고(2) - 중고등학교 시절

2편을 쓰기까지 3년의 시간이 걸렸다.
오래 걸릴 일도 아니었는데, 그 동안 글 쓸 시간이 없었다는 핑계 외에는 할 말이 없다.
---

프로그래머가 되기 까지의 회고(1) - 태어나서 초등학교 시절까지

초등학교때 까지 컴퓨터 학원을 착실히 다니고
컴퓨터 학원 원장님도 날 괜찮게 봐주셨는지 엄마도 내가 나름 컴퓨터에 소질이 있다고 생각했던 모양이었다.

그래서 중학교에 진학했을 때 처음으로 컴퓨터 선물을 받았다.
삼성 알라딘 286 AT 컴퓨터로 그 당시에는 흔하지 않은 256색이 나오는 컬러 모니터에 40M 하드 디스크도 장착되어 있는 정말 부의 상징이 따로 없는 컴퓨터였다.

내 기억으로는 그 컴퓨터 가격이 거의 250만원에 육박했는데 컬러 모니터만 거의 70~80만원대였고 흑백 모니터로 샀다면 150만원은 넘었던 가격이었다. 하드디스크도 없고 흑백 모니터만 있는 컴퓨터도 100만원 부터 시작이었으니 정말 큰맘 먹고 사주셨던 것 같다.

하지만...
난 부모님의 기대에 크게 부응하는 그런 짓(?)을 하진 않았던 것 같다.
물론 처음에는 학습 명목으로 학원에서 배웠던 basic 프로그램도 짜고 교육용 프로그램도 설치해서 쓰고 했었지만, 사람의 마음이 간사해서 그 동안 학원에서만 했던 PC 게임들을 컬러로 할 수 있다는 그 사실 만으로도 좋았던 시기였다.

<호화스러운 컴퓨터로 접해서 엄청난 시간을 투자해서 플레이한 대항해시대,
현재 steam에서도 14,000원이라는 자비없는 가격에 판매중이다.
출처: steam https://store.steampowered.com/app/521720/Uncharted_Waters/>

일단 대항해시대, 삼국지, 프린세스 메이커 등 90년대에 학창시절을 보냈던 분들이라면 할 얘기가 많은 그런 게임들을 나도 플레이하며 시간을 보냈었다.

사실 게임 얘기를 하면 끝도 없고 그 시절에 컴퓨터 프로그래머가 될법한 뭔가를 했냐가 중요한 포인트이기에 그 얘기를 더 해보자면, 특별히 한 건 없다. 내가 좀 쓸데없이 거만한 면도 없지 않아 있었던게 초등학교 시절에도 컴퓨터 자체를 아는 친구들이 그렇게 많지도 않았었다. 그런 친구들이 중학교에 진학했다 하더라도 딱히 달라진건 없었다. 그러니까 그 놈들이 그대로 헤쳐모여서 중학교에 모여 왔을 뿐 특별히 프로그래밍에 취미가 있다던가 하는 친구들은 없었다.

물론 프로그래밍하고 상관없이 컴퓨터를 쓰는 것 자체에 관심이 많은 친구들은 꽤 됐다. DOS 최신판 구해서 뭐가 달라졌는지 써보기, PCTools 버전업 되면서 유용하게 쓸 수 있는 사용법, 배치파일 작성법 정도만 할 줄 알아도 컴퓨터에 대해 꽤 잘 아는 친구였었다. BASIC이나 C언어에 대해 논할 수 있던 친구를 만난 건 대학을 진학하고 나서였으니까.

중고등학교 시절에 프로그램 짠건, 어느 PC 잡지에 BASIC으로 달력 출력하는 코드 따라 쳐본거, 그리고 Q-Basic 언어로 낱말 맞추기 프로그램 짠거 따라 쳐본게 전부였다. 사실 C언어도 따로 공부한것도 하나도 없었고 잡지에 어떤 개념이 나오면 그냥 BASIC하고 어떻게 매핑되는 코드인지 정도만 봤었다. 그렇다는 것은 포인터라는 개념은 하나도 없었고 그게 어떻게 동작하는지도 모른채 그냥 잡지에 Text 상에 있는 내용의 결과가 이렇게 나오겠거니 하는 눈 디버깅 해본게 해본게 전부였다는 것이다.

대학에 진학하기 전까지 내가 한 건
  • BASIC 프로그램 짜는 방법을 잊어버리지 않았던 것
  • 한글과 영문 타자 연습을 꾸준히 했던 것
  • 삼국지 게임을 통해 숫자 키보드로 빠르게 숫자 입력하는 능력을 가진 것
  • PC 잡지, 게임 잡지 같은걸 꾸준히 보면서 프로그래머 (정확히는 게임 프로그래머)가 되겠다는 막연한 희망을 품었다는 것
이정도였다.

그리고 고등학교 2학년 여름방학때 쯤 덥고 무료한 날에 수학의 정석 책만 쳐다보다가 무심코 교과서의 수학책을 리뷰해 보면서 뭔가 제대로 수학을 알아야 겠다는 생각이 번뜩 들었다. 그 번뜩이는 생각이 뭐였냐 하면 그 전까지 수학은 다른 친구들과 마찬가지로 뭔가 공식 같은걸 외워서 낑낑대면서 따라가기 바쁜 그런 공부였는데, 다시 찬찬히 보니 수학은 그렇게 공부하는게 아니라는 걸 깨닫게 된 것이다. 어떤 원리가 나온 이유, 왜 이런 방법으로 수학적인 체계를 만들고 검증하게 되었는지에 대한 생각의 흐름을 읽다 보니 여태까지 바보 같은 공부를 하고 있었다는 걸 깨달은 것이다.

그 이후 처음부터 다시 개념을 이해하는 공부를 다시 시작해서 혼자 미친듯이 시간을 투자해 공부해서 수학 점수가 엄청 잘나왔었다. 수학을 좋아해서 이과를 선택한 것도 아니었는데 고등학교 2학년 여름 때 부터 수학을 좋아하게 되었고 그게 수능을 볼 떄도 반영이 되어서 상위 5%에 달하는 수학 점수를 받았다.

그게 컴퓨터공학과를 진학해서 프로그래머가 되겠다는 마음을 먹은 것에 상당히 중요한 기반이 되었다는 걸 한참 나중에 알게 되었다. 왜냐하면 대학 다닐때만 해도 크게 연관성이 없다고 생각했었고 코딩을 잘하는게 더 중요하다고 생각했었으니까. 지금 다시 생각해보면 프로그래머가 되려고 내가 그렇게 수학을 열심히 공부했나 하는 결과론적인 착각도 하게 된다.

중고등학교 때의 기억은 정말 게임만 미친듯이 했지만 "컴퓨터를 가지고 뭔가 하는 직업"이라는 막연한 꿈을 그냥 놓치지 않고 지냈던 것 같다.

Tuesday, April 10, 2018

기억을 만나다 영화 체험 후기

세계 최초 VR 영화라고 해서 관심이 가기도 했고 러닝타임 40분에 6천원이 적절한지에 대해서도 의문이 들어 보게 되었다.

<4DX VR 영화, 세계 최초란다. 새로운게 나오면 경험해 보고 싶은 것은 인간의 호기심.>

영화 내용이야 직접 보면 되고 "체험 후기" 니까 체험한 얘기를 써보고자 한다.

  • 좋은 점
    • 광고 및 예고편이 없는 듯?
      • 영화 시작 시간 10분 후 상영되는 걸 알고 일부러 5분 후에 들어갔는데, 영화 시작시간에 바로 시작한 듯 앞에 5분을 보지 못했다.
    • 친절한 안내
      • VR을 어떻게 써야 하는지 상영관 입장하기 전 설명을 해준다.
    • 상영관 내에서도 친절한 안내
      • 일단 VR 쓰고 뭘 보라는 것 부터가 무리수라. 나 같이 현업에서 VR 개발을 하고 체험도 많이 해본 사람은 상관 없지만, VR이 뭔지 모르는 사람이 대부분이기에 상영관 복도에 CGV 미소지기들이 대기하고 있다가 문제가 생기면 도와준다.
  • 안 좋은 점
    • 일단 화질
      • VR 화질 별로 안좋은거 알고 있긴 하지만 거짓말 조금 보태서 80년대 브라운관 컬러 TV를 20cm 앞에서 보는 느낌이다.
    • 참을 수 없는 무게
      • VR 헤드셋 부터가 무겁다. 영화 상영 내내 불편하다.
    • 쓰고 있기의 불편함
      • 땀, 화장 방지용 마스크를 주는데 이게 VR 헤드셋하고 겉돌아서 쓰고 맞추는데 상당히 힘들다.
  • 진짜 안 좋은점
    • 왜 VR로 찍었나?
      • 화질이 진짜 안 좋은점이라고 쓰고 싶지만 더 안 좋은점이 있는데, 이걸 굳이 VR로 만들 이유가 있나 싶었다. 솔직히 내가 기대한건 1인칭 시점에서의 동적인 화면이었는데, 영화를 너무 정적으로 찍었다.
    • 화면과 겉도는 사운드
      • 일반 영화를 보면 스크린이 멀찍이 있고 스피커도 그 쯤에 위치하기 때문에 화면에서 소리가 나오는 느낌이 든다.
      • 그런데 VR은 화면이 눈 앞에 있는데 소리는 저 멀리 스크린 쪽에서 나오기 때문에 이질감이 든다.
    • 뭔가 아쉬운 러닝타임
      • 40분 짜리 영화인 줄 알고 본거긴 하지만
      • 40분에 맞춰서 영화를 제작한게 아니라 원래 2시간 짜리 영화를 찍어놓고 40분 짜리로 편집한 느낌이 더 강하게 든다.
    • VR로 봐서 전해지는 감동이 없다
      • 왜 VR로 찍었는가에 이어지는 건데 VR로 봐서 재밌었다라는 느낌이 거의 들지 않았다.
  • 추가
    • 앞으로 VR 영화 컨텐츠는 이런 내용을 찍지 말고 1인칭 액션 영화를 찍는게 더 나을 수 있다. 이 얘기는 VR 기기 + 영화에 대한 분석을 좀 더 해봤으면 좋겠다는 뜻이다. VR 기기는 영화가 아니라 왜 게임이나 체험형 영상으로 인기가 더 있는지 부터 생각해 봐야 한다.
    • 생각해 보니 VR 기기를 쓰고 영화 볼거면 굳이 영화관에 앉아서 볼 이유가 없다. 그러니 VR 기기를 고장없이 그대로 돌려준다는 계약 하에 대여를 해주고 알아서 편한 장소에서 보라고 하는게 더 나을 수 있다.
    • 그리고 VR 기기로 영화를 상영한다는 것이 어떤 의미인지에 대한 생각을 안하고 다음에도 VR 영화를 계속 상영할 계획을 가지고 있다면 왜 사람들이 영화관에 가서 영화를 보는지 단순하고 중요한 원칙을 잘 생각해 보자. 집에 앉아서 IPTV로 영화 보는게 더 편할 수도 있는 세상인데 말이다.

Monday, April 2, 2018

프로그래머와 일반인이 이해하는 영어 차이

억지스러운 것도 있고, 웃자고 쓴 것도 있다.

퇴근할 때 문과/이과가 생각하는 "정의"의 영어 단어가 justice/definition 과 같이 다르다는 것에 웃다가 프로그래밍 용어도 생각해 보니까 바로 몇 개가 떠오르길래 쭉 정리해 봤다.

<요런 버전도 있다.
출처: http://knowyourmeme.com/photos/1215080-artist-vs-normal-people>


---- 억지로 만든거

Load
프로그래머: 데이터 읽어 들이기
일반인: 짐, 하중

Save
프로그래머: 저장
일반인: 절약

---- 괜찮다고 생각되는 거

Bug
프로그래머: 프로그램의 오류
일반인: 벌레

Build
프로그래머: 소스코드를 최종 실행 파일로 만드는 과정
일반인: 건축

Cache
프로그래머: 일반 램 보다 용량이 작고 속도가 빠른 메모리
일반인: (스펠링을 알려주기 전까지) 현금

Callback
프로그래머: 함수의 실행의 결과를 나중에 받기 위한 기법
일반인: (주로 전화통화에서의) 나중에 전화해!

Class
프로그래머: 객체지향의 class
일반인: 수업, 반

Client
프로그래머: 서버에 접속하기 위한 컴퓨터
일반인: 의뢰인, 고객

Cloud
프로그래머: AWS, Azure 등의 클라우드 서비스
일반인: 구름

Cookie
프로그래머: 웹 브라우저에서 작은 데이터를 저장하기 위한 파일
일반인: 쿠키 (먹는거)

Constructor
프로그래머: 객체지향에서의 생성자
일반인: 건설자

Crash
프로그래머: 알 수 없는 이유로 프로그램의 동작이 멈추는 현상
일반인: (주로) 자동차 사고

Function
프로그래머: 함수
일반인: 기능

(번외편) 함수
프로그래머: 호출할 수 있는 실행 블록, 파라미터와 결과값이 있을 수도 있고 없을 수도 있다.
일반인: (주로) f(x) 로 시작하는 방정식

Heap
프로그래머: 동적 실행시간에 생성되는 메모리 저장 공간
일반인: (마찬가지로 스펠링을 알려주기 전까지) 엉덩이

Matrix
프로그래머: 2차원 이상의 배열, 수학쪽에서는 행렬
일반인: 매트릭스 영화

Memory
프로그래머: 프로그램의 힙, 스택 등에 저장되는 데이터 공간
일반인: 기억

Method
프로그래머: 객체지향에서의 객체의 함수
일반인: 주로 영화에서의 메소드 연기

Operator
프로그래머: 연산자
일반인: 군대에 상황실이나 지통실에서 일하는 병사들이나 공장에서 기계를 조작하는 사람

Platform
프로그래머: 소프트웨어가 동작하게 하는 어떤 환경
일반인: 지하철/기차 타는 곳, 폰에 관심이 많은 사람이라면 휴대폰의 OS (라고 오해함)

Pointer
프로그래머: C/C++ 프로그래밍 언어에서의 주소를 가르키는 값
일반인: (주로 마우스) 커서 혹은 발표 때 사용하는 레이저 포인터

Property
프로그래머: 속성 값
일반인: 재산

Queue
프로그래머: 자료구조의 Queue
일반인: 모름
주로 영연방국의 유학생 혹은 IELTS를 공부한 사람: 대기줄

Record
프로그래머: 주로 데이터베이스에서의 어떤 테이블의 한 줄의 데이터
일반인: 기록, 녹음, (아재들에 한해) LP판, 음반

Request/Response
프로그래머: 클라이언트-서버간의 양방향 네트워크 통신을 설명하는 단어
일반인: 사전적 의미의 요청/응답

Return
프로그래머: 함수 처리의 결과값을 반환하는 키워드
일반인: 복귀, 반환, (주로 셀프 서비스 식당에서의) 식판 갖다주기

Run
프로그래머: 프로그램의 실행
일반인: 달리기

Stack
프로그래머: 자료구조의 Stack
일반인: 박스나 책들이 쌓여있는 상태

String
프로그래머: 문자열 타입
일반인: 기타 등의 악기 줄 혹은 스트링 치즈의 스트링

Tree
프로그래머: 자료구조에서 표현의 한 방법
일반인: 나무

Thread
프로그래머: 프로세스 안에서 실행되고 있는 흐름의 단위
일반인: 실

마지막으로

Coding
프로그래머: (속된 말로) 생계를 위해 일정에 쫓겨서 하는 키보드 타이핑 노가다
(웃자고 쓴 글이며, 저를 포함하여 프로그래머를 비하할 의도는 전혀 없음을 밝힘)

일반인: 4차 산업혁명 시대를 맞이하여 인공지능/가상-증강현실/빅데이터/딥러닝/머신러닝 등등의 멋지고 어려워 보이는 최신 기술을 활용 하여 컴퓨터에 코드를 입력하는 어떤 방법이며, 초등학생들도 이제 배운다고 하던데, 나는 잘 모르는 것.

Monday, March 26, 2018

영화속에서의 IT (1): 허리케인 하이스트

이런 글을 쓰고자 한 목적부터.

이 블로그에도 잘 나와 있지만 취미가 영화보기인데
그 중에서도 최신 개봉작 챙겨보기다.

남들이 알고 있는 영화는 물론이고
남들이 잘 모르는 영화, 관심도 안가지는 영화임에도 불구하고 개봉작인데 볼만하다고 생각되면 본다.
남들의 평점으로 영화를 볼지 안볼지를 결정하는 건 나한테는 있을 수 없는 일이기에, 생각 외로 영화를 자주 보는 편이며 거기에 뭔가 눈에 거슬리는 것들은 아무래도 내가 좀 잘 알고 있는 분야의 장면이 나올 때인 것 같다.

여태까지 봤던 영화는 뭐 나중에 시간나면 써볼건데
우선 올해 본 영화 중에서 하나씩 써 보려 한다.
그래서 그 첫번째 영화는 허리케인 하이스트이다.

<Hurricane heist 해외판 포스터, 허리케인을 똟고 나오는 트럭 그리고 흩날리는 지폐가 생동감있는 액션을 선사해 줄 것이라는 걸 암시해 준다.>
IT 관련된 얘기에 앞서, 우선 영화에 나오는 허리케인 부터가 그렇게 현실적으로 존재할리가 없고 설사 영화적 장치를 위해 존재하는 허리케인이라 하더라도 비현실적인건 맞다. 하지만 난 기상 학자는 아니니까 이 부분은 패스하고.

일부 스포일러가 있을 수 있지만 IT 관련된 내용만 짚어낼 거라 큰 상관은 없을 듯 한데, 그래도 불편한 분은 안보는 걸 추천한다.

  • 전반적으로 큰 구멍이 없는 설정인데
    1. 주인공 윌의 차: 정교하게 만들어진 시스템 하에 작동하는 튼튼한 차다.
    2. 드론: 드론 설정도 꽤 현실적이며 큰 문제는 없다.
    3. 보안 시스템: 홍채 인식, 지문 인식 등 실제 존재하는 보안 인식 기능을 사용함으로써 신뢰도 있는 연방의 관리 시설이라는 인식을 강하게 심어준다.
    4. 별도 네트워크 사용: 해킹을 위한 별도의 망을 쓰는데 그게 동네 있는 송전탑이라는 점


그럼에도 불구하고 지적을 해 보자면
  • 암호가 바껴서 다시 해킹을 위한 암호화 알고리즘을 돌린다? 돌리는건 그렇다 치고 시간도 걸린다?
    • 여기가 좀 마음에 안드는데, 영화 구성을 위해 넣은 장치이기는 하다. 알고리즘을 푸는데 시간을 소비하게 함으로써 주인공들이 뭔가 작전을 짜고 실행할 수 있는 시간을 벌어준다는 거에 있는데
    • 사실 암호화 알고리즘이 바뀌면 그냥 안된다고 보는게 맞다. 그리고 영화상에서 분명히 얘기한다 어떤 key값이나 인증할만한 값을 구하는게 아니라 알고리즘을 다시 돌려야 한다고.
    • 결국 알고리즘 얘기는 가짜에 불과하고 설명한대로 영화적 장치를 위해 넣은 것 뿐이다. 홍채 인식, 지문 인식 까지 있는 마당에 숫자로 된 알고리즘 그것도 거창한 것도 아니고 피보나치 관련된 거라고 언급까지 하니 모르는 사람이 보면 뭔가 대단한 거라도 해야 되는 것처럼 들린다.
    • 게다가 네트워크를 사용해서 접근해야 되는 거면 이미 서버 쪽에서 접근 시도한걸 알아채고 끊어버릴 수 있는데도, 실제 송전탑이 물리적으로 박살나 네트워크가 안되는 상황이어야 실패를 한다.
    • 고로 연방 시설의 서버 보안도 그렇게 썩 좋은 편은 아니라는 걸 알 수 있다.
  • 이미 몇 달전 부터 계획해서 침투해 들어온 해커들이 쓸데 없는 키보드질을 하고 있다?
    • 이건 다른 영화에서도 보이는 쓸데 없는 설정들인데 뭔가 키보드로 대단해 보이는 명령어들을 마구 입력하는 쓸데없는 짓을 해야 보안 시스템을 겨우 뚫을 수 있는 것처럼 해 놓는데
    • 제발 이러지 말자, 어차피 admin이나 그에 준하는 계정을 획득해 시스템에 로그인 했으면 그냥 끝난거나 다름 없다.
    • 그럼에도 불구하고 두 해커는 시스템에 접근하는데 상당한 시간을 소비한다.
    • 시대가 많이 변했다. 보안 시스템 = 뭔가 어려운 작업 = 남들은 알지 못할것이라는 쓸데 없는 키보드질 이라는 설정은 그만하자.
쓰고 보니 IT 관련되서는 사실 구멍 보다는 보안 설정이 생각보다 잘 되어 있어서 그렇게 많이 깔만한 요소는 없는 것 같다.

Friday, March 9, 2018

소프트웨어가 뭔지 모르는 사람들이 코딩에 대한 질문을 하고 있는 걸 볼 때의 안타까움

우선 소프트웨어 개발이라는 용어에 대해 명확하게 이해한 후에 얘기를 해보고자 한다.

개발을 한다는 건 소프트웨어를 개발한다는 것이고 코딩을 한다는 건 프로그래밍 언어로 스크립트를 작성한다는 얘기다.
소프트웨어 개발과 코딩의 차이는 엄청난 것임에도 불구하고 소프트웨어에 무지한 사람들에게는 두 단어의 차이는 거의 없다고 봐도 될 정도이다.
그냥 특정 프로그램 언어로 코딩해서 실행하면 어떤 결과가 화면에 나오는 것 정도로 이해하고 있을 수 있는데, 사실 이 둘의 차이는 엄청난 것이다.


<당장 Software engineering으로 검색해봐도 나오는 이미지가 이렇다>

개발을 하는 대상이 소프트웨어이므로 소프트웨어 개발은 아래 내용들이 포함되는 걸 얘기한다.

  • 요구사항의 확인, 수집, 분석
  • 소프트웨어로의 개발 계획
  • 요구사항 및 시스템의 설계
  • 구현, 버그 수정, 테스트, 문서화
  • 추가 요구사항에 대한 커스터마이징 및 버전관리, 유지보수
자 이제 내가 얘기하려고 하는 건 위의 내용을 학문적으로 공부해 본 적도 없고 실무에서도 적용해 본 적이 없는 사람들에 대한 얘기다.
안타깝게도 실무 경험은 없지만 학교에서 학문적으로 소프트웨어에 대한 과목을 공부해 본 컴퓨터 관련 학과 전공자 3학년 이상 학생들도 포함되는 얘기다.

네이버의 개발 관련 커뮤니티 까페를 가보면서 많은 사람들의 질문 글들을 보는데, 대부분 안되는 걸 되게 만들고 싶어하는 욕구가 충만한 글들이 대부분이다.
문제는 그 안되는 것들이 조금만 찾아보고 생각해 보면 다 해결할 수 있는 것들이라는 것이다. 사실 그런건 해결해 주면 되고, 다른 사람들도 댓글을 잘 달아주는 편이다.

어? 이게 문제가 아니면 뭐가 문제인거냐? 라고 생각할텐데 내가 안타까워 하는 건 그런 식의 문제 해결이 코딩하는 능력 향상에 매우 방해가 되는 행위라는 것이고, 소프트웨어 개발을 하는 능력 향상에는 전혀 미치지 못한다는 것이 문제라는 것이다. 위에 나열한 소프트웨어 개발 내용 중에 구현에만 해당되는 내용이며 구현에 따라서 다르겠지만 거의 대부분 잘 모르고 구현한다.

잘 모르고 구현한다는게 이해가 안될 수 있는데, 검색해 보면 그들이 원하는 거의 모든 문제의 해결은 best practice 라고 모범 답안 같은게 있다. 이것만 보고 이해한 다음에 자기가 구현하고자 하는 문제 해결에 응용해서 적용하면 해결된다. 이것도 어렵다 하면 기초적인 공부를 더 하는 것이 맞는데도 이 마저도 찾아보지 않고 찾았다고 하더라도 이해를 못하거나 이해를 하려고 하지 않는다. 그런 상태에서 안되는 걸 되게만 하려고 구현하고 있다는 게 잘 모르고 구현한다고 하는 것이다.

그런 질문을 하는 사람들의 다른 글들을 쭉 보면 소프트웨어 공학적인 기법, 설계의 노하우, 테스트, 오류 검증 방법, 성능 향상 이런 것들이 아니다. 반복적이고 단순한 문제를 마치 어려운 것 처럼 계속 질문해 나가고 답변이 달리면 마치 자기가 해결을 한 것 마냥 개발이 잘 되고 있는 것 같은 착각을 한다. 그 후에도 계속 비슷한 패턴의 질문-답변-질문-답변이 이어지는데 그러다 질문이 어느 순간 끊기게 된다. 이유는 예측이 가능하다. 자기가 알던 개발이라는 것이 코딩이 다가 아니라는 걸 깨닫는 순간인 것이다.

결국 그런 사람에게는 다음과 같은 문제점들이 나타나게 되어 있다.

  • 요구사항이 뭔지 모르니까 뭘 만들어야 하는지 정확히 인지가 안되고,
  • 계획을 잡지 않으니 생각대로 진행이 안되고 뒤죽박죽이 된다.
  • 설계라는 걸 하지 않고 구현 먼저 했으니, 구현이 끝난 후에 다시 기존에 구현한 것에 덧붙이거나 다른 기능/모듈과의 연결을 계속해서 구현하기가 힘들어 지고,
  • 버그 수정 능력도 부족한테
  • 테스트라는 것도 할리가 없기 때문에
  • 결론적으로 소프트웨어의 품질이 매우 떨어지게 되어 있다.
게다가 어찌해서 완료를 했다 하더라도 나중에 다시 버전업해서 기능 추가를 하려면 어디서 부터 손을 대야 할지 막막하니까 "그냥 다시 만들자" 라는 얘기가 나오게 된다. 그냥 다시 만들자는 얘기가 나온다는 건 소프트웨어를 아주 잘못 만든 것이다.

그래서 전공자던 비전공자던 일단은 생각한걸 바로 코딩하다가 막힌걸 물어보는걸 먼저 하지 말고 계획과 설계를 최소한 두번 이상 생각해서 문서화 라는 걸 한 후에 해보면 좋겠다는 생각이 든다. 그리고 비슷한 종류의 문제와 고민은 반드시 다른 사람도 겪어본 고민이기 때문에 구글에 검색해 보면 관련된 내용과 사례는 충분히 찾아낼 수 있다. 그래서 사실 그들에게 완벽에 가까운 답변인 "문서화 + 구글 검색" 이라는 얘기를 매우 해주고 싶긴 하지만, 정작 그들에게 필요한건 지금 내가 짠 코드가 안도는 이유(이유라도 알고 이해하면 다행)와 이걸 되게 하려면 어떻게 해야 하는지가 더 중요하다고 생각할 것이다.

나는 그들이 문제해결은 물론이고, 소프트웨어 공학 아니 공학까지 거창하게 갈 필요도 없다 소프트웨어 개발에 대한 이해를 하고 코딩이라는 걸 했으면 한다. 그리고 정말 진심으로 도와주고 싶다. 

다음에 내가 그들을 도와주려는 방법과 실천하는 사례를 얘기해 보려 한다.