처음 기술 블로그라는 걸 알게 되었을 때 “이거, 나도 만들어야겠다.” 라는 생각이 들었다. 하지만 다른 개발자들도 그랬을 것 같은데 이는 절대 쉽지 않았다. 개발자가 블로그를 만드는 게 어렵냐고? 아니다. 만드는 거 자체야 당연히 어렵지 않다. 다들 알겠지만, 문제는.. 개발자는 글을 쓰는 것보다 코딩하는게 차라리 더 편하다는 것이다.
기술 블로그(Engineering Blog)란?
보통 기술 블로그는 IT 기업에서 운영하는 블로그를 말한다. “우리 회사에서는 이런 식으로 서비스를 개발하고 이런 기술력을 가지고 있으며, 이런 이슈와 부딪히고 고민하고 해결합니다.” 이러한 내용들의 포스트가 올라오는 블로그라 보면 된다. 하지만 반드시 기업에서만 기술 블로그를 운영할 수 있는 건 아니다. 개인 개발자가 운영하는 개발 관련 블로그도 기술 블로그라 불린다.
영어로는 Engineering Blog 또는 Tech Blog, Developer Blog라 불린다고 한다. 부르는 이름이야 다를 수 있겠지만 중요한 건 일반 블로그와는 명확히 그 특징이 구분된다는 점이다. 나는 일반적인 블로그는 일종의 정보 공유 글 모음 또는 개인의 일상을 기록해두는 일기장 정도라고 생각했다. 그런데 기업이나 개인의 기술력을 글로 정리해서 올려두는 블로그라니, “다른 경쟁자가 보면 어쩌지?” 라는 생각이 들었다.
하지만 기술 블로그는 그런 의도로 운영되는 게 아니었다. 기술의 자랑이라기보다는 일종의 토론장이었다. 서로서로 상대방이 쓴 블로그를 참조해가며 나아가 최종적으로 해당 분야의 발전으로 이어지는 맥락이었다. 누군가 잘못된 방법이나 비효율적인 방법을 사용하는 것을 발견했다면 다른 방법을 알려줄 수도 있고 반대로 내가 새로운 방법을 배워갈 수도 있다는 것이다. 구글링
또한 기업에서 이러한 내용의 블로그를 운영하고 있다면 새로운 인재 채용의 발돋움 대가 될 수도 있다. 당신이 이직을 앞두고 어떤 기업의 기술 블로그를 통해 최근 그 기업이 당신이 관심 있어 하는 분야의 프로젝트를 진행하고 있다는 내용의 글을 보았다. 그러면 그 기업으로 입사 지원을 해봐야겠다고 생각하게 될 수도 있지 않겠는가?
마찬가지로 만약 개인이 이런 기술 블로그를 운영하고 있다면 포트폴리오로써 활용될 수도 있다. 당신이 여태까지 매일 관심 가져 공부하고 개발했던 내용들을 하나씩 블로그에 올려두기만 해도 이것을 나중에 이력서 참고내역으로 제출할 수 있을 것이다. 반대로 어떤 기업의 채용 담당자가 당신이 쓴 블로그 글을 우연히 보고 면접을 보러 오지 않겠느냐고 연락이 올지도 모를 일이다. 📬
기업의 기술 블로그에 해당 기업의 모든 기술이 올라와 있을리는 없다. 게다가 어차피 나는, 올려둘 기술이랄 것도 없다..
블로그를 만드는 방법
인터넷을 접해온 세대부터는 각각 애용하는 포털 사이트가 있을 것이다. 그 중 누구나 한 번쯤은 들어봤을 네이버나 다음 같은 경우는 계정을 만들었을 때 블로그를 만들 수 있다. 이를테면 네이버 블로그, 티스토리 등이 있다. 이외에도 워드프레스Wordpress, 고스트Ghost, 벨로그Velog, 미디움Medium, 브런치Brunch 등 블로그를 만드는 다양한 방법이 있다고 한다.
현재 이 블로그가 만들어져 있는 플랫폼, 내가 선택한 방법은 바로 깃허브(GitHub)에서 제공하는 깃허브 페이지(GitHub Pages)라는 서비스였다. 이전 포스트 마지막에서 언급했던 포트폴리오에 기술 블로그와 깃허브를 이용하겠다는 부분, 깃허브 페이지를 이용해 기술 블로그를 만들게 되면 다른 방법을 이용하는 것보다 좀 더 이 부분과 많이 겹치게 되기 때문이었다. 깃, 깃허브, 깃허브 페이지. 자꾸 깃 깃 하는데 그럼 도대체 이 깃(Git)이란 건 무엇일까? 🤔
깃(Git)이란?
만약 당신이 A, B, C라는 3명의 개발자와 함께 네 명이 한 팀으로 메신저 앱을 개발한다 생각해보자. 팀은 또, 두 부서로 나뉘어 당신은 A와 함께 친구 목록 화면을 맡았고, 나머지 B, C 두 명은 다른 화면을 맡았다. 이제 당신은 친구 목록 화면에 필요한 기능들을 A와 적절히 나누어 맡아 따로 개발을 시작했는데, 중간중간 기능들을 합쳐서 화면이 잘 나오고 있는지 테스트해야 했다. 이때 당신은 같은 부서원 A에게 당신이 만든 기능 부분을 어떤식으로 공유할 것인가? 내가 짠 코드 카톡으로 보내기!?
또 다른 예로, 당신은 어떠한 기능을 하는 한 파일을 A와 함께 작업해야 하는 상황이 있을 수도 있다. 한 파일 내에서 번갈아가며 기능을 구현해내야 하는 상황이라는 것인데, 어떻게 매번 소스코드를 토스할 것인가? “제가 137번째 줄부터 184번째 줄까지 작성해뒀어요. 이제 A님이 185번째 줄부터 짜시면 되요!” 라고 전달할 것인가? 아니면 그냥 마지막에 하나로 합치는 방법을 선택한다 해도 그럼 어떻게 그 내용을 일일히 비교해서 합칠 것인가? 🫢
마지막 예로, 최종 단계인 배포를 앞두고 나뉘었던 두 부서의 화면들을 모두 합쳐 메신저 앱을 완성해야 한다. 그러면 또 네 명이 한데 모여 퍼즐 맞추듯 코드 조각들을 맞추고 있어야 할까? 이쯤되면 그냥 누군가 일정한 때마다 알아서 수정된 사항들을 정리해주고 차곡차곡 소스코드를 쌓아줬으면 한다는 생각이 들게 될 것이다. 깃은 바로 이런 상황들에 유용하게 쓰일 수 있는 시스템이다. 여러명의 개발자들이 하나의 프로젝트를 개발해낼 때, 협업이 필요한 때, 깃은 빛을 발하게 된다.
깃과 같은 시스템을 ‘분산 버전 관리 시스템 : 알아서 파일의 변경 사항을 추적해주고 여러 명의 사용자 간에 작업 순서나 그 내역을 조율해주는 시스템’ 이라 부르며, 깃은 그 중 한 종류이다. 이름 그대로 깃을 활용해 파일의 버전을 쉽게 관리할 수 있다. 새로운 업데이트가 생길때 마다 새 파일을 만들 필요 없이 버전을 붙여주며 갱신할 수 있는 것이고 그렇기에 예전의 버전으로도 언제든 쉽게 돌아갈 수 있다.
안녕하십니까? 신입 개발자 입니다. 네? 깃을 안 쓴다고요?.. 😨
안녕히계세요.
깃허브(GitHub)란?
깃을 이용해 버전 관리를 하게 되면 그 내역들이 쌓일 저장소가 필요하다. 매번 변경사항이 담긴 문서가 나올 때 그 문서들을 정리해둘 수 있는 문서함 같은 공간 말이다. 그리고 우리는 이 저장소를 이미 가지고 있다. 바로 당장 쓰고 있는 컴퓨터 즉, 로컬 환경이다. 문제는 팀 프로젝트로써 협업이 필요할 때에는 개개인의 로컬 저장소가 아닌 온라인으로 공유되는 저장소가 필요할 것이다. 우리는 이를 리모트 저장소 즉, 원격 저장소라 부른다. 깃허브는 바로 이 원격 저장소를 제공해주는 웹 호스팅 서비스1인 것이다.
심지어 깃허브는 이러한 서비스를 무상💸으로 제공해준다. 당신이 당신의 프로젝트를 오픈소스2로써 깃허브에 올려둔다면 말이다. 그렇기에 깃허브는 오픈소스들의 바다, 또 웹 서비스인 만큼 편리한 UI와 커뮤니케이션 기능이 잘 되어 있기 때문에 개발자들의 SNS라고도 불린다. 다른 사람들이 만든 코드를 도서관에서 책을 빌려 보듯 언제든 참고할 수 있고, 또 이를 내 로컬 저장소에 가져와 그 프로젝트에 팀원으로서 참여해 기여할 수도 있으며, 내가 올린 코드들을 다른 사람들이 보고 의견을 달아줄 수도 있다.
다시말해 깃과 깃허브를 이용한다면 장소와 장비에 제한 받지 않고 언제 어디서든 개발을 이어나갈 수 있다는 것이다. 그렇기 때문에 당신은 당신이 만든 모든 프로젝트를 자연스럽게 깃허브에 업로드 해둘 것이다. 그렇다면 우리는 이런 생각이 들지도 모른다. "이거 이력서가 따로 필요 없겠는걸?" 그렇다. 요즘은 기업에서 단순히 깃허브 프로필 주소만을 요구할 때도 있다. 우리는 URL 주소 하나만으로 우리를 어필 할 수 있게 된 것이다.
깃허브 페이지(GitHub Pages)란?
내가 만든 프로젝트와 그 소스코드들은 모두 깃허브에 업로드해두고 그에 따른 자세한 설명이나 내 생각은 기술 블로그에 기록해둔다. 이게 바로 내가 생각해둔 포트폴리오 준비 계획이다. 그렇다면 블로그를 만드는 다양한 방법 중에서 내가 깃허브 페이지를 선택한 이유는 무엇일까. 먼저 위에서 얘기했듯 깃허브에서 제공하는 서비스이기에 자연스럽게 깃허브의 사용 빈도가 많아질테고 다른 기능들도 활용해보게 될거기 때문이다.
또 가장 큰 이유는 바로 깃허브 페이지가 역시 무상이기 때문 개발자가 사용하기에 편리하기 때문이다. 깃허브 페이지 홈페이지에 들어가 보면 하단 부분에 Jekyll이라는 것을 이용해보라고 나와 있다. 제키라고 읽는지 제킬이라고 읽는지 모르겠는데 아무튼, 제키는 Ruby를 기반으로 만들어진 정적 사이트 생성기로써 지금 내 블로그에도 사용되었다. 자세한 기술적인 내용은 앞으로 블로그 만들기, 커스터마이징 과정 포스트에서 이어서 다루어보려 한다.
아무튼 어느 정도의 개발 지식만 알고 있다면 손쉽게 블로그를 만들어 낼 수 있고 여러 가지 테마를 개발자 측면에서 편리하게 수정하고 관리할 수 있다는 장점이 있다. .io 도메인과 같은 유료 도메인을 무료로 제공해주기도 하며 자동으로 https를 지원해준다. 물론 반대로 개발 지식이 부족한 일반인의 경우라면 오히려 이런 부분들은 단점이 될 수도 있다. 그 예로 포스트를 작성하는데에도 기본적인 별도의 세팅 환경이 갖추어져 있어야 한다.
앞으로
이번 포스트에서는 기술 블로그와 깃허브뿐만 아니라 다양한 용어가 많이 튀어나왔던 것 같다. 그래서 앞으로도 포스트를 쓸 때 누군가 내 블로그를 보고 도움이 될 수 있게 끔, 오늘 썼던 방법처럼 설명하는 듯한 내용으로 작성해보려 한다. 물론 이 내용들은 내 지식을 정리해서 올려두는 용도이기도 하다. 🙏🏻
이제부터는 내가 맥(Mac)을 사용하게 된 계기와 다 까먹어 버렸던 깃을 복습했던 과정, 또 위에서 미쳐 다 다루지 못했던 깃허브 페이지를 이용해 블로그를 완성하고 커스터마이징까지 끝냈던 과정까지 모두 상세히 담아보려 한다. 그 이후에도 T.I.LToday I learned, 토이 프로젝트Toy Project 등 욕심이 많다보니 해야할게 산더미라.. 앞으로 더 열심히 해야할 것 같다.