어떻게 하면 개발을 잘할 수 있을까요?

"어떻게 하면 개발을 잘 할 수 있을까요?" 많은 개발자들이 이런 질문을 주변의 동료나 선배들에게 합니다. 이 질문에 대해서는 많은 대답이 있을 수 있고, 사람마다, 조직마다, 무엇을 개발 하느냐에 따라 혹은 개발에 대한 정의에 따라 다른 답이 나올 겁니다. 올해 초 같이 일하는 중국 개발자들을 대상으로 이 주제로 발표할 자리가 있어 몇장의 발표자료를 만들었는데 그 자료에 있는 내용을 정리해볼까 합니다. 참고로 필자가 이 발표를 통해 읽기 쉽고, 예쁜 코드를 만들기 위한 노력, 논리적인 고민을 많이 할 것을 강조하고 싶었기 때문에 이런 내용으로 정리되었습니다. 이 글을 읽으실 때에 이런 의도를 감안하시고 읽어 주셨으면 합니다.

이미지 출처: https://www.cyphercoders.com/themes/creative-writing

기본에 충실하자!

개발을 하는데 있어 필요한 기본 지식들이 있습니다. 이런 지식들은 프로그램을 만드는데 있어 반드시 필요한 지식들입니다. 하지만 이런 지식을 배우고 이해하는데 소홀한 경우가 많습니다. 이런 지식은 가능하면 정규화된 과정을 통해 배울 것을 권장합니다. 대학에서 전공으로 들으면 좋겠지만 이미 다른 전공으로 졸업했다면 굳이 대학에서 공부할 필요는 없고, 최근에는 많은 온라인 강좌나 오프라인 강좌에서 이런 교육 과정을 가지고 있기 때문에 기회가 있으면 강좌를 들어볼 것을 추천합니다.

Programing Language Theory

개발을 할때 개발자가 자신의 생각과 로직을 표현하는 도구로 사용되는 것이 프로그램 언어입니다. 따라서 프로그램 언어는 개발에 있어 가장 중요한 도구라고 할 수 있습니다. 필자가 공부하기를 원하는 분야는 프로그램 언어 그 자체가 아닌 "Programing Language Theory" 입니다. 즉, 프로그램 언어의 기본 이론에 대한 부분인데 프로그램 언어가 가지고 있는 특징, 개념들(구조형, 객체지향, 함수형) 등에 대한 내용을 다루는 분야라고 볼 수 있습니다. 필자의 경우 1997년 학교에서 배운 프로그램 이론이 새로운 언어를 익힐때나 디버깅을 하는데 아직도 많은 도움이 되고 있습니다.

Operating System

우리가 만드는 모든 프로그램은 운영체제 위에서 실행됩니다. 우리의 생활에 비쳐보면 우리가 살고 있는 터전, 사회에 해당되는 것입니다. 이 터전과 사회에 대한 이해 없이 우리가 생활할 수 없듯이 프로그램이 실행되는 환경인 운영체제에 대한 이해가 없이 좋은 프로그램을 개발하기는 어렵습니다. 많은 도구와 컴파일러들이 운영체제와 프로그램 언어 사이의 간극을 메워주고는 있지만 운영 체제에 백그라운드 지식 없이 개발을 하는 것은 지도 없이 낯선 환경에서 길을 찾아 가는 것과 같은 상황이 될 것입니다. 다른 장점으로는 운영체제 개념에서 설명되는 많은 개념들이 실제 프로그램에서도 사용할 수 있다는 겁니다. 운영체제 과목에서 설명하는 병렬처리, 락, 페이징, 메모리 관리 등의 기법들은 실제로도 많은 프로그램에서도 사용하는 기법들입니다.

Database Theory

데이터베이스는 기업용 애플리케이션이나 인터넷 서비스/앱 등에서는 필수적으로 사용되는 개념입니다. 이 절의 제목도 "Theory" 인 것처럼 단순히 오라클, MySQL 과 같은 데이터베이스 관리 솔루션이나 SQL이 아닌 데이터베이스 이론을 학습해야 합니다. 필자가 대학에서 배운 데이터베이스 이론은 많은 부분이 관계형 데이터베이스에 집중되어 있었는데 추측컨데 최근에는 다양한 이야기가 나올 것 같습니다. 조금 더 나아가면 단순 데이터베이스 뿐만 아니라 데이터 그 자체를 다루는 분야까지 확대해서 공부하면 더 좋을 것 같습니다. 참고로 필자의 대학 전공은 컴퓨터 사이언스가 아니라 "정보공학(Information Engneering)"이 었습니다.  30년전이었는데 이런 이름으로 전공을 만든 교수님들의 안목이 놀라울 따름입니다.

Network

워드프로세스나 계산기 등과 같은 프로그램을 제외하면 요즘의 모든 프로그램이나 서비스나 네트워크 자원을 항상 사용하고 있습니다. 프로그램 운영 중에 발생하는 많은 문제도 네트워크 병목, 네트워크 단절, Timeout 등의 문제입니다. 이런 문제에 대한 방어적인 프로그램을 만들거나, 문제 발생 시 원인을 해결하기 위해서는 네트워크 동작 원리에 대한 기본 지식이 필수라 할 수 있습니다. 네트워크 장비나 망 전체에 대한 설계, 운영 등은 인프라 팀이나 클라우드 사업자가 대신해 줄 수 있지만 프로그램 자체에서 발생하는 네트워크 관련 문제는 개발자들이 해결해야 하고, 이런 내용들이 코드에 반영되어야 합니다. 이를 위해서 네트워크에 대한 기본 지식이 반드시 필요합니다.

기타

이런 기본 과목 이외에 최근에는 다양한 개념들이 나오고 있습니다. 불과 10년 전에만 해도 분산 컴퓨팅은 일부 슈퍼컴퓨팅이나 연구소 등에서 사용하는 개념이었던 것이 일반적인 프로그래밍이나 서비스 운영 환경에서 사용되고 있습니다. 데이터 분석에서 많이 사용하는 Hadoop이나 NoSQL 의 많은 솔루션 들은 이런 분산컴퓨팅의 여러 개념들을 녹여낸 솔루션이라 할 수 있습니다. 이들 솔루션을 잘 이해하고 사용하기 위해서도 분산 컴퓨팅의 기본 이론이 필요할 것입니다.  이외에 딥러닝, AI 등과 같은 분야도 새롭게 나타나고 있습니다. 이렇게 기술적으로나 사용적인 측면에서 새롭게 나타나고 있는 기술도 실제로는 이론적으로는 과거 수십년 동안 축적된 이론을 기반으로 해서 출현된 것들입니다.  가능하면 이론적인 내용도 같이 보는 것이 이들 관련 프로그램을 잘 만드는 방법이 아닐까 합니다.

에피소드

이런 기본 지식 학습과 관련해서 두가지 에피소드가 있습니다. 하나는 저의 오랜 지인에 대한 이야기입니다. 이 지인은 컴퓨터 사이언스를 전공으로 하지 않고 재료공학(특히 반도체 분야)을 전공 했습니다. 필자는 항상 이 개발자에게 농담삼아(비하할 의도가 없습니다. 오해 하지는 마세요) "모래 전공하니까 이런 코드가 나오지!"라고 놀렸습니다. 제 말에 자극 받았는지는 모르겠지만 이 지인은 개인적으로 앞에서 나열한 기본 지식에 대해 공부를 많이 했습니다. 흔히 말하는 공룡책(운영체제)도 알고, Linux 커널에 대해서도 누구보다 더 많이 알고 있습니다. 이 지인은 지금은 저보다 훨씬 더 깊은 기본 지식을 가지고 있습니다. 운영체제, 네트워크 등에 궁금한 점이 있으면 항상 이 친구에게 물어 봅니다.

다른 하나의 에피소드는 저에 대한 이야기인데 저도 처음 Hadoop을 접할 때에는 Hadoop부터 본것 아니라 분산 컴퓨팅, 파일 시스템에 대한 이론부터 공부를 했습니다. SI 프로젝트와 기업의 시스템 유지보수 경험이 전부였던 필자에게 분산 컴퓨팅은 미지의 분야 였습니다.  네이버 입사 당시 과거의 경험만으로 주어진 미션을 해결하기에는 부족하다고 생각하여 2 ~ 3개월 동안 집중적으로 분산컴퓨팅 분야의 논문과 솔루션 등을 분석하여 이 분야에 대한 이론적 배경과 카테고리 등을 나누는 작업을 했었습니다. 이 짧은 시기 동안에 학습한 내용이 이후 10년 가까이 많은 새로운 솔루션이 나왔을 때 이를 이해하고 업무에 적용하는데 있어 많은 도움이 되었습니다.

코드는 글쓰기이다. 좋은 글을 쓰려고 노력하자.

필자가 이번 글에서 강조하고자 하는 "프로그램 잘하는 방법에 대한" 주제입니다.  "프로그램을 개발한다" 라는 말 자체에는 많은 의미가 내포되어 있지만 "프로그램" 그 자체에 집중해보면 필자의 의견은

프로그램 언어를 이용하여 글을 쓰는 행위

라고 할 수 있으며, 좋은 프로그램을 만드는 것은 좋은 글을 쓰는 것과 비슷하다는 것입니다. 필자는  기회가 있을때 마다 개발자들의 글쓰기 역량을 강조하였고, popit 서비스를 만들고 운영하는 목적 중의 하나도 개발자들의 글쓰기에 도움을 주기 위해서 입니다.

• 글쓰는 개발자가 되자.

그러면 글쓰기와 프로그램 잘하는 것이 무슨 관계가 있을까요? 글을 쓴다는 의미는 자신의 생각을 남이 이해할 수 있도록 자신이 아는 언어로 표현을 하는 행위입니다. 말하기도 이런 행위 중의 하나이지만 기록으로 남긴다는 것에 말과 글은 차이가 있습니다. 프로그램을 만드는 행위도 이와 유사하지 않나요? C, Java, Go 와 같은 언어로 개발자가 생각했던 로직을 표현한 기록물을 프로그램이라고 볼 수 있습니다^[1]. 이런 관점에서 보면 좋은 프로그램을 잘 만들기 위해서는 대략 다음 두 가지가 필요합니다.

1. 문제 해결을 어떻게 할 것인가에 대한 생각 -> 설계
2. 생각한 내용을 잘 표현하는 쓰기 -> 코딩

"생각하기"를 잘하는 개발자 만든 코드가 이상한 것은 표현(글쓰기)을 잘 못하기 때문입니다. 표현을 잘하는 개발자가 만든 코드에서 문제가 많거나 쓸데 없이 복잡한 것은 생각(설계)를 잘 못한 것입니다. 두가지 다 못하는 경우도 있겠죠. 좋은 글쓰기도 이것과 다르지 않습니다. 쓰고자 하는 주제와 논조에 대한 생각에 대한 정리와 이것을 언어로 표현해 내는 능력이 조합되어야 좋은 글이 나옵니다.

좋은 프로그램을 만들 수 있는 방법이나 이를 익힐 수 있는 학습 방법은 많이 나와 있지 않거나 구체적이지 않지만 좋은 글쓰기를 하는 방법은 많이 있습니다. 프로그램을 글쓰기에 빗대어 보면 좋은 프로그램을 만드는 방법을 학습하는 것을 글쓰기 학습에서 빌어와 보면 어떨까 하는 것이 이글을 통해 필자가 주장하려는 내용입니다. 그리고 개발자가 글쓰기에 소홀해서는 안된다고 주장하는 이유 중의 하나이기도 하고요.

논리적 사고와 글쓰기

흔히 설계를 잘 하기 위해서는 앞절에서 설명한 소프트웨어 개발에 필요한 기본 지식이나 도메인 지식이 필요합니다. 하지만 이것이 전부는 아닙니다. 실제로 이런 지식을 가지고 있는 개발자가 만든 코드 중에 잘 만들지 못한 코드가 의외로 많이 있습니다.  필자는 1번 "생각하기"와 2번 "글쓰기"는 서로 상호 작용을 하고 있다고 봅니다. "글쓰기"를 잘하면 자연스럽게 "생각하기"를 잘하게 되거나, "생각하기"를 잘하면 "글쓰기"에 도움이 됩니다.

"생각하기"를 잘하기 위해서는 훈련이 필요한데 사람의 생각의 과정을 바꾸는 훈련은 무척 어렵습니다. 또한 방법도 많이 알려지지 않았고요. "글쓰기"는 생각하기를 배울 수 있는 가장 좋은 방법 중의 하나라고 할 수 있습니다. 여기서 말하는 글쓰기는 일반적인 글쓰기가 아닌 흔히 작문시간이나 논문을 쓰기 위한 글쓰기 방법입니다.  글은 많은 형태를 가지고 있습니다. 개인적인 소감이나 느낌을 전달하는 자유로운 산문이나 어느 정도 정해진 형태의 산문, 논문 형태의 리포트 등이 많은데 필자가 말하는 글쓰기는 서론, 본론, 결론이 갖춰진 형식있는 글을 의미합니다. 가장 좋은 것은 문제정의, 가설수립, 검증, 결론 등과 같은 논문이나 테크니컬 리포트 등이 가장 좋다고 생각합니다.

저도 최근에 들어서야 글쓰기에 대해 잠깐이나마 학습할 수 있었습니다. 영어를 배우는 중에 영작 과정을 들으면서 였는데 이 과정을 들으면서 프로그램 개발에 글쓰기가 도움이 된다는 데 대해 더 확신을 하게 되었습니다. 글을 쓰는 과정은 단순히 자기 생각을 표현하는 과정이 아니라 자기 생각을 정리하는 과정이 포함되어 있습니다. 예를 들어 서론에는 글의 주제에 대해 필자가 가지는 메인 아이디어에 대한 선언을 하고 본론에서 이를 뒷받침라는 여러개의 근거를 제시합니다. 각 근거에는 다시 이 근거를 뒷받침하는 Support Sentence 들이 몇개씩 붙게 되고요. 논문을 보면 더욱 뚜렷합니다. 문제를 정의하고, 이 문제를 해결하기 위한 가설을 세우고, 그 가설을 검증할 실험 환경의 구성, 실험, 실험 결과에 대한 분석 등이 글의 주요 내용이 됩니다.

선진국의 교육 과정을 보면 교육 과정 전반에 글쓰기를 강조하고 있습니다. 좋은 에세이를 쓰고 명문 대학에 진학하는 사례도 많이 볼 수 있습니다. 좋은 에세이를 쓸 수 있다는 것은 이런 능력을 갖추고 있다고 생각하기 때문이겠죠. 최근에 코딩 과정을 학교에서 가르치게 하는 것도 이런 이유때문이라고 봅니다. 글쓰기는 큰 범위에서 사고를 정리하는 관점이라면 코딩이라는 것이 논리적인 사고를 정리하는 관점으로 정확하게 정의할 수 있기 때문이죠. 왜 글쓰기를 배워야 하느냐? 라고 질문했을 때와 왜 코딩을 배워야 하느냐? 라고 질문했을 때 더 구체적인 설명이 가능하기 때문이겠죠. 즉, 과거에는 사고력을 높히는 방법으로 약간은 광범위한 글쓰기를 도구로 사용했다면 이제는 좀 더 구체적인 도구를 추가로 사용하려고 하는 것이 아닐까 추측해 봅니다.

이렇듯 형식을 잘 갖춘 글쓰기를 꾸준히 하면 자신의 생각을 잘 정리하는 능력이 자연스럽게 생기게 됩니다. 물론 반대일 수도 있습니다. 이미 논리적인 사고를 잘 할 수 있는 사람은 이런 과정이 글을 쓰는 동안 자연스럽게 나타나고 글로 표현됩니다. 이런 능력이 부족한 경우에는 꾸준한 글쓰기를 통해 이런 능력을 학습할 수 있게 됩니다. 필자의 경우도 추억의 네티앙 시절부터 개인 홈페이지를 운영하면서 꾸준히 글쓰기를 하고 있습니다. 이렇게 꾸준하게 글쓰는 것이 시스템을 설계하고 코드를 만드는데 많은 도움이 되고 있습니다.

프로그램 작성과 글쓰기

그럼 구체적으로 글쓰기의 기법을 프로그램 작성에 어떻게 도입을 할 수 있을까요? 필자가 글을 쓰는 과정을 보면 대략 다음과 같습니다.

• 글의 주제를 정하고
• 이 주제에 부합되는 사전 자료를 모으고
• 머리속에서 시나리오나 내용을 정리하고
• 초벌로 작성해보고
• 표현식이니 사용된 단어, 문장의 길이 등에 대해 교정을 하고
• 다른 사람에게 리뷰를 봐달라고 요청하고,
• 비로소 하나의 글이 완성된다.

프로그램 코드 작성도 이와 같은 흐름으로 전개되어야 합니다. 코드 작성과 비교해보면 다음과 같이 표현할 수 있습니다.

좋은 글이란 저자의 원래 의도가 독자들에게 잘 전달되어야 하고 읽기도 편해야 합니다. 제가 코드 리뷰를 볼때에도 이런 관점에서 코드 리뷰를 많이 봅니다.

코딩의 결과물은 쓰기의 결과물인 글과 같아야 한다.

코딩의 결과가 내가 만들고자 했던 것 (시나리오)을 말로 했을 때와 다르게 되어 있다면 코딩이 잘못되었거나 의도(시나리오 또는 설계)가 잘못되었다 것을 의미합니다. 코드 리뷰를 할때 필자가 잘 이해가 안되거나 잘못된 코드라는 생각이 들면 원작자에게 이 코드를 설명해달라고 요청합니다. 실제로 이런 상황에서 개발자의 설명과 실제 코드의 구현 내용이 다른 경우가 많았습니다. 생각은 제대로 했는데 이것을 코드로 만들어 낼때 다르게 표현하고 있는 경우가 많았습니다. 어떤 경우에는 끝까지 설명하지 못하는 경우도 있었습니다. 코드를 만들때 생각을 하고 만드는 것이 아니라 그냥 만들면서 생각하는 경우가 이런 경우입니다. 즉 구조를 잡지 않고 그냥 만들어 내는 것이죠. 이런 방식이 나쁘다는 것이 결코 아닙니다.  이렇게 만들어도 잘 만드는 개발자가 있습니다. 잘 만드는 개발자는 이미 머리속에서 정리가 되어 있기 때문이죠. 즉, 이런 사고를 잘 못하는 개발자는 생각을 하고, 그 후에 코드를 만들고, 생각대로 코드가 나와 있는지 확인을 하는 과정이 필요한 것입니다.

코드가 완성된 이후에도 완성된 코드의 형태를 생각하지 않는 개발자가 많이 있습니다. 글을 쓸때 문장의 구성 , 단어의 선택,마침표, 띄워쓰기 등에 신경을 쓰듯이 코딩할때에도 독자들이 이해하기 쉽도록 코딩 포맷, 변수명, 스페이스, 괄호의 위치 등을 아주 아주 신경을 써야 합니다. 이것은 코드의 품질과 관련된 내용인데 글쓰기를 할때에도 하나의 문단은 너무 많은 문장을 포함하지 않도록 가이드를 합니다. 이것은 독자들이 글을 읽을 때 좀 더 쉽게 읽게 하고, 문단의 분리를 통해 주제를 나눔으로써 글을 좀 더 구조적으로 만드는데 효과적이기 때문입니다. 프로그램에서도 긴 함수를 작성하는 것이 좋은 습관이 아니라고 말합니다. 같은 맥락이겠죠.

개발자는 코드가 다 만들어 졌다고 생각이 되면 글을 읽듯이 코드를 읽어가면서 자신의 생각과 일치하게 만들어 졌는지, 잘 읽혀지는지 등을 다시 한번 검토해보는 습관을 가져야 합니다. 자신이 쓴 글을 남에 보여주기 전에 하는 행위와 똑같이 말이죠.

중국에서도 이런 내용을 계속 강조해서 그런지 이글을 쓰고 있는 중에 팀원 중에 누군가가 다음 그림을 팀 채팅방에 공유하였습니다.

"Naming", "Explaining what I do" 이런 것들 역시 글쓰기 요소들이라고 봅니다. 이 그림을 올린 동료도 그런 생각을 하고 올린지는 모르겠지만 조금이나 제 글이 영향을 미쳤다고 생각합니다.

다른 사람의 코드를 읽어라!

마지막으로 좋은 프로그램을 만들기 위해서는 다음 사람이 만든 코드를 많이 읽어야 합니다. 이것 역시 앞에서 설명한 글쓰기와도 같은 맥락입니다. 글을 잘 쓰는 방법 중의 하나는 좋은 글을 많이 읽는 것입니다. 이것은 누구나 다 알고 있습니다. 좋은 코드를 만드는 방법 중의 하나 역시 다른 사람이 만든 코드를 많이 읽는 것입니다. 무턱대고 다른 사람의 코드를 읽기 보다는 다음 정도의 코드를 읽는 것을 제안해봅니다.

• 동료가 만든 코드 만든 코드의 의도와 목적이 무엇인지 잘 알고 있기 때문에 의도를 잘 반영하고 있는지 아닌지를 잘 파악할 수 있다. 즉, 잘 만들어진 코드인지 아닌지를 스스로 판단할 수 있고 이를 통해 자신이 만든 코드와 비교를 하면서 반성이나 배울 수 있다.
• 유명한 오픈 소스의 코드 반드시 그렇지는 않지만 유명한 오픈소스의 코드는 대부분 잘 만들어져 있다. 필자의 경우 Hadoop 소스 코드를 분석하면서 RPC의 구현, 파일 핸들링, 멀티쓰레드, 분산 환경에서의 처리 등 많은 부분을 배울 수 있었다. 여기서 배운 코드를 기반으로 현재까지 분산 환경에서 사용하는 코드를 작성할 수 있게 되었다. 동료의 코드를 통해 나의 수준과 동료의 수준을 비교할 수 있다면 오픈 소스의 코드를 통해 한단계 성숙할 수 있게 된다. 오픈 소스 코드 읽는 방법에 대한 글은 아니지만 필자의 글 오픈소스 코드 분석 어떻게 하나! 글을 도움을 줄 수도 있다.
• 내가 만든 옛날 코드 이 부분도 중요한데 과거 작성한 코드를 읽어 봤을 때 자신이 만든 코드이기 때문에 어떤 부분이 잘못되었는지 눈에 쉽게 띈다. 그 문제점을 다시 한번 확인함으로써 동일한 실수를 하지 않고 더 좋은 코드를 만들 수 있다.

글을 마치며

프로그램을 만드는 과정은 찰나에 지나가는 뇌의 정신적 활동과 이해 관계가 섞여 있는 많은 사람과의 관계를 통하게 됩니다. 이렇게 복잡한 과정을 거치는 프로그램을 잘 만들거나 배움에 있어 정답은 없을 것입니다. 필자가 이글에서 말한 글쓰기에 비유한 것도 한 방법이겠죠.  필자가 이 주제를 잡고 글을 쓰려고 마음먹었던 것도 어떻게 하면 추상적으로 설명하기 보다는 기존에 알고 있는 훈련 방법을 사용할 수 있을까를 생각하면서 선택한 것이 글쓰기 였기 때문입니다.

본문에서 밝혔듯이 필자도 최근에서야 작문에 대한 이론적인 내용을 간단하게 나마 맛볼수 있었습니다. 그것도 국문이 아닌 영작 시간을 통해서 입니다. 이 영작 시간에 배운 내용이 글쓰기에도 많은 도움이 되었고, 이 이론들이 코드를 만드는데에도 적용될 수 있다는 것을 알았습니다.

누구나 알 듯이 좋은 글을 쓰기 위해서는 단기간에 수련되지 않습니다. 프로그램을 잘 만드는 방법도 똑같습니다. 꾸준한 학습, 논리적인 사고력을 기르는 훈련, 실제 개발 경험 등을 지속적으로 할때만 가능합니다. 꾸준한 글쓰기도 이를 도와주는 도구 중의 하나입니다.

마지막으로 이 글의 영향을 받아 글쓰는 개발자들이 많이 나오기를 바랍니다.

추가

이글을 다 쓰고 이 주제와 관련있는 다른 글은 없는지 구글 검색을 해보았습니다. 예상하지 않았는데 저와 비슷한 생각을 하고 있는 글들이 여럿 보였습니다. 제 글을 읽고 흥미를 가지신 분이라면 구글 검색으로 다른 글들도 같이 보시면 도움이 되리라 생각합니다.

주석

[1]: 프로그램의 실행 관점에서 보면 그 뒤에 이야기가 많지만 이 글에서는 논외로 하였습니다.