팀을 옮기고 올해는 새로운 것들을 배워 재미있는 시간들이었다.
팀 내에서 연간 회고를 진행했는데 회사에서의 나의 회고와 회고를 준비하며 느낀 올해에 대해 정리해본다.
설계
올해 팀을 옮겨서 배웠던 것 중 가장 크게 배우고 느낀 것은 설계에 대한 부분이다.
이전 팀에서는 유지/보수가 대부분인 업무에 새로 무언가를 개발하는 일은 잘 없기 때문에, 제대로 된 설계 회의를 진행해본 적이 없었다. 팀을 옮기고 새로운 모듈 개발과 이어지는 배치 개발을 위한 반복된 설계가 개인적으로는 배울 점이 많았다.
설계 회의에 참여해서 구조를 생각하고 그려나가고 토론하는 것이 도움이 많이 되었는데, 어떻게 토론을 해나가고 어떤 부분을 짚어나가야 하는지 알 수 있었다.
처음에는 경험이 적다보니 아 그렇구나 하고 넘어가던 설계들이 나중에는 나는 이렇게 생각했는데 팀원들 아이디어가 좋구나 하고 넘어가는 경우도 많았다.
아직은 배워가는게 크지만 내년에는 내가 더 많이 설계에 영향을 미치면 좋겠다는 생각이 든다. 설계는 남기고 싶은 내용들이 있어 따로 정리해본다.
동기화 작업
우리는 단말 앱과 연관이 많은 동기화 서버를 개발했다.
처음부터 시작하는 동기화와 현재 어디까지 동기화 되었는지를 구분하기 위한 값을 단말에 제공한다.
이 값은 이렇게 설계된다.
- 단말이 이해할 수 없는 값이어야 한다. 따라서 우리만 아는 데이터를 암호화하여 내려준다.
- 단말이 이해할 수 있다면, 특정 유저라거나 특정 값의 데이터를 단말이 직접 수정할 수 있으면 우리가 통제할 수 없는 동기화 시나리오가 발생하거나 다른 이슈가 생길 수 있다.
- 단말이 임의로 수정하면 동기화 에러가 나야한다.
- 위와 동일한 이유이다. 동기화 에러가나면 초기 동기화(처음부터 시작하는 동기화)를 할 수 있도록 값을 내려주고 유도한다.
동기화 서버를 개발하면서 우리한테 쌓인 노하우가 아닌가 싶다.
배치
우리가 관리하는 서비스 하나는 배치 서버가 네 대가 있다.
필요해 의해 하나씩 추가되다가 이렇게 되었는데 참 번거롭고 헷갈리기도 하다.
새로 모듈을 만들면서 배치를 설계할 때는 기존의 구조를 따르지 않도록 batch job이 추가가능한 배치 모듈을 설계하려고 노력했다.
kafka를 통해 연결된 배치 서버를 개발하고 여러 job task를 수행할 수 있도록 설계하고 필요하다면 task를 추가 설계하는 방식으로 구현했다.
서비스 말고도 배치 서버도 초기 설계가 중요하다는 것을 많이 느꼈다.
그리고 delete는 최대한 안전하고 정확하게 진행되어야 한다는 것도.
언어
golang을 공부하고 배치에 적용한 것도 기억에 남는다.
golang 스터디를 하고 잠깐 잊고 지냈는데 기존 batch의 성능을 개선하는 작업을 하면서 batch를 golang으로 설계했다.
language의 중요성을 이번에 느끼게 되었는데 이렇다.
- 기존의 python batch가 성능이 굉장이 안좋았다.
- 한 눈에 봐도 개선의 여지가 명확했고 일부 로직을 개선한 python batch로 업그레이드?했다.
- golang의 go routine(경량 thread)와 빠른 성능이 좋은 효율을 발휘할만한 상황으로 보였다.
- language 변경하고 설계하여 다시 개발했다.
- 단일 ec2 기준 100배에 가까운 성능 개선이 이뤄졌다.
이번 작업을 하면서 느낀 것은
- 개발 없이 스터디 하는건 오래 남지 않는다.
- 코드는 부패하기 마련이고 잊혀진다.
- 언어가 중요하다.
- golang이 굉장한 효율을 발휘하는 부분들이 있다.
- 특히 경량 쓰레드는 굉장하다.
자동화
작년에 여러 작업들에 걸쳐서 (거창하게 표현하면) 자동화가 많이 진행되었다.
이런 자동화 작업들은 내가 생각하기에 이런 장점들이 있다.
- 귀찮은 작업들을 이젠 하지 않아도 된다.
- 반복된 업무는 귀찮지만 자동화 툴을 만드는건 재밌는 작업이다.
우리 팀은 올해 이런 작업들을 자동화 했다.
- WAS나 batch에서 error나 issue에 대해 slack noti 적용
- 우리가 새로 만든 모듈에서 500 error에 대해 slack noti를 적용하고 이 모듈에서는 우리가 알지 못하는 500 error는 없도록 유지보수를 하고 있다. 모르는 500 error가 나온다면 바로 노티를 받고 수정에 들어간다. (부끄럽지만 다른 모듈은 아마 500 error가 좀 있을 것 같다)
- Grafana나 지표는 만들어놔도 손이 잘 안가기 때문에 초기 서버에서 이런 작업을 해놓는게 굉장히 서버 관리에 도움이 되었다.
- versioning & release note & 문서 작성
- 우리는 배포 프로세스가 굉장히 귀찮은 편이다.
우선 검증 팀에 변경사항을 문서로 작성해서 보내주어야 하고, 검증이 끝나면 변경사항을 결재를 올려야 한다. 그리고 나서 release note를 작성하는데 이게 참 귀찮아서 날 잡고 자동화를 진행했다. - 문서 작성 프로그램을 python으로 작성했다. git commit과 PR rule을 자동화하기 좋게 convention을 잘 지키면서 convention에 맞는 commit/PR message들을 가지고 major/minor/patch version을 자동으로 계산해서 version을 올리고 수정된 내용들을 정리하는 방식이다. 정리된 내용들과 버전은 검증 문서와 변경사항을 slack으로 보내고, github release에도 자동으로 업데이트 하도록 구현했다. (github / slack api 사용)
- python dockerize를 하여 각 모듈에 circleci에 문서 작성 step 추가해서 docker를 수행하도록 했다.
- 이 작업으로 정말 귀찮고 어떨땐 빼먹기도 했던 문서 작업들이 정리되었다.
- 우리는 배포 프로세스가 굉장히 귀찮은 편이다.
자동화를 통해 업무에 대한 효율과 서비스 안정성을 확보할 수 있었다는 생각이 든다.
그리고 작업을 진행하면 평소에 관심을 두지 않았던, 진행하지 않았던 일들을 진행하게 되니 공부도 되고 지루하지도 않아 재밌게 개발을 할 수 있게 되었다.
그리고 생각보다 자동화가 어렵지 않다는 것을 느꼈다.
문서 자동화는 항상 불편했다. 자동화가 쉽지 않을 것이라 생각했는데 생각보다 쉽고 빠르게 일을 정리할 수 있었다.
테스트
새로운 모듈을 처음부터 개발하면서 우리는 성능 개선이나 요구사항 만족 등을 위해 테스트를 다양하게 진행해왔다.
우리가 진행한 테스트는 아래와 같다.
- unit test
- unit 단위의 TDD에 필요한 단위 테스트
- api test
- 실제 api를 통해 server 밖에서 호출되는 테스트
- scenario test
- api, 기능 단위로 실제 사용자의 호출 flow(시나리오)에 맞게 정상 호출되는지 확인하는 테스트
- performance test
- pin point, locust를 통한 성능 테스트
켄트 백이 말하는 테스트는 항상 마음을 편안하게 해주고 믿음을 준다라는 말이 참 공감이 된다.
여러 테스트를 통해 출시 전, 후로 우리 서비스에 대한 믿음을 가질 수 있었던 것 같다.
이전 모듈들에서 진행하지 않던 scenario 테스트도 추가했는데 테스트가 중요하고 unit/api 테스트에만 의존하지 않고 여러 종류의 테스트가 필요하다는 것을 배웠다.
돌아볼만한 점은 이렇다.
- 중복되는 테스트
- 위와 같이 여러 테스트가 있다보니 중복되는 테스트들이 있다. 테스트가 많으면 느려지기 쉬우니 test의 layer를 명확하게 하면 좋겠다.
- 성능 테스트
- 성능 테스트를 진행할 때 다른 개발을 하느라 성능 테스트 셋업이나 진행에 참여하지 못했는데 아쉽다.
- 테스트 가독성
- “테스트니까” 라는 말을 하기도 하고 듣기도 한다. 테스트는 좀 대충 짜도 된다라는 생각인데, 이게 리뷰할 때 굉장히 불편하고 코드 변경이 생길 때 테스트를 이해하는데 시간도 많이쓰게 되었다.
- 테스트 안에 분기가 있는건 나는 정말 별로다. 그럴거면 테스트를 나눠야된다고 생각한다. 이게 취향인지, 이걸 하려고하는 팀원도 있긴하다.
재미있는 한 해였다.
팀 분위기가 중요하다는 것을 많이 느꼈다.
pair work이나 code review, 회고 등의 개발 문화에 대해서도 많이 느꼈는데, 우리 팀은 이전 팀보다 자신의 생각과 불편할 수 있는 얘기들을 편하게 할 수 있어 참 좋은 것 같다.