스타트업에서는 비즈니스에 우선 순위가 높다보니 개발 생산상에 대한 고민을 많이 할 수 없는 환경일 수도 있는데 그래도 비즈니스 지향점을 가지고 가돼 개발자의 문화, 환경, 생산성에 대해서도 고민해 조직내에 여력이 되면 틈틈이 내재화시킬 요량으로 고민한 내용을 정리할 겸 기술해 봅니다.
사용하지 않는 기능에 대한 낭비
비즈니스의 문제 의식을 통해 지금 있는 제품을 더 잘하고 싶고, 더 시장 변화에 유연하게 대응하고 싶기도 하고, 더 자주 시장에 제품을 투입하고도 싶다. 더 다양한 것을 시도하고 싶고 고객 늘리고 연결하고 싶으며 사용해야 할 곳에 돈을 사용하고 싶은게 인지상정이다.
하지만, 2002년 5월에 개최된 The XP 2002 Conference에서 Standish Group의 회장인 Jim Johnson의 기조 강연 "ROI, It's Your Job"에서 소개되었는데, 제품을 위한 만들어진 기능의 64%가 거의 사용되지 않는다고 한다.
마이크로 소프트에서 실험을 다룬 논문에서도 테스트된 아이디어의 1/3만 성공했고 넷플릭스에서는 아이디어 90%가 실패를 했고, 아마존은 신규 기능의 성공률은 50% 미만이라고 한다. 기능은 유용하다고 생각했기 때문에 만들어졌지만, 많은 도메인에서 대부분의 아이디어가 중요한 지표를 개선할 수는 없다는 사례가 많다.
사용하지 않는 기능에 대한 낭비이다. 스티브 맥코넬(Steve McConnell)은 요구 기능의 실수를 릴리즈 후에 수정하는 비용은 요구 단계에서 수정하는 것에 비해 10배부터 100배 걸린다고 한다. 성공할지 실패할지를 구분이 모호한 아이디어의 개발 규모를 처음부터 크게 하는 것은 낭비다. 그래서 소프트웨어 제품을 런칭하거나, 요구 기능을 순차적으로 릴리즈를 반복하면서 추가 되었던 것들은 실제로 얼마나 비즈니스와 고객에게 가치가 있었는지에 대한 고민을 많이 해봐야 한다.
코드의 품질과 비즈니스 영향도
"Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases"에서 고품질 코드가 결함이 15배 적었고, 개발 속도가 2배 빠르며, 문제 해결 시간이 좀 더 예측 가능했다고 한다. 고품질 코드의 비즈니스 이점은 분명하기에 코드 퀄리티를 올리기 위해 노력해야 한다.
그리고 Stripe사의 보고서에 따르면, 개발자의 평균적인 1주일의 작업시간 41.1시간 중 42%에 해당하는 17.3시간은 품질이 낮은 코드에 의해 개발 비용이 발생하고 있다.
또 다른 조사 Technical Debt tracking에서는 기술적 부채 관리에 소요되는 개발 시간은 개발 전체의 25%이지만 그 추적에 툴을 이용하는 조직은 불과 26%로, 체계적으로 추적하고 있는 조직은 7.2 %밖에 없었다.
결국, 코드 품질이 떨어지면서 일어나는 파생적인 일들이 일을 만드는 구조를 만들게 되어 개발 생산성이 떨어지고 비즈니스 뿐만 아니라 개발자의 경험에도 안좋은 영향을 끼친다는 것을 알아야 한다.
UX(사용자 경험)도 중요하지만, DX(개발자 경험)도 중요하다.
개발 문화가 존재하지 않거나 기술적 부채(Technical Debt)가 많은 상황에서 바쁘게 돌아가야만 하는 상황이라면 개발자에게 좋은 경험이 되지 못해 결국 개발 생산성 저하, 개발자의 이탈로 기업에게 손실을 줄 수 있다.
위 그림은 Philippe Kruchten가 설명한 백로그에 포함된 아이템을 분류하여 4색으로 구분한 것인데, "What Color is your Backlog?"라는 제목으로 발표 되었다. 왼쪽 영역의 Visible 영역은 행동(Behavior) 바꾸거나 바로잡는 사용자 경험(UX, User eXperience)의 영역이고 오른쪽은 소프트웨어 제품의 구조(Structure)나 기술 부채(Technical Debt)는 보이지 않는 Invisible 영역, 즉 개발자 경험(DX, Developer eXperience) 영역이다. Visible 영역은 고객의 체험에 영향을 주기 때문에 고객의 이탈에 직접적인 영향을 주어 이슈가 생기면 바로 대응을 하게 되는 메카니즘을 갖는데, Invisible 영역은 회사내, 팀내에서 소프트웨어 의사결정을 통해 구조 변경이나 기술 부채를 줄이는 시간을 확보하지 않으면 본래 할 일을 하지 않았기 때문에 나중에 더 강해지는 노력을 해야하는 Failure Demand가 발생하게 되고 결국 새로운 가치를 창출하는 Value Demand를 위한 시간을 빼앗아 개발자 경험(DX, Developer eXperience)을 악화시키게 된다.
1. 개발자 경험과 생산성((DevEx 관점)
개발자 경험의 과학적 연구 논문 DevEx: What Actually Drives Productivity에서 DevEx(개발자의 업무 체험이나 환경, 경험)가 개발자 생산성에 영향을 미치는 요인을 3차원 프레임워크로 설명하고 있다.
1) Feedback Loops(피드백 루프)
빈번한 배치와 리드 타임의 단축이 퍼포먼스 향상으로 연결되는데, 이유는 빠른 피드백 루프가 개발자가 장애 없이 작업을 진행하는 데 도움이 되어 생산성이 향상된다고 한다. 피드백 루프를 빠르게 하기 위해서는 개발 툴(빌드 및 테스트 시간을 단축), 인계 프로세스(코드 검토 및 승인), 조직 구조(팀 간의 상호작용을 간소화하고 지연을 줄임) 등의 개선안을 적용할 필요가 있다.
2) Cognitive Load(인지 부하)
높은 인지 부하는 부적절한 문서와 복잡한 시스템으로 인해 개발자는 작업 완료에 많은 시간과 노력을 소비하게 되어 고객에게 빠르게 가치를 제공하는 것을 방해한다. 인지 부하를 줄이려면 개발 과정에서 불필요한 장애를 제거하고, 이해하기 쉬운 시스템을 구축하고 컨텍스트 및 작업 전환을 줄여주고, 사용하기 쉬운 셀프 서비스 도구를 제공하고 개발 및 릴리스 절차를 간소화한다.
3) Flow State(플로우 상태)
이것은 집중력과 활력을 가지며 완전히 몰두하는 흐름 상태를 말한다. 플로우 상태에 들어가기 쉽게 하려면 계획되지 않는 회의나 작업을 최소화하고, 개발자에게 자율성을 부여하고 만족스럽고 도전적인 업무를 제공하고, 적극적인 팀 문화 구축하는 것이 좋다.
2. 개발자 웰빙과 생산성(SPACE 관점)
SPACE는 Lean과 DevOps의 저자중에 한명인 Nicole Forsgren이 고안 했으며 개발 생산성을 개인의 성능이 아닌 세가지 적용 수준 (개인, 그룹, 시스템)으로 측정하는 것이 좋다는 의미에서 만들어졌다.
예를 들어 풀 요청 수와 병합까지의 시간을 측정할 때 특정 누군가의 성능이 높아도 전체 팀을 볼 때 낮으면 의미가 없고, 코드 리뷰를 소홀히 하면서 개인의 업무는 빠르게 진행해 개인의 개발 생산성은 올라갈지 모르지만 그만큼 코드 리뷰를 하고 있지 않기 때문에 다른 멤버의 개발 생산성, 나아가서는 시스템의 개선이 어려워질 수 있어 개인, 그룹, 시스템 세가지 관점에서 보는 것이 중요할 수 있다는 관점이다.
이러한 생산성 향상의 지표 중에 하나로 개인의 웰빙도 있어서 개발자의 행복감이 개발 생산성에 영향을 줄 수 있다.
소프트웨어는 왜 지속적으로 개선을 해야 하나?
더 이상 시장 변화에 수동적으로 대응하는 것만으로는 부족하기 때문에 기업이 변화를 예측하고 아이디어를 신속하고 효율적으로 사용자에게 필요한 업데이트로 전환함으로써 제품의 가치를 높이는 데 적극적으로 노력해야 한다. 지속적인 개선은 기업이 이러한 경쟁적인 요구에 시간과 비용 효율적인 방식으로 대응할 수 있도록 지원하는 접근 방식이다. 실제로, 지속적인 개선은 조직이 비즈니스 전반에 걸쳐 개선할 수 있는 작업들을 식별함과 동시에 낭비와 비효율성을 줄일 수 있는 개선이다.
외부적으로는 고객에게 가치를 지속적으로 제공해 경쟁에서 이탈하지 않게 하기 위한 요인이 있고 내부적으로는 소프트웨어는 유효기간이 있어 일정 기간이 지나면 서버가 움직이지 않는 곳이 생기게 된다. OS, 라이브러리, 프레임워크, 외부 API 등의 변화가 그럴수 있다. 그리고 사용하지 않는 기능을 제거하는 노력도 코드의 복잡도를 줄여주는 효과가 있어 지속적으로 해야한다.
끊임없이 가치를 지속적으로 제공하되 복잡성, 성능, 안정성, 고객의 니즈, 비즈니스 상황의 변화 대처 등을 잘 부합하게 관리하는게 무엇보다도 중요하다.
개발 생산성을 올릴려면 어떻게 해야하나?
개발 생산성을 산정하기 위해서는 보통 처리량 많고 리드 타임 빠르냐를 가지고 파단할 수 있다. 먼저 처리량에 대변되는 업무량(신출물)에 대해서 먼저 고민해보면
- 소스 코드 양(SLoC:Source Lines of Code): 산출물을 측정에 많이 쓰긴 하지만 후행 지표이며, 코드 품질이나 가독성, 코드 중복을 무시하게 되면 생산성을 떨어지는 효과가 발생해 업무량 성과 지표로는 활용할 수 있을지 몰라도 개발 생산성 관련 지표로는 사용할 수 없다.
- 기능 포인트 양 : 1979년에 IBM의 Allan J. Albrecht가 제안한 작업량 견적 기법 중 하나인데, 누가 관여를 해서 FP를 작성해야하는 수고스러움이 있어 스토리 포인트(백로그) 기준으로 측정할 수도 있다. FP, 스토리 포인트는 팀 활동이나 성과 지표로 사용할 수는 있지만, 개발 생산성까지 확장에는 한계가 있기에 다른 지표들과 혼합해서 사용해야 할 것이다.
- 풀 리퀘스트 양 : 산출물 관점으로만 볼때 풀 리퀘스트를 파편화시키는 단점을 가지고 있지만, 병합시 커뮤니케이션이나 코드 리뷰를 통해 조직의 평균적인 기술 수준이나 생산성을 올릴수 있고 평균 릴리즈 시간을 예측할 수 있어 출시 일자의 지표로 활용할 수 있다.
- 예상 부가가치 양 : 실제 작업량과 기능에만 집중해서 산출물을 설계하면 실제로 의사결정자나 제품 부문과의 관련성이 떨어진다. 제품 기능의 관점에서는 가치로 연결되기는 어려워서 실제 가치 추정보다는 동료 평가에 의한 기대 가치 평가를 하면 도움이 된다. 그리고 기대 부가 가치 평가는 개발 우선 순위에 적용할 수 있어 기업 가치에도 도움이 된다. 일반적인 기대 부가 가치 스코어링 모델은 RICE 스코어링 모델을 차용할 수 있는데 Reach(기능 추가가 얼마나 많은 사람에게 영향을 미치는지), Impact(얼마나 큰 영향을 미치는지), Confidence(얼마나 성공할 가능성), Effort(기능 추가 들어가는 개발 공수) 기준으로 1-5점 단위로 동료 평가를 해 평균점수를 산정해 도출할 수 있다.
- 매출 양 : B2B의 프로젝트 단위의 업무를 할때 활용이 가능하며 후행 지표이고 B2C일 경우 매출 측정이 쉽지 않는 단점이 있다.
두번째로 리드 타임을 고민해보면 리드 타임은 보통 경영 및 사업 책임자가 의사 결정한 후 요구 사항이 결정되고 실제로 출시될 때까지의 시간을 말하는데 개발 생산성을 기준으로 할때는 의사 결정 시간을 빼고 보통 그 이후를 산정하는 경우도 많은데, 스타트업의 경우는 의사결정 과정도 개발조직과 협업을 통해 많이 결정되기 때문에 포함시키는게 좋다.
제일 중요한것은 처리량/리드 타임 빈도가 개발 생산성을 판단하는데 주요 키 포인트지만 빈도를 질로 전환시키는 고민도 해야한다. 즉, 장애없는 리드 타임, 처리량(업무량)도 제품의 가치와 연계해서 산정할 필요가 있다.
개발 생산성을 올릴려면 어떻게 해야될까?
1) 단위 테스트를 강화해 버그 발견율을 높임
위 그림은 Capers Jones의 "Applied Software Measurement: Global Analysis of Productivity and Quality"에서 제안된 소프트웨어 결함에 대한 일부 분석을 보여주는데, 파란색은 단계별 결함이 발생할 확률이고 노란색은 단계별 결함이 발견될 확률, 빨간색은 결함을 처리하는데 드는 비용을 나타낸다. 여기서 유추할 수 있는 것은 결함 발생률이 높은 개발자의 코드 퀄리티를 높일 필요가 있고 결함 처리비용이 적은 단계인 단위 테스트를 강화해 버그 발견율을 높이는 방향이 바람직할 것이다.
2) 회사내 소스 공유, 의존 관계(코드나 라이브러리 등 종속관계) 관리, 개발 도구(오픈 소스, 개발툴, 정적분석, 단위테스트 도구, 프로그래밍 언어) 등을 관리
"Why Google Stores Billions of Lines of Code in a Single Repository" 논문에 보면 개발자들이 가장 많은 도움(생산성 향상 효과)을 받은 영역이 가시성, 종속성 관리, 개발 도구라고 했다.
- 가시성 : 복수의 프로젝트의 개발자가 서로의 코드를 공유해, 그들을 자유롭게 검색·열람할 수 있어 높은 가시성을 가진다는 장점을 선호하고 있다. 코드 기반의 가시성(Visibility of codebase)을 높이 평가하고 있는 것이다. 설문 조사 결과를 보면 그 목적이 코드 재사용(Code Reuse)과 이용 예(Usage Examples)가 많았다고 한다. 기존의 코드를 검토해서 나의 프로젝트에 쉽게 반영할 수 있고 그리고 코드의 재사용으로 코드의 크기가 작으면 개발자에게 인지 부하가 낮아져 개발 생산성이 올라갈 수 있다.
- 의존 관계(코드나 라이브러리 등 종속 관계) 관리 : 의존성 라이브러리 같은 경우 버전이 많을 경우 선택비용 및 하위 호환성 불일치로 충돌이 발생하는데 비용이 들 수 있고, 라이브러리간의 의존성이 엮여 있다보면 한 라이브러리의 변경이 의존 관계의 모든 라이브러리에 영향을 줄 수 있고 빌드 리드 타임을 늘려주는 원인이 되기도 한다. 그래서 규모 있는 기업이나 프로젝트의 경우 의존성(단일 라이브러리 버전 호환성, 라이브러리간 종속성)울 명확하게 관리하는 단일 버전 규칙(One-Version Rule)을 관리할 필요가 있고 이렇게 함으로써 프로젝트 업데이트, 프로젝트간 커뮤니케이션 비용, 오픈 소스 도입 비용 등을 절감할 수 있다.
- 개발 도구 : 사용 가능한 개발자 도구(Available Developer Tools)을 일목요연하게 정리(라이센스, 업데이트 주기, 구현 주요 기능, 인기도, 개발된 언어 등)해 두면 프로젝트나 비즈니스 개발하는 부서에서 소프트웨어 아키텍처(플랫폼) 및 개발/운영 환경, 프로그래밍 언어, 프레임워크, 코딩 스타일 선택에 드는 비용을 줄일 수 있다. 그리고 프로젝트/비즈니스간 개발자 이동의 경우 사용 도구 스타일이나 코드 스타일 등의 다를 경우 학습 비용이 발생하기도 한다.
3) 팀 역량을 강화
팀 퍼포먼스를 강화해 조직의 역량을 키우는 것이 기업의 역량이 되므로 개인 역량보다는 더 중요하게 생각한다. 개인 역량을 위해 교육(세미나, 기술 공유)을 제공하고, 코드 리뷰나 페어 프로그래밍을 통해 앞선 경험을 제공하고, 개인의 만족도(컨디션, 정착, 스트레스, 갈등관리, 일의 강도 등)를 관리해주고 조직의 역량을 위해선 팀간, 팀내 개인이 조직의 목표(고객이나 사용자에게 가치를 창출)를 향하고 있는지, 팀내/조직간 협업이나 커뮤티케이션이 잘 이루어지는지, 조직간 리스크 분산은 잘 되어 있는지, 조직간의 불균형은 없는지 등을 관리하는 합리적인 프로세스가 있으면 좋을 것이다.
코드 리뷰에 대해서도 신경쓰는 것이 좋다. 코드 리뷰의 목표는 깨끗한 코드를 유지하는 것이리고 생각한다. 다음은 코드 리뷰를 위해 참고할만한 자료들이다.
- 코드 리뷰 모범 사례(Best practices for pull requests)
- 건강한 코드 리뷰(Code Health: Respectful Reviews == Useful Reviews) - 단위 테스트 아이디어(Shift testing left with unit tests)
- 개발 생산성이 높은 조직을 위해서는 DevOps 역량을 참조할 만하다.
- DORA Core Model에도 개발 조직의 케이파빌리티와 개발 생산성 지표와의 관계도 참고할 만하다.
코드 리뷰는 커뮤니케이션이다. 코드 리뷰 전에 프로그래머가 대상 요구 사항에 대해 가장 자세히 알고 있어야 리뷰 비용도 줄일 수 있다. 다음은 리뷰 전에 검토해야할 것들을 적어본다.
- 원칙이나 팀의 규칙을 따르는지 확인
- 단위 테스트 작성 여부
- 정적 분석 수행
- LLM 분석 수행
- 배경 지식 정보(Work Item 링크 )
- 우려와 타협점을 제시
4) 기술 부채는 지속적으로 해결하는 습관
스타트업에서는 기술 부채는 속도를 위해 품질이 희생되면서 발생하는 경우가 많다. 희생되는 품질의 대부분은 Invisible 영역으로 아키텍처나 운영(수작업) 업무 등에서 일어나서 고객에는 직접적인 피해가 가는 영역이 아니어서 개발 우선 순위에서 밀려나게 되어 쎃이게 되는 것이 대부분이다. 기술 부채의 경우 상환해야 할 부채와 그 영향을 파악하고, 해결에 걸리는 시간 등을 고려해서 정리한 다음 의사결정을 통해 우선순위를 두고 진행하면 된다. 진행과정은 기존 개발업무와 부채 상환업무를 병행할 수도 있고 영향도가 큰 경우는 기술 부채를 상환하는 업무를 먼저 진행할 수도 있다.
- 틈틈히 지속적으로 해야할 것은 반복 프로세스에 포함된 수작업(데이터 작업, 소스 관리, 배포 관리, 테스트 등)을 자동화하고 자동화에 그치지 않고 피드백을 받아서 개선해 나가야 한다. Context Switching을 줄여줘 개발하는데 집중할 수 있고 시간적 여유가 생겨 학습할 시간을 벌게 해준다.
- 버그는 묵혀두지 않는다. 그때 그때 차리하는 습관이 나중에 했을때 버그 원인 발견과 해결하는데 시간이 오래 걸리게 된다.
- 오버 엔지니어링을 하지 않는다. 오버 엔지니어링은 필요 이상으로 적용에 시간이 걸리거나 새로운 문제를 만들 수 있고 스타트업의 경우 운영 경험이 없는 기술일 경우 장애 대응시간도 길어지고 개발자의 경험을 피폐하게 만들 수 있다는 점을 명심하자. 꼭 비즈니스에, 우리 조직의 수준에 적합한 기술을 선택해 사용하자.
- 시스템의 결합 관계 및 변경에 따른 영향 범위의 명확하게 문서화하자. 이렇게 문서화하면 버그 발생 빈도도 줄일 수 있지만 코드 리팩토링 등 비효율적인 코드들의 최적화시 영향 범위를 명확하게 알 수 있고 테스트 커버리지도 높일 수 있어 여러모로 좋다.
5) 머리가 아닌 습관, 일머리
KentBeck은 말하기를
나는 위대한 프로그래머가 아니라 위대한 습관을 착용한 프로그래머다.
개발을 함에 있어서 머리를 쓰기 보다는 단순한 생각의 습관이 좋다. 일을 단순화거나 프로그램을 단순화하는 등의 생각들이 체득된 습관을 가지는 것이 생산성에 좋다는 것을 경험해보면 알 수 있다. 크게 생각하지 말고 뭐든 조그만 단위로 쪼개어 생각하고 실행해보고 디버깅해 보고 즈금씩 이해하는 스텝을 가져간다. 이런게 쌓이면 머리속의 메모리에 문맥이 저장되어 있어 몸이 체들해 습관이 되고 뭐든 이해가 빠르다는 소리를 듣게 된다.
6) 질문을 해야하는 상황 그자체가 비용임
질문은 동기식으로 이루어져야해 상대방에게 콘텍스트 스위칭을 유발해 집중도를 떨어뜨리게 한다. 학습을 통해 이해도를 높이는 농력을 많이 해야한다. 모르면 질문의 정확하게 할 수 없게 되고 커뮤니케이션 비용을 증가시킨다. 또, 관련 문서가 없다면 커뮤니케이션을 유발하게 한다.
커뮤니케이션은 상대방에게 기분상하지 않게 해야하기에 메터데이터가 추가되고, 완곡한 말투가 가미되어 상대방에게 전달되어진다. 이것 또한 의사 소통의 부하를 유발할 수 있다. 스스로 할 수 있는 상황을 만드는 것이 제일 생산성에 베이스가 된다.
그리고 Ask culture(묻는 문화) vs Guess culture(눈치보는 문화), 관점 이해를 통한 갈등 해결도 필요하다. "Ask culture vs Guess culture"라는 개념은 2007년 Metafilter 사용자인 tangerine가 온라인에서 공유를 했다. "Ask culture"는 거절될 수 있는 요구들도 상대에게 하는 것이고 "Guess culture"는 다른 사람이 아마 받아 들일 것 가능성이 큰 경우에만 상대방에게 뭔가를 부탁을 하는 경우를 말한다. Ask culture형의 사람과 Guess culture형의 사람이 조직내에 있으면 커뮤니케이션에서 서로 충돌할 가능성이 있기에 양쪽의 관점을 해킹해 갈등이나 스트레스의 해결 방법이 될 수도 있다.
학습을 하고 충실한 문서를 만들어 둔다.
7) 콘텍스트 스위칭을 피하자.
컨텍스트 스위칭에 관련된 마이크로소프트 리서치의 연구('A Diary Study of Task Switching and Interruptions' Mary Czerwinski 외 2004년)에서 중단된 작업을 재개하는 데 평균 25분 26초가 소요되고 외부 요인(전화, 동료 방문 등)에 의한 중단에서는 22분 37초, 내부 요인(자발적인 중단)에서는 29분 1초가 필요하며 전체적으로 집중력이 40% 감소한다고 한다.
또한, American Psychological Association(미국 심리학회)의 기사('Executive control of cognitive processes in task switching.')에 따르면 컨텍스트 스위칭은 생산성이 최대 40%까지 낮아질 수 있다고 한다.
이런 나쁜 컨텍스트 스위칭을 피하는 것이 개발자의 경험과 생산성에 중요한 역할을 한다.
비즈니스 가치 지향 코딩을 하는 것은 어떨까요?
개발자가 기업에 존재한다는 것은 자산으로 보이지만 반대로 기업을 운영 관점에서보면 비용으로 인식될 수 있어서 양날의 검이다. 그래서 개발자가 비용 최적화의 한 수단으로 인식될 수 있어 아쉽게 생각하지만 스타트업에서는 그 비용이 부담이 될수 있고 기업 존속의 문제가 될 수도 있다. 물론, 비즈니스의 가치를 올리면 비용은 감당할 수준이면 용서가 되지만, 개발자의 비즈니스 가치 지원 관점에서 노력을 기울여야한다는 점을 강조하고 싶다. 비즈니스는 고객에게 일반적으로 좋다라고 느끼기보다는 설득력이 있는 비전을 제공해 구체적으로 이건 이렇고 저건 저래서 좋다라는 구체적인 비전을 고객에게 제시할 수 있는 가치를 구현하는게 좋다. 그리고 그 비전에 공감되었을 때 선택될 수 있다.
- 매출/고객 증가시킬 수 있는 기능을 우선 개발한다. 소프트웨어 엔지니어링 조직은 신규 고객에게 요금이 높아도 이용하고 싶게 하거나 기존 고객의 업셀이나 크로스셀, 계속 이용의 이유가 되는 제품의 기능의 개발에 우선 집중을 해야한다.
- 운영 업무를 지속적으로 개선한다. 스타트업의 경우 가파른 성장 곡선을 감당할 수 있는 그 이면에는 비즈니스의 고객 가치 이외에 운영 업무가 잘 조직화되어 있을 가능성이 높다고 생각한다. 눈에 잘 띄지 않지만, 다양한 업무 구석구석을 살피고 이어주는 역할을 재대로 하기 위해서 많은 노력하고 있을 것이다. 운영 업무(유지보수 포함)를 하다보면 데이터가 보이게 되고 장애 등의 운영 이슈에 대한 대응력이 쌓이게 되며, 이 경험이 프로그래밍에 반영되면 최소한의 노력으로 안정적인 서비스를 유지할 수 있게 된다. 운영중인 서비스에서 추가하고자하는 Features나 개선 사항들을 반영할 때, 안정화 기간을 최소화 해 고객에게 버그 노출을 줄이는 방법으로 데이터(DB, 로그) 기반한 프로그래밍을 하면 되는데, 데이터 기반 프로그래밍이란 보완/개선/신규 기능을 테스트 후 반영하기 전에 우리가 모르는 버그를 예측하기 위해서 관련 테이블의 검증 쿼리를 미리 마련해 데이터 검증 프로세스를 만들어 두고 또한, 에러 로그 필터도 만들어서 알림 프로세스에 넣어두면 우리가 예측하지 못한 사용자의 다양한 프로세스와 데이터 속에 의도하지 않는 케이스, 개발자의 버그 등이 노출될때 빠르게 캐치를 할 수 있다. 이를 빨리 보완해서 테스트하고 적용하는 Iteration을 짧은 주기로 하게 되면 서비스 반영 후 빠른 안정화를 꾀할 수 있다.
- 이탈률 저하를 목적으로 한 제품 기능 개선한다. 고객이 제품을 사용하다가 중지하면 피드백 받는것도 중요하고 그 피드백을 제품에 녹이는 것은 더 중요하다. 복잡한 기능을 단순화하고 어렵지 않게 하며, 고객의 비즈니스 동선을 바꾸려하지 않는 선에서 부가가치를 제공하려고 하고, 기능 추가보다 불필요한 기능을 제거하는 것이 더 중요할 수도 있다는 것을 생각해야한다.
- 서비스 품질 개선 활동을 한다. Dev에서는 개발 성능을 중요시하고 Ops에서는 신뢰/안정성을 중요시해서 상호간의 트레이드오프가 일어나 DevOps가 작동하지 않는 큰 원인 중 하나가 되기도 한다. 그래서 절충을 통해 사용자에게 제공하는 가치 극대화라는 목표를 위해 Dev, Ops, Biz의 인센티브 정렬이 필요할 수도 있다. SLO를 절충해서 운영할 수도 있고 비즈팀에서는 비즈니스 우선 순위를 고려한 SLO를 운영할 수도 있다. 또한 서로 지원하여 이익을 얻는 포지티브 루프를 만드는 등의 인센티브 디자인도 같이 고려할 수도 있다.
- 비용 적정화도 고민해야 한다. 스타트업 특성상 비용에 민감할 수 있어 비용에 대한 고민들중에 하나로 서버 비용에 대해 절감할 수 있는 방안들을 고민해야 한다. 동일 트래픽을 수용할 수 있다면 서버, 개발 언어, 클라우드 사용 등의 변화를 통해 서버 대수가 적을수록 유리하다.
