어쩌다 데이터 11 : 코더에서 개발자로

0. 들어가며

요 근래 프로젝트 중 단독으로 추천 시스템을 개발하는 업무를 진행하며 기술적 부채를 온 몸으로 느끼고 있다. 원리를 몰라도 가져다 썼던 것, 가장 유명해서 일단 썼던 것, 패키지에만 의존하던 것, 전체 시스템과는 상관 없이 그저 성능만 높이려 했던 것 등등 쌓일대로 쌓인 기술적 부채들을 비싸게 갚아나가고 있다.

이제까지 정말 많은 강의를 들었고, 또 나름 실무를 통해 분석일에 익숙했고, 캐글이나 여러 외부 활동을 통해 알고리즘과 코딩에는 자신이 있었다. 하지만 정말 제대로된 실전은 가혹했다. 어쩜 그렇게 속속들이 귀찮아서 생략했던 것과 또 그것을 지나쳤던 장면까지 함께 복기되는 것일까. 이제와서 주말에도 휴일에도 공부하며 자괴감이 드는 것은 덤으로 얻어가며 꾸역꾸역 채워넣고 있다.

그럴싸한 실력인줄 알았다..

이제껏 내가 공부한 것이 코더로서의 공부였는지 개발자로서의 공부였는지 생각해보게 되었다. 공부는 꽤나 열심히 하고 있었다고 생각했는데 그 방향이 맞았던 것인지에 대해 생각해봤다. 더해서 개발 시장에서 왜 코더와 개발자가 나뉘는지, 또 그보다 앞서 굳이 코더와 개발자를 왜 구분짓기 시작했는지 어느정도 생각해보게 됐다. '그래도 된다'라기보다는 '이래서 그렇구나' 정도의 생각을 하게 되었고, 정리해보고자 한다.

 

1. 난 코더였나?

코더와 개발자의 개념적 차이는 여기를 참고 했다.

코더가 아닌, 개발자가 되려면

나도 코더였던것 같다.
나의 코더로서의 마인드와 생각을 정리해봤다.

 

(1) 구현만이 목표

첫 째도 구현, 둘 째도 구현이다. 구현을 위해서 모든 우선순위가 무시된다. 여기서 말하는 구현은 모델링이라면 모델이 돌아가는 것, 프로그래밍이라면 input, output이 제대로 작동하는 것이다. 당연히 정확도도 따질테고, 성능도 따지지만 구현이 최대의 목표기 때문에 만들어가는 과정에서 그 어느것도 고려되지 않는다. 그냥 구현하기 위해서는 마구잡이로 때려 넣는다고 보면 된다. 쉽게 결과를 낼 수 있는 패키지를 그냥 아무데나 가져다 쓰고, 그저 정확도를 높일 수 있는 튜닝이면 일단은 돌린다. 그렇게 만들었을 때는 구현이 되어도, 또 안되어도 문제다. 구현에 성공 했다고 해도 튜닝을 진행하려고 할 때 어디서부터 손 대면 좋을 지 알 수가 없다. 또 구현이 안된다해도 어디가 문제인지 알 수가 없다.

현재 추천 시스템을 만들면서 이 부분에서 가장 큰 반성을 하고 있다. 일단은 돌리고보자는 마음으로 코드를 짜다보니 파트마다 제대로 나눠져 있지 않다. 정확도를 높여야 할 때, 또 다른 모델링을 시도해봐야 할 때, raw 데이터를 바꿔야 할 때마다 처음부터 다시 돌려야 하는 경우가 있다. 매번 모델 fitting을 다시해 모델마다 파라미터 튜닝을 따로 저장하고, 다시 또 raw데이터를 바꾸고 모든 작업을 다시 하다보면 메모리는 엄청나게 먹고 있지만 정작 살아있는 부분이 어디인지 알 수가 없는 지경에 빠진다.

 

(2) 원리는 패스

모델링을 할 때 어떤 방법론을 선택할 것인지에 대한 기준은 성능이 정할 뿐이다. 그것도 비슷한 캐글 Competetion의 Leaderboard가 정해줄 뿐이다. 거기다 성능이 좋은 것을 정한 후에도 왜 좋은지는 다른 세상 이야기다. 어려운 수식과 원리를 만나면 무조건 패스하진 않지만 한 눈에 이해가 되지 않으면 그냥 넘어갈 뿐이다. 그러니 당연히 넘어가게 된다. 이것 또한 첫 번째 이유인 구현만이 목표인 이유와도 맞닿아 있다.

원리를 모르고 그냥 사용했을 때 문제는 캐글처럼 실제로는 좋은 성능이 나오지 않았을 때 발생한다.

---

"캐글에서는 rmse가 엄청 향상됐는데 똑같이 사용했을때 왜 잘 안나오지?"

 

문제는 알겠지만 왜 그런지, 또 어떻게 향상 시켜야 할 지 알 길이 없다. 구글링을 해도 정말 친절한 글이 아니라면 별 도움이 되지 않는 경우가 많다. 물론 '토끼굴'에 빠져 협업 필터링 추천을 만들다 선형대수학을 공부하면 안되겠지만 적어도 협업 필터링은 언제 쓰는 건데 이걸 써야 하는 상황인지를 판단할 수 있어야 하지 않을까? 

 

(3) '선'하지 않은 모델링

이건 개인적인 문제일 수도 있겠다. 그저 구현에 목적을 두고 쓰다보면 웬만하면 '선'하지 않은 코드가 나온다. 특히 readablility가 굉장히 떨어질 때가 많다. 주석도 나름 달고, 목차도 쓰지만 정신없이 이것저것 붙이다 보니 나조차 알아보기 어려운 코드가 되기 쉽다.

 

2. 어떻게 개발자가 될 수 있을까?

 

(1) 개발자는 뭐가 다를까?

프로그래머(개발자)가 되고 싶은 건 아니지만 분석가로서도 가지고 있어야 할 부분을 정리해보고자 한다. 우선 프로그래머는 코더와 무엇이 다를까? 여러 주장이 있고, 또 일치된 공통 의견은 없지만 개인적으로 생각해봤을 때 이 분의 의견에 제일 마음이 간다.
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=mdexcel&logNo=220077227629

개발자, 프로그래머, 코더 차이

요약해보면 이렇다

1. 어떤 프로그램을 만들것인지 기획하고
2. 프로그램을 설계하고
3. 프로그램을 구현하고
4. 만들어진 프로그램을 테스트하고
5. 마지막으로 상품성을 입혀서 내놓는다

이 모든 과정을 손에 쥐고 최종 결과물을 목적으로 달려가는 사람을 개발자라고 부른다

이 부분에 내 생각을 덧붙여 보자면 단계단계마다 '왜'에 대해 묻고 답할 수 있는 사람이 아닐까 싶다. 왜에 대해 묻고 답하려면 당연히 그에 대한 지식이 필요하고 경험이 필요하다. 물론 지식과 경험 모두 깊게 고민해볼 수록 왜에 대한 질문과 대답이 날카로워지는건 당연하다.

왜 이 부분을 이렇게 설계해야 하는지 묻는 질문에 답하고, 왜 데이터베이스를 이렇게 설계했는지 물을 수 있는 사람. 또 그 대화에 따라 방향을 바꾸거나 문제를 해결할 수 있는 사람이라고 생각한다. 거창한 것 같지만, 인용글의 마지막 문장이 정말 잘 설명하고 있다고 생각한다.

 

 

"이 모든 과정을 손에 쥐고 최종 결과물을 목적으로 달려가는 사람"

 

(2) 어떻게 개발자가 될 수 있을까?

레전드 임백준님의 글로 정리할 수 있겠다.

1. 지금 다니고 있는 회사에서 하는 일을 잘하기 위해서 노력하는 것이 가장 좋은 공부다.

2. 회사에서 하는 일과 개인적으로 공부하는 내용을 최대한 근접시키기 위해서 노력하라.

3. 새로운 기술을 익히는 최선의 방법은 스스로 문제를 정의한 다음, 새로운 기술을 이용해서 그 문제를 풀어보는 것이다. 책을 읽거나 동영상을 보는 것은 그보다 하위수준의 방법이다.

4. 신기술을 좇는 메뚜기가 되지 말라.

5. 모든 것을 알아야 한다는 강박을 버려라. 미리 획득하는 지식의 99%는 무용지물이다. 필요할 때 필요한 기술을 익힐 수 있는 것이 능력이다. 그 능력을 키워라.

6. 이상한 나라의 앨리스에 나오는 토끼굴(rabbit hole)을 피하라. 카테고리이론을 알아야 함수형 언어를 쓸 수 있는게 아니고, 선형대수학을 공부해야 머신러닝을 할 수 있는게 아니다. 토끼굴에 빠져서 한없이 들어가다보면 비본질적인 공부에 시간을 허비하게 된다.

7. 겉만 핥는 것은 경박하지만 토끼굴에 빠지는 것은 우매하다. 둘 사이의 적당한 지점에서 균형을 잡는 것이 개발자의 능력이다.

8. 머리에 들어오지 않는 어려운 개념이나 용어는 자투리 시간을 이용해서 반복적으로 읽고 암기하라. 나중에 큰 그림을 공부할 때 도움이 된다.

9. 항상 겸손해야 하지만 동시에 자긍심을 가져라. 그대가 지금 작성한 코드, 지금 읽은 책, 지금 공부한 내용을 그대보다 잘 아는 사람은 지구상에 없다. 모든걸 알고 있는 것처럼 보이는 다른 사람들도 그대와 마찬가지로 불안해하고, 위축되고, 두려워하면서 살아가고 있다. 자긍심이란 그런 타인을 돕고자 하는 마음가짐의 다른 이름이다.

-2017-06-16, zdnet korea, 임백준 칼럼, [개발자의 평생 공부], https://zdnet.co.kr/view/?no=20170616090644-

뼈 맞고 가루가 되어서 요약도 필요가 없다. 특히나 5,7, 9번은 정말 너무하다 싶을 정도로 머리를 울렸다.

 

3. 실력은 고통의 총합

본질에 다가가기 위해서 감내해온 고통, 불면의 밤, 좌절, 환희, 이런 것으로 점철된 뜨거운 경험에서 나오는 것이다. 그래서 실력은 지식의 총합이 아니다. 고통의 총합이다.

지금 추천 시스템을 만들면서 너무나 내 지식이 '경박'하다는 것을 뼈저리게 느끼고 있다. 하지만 그렇다고 SVD를 알기 위해 선형 대수학을 공부할 수도, 메모리 개념을 알기 위해 자료구조, 프로그래밍을 공부할 수도 없는 노릇이다. 또 그렇다고 피상적으로 공부하고 넘어가면 똑같은 문제에 봉착하게 된다. 결국 본질을 알아보는 진짜 실력이 필요하지 않을까 싶다. 다소 추상적이지만 이게 가장 맞는 방향 같다.