안녕하세요 😀
헤렌 공비서 팀 백엔드 개발자 버디입니다.
저는 헤렌에서 개발자 커리어를 시작했습니다. 5월 10일에 입사했으니, 다음 주면 입사한 지 2개월 차가 됩니다. 입사 후에 한 달 반 정도는 적응하는 데 정신없이 시간을 보낸 거 같습니다. 주로 서포트 업무를 담당하면서 조금씩 서비스 코드와 인프라 구조를 파악해 나갔습니다. 그러다가 드디어! 처음으로 작은 기능 개발을 담당하게 되었습니다.
맡게 된 기능은 새로운 회원 탈퇴 API 개발과 기존 탈퇴 로직의 개선 작업이었습니다. 비교적 간단한 작업이었지만, PR 후 Merge에 이르는 과정은 꽤나(?) 험난했습니다. 코드양이 그리 많지도 않았고, 요구사항도 간단한 편이었지만 무려 72개의 코멘트를 주고받은 후에야 운영 서버에 배포할 수 있었습니다.
창의력마저 느껴지는(?) 근본 없는 코드가 PR페이지를 뜨거운 참여의 장으로 만들었습니다.
처음 기능 개발을 맡게 되었을 때, 드디어 무언가 해본다는 기쁨도 있었지만 사실 무엇보다 코드 리뷰가 기대되었습니다. 블로그나 강연을 통해 코드 리뷰 문화의 중요성을 강조하는 분들을 많이 보았지만, 정작 한 번도 경험해 본 적이 없었습니다. 개발자 지망생 시절, 학원이나 부트 캠프를 다니지 않고 혼자 공부했기 때문에 경험과 노하우가 많은 개발자분의 피드백은 어떤 내용일지 무척이나 궁금했습니다. 개발자에게 코드 리뷰 문화는 최고의 성장 환경이라고 하는데, 그 말의 참 의미를 느껴보고 싶었습니다.
결론부터 말씀드리면, 왜 많은 분이 코드 리뷰를 강조했는지 확실하게 느껴볼 수 있었습니다. 동료 개발자분들이 남겨주신 코멘트 하나하나를 읽어 보면서 "아하!" 의 순간도 있었고, "왜 이런 것도 생각하지 못했을까" 싶을 때도 있었습니다.
첫 번째 코드 리뷰를 경험하고 나니 블로그에 글을 써야겠다는 생각이 들었습니다. 신입 개발자가 코드 리뷰를 통해 구체적으로 무엇을 배울 수 있는지 궁금했던 분이라면 흥미로운 내용이 될 거 같았습니다. 아울러 헤렌의 신입 개발자는 어떤 피드백 문화 속에서 성장하고 있는지 공유하고 싶습니다.
코드 리뷰 과정에서 다양한 피드백을 받을 수 있었습니다. 내용이 많기는 했지만, 전체적으로 피드백 받은 내용을 쭉 훑어보니 크게 3가지 메시지로 정리가 되었습니다. 구체적인 피드백 내용과 함께 어떤 생각이 들었는지 솔직하게 공유해 보려고 합니다.
제가 첫 번째 코드 리뷰를 통해 배울 수 있었던 3가지 교훈입니다.
첫 번째 코드 리뷰를 통해 많은 것을 배울 수 있었지만, 그중에서도 나에 대한 객관적인 인식(메타인지)을 도와줬던 피드백이 많았습니다. 어설프게 알고 있으나, 정작 실천하지 않았던 기본기에 대한 피드백입니다. 프로그래밍을 한 두 달만 공부해도 null 처리와 예외 처리가 중요하다는 것을 알게 됩니다. 저 역시 인강과 여러 블로그 글을 통해 null 처리과 예외 처리의 중요성을 알고만 있었습니다. 하지만 코드 리뷰를 통해 기본기를 아는 것과 그것을 체화하고 자연스럽게 코드에 적용하는 것은 다르다는 것을 배울 수 있었습니다.
테스트 도중 null로 인한 버그가 발생했습니다.
더 나은 null 처리 방식에 대한 피드백도 받을 수 있었습니다.
예외 처리가 필요하다는 코멘트에 이어, 적합한 에러 메시지 사용에 대한 피드백도 받을 수 있었습니다.
저는 피드백 내용을 통해 어느새 잊어버리고 있었던 기본기에 대해 자각할 수 있었고, 다음부터는 null과 예외 처리만큼은 확실하게 확인해야겠다고 생각하게 되었습니다.
헤렌은 뷰티 사업자의 비즈니스 성장을 돕는 공비서를 서비스하고 있습니다. IT 서비스 회사의 개발자는 서비스 운영 업무의 비중이 크기 때문에 신규 개발만큼 기존 코드를 읽거나 수정하는 데도 많은 시간을 사용합니다. 여러 명의 개발자가 작성한 코드를 읽고, 이해하는 작업은 쉽고 명확한 코드를 작성하는 것만으로도 효율을 크게 높일 수 있습니다. 그러다 보니, 자연스럽게 클린 코드를 중요시하고, 코드의 표현 방식을 통일하기 위해 컨벤션을 정립해나갑니다. 저 역시 첫 번째 코드 리뷰를 통해 몰랐던 컨벤션을 확인할 수 있었고, 심지어 새로운 컨벤션이 만들어지는 과정까지 경험해볼 수 있었습니다.
쉽고 명확한 코드 소통을 위해서는 컨벤션을 준수해야 합니다.
헤렌에서는 그동안 합의된 컨벤션이 없었다면 공개적인 논의를 통해 새로 만들기도 합니다. 헤렌의 개발 문화는 컨벤션에 대한 의견이 있다면, 누구나 자유롭게 제안할 수 있습니다.
by사용에 대한 피드백 과정에서 새로운 컨벤션 요소가 발견되었습니다.
피드백 내용을 기반으로 슬렉에서 빠르게 논의가 진행되었습니다.
by사용에 대한 새로운 컨벤션이 탄생하는 순간이었습니다.
꼭 컨벤션이 아니더라도, 메서드의 명확한 표현을 위해 어떠한 표현 방식이 더 적합한지 피드백을 받을 수 있었습니다. 쉽고 명확한 코드 가독성을 위해 꼼꼼한 리뷰를 남겨주시는 게 느껴져 감사했습니다.
불필요한 중복 표현은 제거하는 것이 좋습니다.
제가 맡은 업무는 비교적 간단한 기능을 만드는 일이었습니다. 앱에서 사용할 수 있는 회원 탈퇴 API를 추가하고, 기존의 탈퇴 로직을 개선하는 요구사항이었기 때문에 설계에 대한 고민을 크게 하지 않았습니다. 하지만 작은 기능이라도 기존의 설계와 코드 구조를 고민하지 않으면, 조화롭지 못한 구현이 될 수 있습니다. 읽기 쉽고 명확한 코드를 위해서는 컨벤션뿐만 아니라, 설계까지 신경 써야 한다는 사실을 배웠습니다. 선임 개발자분이 설계에 필요한 개념과 비즈니스 흐름을 직접 설명해주시면서, 여러 차례 수정작업을 도와주셨습니다. 작은 기능이지만 설계에 대한 고민을 직접 해보고, 다양한 논리 오류를 해결해보면서 객체지향의 기본 개념인 역할과 책임에 대해서도 다시 한번 그 의미를 느껴볼 수 있었습니다.
기능은 동작해도, 객체지향의 기본 원리가 반영되지 못한 설계는 다른 사람의 코드 이해를 어렵게 만드는 문제가 있었습니다.
최초의 구조는 하나의 도메인 객체가 너무 많은 역할과 책임을 수행하는 문제가 있었습니다. 리뷰를 도와주신 레이님이 각 도메인 서비스의 역할과 비즈니스 시퀀스를 직접 설명해 주었습니다. 노트에 그림을 그려주며 자세하게 설명해주신 덕분에 어떤 방향으로 설계해야 하는지 이해할 수 있었습니다. 설계에 대한 설명 전반에는 객체지향적 사고를 돕는 가이드가 포함되어 있었습니다. 예전에 조영호 님의 **<객체지향의 사실과 오해>**라는 책에서 읽었던 내용이 갑자기(?) 와닿는 신기한 경험을 할 수 있었습니다.
설계에 대한 피드백뿐만 아니라, 객체지향의 기본적인 패턴에 대한 피드백도 받을 수 있었습니다.
위 콘멘트는 “책임을 위임하면 좋겠다”는 단순한 피드백처럼 보일 수 있지만, 그 안에는 객체를 자율적인 존재로 생각해야 한다는 중요한 개념이 포함되어 있습니다.
좋은 객체지향 설계라면 객체가 캡슐화된 상태와 외부에 노출된 행동을 가지고 있어야 합니다. 그리고 다른 객체와 메시지를 주고받으면서 협력합니다. 객체는 메시지를 받으면 자율적 판단에 의해 로직을 수행하고 필요한 경우 내부의 데이터도 변경할 수 있습니다. 하지만 객체가 가지고 있는 멤버변수에 접근하기 위해 getter를 사용하는 방식은 객체에게 일을 맡기는 것이 아닌 객체 외부에서 데이터을 꺼내 사용하는 것을 의미합니다. 객체 스스로가 자신의 로직을 수행하지 못하고 주도권을 뺏기게 되므로, 객체가 객체답지 못함을 의미하게 됩니다.
일전에 읽었던 **<객체지향의 사실과 오해>**를 통해 **“객체가 자율적 판단을 통해 스스로 일을 하게 해야 한다”**는 개념을 알고 있다고 생각했습니다. 하지만 정작 제가 작성한 코드에는 반영하지 못하고 있었습니다. 설계에 대한 피드백 역시, 아는 것과 실천하는 것의 차이를 스스로 인지하는 데 큰 도움이 되었습니다.
72번을 주고받은 코멘트 속에는 앞서 말씀드린 피드백 외에도 다양한 내용이 있었습니다. enum 사용에 대한 피드백이나 정적 리팩터 사용에 대한 피드백 그리고 더 적합한 메서드 사용 등 신입 개발자가 좋은 코드를 작성하는데 필요한 노하우를 집중적으로 배울 수 있었습니다. 그중에서도 세 가지 포인트로 정리한 내용은 스스로 많은 반성과 깨우침을 주었던 피드백입니다. 아는 것과 실천하는 것이 명백하게 다르다는 것을 배웠고, 협업의 기본은 소통이라는 것을 다시 한번 깨달았습니다. 코드 역시 자연어로 이루어지는 소통과 마찬가지로 기호학적 약속과 이해하기 쉬운 표현이 중요했습니다.
연관된 상수가 있다면 Enum을 만들어 사용하는 것이 좋습니다.
forEach만으로도 원하는 로직 수행이 가능하다면stream을 사용할 필요가 없습니다.
첫 번째 코드 리뷰는 제게 많은 가르침을 주었습니다. 개발자 지망생 시절, 왜 주변 분들이 코드 리뷰 문화가 잘 갖춰진 회사에 가야 한다고 조언해 주셨는지 이해가 되었습니다. 헤렌은 코드 리뷰가 잘 자리 잡은 곳이어서 참 감사하다는 생각도 들었습니다.
PR에 한 개 두 개 코멘트가 달리기 시작할 때는 내심 불편한 마음도 들었습니다. 실수가 잦고 부족한게 많다는 생각에 압박감이 들었기 때문입니다. 하지만 정신없이 피드백 받은 내용을 구글링해 보고, 코드를 수정하는 작업을 하다 보니 어느새 코드가 많이 개선되어 있었습니다. 결과적으로 설계가 더 바람직해졌고, 읽기 쉬운 코드가 되었습니다. 코드 리뷰는 신입 개발자에게 더없이 좋은 선생님이자, 실력에 대한 메타인지를 돕는 놀라운 도구라는 생각이 듭니다.
코드 리뷰는 신입 개발자에게 강력한 동기부여를 주기도 합니다. 좋은 피드백을 남겨주었던 리뷰어 그 자체가 롤모델이 되기 때문입니다. 성장의 욕구를 강하게 자극하는 리뷰어의 뛰어난 실력을 보면서 저 역시 다른 개발자의 성장을 도와줄 수 있도록 노력해야겠다고 생각했습니다. 배움과 열정이 가득했던 저의 첫 번째 코드 리뷰 경험을 통해 이 글을 읽는 주니어 개발자분들도 좋은 리뷰 문화의 장점을 느껴보셨으면 좋겠습니다. 저 역시 다음 코드 리뷰에는 또 어떤 것들을 배울 수 있을지 매우 기대됩니다 😁
📌 잘 자리 잡은 코드 리뷰 문화를 통해 성장을 이어가고 싶은 개발자분들이라면, 헤렌의 채용 담당자 에게 커피챗을 요청해보세요. 헤렌은 현재 다양한 개발 직군을 적극적으로 채용하고 있습니다.
