야놀자 기술 블로그 만들기

Hello world!

저는 CX서비스실에서 기획을 담당하고 있는 강미경입니다. R&D 그룹의 기술 블로그, 그 영광의 첫 포스트로 개발의 보람을 대신할 수 있어 기쁩니다. 오늘은 ‘기획자가 어쩌다가’ 기술 블로그를 만들게 되었는지 얘기해보려고 합니다.

왜 기술 블로그인가

제가 야놀자에 입사한 지 만 1년이 되었습니다. 입사하면서 가진 개인적인 목표 중의 하나는 블로그를 운영하는 것이었습니다. 저는 오래전부터 개인 블로그를 운영하고 있고, 외부 커뮤니티 활동에서도 팀 블로그를 운영합니다. 그래서 개발자에게는 기술 블로그에 쓸 글을 작성하는 것보다 코딩을 하는 게 더 쉬울 정도로, 글 쓰는 고통이 남다르다는 것도 알고 있지요.

하지만 ‘알고 있다’고 생각하는 정보를 정리하고 그것이 잘 전달될 수 있도록 하는 것은 개발실력과는 약간은 다른 영역의 것이기도 합니다. 그래서 테크 스웩이 넘치는 블로그가 아니더라도, 꾸준히 스토리를 전달하면 그게 개인과 조직의 히스토리로써의 가치가 충분하다고 생각했습니다. 무엇보다 조직 자체의 성장에 큰 밑거름이 되고요.

블로그를 시작해보자

기술 블로그를 하자는 말에, 놀랍게도 한결같이 ‘관심만’ 주더군요(…) 평소 업무가 많고 바쁨을 떠나서, 보람보단 책임만 남아 유지보수 대상이 되어버릴 가능성이 무궁하지 않겠습니까. 하지만 목마른 사람이 우물을 파라고, 개발자의 도움 없이 블로그를 만들 각오를 하기에 이르렀습니다.(과거의 나를 규탄…🙊)

일단 검토를 시작했던 블로깅 방법은 Wordpress, Medium, Brunch 등입니다. 하지만, 계정관리 없이 할만한 건 없었습니다. 워드프레스는 호스팅할 서버와 도메인 설정, 복잡한 테마와 각종 플러그인까지 손대야 할 부분이 많아 빠르게 구축이 어려운 데다 어딘가가 터지면 비 개발자 혼자서는 해결하지 못하는 경우가 있습니다. 미디엄은 개인적인 취향(=한글폰트)때문이지만 왠지 모르게 정이 가지 않습니다. 브런치는 개인 계정을 만드는 과정부터가 심사를 거쳐야 하고, 그 또한 매거진필자를 관리해야하므로 관리 포인트가 늘어납디다.

그래서 결정한 것은 Github에서 지원하는 Jekyll 이었습니다. 개발팀이면 github 계정을 모두 갖고 있고, 입퇴사에 따른 멤버 관리도 되고 있기 때문이지요.

어렵진 않았나

Jekyll은 블로그를 하려는 개발자라면 한 번쯤 고려할법한 정적 사이트 엔진입니다. 깃헙 레포만 생성하면 되니, 설치에 어려울 이유는 없었고, 테마 오픈소스들이 많으니 적당한 걸 골라오면 됩니다.

1. 로컬 개발환경 만들기

처음에는 가볍게 보고 master 브랜치에 바로 푸시를 쏴댔지만, ‘아 이렇게 몇 군데 고쳐서 될 일이 아니구나’를 깨달은 건 그렇게 오래 걸리지 않았습니다. 정적페이지다 보니 엔진이 렌더링 해줄 때까지 기다려야 했고 auto save 수준으로 코드를 바꿨기 때문입니다. 그제야 로컬에 개발환경을 꾸려야겠다. 라고 생각이 들었습니다.

하지만 로컬환경을 구축할 때 크리티컬한 버전 호환성의 이슈가 있었고, 이로 인해 4시간 가까이 Ruby의 설치와 삭제를 반복하는 인고의 시간을 보내야 했습니다. 개발자 한 명 옆에 두고 시작하세요. 중요하니까 두 번 말합니다. 만약, 비 개발자라면 필요할 때 도움을 요청할 개발자 - 이왕이면 루비러를 꼭 섭외해두세요.

2. 소스트리 사용하기

종종 Sourcetree를 사용해본적은 있지만, 이렇게 본격적으로 사용해본 적은 사실 없었습니다. 적당한 테마를 주워 커스터마이징 몇 시간 하면 될 거라 생각했던 작업 기간은 정말 길어지고 있었고, 압축 폴더 업로드하는 느낌적 느낌으로 master에 푸시하던 것도 고쳐야 겠단 생각이 들었습니다.

이 역시 주변 개발자들에게 물어보며

  • 작업단위로 커밋은 어떻게 쪼개는지
  • 작성한 커밋메세지는 어떻게 수정하는지
  • 작업한 걸 롤백하고 이전에 커밋한 상태로 되돌릴 수 있는지
  • develop 브랜치는 어떻게 따고, merge는 어떻게 하는지
  • git flow는 어떻게 사용하는지

등등을 배웠습니다. 아무리 잘 배우고, 혼자 수정하는 코드에도 conflict는 생기더군요. 어떻게 풀어야 할지 한참 헤맸지만… 뭐, 저는 업자는 아니니까요. 프로젝트를 통째로 지우고 새 레포를 팠습니다.(응?)

3. 이슈로 작업 이력 남기기

저장의 문제인지, 로직이 꼬이는 문제인지는 모르겠지만, 똑같은 수정사항을 계속 반복 작업하는 경우도 생겼습니다. 머릿속으로만 작업하려니, 아무래도 작업 이력이 엉키기 때문이라고 생각했습니다.

깃헙의 이슈를 활용해 먼저 Todo task를 리스트업하고, 커밋할때 이슈 번호를 넣어 함께 제출했습니다. 그러면 이력도 관리되고, 일단 정리를 해놓고 시작하니 확실히 할 일이 명확해진다는 장점이 있네요. 제가 개발자들에게 종종 하는 잔소리인데, 막상 스스로에게 적용하려니 쉽지는 않았습니다. 그러니 좀 더 잔소리하기로..(결론이?)

4. 나와의 싸움에서 이기기

회사에서의 본업은 기획이고 주로 하는 일은 개발 스펙, 로직에 따른 예외정책, User Flow 등을 정의합니다. 하지만, 지금 이 순간에는 개발을 하고 있으므로 주어진 코드 안에서 기대하는 대로 동작하지 않는 기능을 몇 시간이고 붙잡게 되더랍니다.

한 3~4시간쯤 수차례 로직을 수정해보고도 되지 않자 (로컬에선 되는데, 마스터에 올리면 안 됩니다.. 흑흑..) 저는 아쉬움을 뒤로하고 스펙아웃 시켰습니다. 오랫동안 버그 수정을 위해 고생한 개발자에게 개발이 어려우면 기능을 없앨까?라는 말을 입에 달고 사는 저인데도, 스스로에게 굉장한 아쉬움으로 다가오더라고요. (앞으로 개발자와 이야기할 때 좀 더 친절해지기로 했습니다.)

아마도 다시 Jekyll 블로그를 구축할 미래의 저를 위하여 구체적인 lesson point는 개인 블로그에 다시 정리해볼 참입니다.

글을 마치며

블로그는 외부 노출이 거의 없는 내부 조직원들에게 굉장히 훌륭한 Showing box입니다. 누구나 존잘님이 되어 컨퍼런스 스피커로 나설 수는 없어요. (팩트) 내가 하는 일들이 흔한 일이고, 뻔한 일이고, 반복적인 일이어서 가치 없다 생각할 수 있습니다. 또 쓸만한 주제가 없거나, 있다 해도 유려한 글을 못 쓸 수도 있습니다. 그럼에도 불구하고 서로의 생각이나 경험을 공유하고 동료 개발자들에게 피드백을 받는 것은 색다른 성취감과 만족감을 줄 거라 생각합니다.

특히나 이렇게 Jekyll 로 블로그를 같이 운영하면, 모두가 조금 더 git과 친해지고, 성숙한 PR과 리뷰의 문화를 녹일 수 있을 겁니다. 바쁜 일정 속에서 타인의 생각을 비동기적으로 알 수 있을 거고, 새 글을 올리기 전에 pull 해야 할 테니 그 사이에 추가된 글들도 자연스레 읽을 수 있겠죠. 그리고 저와 같은 비 개발자들도 좀 더 개발자와 친해지는 계기도 되기도 하고요.

만약 블로그의 시작을 고민한다면, 왠지 다른 회사가 다 기술 블로그를 하니까 따라 하는 느낌이 들 수도 있는데요. (저도 고민했어요…🙈) 최소한 블로그에 경험을 누적함에 있어 ‘늦음’은 없습니다. 쓰지 않으면 ‘없음’이니까요.

앞으로 종종 업로드될 야놀자 기술 블로그의 글을 기대해주세요.

ps. 긴 글 읽어주셔서 감사합니다.

minieetea

R&D CX서비스실

야놀자의 모바일 PO를 맡고있습니다. 하는 일은 서비스기획(2) + 이슈매니징(3) + 삽질(5)로 구성되어 있습니다.