개발 피드 목록

앞서 종합 모빌리티 플랫폼인 타다의 시스템 설계를 위한 많은 고민과 기술적 결정들에 대해서 서버팀에서 소개한 바 있습니다. 이번 글에서는 타다 서비스를 출시하기까지 타다 모바일 클라이언트를 개발하는 과정에서 내린 클라이언트 팀의 전략적 결정들과, 타다 클라이언트를 개발하는데 사용한 기술들을 공유합니다.시작 전 상황3달 반의 개발 기간: 타다는 VCNC가 SOCAR에 인수되면서 개발하게 된 서비스입니다. 빠르게 시장에 뛰어들어서 선점하는 것이 무엇보다 중요했기에 시간과의 싸움은 필수적이었습니다. 프로젝트는 6월에 시작되었고 1.0 출시는 추석 연휴 직전인 9월 중순으로 결정되었습니다. VCNC에서 오프라인 운영은 처음이었기 때문에 차량을 실제로 운행해보면서 사용성 경험을 테스트할 필요가 있었습니다. 그래서 8월 초에 사내 테스트용 알파 버전을 출시하기로 했습니다.클라이언트 팀 통합: 비트윈 때는 Android/iOS 팀이 나뉘어 있었습니다. 회사 인수 과정에서 발생한 조직 개편으로 인해 타다 클라이언트 개발자는 5명으로 이루어졌습니다. 전부터 다른 OS 개발도 경험하고 싶던 적극적이고 열정적인 5명의 멤버들은 과감하게 팀을 통합해서 Android/iOS을 함께 개발하기로 했습니다.3개의 앱 개발: 타다의 서비스를 위해서는 Android/iOS, 라이더/드라이버 총 4개의 앱을 제작해야 합니다. 하지만 시간과 일정을 고려했을 때 4개의 앱을 다 제작하기는 무리라고 판단을 했습니다. iOS에서는 내비게이션 앱을 사용 중에 드라이버 앱으로 손쉽게 전환하는 기능을 제공할 수 없고 내비게이션 앱으로 경로 안내를 요청하는 것도 제한적이기 때문에 iOS 드라이버 앱은 제작하지 않기로 했습니다.무에서 시작한 프로젝트: 타다는 코드 베이스가 없는 empty repository에서 시작했습니다. 언어도 바뀌었고 레거시 코드와도 엮이고 싶지 않았기 때문에 비트윈에서 어떠한 라이브러리도 가져오지 않고 전부 새로 만들기로 했습니다.클라이언트 팀의 5명의 정예 용사들. by Sam코드 아키텍처 - RIBs프로젝트가 시작되고 기획이 진행되는 동안 3주의 시간을 기반 작업에 쓰기로 했습니다. 가장 먼저 진행한 것은 코드 아키텍처 정하기입니다. 당시에 제가 SAA(Single-Activity Application)에 관심을 가지고 있었는데, 때마침 Google I/O 2018의 세션 중 Modern Android development: Android Jetpack, Kotlin, and more 에서도 비슷한 언급이 나와서 팀에 제안했고, 본격적으로 조사를 해보았습니다. 팀원들이 조사를 진행해보니 Uber, Lyft, Grab 등 굴지의 모빌리티 서비스 회사들이 전부 SAA 기반으로 앱을 개발했다는 것을 알게 되었습니다. 무거운 리소스인 지도를 중심으로 화면이 구성되기에 반복적인 지도 리소스 할당/해제를 피하기 위한 필연적인 선택으로 보입니다. 큰 기업들이 수년간 서비스를 하며 문제를 느끼고 내린 선택인 만큼 저희도 따라가기로 결정했습니다. 비트윈 때 Activity Stack으로 인해 굉장히 고통을 겪은 적이 있는지라 SAA를 원하는 공감대도 있었고요.SAA로 개발을 하기로 정한 이후에는 어떤 프레임워크를 사용해서 개발할지를 고민했습니다. 여러 개의 오픈소스를 비교할 때 Android/iOS 간의 통일된 아키텍처로 개발할 수 있는지를 가장 중점적으로 보았습니다. 대부분의 팀원이 한쪽 OS에만 익숙하기 때문에 초보임에도 빠르게 적응하고 개발하려면 비즈니스 로직을 구현하는 부분이 통일되어 있어야 한다고 생각했습니다. Uber의 RIBs는 저희의 이런 요구를 가장 잘 충족했습니다. 거기에 데이터의 scope와 전달 방식 명확해서 side-effect 없이 개발할 수 있다는 점, 그로 인해 효율적으로 협업이 가능하고 여러명이 개발한 RIB 을 레고 조립하듯 합쳐서 기능을 완성할 수 있다는 점에서 RIBs를 선택하게 되었습니다.RIBs는 아키텍처를 이해하는 것 자체가 굉장히 난해합니다. 오픈소스 상으로 공개가 되지 않은 부분들도 있어서 저희의 입맛에 맞게 변형하는 데 매우 많은 시간을 할애했습니다. RIBs와 관련한 내용은 Nate(김남현)가 Let'Swift 2018에서 발표한 RxRIBs, Multiplatform architecture with Rx 의 영상 및 발표자료를 참조하세요.추후 RIBs를 상세하게 다루는 포스팅을 해보도록 하겠습니다.서버와의 통신 프로토콜새로운 서버 API가 생길 때마다 해당 API의 명세를 문서화하고 전달하는 것은 굉장히 불편한 일입니다. 또한 문서를 작성할 때나 클라이언트에서 모델 클래스를 생성할 때 오타가 발생할 수도 있습니다. 타다에서는 서버 클라이언트 간 API 규약을 Protocol Buffer를 사용해서 단일화된 방법으로 정의하고 자동화하기로 했습니다. 모든 API의 url은 .proto 파일 이름으로 정형화되어 있고 POST body로 Params 객체를 JSON으로 serialization 해서 보내면 Result JSON이 응답으로 옵니다. 서버가 새로운 API를 개발할 때 .proto 파일만 push 하면 클라이언트에서 스크립트를 돌려서 Model 객체를 생성하고 해당 객체를 사용해서 호출만 하면 되는 아주 간단하고 편한 방식입니다.참고로 타다의 서버군에 대한 설명은 타다 시스템 아키텍처에 기술되어 있습니다.기반 작업타다는 빈 repository에서 시작한 깔끔한 프로젝트였기 때문에 Base 코드와 내부 라이브러리들을 전부 새로 개발했습니다.API Controller, gRPC Controller서버와의 통신에 필요한 모듈들을 개발했습니다. 모든 API는 Rx의 Single과 Completable로 wrapping 되어 있습니다.RIBs가장 자주 사용하는 Router 패턴들을 wrapping.Android에서 구현이 공개되어 있지 않은 ScreenStack 구현.SAA이므로 Android에서 Activity가 아닌 화면 단위의 로깅을 구현.Router의 기초적인 화면 Transition을 구현RIB 뼈대 코드용 template 파일 제작Prefs(Android)/Store(iOS)타다에서는 DB를 사용하지 않고 key-value store로만 데이터를 저장합니다. Android SharedPreference와 iOS UserDefaults의 wrapper를 만들었습니다. Object를 serialization 해서 저장하는 기능, Rx 형태의 getter, cache layer, crypto layer 등이 구현되어 있습니다.Design SupportAndroid에서 drawable을 생성하지 않고 layout.xml 상에서 border, corner-radius, masking을 쉽게 설정하기 위해서 제작했습니다.ButterKtAndroid에서 View Binding 처리를 위해 개발했습니다. 비슷한 기능을 하는 Kotter Knife, Kotlin Android Extension이 가지고 있는 lazy binding 문제를 해결하고 싶었고 가능하면 Butter Knife와 달리 apt 없이 동작하는 라이브러리를 만들고 싶었습니다. 이와 관련된 저희의 생각은 여기에 David(김진형)이 상세하게 기록해 두었습니다. 코드도 공개되어 있으니 잘 활용해 보시길 바랍니다.ToolsModel CompilerPBAndK, swift-protobuf를 수정해 .proto 파일을 저희가 원하는 형태의 kotlin data class와 swift codable struct로 변환하는 스크립트를 구현했습니다.Import ResourceUI/UX 팀에서 작업해서 Google Drive File Stream으로 공유하는 리소스를 프로젝트에 sync 하는 스크립트입니다. 타다에서는 기본적으로 벡터 포맷(Android xml, iOS pdf)을 사용하고 Android에서 벡터로 표현이 안되는 이미지들은 png를 사용합니다. 또한 애니메이션을 위한 Lottie json 파일도 사용합니다. 현재는 Android 용으로만 스크립트가 구현되어 있고 리소스를 프로젝트 내의 각각의 res 폴더에 sync 하는 기능과 svg로 전달받은 벡터 파일을 Android xml 형식으로 변환하는 기능을 포함합니다.sync Lokalise타다에서는 Lokalise로 문자열 리소스를 관리합니다. strings.xml, Localizable.strings 파일로 다운받아서 프로젝트에 sync 하는 스크립트 입니다.Code Template & Settings개발 편의를 위한 간단한 Android Studio Code Template과 코드 통일성을 위한 idea settings를 공유합니다.사용된 기술들OS 공통Firebase: Analytics, Crashlytics, Messaging, Storage 등 다양한 용도로 Firebase를 활용하고 있습니다.gRPC, ProtoBuf: 서버에서 실시간 Event를 받기 위해서 사용합니다.RIBs: 타다의 기반 아키텍처 입니다.Lottie: 애니메이션 요소를 표현하기 위해 사용합니다.Semver: 앱의 버전은 Semantic Versioning 규약을 따라 정의합니다. 버전을 파싱하고 관리하기 위해서 Nate(김남현)가 Kotlin 버전과 Swift 버전의 라이브러리를 제작하고 공개했습니다.Braze: CRM(Customer Relationship Management) 툴인 Braze는 유저를 타게팅해서 전면팝업을 띄우거나 푸시 알림을 발송하기 위해 사용합니다.TeamCity, Fastlane, Beta: CI/CD를 위해서 개발 초기에는 Jenkins를 사용했습니다. 출시 대응을 빠르게 하기 위해서 parallel build 및 우선순위 컨트롤을 하고 싶었는데 Jenkins의 Parallel build가 원하는 대로 동작하지 않아서 현재는 TeamCity로 이전했습니다. Beta를 사용해서 모든 브랜치의 빌드를 배포해서 QA 팀에서 테스트할 수 있게 했습니다. 출시용 빌드는 Android의 경우 아직은 수동 업로드를 하고 있고 iOS의 경우 Fastlane으로 배포합니다.git-flow: Git branching model로는 git-flow를 사용합니다. Branch의 종류에 따라서 TeamCity에서의 빌드 우선순위가 결정됩니다.AndroidKotlin: 당연한 선택이겠죠? 타다의 모든 소스 코드는 Fork 해서 수정한 RIBs의 클래스들을 제외하면 전부 Kotlin으로 구현되어 있습니다.AndroidX: 타다 개발을 시작하는 순간에 AndroidX가 공개되었습니다. 기존 Support Library를 사용하게 되면 언젠가는 migration 해야 할 것이기 때문에 알파 버전임에도 불구하고 처음부터 사용하기로 했습니다. ConstraintLayout, PagingLibrary, Material Component, KTX 등 다양한 Component를 사용합니다.Retrofit, OkHttp: 서버와의 HTTP 통신을 위해서 사용합니다.RxJava: 클라이언트 팀은 Rx 없이는 개발할 수 없을 정도로 적극적으로 Rx를 활용합니다.AutoDispose: Rx subscription을 dispose 하기 위해서 사용합니다. 관련해서 도움이 될만한 글을 읽어보시는 것을 추천합니다. Why Not RxLifecycle?RxBinding: View 이벤트를 Observable 형태로 바꿔주는 RxBinding은 굉장히 유용합니다.Moshi: JSON 라이브러리입니다. Kotlin data class와의 호환을 위해서 Gson 대신 선택했습니다.Glide: 이미지 로딩을 위해서 사용합니다.Detekt: Kotlin을 위한 static code analyzer 입니다. Detekt의 extension을 통해 ktlint도 활용하고 있습니다.Dagger: RIBs는 Dependency injection을 기반으로 합니다. RIBs에선 어떠한 DI system이든 사용할 수 있게 Builder가 분리되어 있습니다. RIBs에서는 Dagger로 설명이 되어 있고 저희도 마찬가지로 Dagger를 사용합니다.ThreeTen Backport: Java8의 날짜 및 시간 라이브러리인 JSR-310의 Java SE6 & 7을 위한 backport 라이브러리입니다. 문자열 파싱 및 시간 연산을 위해 사용합니다.iOSSwift: Kotlin과 마찬가지로 당연한 선택입니다. Swift4.2의 CaseIterable Swift5의 Result 등 항상 최신 버전의 Swift를 사용합니다.RxSwift: 역시나 reactive programming은 필수입니다.RxCocoa, RxGesture: iOS에서도 역시 모든 뷰 이벤트는 Rx 형태로 감지합니다.SnapKit: AutoLayout DSL을 제공하므로 코드상에서 편하게 Constraint를 조절할 수 있습니다.Moya/RxSwift, Alamofire: Http 서버와의 통신을 위해 추상화된 네트워크 라이브러리인 Moya를 사용합니다. 역시나 Rx로 wrapping 된 버전을 사용하고 있습니다.Codable: Swift4부터 제공된 프로토콜로 JSON Encoding, Decoding으로 사용중입니다.Hero: RIBs의 Router가 attach/detach 될 때의 Transition을 처리하는데 이용합니다.Kingfisher: 이미지 로딩을 위해서 사용합니다.KeychainAccess: Access Token 같은 중요 정보를 안전하게 저장하기 위해 사용합니다.Swiftlint: SwiftLint는 fastlane action으로 실행해서 code validation을 합니다.출시 후의 회고짧은 시간에 여러 개의 앱을 만들기 위해서는 시간 및 인원을 아주 효율적으로 배분해야 했습니다. 각 OS의 기존 개발자들이 먼저 프로젝트 기반을 닦는 동안 나머지는 스터디를 진행했습니다. 차량 운영 경험을 쌓는 것이 알파 테스트의 목적이었으므로 일정에 맞추기 위해 드라이버 앱도 개발해야 하는 Android로만 알파 버전을 개발했습니다. 대신에 iOS 알파 버전은 서버팀 YB(김영범)가 아주 빠르게 웹앱으로 개발해주었습니다(1.0은 Native입니다.). 알파 버전의 스펙도 호출-하차까지의 시나리오 외의 다른 부가 기능은 전부 제외했습니다.회사 구성원들이 전부 처음 도전하는 분야였기에 기획을 포함해서 모두가 지속적인 변화에 대응해야 했습니다. 특히 사내 테스트를 시작한 직후 실제 운영을 해보며 깨닫고 변경한 기획 및 UX가 상당히 많았습니다. 개발적으로는 익숙하지 않은 아키텍처인 RIBs를 이해하며 개발하는 것이 생각 이상으로 난도가 높았고 개발하는 중간에도 큰 리팩터링을 여러 번 해야 해서 힘들었습니다. 이러한 이유들로 1.0 출시도 시작 전 상황에서 언급한 것보다 2주 정도 미뤄졌습니다.실제 타다 프로젝트 타임라인하지만 저희는 성공적으로 타다를 출시했습니다! 아래는 팀 내에서 출시를 회고하며 나왔던 몇몇 의견입니다.OS 간 아키텍처가 통일되어서 한 명이 같은 기능을 두 OS 전부 개발할 때 굉장히 효율적이다. 비즈니스 로직의 경우 정말로 Swift <-> Kotlin간 언어 번역을 하면 되는 정도.결과적으로 앱 개발 순서를 굉장히 잘 정했다. 한쪽을 먼저 빠르게 개발하고 문제점을 느껴보며 정비해 나가니까 프로젝트 후반부에 빠른 속도로 기능을 개발하는 데 도움이 되었다. 큰 수정을 양쪽 OS에 하지 않아도 됐던 게 좋았다.짧은 기간 개발했음에도 앱 퀄리티가 굉장히 만족스럽다. 매 상황에서 기술적 선택, 인원 배분 등 경험에서 우러나온 아주 적절한 판단들을 했다고 생각한다.각자 독립적으로 개발하던 기능들이 쉽게 합쳐지고 큰 문제없이 잘 동작하는 하나의 앱이 되는 과정이 정말 신기했다. 아키텍처 설계에 쓴 많은 시간이 결코 아깝지 않았다.마치며아직 저희가 하고 싶고 도전해야 하는 과제들은 무궁무진합니다. 그 중 간략히 몇 가지를 소개합니다.테스트 코드 작성: 시간과의 싸움 속에서 테스트 코드 작성을 지금까지 미뤄왔습니다. RIBs의 Interactor 에 구현된 비즈니스 로직은 반드시 테스트 되어야 합니다.OS 간 구조 통일: 같은 화면임에도 OS 간 작업자가 다른 경우 많은 파편화가 일어났습니다. 1순위로 RIB tree 및 Interactor의 비즈니스 로직 통일하는 작업을 진행하고 있습니다. AlertController 같은 공통적인 컴포넌트들도 최대한 포맷을 통일하려는 작업을 지속해서 진행할 예정입니다.iOS DI: RIBs에서 Android에선 Dagger를 활용해서 쉽게 Builder 구현이 가능하지만, iOS에서는 좋은 방법이 없어서 수동으로 DI를 해결하고 있었습니다. 그래서 Uber가 개발 중인 Needle을 적용하려고 관심 있게 보고 있습니다.네트워크 에러 handling 개선: 중첩돼서 뜨는 Alert를 해결하는 것, global 하게 에러를 처리하는 좋은 구조 찾기 등의 이슈가 있습니다.String Resource 관리: 개발하면서 생성하고 아직 Lokalise에 동기화하지 않은 리소스 키를 체크해서 빌드 오류를 발생시키려고 합니다. 또한 iOS에서 "some_key".localize 형태의 extension으로 번역을 코드상에서 불러오는데 key 값 오타가 나면 런타임에서만 오류를 알 수 있습니다. 따라서 String resource를 enum 형태로 관리하려고 합니다.그 외 50여 가지나 되는 팀원들이 하고 싶은 백로그 목록이 여러분을 기다리고 있습니다. 타다가 성공적으로 런칭할 수 있었던 것은 훌륭한 팀원들이 있었기 때문입니다. 앞으로 저희와 함께 좋은 서비스를 만들어 나갈 멋진 분들의 많은 관심 바랍니다.

2015년 11월 4일에 8퍼센트에 입사했으니 이제 1년이 되었다. CTO라는 직함을 달고 보낸 지난 1년을 뒤돌아 본다.1년전 첫번째 스프린트나는 무엇을 원했던가?회고를 할 때는 목표를 기준으로 지금을 살펴봐야 한다. 일 년 전에 썼던 8퍼센트에 입사하기까지 라는 글을 다시 꺼내어 보니 당시의 나는 이런 것들을 원했다. 성공하는 회사에 다닌다.개발 조직을 책임 지고 꿈꿔왔던 이상을 실험한다.회사 경영을 경험한다.사회에 도움이 되는 일을 한다.1) 성공하는 회사에 다닌다. 입사 전이라 "성공하는 회사에 다닌다”라고 적었지만 입사를 한 이상 “회사를 성공시킨다”라는 목표로 바꿔서 생각해도 좋겠다.2015년 10월 말을 기준으로 78.4억의 누적 대출액이 현재 기준으로 480억 가량 되니 지난 1년 동안 약 400억의 돈을 투자자로부터 대출자에게로 연결했다. 나는 이 돈의 크기가 정확히 8퍼센트라는 회사의 사회적인 영향력 그리고 고객들이 회사에 갖는 신뢰의 크기라고 생각한다. 또한 회사의 성공의 척도이다.그럼 이 400억이 성공을 이야기할 때 충분한가에 답을 해야 할터인데, 아직은 많이 부족하다. 하지만 어디인지 모르는 성공이라는 것에 다가갈 확률이 일 년 전에 비해 높아졌느냐라고 묻는다면 "그렇다"라고 자신 있게 말하겠다. 그리고 나 또한 그 확률을 높이는 것에 공헌하고 있다.입사할 당시에 대표님이 내세웠던 조건 중 하나가 올해 말 기준으로 500억이었는데, 그 기준은 넘기게 되었으니 80점을 주자.2) 개발 조직을 책임 지고 꿈꿔왔던 이상을 실험한다.입사 전에는 개발 조직만 맡을 것이라고 생각했으나, 현재는 더 넓은 프로덕트를 만드는 조직을 책임지고 있다. 1년 전에 꿈꿨던 이상이라는 것은 멋지게 일하는 조직이다. 입사 초기에는 이를 위해 꽤나 많은 노력을 했다. 회사 자체가 백지상태이기도 했고 의욕도 충만했다. 하지만 시간이 지나면서 나도 모르게 안주하게 되고 더 잘하기 위한 노력에 게을러졌다. 반성하자. 그래도 일 년 동안 데모를 한 번도 빠지지 않고 34차례 진행했다. (종종 프로젝트 진척이 잘 되지 않으면 데모에서 도망가고 싶다) 그리고 주기가 끝날 때마다 프로세스 개선을 위한 회고 회의를 해왔다. 비록 그 과정에 보완할 점은 많으나 포기하지 않고 프로세스를 일 년 동안 유지한 것에 점수를 주고 싶다. 이상에는 아직 멀었으나 이 조직이 내가 많은 것들을 실험할 수 있고, 그런 설득만 할 수 있다면 그 실험에 기꺼이 동참해 줄 수 있는 조직이라는 것을 깨달았다. 80점으로 시작해서 50점까지 내려갔다가 최근에 10점 정도를 얻었다. 60점을 준다.3) 회사 경영을 경험한다. 초기에 대표님의 신뢰를 얻는데 까지 시간이 꽤 걸렸다. 지금 생각해보면 서로 간의 신뢰를 쌓는데 시간이 걸리는 것은 자연스러운 것인데, 초기에는 의욕이 앞섰다. 왜 내게 더 많은 것을 맡기지 않는지가 불만스러웠다. 대표님이 내리는 결정의 많은 부분에 의심이 들었으며 딴지를 걸었다. 하지만 지금은 대표님의 선택과 결정이 대부분 이해되고 신뢰가 간다. 그리고 대표님이 내게 많은 것을 위임하고 믿어주는 것을 느낀다. 합이 맞아간다.생각보다 회사는 시장의 시간에 쫓겨 부족한 정보를 가지고 결정을 내려야만 했다. 회사의 결정이 모든 것을 좌우한다고 생각했었지만 이제는 결정에 따른 실행이 더 중요하다는 것을 알게 되었다. 4) 사회에 도움이 되는 일을 한다. 사회에 도움이 되는 일을 하는 것은 이 회사에 입사했을 때 결정이 되었다. 회사의 성장이 사회에 미치는 긍정적인 영향과 비례한다는 생각에는 변함이 없다. 이 회사의 존재가 이미 사회에 많은 영향을 미쳤다. 그리고 대부분은 긍정적인 영향이라고 생각한다. 90점을 주겠다.일하는 것의 변화 1) 일하는 양의 변화초기 반년은 후회가 없을 정도로 최선을 다해서 살았다. (내가 인생에서 이런 말을 할 수 있는 시기가 몇 번 없다.) 내 역량의 100%를 다하며 살았다. 그 6개월을 지난 이후에는 살짝 기어를 낮췄다. 좋게 말하면 마라톤을 위한 모드로 바꿨다고도 할 수 있고 어쩌면 6개월의 달리기로 조금 지쳤는지도 모르겠다. 2) 시간 분배의 변화처음 입사했을 때에는 시간의 50%를 개발에 사용했지만 지금은 10% 밖에 사용하지 못하고 나머지 40% 를 프로젝트 관리에 사용하고 있다. 30% 정도를 팀에 쓰고 있는데 처음에는 팀의 구조를 갖추는 데 사용했다면 지금은 팀을 운영하는 데 사용한다. 대체로 자리에 앉아 있는 시간이 많이 줄었고 내외부 사람들과 커뮤니케이션하는 시간이 늘어났다. (슬랙 통계를 보니 내가 압도적인 수다쟁이더라)나는 무엇을 배웠을까? 1) B2C 사업에서의 배움 기존에 일했던 회사는 B2B 회사였다. 손에 꼽을 수 있는 고객을 만족시키면 되었고 상대적으로 그들이 원하는 것은 명확했다. 혹은 커뮤니케이션을 통해 요구사항을 명확하게 만들 수 있었다. 상대적으로 긴 호흡으로 일을 했고, 성능이 중요했다.B2C 서비스는 달랐다. 고객은 어떤 면에서는 전혀 이성적이지 않았다. 놀라운 일이었다. 하지만 대부분 우리의 서비스는 냉정하게 평가되었다. 고객의 반응은 즉각적이지만 그 반응을 옳게 해석해서 제품에 반영하는 것은 어렵구나라는 것을 느꼈다. 지금 이 순간 고객을 최대로 만족시키는 선택이 회사에 있어 항상 옳은 선택은 아니라는 것도 알았다. 내가 개발하고 있는 서비스를 사용하는 많은 사람들이 있다는 것 그리고 사회에 직접적인 영향을 미친다는 것이 제품 개발을 지속할 수 있는 큰 동기가 된다는 것을 느꼈다.2) 프로덕트 책임자로서의 배움제품을 책임지고 있는 사람으로 B2C 서비스에 필요한 많은 역량이 부족하다는 것을 알게 되었다. 그리고 나의 부족한 역량이 완성도가 떨어지는 서비스에 많은 영향을 주고 있다는 것 또한 알게 되었다. 기획자와 일하는 경험, 디자이너와 일하는 경험 모두 처음이었다. 이를 통해 같은 회사에서 하나의 제품을 만들지만 그것을 바라보는 다양한 시각이 존재한다는 것을 알게 되었다.지난 회사의 CTO를 보며 제품의 문제를 어떻게 이렇게 잘 찾아낼까 생각했었는데 나 또한 그렇게 되더라. 통찰력이 아니라 관심을 얼마나 가지는가, 얼마나 책임감을 가지고 제품을 바라보는가에 대한 차이라는 것을 알게 되었다. 많은 기술적, 비즈니스에 기반한 결정을 했고, 그 결정의 결과를 지켜보고 있다. 그것에서 배웠다.3) 프로젝트 관리자로서의 배움 프로덕트팀이 일하는 방식으로 스크럼을 도입했다. 스크럼을 할 때 ScrumBut(우리는 스크럼을 해요. 하지만 이것저것은 하지 않아요.)을 유의하라는 말을 하는데 스크럼에서 요구하는 것들 중에서 하지 못한 것들이 꽤 있다. 예를 들면 업무의 양을 측정해서 번다운 차트를 제대로 그려가며 팀의 속도를 측정하거나, 업무를 항상 우선순위 기반으로 하는 것 등이다. 처음에는 시도했었으나 몇 번의 스프린트 후에는 적당히 스크럼을 적용하고 말았다. 프로젝트를 잘 관리하기 위해서는 많은 노력이 필요하다는 것을 알면서도 필요한 만큼의 노력을 기울이지 않은 것을 반성한다. 코딩을 포함한 회사에 많은 재미있을 것들에 우선순위를 두고 재미없음을 이유로 중요한 프로젝트의 관리를 뒤로 미루었다.4) 도구의 도입에서의 배움여러 가지 도구들을 도입했다. 모든 커뮤니케이션을 슬랙을 통하도록 여러 가지를 도입했다. 아마 우리 회사만큼 슬랙을 열심히 그리고 잘 쓰는 회사가 흔치 않을 것이라 생각한다. 컨플루언스를 도입해서 문서를 쓰는 문화를 만들어 갔다. 여전히 내가 제일 많은 문서를 쓰고, 대부분 내가 위키 가드닝(문서의 내용과 구조를 재조직하는 일)을 하고 있지만 사람들이 위키를 통해서 커뮤니케이션하는 것을 자연스럽게 생각하는 것을 보면 뿌듯하다. 트렐로도 도입해서 사용하고 있다. 최근까지는 엉성하게 쓰고 있었는 데 사용 가이드라인을 잡아서 한번 공유했으니, 앞으로 팀에 녹아들 것으로 기대한다.이렇게 도구를 도입하는 과정에서 변화를 이끌어 내는 방법을 연습했다. 사람들은 스스로 필요성을 느껴야 변화를 받아들인다. 탑다운식의 강압적인 도입은 결국 실패한다. 구성원들이 도구가 업무에 도움이 되는구나 라는 것을 느낄 때까지 선구자가 많은 노력을 기울여야 한다는 것을 알게 되었다. 사람들은 자신들이 필요한 정보를 컨플루언스에서 찾을 수 있을 때 자신도 정보를 컨플루언스에 남기기 시작했다. 자신들의 요청이 트렐로를 통해서 잘 처리된다는 것을 느꼈을 때 새로운 업무를 트렐로를 통해 전달해 주었다. 5) 개발에서의 배움초반에는 영역을 가리지 않고 개발을 했었다. 인프라 쪽도 정리하고 대출 프로세스도 개발하고 다른 금융업체와 연동도 하고 그리고 개발 환경도 갖추었다. 하지만 1년이 지난 지금 이미 내가 작성했던 코드는 절반 이상 다른 분들의 더 나은 코드로 대체되었다.타 금융권과 연계해서 개발을 하면서 이쪽 동네가 얼마나 기술 변화에 뒤쳐져 있는지를 알게 되었다. 취미로만 해봤던 웹 개발을 제품 레벨로 처음 해봤다. 프런트앤드 개발의 중요성과 어려움을 알게 되었다.개발팀의 효율을 올릴 수 있는 테스팅, 코드 리뷰, CI의 사용 등을 실제로 적용해 볼 수 있었다.마지막으로 회사에 좋은 분들을 모셔오면서 내가 얼마나 부족한 개발자인지를 알게 되었다.6) 금융업에서의 배움회사의 절반인 프로덕트를 만드는 사람들은 대부분 스타트업 출신이고, 나머지 절반은 금융권 출신으로 구성되어 있다. 금알못(금융을 알지 못하는 바보)으로 출발한 내가 이제 그들의 대화에 낄 수 있는 정도는 되었다. 하지만 여전히 하루가 멀다 하고 새로운 용어와 개념을 만나고, 대화가 끝나면 용어를 검색해보기 일쑤다.금융 동네는 어떤 경우에는 모든 것에 이유가 있어 딱딱 맞아떨어지는 것처럼 보이다가도 어떤 경우에는 도대체 이해가 안 되는 경우를 만나기도 한다. 여하튼 지난 일 년 동안 새로운 분야에서 일하면서 모르던 것(정확히는 모르는지도 몰랐던 것)들을 알아가는 즐거움을 느꼈다. 다음 회사를 가게 된다면 금융이 아닌 또 다른 분야에서 일하는 게 좋겠다는 생각이 들었다. 7) 채용에서의 배움입사했을 때 개발자 2명, 기획자 1명, 디자이너 1명이던 팀은 이제 개발자 9명에 기획자 2명, 디자이너 1명인 12명 팀이 되었다. 이 중 개발자 6명과 기획자 1명을 직접 채용했다. 이 과정에서 스타트업 채용의 어려움을 알게 되었고 조그만 노하우를 얻게 되었다. 그리고 채용에 따르는 책임이라는 것도 알게 되었다.채용 글을 쓰고 페이스북에 광고를 하고 구인 사이트에 올려보고 했지만 결국 대부분의 채용이 소개로 이루어졌다. 좋은 사람은 쉽게 다른 회사에 지원하지 않는다. 채용한 사람의 30배가 넘는 이력서를 받았고 5배가 넘는 면접을 보았다. 하지만 결국 소개를 받아 채용하는 것이 거의 유일한 방법인 것 같다. 회사에 대해 꾸준히 글을 써오고 있는데 이것이 채용에 많은 도움이 되었다.프로덕트팀 구성원은 내가 직접 채용을 결정하다 보니 이효진 대표에 의해서 내 인생이 바뀐 것처럼, 내가 채용한 사람들의 인생을 바꿨다. 그들이 자신들의 능력을 발휘해서 8퍼센트에 공헌할 수 있도록 하고 회사를 성공시켜서 그들의 노력에 답해 줄 수 있어야 한다는 생각을 한다. 8) 관리자로서의 배움 지난 회사에서 5명의 팀 리더를 할 때에는 내가 개발자인가 관리자인가라고 물으면 답하기가 쉽지 않았다. 하지만 지금 내게 묻는다면 나는 관리자라고 답하겠다. 나는 내 노력 50%를 들여서 전 구성원의 효율을 10% 더 올릴 수 있는 사람이 되어야 한다. 좋은 관리자였냐라고 하면 그렇지는 못했던 것 같다. 특히 구성원들에게 제때 필요한 피드백을 하지 못한 것은 아쉽다. 쓴소리를 해야 하는 위치에 있음에도 좋은 사람으로 남고 싶어서 적절한 때 적절한 피드백을 하지 못했다. 특히 같은 팀에 있는 디자이너와 기획자에게는 미안한 마음이다. 그들의 결과물에 대한 피드백도 쉽지 않았고, 커리어에 대해 해줄 수 있는 조언도 없었다. 그저 그들이 맡고 있는 좋은 프로덕트를 통해 성장해 나가길 바랄 뿐이다. 회사에서 1년 동안 "함께"라는 것을 기업 문화에 심기 위해 노력했다. 내가 시도했던 것들 중에 어떤 것들은 문화가 되어 정착이 되었고, 어떤 것들이 도태되어 사라졌다. 그 기준은 재미였다. 사람들에게 재미를 줄 수 있었던 슬랙의 #study 채널을 통해서 함께 공부하기, 브런치 매거진을 통해 함께 글쓰기, 2주에 한 번씩 오는 특별한 점심, 함께 하는 워크샵은 문화로 살아남았고 나머지는 사라졌다. 잃은 것은 무엇인가?1) 개발자로서의 경쟁력 개발자로서 경쟁력이 떨어지고 있다. 일반적으로 개발자가 망하는 과정을 다음과 같이 이야기한다.개발을 열심히 잘 하고 있음나이가 들면서 회사에서 관리자를 하라고 함관리자를 했더니 개발할 시간이 없어서 개발 실력이 떨어짐그 회사를 나오고 났더니 찾아 주는 곳이 없음치킨집내가 이런 과정으로 가고 있는 것은 아닐까? 에 대한 불안감이 있다. 전 회사에서는 새롭게 쏟아지는 기술들을 따라가며 공부를 해왔는데, 이제는 그런 공부 대신 당장 회사에 필요한 공부를 하게 된다. 이렇게 기술적인 경쟁력을 잃어 가게 되면 앞으로 먹고사는데 문제는 없을까?라는 생각도 들고, 당장 CTO라는 자리에서 옳은 결정들을 할 수 있을까 하는 생각 또한 든다. 2) 나와 가족체중을 얻었다. 운동할 시간이 없었기보다는 운동할 마음의 여유가 없었다. (둘 다 핑계이기는 매한가지다.) 체중이 늘어나다 보니 나 자신에 대한 자신감이 좀 떨어졌다. 가족들과는 입사 전에 비해 많은 시간을 보내지 못한다. 시간을 함께 보낼 때에도 핸드폰으로 슬랙을 확인하기 일쑤였다. 그리고 육체적/정신적으로 지친 상태라 100% 마음껏 놀아주지 못했다. 총평8퍼센트에 입사하기 전 일 년보다 훨씬 더 치열하게 살았다는 것만으로도 만족할 수 있는 1년이다. 내가 원하던 자리에서 원하던 경험을 할 수 있는 기회를 갖게 된 것만으로도 8퍼센트와 이효진 대표에게 감사한다. 자신 있게 추진하던 일 중 용두사미가 되어 버린 것들은 아쉽다. 하지만 용기 있게 많은 것들을 시도한 것은 잘했다. 내가 잘하는 것과 못하는 것이 여실히 드러난 1년이었다. 다음 1년은 무엇을 목표로 해야 할까?1) 회사를 성공시키자회사의 성장과 성공에 기대고 있는 것들이 너무나 많다. 지난 1년이 잽으로 탐색으로 해보는 1라운드였다면, 앞으로의 1년은 제대로 주먹을 뻗어보고 맞아보는 2라운드가 될 것으로 기대한다. 2) 그릇의 크기를 늘이자내 그릇의 크기에 따라 좋은 프로덕트, 구성원들의 성장, 채용이 좌우된다는 것을 알게 되었다. 그리고 입사 전보다 내가 갖춰야 할 역량들이 훨씬 명확해졌다. 꾸준히 갈고닦자.3) 더 멋지게 일하는 팀을 만들자 점점 손발이 맞아 간다. 더 많은 기회를 제공하고, 더 많은 것을 위임하자. 그리고 피드백을 잘하자. 이를 위해 끊임없이 실험하자.4) 손은 항상 더럽게지난 회사 CTO 님의 가장 큰 장점이 항상 손을 더럽게 유지하는 것이었다. 다시 말해 작더라도 일부 모듈을 직접 개발하고 다른 사람들의 코드들을 충분히 이해하셨다. 나 또한 다른 많은 일들이 있더라도 하루에 한 줄의 코딩은 할 수 있도록 하고, 다른 사람의 코드를 리뷰하는 데에도 시간을 쏟아야 하겠다.다시 맞이하는 1년회고를 통해 순식간에 지나간 지난 1년이 가볍지 않았다는 것을 알게 되었다. 다행이다. 이 글을 작성하면서 1년 전에 쓴 8퍼센트 입사 날을 읽어 보았다. 그날만큼은 아니지만 가슴이 두근거린다. 여전히 8퍼센트는 내게 모험이고 도전이다. 이제 새로운 마음으로 1년 1일 째를 맞이해야겠다. 지금 기분이라면 1년 뒤 더 멋진 회고글을 쓸 수 있을 것 같다.30번째쯤 스프린트의 데일리 미팅저와 함께 하고 싶은 개발자 분은 지원해 주세요! 기다리고 있습니다.#8퍼센트 #에잇퍼센트 #CTO #기업문화 #조직문화 #팀문화 #후기 #돌아보기 #개발자

스토리 홈

인터뷰

피드

뉴스

SaaS 와 On-Premises 장단점

Node.js - Event

Golang 체험기

Bluetooth Low Energy(BLE) 파헤치기

아키텍트, 개발 리더십의 변화...

CSS animation으로 프로토타이핑하기

AWS Rekognition + PHP를 이용한 이미지 분석 예제 (2/2)

타다 클라이언트 개발기

AWS Lambda에서 메모리 설정값과 CPU 파워의 관계

8퍼센트 CTO 1년 차 회고

[Tech Blog] How we pipe data

100일 간의 챗봇 디자인 실패기-1편

샌프란시스코 테크 업계 인터뷰 2: Bleacher Report, Udemy, Intuit

Humans of TODAIT : 전설의 전성윤을 만나다

Culturalization of Video Game Soundtracks: An Interview with Pierre Langer, Managing Director & Founder of Dynamedion

개발자의 경력관리란?