꿀벌개발일지

서비스를 만들다 보면 우리가 가장 먼저 신경 쓰는 건 기능이 잘 동작하는지입니다. 버튼을 누르면 화면이 잘 넘어가는지, 사용자가 원하는 대로 데이터가 저장되는지, 디자인이 깨지지 않는지 같은 것들이죠. 그런데 그렇게 기능에만 집중하다 보면 예외적인 상황이나 예상하지 못한 행동은 놓치기 쉽습니다. 누군가 의도적으로 이상한 방식으로 서비스를 어뷰징하거나, 우리가 공들여 가공한 데이터를 손쉽게 긁어가는 일도 벌어질 수 있고요. 심한 경우에는 예상하지 못한 공격에 서비스가 뚫리는 일이 생기기도 합니다. 특히 ‘설마 누가 이렇게까지 하겠어?’ 하고 넘겼던 부분이 나중에 서비스 운영에 큰 문제가 되기도 합니다. 이런 위험을 줄이기 위한 간단하면서도 좋은 습관이 하나 있습니다. 바로 내가 직접 서비스의 공격자가 되어보는 것입니다. 내가 만든 기능이나 서비스가 있다면, 그냥 정상적인 사용자처럼 쓰는 게 아니라 어떻게든 깨뜨리려는 사람의 시선으로 한 번 바라보는 거죠. 예를 들어, 서비스에 있는 정보를 몽땅 긁어가려면 어떻게 할까? 서비스를 멈추게 하려면 어떻게 하면 될까? 자동으로 스팸 광고를 올리려면 어떻게 하면 될까? 내가 이 서비스 내부를 훤히 알고 있다면 어디를 노릴까? 이렇게 상상한 것을 실제로 시도해보면 더 좋습니다. 직접 이상한 방식으로 기능을 써보거나, 엉뚱한 데이터를 넣어보거나, 비정상적인 다양한 경로로 망가뜨리려는 시도를 해보는 것입니다. 이렇게 하면 평소에는 보이지 않던 위험들이 하나둘 보이기 시작하고, 자연스럽게 ‘어떻게 막을까?’를 고민하게 됩니다. 물론 모든 상상 가능한 위험을 다 막으려고 하면 너무 비효율적일 수 있습니다. 예를 들어, 사용자 10만 명 서비스인데 1억 명이 몰릴 때까지 대비하는 시스템을 처음부터 만드는 건 과할 수 있습니다. 작은 서비스인데 은행처럼 보안 솔루션을 깔고 감사 절차를 갖추는 것도 마찬가지고요. 저도 스타트업에서 일하면서 "그 정도 트래픽 오면 이미 성공한 거니까 그때 가서 걱정하자"는 농담을 자주 하곤 했습니다. 중요한 건 서비스의 단계나 규모 등 상황에 맞는 적정한 대비입니다. 하지만 분명한 건, 내가 공격자가 되어 생각해보는 습관만으로도 평소에 놓치던 위험을 발견할 수 있고, 훨씬 더 단단한 서비스를 만들 수 있다는 점입니다. 생각보다 어렵지도 않고, 오히려 재미있을 때도 많습니다. 만드는 것만큼 망가뜨리는 것도 흥미롭거든요. 그리고 모든 걸 다 막지 못하더라도, 어떤 위험이 있는지 알고 있는 것과 전혀 모르는 것 사이에는 정말 큰 차이가 있습니다. 그러니 한 번쯤, "내가 공격자라면?" 하고 생각해보세요. 그 생각만으로도 서비스는 훨씬 더 단단해질 수 있습니다.

[개발자를 위한 교양서] #10 코드리뷰에 대하여 몇 년 전, 코드리뷰를 적극적으로 하면서 일한 적이 있습니다. 코드리뷰를 도입하고 정착시키는 과정에서 많은 시행착오를 겪었고, 약 2년 동안의 경험을 정리해 회사 게시판에 올렸습니다. 생각보다 반응이 좋았습니다. 코드리뷰를 도입하고 싶었지만 망설이던 분들, 혹은 이미 도입했지만 잘 유지되지 않아 고민하던 분들이 공감해 주신 덕분이었습니다. 이 글은 회사 외부로도 공유되었고, 덕분에 여러 회사에 초청받아 강연할 기회도 얻었습니다. 같은 주제로 컨퍼런스에서 발표를 하기도 했고요. 경험을 정리하고 전달하는 과정에서 저 스스로도 다시 한번 깊이 되짚어볼 수 있었습니다. 의미 있는 시간이었습니다. 그런데 시간이 지나 돌아보니, 너무 코드리뷰 자체에만 집중했던 건 아니었을까 싶었습니다. 더 좋은 제품을 만드는 것이 목적이었는데, 코드리뷰를 철저히 하려다 보니 여러 절차를 만들었고, 결국 그 과정이 오히려 장애물이 되어 버린 건 아닐까 하는 생각이 들었습니다. 실제로 발표 자료를 준비하면서 팀원들에게 인터뷰를 해보니, 다들 리뷰에 대한 부담과 스트레스가 꽤 컸던 것 같았습니다. 코드리뷰를 꼭 해야 한다는 생각에 더 중요한 것들을 놓친 건 아니었을까, 속도가 느려지고 사기가 떨어졌던 건 그 때문이 아니었을까 반성하기도 했습니다. 지금은 한 발 물러서서 바라보니, 코드리뷰는 상황에 따라 유연하는 게 더 좋다고 생각합니다. 필요한 때에, 적당한 수준에서 하면 충분하고, 경우에 따라 생략하는 것도 괜찮다고 생각합니다. 무엇보다 중요한 것은, 코드리뷰 같은 수단이 목적이 아니라는 것을 잊지 않는 것입니다. 코드리뷰의 장점은 분명합니다. 작게는 컨벤션을 맞추는 것부터, 크게는 아키텍처 개선까지 도움을 받을 수 있습니다. 다른 사람의 코드를 읽으며 배우는 점도 많고요. 예상치 못한 개선 포인트를 찾을 수도 있고, 운이 좋다면 치명적인 버그를 미리 잡을 수도 있습니다. 다만, 리뷰를 받는 과정이 부담스럽게 느껴질 수도 있습니다. 검사받는 기분이 들 수도 있고, ‘코드와 나를 분리하라’고 하지만 애써 작성한 코드를 지적받으면 기분이 좋을 수만은 없습니다. 특히 표현이 거친 리뷰어를 만나면 더욱 그렇죠. 하지만 코드리뷰는 성장할 수 있는 좋은 기회입니다. 대부분의 직업에서는 이렇게 직접적이고 구체적으로 피드백을 받을 기회가 많지 않습니다. 그런데 누군가 내 작업물을 시간을 들여 꼼꼼히 살펴보고, 자신의 경험과 노하우를 담아 하나하나 첨삭까지 해준다니요. 그것도 무료로요! 그러니 마음을 조금 더 열어보세요. 그리고 꼭 추천하고 싶은 것이 있습니다. 자기 코드를 직접 리뷰하는 습관입니다. 책을 출판하기 전에 여러 번 퇴고하듯이, 코드도 누군가 읽는다고 생각하고 한 번 더 다듬어 보세요. 팀원들을 독자라고 생각하면서, 다시 읽어보고 조금씩 더 나은 방향으로 고쳐 가다 보면, 어느새 코드가 더 나아져있을 지도 모르니까요.

개발한 지 얼마 되지 않았을 때는 코드를 멋지게 짜는 것이 좋았습니다. 복잡한 로직을 짧게 줄이거나, 유행하는 패턴을 적용하면 왠지 더 뿌듯했습니다. 성능 차이가 크지도 않은데 괜히 비트 연산을 써서 있어보이게 만들기도 하고, 그냥 잘라서 비교하면 될 문자열을 굳이 정규식을 사용해 전후방 탐색까지 동원해가며 복잡하게 처리하기도 했습니다. 함수형 프로그래밍에 빠졌을 때에는, 함수에 함수를 넘기고 그 함수가 다른 함수를 호출하는 식의 코드를 짜기도 했고요. 디펜던시 인젝션이 멋있어 보일 때는 단순히 함수로 호출하면 될 코드를 여러 개의 객체로 감싸 추상화하기도 했습니다. 그때는 그런 코드들이 더 수준 높고 잘 만든 코드라고 생각했습니다. 배경지식이 있어야 이해할 수 있으니, 왠지 더 고급스럽게 느껴지기도 했고요. 아마도 ‘이것 봐, 나는 이런 것도 알고 있어!’ 하고 내보이고 싶은 마음도 있었던 것 같습니다. 그런데 시간이 지나면서 생각이 달라졌습니다. 처음엔 있어 보였던 코드들이 막상 수정하려고 하면 골치 아팠습니다. 한 눈에 이해되지 않아서 한참을 들여다봐야 했고, 결국 너무 어려워서 다시 작성한 경우도 많았습니다. 유행하는 패턴을 적용했던 코드들은 유행이 지나니 촌스럽게 보이기도 했고요. 그렇게 시행착오를 겪으며, 오래 고민하지 않아도 한 번에 읽고 이해할 수 있는 코드가 실용적이라는 걸 깨닫게 되었습니다. 예전에는 반복을 없애는 것이 깔끔한 코드라고 생각하기도 했습니다. 같은 코드가 두 번 이상 나오면 무조건 정리하는 것이 정석이라 믿었고, 반복되는 패턴을 찾아 추상화하는 것이 능력이라고 여겼습니다. 하지만 지나친 추상화는 오히려 코드를 읽게 어렵게 만들었습니다. 모듈이 지나치게 쪼개져있거나 여러 패턴이 겹쳐 있으면, 코드를 따라는 것조차 부담스러웠습니다. 이런 코드들은 고치는 것보다 새로 짜는 게 더 쉬울 때도 많았습니다. 지금은 직관적인 코드가 더 좋다고 생각합니다. 구조가 단순하거나 중복된 부분이 있더라도, 한 번에 보고 이해할 수 있는 코드가 더 낫습니다. 한 줄로 압축된 로직보다, 다소 장황하더라도 고치기 쉬운 코드가 더 실용적입니다. 누구나 쉽게 수정할 수 있는 코드라면 더 좋겠습니다. 코드는 혼자만 보는 것이 아니니까요. 설령 혼자만 본다고 하더라도, 몇 달 뒤의 나는 남과 다름없으니까요. 저 역시 쉽고 오래 유지할 수 있는 코드를 짤 수 있도록 더 고민하고 노력해야겠습니다.