Monday, January 14, 2019

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

제목이 좀 자극적이어도 글을 끝까지 읽기를 권한다.

개발 실력이라는 것?


실무 경험이 없는 그리고 개발자가 되려고 하는 사람 중에는 이렇게 생각하는 사람이 많을 것이다.

- 빨리 회사에 입사해 도움이 되는 사람이 되려고 하는 것
- 회사가 내 개발 능력을 잘 써주길 바라는 것

그런데, 사실 일해보면 알겠지만 위 두 생각은 틀린 생각이다.

일단 회사에 도움이 되는지 안되는지는 일을 함께 해 보지 않고 알 방법은 없다. 뭐 같은 기술을 쓰고 같은 개발을 하는 입장에서는 도움이 된다고 생각할 수 있지만, 근본적으로 일을 하는데 도움이 되고 안되고가 판단의 포인트가 아니라는 뜻이다. 회사는 제품 개발이 되고 수익이 나는 상황을 원하게 되어 있고 그러려면 일 하는 사람에게 요구하는건 개발 하면서 배웠던 개념이라던지, 좋은 개발 문화, 성장할 수 있는 환경, 코드의 품질을 높이는 작업 등등을 원하는 게 아니고 어떻게든 동작하는 코드를 작성해서 버그가 없이, 그리고 일정에 맞춰서 문제 없이 일을 끝낼 수 있는지에 대한 여부만 보게 되어 있다는 것이다. 즉, 시키는 일을 별 문제 없이 잘 해서 월급 줘 가며 일 할 수 있는 사람인지가 회사 쪽에서 가지는 시각이라는 것이다. 뭐 이것도 내가 여차저차 잘 해서 스스로 회사에 도움이 됐다고 생각하면 좋은 케이스이지만 그렇게 개발을 하다 보면 내 개발 실력이 느는게 아니라 회사가 원하는 일에 맞게 잘 훈련되서 거기에 맞춰 열심히 노동력을 제공 해 주고 월급을 받아왔다는 게 팩트인데, 그걸 잘 모른다는 게 사회 초년생들의 흔한 착각이다.

또 회사가 나의 능력을 잘 써주길 바라는 마음이 있는건 좋지만, 아마 반대의 상황으로 흘러가는 게 더 많을 것이다. 즉, 나의 능력과 흥미가 어디 있는지 크게 관심이 없고, 회사가 원하는 방향대로 나의 능력을 그쪽에 맞춰 키워나가는 걸 더 원한다는 것이다. 예를 들면 내가 가진 능력은 코드를 계속 리팩토링 해서 간결하고 유지보수 하기 좋게 코드를 짜는 능력이 있고 그걸 회사 업무 하면서 발휘하기를 원한다. 하지만 회사는 그런 거에 관심이 없고, 당장 2주 후에 만들어야 할 관리자 페이지와 프로모션 페이지를 만들어야 하고, 서버 로직과 DB 쿼리를 잘 짜서 어떻게든 기능을 만들어 내는 데 쫓기게 되는 상황이다. 이런 상황이면 잘 설계되고 잘 리팩토링 된 아름다운 코드는 나오기 어려울 수 밖에 없다. 아니면 시간을 더 투자해 내가 원하는 능력을 발휘해서 리팩토링된 코드를 잘 구현했다고 하더라도 쓸데없는데 시간 썼다고 생각할 가능성이 높다. 개발 문화가 나의 관심사를 발휘할 수 있는 문화가 아니라면 내 진짜 실력이 성장할 기회 조차도 없기 때문에, 애초에 아무 회사나 들어가서 내 능력이 잘 쓰이길 기대하는 거 부터가 잘못됐다. 처음부터 내 관심사에 대해 발휘할 수 있는 문화가 있는 회사를 찾아가서 일하는게 맞다.

이런 시간을 1년, 2년, 3년 보내고 나면 얻는 타이틀이 개발 실력일까?


개발 실력이 늘던 아니던, 성장을 했던 못했던 어쨌든 모두들 사회 생활을 하다  스스로 이렇게 부르게 된다.

"안드로이드 개발 2년차"
"자바 개발 3년차"
"서버 개발 5년차"

뭐 5년차 까지는 괜찮다. 회사 이직 시 연봉 상승에 아주 좋은 연차들이니까. 그런데 그런 시간을 보내온게 실력을 증명하는 길인지 아닌지 잘 생각해 봐야 한다. 일단 좋은 개발문화를 가지지 못한 회사에서 시키는 일과 일정에 쫓겨 일을 했던 사람이면 개발 년차가 크게 의미가 없다. 왜냐하면 내가 성장하기 위한 능력을 키운게 아니고 일 하는 방법을 잘 훈련해서 그렇게 시간을 보내온 거니까.

"내가 개발 3년 했으니까, 어느 정도 인정 받을 수 있겠지?"

라는 생각은 매우 위험하다. 개발 문화가 좋지 않은 곳, 즉 여태까지 일정에 쫓겨가며 시키는 일을 마무리 하는 것에 시간을 보내온 개발자는 비슷한 환경에서 일하는 다른 회사에서는 대우 받을 수는 있을 것이다. (왜냐하면 등급이 올라가면 더 단가를 후려치고 월급은 조금만 더 줘도 되니까) 그런데 대부분 이직을 원하는 회사는 개발 문화가 좋은 곳을 원한다. 카카오라던지 네이버, 우아한 형제들 이런 곳일 것이다. 그런 곳에 이력서를 넣고 면접을 한번 보러 가보자, 그러면 자신이 얼마나 형편없는 개발자였는지를 뼈저리게 느끼게 될 것이다. (물론 서류 전형이 통과될 수 있는지 없는지에 대한 여부는 논외이다.)

그 회사들이 원하는 면접의 형태에 코딩 테스트가 있다. 알고리즘 문제 해결이라던지 프레임워크나 특정 기술적 상황에서의 문제 대처 방법과 왜 그렇게 생각하는지에 대해 면접을 진행을 할 것이다. 하지만 회사에서 했던 일은 그런 것과 상관 없는 것들을 해왔기 때문에 면접을 잘 볼수 없게 된다. 혹은 그런 경험을 했고 잘 알고 있다고 하더라도, 그걸 남들한테 보여주거나 설명해 본 적이 없기 때문에 분명히 아는 건데도 어버버 하면서 말이 제대로 안나오게 되는 경우가 허다할 것이다. 그리고 그 경험을 한 후 부터 부랴부랴 알고리즘 공부도 하고 원하는 직군의 기술들에 대해 공부를 한다. 그런데 또 그게 잘 될리가 없다. 왜냐하면 갑자기 안하려던 걸 하니까 힘들고, 실무 하기 전에 공부할 때도 그런 레벨로 공부를 해보지 않았기 때문이다. 그런 레벨로 공부를 해보지 않았다는게 무슨 의미냐 하면 따라하기식 강의나 그저 그런 스터디모임에서 뭐 하나 제대로 끝내보지 못한 채로 수박 겉핥기 식으로 조금 "따라" 해 본게 전부인데, 면접 질문은 그런 수준이 아니라 근본적인 기술적 수준에 대한 것이나 그 해결 방법, 또는 왜 이런 기술과 방법을 썼는지와 같은 걸 물어보기 때문에 그런 걸 공부해 보지 않았으면 대답을 할 수가 없다는 것이다. 또 공부해 봤다고 하더라도 블로그 같은 곳에 잘 정리를 해 놓거나 어느 커뮤니티 사이트에서 발표 혹은 스터디 모임 주도 정도를 해보지 않았다면 어려운 일이 된다.

진짜 문제는 따로 있다.


결정적으로 가장 큰 걸림돌은 현실과의 타협이다. "나 정도면 이 회사에서 더 잘할 수 있어", "여기 말고 다른데 가도 크게 달라질까?", "당장 다음달 까지 마감 프로젝트 있는데, 그거 끝나고 다시 생각해보자" 이런 식의 타협은 현재 다니는 회사에 안주하게 되고, 시간은 계속 흐르고 이직 타이밍은 미뤄진다. 더 웃긴건 회사에서는 어느 정도 연차가 차면 시니어급 레벨로 인정해 주고 manager 노릇도 할 수 있기를 기대하는데, 여태까지 시키는 일만 한 채로 몇 년을 지내왔을 뿐이라 그런 능력이 또 갑자기 생길리가 없다. 아마 처음 드는 생각은 이럴 것이다. "아니 나도 잘 모르는데 누굴 알려줄 수 있을까?" 그리고 이 때 쯤 다들 힘들어한다. 그런다고 해서 회사에서 연봉을 많이 주는 것도 아니다. 그 시점에서 내가 몇 년차 개발자라는 걸 어필해도 먹힐리가 없다. "몇 년 동안 했는데 그거 밖에 안되냐?" 라는 말로 공격 당하면 서러움이 눈 밑과 목구멍까지 울컥하고 올라오게 된다.

그러면 개발 실력이라는 건 회사에서 하는 일 아니면 어디에서 오는 건지 다음 편에서 얘기해 보기로 한다.

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 처리 쪽을 더 공부 하려고 했으나 집안 사정 때문에 취업을 할 수 밖에 없는 상황이었죠. 부모님의 바램대로 졸업 전에 취업을 해서 회사 생활을 쭉 해오긴 했지만 마음속 깊은 곳 한쪽에서는 대학원을 진학해 조금 더 연구과제에 대한 공부를 했으면 어땠을까 하는 아쉬움이 조금은 있긴 합니다.