“코드 리뷰는 코드의 틀린 부분을 찾는 것이 아닙니다.” CTO 정국님이 알려주는 코드 리뷰

테크 회사의 특성상 코드 리뷰는 중요한 개발 문화 중 하나입니다. 개인이 발견하지 못한 실수를 확인할 수 있고, 혹여나 발생할 수 있는 위험에 미리 대응할 수 있죠. 그리고 단순히 문제점을 발견하는 것을 넘어 전체적인 개발 역량을 키우는 데 중요한 역할을 합니다.

그런데 코드 리뷰는 정확하게 어떤 프로세스로 이루어지는 것일까요? 어떤 부분을 리뷰하면 좋을지, 어느 정도로 하면 좋을지, 어느 부분을 주의하면 되는지 쉽게 파악하기가 어렵습니다. 특히 개발자 취업을 준비하는 분들, 주니어 개발자분들께서 많이 궁금해하실 것 같은데요. 그래서 엘리스 CTO 정국님께 코드 리뷰에 대한 이야기를 들어보았습니다.

더군다나 지난 5월 말, 정국님께서 포브스가 발표한 ‘아시아에서 영향력 있는 30세 이하 리더’에 선정되셨는데요. 포브스가 새로운 앱 개발의 최전선에 있다고 강조한 소비자 기술 분야에서 선정된 만큼, 정국님께서는 어떻게 코드 리뷰를 하는지 더욱 궁금해집니다. 포브스의 남자 정국님의 코드 리뷰 이야기, 함께 들어볼까요?

Q. 안녕하세요, 정국님. 포브스에 선정되신 것을 축하드려요. 간단한 자기소개 부탁드립니다.

안녕하세요. 저는 엘리스에서 CTO 겸 백엔드 팀 리드를 맡고있는 박정국이라고 합니다.

Q. 어떤 업무를 주로 하고 계시나요?

저는 백엔드 부분을 총괄하고 있습니다. 프로덕트가 작동될 때 뒤에서 작동되는 각종 API와 API 서버를 만들고 유지보수하는 것, 그리고 많은 사람이 들어왔을 때 서버가 느려지지 않게 하는 것이 메인 업무입니다. 그리고 엘리스에서 데이터를 수집하고, 그 데이터를 바탕으로 어떤 서비스를 제공할지 관리하는 역할도 하고 있어요. 물리적으로 서버를 배치, 업그레이드하고 교체하는 것까지 담당하고 있습니다.

코드 리뷰란 무엇인가요?

Q. 오늘은 특별히 코드 리뷰를 하는 과정을 설명해주실 예정인데요. 그 전에 앞서 ‘코드 리뷰’를 어떻게 설명할 수 있을까요?

코드 리뷰는 쇼핑몰에서 주문하여 도착한 택배를 살펴보는 과정에 비유할 수 있어요. 실제로 코드를 처음 딱 받았을 때의 느낌이 택배를 받았을 때의 느낌과 비슷하거든요. 설렘과 약간의 불안감이 있죠(웃음).

일단 처음에는 겉을 훑어봐요. 예를 들어 청소기를 샀다고 가정하면, 설명서가 있고 조립해야 할 것들도 있잖아요. 코드도 마찬가지예요. 설명서를 보듯이 프로젝트의 리드미나 각종 문서가 잘 작성되어 있는지 검사합니다. 또 API 서버에서 어떤 모델들을 바탕으로 기능을 구현하는지 보는 것을 청소기 부품을 확인하는 과정에 비유할 수 있어요.

첫 번째, 프로젝트 구조 보기

Q. 정국님의 코드 리뷰를 위해 엘리스 AI 트랙 3기 수상팀의 프로젝트인 WellAi를 준비했습니다. WellAi는 집에서 요가를 할 수 있도록 이미지 인식, 영상 인식으로 요가 자세를 확인하고 기록, 관리해주는 AI 홈트 서비스인데요. 이 서비스에 대해 가장 먼저 리뷰할 부분은 어떤 것인가요?

우선 프로젝트 구조를 먼저 봅니다. 처음에 WellAi를 보자마자 Django 프로젝트라고 하기에 일반적인 구조는 아니라고 생각했어요. 사실 프로젝트 구조에 정해진 공식이 있는 것은 아니지만, 보통은 유명한 개발자의 블로그에 있는 글이나 프로젝트를 참고하는 것이 좋습니다. 이를 통해서 어떤 식으로 파일과 폴더를 구성하는 것이 일반적인 구조인지 알 수 있어요. 이렇게 구성하면 코드를 처음 보는 사람도 헤매지 않을 수 있죠.

Q. 프로젝트 구조와 관련해서 참고할만한 사이트가 있을까요?

FastAPI는 파이썬에서 유명한 웹 프레임워크인데요. 이 FastAPI를 만든 Tiangolo라는 개발자가 공개한 소스 코드를 참고하면 좋아요. 여기서 풀스택으로 FastAPI를 사용해서 개발할 때 어떤 식으로 프로젝트 구조를 잡으면 될지 알 수 있습니다.

이 프로젝트 구조를 보시면 최상위 폴더에는 파일과 폴더가 몇 개 없다는 것을 확인하실 수 있어요. 보통 라이센스, 리드미 설명 그리고 프로젝트에 어떻게 컨트리뷰팅 할 수 있는지에 대한 문서가 있고요. 다음으로는 스크립트, 즉 프로젝트를 조작하는데 필요한 프로그램들이 있습니다. 실제로 백엔드에 들어가면 굉장히 단출한데요. 이 구조와 비슷하게 정리하면 일반적으로 익숙한 프로젝트 구조로 개선할 수 있습니다.

Q. 프로젝트 구조를 잘 정리할 수 있는 꿀팁을 알려주셨네요. 실제로 협업을 위해서도 정리를 잘하는 것이 중요합니다. 협업할 때 필요한 툴도 알려주실 수 있나요?

협업할 때 필수적으로 사용해야 하는 툴이 있어요. Code Formatting에 관한 것입니다. WellAi에서도 black, flake8이라는 코드를 확인할 수 있는데요. 이게 Code Formatter라고 하는 프로그램이에요.

사실 코드를 작성할 때도 개인의 취향이 반영되거든요. 예를 들어 엔터를 많이 치는 분도 계시고요. 이렇게 자신의 스타일대로 코드를 짜게 되면 여러 명의 코드가 짬뽕이 되어버려요. 그래서 여러 명이 협업할 때는 코드를 어떻게 할지 룰을 정하는 것이 중요합니다. 이런 것이 기능에 영향을 미치는 것은 아니지만, 코드가 한눈에 보기 좋고, 통일되어야 협업할 때 용이해요.

Q. 그렇다면 Code Formatter로는 어떤 것이 있을까요?

최근에 파이썬에서 유행하는 Code Formatter로는 black이라는 것이 있는데요. 이 툴은 ‘개발자에게 선택지를 주지 않는다’라고 생각하시면 돼요. 개발자는 그냥 시키는 대로 따라야 하는 거죠. 예를 들어 싱글 쿼터를 사용하면 무조건 더블 쿼터로 바꿔버려요. (웃음) 룰을 강조하는 툴이라고 생각하면 됩니다. WellAi에서도 Code Formatter를 사용했는데요. 그 덕분에 제가 리뷰를 더 쉽게 할 수 있습니다.

두 번째, 코딩 컨벤션 체크하기

Q. 통일성을 위해 강조하는 툴이라는 것이 인상 깊네요. 다음으로는 어떤 부분을 리뷰하게 될까요?

다음에 보는 것이 어떤 모델들을 선언했는지, 처음에 어떤 모델이 있는지를 보게 됩니다. WellAi를 보시면 Tag가 있고 Exercise가 있고 그다음에 Course가 있는데요. Course에서도 review가 있고 bookmark 기능이 있다는 것을 확인할 수 있습니다. 그럼 감이 잡히죠. 서비스에 요가 코스가 있을 것이고, 그 코스 안에 요가 운동이 있다는 것을 알 수 있습니다. 그리고 여기에 리뷰도 남기고 북마크도 할 수 있겠다는 생각이 들죠.

이 구조에서 모델들 간의 관계나 모델이 어떤 데이터를 포함하고 있는지 확인하는 것을 코딩 컨벤션 체크라고 합니다. 체크하다 보면 중간중간에 이해가 되지 않는 부분들이 발견되죠.

예를 들어 처음에 Tag 모델이 있고 tag_name이라는 필드가 있는데요. 저는 개인적으로 tag에 tag_name이라는 의미가 중복되어 있다고 생각해요. Tag.name이어도 되지 않을까라는 생각이 들어요. 그리고 뒷부분에 있는 tag_name의 의미를 확인해보면 ‘해시태그’라고 되어 있습니다. 그렇다면 이름을 hashtag로 하거나, tag라 쓰고 ‘태그’라고 하는 게 더 일관적일 것이라고 생각해요. 이런 명칭들이 계속 쌓이다 보면 확장할 때 어려움이 있을 수 있기 때문에 이름을 잘 짓는 것이 중요합니다. 사실 이름 짓는 게 프로그래밍할 때 가장 어려운 부분 중 하나에요.

Q. 프로그래밍할 때 이름을 잘 짓는 것이 중요하다는 말씀을 해주셨습니다. 추가로 칭찬을 하고 싶은 부분이 있다고요.

실제 이 모델들을 가지고 프로젝트에서 하고자 하는 것들을 제대로 하고 있는지 확인하는데요. 잘했다고 생각이 드는 부분은 rest_framework라는 프레임워크를 사용한 것입니다. 이렇게 검증된 라이브러리를 사용하면 ‘운동 상세’를 얻어오는 과정 자체에는 오류가 없다고 생각하고 빠르게 리뷰를 넘어갈 수 있습니다. (웃음) 이렇게 라이브러리나 프레임워크를 상황과 목적에 맞게 잘 쓰는 것이 중요하다고 말씀드리고 싶어요.

세 번째, 코드의 효율성 확인하기

Q. 그다음으로 코드가 효율적으로 작동하는지 확인이 필요한거죠?

맞아요. 다음으로는 코드가 효율적으로 작동하는지, 성능이 정말 좋은지를 봅니다. 그리고 성능을 고려했을 때 잘 짜인 코드인지도 확인하죠. 예를 들어 요가 코스(Course)의 리뷰(review)를 리스트하는 API를 확인할 수 있는데요. 코스의 평점(Rating)이나 생성일(Create_at) 기준으로 순서(ordering)를 바꿀 수 있는 기능을 제공하고 있습니다.

그렇다면 예를 들어 리뷰가 1,000개 있을 때 효율적으로 이루어지는지를 보게 됩니다. WellAi에서는 프레임워크라는 만들어진 라이브러리를 사용했기 때문에, 사실 그 이상의 개선을 스스로 하기 어려운 부분도 있긴 한데요. 효율적으로 코드를 짜는 것은 프로젝트를 작성하는 사람의 몫이라고 생각하시면 될 것 같아요.

네 번째, 보안 이슈 체크하기

Q. 보안 이슈를 체크하는 것도 코드 리뷰에서 중요한데요. 보안 이슈는 어떤 방식으로 체크하시나요?

보안상 문제가 없는지 확인하는 것은 매우 중요합니다. 왜냐하면 API 서버에서 보안 문제가 생기면 돌이킬 수 없거든요. 보통 자주 실수하는 패턴들이 있어요. 실수로 비밀번호를 코드 안에 작성하는 경우가 대표적이죠.

이런 실수를 사전에 방지해줄 수 있는 툴이 있습니다. 대표적인 툴이 파이썬에 bandit이라는 프로그램입니다. 이 툴은 코드를 읽고 어떤 부분에 보안상 위험이 있는지 확인해줘요. 예를 들어 Flask로 코드를 작성했는데 Debug를 true로 설정해놓았으니 이를 False로 바꾸라고 알려주죠.

Q. 사전에 위험을 방지할 수 있는 좋은 툴이군요. 개발자를 준비하는 분들께 꿀팁이 될 수 있겠네요. 이 외에 코드 리뷰를 할 때 추가로 더 보는 부분이 있을까요?

추가로 프로젝트가 극한 상황이 왔을 때도 제대로 작동하는지 확인합니다. 예를 들어 접속자가 순식간에 몇천 명이 되거나, 데이터를 저장하는 도중에 정전이 되어서 서버가 꺼졌을 때도 데이터가 깨지지 않는가를 확인해요.

사실 이런 것들은 코드만 봐서는 알 수 없는데요. 이럴 때 많이 사용하는 것이 APACHE - JMeter라는 프로그램입니다. 다양한 경우에 대해서 시간이 얼마나 걸리고 CPU를 얼마나 사용하는지 테스트할 수 있어요. 극한의 상황에서 서버에 에러가 발생하지 않는지 확인이 필요할 때 이 툴을 사용하는 것을 권장해 드립니다.

Q. 지금까지 코드 리뷰를 하는 과정에 대해서 잘 설명해주셨습니다. 이해하기 쉽게 설명해주셔서 감사해요. 마지막으로 하시고 싶은 말씀이 있나요?

코드 리뷰는 리뷰를 받는 사람도, 하는 사람에게도 모두 좋아요. 개발자로서 성장하는 데 굉장히 도움이 되는 과정입니다. 그래서 코드 리뷰하는 것을 중요하게 생각하시면 좋을 것 같아요. 팀 프로젝트를 하실 때 서로 리뷰하는 것도 좋고, 리뷰를 할 사람이 없다면 오픈소스들의 코드를 스스로 리뷰해보는 것도 좋습니다. 여러 가지를 찾아보고 리뷰하는 경험을 많이 쌓으면 좋을 것 같아요. 저도 이번 기회로 코드 리뷰를 통해 어떤 것들을 보는지 알려드릴 수 있어서 좋았습니다. 감사합니다!

정국님의 코드리뷰 이야기 잘 들어보셨나요? 코드 리뷰가 어떻게 진행되는지, 리뷰할 때 사용하면 좋은 프로그램과 툴을 많이 알려주셨습니다. 그리고 코드 리뷰를 하는 경험을 많이 쌓는 것을 강조하셨어요. 다른 사람들과 서로 코드를 리뷰하고 피드백을 나누기 위해서는 열린 태도와 마음이 중요하다는 생각이 듭니다.

앞으로도 엘리스 개발자의 인사이트를 얻을 수 있는 콘텐츠를 꾸준히 선보일 예정입니다. 개발자는 어떤 프로그램을 사용하는지, 어떤 북마크가 있는지 개발자 꿀팁 정보를 알려드릴 예정이니까요. 다음 콘텐츠도 많이 기대해주세요!

정국님께 코드 리뷰를 받고 싶다면 엘리스 엔지니어로 지원해보세요!
엘리스 엔지니어 지원하기 👉 https://elice.careers