- 비즈니스를 잊지 않길
개발자는 비즈니스 문제를 기술로 풀어내는 사람이다.
많은 취준생, 주니어들이 착각하고 있는게 있다. 개발자가 회사에 입사하게 되면, 자신의 머릿속에서 그려지는 참신하고 새로운 아이디어, 새로운 기술을 적용하는 것 등 무언가 새로운 것을 만들어내는 일을 주로 하지 않는다. 하루종일 코드만 작성하고 있지도 않는다. 여러분이 생각하는 것보다 누군가와 소통하는 것이 많은 시간을 차지하게 된다.
개발자는 내가 몸담고 있는 회사의 비즈니스 과제를 구현해내는 역할을 한다. 과제를 해결하기 위해서 기획자와 회의를 하면서 요건의 방향성을 잡아나갈 수도 있고, 다른 개발자들과 함께 요구사항 분석과 개발일정, 비용에 관한 회의를 통해서 개발 과정을 구체화한다. 그렇게 내가 할 '일'이 명확해지고 나면 비로소 코드를 작성하게 된다.
이 모든 과정이 '비즈니스 과제' 라는 하나의 목표를 바라본다.
하나의 예를 들어보자. 어떠한 목표물도 맞출 수 있는 사격수가 있다고 치자.
총알이 빗발치는 전장 가운데에 이 사격수를 떨어뜨려보자. 이 사격수는 어떤 역할을 할 수 있을까? 아마도 그는 아무것도 못한채 전사할 확률이 상당할 것이다.
우선 그에게는 자신이 어떤 진영에 속해야 하는지도 모른다. 무슨 무기를 사용하게 될지도 모른다. 설령 어떤 진영에 속해있는지 알고, 무기도 지급받았다 할지라도 어떤 목표를 쏴야하는 지를 모를 것이다. 우리가 장군이라면 훌륭한 사격수를 그렇게 배치하지 않을 것이다. 좋은 장비와 특화된 작전 지시로 그가 가진 역량을 최대한 발휘해서 전투를 승리로 이끌기를 바랄 것이다.
여러분이 맡게되는 업무가 전투라고 생각해보자.
제일 우선적으로 생각해야하는 것은 목표 다.
전투에서는 승리일 것이고, 업무에서는 특정 서비스의 출시 혹은 서비스의 성능 향상, 오류해결 등이 될 것이다. 이 목표를 해결하기 위해서 우리는 어떻게 전투를 시작해나갈지 설계를 해야 한다. 설계를 바탕으로 어떤 루트로 목표를 공략할지 정하고, 각자 장비를 들고 각자의 위치로 이동한다.
자신의 역할을 수행하면서 발생하는 문제점이나 실시간 상황등을 서로에게 공유하고 전략을 유동적으로 수정하면서 목표에 한 걸음씩 다가간다.
그 과정에서 적을 제거하고 길을 뚫는 것(Coding)은 당연한 것이다. 내가 지나가는 길이 아군이 따라오기 쉽게(Clean Code, Clean Architecture, Documentation) 다듬어 놓으면 더없이 좋다.
- 코드에 진심이 되어라
"신입 / 주니어 개발자는 코드에 진심이어야한다."
C 회사의 개발본부장님과의 면접에서 들은 말이다.
N사, 세계적인 게임회사 등을 거쳐온 분께서 주니어는 코드에 진심일 필요가 있다고 하셨다. 요즘은 MSA(Micro Service Architecture) 라는 말은 흔하게 들어볼 수 있다. 대학에 다니고 있는 후배들과 이야기를 해봐도 MSA를 모르는 사람이 더 드물 정도였다. MSA뿐 아니라 여러 소프트웨어 아키텍쳐들에 대해서 많은 사람들이 관심을 가지고 공부하고 있다. 본부장님께서 다음과 같이 말하셨다.
'다들 아키텍쳐의 필요성을 느끼지 못하면서 아키텍쳐를 설계하고, 개발해보았다고 말한다.'
취업을 하는 과정에서 조금 더 상세히 말하겠지만, 나는 이미 본부장님께서 그렇게 생각하고 있다는 것을 알고 있었다. 알고 있음에도 직접 생각을 듣는 것은 또 달랐다. 내가 아키텍쳐의 필요성을 유튜브나 구글을 통해서 듣고 읽어서 이해한 것과 실무에서 아키텍쳐가 없으면 안되겠다고 느낀 것은 천지차이라는 것이다. 본부장님이 말한 필요성은 나의 프로젝트, 나의 시스템에서의 필요성을 말한 것이었다.
이러한 필요성은 경험 없이는 만들어질 수 없다. 수많은 코드를 짜보고, 많은 문제에 부딛혀보고, 해결하기 위해서 고민하다보면 어느새 아키텍쳐를 필요로 하게 될 것이라고 하셨다. 그렇다면 그동안 주니어는 무엇을 하면 되는가?
적을 제거하고 길을 뚫으면 된다. 단, 나의 아군들이 함께하기 편하게, 뒤따라오기 편하게 말이다.
내가 오늘 작성한 코드는 나만 보지 않을것이다. 나 이후로 수많은 사람들이 그 코드를 읽고, 수정하고, 참고할 것이다. 비즈니스 로직을 이해하기 위해서 일수도있고, 코드 작성 방법을 참고하기 위해서 일수도 있다.
남들이 보기 쉬운 코드란 어떤 것일까? 기술적인 방법은 로버트.C.마틴의 Clean Code를 읽어보길 바란다.
기술적인 방법론이 아니더라도 내가 말할 수 있는 남이 보기 쉬운 코드는 내가 작성한 변수명, 함수명, 로직들을 읽는 사람이 나에게 물어보지 않고도 알 수 있는 코드이다. 여러 사람들에게 사전 설명 없이 내 코드를 보여줘라. 엄청나게 많은 구멍들이 발견될 지도 모른다. 적어도 나는 그랬다.
- 코드리뷰 : 사라진 코드들
내가 회사에서 처음 작성한 안드로이드 소스코드는 작성한지 10분만에 다 사라졌다.
정확히 말하자면, 원래의 형체를 찾을 수 없을 정도로 분리되고, 분산되었다.
하나의 함수로 뭉쳐져있던 것들은 기능별로 분리되어, 각기 다른 패키지나 클래스로 이동했고, Exception을 고려하지 않았던 코드들은 try...catch문이나 if문을 통해서 예외처리 하도록 바뀌었다.
코드 리뷰가 익숙하지 않았던 나는 충격이었다. 누군가가 내 코드를 볼 때의 기분은 아주 어린시절 대충한 일기를 선생님이 검사하는 것 같은 느낌이었다. 다행히도 나는 비난과 혹평보다는 제안하는 분위기의 코드리뷰를 해주신 팀장님 덕에 코드리뷰에 대한 두려움의 벽이 많이 낮아졌다.
그 뒤로, 남들의 코드를 더 많이 보면서 왜 이렇게 작성했을까? 어떻게 하면 더 효율적이고 이해되기 쉽게 작성할 수 있을까 고민하는 좋은 계기가 되었다.
최종합격한 C회사의 기술면접에서 코드리뷰를 한 적이 있다.
나는 채용프로세스에서 면접에서 코딩테스트를 리뷰한 적은 처음이었다. 구두로 코딩테스트가 어땠는지, 어떤 부분이 어려웠는지에 대한 질문을 받은 적은 있었지만, 기억도 가물가물한 내가 작성했던 코드를 다시 마주하리라곤 생각도 하지 못했다.
약간의 시간동안 내 코드의 로직을 설명했다. 그리곤 면접관께서는 질문을 했다.
"노아님이 이 소스를 처음 보는 동료라고 생각하면 어떤 부분들을 수정할 수 있을까요?"
사용한 자료구조, 변수명, 주석들을 전부 샅샅이 훓어가며 코드를 리뷰했다. 하지만 비슷한 질문들을 받아본 경험들이 있었기에 당황하지 않고, 면접관과 소통하며 코드리뷰를 마칠 수 있었다. 긴장되고 힘들었다기보단, 저렇게도 생각할 수 있겠구나 하는 생각과 함께 또 하나를 배워간다는 생각이 들었다.
이 글을 읽는 주니어들 중 나처럼 코드 리뷰가 두려웠던 분들이 있다면, 어떠한 코드든 상관없다. 주변 사람들에게 내 코드를 설명없이 보여줘라. 나의 경우 입사 동기였던 형에게 보여주었고, 고맙게도 동기 형은 언제든 코드에 대한 고민을 함께 나눠주었다. 그런 고민들을 하고, 다른 사람과 나누는 것이 코드에 대한 나의 진심을 보여줄 것이라고 생각한다.
