핀다가 좋은 코드를 만드는 방법
핀다 개발자들은 이렇게 일하곤 하지 Vol.01
안녕하세요, 핀다 Frontend Engineer 남은우입니다.
핀테크는 국내에선 ‘카카오뱅크’, ‘토스’ 등 빅테크의 활약으로 이미 많은 분들의 이해도가 높은 상황입니다. 핀테크의 파이낸스를 의미하는 Fin은 어느 정도 이해가 되지만, 테크니컬의 Tech에 대해서는 이해도가 높지 않은 상황이죠. 개발자의 영역으로만 알려진 테크니컬 분야는 기본을 이해하면 그 후엔 무척 쉽게 접근할 수 있다는 사실, 알고 계시나요? 기본은 코드 작성입니다. 좋은 코드를 작성하기 위해서 우리는 무던히 노력하고 있습니다.
좋은 코드를 작성하기란 마치 학창시절 미술시간에 하얀 도화지 위에 나만의 논리가 가득한 그림을 그려내는, 흥미롭지만 막막한 작업인데요. 오늘은 제가 핀테크 기업 핀다에서 3년 가까이 재직하며 습득한 기본기를 설명하고자 합니다.
살아 있는 유기체, 코드(Code)
우리의 몸은 60조의 세포로 이루어져 있습니다. 이 세포의 평균 수명은 2년이며, 매일 800억 개의 세포가 새로 생기고 사라집니다. 이 때 매일 3000~4000 개의 새로 생기는 세포에 이상이 생기며, 우리는 이것을 '암세포'라고 부릅니다. 인체의 면역 세포에 의해 10,000 개 까지의 세포를 막을 수는 있습니다. 그러나 감당할 수 있는 범위를 넘어가면, 좁쌀 만한 크기의 종양이 생기고, 이것이 증식하면 인체에 치명적인 영향을 끼치게 되죠.
우리의 개발 프로젝트는 적게는 몇천줄, 많게는 몇 십만줄의 코드로 이루어져 있습니다. 이 코드들의 평균 수명은 제각각, 매일 많은 수의 코드이 생기고 사라집니다. 이 때 매일 셀 수 없이 많은 코드에 악취가 생기며, 우리는 이것을 '코드 악취(Code Smell)'라고 부릅니다. 몇몇 부지런한 개발자에 의해서 코드의 악취를 막을 수는 있습니다. 그러나 감당할 수 있는 범위를 넘어가고, 이것이 증식하면 프로젝트에 치명적인 영향을 끼치게 됩니다.
코드는 유기물입니다. 큰 단위 프로젝트도 막 생성되었을 때는 몇 십줄로 구성된 이른바 단세포 코드였습니다. 그러다 아키텍쳐(Architecture)라는 뼈대가 만들어지고, 기능이 붙게 되지요. 코드를 생산할 더 많은 개발자들이 참여하면서 머리, 또는 팔과 다리 역할을 하는 코드들이 생겨나기 시작합니다. 형체가 만들어지다가 또 우리가 모르는 사이에 알 수 없는 코드와 로직들이 구성을 엉망으로 만들곤 합니다. 초기에는 아무런 증상이 없지만 여기저기 꼬여 있는 스파게티 코드들이 범람하게 되면, 서비스는 더이상 새로운 기능을 추가하거나 변경할 수 없는 상황에까지 이르게 됩니다. 그렇기 때문에 많은 개발자들이 이러한 불상사를 막고 코드 작성의 효율성을 높이기 위해 오늘도 밤낮으로 고민하고 있습니다.
최근 서비스 트렌드는 기능을 런칭하고 A/B Test 또는 클릭/이탈률 측정을 통해 유저(User)의 반응을 살피며 지속적으로 수정하는 겁니다. 즉, 속도감 있는 개발이 중요해진 것이지요. 코드를 추가하거나 변경하는 것이 힘들어진다면 경쟁에서 밀릴 확률이 높습니다. 결국 변화를 수용하고, 이해하기 쉬운, 험난한 상황에서도 잘 동작하는 코드를 생산해야 할 때입니다. 이러한 목표를 이루기 이해 도움이 되는 몇 가지 규칙과 방법을 소개하겠습니다.
좋은 코드를 작성하는 규칙
보이 스카웃 규칙
The Boy Scout Rule: "Always leave the campground cleaner than you found it." 보이 스카웃 규칙: 언제나 처음 왔을 때보다 깨끗하게 해놓고 캠프장을 떠날 것.
로버트 마틴(Robert C Martin)의 저서 클린 코드(Clean Code)는 개발자들 사이에서 언제나 필독 목록 상위에 랭크되는 명저입니다. 책 내용 중 코드의 보이 스카웃 규칙은 코드를 깨끗하기 유지하기 위한 방법론보다는, 항상 개발자가 지녀야 하는 올바른 태도에 대한 비유라고 할 수 있습니다.
코드를 작성하는 도중 엉망으로 어질러져 있는 코드를 발견한다면 일단 청소를 시작해야 합니다. 누가 그렇게 코드를 작성했는지는 중요하지 않죠. 다만 다음으로 작업할 사람들 위해 코드 상태를 개선하는 것이 필요합니다. 프로젝트에서 개발자 모두가 이 단순한 규칙을 실천한다면 시스템은 점진적으로 개선될 것이며, 각자 맡은 부분만 담당하는 개개인의 집합이 아닌 시스템 전체를 돌보는 팀이 될 것입니다.
사실 이 부분은 코드를 만드는 것에 국한되지 않고, 우리의 일반적인 행동양식에 대한 말처럼 들립니다. 화장실에서 일을 보고 손을 씻거나, 쓰레기를 바닥에 버리지 않고 쓰레기통에 넣는 것처럼 말이죠. 내가 싼 X을 내가 깨끗하게 치우는 것! 기본 중 기본입니다.
좋은 코드를 작성하는 방법
첫번째, 어떻게 구현할지 문서화하자.
부끄럽지만, 핀다에 처음 들어왔을 때 저는 기획에 대한 이해없이, 손이 먼저 나가는 타입이었습니다. 어떻게 하면 코드를 채워 나갈 수 있을지에 대한 생각만 가득해, 결국 만들고자 하는 것은 무언지에 대한 생각이 명확하지 않았죠. 이렇게 만들어진 코드는 많은 문제를 일으켰습니다. 개발 완료 후 QA에서 발생하는 문제들이 쌓여갔고, 심지어 QA에서 잡지 못한 문제들이 유저에게도 영향을 미쳤습니다. 이미 배포되어 버린 제 나쁜 코드들은 부메랑처럼 돌아와 악몽 같은 경험을 선사해주었죠.
이 문제를 깔끔하게 해결해 준 것은 문서화였습니다. 문서화에는 여러가지 장점이 있는데요. 본인의 생각과 구현 방법이 정리되는 것이 첫 번째입니다. 본인의 생각과 구현 방식, 기획에 대한 명세와 요구사항을 문서화하는데 시간을 들이면, 역설적이게도 코드에 쏟는 시간이 줄어들게 됩니다.
더 좋은 것은, 이 문서들이 차곡차곡 쌓여 모인다면 나만의 위키가 된다는 점입니다. 이 문서를 무엇으로 부를지는 본인 또는 팀의 선택이겠지만 가장 중요한 것은 한 번 써본다는 것입니다. 그리 어려운 일이 아니니, 가장 쉽게 효과를 볼 수 있는 방법이라고 생각합니다.
두번째, 테스트 코드를 작성하자
이 단계는 첫 번째 단계인 문서화의 연장선이라고 할 수 있어요. 문서화 단계를 넘어, 코드 레벨에서 더 구체적인 피드백을 제시해줍니다. 테스트 코드를 작성하고 실행하면, 어떤 문제가 발생하는지 바로 알 수 있기 때문입니다. 잘 작성된 테스트 코드로 얻는 장점은 코드의 안정성을 얻게 되는 점, 기능 추가 및 수정에 대한 부작용(side-effects)를 미리 알 수 있는 것입니다. 테스트 코드를 작성할 때는 초반부터 넓은 범위를 커버하려고 하지 말고, 작은 것부터 테스트 코드를 작성하기 시작하여 점점 범위를 넓혀 나가는 것이 좋아요.
애플리케이션에서 유저의 리뷰는 다운로드 수에 큰 영향을 미치는 요소입니다. 따라서 빈번한 크래시(Crash)로 앱이 강제 종료되어 유저들의 원성이 빗발친다면 회사나 프로덕트의 성장에도 큰 영향을 받을 수 있죠. 이러한 경우를 방지하기 위해, 안정성을 보장해주는 테스트 코드가 빛을 발하는 거죠. 특히나 코드의 추가 또는 수정이 빈번한 프로덕트에서는 더욱 그러합니다. 프로덕트 테스트는 사람을 믿지 말고 코드를 믿어 봅시다!
세번째, 코드 리뷰와 페어 프로그래밍을 하자
사람들은 모두 생각하는 방식이 다릅니다. 따라서 같은 툴과 언어로 같은 기능을 구현해도 결과가 다를 수 있죠. 프로그래밍에 정답은 없지만, 퍼포먼스가 좋고 나쁜 것은 존재합니다. 따라서 코드 리뷰를 통해 우리가 추구하는 좋은 코드가 무엇인지, 어떻게 개선할지에 대한 충분한 논의가 필요합니다. 더불어 코드가 컨벤션에 맞게 잘 작성되었는지, 버그가 없는지, 미리 작성된 재사용 컴포넌트를 사용하고 있는지 등을 알 수 있기에 코드 리뷰는 필수입니다.
그리고 페어 프로그래밍을 하면 실시간으로 코드 리뷰를 하는 효과를 볼 수 있습니다. 페어 프로그래밍의 방법은 많지만, 보편적으로 사용하는 드라이버&네비게이터 패턴으로 진행하는 것을 생각해보겠습니다. 한 명은 코드를 작성하고 한 명은 리뷰와 가이드를 합니다. 집중도가 높아지며, 놓친 부분이 현저하게 줄어들게 됩니다. 그리고 보통 리드 개발자와 주니어가 함께 코드를 짜면서 몰랐던 부분을 알려주는 효과도 기대할 수 있습니다.
마무리하며
핀다의 좋은 코드를 만드는 비법은 핀다 멤버들의 컬러가 녹아 있습니다.
스스로 고민하고 끊임없이 질문한다
내가 싼 X, 내가 치운다
기록하고 퇴고하고 또 퇴고한다
가르치지 않고 리뷰한다
큰 잘못은 스스로에게 가르침이 된다
핀다 기술 블로그를 통해 위와 같이 생각하고 성장하는 개발자들이 더욱 자신감을 갖고 좋은 코드를 만들 수 있다면 좋겠습니다.
