readable_code::CMake - Fancy하게 C++ Project 만들기

readable_code

cpp::build_system::modular_project_with_cmake - OS/Platform 종속성 없이 fancy하게 C++ project 만들기

C++ 프로젝트 생성에 필수적인 CMake에 대해서 배워요!

• CMake는 어렵지요?

• 하지만 이 강의에서는 어떤 프로젝트 구성에도 사용이 가능한 CMake template을 알려드립니다.

• 10년 넘게 CMake로 쌩 고생하며 알게된 엑기스 전부 알려드립니다!

이런 내용을 배워요

CMake의 기초 문법

• CMake를 보다 잘 활용할 수 있게 해주는 기초 문법을 알려드려요.

• 변수, 메시지, 함수, 제어문 등 CMake 기초 문법을 통해 프로그래밍 언어처럼 사용해보아요!

Modern CMake의 문법

• C → C++로 프로그래밍 패러다임이 바뀐 것처럼 이젠 모던 CMake가 대세랍니다!

• CMake를 통해 라이브러리와 실행 파일을 만들 때, 예전 방법을 쓰지 않도록 해요.

CMake를 사용한 외부 종속성 관리

• 아직도 외부 종속성을 PC에 설치해서 관리하세요?

• CMake 프로젝트와 외부 종속성을 통합해서 관리해보아요.

• 이젠 프로젝트를 빌드하기 위해 별도 라이브러리 설치과정을 없앨 수 있습니다!

CMake를 사용한 재사용 가능한 C++ project 구축

• 10년 넘는 개발 경력의 정수를 담았습니다.

• 최소한의 수정으로 최대한의 효율을 뽑을 수 있는 CMake 구조를 전달해드립니다.

• 이런 프로젝트 구조는 어디서도 본 적 없으실 걸요?!

무엇을 얻을 수 있을까요?

• 프로그래밍 언어처럼 CMake를 사용할 수 있는 능력

• CMake를 사용한 C++ project 구축의 best practice

  • CMake를 외부 종속성 관리

  • CMake를 사용한 개발 프로세스 자동화

  • CMake를 사용한 재사용 가능한 구조화된 C++ project 구축

Keywords

• Build System

• CMake

• Morden CMake

• Project Architecture

• Modular System

• Thirdparty library

수강 전 참고 사항

readable_code

왜 readable_code 일까요?

대학원 연구실에 처음 들어가서 구현되어 있는 소스 코드를 보며 들었던 자괴감이 아직도 기억납니다. ‘아… 왜 아무리 봐도 이해가 안되지?’ 그 당시에는 제가 부족해서 그런 줄 알았습니다. 그 때부터 10년이 넘는 시간이 지났습니다. 이제야 알게 됐습니다. 내가 문제가 아니라 코드가 문제였구나.

많은 개발자들이 코드라는 이름의 암호를 작성하며 ‘일단 돌아가야 해!’라고 외치고 있습니다. 하지만 그 코드들은 머지않아 옥죄는 목줄이 되어 나에게로 돌아옵니다. 빠른 구현을 위해 컨벤션을 맞추지 않고 구현한 코드와 남발한 주석은 코드를 읽는데 혼란을 야기하고, 큰 생각 없이 만들어 놓은 인터페이스는 나중에는 어떤 데이터를 주고 받기 위함인지조차 희미해집니다. 이렇게 짜여진 코드들은 시간이 지남에 따라 잘못된 결과 값이 발산하는 것처럼 아무도 읽을 수 없는 코드가 되어갑니다. 심지어는 그 코드를 작성한 본인도 코드를 보지 않고 일주일 지나면 그 암호를 디버깅이라는 코드북을 펴놓고 해석해야만 합니다.

우리는 소스 코드를 언어라고 부릅니다. 언어는 어떤 존재와 대화하기 위해 존재하는 것입니다. 여기서 많은 사람들은 그 어떤 존재를 컴퓨터라고 생각합니다. 이 착각으로 부터 야기되는 코드라고 부르는 많은 암호들이 생겨나는 것이겠죠.(코드의 뜻이 암호라는 것이 재미있지 않나요?)

하지만 앞서 이야기한 대로, 코드는 컴퓨터가 읽는 것이 아니라, 우리가 읽는 것입니다. 그렇기에 소스 코드를 작성하는 것은 글짓기와도 같습니다. 그 중에서도 기술 문서를 작성하는 것과 비슷합니다. 간결하고 명확하게 사람이 이해할 수 있게 코드를 작성해야 하는 것이죠. 이렇게 작성된 코드는 언제 누가 보아도 편하게 읽고 이해할 수 있습니다. 불행하게도 제가 겪어온 현업에서는 그런 사소하고 자잘한 것을 고려해서 구현할 시간이 없다고 합니다. 하지만 제가 느낀 것은 ‘시간이 없어서 못하는 것’이 아닌 ‘할 수 없어서 못하는 것’이였습니다.

사람이 읽기에 좋은 코드(readable_code)는 대부분의 경우 컴퓨터가 읽기에도 좋습니다. 불필요한 변수, 함수, 변환 및 프로세스를 구현하지 않기 때문이죠. 또한 이것은 협업과 코드 유지 관리의 퍼포먼스를 비약적으로 상승시켜 줍니다. 실제적으로 저는 제가 있던 회사에서 기존의 프레임워크를 버리고 새로운 프레임워크를 설계하여 구현하였고, 기존 프레임워크에서 2주가 걸려서도 진행하기 어려웠던 코드 통합작업을 3일만에 가능하게 단축시켰습니다. 또한 기존 프레임워크에서 3달정도 걸렸을 모듈 구현이 1달도 안 걸리는 시간에 가능하게 되었죠. 이렇게 사람이 읽기에 좋은 코드는 구현을 못해서 문제인 것이지, 할 수만 있다면 안할 이유가 없는, 말도 안되게 개발 효율을 향상시킬 수 있는 놀라운 것이죠.

아직까지는 성숙한 개발 문화와 협업, 사람이 읽기에 좋은 코드는 많은 경우 있으면 좋은 것, 없어도 큰 상관 없는 것 정도로 치부되는 경우가 많은 것 같습니다. 하지만 저는 사람이 읽기에 좋은 코드의 능력을 보았고 그것의 실제를 경험했습니다. 제가 이것을 지엽적으로 제가 있는 회사와 팀에 적용할 수도 있겠지만, 저는 그 정도로 만족하고 싶지 않습니다. 한국의 SW 생산성 자체를 키우고 싶습니다. 엔지니어 분들이 더 좋은 환경에서 개발을 하기를 원합니다. 좋은 개발 문화가 한국의 회사들 안에 자리잡기를 원합니다.

저는 이제부터 제가 가졌던 경험, 성공과 실패, 그 과정을 통해 알게 된 모든 노하우들을 여러분과 함께 나누려고 합니다. 이것들은 매우 소중한 것이며, 여러분께서 갈 그 길에 탄탄한 기반이 되어줄 것입니다. 함께 하시겠습니까?(y/n) …-y