프로그래머로 산다는 것 - 라이엇 게임즈 유석문 CTO

1. 개발자???

2013 문화체육관광부 우수학술도서 - 프로그래머로 산다는 것(황상철, 하호진, 이상민, 김성박 - 로드북)

해당 책이 출판되고 나서 많은 개발자들이 화를 냈음. 책 표지가 화장실에서 노트북을 하는 장면이었기 때문임. 미래도 없고 꿈도 없듯이 밤낮없이 화장실에서도 일하면서 과로로 쓰러지라는 것이냐! 라는 느낌이었기 때문. 기존 개발자들은 연봉도 오르지 않고 쇠퇴하는 경우가 많았기 때문에 프로그래머를 평가절하한 것이냐는 의견이었음. 프로그래머가 왜 되려고 하는 것인가? 대부분의 경우 프로그래밍이 어렸을 때부터 너무 재밌었기 때문에 프로그래머가 된다고 한다. 보통 모바일 게임의 경우 화장실에서도 볼일을 다보고도 계속 하듯이, 프로그래머가 되려고 한 자체는 결국에 이 일이 재밌고 즐거워서, 평생 할 수 있어서이기 때문이어야 할 것이다. 해당 책 소개를 의도한 이유는, 재밌다면 그 일을 계속 하라는 것을 이야기하고 싶어서이다. 코딩이 재밌다면 화장실이 아니라 어디에서 하든 상관없다. 하지만 나를 소진해가면서 밥벌이를 위해서라면 하지 마라는 것을 이야기하고 싶었다.

1.1 개발자??? or ?????

보통 신입사원 면접을 진행할 때 겪는 일이다. 기술면접 할 때 아이스브레이킹 시간을 가지고 간단한 기술문제를 푼 이후 난이도 조절을 통해 다음단계를 진행하게 된다. 아래는 3-5년차 자바 개발자를 대상으로 면접을 할 때 냈던 문제이다.

위의 문제를 가지고 해당 자료구조(스택)를 만들어보라는 문제를 냈다. 하지만 클래스 선언도 못하는 경우가 허다했다. 이력서는 화려한데 왜 못하지..? 라고 물어보면 “최근에는 개발보단 관리를 많이 하느라..” 라는 답변이 돌아온다. 이런 상황이 이해가 되지 않았음. ‘읭?’

1.2 개발(놈) Begins - 업무 할당

프로그래밍 관련 학과를 졸업하고, 현업에서의 시간도 어느정도 지났는데 왜 하지 못할까라는 고민에 대한 고찰.

회사에 처음 가서 어떤 과제를 받았다고 해보자. 정상적이지 않은 회사라고 한다면 대부분 “이 일을 언제까지 끝낼 수 있겠니? 참고로 시간이 없어.” 라면서 일을 시킨다. 무조건 그 시간안에 다 해야 하고, 심지어 충분한 레퍼런스나 리소스도 없다. 관리자가 시간만 관리하고 기술적 지원/교육도 없는 상태에 데드라인에 맞춰서 일을 끝내야 하는 상황에 놓였다고 상상해봐라..

1. 검색
2. 복사 & 붙여넣기
3. 되는것처럼 보일때까지 삽질.

1.3 개발(놈)의 탄생 주역

네이버든 어떤 조직이든간에 개발 잘하는 사람들이 있는 반면 저런 사람들도 (당연히) 있을 것이다. 운이 좋으면 좋은 팀을 만나서 성장을 막 할 수 있을테고, 운이 나쁘면 저런사람들을 만나서 소진될 것이다. (운 나쁠 확률이 더 많음 ㅋ.)

기피해야 하는 대상

1. 나쁜 고객과 상사 - 어떤 기술을 쓰든 좋은 기술을 쓰든 관심없고 대부분은 기술능력도 없고 결과만 나오면 되길 원함. 이러면 내 인생을 낭비하게 되는 것과 다름없다.
2. 탐욕스러운 회사 - 개발자들은 백날천날 같은 기술만으로는 살아남을 수 없다. 새로운 것을 배우고 적용해봐야 실력이 늘며 성장하는 것인데, 탐욕스러운 회사는 똑같은 일만 시킨다. 그렇게 개발자들은 소진될 것이다.
3. 비협조적인 동료 - 서로 긍정적인 영향을 주고받을 수 있으면 좋은데, 대부분의 동료는 내가 하는 일에 관심이 없을 것임. 더 좋은 방법이 있다고 했을 때 대부분은 그 사실을 설득시키기가 어려움. 거부감이 많기 때문임. 직장생활을 할 때 당연히 겪게되는 문제이다.

하지만 위의 것들은 통제할 수 없는 외부 요인이다. 통제할 수 없는 것들은 깨끗하게 포기하고 스스로를 지키고 성장시킬 수 있는 방법을 터득해야만 한다.

1.4 개발자의 필수능력

깔끔한 코드

• 사람이 이해하기 쉬운 코드
• 변경이 용이한 코드
• 유지보수 비용이 낮은 코드

하지만 생각보다 코드 자체의 가독성에 관심없는 사람이 많다. 가독성 없는 코드에 오류가 발생한 뒤 그것을 내가 고쳐야한다..? 어떤 기업에서는 다른 사람이 짠 코드들을 다른 사람이 고치는 경우가 많다. 즉 쉽게 고칠 수 있는 코드가 필요하다. 따라서 개발자라면 매우 깔끔한 코드를 짤 수 있어야 한다. 컴파일 오류든 실행오류든 이딴거 필요없다. 사람이 이해할 수 있는 코드를 작성해야 한다. 이렇게 되면 코드 변경이 용이해져서 버그 수정도 편하고 얼마든지 다른 기능도 쉽게 추가할 수 있다.

신입개발자들 이력서를 보고 자신을 어떤 개발자라고 표현하는지를 보면 굉장히 모호할 때가 많다. 개발자로서 자신을 어필하기 위한 가장 좋은 방법은, ‘코드 깔끔하게 잘 짠다. 변경하기 용이한 코드를 잘짠다. 초등학생도 이해한다.’ 와 같은 말을 쓰는 것이다.

“코드를 지우는 사람입니다.” 라는 말에 엄청난 인상을 준 사람이 있었다. 개발자는 코드를 생산한다고 흔히 생각하는데, 그 분은 불필요한 코드를 줄이고 유지보수할 수 있는 코드를 짜는 사람이라는 이야기가 얼마나 내공이 높은 것인가.

적절한 논리력

• 원리 탐색 능력
• 제약조건을 고려한 해법
• 단순한 디자인

“절대 죽지 않는 웹서버를 만들 것이다.” 와 같은 극단으로 가는 것은 불필요하다. 엔지니어라고 한다면 현재 가용가능한 리소스를 가지고 적절한 동작을 하게 하는 것이 필요하다. 나는 이 기술을 많은 사람들이 썼으면 좋겠다고 생각해서 백만명을 수용할 수 있는 서버를 만들었는데 막상 오픈했더니 사용자가 열 명이다. 이러면 말짱도루묵이지 않은가. 따라서 적절한 리소스로 적절하게 문제를 해결하는 것이 가장 좋다. 원리를 잘 탐색하고 무작정 만드는 것이 아니라 제약조건을 고려한 해답을 찾고 단순한 디자인을 만들 수 있는 것이 가장 좋다.

1.5 깔끔한 코드 작성법

ATDD (Acceptance Test Driven Development)

TDD(Test Driven Development)

• 두 가지를 모두 잘 해야 한다.
• 둘 중에 하나를 선택해야 한다고 하면, 당연히 TDD가 될 것이다.
  • 테스트 코드를 만들어놓고 테스트 코드에 걸맞는 양의 코드만 생산을 하는 것임.

1. 사용하는 코드만 만들기 (Caller Create)
2. 리팩토링 (Refactoring)
3. 코드 읽기 (Code Review)

이 세 가지 원칙만 꼭 기억하자.

PR에서 변수명, 함수명도 제안하는 것이 매우 좋음. 대부분 코드리뷰에서 버그를 찾으려고 하는데, 보통의 경우 눈으로 봤을 때 버그를 찾을 수 있으면 매우 이상한 것임. 그러진 말고 ‘짧고 간결하게’ 어떤 작업을 했는지 적는 것이 좋음.

1.6 적절한 논리력

1. 알고리즘과 데이터 구조
2. 단순한 디자인
3. 진화적 디자인
4. 협업
5. 기술 벤치마킹

보통 가장 복잡한 케이스부터 고려를 많이 한다. 그러다보면 디자인도 매우 복잡해진다. 대부분의 경우 복잡한 문제들은 매우 작은 문제들의 집합이기 때문에, 복잡한 문제를 처음부터 고민한 것에 비해 작은 문제들부터 작성하는 것이 더 좋음.

코드 리뷰를 할 때는 공격적인 피드백이 매우 중요함. 그리고 계속해서 새로운 기술, 문제를 하기 위해 더 좋은 기술이 있는지 벤치마킹 해야 한다.

1.7 실천법

• 꾸준한 연습(Daily Practice)
• 매일 몸값 올리는 시간을 가져라.

취준 입장에서 우리의 동기부여가 무엇일까? 회사에서는 연봉올리는 것 등. 이런 동기가 있으면 시간 투자를 할 이유가 있다. 우리를 동기부여해주는 동기가 무엇인지 찾아보자.

• 멀리 가고 싶다면 함께 가라

혼자 실천하는 것은 어려운데 동료와 함께면 쉽다. 하기싫어하는 사람 아무나 붙잡고 하면 당연히 안됨!

• 현재 필요한 만큼만 하라
• 간단하게 하라

무엇을 하나 만들어야 한다고 하면 미리 하지 말고 현재 딱 필요한 만큼만 해라.

2. 좋은 개발자???

2.1 좋은 OO 개발자

“좋은” OO 개발자 (서버, 웹, 클라이언트, 임베디드, 모바일, 게임 등..)

불과 몇 년 전까지만 해도 AI 개발자는 취업할 곳이 없었음. 이렇듯 분야가 다양하고 시간 변동이 크다. 어느순간 표준화된 AI 모델이 나오고 나서 파인튜닝하는 것처럼 특별해지지 않을 수 있음. 나는 AI가 전부다! 라는 생각은 너무 위험함. 몇 년 뒤에는 너무 보편적인 기술이 될 수도 있기 때문. 도메인과 함께 망할 수 있기 떄문에 나는 어떤 개발자가 되려는 것에 유동적일 수 있어야 한다. 물론 도메인에 특별한 전문성이 있는 것도 중요하지만 리스크가 있음.

“좋은” 이라는 것은 공유와 협업이 잘 이루어지는 사람을 뜻한다. 협업 전혀 안되는데 코딩 졸라 잘하면 그 팀 내에서 주변에 있던 모든 사람들이 회사를 뛰쳐 나간다. 회사 입장에서는 굉장히 위험한 일이다. 그래서 많은 회사들이 협업 잘하는 개발자를 원하게 된다. 즉 좋은 개발자라는 것은 공유를 잘하고 협업이 잘 이루어지는 영역 내에서 말할 수 있다.

2.2 공유하는 이유

잘난척하는 거 절대 아님.

공유를 하는 가장 중요한 이유는, 주변이 똑똑해져야 내가 편해지기 때문이다.

• 사고를 수습하는 일이 줄어듬
• 중요한 일을 할 여유를 가질 수 있음.

주변이 똑똑하지 않으면 나의 일은 그 사람들이 친 사고를 급급하게 해결하는 것에 국한될 것이다. 그렇기 때문에 주변을 나보다 똑똑하게 만들기 위해 투자하는 것이 좋음.

투자를 하고 나면 좋은 평판을 얻을 수 있고, 그 좋은 평판은 나를 밥먹여준다. 이직을 할 때라던지. 좋은 평판을 받았다고 하면 주변의 추천도 많이 들어오고, 주변의 덕을 볼 확률이 올라간다.

2.3 공유 대상

무엇이든.

잘난 것만 공유해야 할 것 같지만, 실패를 공유하는 것도 중요하다. 내가 이렇게 해봤더니 개망했어. 라는 이야기를 공유하면 다른 사람들은 그 방법대로 하지 않을 수 있기 때문이다. 실패했다는 것은 창피한 것이 아니고, 그만큼 투자를 해서 값진 시행착오를 얻게 된 것이다.

새로운 기술을 공유했다라고 하면 그 기술을 시도해보고 장단점에 대해 명확하게 설명할 수 있어야 하는 정도는 되어야 한다.

2.4 협업의 전제조건: 상대를 이해하자

고슴도치도 제 새끼는 함함하다.

• 기획자의 입장에서, 기획자는 고객들이 원하는 것을 바탕으로 디자인을 만들거나 문서를 만들어낸다. 이러한 기획문서의 산출물을 개발자 QA 마케터 등 모두에게 공유하게 된다. 대부분 오 이거 쩐다!라고 하면 좋겠지만, 대부분 그렇지 않고 ‘이거 왜 해야 돼요?’라는 말을 듣게 된다. 기획 아이디어를 외부에 공유했는데 칭찬은 커녕 욕만 들으면 협업하기 빡친다.
• 개발자의 입장에서, 코드라는 산출물을 공유했는데 ‘이거 이상해요! 버그 있어요!’라는 말을 많이 하게 되는데, 이것도 개빡침. 열 개 잘되고 하나 안되면 열 개 잘된건 무시하고 하나 안된거에 대해서 콕 지적하고 지랄임.
• QA의 입장에서, 테스트케이스나 버그레포트를 썼는데 ‘그럴리가 없는데?’와 같은 반응을 얻게 됨.

2.5 협업의 필수요소

누구든 산출물에 대해 ‘이상하다’라는 말을 듣게 되면 이 새끼가 날 공격하나? 라는 생각이 들 수 밖에 없음.

자아존중감

• 자신이 존중받을 가치가 있다고 믿음.
• 있는 그대로의 자신을 인정함.
• 타인의 부정적 견해에 크게 영향 받지 않음.

결국에 협업을 잘하기 위해서는 자아존중감이 있어야 한다. 실패를 하건 실수를 하건 성공적인 일을 했건 내가 누구보다 위대하고 누구보다 쓰레기고 이런게 절대 아니다. 어떤 상황에서든 나는 나를 사랑할 수 있는 믿음이 있어야 함. 이것이 높으면 사람들이 협업이 잘 된다. 보는 개인의 입장에서 잘 상처받지 않고 상처받더라도 쉽게 회복할 수 있음.

우리는 앞으로 사고 졸라 칠거고 그것이 전혀 나쁜것이 아님. 지극히 정상적인 것인데 그런 사고들을 잘 겪고 이겨낼 수 있어야 한다.

3. 좋은 개발자!!!

이미지출처: http://ifather.tistory.com/category/재밌는세상?page=2