무근본 주니어의 좋은 코드

근본없는 개발자, 주도현

안녕하세요. 블로그를 통해 처음 인사드리는 주도현입니다. 저는 미술학사 웹 개발자로 시각디자인 전공으로 학사를 마치고 본격적으로 개발에 뛰어들었습니다. 개발을 시작하기로 마음먹고 4년 간은 자잘한 개인 프로젝트와 지인을 통한 외주작업을 위주로 작업했습니다. 그리고 지금엔 획기획에서 외주와 BE, FE에 걸쳐 얕지만 다양하게 개발을 이어나가고 있습니다. 커리어로 보나, 하고 있는 일로 보나 근본있는 사람은 분명 아닌 것 같습니다. 그런 제가 획기획에서 처음으로 쓰는 글로 ‘좋은 코드’에 대한 이야기를 해보고자 합니다. 근본없는 미술학사 주니어로서 조금은 주제넘은 주제가 아닌가 저 또한 생각합니다. 하지만 이 글을 끝까지 읽으신다면, 제가 어떻게 이렇게 주제넘을 수 있는지에 대해서도 조금은 이해하시게 될 거라고 믿습니다.

‘좋은 코드’는 무엇일까?

저는 혼자 일했기 떄문에 획기획에 입사하기 전의 코드가 모두 자기중심적입니다. 제가 아니면 그 누구도 함부로 제 코드를 건드릴 수 없습니다. 어떤 사이드 이펙트가 생길지 모르며, 독자적인 코드스타일로 코드 자체를 파악하는데도 큰 시간이 소요됩니다. 어떤 코드스타일이라고 규정하는 것도 이상합니다. 문제가 발생할 때마다, 수정사항이 생길 때 마다 덕지덕지 코드를 편한곳에 붙여 당장에 기능이 구현되는 데에만 집중했기 때문입니다. 이런 코딩 스타일은 큰 문제가 되지 않습니다. 버그가 생기고, 예기치 못한 사이드 이펙트가 생겨도 제가 수정한다면 다 커버할 수 있습니다. 하지만 누군가와 같이 일 하게 되면 문제입니다. 다른 누군가는 내 코드를 건드리고 이해할 수 없기 때문입니다. 그리고 정말 문제는 개발자로서 커리어를 이어나가려면, 더욱 성공하는 서비스를 개발하기 위해서라면 누군가와 함께 일하는 게 필수적이라는 점입니다. 심지어는 그 누군가가 미래의 ‘나’일 수도 있습니다. 지금의 나만 이해할 수 있는 코드를 쓰게 된다면, 나는 그 프로젝트에 갇히고 말것입니다. 시간이 지나서도 그것을 알아보고 유지보수 할 수 있다는 보장이 없기 때문에, 난 항상 그 프로젝트를 예의주시하고 있어야 하기 때문입니다. 이렇게 무리한 설명을 보태지 않아도 누구나 보기 좋고 수정하기 좋은 코드를 작성하는 것은 백익무해하다는 사실을 우리는 이미 모두 공감하고 있을 것입니다. 그럼 ‘좋은 코드’는 무엇 일까요? 좋은 코드의 기준은 다양할 겁니다. 제가 생각하는 좋은 코드는 ‘의도가 명확한’코드 입니다.

소프트웨어의 아름다움은 끊임없는 수정보완에서

‘의도가 명확한’ 코드가 좋다고 생각하는 제 의도를 설명하기 위해서는 먼저 소프트웨어의 아름다움에 대해 이야기해야합니다. 소프트웨어는, 특히 웹 어플리케이션의 아름다움은 끊임없는 수정보완에서 나온다고 생각합니다. 세상의 다른 것들과 다르게 소프트웨어는 릴리즈 된 이후에 수정 보완하여 다시 릴리즈 하는 것이 가능합니다. 이걸 자동차나 가구, 음식, 인쇄물 등 하드웨어에 대입하여 생각해보면 정말 대단한 일입니다. 한번 잘못 시장에 팔려나간 하드웨어들은 거둬들일 때 큰 비용을 수반합니다. 그들의 불량률을 관리하는 것이 얼마나 거대한 일인지에 대해 생각해보면 더욱 그렇습니다. 반면, 소프트웨어는 심하게 표현하여 언제나 수정보완이 가능합니다. 그에 따라 투여되는 리소스도 하드웨어에 비해 거의 없다고 봐도 되는 수준입니다. 소프트웨어의 이런 점이 ‘의도가 명확한’코드를 좋은 코드로 만듭니다. 지금 ‘당장’의 코드의 유려함이나 기술적 구현의 올바름은 중요하지 않습니다. 코드 자체가 의도한 바를 명확하게만 나타내고 있다면 우리는 ‘미래’의 내가 그 코드를 수정할 수 있음을 알고 있습니다. 심지어는 그 의도가 명확하다면 내가 아닌 제 3자도 그 코드의 목적을 이해하고 보다 유려하고, 기술적으로 효율적인 방식으로 코드를 수정할 수 있습니다. 여기서 말하고자 하는 점은 코드의 유려함, 효율성, 기술적 정합성에 대해 고민하지 말자는 것은 아닙니다. 그런 고민은 ‘현재’ 더 좋은 코드를 작성하기 위해 필요합니다. 다만 의도를 명확하게 하는 코드가 미래의 ‘발전 가능성’을 어느정도 보장하는 부분이 있기 때문에, 좋은 코드를 대표하는 다양한 지표들 가운데, ‘의도의 명확성’이 가장 핵심적인 좋은 코드의 지표라는 것을 말하고자 합니다.

명확하고 쉬운 코드

이런 방식으로 생각하면 ‘좋은 코드’를 만드는 다양한 스킬들은 자연스럽게 머리에 떠오르게 됩니다. 내 코드의 의도를 명확히 하기 위해 주석을 달거나, 함수로 일련의 과정을 추상화할 수 있습니다. 로그를 남기는 것도 내가 무슨 작업을 하려고 했던 것인지 정확하게 구분하고 명확한 이름을 작성하게 됩니다. 이런 점들은 다른 개발자와 미래의 내가 코드를 ‘예측’할 수 있게 돕습니다. 무엇이 어떻게 움직일지 알면, 내 행동을 정하는 것은 어렵지 않은 일이됩니다. 협업하는데 있어 커뮤니케이션 비용이 줄고, 각자가 유기적으로 개발에 참여할 수 있게 됩니다. 예측을 돕는 코드는 실제 프로덕션이 어떻게 작동할지에 대한 명확한 힌트도 제공하기 때문에, 협업에 참여하는 개발자들이 서비스의 맥락을 이해하게 돕는데도 큰 기여를 합니다. 결국 코드는 파악하기 쉬워집니다. 읽는 사람이 편해집니다. 생각없이 구현에 급급해 작성해나간 지저분한 코드를 파헤쳐 정확하지 않은 저자의 의도를 추측하지 않아도 됩니다. 그러다 발생할 수 있는 사이드 이펙트에 두려워하지 않아도 됩니다.

어떻게 쓸까

우선, 섣불리 작성하지 않고, 어떤 기능을 어떻게 작성할지 구상하고 코드를 작성합니다. 디자인은 하나의 결과물을 끊임없이 실험하고 구상하면서 결과물을 만들어나갑니다. 그 과정의 시작으로 ‘스케치’를 진행합니다.(물론 그 이전에 개념을 표현하기 위한 다양한 방법 및 메타포들을 아이데이션합니다.) 스케치 단계는 머리속에만 있는 디자인 결과물에 대한 흐릿한 이미지를 현실세계에 꺼내어 디자이너로 하여금 ‘판단’할 수 있게 돕습니다. 코드 또한 마찬가지의 과정을 거치면, 보다 정제된 코드를 쓸 수 있습니다. 이는 프로그램의 작동 플로우를 도식화하거나, 수도코드를 작성함으로써 달성할 수 있습니다. 이런 과정들은 지엽적인 코드를 작성하기 이전에 코드의 전체적인 맥락을 파악하는 데 큰 도움이 됩니다. 그렇게 되면 내가 작성하는 코드의 목적성이 명확해지고, 불필요한 낭비 없이 ‘의도’에 맞는 코드를 작성할 수 있게 됩니다. 그렇게 목적의식이 명확해지면, 코드의 사이드이펙트 또한 줄어드는 효과가 있습니다. 이 때 작성하는 코드는 복사 붙여넣기, 중복을 적극적으로 활용하여 작성합니다. 최대한 전 과정을 직관적으로 이해할 수 있는 코드를 작성하는 것에 유의하며 작성합니다. 코드의 섣부른 ‘간결화’는 지나치게 코드를 추상화하여 맥락이 없는 다른 개발자들에게 혼란을 야기할 수 있습니다. 초기에는 중복을 두려워하지 말고 한눈에 이해하기 좋은 코드를 지향하여 작성하되, 개발하기로 목적한 기능 구현이 일단락 된 뒤에, 전체 구조를 조망하며 부분 부분으로 추상화하여 간결화하면 됩니다.

결국엔 방향성의 문제

조금은 추상적이고 당연한 이야기를 했는지도 모르겠습니다. 이 글에서 이야기하는 좋은 코드에 대한 이야기도 사실은 하나의 ‘이상적인 추구’에 불과할 것입니다. 하지만 어떤 길을 가느냐보다 중요한 것은 어떤 방향으로 가는지에 대한 것이라고 생각합니다. 이런 이상적인 추구는 내가 앞으로 코드를 작성할 때 기준으로 삼을 수 있는 중요한 지침이 될 것입니다. 세상에는 수 많은 방법론이 있고, 그 방법론을 수용하는 것은 우리의 몫입니다. 때문에 좋은 코드에 대한 자신만의 고민을 하는 것은 필수적이고, 방법론 이전에 키워나가야 하는 것이라고 생각합니다. 따라서 이 글 또한 결국엔 어떤 코드를 좋은 코드로 바라볼것인가에 대한 접근입니다.

이 세상에 좋은 코드의 수는 개발자의 수와 같다.

“이 세상 맛있는 요리의 수는 어머니의 수와 같다” 식객에 나오는 유명한 대사입니다. 이 말처럼 ‘좋은 코드’를 규정하는 말은 이 세상 개발자의 수와 같을 것입니다. 모두가 각자의 기준으로 좋은 코드를 그리며 오늘도 키보드를 열심히 두들기고 있으니 말입니다. 이 글 또한 수 많은 개발자 중 하나, 근본없는 주니어가 그리는 이상적인 좋은 코드에 대한 이야기입니다. 여러분은 어떻게 생각하시나요? 제 생각에 공감하시나요? 아니면 다른 생각을 하고 계신가요? 당신이 생각하는 좋은 코드란 무엇입니까?