원문: https://blog.passionoil.co/andeuroideu-rilrijeu-beogeu-eobsi-3-5ju-cut-haneun-beob/ 2022년 1월 29일에 작성된 글 입니다.

안녕하세요, 열정에기름붓기 cto 새발입니다. (우리 팀은 2글자 닉네임으로 서로를 부릅니다.)

블랙스완 안드로이드 첫 버전이 릴리즈 되었습니다. 개발 기간은 3.5주 밖에 되지 않습니다. 어떤 방식으로 프로젝트에 접근하고, 협업하고, 개발했는지 한번 적어보려 합니다.

코로나로 인해 크리에이터클럽이 문을 닫고, 팀원들이 떠나가는 와중에 남아있는 팀원들은 새로운 서비스를 준비했습니다. 새로운 비전을 찾고, 피벗할 서비스를 구체화 하며, 디자인과 개발을 밀고 나갔습니다. 4개월만에 ios 버전이 세상에 나왔고, 2개월 동안 앱스토어 심사를 반려 당하며 서비스의 방향성과 포지션, 핵심 가치를 견고하게 다졌습니다. 그리고 2021년 9월 20일, 드디어 심사가 통과됐고, 서비스가 굴러가기 시작했습니다.

개발팀은 저 포함 총 3명이었는데, 출시 직후 ios 개발자분이 퇴사 하셔서 2명 뿐인 개발 듀오가 되었습니다. 우리는 서비스 출시 후 밀려 들어오는 유지보수와 리디자인 작업, 백오피스 개발에 시간을 쏟았습니다. 힘든 시간이었습니다.

날씨가 조금씩 추워질 무렵, 팀에서는 안드로이드 버전에 대한 필요성을 점점 크게 느끼고 있었습니다. 개발 리소스가 부족하단 걸 아는 팀원들은 외주 개발사를 고려했지만, 코드 퀄리티와 제품 퀄리티 측면 때문에 망설였습니다. 사실 안드로이드 버전 개발을 우선순위 1순위로 찍고 달릴 수 있었습니다만 최소 4주에서 6주 정도의 시간을 온전히 안드로이드 개발에 쏟기엔 대표와 PO 입장에서 불안한 마음이 더 컸던 것 같습니다.

저는 11월 1주차 쯤인가 개발을 하다 갑자기 불안감에 휩쌓였습니다. 팀에 안드로이드 버전이 꼭 필요해 보이는데, 있으면 너무나 좋을 거라는 걸 모두가 아는데 선뜻 결정을 내리지 못하는 그런 분위기.

개발 리소스가 부족하단 게 문제의 원인인지 아니면 핑계인지, 정말 단순하게 불안감 때문에 우선순위를 찍고 달리지 못하는 건지 아리송 했었습니다. 이건 굳이 길게 끌며 고민할 문제가 아닌 것 같았습니다.

새로운 액션이 필요했고, 이는 개발팀이 이끌고 싶었습니다. 주말에 스타벅스에서 간단하게 생각을 정리했습니다. 그때 노션에 정리했던 것은 -

• 안드로이드 버전이 꼭 필요한데, 모든 걸 잘하기 위해 필요한 것은 무엇인가
  • 팀원(대표, PO) 설득 / 마음 케어하기 (일정과 리소스에 대한 불안감 최소화)
  • 기존 개발 업무 일정 문제 없이 진행하기
  • 안드로이드 개발에 대한 불확실성 제거
    • 삽질, 학습, 테스트, 개발 환경
  • 개발 잘하기
  • 개발팀 동기부여와 컨디션 관리하기

이것들을 효과적으로 실현하기 위해 했던 고민들과 액션을 공유해보고자 합니다.

1. 작게 시작하기

단순하게 “안드로이드 개발 빨리 잘 해줄게!”라고 할 수 있었음에도 그렇지 못한 이유는 개발팀 조차 일정과 일감 예측에 대해 확신이 없어서 였습니다. 기존 개발 업무도 있고 자칫 큰소리 쳤다가 일정 관리에 실패하면 개발팀 신뢰도와 분위기에 그닥 좋지 않기 때문입니다. 개발팀 리드로서 부담감도 느껴졌구요.

그래서 당장은 개인 프로젝트로 시작했습니다. 아주 가볍게. 팀원들에게도 알리지 않았습니다. 책임과 부담감을 느끼고 싶지 않았습니다. 평일에 꾸준히 저녁 시간을 내 취미 삼아 진행했습니다. 가입 퍼널까지 구현되면 팀에 공유하고 안드로이드 개발 하자고 설득하려 했습니다. 이 기간 동안 저는 느긋하게 즐겼습니다. 개발을 해도 그만 안해도 그만이고, 코딩 안하고 그동안 놓쳤던 문서를 읽을 때도 있었고, 삼천포로 빠질 때도 있었습니다.

그럼에도 한가지 규칙은 지키려고 했는데 “주 단위 목표로 뒀던 정량적 시간은 꼭 채우자” 였습니다.

2. 측정하기

대표와 PO은 일정과 개발 리소스에 대해 불안감을 가지고 있었습니다. 종종 회의때마다 “다 하려다가 이도저도 아니게 되면 어쩌지”라는 말을 했었습니다. 저는 이게 막연함에서 오는 불안감이라 생각했습니다.

저는 정량적인 개발 시간을 측정해 대표와 PO를 설득하려 했습니다. 그러면서 저 스스로도 확신을 가질 수도 있구요. 앞서 말한 주 단위 목표였던 “정량적 시간 채우기”는 이 시간 측정을 위함입니다.

저는 일주일에 최소 12시간을 채우려고 했고, 안드로이드 코드 베이스 + 가입 퍼널 구현까지 총 4주가 걸렸습니다. 정확한 시간으로는 51시간 정도 소요했습니다. (시간 측정엔 https://toggl.com/track/을 사용했습니다.) 이미 안드로이드 개발 경험이 있던 지라 러닝커브는 다소 적었고, 대신 코드 베이스 잡는 것과 최신 안드로이드 트렌드를 읽고 학습하는 데 시간을 쏟았던 것 같습니다.

한명이서 워킹타임으로 열심히 1주일(50시간 내외) 개발하면 가입 퍼널이 나오는데, 이정도면 2명이서 안전하게 4주면 되지 않을까? 스스로 확신에 차서 팀원들에게 공유했고, 설득 됐습니다. 살짝 예상에서 벗어난 게 있다면 정량적인 측정 값으로 예측하고 증명하기 보단 제 스스로 가진 확신에 팀원들이 반응했습니다. 검증보다 먼저 앞장서 나가면 해결되는 문제였나 싶었습니다.

어쨌든 드디어 안드로이드 개발 진행이 결정이 났습니다. 이때가 딱 12월 초였네요.

3. 사용한 스택

개인 프로젝트로 진행할 땐 손에 익숙한 kotlin과 rx로 개발했습니다. 프로젝트 진행이 결정된 후 data binding과 kotlin coroutine / flow에 대해 찾아봤었는데 절대적 코드량을 줄이는 데 도움이 돼보였습니다. 때문에 기존 만들어놨던 코드 베이스를 버리고 새로운 베이스를 깔았습니다.

현재 개발팀은 백엔드를 kotlin + spring으로, 백오피스를 kotlin/js + react + antd로 구현 했습니다. 개발팀은 kotlin으로 통합했을 때 따라오는 장점을 톡톡히 느꼈습니다. (팀원의 소감) 때문에 안드로이드도 최대한 kotlin 환경에 붙어 개발하기로 했습니다.

koin으로 의존성 주입을 받고, ktor와 kotlinx-serialization으로 네트워크 레이어를, kotlinx-coroutine과 kotlin flows로 비지니스 로직을 구현했습니다. kotlin multiplatform에도 욕심이 생겨 ios/android/web 모두 네트워크 레이어를 통합시키려 했지만 아직은 시기상조라 테스트만 해보다가 끝났습니다. 여담이지만 개발팀이 최대한 kotlin에 붙어서 스택을 구성한 이유는 언젠가 안정화될 수도 있는 kotlin multiplatform에 올라타기 위해, 개발팀원들의 개발 환경과 언어를 통합하기 위해서 입니다.

4. 깔끔한 베이스를 깔자

코드베이스

코드 베이스는 중요합니다. 잘 깔려진 코드 베이스는 좋은 예제가 되고 규칙을 가이드 해줍니다. 이는 개발 속도에 직접적인 영향을 주기 때문에, 프로젝트 초기엔 더욱 중요하다 생각합니다. 개발 시작 이후 1주일 정도는 코드 베이스에 시간을 많이 쏟았던 것 같습니다. data binding과 kotlin coroutine / flows를 처음 써보기 때문에 이리저리 실험을 하며 규칙을 만들어 나갔습니다. 모든 Fragment들이 상속하는 BaseFragment는 어떤 모양이어야 하는지, 반복하는 작업(예: 새로운 fragment / view model 만들기)에 코드를 한 줄 이라도 덜 칠 수 있는 방법은 무엇인지, callback과 suspend 중에서 어떤 걸 더 선호해야 할 지, exception은 어떻게 핸들링해야 할지 등. 새로운 코드 베이스와 가입 퍼널을 재구현하며 이정도면 됐다 싶을 정도로 예제와 규칙을 만들었습니다. 충분히 시간을 들이고 신경을 쏟았습니다.

CI/CD

마음 같아선 viewModel만이라도 unit test를 진행하고 싶었지만, 개발 시간이 부족해 메인 화면 viewModel만 unit test를 작성했고, CI에 연동해놓았습니다. 출시 이후 시간이 될 때 언제든지 TDD를 할 수 있도록, 혹은 쉽게 test를 작성할 수 있도록 환경을 만들어놓았습니다.

마지막으로 시간을 조금 더 내 CD와 firebase app distribution을 통한 테스트 환경까지 구축해놓았습니다.

5. 잘 개발하기

개발 일정은 QA 포함 총 4.5주였습니다. 우선순위를 비집고 들어오는 일감 처리를 위한 0.5주, 혹시모를 위험 요소를 대비한 버퍼 0.5주를 제외하고 남은 3.5주를 총 개발 일정으로 잡았습니다. (원래는 이렇게 빡빡하게 일정을 잡으면 안되지만, 상황이 상황인 만큼..) 개발팀은 어떻게 하면 높은 퀄리티의 프로덕트를 3.5주 안에 개발할 수 있을까 고민했습니다.

나름의 전략을 세웠고, 개발을 시작했습니다.

1. 위험 요소는 미리 앞당겨 해결하자.
   1. 개발팀이 한번도 해보지 못한 작업을 먼저 하자. (예: 인앱 결제)
   2. PO와 협의해 최소 기능을 정한 후, 미리 스토어에 릴리즈 하자.
   3. data binding / kotlin coroutine & flows에 대한 경험이 없으니 빨리 로직 연결을 해보자.
2. 핵심 기능 / 기타 기능으로 나누어 개발을 진행해 각 개발자 간 작업 흐름이 겹치지 않도록 하자.
3. 릴리즈 시점에 꼭 필요한 기능이 아니라고 판단되면 과감하게 제외하자.
4. 먼저 뷰를 모두 구현한 뒤에 로직 구현을 시작하자.
5. 자주 테스트하자.

1주차엔 핵심 / 기타 기능으로 카테고리를 나눠 각 개발자가 뷰를 그리기 시작했습니다. 저는 가입 퍼널 뷰를 그렸는데, 이때 코드 베이스 작업과 함께 최소한의 로직 연결을 했습니다. data binding 과 kotlin flows & coroutine에 대한 학습이 이때 이루어졌습니다. 결과물로 튼튼한 코드 베이스와 CI/CD, 간략한 test code, 약 80%의 뷰가 구현됐습니다. 팀원들은 실제 기기에서 개발팀이 구현한 뷰를 볼 수 있었습니다.

2주차엔 PO와 이야기해 첫 릴리즈 일정을 앞당겼습니다. 가입 퍼널이 구현된 시점에 조만간 서비스가 오픈된다는 페이지와 함께 스토어에 정식 릴리즈 하기로 했습니다. 가입 퍼널 로직 구현과 함께 안드로이드 버전 릴리즈로 인한 백엔드/백오피스 사이드 이팩트 처리, 정식 릴리즈 준비를 진행했습니다. 결과물로 가입 퍼널까지 구현된 안드로이드 앱이 스토어에 릴리즈 되었으며, 릴리즈 당일부터 조금씩 안드로이드 유저를 받기 시작했습니다.

3주차엔 PO와 함께 2번째 최소 기능에 대해 정의했습니다. 서비스 핵심 기능이라고 생각되는 것 까지만 구현 후 2번째 릴리즈를 진행하기로 했습니다. 가입 쪽 기능은 이미 릴리즈가 되어 굴러가고 있었기 때문에 개발팀은 메인 기능에만 집중할 수 있었습니다. 앞서 세운 전략대로 개발팀은 지금까지 경험해보지 못했던 기능부터 구현했습니다. 저는 스토어 / 인앱 결제 연동을 먼저 했습니다. 그 후 핵심 기능을 구현하기 시작했는데, 개발 초기에 신경써서 쌓아놨던 코드 베이스와 CI/CD 환경이 이때 빛을 발했습니다. 덕분에 코드를 국수가락 뽑듯 쭉쭉 뽑아냈고, 버그와 디버깅 시간은 적었습니다. 결과물로 앞서 정의했던 최소 기능보다 더 많은 기능을 더 추가해 릴리즈를 성공적으로 진행했습니다.

마지막 주차엔 남은 기타 기능들을 구현하며 에러 로깅과 메일로 들어오는 CS를 처리하는 시간을 가졌습니다.

몸과 머리가 좀 힘들었지만, 결과적으로 개발팀은 안전하게 릴리즈 했고, 우리 팀은 잘 굴러가는 안드로이드 앱을 얻었으며, 몇가지 자잘한 버그를 제외하면 앱에 크리티컬한 문제는 없었습니다.

치열했던 기간

예쁜 burn up chart

버그가 없나봐요

6. 개인적인 노력

프로젝트를 성공적으로 마치고 싶어 개인적으로 했던 노력들 입니다.

1. 매일 테스트
   • 일찍이 CI/CD를 구축해 테스트가 용이했습니다. 그래서 매일 출근할 때 지하철에서 앱을 테스트해보고는 했습니다. 문제가 발견되면 출근 직후에 고치고 개발을 진행했습니다. 누군가는 테스트를 해줘야 하는데, 개발에 집중하다 보면 놓치기 쉽상입니다. 덕분에 릴리즈 직전에 자잘한 버그를 수정 하느라 시간을 빼지 않고 온전히 릴리즈에만 집중할 수 있었습니다.
2. 규칙적인 생활
   • 컨디션을 유지하려 최대한 같은 시간에 자고 일어났습니다. 마음이 급해 하루 밤을 새버리면 2~3일 동안 후유증이 남기 때문에, 밤새는 건 최대한 피하고 릴리즈 직전에만 늦게 잤습니다.
   • 집중이 안될 땐 30분 단위의 뽀모도로를 사용했습니다.
   • 밥은 제때 제때 먹었습니다. 회의/개발 시간을 제외하면 머리를 비울 수 있는 시간이 점심/저녁 시간 밖에 없었는데, 이때 같이 밥먹는 팀원들에게 하소연도 하고 힘든 것도 티를 냈습니다. 팀원들이 응원해주면 나름 마음의 위안이 되더군요.
3. 시간날 때마다 타자를 치자
   • 정확하게 예측할 순 없지만, 릴리즈에 필요한 최소한의 코드 라인 수는 어디엔가 정해져 있습니다. 이 라인 수를 미리 미리 채워 놓으면, 릴리즈 직전에 자잘한 버그와 각종 문제에 휘둘릴 확률이 줄어듭니다. 사소한 작업을 따로 뽑아놓고, 시간이 날 때마다 작업을 했었습니다.
4. 빌드 횟수 최소화
   • 로직 구현 때 개발 속도를 최대한으로 내기 위해 구현을 모두 끝내놓고 빌드를 했습니다. 안드로이드 빌드 시 약 10~30초 정도를 소모하는데, 프로젝트 일정이 빠듯한 만큼 빌드 시간이 아까웠습니다. 바보 같은 행동일 수도 있지만, 하루 50번 * 빌드 당 30초 정도라고 가정하면 약 30분의 시간이 빌드 기다리는 동안 낭비됩니다. 이 시간을 아낀다면 릴리즈 전날 밤샐 확률이 줄어들지 않을까? 라는 생각이었습니다.
5. 구현할 건 미리 설계해놓자
   • 종종 출근해서 사무실 올라가기 전에 카페에서 당일에 구현해야 하는 기능을 미리 설계하고 들어갔습니다. 미리 생각을 정리하고 개발에 들어가면 코드 퀄리티에 큰 영향을 주는 듯한 느낌입니다.

7. 팀원들의 호응

개발팀을 제외한 다른 팀원들은 개발하는 동안 정말 많이 응원해주셨습니다. 개발팀이 열심히 하니 다른 팀원들도 같이 열심히 해주는 느낌을 받았습니다. 앱이 릴리즈 됐을 때는 다들 엄청 기뻐했습니다. 대표와 PO에게는 서비스 성장에 아주 큰 장벽 하나가 없어진 것이고, 마케팅 팀은 안드로이드 유저를 데려올 수 있는 가능성과 ios보다 더 정확한 마케팅 전환 지표를 얻었습니다. 명확하게 눈에 보이는 성과라 팀 분위기도 더욱 좋아진 느낌입니다.

개발팀이 팀 전체에 이정도의 영향력을 낼 수 있다는 게 기뻤고, 정말 뿌듯했습니다.

8. 책읽기

기술적인 지식보다는 프로젝트 진행 / 팀 운영 / 자기관리에 대한 지식이 많은 도움이 되었습니다. 개발 기간 동안 다시 꺼내봤던 책들입니다.

1. 익스트림 프로그래밍
2. 함께 자라기 - 애자일로 가는 길
3. 클린 코드
4. 실용주의 프로그래머

9. 앞으로

그냥 일과 코딩 많이하면 되는 거 아니야? 라고 생각할 수도 있습니다. 하지만 능동적으로 문제 해결에 임하고 적극적으로 나서고 이끌며 성공적인 결과를 내는 건 동기부여, 성취, 자기효능감 측면에서 하늘과 땅차이라 생각합니다.

글 처음에 얘기했 듯 저희 팀은 코로나로 인해 힘든 시간을 겪었고, 긴 시간동안 버텨왔습니다. 그리고 블랙스완을 통해 조금씩 성취와 작은 성공을 쌓아나가고 있습니다.

이번 안드로이드 릴리즈는 오랜만에 온전히 개발팀에서 이뤄낸 성취라 더욱 뜻깊습니다.

앞으로도 우리 개발팀에서는 문제 해결에 더욱 적극적으로 뛰어들어 그 누구보다 삽을 먼저 들고 땅을 팔 생각입니다. 삽질에 의미가 있었다면 종종 이렇게 글을 올려보겠습니다.

그리고 이 작은 경험이 누군가에게 도움이 되면 좋겠습니다. 앱도 써봐주시면 감사하겠습니다.

원문: https://blog.passionoil.co/refrigerator-vs-notion/ 2021년 1월 22일에 작성된 글 입니다.

사무실 냉장고와 노션의 공통점 by 오월

사무실 냉장고와 노션의 공통점이 하나 있습니다. 무언가 썩기 좋은 환경입니다. 사무실 냉장고에 넣어둔 음식을 누군가 관리하지 않게 된다면 말라 미틀어지고, 심한 경우 썩기도 합니다. 먹지도 못하는 음식이 공간을 차지하게 된다면 다른 사람이 이용하지 못하는 불편함이 있고 미관상 그리고 위생상 좋지 않습니다. 노션, 거시적으로 팀에서 관리하는 문서 혹은 문서 도구도 동일합니다. 쌓아두기만 한다면 문서가 썩어 필요할 때 사용하지 못하는 경우가 있고 필요한 문서를 찾기 어려워집니다. 그래서 문서가 썩기 전에 감지할 수 있는 감각을 키우고 환기 시킬 수 있는 능력을 키우는 것이 목표입니다.

이 글은 여러 팀에서 노션 사용 경험을 바탕으로 작성 하였지만 노션 사용법이 아닌 문서 관리방법에 대하여 이야기 합니다.

문서가 썩으면 냄새가 고약해요~

문서가 썩었다고 판단할 수 있는 경우는 크게 4가지 입니다. 제목만 있는 문서, 깊숙이 있는 문서, 이해할 수 없는 문서, 업데이트가 없는 문서

제목만 있는 문서

제목만 있는 경우는 냉장고에 빈 병, 빈 봉투, 빈 용기 혹은 그것들에 남아있는 음식물과 비슷합니다. 누군가 정리하기 전까진 공간만 차지합니다. 필요 없거나 내용이 없는 문서가 많아지는 경우 필요없이 눌러서 찾아봐야 하는 요소들이 많아집니다. 입사 온보딩, 업무를 파악하는 과정에서 제목만 있는 영양가 없는 문서는 불필요한 시간 자원을 소모 시키고 피로감을 줍니다. 필요한 정보에 키워드를 검색하는 경우에도 내용이 없는 문서가 노출돼 문서를 찾는데 불필요한 시간을 소모시키는 문제가 발생합니다.

깊숙이 있는 문서

냉장고 깊숙하게 있는 음식은 내용물이 무엇인지 알 수 없고 썩기 좋습니다. 깊숙이 있는 문서안에 있는 문서 혹은 여러 군데 흩어져 있는 문서입니다. 깊숙이 있는 문서는 특별한 경우가 아니라면 다른 팀원이 볼 수 있는 경우가 적습니다. 문서를 한번도 보지 못했다면 문서의 내용이 필요한 경우에 문서를 이용할 수 없기에 문서의 역활을 하지 못합니다. 이로 인해 비슷한 내용의 새로운 문서가 생기고 모두에게서 잊혀질 수 있습니다.

이해할 수 없는 문서

냉장고 속 정체를 알 수 없는 음식 먹을 수 있을까요? 문서는 정보를 전달하는 기능을 가지고 있습니다. 하지만 문서를 읽는 사람이 정보를 이해할 수 없다면 문서의 기능을 상실했다고 볼 수 있습니다.

업데이트가 없는 문서

누가 언제 넣었는지 모르는 음식, 유통기한은 한참 지났습니다. 문서는 업데이트가 없는 경우 정보가 잘못되었을 수 있습니다. 과거에는 적용 가능하더라고 현재에는 적용 불가능한 경우가 있습니다. 물론 모든 문서에 업데이트가 자주 있을 필요는 없습니다. 썩지않고 숙성해야 좋은 문서도 있고 먼 미래에 적용해도 상관 없는 통조림 같은 문서도 있습니다. 하지만 자주 열어봐야 하거나 변경해야 하지만 그렇지 않은 문서는 썩은 문서입니다.

썩지 않게 관리하기

그럼 어떻게 해야 문서를 썩히지 않고 싱싱하게 유지할 수 있을까요?

문서를 작성하는 경우에는 기존 문서 중 동일한 내용이 있는지 찾아봅니다. 해당 문서가 있는 경우 문서를 업데이트해야 합니다. 내용 뿐만 아니라 썩기 좋은 위험 요소들도 함께 수정해야 합니다. 문서에 라벨링과 카테고리 기능이 있다면 최대한 활용하고 없는 경우 비슷한 항목의 문서들의 링크를 모아둔 문서를 만드는 것도 방법입니다. 문서의 내용은 다른 사람도 쉽게 수정 가능한 형식으로 작성해야 하고 수정가능한 권한 등을 확인해야 합니다. 문서 도구에서 검색 기능이 제공되는 경우 핵심 키워드로 검색 했을 때 해당 문서가 노출 되는지 확인할 필요도 있습니다.

냉장고도 주기적으로 청소하고 썩을 것 같은 음식을 버려줘야 합니다. 동일하게 주기적으로 필요 없는 문서는 삭제하고 동일한 문서들을 통합하는 등 문서들을 점검하는 시간을 가져야 합니다.

사무실 냉장고 속 음식은 넣어둔 사람이 관리해야 하지만 썩은 음식이나 빈 병, 빈 봉투, 빈 용기는 모두가 함께 관리하면 위생적이고 쾌적하게 이용할 수 있습니다. 문서도 작성한 사람이 주기적으로 관리 해주는 것이 제일 좋습니다. 하지만 모든 팀원의 관심과 참여는 문서 관리에 많은 도움을 주고 업무 비용을 절약할 수 있습니다.

노션은 글을 작성하는 재미는 있습니다. 하지만 남용할 수 있는 위험 요소도 많은 것 같습니다. 그래서 노션을 예쁘게 쓰는 것도 좋지만 의미있게 잘 쓰는 것도 중요하다고 생각합니다. 문서는 협업간 눈높이를 맞춰주는 도구입니다. 과거의 자신과 현재의 자신의 눈높이를 맞춰주고, 타인이 모르는 자신의 지식을 빠르고 제약없이 전달해 눈 높이를 맞춰 줍니다. 그래서 문서 / 노션을 모두 함께 잘 활용하면 좋을 것 같습니다.

읽어주셔서 감사합니다.

원문: https://blog.passionoil.co/our-own-daily-meeting/ 2020년 1월 16일에 작성된 글 입니다.

우리만의 데일리 미팅 by 오월

열기는 매일 일정한 시간에 데일리 스크럼을 진행하고 있습니다. 개발팀은 애자일 방법론을 도입중이며 이 중 데일리 스크럼을 팀 전체로 확장해서 진행하고 있습니다. 문제는 팀 전체가 스크럼에 맞춰 업무를 진행하지 않거나 힘들고 업무 방식 또한 달라 정석적으로 적용하는데 어려움이 있습니다. 그래서 기본적인 방식과 규칙을 따르고 데일리 스크럼의 목적(Goal)과 세부 규칙은 저희만의 방식으로 진행하고 있습니다. 그럼 2021년 01월 기준의 데일리 스크럼을 소개하겠습니다.

언젠가 지인과 점심을 먹고 회사에 돌아왔더니 한 팀원이 “미팅 다녀오신건가요?” 라고 물었습니다. “아뇨, 그냥 가볍게 점심 먹은 겁니다.” 이라 답 하였고 그분은 “그게 미팅 아닌가요?” 라고 되물었습니다.

저희 데일리 미팅에서는 업무적인 이야기만 할 필요는 없습니다. 궁극적인 목적은 크게 2가지로 팀원들간에 유대감 형성과 협업간 위험요소 탐지에 있습니다. 단순한 업무보고의 목적이라면 오전에 슬랙채널이나 노션 등에 기록해서 쉽게 해결할 수 있습니다. 하지만 저희는 함께 문제를 해결하고 발전하는 팀이기 때문에 서로가 컨디션을 파악하고 자주 소통할 필요가 있습니다.

매일 같은 시간, 같은 장소, 다른 이야기

매일 10시 반에 데일리 미팅을 진행합니다. 데일리 미팅으로 하루를 시작하며 같은 시간에 같은 장소에서 하는 것을 목표로 합니다. 시간이 불규칙해 질 경우 지속성을 잃을 위험이 있습니다.

서서 최대 15분 이내

모두 일어난 상태에서 최대 15분을 목표로 진행합니다. 데일리 미팅 참석자 수와 컨디션에 따라 최대 시간을 정하고 시작합니다. 서서 하는 이유는 길어지지 않게 하는 장치이며 서로의 얼굴을 보는 목적을 가지고 있습니다. 서로가 질문이나 답변은 가능하지만 길어지는 경우 회의 일정을 따로 잡아서 진행해야 합니다.

3가지를 보고가 아닌 공유합니다.

1. 지난 데일리 미팅 이후 진행한 업무
2. 다음 데일리 미팅까지 진행할 업무
3. 발생한 문제 혹은 발생 가능한 문제

구체적인 업무들을 말하게 된다면 다른 팀원은 이해할 수 없거나 집중도를 낮출 수 있습니다. 그렇게 때문에 모두가 이해 가능한 에픽이나 상황 위주로 공유합니다. 공유할 업무가 없어도 상관없습니다. 전날 컨디션이 좋지않아 업무를 진행하지 못해서 발생한 문제를 공유하는 것 혹은 개인적인 이야기를 하는 것 만으로도 충분합니다. 개인적인 이야기나 자신의 컨디션을 공유하는 것도 좋습니다.

안좋은 예) 새발: 오늘 저는 우리 웹 서비스를 docker로 묶고 fargate를 연동해 좀 더 좋은 서버 배포 / 관리 환경을 만들 예정입니다.

좋은 예) 오월: 안드로이드 마이페이지 UI를 그리는 작업을 하고 있습니다. 작업에 어려움을 겪고 있습니다.

스크럼 마스터

스크럼 마스터는 데일리 미팅을 진행하는 사람입니다. 데일리 미팅 시간이 되었을때 사람들을 모으고 스크럼의 진행 순서와 시간을 정합니다. 순서는 시계방향, 반시계방향, 다음 사람 지목하기, 자발적으로 하기 등으로 정할 수 있고 시간은 최대 15분 이내로 정합니다. 한 사람이 너무 많은 시간을 말하는 것을 조정하는 것도 스크럼 마스터의 역활입니다. 스크럼 마스터는 누구나 할 수 있으며 다양하고 재미있는 방법으로 스크럼 마스터를 정할 수 있습니다.

재미있게 시작하기

데일리 미팅에서 재미있는 요소들을 추가해서 집중도를 높이고 분위기를 좋게 만들 수 있습니다. 주말에 무슨일을 했는지 말하기, 신년 덕담하기, 기분점수 말하기 좋아하는 음식 말하기, 팀원 칭찬하기 등으로 팀원들과 더 많은 소통을 할 수 있는 기회를 줍니다.

앞으로 저희만의 데일리 미팅을 만들기 위해 회고하고 개선하려고 합니다. 궁금한 점이나 개선할점, 좋은 사례를 알려주시면 좋을거 같습니다. 읽어주셔서 감사합니다.

원문: https://blog.passionoil.co/how-the-dev-team-gets-things-done/ 2020년 12월 9일 작성된 글입니다. IT 조직 경험이 없는 내부 팀원들에게 공유하기 위해 작성된 글 입니다.

개발팀이 일을 매듭 짓는 방법 by 새발

프로젝트 시작 후 기획과 디자인/개발이 끝나면 QA, 배포 단계를 거쳐 유저에게 전달됩니다. 1년 넘게 같이 협업하면서 QA, 배포에 대해 대략적으로 얘기만 했지 제대로 알려드린 적이 없는 것 같아요.

최근 디자이너 심옹과 마케터 이든이 합류하고, 팀 전체 구조가 바뀌면서 개발팀의 업무 형태도 많이 달라졌습니다.

몇달 전만 해도 “퀄리티 보다는 속도” 중점으로 1주일 단위 업무 계획과 실행(스프린트), 그리고 커뮤니케이션을 최소화한 상태에서 기능을 빠르게 올린 후 터져나오는 문제를 실시간으로 해결을 하는 방식이었습니다.

지금은 적극적인 커뮤니케이션, 예측 가능한 계획과 실행, 위험 관리 등 속도를 조금 포기하고 디테일과 안전성을 확보하려 노력하고 있습니다.

때문에 QA와 배포 대한 중요도가 높아졌어요. 각각에 대해 한번씩 짚어보겠습니다. 여기에 더해 개발팀에서 요새 자주 얘기하는 “코드 퀄리티”에 대해서도 얘기해 보겠습니다.

QA

개발팀에서 “배포 전 QA를 해야 서비스가 터질 확률이 줄어든다”라는 말을 많이 했었습니다. 하지만 빠른 배포 일정으로 QA가 없거나 간단한 테스트만 거치고 출시하는 일이 잦았어요. 더불어 서비스가 터지고 버그가 발생하는 일이 많았습니다.

QA는 “Quality assurance”의 약자로, “품질 보증”을 의미합니다. 즉 개발한 기능과 제품이 우리가 정의한 수준 이상의 품질을 보증할 수 있도록 배포 이전에 각종 테스트와 검수 작업을 하는 겁니다.

좀 더 구체적으로 말하자면 기능 테스트와 더불어 기획한대로 결과물이 나왔는지, 기획 상 빈틈은 없는지, 디자인 상 이슈는 없는지, 개발팀에서 놓친 빈틈은 없는지 등 품질 보증을 위해 전반적인 검수를 하는 작업입니다.

QA 진행에도 시간이 들어가고, 수정 사항이 나오면 이를 수정하는데도 시간이 들어갑니다. 때문에 배포 일정이 늦춰지고, 팀 간 불화도 생겨 나죠. 개발팀에선 QA 일정을 개발 일정에 포함 시켜 일정 미루기와 불화를 최대한 피하려고 합니다.

QA는 업무 진행을 평가할 수 있는 최소한의 기준이다.

열기 팀에서 개발팀과 업무를 진행할 때, 기획/디자인/개발 이 세 파트가 서로 맞물려 진행됩니다. 각자 다른 파트의, 각자 다른 사람이 모여 하나의 그림을 그려 나갑니다. 업무에 참여한 팀원들 모두 같은 그림을 같이 그리고 있다면, QA 상 문제가 발생할 확률이 현저히 떨어지게 됩니다. 팀원들이 예측한 범위 내의 결과물이 나오니까요. 개발팀에서 기능 테스트만 잘 진행하면 됩니다.

만약 팀원들이 각자 생각하는 그림을 각자 그리고 있다면 예측치를 벗어난 결과물이 나옵니다. 기획과 다른 방향으로 구현된 기능에, 디자인도 잘 반영되어 있지 않고 심지어 너덜너덜 거리는 결과물이 말이죠. 당연히 QA 상 문제가 많이 튀어 나오고, 일정이 밀리게 되겠죠.

QA는 업무 초반 기획 단계에서부터 많은 영향을 받습니다. 그리는 그림이 팀원들에게 충분히 얼라인 되고, 깊게 생각해 디자인/개발 작업 이전에 빈틈을 찾고, 일정에 차질이 없다면 QA 단계에서 문제가 발생할 확률이 적습니다. 때문에 QA는 디자인/개발팀만의 전유물이 아니며, 참여하는 팀원들 모두가 QA에 영향을 주게 됩니다.

결국 “QA가 예측한 범위 내에서 문제 없이 잘 진행되었다”는 “프로젝트가 시작부터 끝까지 별탈 없이 잘 진행되었다”라는 최소한의 업무 평가 기준을 제시하게 됩니다.

QA를 디자인/개발팀에서 자체적으로 진행하고 있어 피부로 와 닿지 않겠지만, 참여한 모든 팀원의 영향을 받으니 꼭 신경써주시면 감사하겠습니다. 🤤🤤🤤🤤

현재 어떻게 QA를 진행하고 있나요?

몇 주 전까지는 러프하게 필요할 경우에만 QA를 간단하게 진행했지만, 지금은 새로 추가된, 수정된 모든 기능들에 대해 QA를 진행합니다.

현재(2020-12) 시점에서 디자인/개발팀과 협업하는 프로세스는 다음과 같고,

1. 기획 및 아이디에이션
2. 상세 일감 및 일정 산정
3. 디자인 및 개발
4. QA
5. 배포

3번째 단계(디자인 및 개발) 완료 시 디자인/개발팀 내에서 자체적으로 진행하고 있습니다.

기획 단계에서 나온 유저 스토리보다 좀 더 기능에 포커스를 맞춘 유저 스토리를 재작성하고, 이를 노션에 테이블로 만들어 테스트 합니다. (심옹이 많이 도움을 주셨어요) 테스트 후 수정 사항을 반영하고 배포 단계로 넘어가게 됩니다.

배포

배포는 추가/수정한 기능을 앱/웹/서버에 반영하는 작업입니다.

우리가 만든 것들이 실제 유저에게 적용되는 시점이며, 개발 할때는 언제나 예측하지 못한 위험이 도사리고 있기 때문에 위험도가 높은 작업입니다.

앱

크클 앱(ios/android) 배포는 항상 심사 / 업로드 시간이 걸립니다.

애플 앱스토어는 애플에서 우리 앱을 심사합니다. 심사에 통과해야만 앱을 배포할 수 있습니다. 배포 후 앱스토어에 반영되는 시간이 어느정도 있고, 반영되면 유저가 업데이트해야 우리가 추가/수정한 기능이 반영됩니다.

구글 플레이 스토어는 앱을 심사하지 않지만, 스토어에 반영되는 시간이 꽤 있고, 유저마다 이 반영 시간이 다릅니다. 대략 1시간 내지 많게는 2일 정도 까지라고 느껴지네요. 이 또한 유저가 앱을 업데이트 해야 우리가 추가한/수정한 기능이 반영됩니다.

앱 배포 시 최종적으로 스토어 반영까지 시간이 들기 때문에 배포 후 문제가 터질 경우 다시 반영하는데까지 시간이 소요됩니다. 때문에 앱 배포 시에는 QA가 정말 중요합니다.

앱 배포는 해달이 자동화하여 개발자의 번거로움을 줄여주셨습니다. 원래는 손으로 업로드 해야하거든요. (자동화 배포를 CD, Continuous deployment라 부릅니다.)

ios는 코드 반영 시마다 앱 심사 전 단계로 앱스토어에 업로드 합니다. android는 코드 반영 시마다 테스트 단계로 구글 플레이 스토어에 업로드 합니다.

웹

리뉴얼 하고 있는 웹사이트 기준으로 말씀드리겠습니다. – https://gathering.creatorclub.kr , https://creatorclub.kr

앱 배포와는 다르게, 수정 시 바로 바로 배포 가능합니다. 개발팀에서 우리 웹 서버에 코드를 반영하는 시간만 있을 뿐 입니다.

웹 배포 또한 오월이 자동화해주셨습니다. 코드 반영 시 선택적으로 자동 배포됩니다. 평균 반영 시간은 5분 내외입니다.

서버

웹과 마찬가지로 수정 시 바로 배포 가능합니다. 서버 배포도 오월과 새발(나)이 자동화 해주셨습니다. 코드 반영 시 선택적으로 자동으로 배포됩니다. 평균 반영 시간은 10분 내외입니다.

개발팀에서는 배포를 왜 두려워할까요?

“배포 시 문제가 터질 수도 있다”라는 것 때문에 개발팀에서 배포를 두려워 합니다. QA를 충분히 거치더라도 빈틈이 있을 수 있습니다. 심지어는 추가/수정한 기능이 건드리지 않은 기능에 영향을 주기도 해요.

그리고 문제가 터질 경우 기존 작업 계획에 영향을 주기 때문에 위험 부담을 최대한 줄이려는 노력을 하고 있습니다.

왜 점심에 배포하려고 하던게 다음 날로 밀리죠?

주로 타이트한 일정을 잡았을 때 많이 발생하고, 배포 직전에 문제점이나 빈틈을 발견해서 최대한 고친 후 배포를 하기 때문입니다.

코드 퀄리티

제가 아마 코드 퀄리티라는 말을 자주 했었을 겁니다. 코드 퀄리티는 말 그대로 코드의 퀄리티, 품질을 의미합니다.

우리가 만드는 서비스는 모두 “코드”로 이루어져 있습니다. 개발자가 하는 일은 코드를 추가하거나 수정해 기능을 구현해내는 것 입니다.

문제는 코드를 추가하고 수정하는 작업은 단순 타자를 쳐서 뭔가를 적는 게 아닌, 꽤 복잡한 작업이라는 겁니다. 코드는 다른 코드와 서로 얽혀 있기 때문에, 코드를 추가하거나 수정할 때마다 얽힌 코드에 문제가 없는지, 더 나아가 서비스를 구성하고 있는 데이터나 연동된 서비스에 문제가 없는지 지속적으로 체크를 해야합니다.

때문에 코드 퀄리티가 중요해집니다. 작성해 놓은 코드를 개발자들이 지속적으로 읽고 수정하기 때문에, 코드가 정리되어 있지 않으면 그만큼 작업 시간도 오래 걸리고, 버그 발생 확률도 높아집니다.

코드 퀄리티가 떨어지는 잘 정리되어 있지 않은 코드 비유:

코드 퀄리티가 높은 잘 정리되어 있는 코드 비유:

코드 퀄리티는 개발팀 말고는 아무도 모른다.

코드 퀄리티 관리 없이 기능 개발을 치고 나가면 어느 순간 개발팀 생산성이 저하되고 버그가 자주 발생합니다. 이때가 되면 개발팀은 코드나 기능을 리뉴얼 하거나 소위 “리팩터링”이라고 부르는 코드 정리 작업을 진행해야 합니다. 기능 개발과는 별개로 말이죠.

때문에 개발팀은 팀 전체의 우선순위와 긴급도, 요구사항 스펙을 보고 이번 기능 개발 때 코드 퀄리티를 챙길지 말지 생각해 상세 일감과 일정을 짜게 됩니다.

2개월 전쯤에 백조에게 “개발팀이 서비스 개발 일정 권한을 많이 가져가고 싶다”라고 했고, 허락을 받았습니다. 개발팀에서 앞서 언급된 QA, 배포, 코드 퀄리티까지 적당히 생각해서 일감과 일정을 가이드 드리고 있습니다. 혹여 정말 일정이 급한 경우에는 꼭 어필해주세요. 같이 얘기를 해봅시다. 🤤

현재 개발팀에서는 이렇게 코드 퀄리티를 관리하고 있어요.

코드 퀄리티 관리는 QA와 비슷하게 프로젝트 시작 단계에서 부터 시작합니다. 개발자 스스로가 기획, 아이디에이션 단계에 적극 임하지 않으면 요구 사항을 정확히 파악하지 못하며 이는 일감/일정 산정에 악영향을 주게 됩니다. 일정 막바지가 되면 이런 저런 문제가 터져나오고 결국 낮은 퀄리티의 코드로 일정을 최대한 맞추려고 하겠죠.

비슷한 얘기지만 일정 산정에 있어서도 관리가 필요합니다. 우선순위와 긴급도에 따라 달라지겠지만, 타이트한 일정은 낮은 코드 퀄리티를 유지할 수 밖에 없습니다. 일정이 타이트한 만큼 개발자가 설계하고 생각하는 시간이 적어지기 때문입니다.

개발팀 내부에서 서로의 코드를 리뷰해주려 노력하고 있습니다. 급할 땐 못하고 넘어가지만요🌝. 이와 함께 코드 작성에 대한 규칙, 앱/웹/서버 파트 별로 잡힌 아키텍쳐와 철학을 개발팀 내에 지속적으로 얼라인 하고 있습니다.

많은 도구와 방법들이 있지만 제일 효과적인 방법은 코드 퀄리티, 구조, 개발 철학에 대해 팀 내에서 많이 얘기하는 게 가장 좋은 방법인 듯 합니다. 저랑 해달만 있었을 땐 기능 개발만 하다가 코드에 대해서 주관이 뚜렷한 오월 합류 이후로 코드 자체에 대해서 얘기를 많이 하고 있거든요. 대화로 심어진 작은 씨앗이 몇 주 내 반영 되기도 합니다.

결론

QA, 배포, 코드 퀄리티에 대한 지식이 있다면 개발팀과 커뮤니케이션 하는데 많은 도움이 되실 겁니다. 최대한 쉽게 썼지만 어려운 부분이 있다면 언제든지 말씀해주시면 감사하겠습니다.

원문: https://blog.passionoil.co/code-ownership/ 2020년 11월 30일 글 입니다.

그때는 맞고 지금은 틀리다 - 코드 오너쉽 by 새발

난 XP(extreme programming)을 좋아한다. 오랜 생각인 “개발은 도구다”를 극대화할 수 있는 게 바로 XP라서.

xp에서는 여러 실천법과 규칙을 제시 하는데, 그 중 코드와 프로덕트에 대한 오너쉽을 개발팀 전체가 가져가는 collective ownership 이 앞서 말한 생각을 극대화 해주는 중요 포인트다.

현재 크클 개발팀은 3명이며, 이번 해 7월 까지는 2명이었다. 팀이라고 부르기 애매한 규모다. 때문에 개발 문화와 프로세스는 개발팀 리드인 내 취향이 많이 묻었다. 코드 오너쉽에 대해서도 내 취향이 두드러졌다. 앞서 말한 “개발은 도구다”라는 생각은 자연스레 “크클 개발팀은 앱/서버/웹 넘나들며 개발할 수 있어야 한다”로 이어졌다. 좋은 팀원들 덕에 내 생각은 큰 무리 없이 개발팀에 적용됐다. 그리고 크클 개발팀의 강점으로 자리잡았다. 백조(대표)도 나름 개발팀을 자부하는 듯 했다. 앱 출시 후 1년간은 그렇게 큰 문제가 없었다.

크클 앱은 퀄리티를 낮추는 대신 굉장히 빠르게 개발되었다. 기억으로는 2019년 8월 말 쯤 기획과 디자인을 시작했고, 10월 초~중순 쯤 첫 버전을 릴리즈 했다. 워드프레스로 만들어져 있던 크클 웹사이트를 유지하며 새로운 DB와 서버, 새로운 앱을 개발했다. 개발 시작은 혼자 했고, 개발 중간에 짱짱 개발자 “해달”이 합류했다. 첫 릴리즈 약 한달 후가 되어서야 스프린트를 도입 했고 스프린트 주기는 1주일이었다. 평균 1.7주에 한번 정도 크고 작은 릴리즈를 진행했다.

1년이 지나 2020년 8월이 되었다. 퀄리티나 버그 발생 빈도, 관리자 사이트가 좀 아쉬웠지만, 릴리즈 빈도는 만족스러웠다. 일정과 버그, 유저 CS말고는 평화로웠다. 그런데 갑작스럽게 그동안 조용히 쌓이던 기술 부채, 주로 코드 복잡도가 개발팀의 발목을 낚아챘다. 깊이를 알 수 없는 물탱크에 물을 계속 붓다가 어느 순간 물이 넘쳐서 도저히 막을 수 없는 그런 느낌이었다. 다행인 건 넘치는 물이 익사할 만큼은 아니라는 것.

그리고 그제서야 부랴부랴 리뉴얼과 리팩터링을 진행했다. 새로운 피쳐 개발과 유지보수와 함께 해야했기 떄문에 진행이 더뎠다. 2달 정도가 지난 지금 약 40%정도의 중요한 기능들을 리팩토링, 리뉴얼 했다. 아마 내년 1분기 내로는 끝나지 않을까 싶다.

높은 코드 복잡도가 가져다 주는 악영향은 매우 크다. 일정 예측 실패나 버그 발생 빈도를 높이는 것도 높이는 거지만, 개발자의 의욕을 낮추고 두려움을 키우는 게 제일 문제라 생각한다. 빠르게 첫 버전을 릴리즈해야 했기에 크클 코드 베이스는 그렇게 좋지 않았다. 서버 구조도 큰 신경을 못썼고, 워드프레스로 만들어진 기존 사이트를 새로운 앱/서버와 함께 운영해야 해서 각 시스템 사이의 간극을 맞추기도 어려웠다. 복잡한 코드 베이스와 환경에서 빠르게 기능을 치고 나가야 했다. 서비스 상에서의 비지니스 로직이 정립되지 않아 기능에 대한 룰도 자주 바뀌었다. 새로운 기능을 릴리즈 하면 그 다음 기능을 개발하는데 다시 몰두 했다.

위 상황에서 리팩터링할 시점을 잡지 못한 게 근본적 원인이다. 리팩터링은 사치라고 생각했고, 그저 새로운 기능 개발에만 매달렸다. 그땐 이 생각이 맞았고 지금은 틀렸다.

맨 처음 언급한 collective ownership의 가장 큰 장점은 개발팀 전체가 코드와 프로덕트에 대한 오너쉽을 모두 가져가 개발팀 누구나 기능 개발과 유지보수를 할 수 있도록 하는 것이다. 빠른 기능 개발에 대한 은탄환 같이 보인다. 내 실수이기도 하지만, 여기서의 가장 큰 맹점은 “코드, 서비스, 개발 환경에 대한 품질 관리”가 전제가 되어있어야 한다. 이는 xp의 다른 실천법에도 언급되고 관리된다. 예를 들어 TDD, CI, 코드 디자인 개선 등. 나는 “빠른 개발, 높은 릴리즈 빈도, 개발은 도구다”라는 생각에 갇혀 이것들을 등한시 했다.

이제는 챙겨야 하고, 부랴부랴 챙기고 있지만 문제는 개발팀의 프로세스와 문화에 녹아들 때 까지는 시간과 비용이 들어간 다는 것. 그리고 계속 새로운 기능 개발을 치고 나가야 한다는 것. 동시에 두가지를 하기엔 아직 개발팀은 작고 소중한 자원이다. 묘수가 필요하다.

묘수라고 하기엔 너무 간단하지만, 개발팀에서는 collective ownership을 유지한 채 프로젝트 별로 약한 code ownership을 가져가도록 했다. 현재 웹/앱/서버 이렇게 총 3개의 프로젝트를 각 개발자가 하나씩 들고 갔다. 오월은 웹을, 새발(나)은 서버를, 해달은 앱을.

각 프로젝트에 대한 코드 오너쉽을 가지면 아래와 같은 역할을 맡게 된다.

1. 해당 프로젝트에 코드 복잡도를 관리하고 구조와 방향성에 대한 권한을 제일 크게 가진다.
2. 프로젝트에 리팩터링이나 리뉴얼이 필요할 경우 일감 범위와 일정을 조절할 수 있다.
3. CI/CD, 자동화, 개발 환경 개선, TDD나 QA등 등 품질을 높일 수 있는 여러 도구들을 도입할 수 있다.

러프하게 2달 정도 시행했지만 코드 품질과 구조가 굉장히 깔끔해지고 있다. 당연하게도 릴리즈 빈도는 줄어들었다. 조금 불안했지만 좋은 트레이드 오프라 생각했다. 크클 개발팀은 앞으로 더 많은 기능들을 탄탄하고 적은 비용으로, 적은 스트레스로 개발할 수 있을 것이다.