안녕하세요, 데이블 Service Frontend 팀의 위젯 개발 담당 조민지입니다.

우리의 코드는 기본적으로 좀비 바이러스를 갖고 태어납니다. 내가 짠 코드 한 줄이 죽지도 않고 언제까지 살아 돌아다닐 지 우리는 알 수 없습니다. 한 가지 희망은, 항체를 주입해 건강한 코드가 되느냐, 좀비 바이러스가 발현되어 ‘레거시’라는 이름을 갖게 되느냐가 우리 손에 달려있다는 것입니다.

레거시의 계엄 상황에서 벗어나려면 우리는 무엇을 할 수 있을까요?

코드는 이야기다

로버트 C.마틴의 <클린 코드>는 네이밍과 형식, 주석, 오류 처리 등 프로그래밍의 다양한 요소를 기준으로 “클린한” 코드를 짜는 방법에 대해 세세하게 말합니다. 이 책의 제안에 대해서는 많은 해석이 있는 만큼 프로그래밍의 정석, 정답이라고 단정 짓기는 어렵습니다. 하지만 책을 관통하고 있는 하나의 전제에 대해서는 모두 공감하실 거라 생각합니다.

코드는 이야기다. 이야기를 들려주듯 코드를 작성해야 한다.

‘당연한 얘기인데?’라고 생각하실 수 있습니다. 그래서 모두 당연히 알고 계실 내용을 조금 다른 시각에서 살펴봤습니다.


이야기에 코드 엮어보기

이야기와 코드를 세세하게 엮어 보기에 앞서, 이야기가 누군가에게 공유되려면 책으로 출판되어야 하고 코드 역시 나 혼자 보는 것이 아니라 누군가와 공유되는 것이기 때문에, 이야기에서 한 단계 더 나아가 책을 기준으로 비교한 부분도 있음을 말씀드립니다.

이야기(책)이 만들어지는 과정

먼저 책이 만들어지는 과정을 단계별로 살펴보겠습니다. 작가마다 이야기를 만드는 과정은 다를 수 있지만 가장 일반적인 플로우를 생각해봤습니다.

1. 주제 선정 vs 업무 목표 선정

가장 먼저 주제를 선정하겠죠. 이것은 작가의 역할일 수도, 출판사의 제안일 수도 있습니다.

개발 측면에서 주제 선정은 업무 목표가 선정되는 것과 같다고 봤습니다. 개발팀의 업무 목표는 개인이 직접 선정할 때도 있지만 사업팀의 요청과 우선순위에 따라 선정되는 경우도 많습니다.

2. 계획 vs 설계

주제가 선정되면 작가는 구체적으로 어떤 글을, 어떤 흐름으로 쓸지 계획을 세울 것입니다. 개발에서의 설계와 비슷해 보입니다. 얼마나 견고하게 설계하느냐에 따라 이후에 쓰고 지울 코드의 양이 달라지기 때문에 이 단계가 정말 중요하다고 생각합니다.

설계 단계를 거치지 않고 바로 코드를 작성하시는 분들도 계실 수 있지만, 이미 많은 경험이 축적되어서 무의식중에 설계가 끝났거나 코드를 작성하면서 더 좁은 단위로 설계를 해나가시는 게 아닐까 생각합니다. 설계 없이도 완벽한 코드를 짤 수 있는 분이 계신다면 정말 부럽습니다.

3. 집필 vs 코드 작성

이제 정말 글을 쓸 차례입니다. 계획이 잘 되었다면 글은 술술 나올 것 같지만, 그렇지도 않습니다. 애초에 정말 잘 세웠다고 생각했던 계획을 뒤엎어야 할 때도 있고, 계획을 더 구체화할 필요도 있을 것입니다. 코드를 작성할 때도 똑같습니다. 설계할 때까지만 해도 완벽했는데, 정작 마음에 드는 코드 한 줄을 완성하기까지 오랜 시간이 걸리기도 합니다.

같은 이야기도 스토리를 어떻게 풀어가는지, 얼마나 맛있게 전하는지에 따라 독자의 집중도가 달라집니다. 말을 맛있게 하면서 간략하게 하는 것은 더 어렵습니다. 모두가 모든 코드를 본다면 코드를 어떻게 풀어 쓸지만 생각해도 될 것입니다. 하지만 매번 모든 코드를 보는 것은 불가능합니다. 가볍게 보더라도 전체적인 흐름을 이해할 수 있도록 돕는 것 역시 우리의 역할입니다.

구체적으로는 네이밍에 의미를 담아야 하고, 비슷한 역할을 하는 함수끼리 가깝게 두고, 추상화를 통해 선택적으로 필요한 정보만 볼 수 있게 하는 것 등이 있습니다. 마치 책에서 하나의 긴 챕터 안에 내용을 드러내는 소제목을 제공해서, 소제목만 보고도 독자가 필요한 내용을 골라볼 수 있도록 하는 것과 같습니다.

4. 퇴고 vs 셀프 코드 리뷰

글을 쓸 때 꼭 거쳐야 하는 단계가 바로 퇴고입니다. 잘못된 표현, 불필요한 내용을 걸러내고 전체적인 흐름을 다시 맞춰보는 과정입니다.

코드를 작성할 때도 셀프 코드 리뷰를 통해, 초안에서는 ‘아, 너무 잘 짰다’ 했던 생각이 ‘누가 이런 코드를 짰나’로 바뀌기도 하고, 셀프 QA도 해보면서 생각하지 못했던 에러 핸들링을 추가할 수도 있습니다.

5. 편집 vs 피어 코드 리뷰

이제는 편집자에게 역할이 넘어갑니다. 편집자는 단순한 교정, 교열부터 전체적인 흐름을 다듬는 것까지 매우 다양한 역할을 합니다. 책 한 권이 출판되기까지 집필-퇴고-편집의 과정이 한 번 만에 끝나는 게 아니라 반복적으로 진행되고, 그래서 편집자의 역할이 작가만큼이나 정말 중요합니다.

우리에게 편집자는 동료이고, 편집은 동료들의 코드 리뷰라고 생각합니다. 코드 리뷰가 가벼운 교정, 교열에서 끝날 수도 있고 더 깊은 내용까지 나눌 수도 있지만 내용의 경중을 떠나 코드 리뷰를 하는 나의 역할도 중요하다는 걸 기억해야 합니다. 개인적으로는 코드 리뷰를 할 때, ‘이 코드의 전체적인 흐름을 이해하기 위해 나는 노력을 했는가’와 같은 가벼운 질문을 스스로 던져보기도 합니다.


이야기(책)의 구성

이런 과정으로 만들어진 책의 구성요소를 코드에 한 번 빗대어 보려고 합니다.

1. 목차 vs 다이어그램

먼저 목차입니다. 목차는 책의 흐름을 담고 있습니다. 책의 제목만으로는 내용이 파악되지 않을 때, 우리는 목차를 보고 더 구체적인 내용과 전체적인 흐름을 파악합니다. 앞서 봤던 ‘계획’ 단계의 결과가 목차에 담깁니다.

개발에서는 다이어그램이 목차의 역할을 한다고 생각합니다. 글로 쓰인 기능개발문서일 수도 있지만 가장 직관적으로 흐름을 보여주는 건 도식화된 다이어그램이라고 생각했습니다.

2. 프롤로그 vs README

목차를 지나면 프롤로그(서문, 들어가는 말)이 나옵니다. 프롤로그에는 작가가 전체 이야기를 쓴 목적과 의도가 담겨있습니다.

우리는 README에 코드를 짠 이유와 그 역할을 간략하게 담을 수 있습니다. 잘 정리된 README는 코드 진입장벽을 낮춰 독자의 이해를 도울 수 있습니다.

3. 본문(+각주) vs 코드(+주석)

책에서의 본문은 우리에게는 코드입니다. 앞서 말씀드린 ‘과정’에서 본문과 코드에 대한 이야기는 어느 정도 다루었기 때문에 그 안에 포함된 각주와 주석에 대해서만 살펴보려고 합니다.

책에서 각주는 인용한 경우 출처를 밝히거나, 번역가의 번역 의도를 담는 등의 목적으로 쓰는데, 역으로 말하면 반드시 표기해야 하거나 독자의 이해를 돕기 위한 경우가 아니면 달 필요가 없는 것이기도 합니다.

코드에서도 주석을 활용하기보다는 코드 자체에 그 의미를 최대한 녹이고, 최후의 수단으로 주석을 고려해야 합니다. 주석의 최초 작성자는 코드가 업데이트될 때 주석도 업데이트되길 기대하지만 정확한 히스토리를 파악할 수 없는 주석은 함부로 건드릴 수 없는 존재가 됩니다. 반드시 주석을 활용해야 한다면, 정확한 정보를 전달할 수 있도록 친절하게 작성해야 합니다.

4. 부록 vs 기능개발문서

부록은 책의 필수 구성요소는 아닙니다. 그래서 부록을 글로 자세히 적힌 기능 개발 문서와 같다고 생각했습니다. ‘기능 개발 문서를 선택적으로 제공해야 한다’는 의미가 아니라 ‘누구나 다 기능 개발 문서를 보는 것은 아니다’의 관점입니다. 더 깊게 알고 싶거나 궁금한 게 있을 때 부록의 일부를 찾아보기도 하지만 부록을 봐야만 책의 내용을 이해할 수 있는 것은 아닙니다. 기능 개발 문서 역시 보조 수단은 될 수 있지만 코드만으로도 이해를 할 수 있어야 합니다.


그래서 우리는 무엇을

얼마 전 넷플릭스에서 인기를 끌었던 드라마 <지금 우리 학교는>을 보고 가장 기억에 남은 키워드는 ‘책임감’이었습니다. 이 드라마에는 책임지지 않고 방관하는 사람들과 앞장서서 책임지는 사람들이 등장합니다.

앞서 우리는 과정, 구성 측면에서 이야기와 코드를 비교해봤습니다. 지은이도 편집자도 출판사도 혼자 다 해야 한다면 모든 책임을 혼자 질 수 있습니다. 하지만 우리는 회사에 다니고 동료가 있고, 코드의 초판은 내가 쓸지언정 개정판의 지은이나 편집자는 누구나 될 수 있습니다. 그래서 모두가 지은이로서 편집자로서 책임을 다하고 협업을 해나가는 과정이 있어야 ‘잘 쓰인 이야기와 같은 코드’가 나올 수 있다고 생각합니다.

이 방향성에 대해서는 이미 모두 알고는 있지만 현실에서는 지키기 어려운 상황들도 분명히 있습니다. 일정이나 리소스를 고려해서 당장은 결과에 초점을 맞춘 코드를 작성해야 할 수 있습니다. 하지만 첫 배포를 끝으로 영영 떠나보내는 것이 아니라, 다시 돌아와서 책임지는 방법도 있습니다. 책의 초판에서 놓친 것을 2판에서 업그레이드하듯, 우리도 리팩토링을 통해 2판, 3판의 코드를 작성할 수 있습니다.

모두가 책임 있는 코드를 짤 때 우리의 코드는 좀비로 변하지 않을 것이라는 희망 회로를 그려보면서 이야기를 마무리하겠습니다. 감사합니다.