22년은 무슨 일을 했는지 모르겠다.
쏟아지는 일정을 우선순위에 맞게 쳐내다가 한 해가 지나간 것 같다. ASAP으로 위에서 내려오는 요구사항들을 만족시키다보니 여유를 갖고 보수하거나 개발할만한 시간이 부족했던 것 같아 아쉽다.

업무 자동화, 혹은 프로젝트 완성

이슈 대응을 위한 bot을 만들면서 업무 자동화라는 생각을 했다. 우리 파트 리더께서 이건 ‘업무 자동화가 아니라 프로젝트를 제대로 완성하는 것’이라는 말씀을 하셨다.
이슈 대응을 위한 프로세스까지도 프로젝트의 일부인데 우리가 놓쳤다는 것.

맞는 것 같다.
그런데 통계며 이슈 대응까지 생각하며 프로젝트를 설계하고 완성하는게 사실 쉽지 않다.
올해처럼 바쁜 일정에는 더더욱이. 그래도 올해 했던 일들을 정리해본다.

1. 이슈 대응 프로세스 만들기

우리가 맡은 한 모듈의 클라이언트는 이슈 대응을 위해 한 달에 약 80건 정도의 요청을 한다.
우리는 여태까지 이걸 받으면 빠르면 한 시간에서, 늦으면 일 주일 내로 스크립트를 돌려서 결과가 나오면 응답해주는 프로세스를 갖고 있었다.
생각보다 오래 걸리지 않지만 컨택스트 스위칭 비용이 컸던 일이다.

하루는 이 작업을 하다가 재미가 없어서 재미있는 일로 바꾸기 위해 slack bot을 만들었다.
일주일 정도 일이 끝나고 시간을 조금씩 써서 작업한 봇으로 클라이언트 이슈 대응을 대처했다.

봇 제작으로 얻은 효과

  1. 이슈 대응에 드는 시간 월 40시간 감소 (30분 * 80건)
    • 봇 도입 이후 클라이언트는 대응이 늦어 요청하지 못한 요청을 더 많이 했다.
  2. 이슈 대응을 기다리는 클라이언트 대기 시간 월 80일 감소 (평균 1일 * 80건)
    • 말 그대로 대기시간이기 때문에 일을 못하는건 아니지만, 필요한 경우 주말에도 바로 응답받을 수 있는 프로세스가 구축되었다.
  3. 봇 제작을 한번 해보니 기능 추가는 쉬워서 다른 모듈에서 사용할 기능들도 봇에 추가되었다.

2. 서비스 장애를 보고받기

우리는 grafana를 통해 서비스를 모니터링하는데, grafana는 자주 보게되지 않는다.
모듈마다 다른 임계 성공률(예를들면 99.0%) 이하로 떨어질 경우 알람을 받게 되는데 신규 모듈에는 ‘우리가 모르는 500에러는 없게하자’는 생각으로 개발을 시작했다.
예측되는 장애 상황에 slack noti를 날리는 aws lambda를 구축해서 500 에러 장애 상황을 바로 확인할 수 있도록 구현했다.

3. 통계 설계하기

이미 완성된 모듈에서 통계를 뽑는건 곤혹이다. 일 년에 한 두번 요청하는 통계를 뽑는데 db를 dump하는 작업을 하거나 1년치 로그를 조회하는 경우가 있었다. 신규 모듈에서는 설계 시점부터 통계를 같이 설계하려고 노력하고 통계를 정리하는 배치 모듈을 같이 개발했다.

tactical DDD

작년부터 이어지는 DDD를 통한 개발. 우리팀은 작년 말부터 하나의 모듈을 개발했고, 연중에 하나의 모듈을 리팩토링하고, 연말에 하나의 모듈을 새로 개발했다.
총 세 건의 모듈을 DDD로 개발하면서 DDD에 대한 개념을 제대로 익힐 수 있었던 것 같다.

올해 나는 Vaughn Vernon의 Implement Domain Driven Design의 tactical 부분을 읽고 정리했다.

  1. domain events
  2. Value Object
  3. Domain Service
  4. Entity
  5. aggregate

사실 개념들을 요약해서만 읽어도 ‘아하 이거구나’ 싶지만 개발할 때 팀원들 간의 DDD에 대한 이해도와 생각은 다 달랐다. 정리한 내용들을 팀 내에 짧게 공유하기도 하고 내용을 기반으로 배운 것들이 많았다.
덕분에 설계 능력도 성장한 것 같다.

1. aggregate

aggregate은 반버논 아저씨도 DDD에서 가장 애매하다고 말한 부분이다.
우리 팀 내에서도 의견이 가장 분분했던 부분이기도 하다.

우리는 한 모듈을 엄청나게 큰 aggregate으로 작성했는데, 사실 이게 코드스멜이 느껴져서 aggregate에 대해 공부를 더 해보게 되었다.
책에서 말하는 큰 aggregate의 단점을 직접 설계한 모듈에서 느낄 수 있어서 더 배울점이 많았던 것 같다. aggregate은 크기도 중요하지만 어떤 기준으로 나누느냐가 굉장히 중요하다는 것을 배웠다.

2. domain events

사실 우리팀은 domain event를 사용하는 팀이 아닌데, 이 개념을 공부하고 팀 내에 공유하고 나선 domain event를 적용해야 하는 부분들이 꽤 많았다라는 피드백을 받았다.
domain model의 commit 시점에 event를 전달하고 이걸 처리하는 프로세스가 우리 프로젝트에 바로 적용하기 애매해서 거의 적용하진 못했다. 그치만 ‘이건 domain event면 좋았겠다’라는 생각을 할 수 있게 되었다.

팀

우리 팀은 팀 단위의 협업이 잘되고 효율도 좋다고 생각한다. 올해는 우리 팀의 프로세스 몇 가지가 좋은 방향으로 변경되었다.

1. 스토리 표준화와 명확하게 나누기

우리 팀은 작업의 단위를 스토리로 나눈다. 올 해는 개발 스토리를 정리하면서 표준화 하는 작업을 했는데 이 작업을 통해 스토리를 만드는 시간도 줄고, 스토리에서 놓치는 작업없이 마무리할 수 있었다. 표준화된 개발 스토리는 이렇다.

  1. 구현 설계
  2. acceptance test 작성
  3. interface 구현
  4. scenario test 작성
  5. domain 구현
  6. usecase 구현
  7. scenario test pass
  8. acceptance test pass
  9. 회고하기

이런 알찬 구성에서 필요하지 않은 카드는 설계를 하면서 제거한다.
예를 들면 domain의 일부만 수정되어 외부 변경사항이 없다면 test나 interface 카드는 삭제하는 식이다. 스토리를 명확하게 분리하면 팀원들간에 작업 분배가 원활하다.

2. 스토리 포인트 추정

우리는 원래 시간 단위의 추정을 해왔다. 스토리 포인트라는 개념이 처음엔 낯설었는데 스토리 포인트로 작업량을 기준으로 추정을 하는 방식으로 추정 방식을 변경하였다. 스토리 포인트 추정과 팀의 MH를 통해 우리가 어느정도의 스토리를 처리할 수 있는지를 정리하고 있다.

재밌는건 리더는 스토리 포인트를 최대한 많이 가져가려고 한다는 것. (우리는 스크럼 리더를 돌아가면서 한다)

3. 우선순위 기반 일정 관리

원래도 스토리들을 backlog에 쌓아두고 일정관리를 했었지만. 올해는 스토리들에 우선순위(high, mid, low)를 두고 우선순위를 조정하면서 스크럼을 진행했다. 가장 급한 우선순위들을 먼저 보고 스프린트 계획을 세우는 방식이다. 한 눈에 우선순위가 들어오고, 우선순위와 우리가 추정했던 스토리 포인트를 기반으로 스프린트의 스토리들을 결정했다.

결국 할 수 없는 수준의 스토리를 스프린트에 가져온다거나 사실 급하지 않은 일을 먼저 처리하는 일들이 줄었다. 중요한 일들을 할 수 있을지를 어느정도 판단해서 스프린트를 세울 수 있었다.

4. 번외. 팀 리더

연 말에는 회사에서 교육을 가게 되었는데 교육 마지막엔 일주일짜리 팀 프로젝트가 있었다. 서로 다른 팀에서 온 사람들과 진행하게 되었는데. 이 교육 마지막 날 밤을 세워 프로젝트를 마무리하는 팀들도 많다고 했다. 팀이 첫 회의를 할 때 프로젝트 설계를 제대로 진행하는 분위기가 아닌 것 같아서 내가 리더아닌 리더 역할을 하게 되었다.

설계 회의, 설계 내용 공유, 테스트 작성, 인터페이스 작성과 작업 분배.
우리 팀이 팀 단위의 일과 리더로서의 역할을 잘 해내고 있다는 것을 느낄 수 있었고. 처음으로 다른 팀에서 리더를 해본 경험이라 재미있었다.

올해의 교훈은 같은 일을 같은 방식으로 하면 재미없다.
새로운 일을 하려고 하는데 쉽지 않았다. 내년에는 새로운 일을 아니면 새로운 방식으로 좀 더 재미있게 일할 수 있었으면 좋겠다.