3/20/2022

Monolith 분할 하기

Written by Giljae Joo (주길재)  in ,   with 댓글 없음

 

모놀리스 분석

대부분 현재 시스템을 잘 설명해주는 문서는 존재하지 않는다. 존재한다고 해도 현행화가 되어 있지 않기에, 오해의 여지가 발생하기도 한다. 상황이 어떻든 최소한 아래의 정보는 수집해야 한다.

  • 애플리케이션의 기능 모듈 및 상호간의 관계
  • API 및 서비스 인터페이스
  • 모듈에 대한 설명이 있는 논리 다이어그램
  • 시스템 구성을 알 수 있는 물리 다이어그램

데이터

어떤 데이터를 다루는지 알 필요가 있다. 각 모듈별 어떤 데이터를 다루는지 추출을 해야 향후 마이크로서비스로 전환시 경계를 설정할 수 있다.

현황 파악

기능이 이미 외부에 존재하는 경우도 있다. 이 경우 외부 서비스를 재사용하도록 고려해야 한다.

사용자 파악

애플리케이션을 어떤 사용자가 사용하는지 파악해야 한다. 이 작업을 수행하면 사용하지 않는 기능을 추출할 수 있고 분할 방법, 분할하는 이유 및 효과등을 알 수 있다.

분할해야 하는 이유

모놀리스를 마이크로서비스로 분할해야 하는 이유에 대한 답을 찾기가 어려울 수 있다. 가능하면 두가지를 얻으려고 노력한다. 비즈니스/기술 지향 관점에서 이점을 가져가려고 노력해야 한다.

비즈니스 관점

비즈니스 지향 관점에서 분할하는 이유를 고려해야 한다.

  • 애플리케이션 출시 기간 단축
  • TCO 절감 → 트래픽 증가시 필요 부분만 확장
  • 손실 감소
  • 더 나은 사용자 경험 → 이 경우 UX를 반영한 UI가 개선되어야 한다.

현재 프로젝트는 위 4가지 개선 사항이 모두 포함되어 있다.

기술 관점

기술 지향 관점은 비즈니스 Guy들은 이해하기가 어렵지만, 중장기적 관점에서 원할한 MA를 위해서 필요한 작업들이다.

  • 더 이상 사용되지 않는 기술을 제거하고 현재 사용중인 기술로 마이그레이션 → Stored Procedure, EAI등
  • 복잡성 감소
  • 테스트 커버리지 증대 → 장애 감소

오랫동안 사용되었던 시스템을 구조개선해야하는 업무를 수행중이다.

모놀리스 시스템을 분할하기 위해서는 몇 가지 목표를 설정해야 한다. 분할 비용과 분할 되었을 때의 이점을 고려해야 하고, 이 보다 애플리케이션 및 데이터베이스 Scale-up이 더 유리한지 판단해야 한다.

애플리케이션의 특성으로 인해 모놀리스는 매우 지저분해 보일 수 있다. 대규모 시스템이며 상호간 튼튼하게 결합되어 있다.

  • 재사용성 고려
  • Side effect 최소화

마이크로 서비스로 전환?

마이크로 서비스의 이점

무작정 마이크로 서비스로 전환하려는 것은 아니다. 오래전 Gartner가 소개한 MSA에 대한 관점을 보면, 통합 DB를 사용하는 경우 Miniservices라는 표현을 했고, 현재 구조개선을 해야 할 시스템은 마이크로서비스보단 미니서비스가 적합해 보인다. 모든 것을 한걸음으로 해결하면 좋겠지만 현실은 녹녹치 않다.

이점요구사항
서비스 유연성: 모놀리스에 비해 상대적으로 작은 서비스는 유연하기에 기능을 수정하기 쉽다.출시 시간 단축, 개발 비용 절약, 복잡성 해소, 테스트 커버리즈 증대
서비스 재사용성: 서비스는 비즈니스 기능을 중심으로 구성되기에 재사용하기 쉬워야 한다.개발 비용 절약
표준화된 서비스 개발 및 기술에 구애받지 않는 구현: 다양한 기술이 포함된 Stack을 활용개발 비용 절약, 더 나은 리소스 계획, 재사용
서비스 확장: 추가, 제거, 업데이트 및 이벤트 대응등 확장하기 쉬워야 한다.TCO 절감, 더 나은 사용자 경험
복원력: 오케스트레이션을 통한 단일 서비스의 장애 격리더 나은 사용자 경험, 손실 감소

분할 준비

사전 준비하기

모놀리스를 분할하는 단계이다. 비즈니스 요구 사항, 애플리케이션 상태, CI/CD 프로세스를 고려하여 단계를 조정할 수 있다.

기준이 설정되면 모듈/서비스 목록은 비즈니스 기능을 중심으로 구성해야 한다.

리팩토링

분할해야 하는 애플리케이션이 좋은 형태를 가지고 있을 가능성은 거의 없다. 그 애플리케이션 개발되는 시점에는 최선의 선택이었겠지만, 시간이 흐르면 바라보는 관점이 달라지기 때문이다. 따라서 모놀리스에서 리팩토링이 수행될 수 있다.

우리는 각 유형별 Boiler plate를 만들었고, 개발 되는 모든 작업들은 Boiler plate 표준 기반으로 동작되도록 가이드했다. 기존 시스템도 Boiler plate기반으로 리팩토링을 진행했다. 리팩토링을 진행하면서 Controller, Service, DAO등과 같은 애플리케이션의 주요 계층을 이해하고 관찰했다.

서비스/기능 경계 및 API

비즈니스 모델을 모델링하는 대신 기존 애플리케이션에서 비즈니스 기능을 추출해야 한다. 비즈니스 기능을 기존 애플리케이션 서비스 및 도메인 모델에 매핑하여 경계를 식별하기만 하면 된다.

일반적인 모놀리스 시스템에서 컨트롤러는 API를 추출하는데 도움이 된다. 기존 시스템은 DTO 없이 모두 HashMap으로 Request/Response를 처리하고 있었고, DTO 작업을 통해 Request/Response에 대해 미리 파악할 수 있었다.

서비스 외관 작업

서비스 경계가 정의되면 비즈니스 기능을 한 애플리케이션이 처리하는 대신 상호 작용 방식으로 변경해야 한다. 모놀리스 애플리케이션에서 Facade를 만들고 Facade를 통해 작업해야 한다.


서비스를 추출하기 전에 느슨하게 결합된 모놀리스로 리팩토링 되어야 한다.

데이터

데이터베이스로 하나의 서비스를 추출하면 다른 서비스에 영향을 줄 수 있다. 서비스 데이터에 대한 접근은 데이터베이스가 아닌 API를 통해서만 이루어지도록 해야 한다. (통합DB를 사용하더라도, 가능하면 계정을 분리하고 각 서비스에서 제공하는 API를 통해 접근해야 한다.)

이 작업은 상당한 노력이 필요하다. 우리팀의 경우 예기치 않은 Join이 발생했을 경우를 제외하고는 이 정책을 유지하려고 노력중이다.

모놀리스 시스템의 새로운 기능 추가 중단

미니서비스로 분할하는 작업을 진행할 경우, 기존 운영중인 모놀리스 시스템과 병렬로 작업이 수행된다. 이 경우 모놀리스 시스템에 추가되는 기능은 법적인 문제, 버그등으로 제한할 필요가 있고, 신규 기능들은 새롭게 구현되는 미니서비스에서 충족시켜줄 필요가 있다.

사전 준비 마무리

위에서 언급한 단계는 모두 분할전에 수행되어야 한다. 애플리케이션은 세분화된 서비스, API 및 경계, 각 서비스간 데이터 격리의 정책을 기반으로 느슨하게 결합된 모놀리스로 제공되어야 한다.

분할 수행

분할할 서비스 우선 순위 지정

비즈니스 기능/도메인별로 기존 애플리케이션을 재구성/리팩토링/그룹화하려는 시도가 필요하다.

  • 가장 자주 변경되는 서비스: 배포에 대한 영향을 최소화
  • 외부 서비스로 대체될 수 있는 서비스: 굳이 개발할 필요가 없기에
  • 확장해야 할 서비스: 성능을 최적화
  • 서비스 복잡성: 자동화된 프로세스 구축

마이크로 서비스간 통신 방식 선택

대부분의 경우 REST 또는 gRPC를 선호한다. 이유는 상대적으로 단순하고, 팀내에 경험자가 많고, 다양한 도구의 지원이 가능하기 때문이다.

서비스 구현

통신 방식을 선택 후, 미니서비스를 구현한다. 기존에 리팩토링된 모놀리스의 코드를 참조한다.

미니서비스 사용으로 전환

구현이 완료되면 통합 테스트 후, 기존 모놀리스에서 미니서비스로 프로덕션 레벨에서 전환한다.


모놀리스 애플리케이션을 MSA(마이크로서비스)로 마이그레이션 하는 방법

Written by Giljae Joo (주길재)  in ,   with 댓글 없음

이쪽 업종에서 일하는 분들이라면 Monolith으로 구현되어 있는 레거시 시스템을 마이크로서비스로 마이그레이션 하고자 하는 Needs가 있을 것이다.

비즈니스를 분석해서 새롭게 만드는 것이 가장 좋은 방법이겠지만, 레거시와 병행해서 개선을 해야 할 상황도 존재하기에 새롭게 만드는 것이 여의치 않은 경우도 많을 것이다.

나도 레거시 시스템을 분석하면서 어떻게 구조 개선을 할 것인지에 대한 고민이 있고, 새롭게 코드를 짜던 기존 코드를 마이그레이션을 하던 가장 유리한 방식을 채택할 계획이다.

위 관점에서 Dzone에 도움이 되는 글이 있길래, 번역을 하였다.

모놀리스 아키텍처

모놀리스 애플리케이션은 복잡도가 큰 단일 애플리케이션이다. 또한 유지 관리가 어렵고 잦은 배포를 하기가 쉽지 않다. 한 곳에 장애가 발생하면 전체 시스템이 다운 될 수 있는 확률도 높다.

모놀리스 아키텍처의 특징은 아래와 같다.

  • 모든 유형의 브라우저, 모바일 앱등을 제공하는 큰 단일 애플리케이션이다.
  • 매우 복잡하고 거대한 구조와 파일을 지니고 있다.
  • 모놀리스 애플리케이션은 유지 보수가 어렵다. (코딩 표준, 버그 수정등의 측면)
  • 대규모 애플리케이션을 자주 배포할 수 없기 때문에 지속적인 개발이 어려울 수 있다.
  • 애플리케이션 확장이 어려울 수 있다.
  • Scale-out이 매우 어렵다.
  • 개발팀은 모놀리스 애플리케이션을 확장하는 것이 어렵다고 생각한다. 애플리케이션이 일정 크기를 넘어서면 단일팀으로는 유지 관리가 어렵기에 모듈 및 서비스를 현명하게 분할해야 하고 각 모듈간 간섭으로 인해 개발자가 폭넓게 이해를 해야 하기에 시간과 비용이 많이 소요된다. 이런 부분들이 생산성에도 영향을 미친다.
  • 기술의 병목 현상이 존재한다. 애플리케이션이 특정 기술에서 개발을 시작하면 구식이 되어도 최초 사용한 기술을 고수해야 한다.
  • 애플리케이션을 빌드하거나 배포하는데 많은 시간이 소요된다. 이에 개발자는 많은 시간을 할애해야 한다.
  • 애플리케이션을 시작시 많은 시간이 걸리기에 배포에 영향을 미치고, 이는 생산성에 영향을 준다.

위의 이미지는 단일 애플리케이션에 모든 기능이 포함된 일반적인 아키텍처를 의미한다.

마이크로 서비스란?

서비스에 집중하고 각 서비스가 독립적으로 되는 방식이다. 전체 시스템을 조각으로 나누어 서비스를 개발하는 방법이다. 간단히 말해서 유지 관리가 어려운 하나의 거대한 시스템을 독립적이고 유지 관리가 가능한 더 작은 서비스로 나누는 것이다.

마이크로 서비스의 주요 특징은 다음과 같다.

  • 각 서비스는 느슨하게 결합되어야 한다.
  • 각 서비스는 유지 보수가 용이하고 확장 가능해야 한다.
  • 각 서비스는 독립적으로 배포할 수 있어야 한다.
  • 각 서비스는 비즈니스 기능에 따라 경계를 명확히 해야 한다.
  • 각 서비스는 소규모 팀이 소유해야 한다.

아래 이미지를 보면 자체 데이터베이스가 있는 다양한 유형의 서비스가 있음을 식별 할 수 있다.


위 그림에서 각 서비스는 서로 간섭하지 않고 작동하는 여러 마이크로서비스로 나뉜다. 이것은 각 서비스가 다른 마이크로서비스와의 간섭을 최소화하면서 작동할 수 있는 하나의 작은 모듈이고 각 서비스가 책임을 가지며 개별적으로 배포할 수 있고 소규모 팀이 소유할 수 있는 마이크로 서비스 아키텍처의 모습이다.

레거시 애플리케이션을 마이크로서비스로 마이그레이션

모놀리스 애플리케이션을 마이크로서비스로 마이그레이션 하는 방법에는 두 가지가 존재한다.

  • 별도의 마이크로서비스에서 새로운 기능을 구현
  • 기존 모놀리스 코드 기반에서 새 마이크로서비스를 추출

단일 모놀리스 애플리케이션이 있는 경우 별도의 데이터베이스와 기능을 포함하는 마이크로서비스에서 새로운 기능을 개발해야 한다. 이 프로세스에서 모놀리스 애플리케이션의 데이터를 원하는 경우 모놀리스 애플리케이션 내부에 상대 API를 빌드하거나 제공할 수 있는 독립형 애플리케이션을 만들어야 한다.

이것을 모놀리스와 마이크로서비스 사이의 중재자가 될 Glue라고 한다. 이 후 개발자는 시간이 있을 때 모놀리스에서 새로운 마이크로서비스로 모듈을 이동할 수 있다. 일정 시간이 지나면 모놀리스 애플리케이션 없이 마이크로서비스만 가질 수 있게된다.

하나의 식품 주문 및 배달 관리 모놀리스 애플리케이션이 있다고 가정하자. 일부 기능을 마이크로서비스로 추출하여 해당 애플리케이션을 마이크로서비스로 만들려고 한다. 아래 그림은 모놀리스 애플리케이션에서 일부 기능을 마이크로서비스로 변환한 것이다.


1.먼저 모놀리스 애플리케이션 내에서 코드를 분할한다. 즉, 코드를 느슨하게 결합된 코드와 동일한 모놀리스 애플리케이션내에 위치한 주문 코드 및 배송 코드를 별도로 분할한다.


2.데이터베이스를 분할하고 추출된 서비스의 데이터베이스를 분리한다. 이때 접착제를 추가해야 한다. 즉, 개발자는 두 베이스베이스간에 동기화할 계획을 가지고 만들어야 한다. Trigger 또는 코드로 관리할 수 있다.


3.분리할 기능에 대한 별도 서비스를 정의한다. 해당 모듈에 대해 별도의 서비스를 만든다. (아래의 예저는 배송관리이다.)

4.Extracted Service를 독립적으로 사용한다. API 게이트웨이를 이용해 독립적으로 만들 수 있다.

5.기존 모놀리스 애플리케이션에서 전달 관리 코드를 제거한다.

끝으로

위 단계를 따르면 일반적인 모놀리스 애플리케이션을 마이크로서비스 기반 아키텍처로 마이그레이션 할 수 있다.


1/22/2022

유료로 전환되는 도커 데스크탑 대체하기 (Mac M1)

Written by Giljae Joo (주길재)  in ,   with 댓글 없음

 

아래 트윗처럼 도커가 가격 정책을 변경했다. Docker Desktop은 기업내에서 더이상 무료가 아니다.

Kubernetes에서 애플리케이션을 실행해야 한다면 데스크탑에 Kubernetes를 설치하는 것이 매우 유용하고 Docker Desktop을 잘 써 왔었다.

이제 도커를 기업에서 사용하려면 구독을 해야하기에 대안을 모색해봤다. 본 글에서는 Docker Desktop 대체제를 조사했고 설치 및 설정에 대해서 다루고자 한다.

Rancher Desktop

Rancher Desktop은 Kubernetes 및 컨테이너 관리를 데스크탑에서 지원하는 오픈 소스 프로젝트이다.

Rancher Desktop은 아래의 기능을 제공한다.

  • Kubernetes 버전 선택 가능
  • Kubernetes를 업그레이드 및 테스트 지원
  • 컨테이너를 실행하고 이미지를 빌드, 푸시 및 가져오기 지원

현재 Lima와 nerdctl은 GUI를 제공하지 않지만, Rancher Desktop은 Electron 기반의 GUI를 제공한다.


동작 원리


Rancher Desktop은 다른 도구를 매핑하는 방식으로 동작이 된다. MacOS 및 Linux 에서는 가상 머신을 활용하여 컨테이너 및 Kubernetes를 실행한다.

Rancher Desktop 설치

테스트한 환경이 Mac M1이기에 이 기준으로 작성한다.

Rancher Desktop 설치는 간단하다. Github release에 접속해 rancher-desktop-{version}-aarch64.dmg 파일을 다운로드 하고 설치 하면 된다.

설치 후 “Rancher Desktop” 앱을 실행하면, 아래의 화면이 나오고 본인 환경에 맞게 옵션을 선택하면 된다. 아래는 내가 선택한 옵션이다.

Kubernetes 버전 선택

기본적으로 Rancher Desktop은 Kubernetes의 버전을 선택할 수 있다. v1.16부터 원하는 Kubernetes 버전을 선택할 수 있다.


위 화면은 Mac용 Rancher Desktop의 Kubernetes 설정 화면이다. 여기서 사용하려는 Kubernetes 버전을 선택할 수 있다. 새 버전을 선택하면 Rancher Desktop은 버전에 필요한 모든 구성 요소를 다운로드하고 로컬 버전을 전환한다.

지원 툴 선택


helm, kubectl 및 nerdctl까지 필요한 유틸리티를 체크하면 사용할 수 있도록 설치해준다.

Images


k8s.io namespace에 기본적으로 설치되는 Image들이다.

Rancher Desktop 사용

Rancher Desktop이 실행되면 Kubernetes를 사용하는 것과 큰 차이가 없다. 터미널을 열어서 kubectl 명령어를 실행해보자.

giljae@giljae ~ % kubectl get pods --all-namespaces
NAMESPACE     NAME                                     READY   STATUS      RESTARTS        AGE
kube-system   helm-install-traefik-crd--1-vjx5n        0/1     Completed   0               15d
kube-system   helm-install-traefik--1-zrd5f            0/1     Completed   1               15d
kube-system   coredns-85cb69466-rzdnb                  1/1     Running     2 (6m31s ago)   15d
kube-system   svclb-traefik-lwdmn                      2/2     Running     4 (6m31s ago)   15d
kube-system   local-path-provisioner-64ffb68fd-fv9xl   1/1     Running     2 (6m31s ago)   15d
kube-system   metrics-server-9cf544f65-5xcs7           1/1     Running     2 (6m31s ago)   15d
kube-system   traefik-786ff64748-vgszv                 1/1     Running     2 (6m31s ago)   15d
kube-image    builder-t5lbz                            2/2     Running     0               4m4s

Nginx 구동 시키기

nerdctl 명령어를 이용해서 nginx image를 pull한다.

giljae@giljae ~ % nerdctl pull nginx
docker.io/library/nginx:latest:                                                   resolved       |++++++++++++++++++++++++++++++++++++++|
index-sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31:    exists         |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:50ab7908620ee92646ddcd9fe321f969cdff672819fd9c8427448f67f59ef32e: done           |++++++++++++++++++++++++++++++++++++++|
config-sha256:eeb9db34b33190cac170b27d857e9b23511d396a2609c1a54e93025634afed0a:   done           |++++++++++++++++++++++++++++++++++++++|
elapsed: 2.1 s                                                                    total:   0.0 B (0.0 B/s)

image가 존재하는지 확인해본다.

giljae@giljae ~ % nerdctl images nginx
REPOSITORY    TAG       IMAGE ID        CREATED          PLATFORM          SIZE
nginx         latest    0d17b565c37b    4 minutes ago    linux/arm64/v8    142.4 MiB

command외에 rancher desktop app의 Images에서도 확인이 가능하다.


이제 Nginx를 구동 시켜보자. 간단하게 테스트 할 목적으로 daemon으로 구동하진 않았다.

giljae@giljae ~ % nerdctl run -p 8000:80 nginx

브라우저에서 확인해보자. (http://127.0.0.1:8000)


Rancher Desktop에 대한 자세한 내용은 여기를 참조하자.

12/31/2021

효율적으로 일하는 방법

Written by Giljae Joo (주길재)  in , , , ,   with 댓글 없음

일을 하다보면, 공식적으로 Jira에 관리되어 진행하는 Task와 Jira에서 관리하기 애매한 자잘한 Task들이 존재한다. 거기다가 회의 일정등 여러가지 것들을 복합적으로 관리해야 하는 상황에 부딪히게 된다.

오래전부터 나는 GTD(Getting Things Done)를 사용하여 Task를 구성하고 관리하고 있다.

쉽게 말하면 GTD 방법은 추적하고 있는 모든 것(진행중, 대기, 준비등)을 머릿속에서 제거하고 어딘가에 적어 두도록 구성하는 것이다. 어떤 일을 끝냈을 때, 다음에 해야 할 일을 기억하는데 에너지를 쏟을 필요가 없는 것이다.

Email

사용 툴 : Outlook

대부분의 사람과 마찬가지로 내 작업의 대부분은 이메일을 통해 이루어진다. 다른점은 Inbox내에 처리하지 않은 작업만 남아 있을 뿐이다.

가능하면 Inbox(받은 편지함)내에 메일이 0이 되도록 노력중이다. 메일이 올 때마다 메일을 읽고 즉시 처리할 작업을 결정한다는 의미다. 새로운 메일을 받게되면 분류하거나 처리하는 작업을 절대 미루지 않는다.

  • Action
    • 조치를 취해야 하는 모든 이메일이 표시된다. 기한이 있는 작업이라면 캘린더나 Task 관리툴에 등록한다.
  • Waiting For
    • 다른 사람의 작업 완료를 기다리는 메일에 지정한다.
    • 내가 누군가에게 메일을 보냈고, 받은 사람이 처리하기를 기다린다는 것을 기억할 필요가 없다.
    • 이 메일에 대한 응답을 받으면 레이블을 제거한다.
  • Reference
    • 나중에 다시 봐야할 수 있는 정보는 관련 폴더에 저장한다.
    • 메일내 폴더 혹은 원드라이브에 폴더를 지정하여 관리중이다.
  • Archive
    • 작업이 완료된 이메일은 날짜별로 메일내에 폴더를 만들어 관리한다.
      • 2021/12, 2022/01, 2022/02 …

적용해보기

  1. Label 설정 : Action, Waiting For, Reference
  2. 받은 편지함을 정리하여 0(Zero)으로 만들기
    1. 메일을 확인하기 위한 시간을 확보
    2. 메일에 라벨을 지정
    3. 작업이 완료된 받은 편지함의 모든 메일을 보관
  3. 받은 편지함 관리
    1. 받은 편지함의 메일을 검토
    2. 각 메일을 읽고 무엇을 할 것인지 결정
      1. 즉시 답장을 보낸다.
      2. Action 폴더로 이동
      3. 나중에 참조해야 할 경우 Reference 폴더로 이동
      4. 필요 없는 메일일 경우에는 삭제
    3. 메일 답장 후 응답을 받아야 하는 경우 나중에 처리 할 수 있도록 “Waing For” 라벨 지정
  4. 많은 양의 메일로부터 해방되기

메모

사용 툴: Google Keep, Notion

내가 사용하는 메모툴은 다양하지만, 주로 이용하는 툴은 Notion과 Google Keep이다. 특히 Google Keep의 경우 스마트폰을 사용하여 메모를 작성하거나, 사진을 찍어 메모에 추가하고, 알림으로 활용한다.

특히, Google Keep의 경우 시간외에 장소에 대한 알림을 제공하기에 매우 유용하다. 그리고 Google Calendar와 연동되기에 캘린더에서 모두 확인할 수 있는 장점이 있다.

  • 필기 하기
  • 작업 관리
    • 메일로 관리되지 않는 작업은 Google Task나 Google Keep을 통해 관리한다.
  • 반복 작업에 대한 체크 리스트
    • 반복적인 작업들은 Task를 설정하여 놓치지 않도록 관리한다.
  • Reference
    • 필요할 때 참조할 수 있는 항목에 대해 관리한다.
    • Google Keep에 “Reference”라는 태그로 지정하고 관리한다.

메모를 정리하기 위해 라벨을 사용한다. 모든 메모에는 여러 개의 라벨이 있을 수 있다. 그 이유는 메모를 찾기 유용하기 때문이다.

  • @Action
  • @Reference
  • Checklists
  • Agenda
  • Project specific notes

위 라벨로 메모를 관리하고 있다.

적용해보기

  1. Keep에서 라벨을 설정한다.
  2. 라벨 설정 예시
    1. 해야할 작업 - @Action
    2. 회의록등을 작성하기 위한 프로젝트 노트 - Project specific notes
    3. 중요한 미팅을 위한 의제 - Agenda
    4. 아이디어 및 영감 관련 노트 - Incubator
  3. 메모 작성시 라벨 지정
  4. 중요한 메모는 고정
  5. 일반적인 활동에 대해 체크리스트 작성

캘린더

사용 톨: Google Calendar, Outlook Calendar

주로 Google Calendar를 이용하는 편이다. 매일 하루가 끝나면 다음 날 일정을 검토하고 미비된 것이 있는지 확인한다. 아침에 출근시 가장 먼저 확인하는 것이 캘린더이고 모든 일정 15분전에 스마트폰으로 알림을 받도록 설정해두었다.

시간이 정해져 있는 모든 활동과 정보를 추적하기 위해 캘린더를 이용한다. 위에서 언급한 메모도 캘린더에서 확인할 수 있다. 개인 일정 및 업무 일정도 라벨을 지정하여 한 곳에서 볼 수 있도록 설정했다.

  • 그날 해야 할 일을 빠지지 않고 확인할 수 있다.
    • 일회성 알림
      • e.g. 요청한 응답이 왔는지 체크하기
    • 정기적 알림
      • e.g. Weekly 작성하기
  • 미틸
  • 작업을 완료하기 위해 예약된 시간 블록
    • Focus time을 활용한다. 내게 주어진 작업을 완료하기 위해 드물지만 일정이 촉박할 경우 Focus time을 확보해둔다.
  • 휴가 및 휴일
    • 내 휴가외에 팀원들의 휴가도 기록한다.

적용해보기

  1. 한 곳에서 모든 캘린더 보기
    1. 개인 및 업무 캘린더 추가
  2. 각 프로젝트에 대한 캘린더 설정
    1. 각 프로젝트별 고유 색상 지정
  3. 일정 알림 설정
    1. 반복 작업
    2. 미팅등

마치며

GTD 방법을 이용한 관리 방식은 개인차가 있을 것 같다. 나의 경우는 작업들을 효율적으로 관리하기 위한 방법인 GTD를 오래전부터 적용하여 습관화가 되어서 편하고 효율적이라고 느끼지만 그렇지 않을 수 도 있을 것 같다.

어쨌든, 밀려오는 업무를 효율적으로 처리하는 방법은 필요하다고 생각한다.

21년의 마지막 날이다. 22년에는 21년보다 나은 내가 될 수 있기를…


12/08/2021

스토리 포인트 바르게 사용하기

Written by Giljae Joo (주길재)  in , ,   with 댓글 없음

 

스토리 포인트는 팀이 특정 기능을 개발하는데 필요한 노력의 양을 추정하기 위한 편리하고 효율적인 측정 기술이다.

스토리 포인트는 추정치이다. 추정은 예측을 하는 것이고 실제 사실과는 다를 수 있다. 애자일 및 스토리 포인트의 제작자도 정기적인 스프린트 기대치를 충족시키지 못했다고 한다. 경영진은 숫자, 약속, 속도등을 원하기에 스토리 포인트를 이용해 그들을 즐겁게 한거라고 한다. 결국 스토리 포인트를 추가함으로써 경영진을 행복하게 만드는 방법을 찾은 것이다. (믿거나~ 말거나~)

일반적으로 사용자 스토리가 주어지면 스토리의 복잡성을 숫자로 추정한다. 1-5 혹은 1-10 범위로 제한되며 때로는 큰 추정치로 작성한다.

예전부터 스토리 포인트를 사용했었다. 스토리 포인트가 팀의 작업 능력을 식별하는 데 도움이 된다고 생각했다. 그러나 이번에 진행을 하면서 스토리 포인트와 퍼포먼스 측정을 내가 잘 사용하고 있는가에 대한 의문이 들었다.

몇 가지 가정을 해보자. 모든 개발자가 동등한 역량을 지니고 있고, 유사한 스킬을 가지고 있고, 전체 스프린트에 걸쳐 있고, 다른 스프린트에 속하지 않는다면, 예측 가능한 시간으로 작업할 수 있기에 추정치와 비슷하게 나올 것이다. 하지만 현실에서는 거의 불가능하다고 생각한다. 그 이유는 아래에 언급한 것들을 세세하게 고려하기가 어렵기 때문이다.

  • Lamp-up 타임 (문제를 이해하고 그 문제를 해결하는 시간) - 사람마다 다르기에 이 부분이 고려되어 있지 않다.
  • 방해 타임 (회의, 1:1 미팅, 비즈니스 우선 순위 변경, 개인 사유등)
  • 숨겨진 작업

스토리 포인트는 무엇을 추정하는데 사용되는 것일까? 고정된 크기의 스프린트와 정확한 포인트 추정치가 존재한다면, 예측 가능한 번다운 비율이 있어야 한다. 이를 통해 고정된 시간 내에 수행될 작업을 매우 정확하게 예측할 수 있게된다. 그러나 현실에서는 정확한 포인트 추정을 할 수 없다. 그래서 번다운 비율을 예측하기가 어렵다. 그렇다고 해서 스토리 포인트가 가치가 없는 것은 아니다.

스토리 포인트의 역할은 복잡성을 측정하는 것이다.우리팀이 스프린트당 얼마나 많은 복잡성을 처리 할 수 있는지에 대한 추정해 볼 수 있는 것인데, 단순히 시간과 같은 것으로 생각했던 것 같다. 일반적으로 포인트1당 = 하루로 계산했던 것 같다. 물론 이렇게 계산하는게 내부적으로도 편하고 경영진과 의사소통하기에도 무난했지만, 이는 잘못된 방식인 것을 깨달았다. 스토리 포인트는 관리를 위한 것이라기보다는, 팀을 위한 것인데… 이 부분을 놓쳤던 것 같다.

우리 인간의 두뇌는 하루에도 많은 일을 처리하고 있다. 팀원들은 시간을 기능으로 바꾸는 기계가 아니다. 즉, “8시간이 하나의 기능을 의미한다면 16시간에는 2개의 기능을 의미한다.” 처럼 잘못된 것으로 인지 될 수 있다. 이것은 사실이 아니기 때문이다. 인간이 하루에 집중할 수 있는 시간은 생각보다 많지 않다고 생각한다. 스토리 포인트가 5점이라고 해서 1점보다 5배의 시간이 걸린다는 의미는 아니고 1점보다 5배 더 복잡하다는 의미로 생각해야했다. 일반적으로 5점짜리가 1점짜리보다 더 많은 시간이 걸릴 가능성이 매우 높기에 이를 시간으로 환산 하려 했던 점이 잘못되었던 것 같다.

이번에 Jira를 세팅하면서 제품 백로그를 추정하기 위해 스토리 포인트를 사용했다. 하지만 스프린트 백로그는 포인트 단위가 아닌 시간 단위로 추정하도록 했다. 즉, 스토리 포인트는 복잡도/장기적 관점에서 활용하고 스토리 포인트는 스프린트 시간으로 나누는 방식이다.

앞으로 스토리 포인트는 팀이 현재 스프린트의 복잡성 추정하는 용도로만 사용할 것이다.

References

  • https://rigidity.medium.com/agile-waste-story-points-pt-1-a9df2572d0a3
  • https://www.leadingagile.com/2018/12/the-problem-with-story-points/