OKKY 세미나 참석 후기
안녕하세요. 어제 있었던 <비전공 학원출신 SI개발자, 유명스타트업 들어간.ssul> 세미나를 듣고 후기를 남깁니다. 정리하려고 적었다가, (전적으로 제 관점에서 적은 글이라 공감이 안 갈 수도 있지만) 흔적을 남겨도 좋을 것 같아 첫 글을 씁니다. 그렇다 보니 경어체가 아닌데 양해 부탁드립니다. 어제 성심껏 발표해주신 이종립 개발자님, 덕분에 많은 자극을 받았습니다. (제가 그렇게 되긴 힘들겠지만) 경험에 대한 공유, 정말 감사드립니다.
복붙했는데 글이 좀 지저분해졌네요..죄송합니다..OTL..
----------------------- 장소: 선정릉역 근처 eBrain |
강연자: 개발자 이종립 님
---
기억력이 별로 안 좋아서 중간중간 기억 안 나는 부분이 있지만, 복원해본다.
7시 15분까지 김밥을 준다고 해서, 10분쯤 도착했다. 단순 대여 장소로 생각했는데 꽤 깔끔했으며 개발 회사스러웠다. 김밥과 음료를 받았는데 맛있어서 기분이 좋아졌다. 강연 전 OKKYCON에 대한 홍보가 있었다. 그 주제는 개발자간 소통에 관한 것이라 했다. 예전에는 개발이 단지 Top-down 방식으로 업무가 할당되고 그를 구현하면 됐지만, 요즘엔 그렇게만 하진 않기에 개발자간 협업과 그를 위한 소통이 굉장히 중요하다고 했다. 예로 Agile에 대해 잠깐 언급했지만 난 이게 뭔지 잘 몰라서 흘려들었다. 이후 개발자 이종립님의 강연이 시작되었다.
1. 나는 누구인가?
어디서 자신을 소개할 때 Vim 사용자라 한다고 했다. '그렇구나..' 생각했는데 곧 질문이 들어온다.
"Vim을 들어보셨나요?"
처음엔 뭔지 몰랐지만 곧 회사에 있는 문서 중 Vim 관련 문서를 본 기억이 났다. '아...!' 그땐 몰랐는데, 강연을 듣고 왜 자신을 그렇게 규정했는지 알게 되었다. 쭉 타고 올라가 그 계기를 기억나는대로 적어보면 다음과 같다.
-(책이 잘 안 읽혀서) 무식한 방법이지만, 책을 타자로 쳤다.
-새끼 손가락 관절염에 걸렸다.
-코딩 속도가 원하는 만큼 나오지 않았다.
-해결책으로 Linux 사용자들이 사용하는 Vim이라는 텍스트 편집기를 발견했고 한 우물을 팠다.
(사실, 정확히 Vim이 뭔진 잘 모르겠다.)
결국 종합해보면, 새끼 손가락이 아파서 해결 방법으로 Vim이라는 것을 쭉 파게 되었는데 그것이 자신만의 무기가 되었고 지금 이 자리까지 오게 한 원동력이 되었다는 것이다. 그리고 그 배경에는 소프트웨어는 결국 인간을 편하게 하기 위해 존재하는 거라는 생각이 있었다. 그 외 내가 느낀 점은,
-말씀을 상당히 잘하신다. 그런데다 진솔하고 위트가 있으셔서, 인간적인 매력을 느낄 수 있었다.
(단적인 예로 보험을 팔기 위해 전화를 걸어 보험의 단점을 얘기하셨다고 했다.)
-인과 관계에 대한 파악이 분명한 논리적인 사람이다.
(어떤 문제 발생시 어디서부터 풀어나가야 하는지, 개발뿐만 아니라 그에 영향을 주는 인간관계까지 설계하신다는 느낌을 받았다.)
-거기에 더해 꼼꼼한 사람이다.
(잘 먹고, 잘 씻고, 건강해야 개발도 잘 할 수 있다고 말씀하신 부분에서 그렇게 느꼈다.)
-기준이 분명하고, 노력한다.
(상황에 휩쓸리지 않고 스스로 객관화 시키고 답을 찾는 모습, 그리고 스스로 생각한대로 밀고 나가는 모습이 더 인상깊었다.)
-개발을 원래 잘하는 분일 수도 있겠다.
(국비 지원에서 뭐든 제일 먼저 풀었다고 하신 점과 입사 후 직장에서 코딩을 제일 잘하게 되셨다고 하신 부분에서 그렇게 느꼈다.)
넓고 깊은 사람 같았다.
*
https://github.com/johngrib
https://www.slideshare.net/ssuser69b63d1/ss-82150195
2. 조언
개발에 대한 조언일 수 있지만 개인적으로는 더 넓게 받아들였다. 내가 재능이 없거나, 재미가 없어서 다른 일을 하게 되더라도 밥 벌어먹고 살기 위해선 기억해야 할 것 같은.
2-1. 집단에 융화하기
이종립님은 개발자가 되려면 개발자스럽게 생각하고 행동해야 한다고 생각하셨다고 한다. 그 집단처럼 생각하고, 행동해야지 그 집단의 인정을 받을 수 있다고 생각했다고 한다. 일례로 개발자가 된 이후로, 소프트웨어의 불법 다운로드 등을 절대 하지 않고 모두 정품을 사서 사용했다고 한다. 그 과정에서 타인의 저작권을 중요시하는 좋은 습관이 들었다고 한다.
이 생각(집단에 속하려면, 그 사람들처럼 생각하고 행동해야 하는 것)은 자신의 몇몇 경험에서 나왔다고 한다. 예로, 막노동판에 가면 그 사람들만 쓰는 용어들이 있다고 한다. 못 알아듣는 사람을 그들은 '초짜'라고 한다고 했다. 마찬가지로 생각했다고 한다.
-투입되었을 때 그들(현업, 전공자)이 말하는 단어를 알아듣지 못하면 초짜로 낙인찍힐 것이다.
-그렇다면 무시당할 것이다.
-그렇다면 중요한 일이 내게 오지 않을 것이다.
-월급이나 기회도 감소할 것이다.
따라서 가장 먼저 한 것은 그들의 언어를 익히는 것(이 부분에서 지금 나의 공부 방향이 약간 잘못되었다는 것을 느꼈는데, 고칠 수 있을지..)이었다. 따라서 대학 커리큘럼을 뽑아서 과목 별로 빌려 보았다. 중요한 점은 (물론 내용도 읽었지만) 인덱스를 중점적으로 보았다는 것이다. 인덱스를 기억하면, 만약 내가 모르는 내용이라도 들었을 때 집에서 빠르게 찾아보고 공부할 수 있다고 판단했기 때문(이렇게 실시간적인 피드백이 가능할까, 생각이 들었다..)이다.
2-2. 기준이 분명해야
기준, 스스로 세운 규칙 정도로 생각하면 될 것 같다.
얼마 전, <소프트웨어 집단의 부패: Expert Beginner의 유산>*이라는 글을 읽었는데 내가 받아들기로 그 글의 내용은 한 집단, 보통 회사의 사수에 따라 더 발전할 수 있는 사람이 성장을 멈추게 된다는 것이다. 좋든 싫든 개인은 그가 속한 집단의 영향을 받을 수밖에 없으니까. 좋은 사람들이 모인 곳에 있으면 더 발전할 수 있다는 것은 학창시절에도 느껴왔기에, 공감하며 읽었다.
그런데 이종립 님은 좀 특이한 케이스였다. 단지 업무를 이상없이 수행하는 것에 멈추지 않고, 내가 회사에서 가장 뛰어난 코드를 짠다는 것을 알게 되었을 때 밖으로 나왔기 때문이다. 그 동력이 습관, 그리고 그 습관을 만들어준 불안감 및 성향이 있을 것이다.
여기서 내가 배운 것은 모든 기준은 '스스로'로부터 나와야 한다는 점이다.
*
https://medium.com/@jwyeom63/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%A7%91%EB%8B%A8%EC%9D%98-%EB%B6%80%ED%8C%A8-expert-beginner%EC%9D%98-%EC%9C%A0%EC%82%B0-9d226b6ebde2
2-3. 나 자신의 무기가 있어야
말이 쉽지 (나는 저렇게 되기가) 현실적으로 쉽지 않다고 느낀 것은 몇 가지 예를 듣고 였다.
-마지막에 투입됐던 정부 기관 프로젝트에서 PM이 급하게 사인을 요구했다.
-하지만 나는 보험했던 사람이다. 내용을 보기 전엔 사인할 수 없기에 화장실 다녀온다고 하고 도망!
-PM이 없는 틈을 타, 주변에 회사 상황을 가장 잘 아는 사람 중 내게 도움을 줄 수 있는 사람(A)을 파악했다.
-커피 한 잔을 뽑아 급하게 가서 도움을 요청했다.
-대충 내용 파악 후 상황을 인지했고, 이후 PM과 싸웠다.
-A를 찾아가 도움을 청하던 중 보니, 비효율적으로 개발하고 있는 부분을 발견했다.
(어떤 자동화 프로그램을 개발해주셨다고 했는데, 창피하지만 잘 못 알아들었다. =_=;)
-도움을 주자, 굉장히 좋아했고 PM과 대등히 싸울 수 있게 되었다.
위에서 비효율적으로 개발하고 있는 부분을 발견하고, 그 부분을 개발해주었다고 하는 부분이 중요하다고 느꼈다. 눈치야 누구나 볼 수 있지만 Give가 있어야 Take가 있는데, 결국 실력이 기본이 되어야 모든 게 가능하다고 느껴서 쉽지 않겠다고 느꼈다. 그 외 기억나는(내가 못하기에...) 몇 가지는 아래와 같다.
Q. 고객이 요구 사항 외의 것을 요구할시 어떻게 대응했는지?
A. "절대" 거절하지 않았다. 대신 생색을 많이 냈다.
추가. 먼저 친분을 쌓은 후, 그(짠 코드)에 대한 설명을 꼭 해줬다. 먼저 친분을 쌓지 않으면 설명을 들으려 않기 때문이다. 이후 설명 과정에서 부족한 부분이 발견되면 솔직하게 그 부분에 대해 부족했음을 시인하고, 수정한다. 이때 상대에 따라 수정사항 이상을 요구하는 사람이 있고 그렇지 않은 사람이 있는데, 다음과 같이 대응한다. 먼저 요구사항 이상을 요구할 경우, 해주는 대신 내가 하고 싶은 언어로 구현해본다. 이후 코드에 대해 설명해주면 고맙다는 답변이 돌아온다. 그렇지 않을 경우, 이때도 역시 시간이 남으면 해준다고 하고 마찬가지로 구현한다. 그러면 고맙다는 답변이 돌아오고, 해당 사이트에서 좋은 평가를 받게 된다.
Q. 고객사에서 주어진 개발 외 다른 공부를 하게 되면 눈치가 보이진 않았는지?
A. 우선 첫째로, 할당된 업무를 남들보다 빨리 끝냈기에 공부할 시간이 있었다. 둘째로는 평소 친분을 잘 쌓아놨기에 다른 책을 보더라도 눈치를 볼 필요가 없었고 그들이 쉴 때 나도 쉴 수 있었다.
추가1. 저 사람으로부터 내가 뭘 빨아먹을 수 있을까, 에 대해 생각해본다.
(타인도 나에 대해 그렇게 생각할텐데 나는 빨아먹을게 없는 거 같아 걱정이...)
추가2. 만약 고객사 사람들이 어리숙(?)하다면 꼭 회사에 회신 메일을 부탁드렸다.
추가3. 회사에서 모를 때, 타인에게 만든 문서 확실하게 본다. 그래도 모를 땐 모르겠다고 솔직하게 말한다.
(단, 모르겠다고 하면 혼나지만 잘 모르겠으니 알려달라고 하면 배운다.)
3. 습관
이 외, 낙원으로 이끌어준 좋은 습관들 몇 가지가 있었다.
-일년마다 하나의 언어를
-일주일마다 스스로에게 제출하는 하나의 보고서를
-TDD: 우아한 형제들의 면접에서 언급했던 내용으로 대표님께서 "우리 직원들에게 전파해줬으면 좋겠다"고 한 부분이라고 한다.
(역시 자신만의 무기가 있어야..)
-이력서는 항상 2가지 버전으로
-doc, pdf
-합격을 당연하게 받아들이지 않았: 3가지 조건
-연봉 높여부르/술x/공부 방해x
4. 추천도서
-Code Complete 2/E
-<18장. 테이블 기반으로 생각하기> 꼭 보라
-TDD
-실용주의 프로그래머
-독서를 하지 않으면 기술적으로 발전하기 어렵다.
-"습관"에 대하여
-자바스크립트 핵심 가이드
-프로그래머의 길, 멘토에게 묻다.
기회가 왔을 때 놓치지 않도록 "꾸준히" 관리해야 한다.
