👋 안녕하세요! 코드브릭 입니다.

이렇게 만나뵙게 되어 반갑습니다! :)
여기까지 들어오시게 되었다면, 아마도 당신은 개발자? 코드브릭과 토코톡에 대해 소개드릴게요!:smile:

코드브릭은 무슨 회사인가요? 토코톡은?

코드브릭(Codebrick)은 인도네시아 이커머스 플랫폼 토코톡(TokoTalk)을 개발, 운영하고 있습니다.

토코톡은 개인 혹은 기업이 온라인샵을 손쉽게 생성, 편집하고 상품/주문/결제 관리를 가능하도록 하는 온라인 서비스로 Ecommerce에 필요한 기능을 End-to-End로 제공합니다. (잘 알려진 Shopify, 카페24와 같은 서비스입니다)

인도네시아✈️ 를 대상으로 서비스 하고 있으며, 현지에 특화된 기능과 가치를 제공, 2018년 2월 오픈 이후 꾸준한 성장🔥 을 지속하고 있습니다.

#TokoTalk #이커머스 #인도네시아 #스타트업 #성장 #Shopify

토코톡의 Tech Stack?

토코톡의 BE와 FE는 각각 Go와 Vue.js 기반으로 만들어지고 있습니다.

Backend는 BeeGo에 기반하여 코드브릭에 맞게 변형시킨 Core Framework을 기반으로 Main API를 구성하며, Payment, notification, ads management 등 여러가지 Micro Service들로 구성되어 있습니다. (Micro service는 Java/Spring, Node.js 등 경우에 따라 다른 언어와 프레임웤을 사용하여 구성하기도 합니다)

온라인 샵에서 특히 중요한 Frontend는 Vue.js에 Nuxt.js를 이용하여 Server-side rendering을 구현하였으며, Vuetify를 사용하고 있으나 최근 로딩 속도를 위해 이를 경량화를 시키려 준비 중입니다. DB는 MySql, MongoDB를 사용하고 있으며, AWS 상에서 운영되고 Jenkins를 이용하여 배포하고 있습니다.

#요즘뜨는 #Go #Vue+Nuxt꿀조합

Go(lang)?

토코톡이 사용하는 Go는 아직 아주 널리 사용되고 있지는 않지만, 점점 더 많은 프로젝트에 이용되고 있습니다. 코드브릭은 2016년 창업시부터 Go를 팀의 주언어로 사용하기 시작하였고, 자연스레 2018년 토코톡 개발시 Go를 사용하게 되었습니다. ✌️

Go는 컴파일 언어이면서도 Scripting 언어의 장점을 가지고 있습니다. 코드가 간결하고 작성하기 편하며, 포맷이 엄격하여 깔끔하게 구성이 가능합니다. 가비지 콜렉션, 빠른 컴파일 등의 장점을 가지고 있고 기본 라이브러리도 풍부합니다. (하지만 정작 쓰려고 찾아보면 없다는 건 함정...:droplet:) 또한 동시성(concurrency)이 지원되어 효율적인 프로세스를 구현할 수 있습니다.

코드브릭에 오시면 당연히 Go를 마음껏(?) 이용해 보실 수가 있겠...죠? 😅

토코톡 개발팀?

코드브릭은 현재 서울 사무실 10여명, 자카르타 사무실 50여명의 인력 (총 60명) 으로 구성되어 있습니다. 모든 프로덕트 개발 인력은 현재 한국 사무실에서만 근무하며, 서비스 규모에 비해 아주 작은 인력으로 개발 및 시스템 운영이 진행되고 있습니다. (따라서 부득이하게:smiling_imp: 개발자 최우선 주의의 사무실 분위기를 구성하고 있습니다.)

따라서 개발자 개개인의 서비스에 대한 기여가 높아, 기술/태도 모두 높은 기준을 가지려고 노력합니다. 백로그 아이템들은 사용자들의 Feedback을 기반으로 하거나, 사업 전략적인 아이템으로도 구성이 됩니다. 1~3주 단위의 스프린트를 진행하며, 개발자와 PO간 논의를 통해 실제 구현할 사항들을 구체화하고, 주도적으로 개발을 진행하며, QA팀은 자카르타 사무실에 근무하며 협업하고 있습니다.

#개발자최우선 #내가만드는서비스 #처음부터끝까지

이렇게 개발합니다.

저희는 프로세스 보다는 결과물를 중시합니다. 사용자가 원하는 혹은 필요로 하는 기능을 가장 빠르게 전달하고, 또 최대한 빠르게 개선하는 것을 목표로 합니다. 하지만 그 과정 중에서 팀원들이 학습하고 함께 성장하기 위해 다음과 같은 과정으로 일하고 있습니다.

1. 백로그 관리

• 제품 개선의 아이디어는 주로 사용자와 직접 대면하는 현지 어카운트 매니저(Account Manager, 이하 AM)이 최초로 발의합니다. 모든 제안/의견/버그리포트는 Jira 카드로 등록됩니다. 매일 수십 개의 이슈들은 PO가 모두 리뷰하고, AM과 (끊임없는) 대화를 통해 사용자의 실제 의도와 요청 사항으로 구분되어 정리합니다. (카드는 유저스토리, 그리고 고려사항을 구분하여 정리합니다) 즉, 백로그에 쌓입니다.
• 별개로, 사업적 필요성으로 추가되는 (주로 굵직한) 이슈들이 있습니다. 완전히 새로운 기능이거나 새로운 시스템의 적용, 큰 규모의 리팩토링이 해당되며, 팀 내부의 제안으로 시작됩니다. 이 경우, PO와 개발팀이 수일~수주에 걸쳐 아이디어를 구체화하고 타당성을 검증합니다. 어느정도 구체화가 되면 Jira에 에픽-스토리로 정리하여 백로그에 저장합니다.
• PO는 사용자가 얻는 가치와, 회사가 얻는 가치를 기준으로 백로그를 우선 순위로 유지(하려고 노력...:roll_eyes: )합니다.

2. 스프린트 시작

• 백로그의 우선순위, 개발 리소스를 고려히야 개발팀이 함께 논의하고 개발 항목을 배분(?)하는 것으로 스프린트를 시작합니다. 대부분의 경우 하나의 Feature는 한 사람의 개발자가 담당하게 됩니다. (1:1이 아니라 N:1...) 먼저 손들면:raising_hand: 원하는 Feature를 개발할 수 있습니다. (손안들면 남겨진 항목을...)
• 매일 아침 스크럼에서 각각 진행 상황과 이슈를 공유합니다.
• 매주 새로운 스프린트가 시작하지는 않지만, 개발 회의는 매주 진행합니다. 이를 통해 일정을 재확인하고, 문제점을 논의합니다. 필요한 경우 리소스를 재분배하기도 합니다. 지난 스프린트에 대한 간단한 회고도 진행합니다.

3. 개발/배포

• 담당하는 Feature는 하나 혹은 여러 유저스토리로 구성될 수 있습니다. 개발자와 PO가 유저스토리를 구현할 방법을 함께 논의하고, 스펙을 정리합니다. UI 개선이 아닌 대부분의 경우, UI 디자인이 먼저 작성되지 않습니다. 기존 UI 컴포넌트를 최대한 활용하며, 필요한 경우 개발자가 디자이너와 논의하여 디자인을 구체화합니다. 구체화한 스펙을 다시 Jira 카드에 정리하는 것도 개발자의 몫입니다.
• 많은 경우 담당하는 Feature의 BE/FE를 모두 개발합니다. 업무를 나누는 경우도, 가능하다면 유저스토리 단위로 나누며 굳이 BE/FE로 나누지는 않습니다.
• 모든 레파지토리는 기본적으로 Live, QA, Master 세개의 브랜치를 갖고 있습니다. 개발자는 Master 브랜치에서 새로운 브랜치를 생성하여 개발을 진행 후, Master로 PR을 요청합니다. PR 리뷰는 필수이며, Jenkins로 빌드 테스트 성공 후, 다른 개발자에 의해 승인이 되어야 Merge가 가능합니다. (유닛 테스트도 진행하면 칭찬 받습니다..:clap: )
• Master브랜치는 업데이트 시 자동으로 Dev환경에 배포되며, Dev에서 PO가 확인하고 개선 사항을 논의 합니다. 완료된 개발에 대해서는 PO가 QA 체크리스트(테스트 시나리오)를 작성합니다.

4. QA

• Dev 환경에서 확인이 완료되면, 새로운 버전으로 Branch cut 후 QA 에 배포합니다.
• QA 환경에서 현지 QA팀이 신규 기능에 대한 체크, 버그 수정을 요청합니다. 신규 기능에 대한 확인 완료 후 새로운 스프린트를 시작하고, QA는 최종적으로 풀테스팅을 통해 사이드이펙트 버그를 체크하고 수정을 요청할 수 있습니다. 이 경우 개발자는 Master 에 수정하고 QA에 체리픽하여 업데이트합니다.
• QA 팀이 테스트를 완료하면 릴리즈를 컨펌합니다. 이후 Live 로 배포되고, 해당 브랜치는 추후 Live 환경에서 문제가 있을 시 핫픽스를 진행하게 됩니다.

5. 기타

• 스프린트는 대부분 2주 단위로 하지만, 정석처럼 칼 같이 지키진 않습니다. (저희는 프로세스보단 결과를..) 개개인이 담당한 업무가 차이가 있을 수 있어 중간이 추가되거나 빠지기도 하며, 기간 자체가 조절되는 경우도 있습니다. 하지만, 매주 회의를 통해 상황을 공유하고 논의하며, 최대한 기능이 빨리 사용자에게 전달될 수 있도록 노력합니다.

• 기능과 관련하여 개발자가 아주 많은 권한을 가지게 됩니다. 구현 방식 뿐 아니라 지원 가능한 스펙 또한 개발자와 PO의 논의를 통해 구체화되기 때문에, 본인의 판단에 따라 서비스의 스펙이 바뀌는 경험을 하실 수 있습니다. (다만 그렇기에 개발이 아닌 다른 부분에 신경을 써야하는 점도 있습니다. 사용성, flow, 디자인 등...)

  "With great power comes great responsibility..." 🕷️

• 개발자 간 서로 배우고 역량을 향상시킬 수 있는 방법을 찾고자 노력합니다. 새로운 기술, 툴이나 프로세스에 대한 (비정기적) 공유 세션을 갖습니다.

개발자를 찾습니다!

Ecommerce 플랫폼 구축, 또는 인도네시아 시장에서 새로운 서비스를 개발하는 경험이 궁금하신 분들. 글로벌 비지니스를 만들고 싶거나 혹은 Go 새로운 기술을 사용해보고 싶은 어떤 개발분들이라도 만나뵙고 싶습니다. 각잡고 입사지원이 아니라도, 회사나 서비스 혹은 개발과 관련한 호기심이 있으신 분들은 아래로 간단한 소개와 함께 연락 부탁드립니다.

그럼 기다리겠습니다~ 🤘

감사합니다!

[email protected]