얼마 전 개발자 지인을 만나 이야기하던 도중 모 회사의 과제 전형에 관한 이야기를 들었다. 회사마다 차이가 있겠지만 나의 경험을 돌이켜 보면 기능 정의 목록을 보여주고 특정 기간 안에 구현하라는 경우가 많았는데, 모 회사의 경우 좀 더 상세한 에러 핸들링에 대한 내용이었다. 미리 구현된 API 호출 코드를 보여주고 에러가 발생했을 때를 가정해서 에러 핸들링을 처리하는 과제였다. 자세한 요구사항은 모르겠지만 try, catch를 쓰기도 하고. 토큰이 만료되거나 여러 상황을 스스로 고려해서 처리를 요하는 걸로 느껴졌다. 또한 에러뿐만 아니라, 로딩 인디케이터를 처리하거나 pending 상태일 때 사용자에게 어떤 경험을 제공할지 고민해 보라는 의미였던 것 같다. 디테일한 처리를 요구하고 그 안에서 세심한 사고와 꼼꼼한 처리를 보고자 했던 게 아닐까.
더 나은 프로그래머가 되는 법에는 여러 가지 방법이 있겠지만 세심한 사고와 꼼꼼한 처리 또한 필수 덕목이라고 생각한다. 이는 개발 분야뿐만 아니라 아마추어와 프로를 구분 짓는 중요한 요소이기도 하다. 스스로를 아마추어로 만드는 가장 빠른 방법은 모든 일을 대충 처리하는 일임을 머저리 같은 순간의 나와 한심한 주변 사례를 보며 충분히 느껴왔다. 책의 한 문장을 인용하자면, ‘프로다운 접근 방식을 취하고 최고의 코드를 작성하려는 태도로부터 훌륭한 프로그래밍은 태어난다’.
책의 많은 부분에서 책임감에 대해 언급한다. 더 나은 프로그래머가 되기 위한 여러 방법을 제안하고 있지만 꽤 많은 방법의 근간으로 책임감을 요구한다. 예컨대 명명에 대한 이야기도 나오는데, 물론 회사마다 몇 가지 관용 어법이 있겠지만 결국 나머지는 상식과 책임감의 문제에 가깝다. 얼마 전 타사의 Open API의 key를 보고 당황했던 기억이 떠오른다. response로 받은 key 중에 name은 한글명이고 name1은 영문명이었다. vote_count라는 key의 데이터 타입은 문자열이었다. name_ko, name_en으로 명명하고 key에 걸맞은 데이터 타입을 내려주는 게 어려울 일이었을까, 대체 어떤 어른의 사정이 있었길래 그렇게 하지 못했을까. 여러 가능한 추측이 있겠지만 대충 처리했을 가능성이 높다. 뭐 특정 기간 안에만 사용되는 API였기 때문에 그렇게 명명했을지 모르지만 더 나은 프로그래머라고 보기는 어렵지 않을까.
흔히 접하던 DRY(Don’t Repeat Yourself)나 YAGNI(You Ain't Gonna Need It), KISS(Keep It Simple Stupid) 등이 언급되기도 한다. 최근 DRY에 어긋나는 코딩을 조금은 하고 있어서 다소 부채감이 있는데, SI 업체로부터 넘어온 코드를 수정하다 보니 부수 효과가 우려돼서 기존 코드를 수정하는 것보다 별도의 비슷한 코드를 만들어서 사용하는 부분이 있기도 하다. 내 나름대로 이유는 있었지만, 더 경각심을 가지고 작업할 필요가 있다는 점을 다시 느끼게 되었다.
이 책은 초반 몇 장만 넘겨봐도 꽤나 직설적인 문체를 가졌다. 문장을 하나 인용하자면, ‘돼지들이나 자신의 오물 안에서 산다. 프로그래머들은 그럴 필요가 없다. 코드를 작성한 후에는 스스로 정리하고 불필요한 코드는 즉시 제거하라’. 너무 당연한 말이지만, 때로는 귀찮거나 추후 활용할 가능성을 고려해 불필요한 코드를 두기도 했는데, 사찰을 당한 것처럼 뜨끔한 기분이었다. 일부는 유쾌한 농담처럼, 일부는 블랙 코메디처럼 문장을 풀어내는 재주가 있다. 냉소와 위트를 오가는 문장들이 꽤 유쾌한 선배를 곁에 둔 느낌이다.
태도에 대한 이야기도 여러 방면에 걸쳐 반복적으로 언급된다. 주변 사람에게 도움을 얻는 태도, 즉 도움을 요청하거나 질문을 할 때에는 앞서 구글을 통해 검색해보고 언제나 공손하고 감사해야 한다는 점이다. 내 숙제를 대신해달라는 질문과 태도로는 좋은 도움을 얻을 수 없다는 맥락의 이야기를 한다. 그리고 후반부에는 더욱 태도에 대한 이야기가 많은데 그중 하나는 ‘자신의 언어를 사랑하라’는 섹션이었다. 웹 개발을 위해선 JavaScript를 공부하게 되는데, 공부와 동시에 많은 조롱을 함께 접하게 되는 언어이기도 하다. 독특한 부동소수점 연산이나 null의 타입이 object로 나오기도 하고, string과 number의 황당한 연산 등 그 유연성과 독특한 동작 덕분에 생기는 사례들이 있다. 나 또한 이 언어의 특성에 대해 짜증이 나기도 하고 지인과의 대화를 통해 놀리기도 했었다. 근데 언젠가부터 냉소적으로 조롱하는 것이 전만큼 즐겁진 않았다. 받아들여야 할 필요가 있음을 느끼기 시작한 무렵이었던 것 같다. 물론 WebAssembly를 사용하거나 Python을 사용하는 Django를 통해 개발할 순 있겠지만 현재의 웹 개발 환경에서는 완전히 대체하는 건 어렵다고 생각한다. 결과적으로 보면 사랑하고 받아들이는 것이 단순히 조롱하는 것보다 더 생산적인 활동일 수 있겠다는 생각으로 바뀐 것 같다.
책에서 언급한 윤리적인 프로그래머라는 표현은 조금 낯설기도 했다. 다만 코드를 작성하다 보면 딜레마에 봉착할 때가 있었다. 이 버그를 근본적으로 해결하기 위해서는 전체 구조를 뜯어 고쳐야 하지만 몇 가지 땜질로도 당장은 해결 가능한 순간을 마주했다. 그건 분명 기술 부채가 예상되는 순간이고 프로젝트의 안위, 혹은 회사의 이익 창출을 위해서는 개선해야 하는 일이기도 했다. 하지만 회사라는 곳이 근본적인 것을 한다고 해서 항상 환영받는 것도 아니고 한정된 시간 안에 땜질이 당장의 해결책인 경우도 있어서 그건 마음의 짐으로 남기 마련이었다. 하지만 근본적으로 해야 할 것들은 당장 못하더라도 백로그에 두고 언젠가 해결하겠다는 태도를 갖는 것 자체도 꽤 중요하다는 생각이 든다.
개발은 본인의 철학을 만들어가는 과정이라고 생각한다. 스스로 철학을 만든다는 것은 자신의 내면을 들여다보는 행위이기도 하다. 내면을 들여다보며 철학을 만든다는 건 일면 추상적인 부분이 있어서 다소 어렵게 느껴질 수도 있는데 이 책은 그 과정에 도움이 되는 조언들로 구성되어 있다. 500페이지가 안 되는 분량이 39개의 챕터로 잘게 쪼개져 있어 하루에 한 챕터씩 세심하게 읽어나가면서 자신의 철학을 세워 나가는 것도 좋은 방법이라는 생각이 들었다. 조만간 내게 적용해서 다시 읽어나갈 마음을 갖고 있다.
"한빛미디어의 후원으로 책을 받아 작성합니다."
