삼성전자

개발을 시작하는 과거의 나에게 하는 조언  |  Gergely Orosz의 회고를 의역/요약한 글입니다. --- 과거를 좀 회고해보면, 좀 더 빨리 시작했으면 좋았을 것들이 종종 생각납니다. 빠르고 효율적인 성장을 도와주는 습관들이요. 이 회고는 개발자로 첫 발걸음을 뗀 과거의 나에게 하는 조언입니다. "시간을 내어 소프트웨어 엔지니어링에 대한 책을 매년 2권 읽어라" 시간을 내어 개발 관련 서적을 읽을 때면, 한 단계 더 성장한 것을 느꼈습니다. 여기서 “책을 읽었다”는 노트로 정리도 해보고, 책에 대해 다른 사람과 논의하고, 다이어그램을 그리고, 시도해보고, 다시 읽어보는 것을 뜻합니다. 개발 커리어 초기에 좀 더 많은 책을 읽을 걸이라고 가끔 후회합니다. 제가 추천하는 건 무엇이 되었든 현재 본인이 알고 있는 것보다 좀 더 깊은 단계의 깨달음을 얻을 수 있는 서적을 읽는 것을 추천합니다. 이는 기술적인 부분이 될 수도 있고 개발 방법론 같은 것이 될 수도 있습니다. 이런 책을 읽을 때는 빠르게 읽기보단 천천히 하나씩 이해하면서 넘어가려고 합니다. 보통 한번에 많아야 한 챕터 내지 두 챕터를 읽고, 읽은 것을 정리하고, 다른 사람과 논의합니다. 지난 몇 년 동안 이 습관을 형성했는데 이는 제가 개발자, 매니저로 빠르게 성장하는데 큰 도움을 주었습니다. 블로그나 비디오 대신 왜 책이냐고요? 제가 느끼기에 짧은 형태의 매체는 중요한 것을 매우 짧게 알려주거나 스쳐지나가는 것 같습니다. 그에 반해 책은 좀 더 심도 있고 내용에 깊이가 있습니다. 그렇다고 너무 욕심을 내어서는 안됩니다. 책을 제대로 읽는다고 가정했을 때 6개월에 한 권도 충분합니다. "사용하는 개발 언어를 정말 깊이 탐구해보고 이해해라" 저는 처음에 PHP로 개발을 시작했고 약간의 JS를 할 수 있었습니다. 대학교에서는 C와 C++에 대해서 배웠고 첫 직장은 C#으로 개발했죠. 언어를 여러 개 할 수 있었지만 제대로 아는 건 하나도 없었습니다. 2년이 지나고 C#에서 좀 복잡한 버그를 만날 때 마다 시니어 개발자에게 의존해야하는 게 짜증났습니다. 신기하게도 시니어 개발자는 C#의 세세한 부분까지 다 알고 있었습니다. 그는 저에게 C#을 좀 더 공부해보라면서 책을 한 권 추천해줬고 저는 그의 추천서를 읽고 공부했습니다. 스레딩부터 시작해서 가비지 콜렉션, 제너릭 등 정말 어려운 주제까지 이해하려고 몇 시간씩 투자했습니다. 사용하는 개발 언어를 깊게 공부한 건, 제가 가장 잘 한 일 중 하나입니다. 저는 첫 직장에서 우연히 터득하게 된 것이지만, 이는 회사 일과 추후 다른 회사 면접 볼 때 유용하게 쓰였습니다. 이후 스카이프에 취직했을 때는 C# 개발자로 취직했지만 JS와 WinJS로 마이그레이션 하면서 해당 툴을 깊게 공부했고 WinJS 강의를 하기까지 했습니다. 더 많은 개발 언어를 알고 있으면, 각 언어의 장단점을 파악하고 적재적소에 사용할 수 있습니다. iOS가 나왔을 때 쯤에는, 이미 여러 개발 언어를 접한 상태였습니다. 이후 Swift가 나왔을 때, 개발 언어에 기여할 수 있었고 언어적 특징을 알고 있었기에 추후 Objective-C를 Swift로 마이그레이션 하는 과정에서 어떤 전략을 취해야 할 지 잘 정할 수 있었습니다. 그리고 더 많은 언어를 알 수록, 새로운 언어를 이해하는 것이 쉬워집니다. "다른 개발자들과 더 자주 같이 개발하라" 요즘은 같이 개발하는게 더 이상 유행이 아닌 것 같습니다. 제가 개발을 시작했을 때만 해도 익스트림 프로그래밍, TDD, mob 프로그래밍 등이 유행이었습니다. 다른 개발자와 함께 프로그래밍한 몇 몇 경험은 저를 비약적으로 성장 시켜줬습니다. 이는 책으로 얻을 수 있는 것보다 가치 있었습니다. 기억나는 사례는 모든 사람에게 날카로운 피드백을 남기던 개발자와 같이 개발한 경험입니다. 하루는 이런 피드백에 진절머리가 나서 코드 리뷰 툴에 댓글을 남기는 대신 그의 옆에 앉아 남긴 댓글에 대해 설명해 달라고 부탁했습니다. 결론적으로 저는 많은 것을 배웠고 동시에 그가 남긴 댓글들이 일리는 있지만 동의하지 않는 부분도 있다고 말해줬습니다. 그는 이를 받아들였고 동일한 상황이 또 발생하면 같이 이렇게 논의하는 시간을 갖자고 했습니다. 그는 성능을 최우선으로 생각하는 개발자였고 성능을 위한 코드 리뷰를 많이 남겼습니다. 이런 부분에서 저는 많이 배웠습니다. 반대로 저는 성능을 일부 포기하더라도 좀 더 유지 보수가 용이한 코드를 그에게 알려줬다고 생각합니다. 또 다른 사례는 다른 개발자와 TDD로 개발한 것입니다. 하나의 키보드로 한 명이 테스트 코드를 쓰면, 다른 한 명이 프로덕션에 배포할 로직을 짜는 것이었습니다. 우린 이걸 이틀 동안 했고 시스템에서 상당히 까다로운 부분을 개발했습니다. 이런 방법이 얼마나 놀라운지 표현하기는 어렵습니다. 우린 개발 도중 엄청나게 많은 예외 사항을 발견하고 중간에 새로운 방법을 도입했습니다. 우린 이틀 동안 개발하면서 몇 달 간 지속된 끈끈한 유대감을 형성했습니다. "유닛 테스트를 작성하고 CI에 넣어서 테스트 해봐라" 시니어 개발자들은 종종 유닛 테스트의 중요성을 강조합니다. 근데 뭔가 이상합니다. 테스트를 작성하는데 그렇게 공 들일 필요가 있을까요? 심지어 메인 로직보다 더 시간을 투자하면서 말이죠. 저는 한동안 이런 생각이 지배적이었습니다. 유닛 테스트의 중요성을 알려면, 자기가 적은 유닛 테스트가 구사일생 해주는 “아하!” 순간이 필요합니다. 하지만, 이런 “아하!” 순간을 접하려면 때로는 몇 달 동안 유닛 테스트를 작성하고 CI에 넣어서 테스트 해야 할 수도 있습니다. 저는 이런 순간이 두 번 정도 있었습니다. 하나는 사이드 프로젝트로 작은 온라인 카지노 사이트의 백엔드 엔진을 구현할 때 였습니다. 실제 돈이 오가는 프로그램이라 저는 걱정되는 부분이 상당히 많았고 프로젝트 전체적으로 테스트 코드를 덕지덕지 붙였습니다. 예상보다 늦게 고객에게 API를 전달하게 되었지만 그만큼 테스트 코드가 필요하다고 생각했습니다. 2년 뒤 고객으로부터 피드백이 왔는데, 테스트 코드 덕분에 프로덕션에 배포할 뻔한 버그를 잡은 게 한 두 번이 아니라고 했습니다. 다른 하나는 스카이프를 웹으로 만들 때였습니다. 당시 개발 팀은 능력이 출중했고 코드 베이스 전체를 커버하는 유닛 테스트와 통합 테스트도 있었습니다. 프로젝트를 시작하고 3개월 뒤, 한 엔지니어가 전체 프로젝트 구조를 리팩토링 해야 한다고 주장했습니다. 리팩토링 자체가 위험 부담이 커서 우리 모두 반대했지만 그는 잘 짜여진 테스트 코드들이 있으니 믿고 해보자고 했습니다. 우린 의심스러운 마음으로 리팩토링을 시작했고 일주일 뒤 아예 바뀌어버린 구조로 제품을 배포했지만 그의 말대로 테스트 코드를 성공하니까 아무 문제도 없었습니다. 그때 저는 잘 짜여진 테스트 코드의 중요성을 깨닫게 되었습니다. 테스트 코드만 잘 짜여져 있다면, 위험해 보이는 리팩토링도 시도할 수 있습니다. "리팩토링을 습관화하고 리팩토링 툴을 연마해라" 아주 오랜 기간 동안 개발 팀에 속해 있으면 저는 최소한의 코드 변경도 심사숙고해서 하는 편이었습니다. 개인 프로젝트에서는 리팩토링 쉽게 할 수 있지만, 팀이 관리하는 코드 베이스라면 쉽게 하지 못했습니다. 그러다가 스카이프에서 한 시니어 개발자를 만났는데 리팩토링을 밥 먹듯이 하는 것이었습니다. 어떻게 이렇게 리팩토링을 자주하면서도 부서지는게 없지? 라는 생각이 들 때 쯤 그와 같이 개발하는 기회를 얻게 되었는데 그때 깨달았습니다. 그는 IDE에 리팩토링 관련 툴들이 이미 많이 깔려있었고 이를 활용해서 함수를 추출하거나, 변수 명을 바꾸거나, 변수의 타입을 바꾸는 등 몇 초안에 휙휙 리팩토링을 할 수 있었습니다. 제가 리팩토링을 꺼려하니 리팩토링에 대한 툴도 모르고 리팩토링이 습관화 되지 않았던 것입니다. 주기적으로 리팩토링을 습관화 하니까 점점 툴에 익숙해졌고 이를 더 빨리 시작하지 않은 것을 후회했습니다. "좋은 개발 방법은 경험에서 온다. 최대한 많이 경험해봐라" 처음 개발을 시작했을 때 시니어 개발자들을 보면 신기했습니다. 제가 보지 못하는 버그를 잡아내고, 하나도 모르겠는 주제에 답을 척척 내놓고, 단순히 그들이 저보다 더 똑똑하고 나은 줄 알았고 그렇게 받아들였습니다. 이제는 많은 개발자들과 일해봤고, 코치하면서 배운 건데 신기해 할 필요가 없었습니다. 최고의 개발자들은 지식과 현실 경험의 적절한 조화로 만들어진 것이었습니다. 지식은 배울 수 있지만 경험은 직접 찾아다녀야 합니다. 다른 개발 스택, 다른 도메인, 어려운 프로젝트를 찾아다녀야 합니다. 저는 제가 정의한 “시니어” 레벨로 가기까지 7년 내지 8년 정도 걸렸습니다. 우버처럼 빡센 직장에서 3~4년 만에 그 “시니어” 레벨에 도달하는 사람들을 봤습니다. 차이가 뭐냐고요? 그들은 어려운 프로젝트를 맡으면서 성장했고 중간에 여러 팀들을 오갔으며 새로운 프로젝트가 생기면 솔선수범 해서 새로운 기술 스택을 사용해보기도 합니다. 저도 현재는 그런 유형의 사람이지만 커리어 초반 몇 년 동안은 소극적이었습니다. "배운 것을 가르쳐라" 배운 것을 익히는데 가르치는 것만큼 좋은 것은 없습니다. 전 우연한 계기로 2010년 쯤 .NET과 Windows Phone 유저 그룹에서 발표하기 시작했습니다. 물론 발표는 형편 없었지만 준비하는 과정 자체로도 많은 것을 배웠습니다. 요즘은 정말 제대로 배우고 싶은 것이 있다면, 공개적으로 발표를 하려고 찾아봅니다. 2017년에 우버 관련 발표를 자원했고 전 우버에 입사한 지 갓 1년이 되었을 때 입니다. 심지어 전 모바일 팀이었고 관련 발표는 백엔드 변경을 확장성 있게 가져가는 방법에 대한 것이었습니다. 당연히 해당 부분에 대해 잘 알고 있지 못했습니다. 하지만, 해당 이벤트에 수 백명이 올 것을 알고 있었기에 저는 세세한 부분까지 공부했습니다. 다른 분들도 공개적인 발표나 가르침으로 더 많은 것을 배운다는 것에 동의합니다. Shawn Wang의 이야기는 저보다 더 흥미롭습니다. 4년 만에 직군 변경부터 Netlify 와 AWS에서 시니어 롤을 역임하기까지와 그가 배운 것을 책으로 집필했습니다. 다른 이들을 가르친다는 것에 가장 큰 장점은 잃을 게 없다는 것 입니다. 가르치면서 얻는 배움도 있지만 다른 이들에게 좋은 영향을 미칠 수도 있습니다. 그리고 좋은 개발자 중 좋은 선생이 아닌 사람은 못 봤습니다. 배운 것을 가르치고 나누는 것을 다 빨리 하면 할 수록 더 익숙해질 것 입니다. --- 원글: https://blog.pragmaticengineer.com/advice-to-myself-when-starting-as-a-software-developer/

좋아요 18 • 저장 16