개발자를 위한 교양서

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

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

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

일이 어렵다고 고민하는 후배들이 있었습니다. 어떤 친구는 이해가 되지 않아 답답하다고 했고, 또 어떤 친구는 시간이 촉박한데 원하는 결과가 나오지 않아 초조하다고 했습니다. 자신 있게 말할 수 있습니다. 걱정하지 않아도 된다고요. 물론 지금 당장은 힘들고 막막하겠지만, 처음엔 원래 다 어려운 법입니다. 이런 고민을 한다는 건 심리적으로 압박을 느끼고 있기 때문일 것입니다. 주어진 일을 잘 해내야 한다는 부담, 기대에 미치지 못할까 걱정하는 마음 때문일 수도 있습니다. 어쩌면 이미 만족스럽지 않은 평가를 받아들고 난 뒤일 수도 있고요. 처음엔 마음대로 되지 않는 게 당연합니다. 용어도 낯설고, 업무의 흐름이나 전체적인 그림도 잘 그려지지 않으니까요. 하지만 일이라는 건 하다 보면 익숙해지고, 시간이 지나면 자연스럽게 능숙해집니다. 지금 어려운 이유는 단순히 경험이 부족해서일 뿐입니다. 일을 맡긴 사람은 답답할 수도 있겠지만, 아마 그도 처음엔 비슷한 과정을 거쳤을 겁니다. 누구나 그랬을 거예요. 그러니 너무 조급해하지 말고, 마음을 조금 내려놔도 괜찮습니다. 지금 익숙하게 다루고 있는 것들이 처음엔 얼마나 어려웠는지 떠올려보세요. 처음에는 용어조차 이해하기 어려운 것들도 많았을 겁니다. 저는 개발을 처음 배울 때 ‘객체’라는 개념이 도무지 이해되지 않아 스스로 한심하게 느껴졌던 기억이 납니다. 자료구조가 너무 어렵게 느껴져서 개발이 적성에 맞지 않는다고 생각한 적도 있었습니다. 그런데 지금 돌이켜보면, 그때 왜 그렇게 어려웠을까 싶을 정도입니다. 그러니 지금 배우는 것이 어렵다고 해서 너무 위축될 필요는 없습니다. 지금 맡은 일이 유난히 어렵게 느껴지더라도 너무 걱정하지 마세요. 회사에서 나에게 맡겼다는 것은 해결할 수 있는 범주의 일이라는 뜻입니다. 팀에서 할당한 업무라면, 팀의 수준에서 충분히 해결할 수 있는 일이기도 하고요. 미지의 난제가 아닌 이상, 결국 해결 방법은 있을 것이고, 방법을 찾는 것도 경험이 쌓이면 익숙해집니다. 고민해 봐도 해결이 어렵거나 긴가민가하면, 너무 오래 붙잡고 있지 말고 주변에 물어보세요. 경험이 있는 사람들에게는 어려운 문제가 아닐 수도 있습니다. 도움을 요청한다고 해서 거절하는 동료는 많지 않습니다. 오히려 설명하는 과정에서 도와주는 사람도 배우게 되니, 부담 갖지 말고 편하게 질문하세요.

일이 지겨울 때가 있습니다. 평소엔 괜찮았는데 일이 지겨워졌다면, 그럴만한 이유가 있을 것입니다. 일이 너무 익숙해져서 쉬워졌거나, 같은 일을 반복하다보니 흥미가 떨어졌을 수 있습니다. 혹은 일의 목적이 공감되지 않거나, 이 일이 과연 의미가 있는지 의문이 들기 때문일 수도 있고요. 아니면 원치 않던 일을 맡게 되어서일지도 모르겠습니다. 어떤 이유에서든 이런 상황이 오면, 의욕이 사라지고 일도 하기 싫어집니다. 이럴 때 가장 확실한 방법은 더 도전적인 업무를 맡거나, 새로운 환경을 찾아보는 것입니다. 이참에 회사를 옮겨보는 것도 방법일 수 있고요. 하지만 이런 선택은 많은 에너지가 들고, 실행하기 쉽지 않습니다. 무엇보다, 지금의 지겨움이 단순히 스쳐가는 감정일 수도 있습니다. 한 가지 현실적인 방법은 ‘나’의 환경을 바꿔서 몰입할 수 있게 만들어 보는 것입니다. 일이 너무 쉬워서 지겹다면 난이도를 높여보고, 목적이 공감이 되지 않는다면 나만의 목표를 설정해보는 것입니다. 같은 일이지만 사이사이에 ‘작은 도전’들을 넣어보는 것입니다. 저도 그랬는데, 한 가지 일을 2년 정도 하다 보면 지겹다는 느낌이 들기 시작했습니다. 업무에 익숙해지면서 효율은 높아졌는데, 자연스럽게 흥미가 떨어지더라고요. 하지만 일은 계속해야 하니 나름대로 방법을 찾아보았습니다. 한 번은 개발 환경을 일부러 어렵게 만들어 보기로 했습니다. 익숙했던 IDE 대신, 평소에 배우려고 미뤄뒀던 VIM 에디터로 환경을 바꿨습니다. 낯선 환경에 일을 마무리하기까지는 좀 더 시간이 걸렸지만, 새로운 도전을 하다보니 일하는 시간은 오히려 재미있었습니다. 신기하게도 얼마 지나지 않아 지겨움이 사라져버리기도 했고요. 게다가 이 때의 경험으로 지금도 에디터에서 VIM 플러그인을 설정해서 쓰고 있습니다. 딱 봐도 지루하고 반복적인 업무를 맡을 때도 있었습니다. 이럴 땐 어떻게든 자동화 할 수 있는 방법을 찾아보려고 노력했습니다. 가끔은 좋은 해결책이 나오는데, 오히려 시간만 쓴 적도 많았습니다. 하지만 그 과정은 흥미로웠고, 새로운 기술을 익히는 경우도 있었습니다. 이렇게 하니 지겨웠던 일도 새로운 도전 과제의 연습 대상이 되더라고요.

세상에는 재능이 뛰어난 사람들이 많습니다. 우리가 알고 있는 스포츠 스타, 가수, 연예인들은 대부분 그럴 것입니다. 천재적인 과학자나 수학자들도 마찬가지입니다. 이들은 타고난 재능도 있지만, 누구보다도 열심히 하기도 합니다. 회사에서도 그런 사람들이 있습니다. 비록 ‘세계적인 천재’까지는 아닐지 몰라도, 적어도 회사 안에서는 누구나 인정할 만큼 눈에 띄게 뛰어난 사람들이 있습니다. 이런 사람들은 어려운 일도 별 일 아닌 것처럼 척척 잘 해냅니다. 정말 대단한 사람들입니다. 회사에서도 꼭 필요한 인재입니다. 하지만 이런 동료가 나와 같은 팀에서 비슷한 연차로 일하고 있다면, 감탄만 하고 있기 어려울 때가 있습니다. 같은 일을 맡아도 나보다 훨씬 빠르게 처리하고, 나는 엄두도 못낼 것 같은 작업을 어렵지 않게 해내니 불안감이 들 수 있습니다. 특히 그 동료와 내가 상대 평가의 대상이 된다거나, 내가 맡은 일이 잘 풀리지 않을 땐 이런 감정이 더 커질 수 있습니다. 동료의 월등함에 위축될 수도 있고, 어쩌면 괜히 질투가 나면서 미워질 수도 있을지도 모르고요. 이런 감정을 느끼는 것은, 지극히 자연스러운 일입니다. 성장하는 사람이라면 큰 벽을 만났을 때 불안감이나 좌절감을 느끼는 것이 당연합니다. 그러니 낙담하지 마세요. 비교하는 마음이 드는 것은 어쩔 수 없지만, 비교에는 끝이 없으니까요. 우리가 하는 건 '일'입니다. 꼭 1등이 아니어도 다양한 방식으로 기여할 수 있는 기회가 많습니다. 특별히 뛰어나지 않더라도 각자의 역할이 있고, 해야할 일은 너무나도 많고요. 그러니 내가 충분히 노력하고 있다면, 누군가 저만치 앞서간다고 해서 조급해하지 않아도 됩니다. 물론 자극을 받아 성장하는 것은 중요합니다. 뛰어난 동료를 보고 불안한 마음이 들었다면, 마음의 준비는 이미 된 셈입니다. 이제 마음을 실천하기만 하면 됩니다.

개발을 시작한 지 몇 년 되지 않았을 때, 제 목표는 네이버에 입사하는 것이었습니다. 2010년경이었는데, 당시 네이버는 국내에서 가장 잘나가는 서비스였고, 많은 개발자가 꿈꾸는 회사였습니다. 마침 UI 개발팀에서 경력직 공채를 진행하고 있었고, 저는 지원서를 냈습니다. 이후 두 번의 시험과 세 번의 면접을 거쳐 힘겹게 합격했습니다. 설레는 마음으로 첫 팀에 배정받아 팀원들의 소개를 받았을 때, 저는 깜짝 놀랐습니다. 유명한 개발자들이 많았기 때문입니다. 제가 공부했던 책을 번역한 사람, 자주 참고하던 개발 블로그를 운영하는 사람, 그리고 컨퍼런스에서 발표하는 모습을 봤던 사람이 모두 같은 팀원이었습니다. ‘우와, 대단하다!’라는 감탄이 절로 나왔습니다. 하지만 동시에 불안감도 밀려왔습니다. ‘이런 뛰어난 사람들 사이에서 내가 잘 해낼 수 있을까?’ 하는 생각이 들었기 때문입니다. 네이버의 품질 기준은 매우 높았습니다. 회사에 들어오기 전에 네이버를 쓰면서는 별 생각이 없었는데, 실제로 만들어보니 달랐습니다. 디자이너들은 예상보다 훨씬 많은 시안을 테스트했고, 기획자들은 큰 플로우뿐만 아니라 세세한 부분과 예외 상황까지 꼼꼼히 챙겼습니다. 우리 팀에서는 UI 동작을 구현했는데, 최신 브라우저뿐만 아니라 단종에 가까운 구형 IE까지 지원해야 했습니다. 마지막 단계인 QA 팀의 검수도 엄격했는데, 때로는 ‘굳이 이 정도까지 해야 하나?’ 싶은 순간도 있었습니다. 그러나 동료들에게는 이러한 과정이 당연한 일이었습니다. 요구사항을 어렵지 않게 구현해내는 것은 당연하고, 수차례의 디자인 검수 작업도, 다양한 버그와 예외 상황 처리도 자연스럽게 해내고 있었습니다. 이러한 환경 속에서 저도 제품을 대하는 기준이 점점 높아졌습니다. 그리고 어느 순간, 저에게도 이런 과정이 당연한 것이 되었습니다.

개발은 참 즐거운 일입니다. 일종의 ‘만들기’이기 때문입니다. ‘만들기’가 즐거운 이유는 창조 과정에서의 몰입, 완성된 결과물에 대한 만족감, 그리고 피드백을 통해 얻는 성취감 때문일 것입니다. 목공이나 가죽공예 같은 취미가 인기가 있는 것도 같은 이유일 테지요. 내가 구상하고 손수 만든 의자를 가까운 누군가가 써보고 칭찬해주면 얼마나 뿌듯하고 기분이 좋을까요? 생각하고, 계획하고, 정성을 다해 무언가를 만들고, 피드백을 받는 과정은 정말 보람차고 즐거운 일입니다. 서비스를 만드는 것도 즐거운 일입니다. 여러 사람들이 모여서 고민하고, 함께 힘을 합쳐 제품을 만들고, 사용자들의 반응을 보는 것을 정말 흥미로운 일입니다. 여기에 사용자도 빠르게 늘어나고, 반응까지 뜨겁다면 성취와 보람도 클 것입니다. 어떤가요? 개발자로 일하는 것이 즐거운가요? 혹시 그렇지 않다면 ‘만들기’의 요소 중 하나가 빠져있기 때문일지도 모릅니다. (현실은 호락호락 하지 않으니까요…)

팀으로 개발할 땐 코드를 “읽기 편하게” 짜는 것이 정말 중요합니다. 일하다 보면, 어떤 코드는 눈으로만 봐도 술술 잘 읽히는 반면, 어떤 코드는 당최 무슨 말인지 알 수 없는 경우가 있습니다. 버그도 없고 잘 돌아가서 겉으론 차이가 없어 보이지만, 막상 고쳐야 해서 손을 대보면 다릅니다. 읽기 편한 코드는 고치기도 쉽지만, 반대의 코드는 더 많은 시간과 노력이 듭니다. 동료가 자기가 요리를 하려고 준비해뒀는데, 갑자기 일이 생겨서 우리에게 부탁하고 떠났다고 생각해보는 거예요. 깔끔하게 정돈된 테이블 위에 칼과 조리도구, 재료가 한 눈에 보입니다. 재료를 씻고, 손질하고, 조리하는 곳이 잘 나뉘어져 있고 깨끗하게 정리돼 있습니다. 남겨둔 레시피에는 절차가 잘 정리되어 있고, 용어 용량에 대한 표기가 명확합니다. 걱정 없지 않을까요? 큰 문제가 없다면 잘 마무리할 수 있을 것 같습니다. 반대로 주방이 어지럽혀져 있는데, 조리도구도 흐트러져 있고 설거지도 제대로 되어있지 않습니다. 쓰다만 재료가 널부러져 있는데다, 다른 재료는 어디에 있는지도 모르겠습니다. 레시피를 몇 장 적어두고 가긴 했는데, 이게 무슨 말인지 잘 이해가 안되고, 다른 하나는 예전 레시피 같기도 하고요. 휴… 한숨이 나오지 않나요? 프로젝트에 참여하고 있다는 것은, 누군가 내 코드를 읽고 쓰게 된다는 것입니다. 동료가 읽을 것이라고 생각하고, 한 번만 신경써서 퇴고하면 훨씬 읽기 편한 코드가 될 것입니다. 개발을 시작한지 얼마 되지 않았다면, 일단은 들여쓰기를 잘 하고 변수명을 고민해서 잘 짓는 것만으로도 충분합니다. 개발 에디터에는 포맷팅 플러그인이 많아서, 들여쓰기 등의 포맷팅을 정리하는 것은 전혀 문제가 되지 않습니다. 저는 아직까지도 변수에 딱 맞는 마음에 이름을 짓는 것이 어렵습니다. 최근엔 사정이 좀 나아졌는데, AI 에게 이름을 추천해달라고 하면 잘 알려주고, 아예 코드 전체를 리팩토링 해달라고 해도 잘 정리해줍니다. 도구를 활용하면 적당한 수준의 읽기 편한 코드를 작성하는 건 어렵지 않습니다. 어렵지 않는데, 문제는 잘 하지 않는다는 것입니다. 대부분은 정말 바빠서일 것입니다.

아마 15년도 더 지난 일인 것 같습니다. 네이버에서 일할 때, 이해진 의장이 전사 직원들은 대상으로 직접 강연한 적이 있었습니다. 네이버 지식인 서비스의 성공 사례를 들며, “사용자들이 질문에 대한 답변을 작성하도록 하기 위해 어떤 리워드를 줘야 할까”라는 물음에, “숫자를 주면 된다”고 강조했습니다. 돈도 아니고, 숫자를 주면 된다니… 그 답변이 인상 깊어서 아직도 기억에 남습니다. 그후로 서비스를 만들며 경험해보니 정말로 그랬습니다. 숫자는 단순해보이지만, 사용자의 주의를 끌어 행동을 유도하거나, 지속할 수 있는 동기를 부여하는데 효과적이었습니다. 설명보다는 예시를 보는 게 더 이해하기 쉬울 것 같습니다. 실제로 숫자는 가장 많이 사용되는 리워드입니다. 좋아요 200개 노력에 대한 과정을 담아서 행동을 지속할 수 있도록 동기부여할 수도 있고, 운동 37일째 일기쓴 날 175일 지난 컬럼에서 얘기했던 것처럼, 서비스 의도를 담아서 사용자를 움직이게 만들 수도 있습니다. 내 답변으로 도움받은 사람들 293명 나의 운전점수 99점 짧게는 호기심을 유발해서 클릭을 유도할 수도 있을 것이고, 지금 보는 중 972명 길게는 목표를 담아 큰 메시지를 전달하는데 사용되기도 합니다. 무사고 796일 째

의도된 UI는 사용자를 움직이게 만드는 힘이 있습니다. 좀 극단적이긴 하지만, 자동차 속도계를 예로 들어보면 설명하기도 쉽고 이해하기도 쉽습니다. 일반적인 속도계는 자동차의 현재 속도에 대한 정보만 제공합니다. 이 UI에도 의도를 담아볼 수 있습니다. 예를 들어, 자동차의 운전자들이 좀 더 빠르게 달리길 원한다면, 어떻게 해보면 될까요? 속도계의 끝에 ‘나의 최고속도’ 지점을 아이콘으로 표시해주는 방법을 생각해볼 수 있습니다. 사용자들은 계기판에 표시된 아이콘을 인식하고, 자연스럽게 자신의 최고 지점을 갱신하기 위해 노력할 것입니다. 숫자가 함께 한다면 좀 더 효과적으로 반응을 이끌어낼 수 있습니다. 아이콘보다 더 강조해서, 계기판 중앙에 ‘나의 최고속도 187km’를 표기해주는 것처럼요. 이렇게 하면 200km 처럼 딱 떨어지는 기념비적인 숫자를 만들기 위해 노력하는 사용자들도 생길 것입니다. 어쩌면 222km 를 찍었을 때 SNS에 공유할지도 모르고요.