💻 개발 경력 14년, 여전히 프로그래밍은 어렵다 (1)

Piglei님의 블로그를 의역/요약한 글입니다. --- 오래전, 곧 졸업을 앞두고 있던 나는 인턴 자리라도 알아볼 겸 취업 공고들을 살펴보고 있었다. 인턴 자리도 많이 봤지만 호기심에 “경력” 개발자 공고도 몇 개 훑어봤다. 대부분 “최소 5년 이상의 경력”을 요구했기에 “개발 경력 5년 정도면 완전 잘하겠지? 밥 먹듯이 코딩하니까?”라고 생각하며 높은 연차가 곧 실력을 뒷받침할 거란 막연한 상상을 하기도 했다. 업계에 몸 담은 지 14년이 지난 지금, 되돌아보면 그때 생각했던 많은 부분들이 틀렸음을 깨달았다. 그동안의 경험을 바탕으로 프로그래밍에 대한 고찰을 여덟 가지로 추려봤는데, 누군가 공감을 할 수 있다면 더할 나위가 없겠다. 1) 코드를 작성하는 건 쉽지만 좋은 코드를 작성하는 건 어렵다. 옛날에는 프로그래밍이 입문하기 상당히 어려운 분야였다. 입문하려면 여러 책과 문서를 찾아봐야했고 초심자들이 읽기에는 벅찼다. 그래서 대부분은 프로그래밍의 진정한 재미를 알기 전에 포기했다. 이제는 아니다. 개발을 시작하는 방법은 무수히 많으며 더 이상 Java나 C를 고집하지도 않고 관련 IDE도 비약적으로 발전했다. 이제는 누구나 쉽게 배워볼 수 있는 기술이 되었다. 하지만, 쉽게 접근할 수 있는 것과 좋은 코드를 작성하는 것은 다르다. 지금 회사 코드를 떠올려보자. 좋은 코드가 더 많은가 아니면 별로인 코드가 더 많은가? 당신의 답이 뭔지는 모르겠지만 나부터 공유하자면: 좋은 코드는 희귀하다. 2010년, 잘 알려진 인터넷 회사로 이직했다. 이 회사 이전에는 스타트업에서만 일을 했기에 드디어 “좋은 코드 퀄리티”를 접해볼 수 있다는 기대감에 들떠있었다. 그리고 그 기대감은 일주일도 되지 않아 사라졌다. 프로젝트 코드는 내가 생각한 “좋은 코드 퀄리티”와는 완전히 동떨어져 있었고, 아주 작은 수정 사항을 반영하려고 해도 손을 덜덜 떨면서 코드를 작성해야 할 정도였다. 이후 여러 회사를 거치면서 느낀 점은: 회사나 프로젝트 규모와 상관없이 좋은 코드를 접할 기회는 손에 꼽는다. 좋은 코드는 무엇인가? 좋은 코드가 무엇인지 논할 때 Martin Fowler를 많이 인용하고는 한다. “(의역) 컴퓨터가 이해할 수 있는 코드는 아무나 만들 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 만든다.” 이 문구를 시작점으로 생각해도 좋을 것 같다. 좋은 코드는 가독성이 좋고, 쉽게 이해할 수 있으며, 의도가 명확해야 한다. 좋은 코드를 작성하는 원칙은 코드의 독자가 사람이라는 것을 인지하는 것이다. 가독성 이외에도 좋은 코드는 여러가지를 고려해야 한다. * 프로그래밍 언어 표준을 잘 준수하는지: 개발 언어가 제시하는 표준을 잘 따르는지, 개발 언어의 syntactic sugar나 기능을 적재적소에 잘 활용하는지 * 변경이 용이한지: 미래 변경 사항을 쉽게 반영할 수 있는지 * 사용하기 쉽고 확장하기 쉬운 API 디자인: 간단한 시나리오를 쉽게 구현할 수 있는지, 용도에 맞게 좀 더 고급 기능으로 확장할 수 있는지 * 괜찮은 성능: 현재 비즈니스 요구 사항을 맞출 수 있는 성능인지, 더 최적화를 할 여지가 있는지 * 오버-엔지니어링 방지: 과하게 복잡하거나 섣부른 최적화를 하지는 않았는지 즉, 좋은 코드는 쉽게 만들어지는 것이 아니다. 좋은 코드를 작성하기 위해서는 여러 차원을 고려하여 최적의 균형을 찾고, 세심한 디자인을 반영하고, 끊임없이 수정해나가는 것이다. 좋은 코드를 작성하는 방법을 빠르게 깨우칠 수는 없을까? 좋은 코드 작성을 위한 지름길 코드 작성은 글쓰기와 많은 면에서 유사하다. 방식은 살짝 다르지만, 둘 다 글자와 기호로 아이디어를 전달한다. 글을 잘 쓰는 사람들이나 작가들은 직접 글을 쓰는 시간도 많지만 다른 사람의 글을 읽는 시간도 많다. 개발자들은 독서를 소홀히 하는 경우가 많다. 좋은 코드를 작성하는 방법을 깨우치고 싶다면 독서도 게을리해서는 안된다. 우리가 매일 접하는 회사 코드 외에도 좀 더 고전적인 소프트웨어 개발 책이나, API 디자인, 모듈 아키텍처, 코드 작성 방법론 등에 대해 읽어보기를 권한다. “독서 ↔ 프로그래밍”이라는 무한 사이클이 프로그래밍 실력을 키우는 지름길이다. 2) 프로그래밍의 본질은 “창작”이다 프로그래밍을 하다 보면, 간혹 엄청난 성취감과 함께 “개발이 최고야!!!”라고 내적 외침을 지를 때가 있다. 예를 들면, 엄청 잡기 힘든 버그를 완벽하게 고쳐내거나, 새로운 알고리즘으로 성능을 몇 배 향상 시키는 것들 말이다. 하지만, 이것들과 비교될 수 없을 만큼 “창작”은 한 차원 다른 성취감을 준다. “창작”은 개발하는 매 순간 존재한다. 단순히 새로운 버전을 릴리즈하는 것 뿐만 아니라, 재사용성을 위한 유틸리티 함수, 좀 더 명확한 데이터 모델 구현 등 많은 것들이 “창작”이 될 수 있다. 개발자들이 “창작”에 대한 열정을 가지고 있는 것이 중요한 이유는: * 효율적인 학습: 새로운 것을 만들며 얻는 배움이 가장 효과적이다 * 예기치 못한 일들을 접할 수 있음: 유명한 오픈 소스 프로젝트 중 창작자의 호기심에서 시작된 것이 많다. 예를 들면 리눅스나 파이썬. “창작”이 주는 이점도 많고 개발자들에게 기회도 열려있지만, 많은 개발자들이 “창작자”가 되어야 하는 이유를 모르고 있는 것 같다. 이는 한 철학자와 벽돌공들의 이야기와 유사하다. 철학자가 두 명의 벽돌공에게 무엇을 하고 있는지 묻자, 한 명은 성당을 짓고 있다고 했고, 다른 한 명은 단순히 벽돌을 쌓고 있다고 대답했다. 대부분의 개발자들은 후자다. 성당을 보지 못하고 단순히 벽돌 쌓기를 하고 있다. “창작자”가 되어보면 일에 대한 관점이 확연하게 달라진다. 가령 API의 에러 메세지를 작성할 때도 관성적으로 메세지를 작성할지 아니면 어떤 에러 메세지를 반환해야 좀 더 좋은 유저 경험을 만들 수 있는지 고민하게 된다. 이렇듯, “창작자 마인드셋”은 개발 커리어에 있어 중요한 동기가 된다. 스스로에게 되물어 보자: “다음으로 만들고 싶은 것은 무엇인가?” --- 분량 조절 실패로 다음 포스트에서 이어집니다 (TBC) 원글: https://www.piglei.com/articles/en-programming-is-still-hard-after-14-years/