vidigummy SOMA

프로젝트 기획

vidi 2022. 7. 24. 14:52
  1. 기간
    1. 2022.05.15 ~ 2022.06.25
  2. 시작 개념
    1. DORA Team
      1. Google DevOps Research & Assessment Team
      2. 2014년부터 레포트를 내놓고 있음
      3. 행동 과학을 사용하여 소프트웨어를 개발하고 제공하는 방법을 연구(DevOps)
    2. DORA Metrics
      1. 2016 DORA DevOps Report, Lean Product Production에서 Potential Saving from Reducing DownTime 에서 좋은 개발팀에 대한 지표가 등장하기 시작함.
      2. 2017 결국 IT performance by cluster 라는 테이블에서 DORA Metrics의 네가지 개념이 정립되게 되었다. 이는 계속해서 연구되고 있으며 LinearB, HayStack, Jira Agile Metrics, Google 4 Keys, AWS DevOps Monitoring Dashboard 등의 서비스에 적용되어 사용중에 있다.
        1. 그럼에도 불구하고 이러한 Metrics 상품들은 개인적인 성향이 강한 북미 개발 팀 위주로만 사용하고 있으며 아직 한국에는 널리 알려지지 않은 것이 사실이다.
      3. Deployment frequency
        1. 팀의 작업 배포 주기를 말한다.
        2. 팀 전체가 얼마나 빠른 변화를 거듭하는지 보여주는 지표라고 생각할 수 있다.
      4. Lead time for changes
        1. 프로젝트를 이루는 코드는 필요할 때 마다 변경될 것이다.
        2. 하지만 팀이 이를 얼마나 빨리 수행할 수 있을까?
        3. 첫 커밋(작업을 시작할 때)부터 Deployment 될 때 까지의 시간은 얼마나 걸리는가? 또한 생산성에 있어 큰 요소일 것이다.
      5. Mean time to Recover(MTTR)
        1. 심각한 문제가 생겼을 때, 얼마나 빨리 정상 상태로 복구할 수 있는가?
        2. Product 배포와 서비싱에 있어서 장애를 피할 수는 없지만, 이를 얼마나 빨리 회복하여 사용자들에게 정상적인 서비스를 제공할 수 있는지는 팀의 중요한 역량이다.
      6. Change failure rate
        1. 서비스를 제공하고 배포하는 동안 관련하여 얼마나 많은 핫픽스, 롤백, fix forward, patch가 일어나는지?
        2. 위의 예시들은 안전한 코드 변경에 실패했다는 뜻이다. 구현 또한 중요한 사항인 것은 틀림 업고, 모든 코드에는 error 혹은 side effect가 존재할 수 밖에 없음을 알고 있다.
        3. 그럼에도 불구하고, 그 상황 내에서 최대한 안전한 코드를 만드는 것은 중요한 역량임이 분명하다.
  3. 목표
    1. 기존 서비스들은 개인주의적인 성향이 강하며, 성과를 최 우선으로 고려하는 북미를 중심으로 한 서방세계의 개발팀에 특화되어 있다는 맹점을 가진다.
    2. 대한민국의 개발 시장은 생각보다 폐쇄적이며, 성과 최우선주의와는 거리가 좀 있다는 특징이 있다. 또한, 조사를 하면서 알게된 사실인데 개발자들이 자신의 퍼포먼스가 어떻게 되던 간에 드러나는 것 자체를 꺼리는 분위기를 가졌다.
    3. 이러한 간극을 좁히기 위해서는 개발자 개인이 아니라 팀의 퍼포먼스 만을 보여줘야한다는 것이다.
    4. 또한 Lean Product가 아닌 완성된 Product를 내놓는 팀, 그리고 아직 Agile 주도 개발이 익숙치 않은 학생팀 등을 위한 Custom Template 기능등을 통해 더 나은 사용자 경험을 보여주기로 하였다.
    5. 조사 과정 중 다른 상품들에서 배운 점인데, 개발 중에 일어날 수 있는 많은 위험들(To many WIP(working in process), BIg Diff, Code Collision, Burn Out 등…)에 대한 정보들 또한 알림으로 제공함으로써 지속 가능한 개발을 도와주기로 하였다.
  4. 개발 방법
    1. Agile 방법론을 따라 우리 또한 MVP Product를 지속적으로 내놓으며 개발하는 방식으로 진행할 예정이다.
    2. 우리에게 있는 것은 풍부한 프로젝트 진행비, 한국 출신 개발자 중 최고라고 평가받는 멘토님들로 이루어진 멘토단(팀 전담 멘토님은 아니지만 지속적으로 우리를 챙겨주시는 멘토님들 또한 포함되어있다.)(Microsoft Advocate / Google firebase team / Hardware programming team leader / Google Server engineer(그 유명한 조대협의 블로그 주인님이시다) / MLOps+Infra Engineer). 그리고 열정 넘치는 팀원들이다.
    3. 1차 MVP는 8월 25일 소프트웨어 마에스트로 중간발표까지이며, 이주간의 소프트웨어 마에스트로 내부 CBT를 거친 이후 피드백을 수용하여 더 나은 제품으로 서비스할 예정에 있다.
    4. 아키텍처, 개발 프레임워크, 언어 등의 기술적인 부분은 추후 포스팅에서 알려줄 수 있도록 할 것이다.