프로젝트가 장난이야?!

안녕하세요. 저는 배달의 민족 주문시스템을 개발하고 있는 권용근입니다.

(출처 : 타요장난감 타요학교와 꼬마버스타요 버스 친구들:지호토이TV)

저는 개발자의 개인 장난(감)인 프로젝트인 토이 프로젝트에 대해서 이야기해보려고 합니다. 저는 웹 개발 입문과 거의 동시에 토이 프로젝트를 시작했고 이 프로젝트들을 통해 많은 성장을 이루었다고 생각하고 있습니다. 그래서 토이 프로젝트를 통해 무엇을 얻을 수 있었는지에 대하여 말해보려고 합니다.

(우아한 Tech : 김영한 팀장님의 카드 뉴스 중..)

토이 프로젝트란?

토이 프로젝트가 무엇일까요? 크고 간단하게 2가지로 나눈다면 이렇습니다.

1. 여유시간만 투자한다.

본업과 건강에 영향을 미치지 않는 선에서 여유시간을 투자해야합니다.

2. 어떠한 목적을 달성한다.

기능, 스펙, 규모, 일정에 대한 제약은 있을 수도 있고 없을 수도 있습니다. 런칭 혹은 배포도 마찬가지입니다. 프로젝트가 반드시 런칭되거나 배포될 필요는 없습니다. 이것은 내가(혹은 우리가) 프로젝트의 목적을 무엇으로 정하냐 에 따라 달라지게 됩니다.

여유시간을 투자하여, 어떠한 목적을 달성하는 개발 프로젝트가 토이 프로젝트 인 것 입니다. 샘플 프로젝트, 기능을 제공하는 라이브러리 프로젝트, 서비스를 제공하는 웹,앱 프로젝트 등등 무엇이든지 나올 수 있지요!

나의 토이 프로젝트

많은 토이 프로젝트를 진행했었지만, 그 중 대표적으로 챗봇 프로젝트, 코딩덕후 프로젝트 라는 2가지 저의 토이 프로젝트를 중심으로 이야기해보려 합니다. 그래서 일단 간단히 2가지 프로젝트를 소개하겠습니다.

챗봇 프로젝트

저의 웹 개발 시작과 거의 거의 비슷한 시기에 시작했던 첫 토이 프로젝트 입니다. 저의 첫 회사에서 꽤 많은 구성원들이 사용해주었던 대화형(ARS형) 챗봇이였습니다. 나중에는 핵심 코어 기능만 분리하여 프레임워크화 하여 Boot Starter Pack으로 제공하였고, 슬랙, 텔레그램, 라인 등과도 연동하였습니다. 회의실 현황, 예약, 사다리, 심심이, 섣다 기능 등 온갖 잡 기능을 하나씩 추가해나갔던 장난감이였습니다.

Github Link : kingbbode/spring-boot-chatbot

코딩덕후 프로젝트

개발자들의 Github 활동을 장려하고자 Github 활동을 시각화해주는 서비스 프로젝트 로 2018년 11월부터 정식 시즌을 오픈하여 진행 중인 프로젝트입니다. 3명의 구성원들과 함께 진행하고 있는 첫 팀 프로젝트이고, PM 역할을 맡아본 첫 프로젝트 입니다.

Site Link : co-duck.com

위 두 가지 프로젝트를 진행하며 경험할 수 있었던 것, 얻을 수 있었던 것에 대한 이야기를 시작해보겠습니다.

토이 프로젝트로 경험할 수 있었던 것 & 얻을 수 있었던 것

1. 기술에 대한 접근 기회

회사에서 만들게 되는 서비스는 안정성을 추구합니다. 그래서 직접 만들기보다는 잘 만들어진, 충분히 검증된 프레임워크, 라이브러리를 선택하고 조합하여 사용을 합니다. 때문에 본인이 직접 라이브러리와 프레임워크를 구현하는 경험을 가지기는 쉽지가 않습니다.

토이 프로젝트는 무엇이든 목적이 될 수 있고, 무엇이든 해도 되는 프로젝트이기 때문에 저 스스로에게 많은 기회를 만들어줄 수 있었습니다.

기회 #1 프레임워크 만들어보기

처음부터 프레임워크를 만들기로 했던 것은 아니였습니다. 챗봇 프로젝트를 진행하면서, 챗봇 개발에 대한 진입을 낮추어주자는 목적을 달성하기 위해 프레임워크 처럼 만들어보자는 결론이 나온 것이지요.

어떻게 하면 스프링과 같이 쉽게 기능을 작성하도록 할까에서 시작되어, 스프링의 어노테이션 기반의 메타 프로그래밍 방식을 사용하게 되었습니다.

@Brain
public class FirstBrain {

    @BrainCell(key = "따라해봐", function = "echo-start")
    public String echo(BrainRequest brainRequest) {
        return  "말해봐";
    }

    @BrainCell(function = "echo-end", parent = "echo-start")
    public String echo2(BrainRequest brainRequest) {
        return  brainRequest.getContent();
    }
}

이런 식으로 말이죠. 이를 가능하게 하기 위해, Java Relfection API 를 알아야 했고, 동적으로 생성된 챗봇을 위한 Bean 을 관리하기 위해 Spring BeanFactory Container 와 닮은 BrainFactory도 만들게 되었습니다. (물론 완성된 구현물이 Spring Framework 에는 훨씬 못미치지만.. )

서비스를 개발할 때 사용하거나 경험해보지 못할 기술과 방법들을 직접 사용해볼 수 있었고, 이런 기술들을 사용하여 만들어진 스프링 프레임워크의 전체를 부지런하게 까보기 시작했고, 이해하기 위해 노력을 했습니다. 이를 통해 내가 사용하고 있는 프레임워크가 내부적으로 대략 어떻게 돌아가는지를 조금은 이해할 수 있게 된 큰 계기가 되었습니다.

기회 #2 Spring Boot Starter 만들어보기

마찬가지로 만들어진 기능을 쉽게 제공하기 위한 고민을 하다가, Spring Boot 의 Starter Pack 을 만들어보기로 했습니다.

이 때가 약 3년 전으로 국내에서 아직 스프링 부트의 대한 오해들이 만연하던 시기이기도 하였습니다. 물론 당시 신입이였던 저는 그런 것은 모르고, 제가 사용하는 프레임워크를 이해하기 위해 노력을 하고 있던 시기이기도 합니다.

한글 문서가 거의 없던 당시에 공식 문서를 나름 열심히 파고, 소스를 직접 하나씩 모두 들여다보았던 삽질의 기억들이 납니다.

그래서 단일 모듈의 프로젝트에서

이런 구조의(중간 버전의 레파지토리가 삭제되어 현재 구조로 대체) 멀티 모듈 프로젝트로 탄생되었죠!

이 때 부트에 대해서 정말 많은 이해를 할 수 있었고,

덕분에 2017 Spring Camp 에서 연사로 발표도 할 수 있었습니다.

2. 새로운 관심사

신기술이나 이전에 사용해본 적 없는 기술을 운영중인 서비스에 바로 적용할 수 있을까요?

기술이 이미 충분히 검증되었고, 스스로 문제가 발생했을 때 빠르게 해결할 수 있을만큼 기술에 대하여 내가 성숙되었다면 고민을 해보겠지만, 그 이전에는 절대 반대를 할 것 같습니다.

그럼 토이 프로젝트로 사용을 해본 후에 서비스에 적용을 하면 될까요?

내 토이 프로젝트가 회사 이상의 대규모 트래픽을 받고 있으며, 회사보다 복잡한 비즈니스적 요구사항을 가지고 있다면 고민을 해보겠지만, 그 이전에는 절대 반대를 할 것 같습니다.

"새로운 기술, 새로운 모델을 쓰는건 현재 환경에선 더이상 문제를 해결할 수 없다고 느낄때만 엄청 엄청 부담감을 느끼면서 적용한다."
by jojoldu

그럼에도 저는 토이 프로젝트에서 꼭 새로운 관심사를 사용해보시길 강력하게 추천드립니다. 저는 호기심을 잃은 개발자는 성장할 수 없다고 강하게 믿고 있습니다. 현재 내 업무에서 사용하지 않는 것과 내가 가진 기술에 대한 호기심은 전혀 무관합니다. 어떠한 기술로 무언가를 해결해본 경험은 언젠가 반드시 도움이 될 것 입니다.

도움이 되었던 사례 #1 REDIS 활용

챗봇 프로젝트는 처음에 1 DEPTH 를 가지는 매우 단순한 챗봇이였습니다. 공백 split 을 사용하여 명령어 뒤의 기능을 수행하도록 하였습니다.

#투표 짬뽕 -> 짬뽕을 투표한다

챗봇으로 만드려는 기능이 점점 많아짐에 따라 명령어가 점점 난해해지기 시작했습니다.

#연차 사용 반차 2018-11-04 오전 -> 2018년 11월 4일 오전반차를 사용한다.

그래서 Redis 를 활용하여 챗봇 대화의 짧은 Expire 의 세션을 만들었고, 그 세션의 존재에 따라 현재 해당 유저가 대화 중인 상태인지 아닌지를 판단하는 기능을 만들어 대화 방식의 채팅 방식을 만들었습니다.

이때 제가 하고 있는 서비스에는 Redis 비슷한 것도 사용하지 않았던 시기였습니다.

그러나 경험은 개인의 만족으로 끝나지 않았습니다. 현재 배달의 민족의 비동기 결제 시스템을 적용할 당시 주문시스템의 사용자 경험과 관련된 결제 완료를 확인하는 부분에서 이 방식을 제안했고, 이 기능은 현재도 잘 쓰고있는 기능이 되었습니다.

2년 뒤 다른 업무에서 이 기능을 사용하게 될거라곤 생각도 못했습니다. 그러나 이렇게 저의 본업에도 도움이 경험이 되었습니다.

도움이 되었던 사례 #2 ADMIN 뚝딱

현재는 서버개발자를 담당하고 있지만, 이전 회사에서는 프론트와 서버를 모두 개발하던 개발자였습니다. 서버는 서버대로 재미가 있고, 프론트는 프론트대로 재미가 있었지만 과감히 서버개발자의 길을 선택하였고 프론트엔드는 완전한 취미가 되었습니다.

담당 업무에서 프론트엔드가 완전히 없어진 후 VueJs 라는 기술이 화제가 되고 있었습니다. 개발자의 호기심은 무죄입니다. 그래서 당시 진행 중이던 토이 프로젝트 코딩덕후 프로젝트 의 프론트엔드를 VueJs로 만들기로 했고 VueJs를 신나게 공부했었습니다.

이 때도 마찬가지로 제 업무에 프론트엔드는 완전히 없을 줄 알았습니다.

백오피스 필요없는 시스템은 역시 없는 것이였을까요? 결국 백오피스에 대한 요구사항이 생기게 되었고, 프론트엔드 경험이 있는 제가 만들게 되었습니다.

총 2개의 어드민을 만들었는데, 기존 다른 프레임워크와 호환되는 css만 사용하여 템플릿 라이브러리를 사용하지 않고 만든 ADMIN은 2주 가 걸렸고, Vuejs 어드민 템플릿 라이브러리를 사용하여 만든 현재의 주문시스템 ADMIN은 2일 만에 만들 수 있었습니다.

(위 그래프는 실제 지표와 아무런 관련이 없음)

당시 바쁜 일정 중 주문시스템 ADMIN이 생각 이상으로 빨리 만들어져 저희 팀의 관리자(팀장님)가 신나했던 기억이 납니다.

결국 서비스와 상관없이 진행했던 토이 프로젝트가 또 다시 저의 본업에 도움이 되었습니다.

3. 풀사이클 개발(Design-Develop-Test-Deploy-Operate-Support)

요즘 많은 곳에서 업무의 세분화로 알지 않아도 괜찮은 것 같은 영역들이 생기고 있습니다. 그 대표적인 예가 서버 개발 직군과 인프라 직군이 아닐까 생각됩니다. 서버 개발자가 정말 인프라에 대해서 몰라도 되는 것일까요?

저는 우아한형제들에 입사한 후 나와 같은 서버 개발자이지만, 인프라 괴물들을 몇 명 만났습니다.

이분들을 보며 확실히 느낀 것은, 내가 인프라를 직접 하지 않게 되더라도, 반드시 알아야 한다는 것 입니다. 인프라를 알고 모르고에 따라서 설계부터 개발, 운영(문제 해결)에 대한 모든 것이 차이가 난다는 것을 알았기 때문입니다. 넷플릭스의 풀사이클 개발자 블로깅에서도 이런 말을 합니다.

Operating What You Build(당신이 구축한 것을 운영하라)!!

그러나 현재 국내 개발자들이 풀사이클 개발을 회사에서 경험하긴 쉽지 않습니다. 그렇다면 어디서 경험할 수 있을까요?! 바로 토이 프로젝트입니다!

코덕 프로젝트는 아키텍처부터 인프라까지 모두 직접 설계하고 구축하여 서비스되고 있는 저의 첫 토이 프로젝트입니다. “나 혼자서 하나의 서비스를 처음부터 끝까지 만들 수 있을까?” 라는 궁금증이 항상 있었습니다. 그러던 중 정말 만들어보고 싶은 서비스가 생겼고, 망설임 없이 시작을 하였던 것 같습니다. 토이 프로젝트를 시작한다는 것은 저에게 너무 당연한 일이 되었고, 토이 프로젝트는 정말 토이 프로젝트일 뿐이였기 때문입니다.

코덕 프로젝트

사실 하나의 프로젝트로 만들 수 있었지만, 멀티 프로젝트로 쪼개어 설계를 해보았습니다. 당연히 이런 소규모의 서비스라면 하나의 프로젝트로 만드는 것이 좋은 결정이겠지만, 제가 경험하고 싶었던 것은 분산환경이였습니다. 토이 프로젝트에서 나의 목적을 달성하는데에는 전혀 오버스팩이 아닌 아주 적합한 스팩이 되는 것 입니다.

그래서 해보고 싶던 디자인, TDD, 개발 스타일, 브랜치 전략, 이슈 관리, 배포 방식 등을 모두 해볼 수 있었고, 많은 시행 착오를 통해 더 많은 경험치를 쌓을 수 있었습니다.

그래서 완성된 구조는 아래와 같습니다.

저만의 멋진 구조를 완성시키고 싶었는데, 이 모든 것이 돈 이라는 것을 알게 되었습니다. 회사에서 사용하고 있던 당연한 것들을 적용해보려 하였고, AWS 견적 계산기로 대충 계산을 해보았더니…

(우아한형제들은 빵빵한 AWS 스팩을 제공합니다!)

그래서 비용 최소화 모델로 집에서 잠자고 있던 라즈베리파이까지 동원되어 완성된 구조입니다. 서버에 대한 설정부터 데이터베이스 설치까지 모든 것을 직접 해볼 수 있었던 좋은 경험이 되었습니다. 그 과정에서 호돌맨님의 영상(서버 기본 설정, MariaDB 설치)과 알구몬(algumon.com)의 경험을 담은 깨알팁이 정말 많은 도움이 되었습니다.

인프라 괴물님들 다시 한번 감사합니다.

아쉬운 점이 당연히 많습니다. 비용 문제로 AWS 에서 경험해보고 싶은 많은 것들을 아직 사용해보지 못한 것 때문입니다. 그렇지만! 저의 프로젝트는 진행형입니다! (정식 오픈한지 1달도 안된..) 앞으로 트래픽이 (제발) 늘어준다면 분명 더 좋은 경험들을 할 수 있으리라 확신합니다.

Site Link : co-duck.com

많이 이용해주세요 !!

4. 관리자를 이해

저같은 주니어가 어디가서 PM 역할을 해보겠나요? 토이 프로젝트이기에 가능합니다! 소제목으로 관리자를 이해 라고 해놓았지만 사실 관리자는 아직 저에게는 이해할 수 없는 영역입니다. 그럼에도 프로젝트를 진행하면서 느낄 수 있었던 관리자의 일부 모습의 이해 를 이야기 해보려고 합니다!

저는 코덕 프로젝트를 만들기 위해, 3명의 개발자를 합류시켰습니다. 저는 꼭 만들고 싶었던 뚜렷한 프로젝트의 방향과, 취지가 있었기에 프로젝트를 시작하였고, 지인들은 개발 경험이 필요하여 합류한 것 입니다.

전체 설계가 끝나고 구현을 시작할 때까지는 모든 것이 순조로웠습니다. 구현해야할 내용을 작게 나누어 TODO 를 작성하였고, 그것을 구성원들에게 뿌리고 구현이 시작되면서 이상한 것들이 나타나기 시작했습니다!

내가 의도한 바와, 실제 구현이 미묘하게 다른 방향으로 흘러가고 있었습니다. 그러던 중 충격적인 말!

이런 기능을 만들어야하니까 만들고 있는데, 사실 이 기능을 왜 만드는지, 만들어서 뭘 하겠다는 건지 전혀 모르겠다.

그때서야 무엇이 잘못되었는지를 알았습니다. “내가 생각하는게 대충 이런거다” 라며 합류를 시켰고, “내가 생각하는게 있으니까, 일단 해놔봐”, “대충 이런건데, 나중에 설명해줄게” 같은 말들을 했던 순간이 스쳐갔습니다. 구성원들이 서비스를 전혀 이해하지 못하고 있던 것 입니다.

그 후 정밀한 PPT 를 만들어, 2시간에 걸쳐서 구성원들에게 프로젝트를 설명을 하였고 그제서야 많은 오해들이 풀리게 되었습니다.

(하지만 그래도 다 이해하진 못하더라는…)

그리고 우아한형제들 을 다시 생각하였습니다. 매월 진행되는 타운홀 행사, 그리고 최근 조직개편 이후에도 회사의 방향에 대하여 자세히 설명해주셨던 부문장님, 실장님, 팀장님을 떠올렸습니다.

(찍어둔게 없어서 합성을.. 실제론 꽉꽉 찹니다)

내가 현재 우리 회사의 방향을 알고 있고 이해하고 있다는 점, 고작 3명에게 설명하기도 벅찼었던 나의 모습을 떠올렸을 때야 관리자분들의 그런 모습들을 이해할 수 있었고, 감사하다고 생각이 들었습니다.

추가로..

그리고 구성원들을 쪼고 있는 내 모습에 팀장님도 사알짝 이해할 수 있었… (갈갈갈)

마무리

토이 프로젝트는 이렇 듯 저에게 정말 많은 경험을 선물해주고 있습니다. 개발자는 토이 프로젝트를 무조건 해야한다는 이야기가 아니며, 토이 프로젝트를 해야 좋은 개발자라는 이야기도 아닙니다. 그러나 토이 프로젝트를 하고 있는 개발자는 분명 더 많은 경험을 할 수 있는 개발자라는 것은 꼭 말하고 싶었습니다.

저에게 많은 토이 프로젝트들이 생겼고, 첫 서비스를 하는 프로젝트도 생겼습니다. 이 프로젝트들은 기꺼이 레거시가 되어주어, 레거시를 개선해보는 경험도 시켜줄 것이고, 트래픽이 늘어나 그에 따른 새로운 경험들을 시켜줄 것 입니다. 내가 만든 라이브러리를 사용하는 사람들도 생길 것이고, 그들이 제기하는 이슈도 맛보게 될 것 입니다. 그리고 저는 이 프로젝트들을 통해 더 성장하겠지요?

관심있는 기술, 하고싶은 개발이 있지는 않으신가요? 그렇다면 시작해보세요! 토이 프로젝트를!