Henesis Wallet 제품을 운영하면서 느낀 것들

1년 반 정도 Henesis Wallet 제품을 운영하면서 잘했던 부분, 아쉬웠던 부분

훈련소 가기 전에, 그리고 팀을 옮기기 전에 Henesis Wallet 제품을 운영하면서 느낀 것들을 정리한다.

DevOps

데브옵스팀이 제품팀과 분리되어있을 때 조직 간의 경계 때문에 너무 힘들었다. 인프라 업무를 차치하고, 지금 돌이켜봤을 때 팀이 분리되어있을 땐 조금 과장해서 말하면 데브옵스라는 놀이를 하고 있었다. 제품을 만드는 사람들이 어떤 것이 힘든지 알기가 너무도 어려웠다. 처음에는 커뮤니케이션 채널이 마땅치 않아서 그들의 목소리를 잘 못 듣는 게 아닐까라고 생각했지만 지금 생각해보면 조직 구조와 같이 다른 곳에 더 큰 원인이 있었던 것 같다.

팀이 합쳐지고 Henesis Wallet 제품 백엔드 관련 작은 테스크를 받았다. 컨텍스트를 잘 몰라 작업했던 것을 한번 다 엎기도 했다. 내가 개발하고 PR이 올라간 후에 ‘이것은 A라는 것 때문에 이렇게 하지는 않기로 했다.’라는 이야기를 듣고 다시 revert 하고 방향에 맞게 수정했다. 개발을 마친 후에는 통합 테스트를 해야한다. 단순히 API를 호출하는게 아니라 SDK를 통해서 호출해야한다. 누군가가 개인적으로 테스트하기 위해 만든 스크립트를 받아서 그걸로 내가 수정한 API를 호출해야한다. 스크립트가 실패한다. 그래서 실패한 원인을 찾기 위해 로그, 모니터링 시스템에 들어간다. 그런데 정확히 내가 날린 요청이 무엇이고 실패한 원인을 한 눈에 파악하기가 너무 어렵다. 어찌어찌 다른 개발자의 도움을 받아 같이 살펴본 결과 누군가 개발 디비의 값을 잘못 바꿔놔서 실패했다.

통합 테스트를 마치고 이제 스테이징 환경에 올리기 위해서 태그를 달아야했다. 그런데 master 브랜치에 바로 태그를 다는 것이 아니었다. 마지막으로 배포된 태그의 브랜치에서 내가 작업한 커밋만 따로 빼서 새 브랜치를 만들고 거기에 태그를 달아야 했다.

이런 간단한 테스크를 왜 진작에 해보지 않았을까라는 생각이 들 정도로 솔직히 불편한 것들이 많았고 이런 것들을 미리 캐치하지 못하고 개선하지 못했다는 사실이 다른 사람들에게 미안하기도 했고 자책으로 다가왔다. 만든 제품, 서비스만 개밥 먹기 할 것이 아니라 제품을 만들어나가는 프로세스도 개밥먹기가 필요하다.

개발 테스크를 진행하는 것뿐만 아니라 이슈 해결도 마찬가지이다. 직접 이슈를 해결하는데 참여하면서, 그리고 옆에서 정말 가깝게 관찰하는 과정을 통해서 개발 프로세스 때와 비슷한 심정을 느꼈다. 이슈와 관련된 데이터 (로그, 메트릭)를 관련 지어 보지 못하면 원인 파악에 시간이 오래 걸린다. 내가 대시보드에서 클릭을 해서 에러가 발생했는데 그게 이 로그인지 저 로그인지 구분이 안되고 트레이싱도 구분이 안되면 힘들어진다. 스케쥴러도 자신이 죽었을 때 로그나 덤프 데이터를 제대로 남기지 않고 죽으면 정확한 원인을 파악하기 힘들어지고 API에서 타임아웃이 발생했을 때 어떤 파라미터가 왔을 때 터졌는지 알지 못하면 재현과 원인 파악이 힘들어진다. SRE 책에서 멋있게 나오는 Service Visiability가 다른게 아니고 이런 경우에 필요하다고 생각했다. 모든 제품에서 공통적으로 필요한게 있을 수도 있고 제품에 따라 특수하게 더 필요한 것들이 있을 것이다. 단 정보를 찾아볼 때 파편화되어 있는게 아니라 한 곳에서 일관된 방식으로 찾아볼 수 있어야 한다.

서비스 도메인을 잘 알지 못해 도움을 주는 것이 굉장히 한정적일 때가 많았다. 지금 생각했을 때 제품의 인증, 권한, 보안 정도만이라도 자세하게 알았더라면 어땠을까라는 생각이 든다. 제품에서 너무 멀리 떨어지지 말자.

다른 사람과 이야기를 통해서도 문제점을 찾을 수 있지만 많은 경우 그 사람도 문제점이 뭔지 모를 경우가 많다. 그 사람이 해야할 일이 너무 많아 문제점에 대해서 생각해볼 여유가 없었을 수도 있고 이미 시스템에 너무 익숙해져서 이게 이제 자연스러운 과정이라고 느낄 수도 있다.

프로덕션에서 권한 때문에 서로의 시간을 많이 잡아먹을 때가 많았다. 시크릿 변경이 그 중 하나이다. 변경 권한을 가지고 있는 사람들의 수는 매우 적고 그 사람들의 시간은 많이 없다. 자연스레 변경 권한을 가지고 있는 사람에게 병목이 생긴다. 관리자가 스스로 액션을 할 수 있도록 상황별 행동을 프로세스화를 하거나 어드민 페이지와 같이 플랫폼화 하면 운영자의 근심, 스트레스를 줄일 수 있고 관리자와 운영자의 커뮤니케이션 코스트도 많이 줄일 수 있겠다.

혹은 아예 관리자가 액션을 해야하는 상황을 없앨 수는 없을까?

막연하게 비대칭키와 같은 구조로 권한을 설계할 수 없나라는 생각이 있다. 변경을 할 수 있어도 그것만으로는 별 위험이 생기지 않는다. 최종적으로 반대편의 승인이나 자동화된 어떤 과정을 통해서 최종적으로 가능해진다. 팀원들이 업무에 필요한 정보에 최대한 접근할 수 있고 각자가 독립적인 의사 결정을 하더라도 안전한 시스템이 어떤 것일까라는 생각을 많이 한다. 이상적이지만 상상해본다.

Engineering

최근에 가지고 있는 생각은 엔지니어로써 단순히 무언가를 만드는 것 이상으로 비즈니스적인 가치를 만들기 위해 기술을 사용해서 회사 다른 영역의 사람들에게 도움을 줄 수 있지 않을까라는 생각이 많이 든다. 최근까지도 ‘어떤 것을 만들어낸다’에 좀 더 포커스가 있었더라면 조금 더 넓은 영역으로 생각하는 물꼬가 트일 수도 있겠다라는 생각이 든다. 데이터라는 영역이 그 중 하나이다. 이 부분도 데브옵스와 비슷한 고민이 있을 것 같다. 제품팀과 데이터팀이 따로 있으면서 사일로가 있고 특정 파이프라인을 추가하고 변화하는 제품에 대해 해당 파이프라인을 유지 보수 및 개발 하려면 많은 코스트가 들 것이다. 또한 제품을 만드는 과정에서 기능적인 영역뿐만 아니라 데이터 수집 및 분석 영역에 대한 구현도 같이 진행 되면 후에 이걸 따로 만드는 비용이 훨씬 적게 들어가지 않을까라고 생각해본다.

영역 제한 없이 조직에 기술적으로 필요하거나 도움을 줄 수 있는 어떤 것을 만드는 사람으로 있고 싶다. 그리고 다른 사람들과 더 적극적으로 의견을 이야기해서 공감을 얻은 후 크게 실행하는게 중요하다는 것도 알았다. 이따금 왜 진작에 공감을 얻지 못하고 큰 액션을 하지 못했을까라는 아쉬움이 들 때도 있었다.

Team

팀의 복잡도는 인원이 늘어나면서 기하급수적으로 올라간다. 매일 새로운 정보는 어딘가에 쌓이고 새로운 사람들이 계속 들어오면서 과거에 있던 컨텍스트를 효율적으로 전달하는게 중요했다. 그렇지 않으면 모든 과정이 사람들의 커뮤니케이션 코스트 및 유지 보수를 위한 코스트로 들어간다.

문서화에 대한 생각. 조직이 커지고 시간이 지나면서 정보가 파편화되고 outdated 되고 찾아보기 어렵고, 잘 찾아보지 않게 된다. 정확한 정보를 찾는데 시간이 많이 걸리고 구전으로 전해지고 남에게 물어보는 게 일반적인 방식이다. 정보가 필요하면 문서를 찾는게 아니라 슬랙을 통해 다른 누군가를 부른다. 그래서 찾아본게 Gitlab의 handbook 문화였다. 이 조직은 문서화 문화가 가장 기반이 되는 조직이 아닐까 싶었다. 모든 사람이 원격근무를 하기 때문에 커뮤니케이션 코스트를 줄이는데 충분한 장치가 없었다면 조직의 속도가 느리고 사람들이 업무에 집중을 하지 못하는 환경이 되지 않았을까.

한 때는 이런 생각도 했다. 계속 시스템이 바뀌면서 문서는 outdated 되는데 그러면 차라리 시스템에 따라서 문서를 자동으로 생성되게 하면 어떨까? 이 생각때문에 노션 API 문서 기웃거린적이 한 두 번이 아닌 거 같다. Infrastructure as Code 와 반대로 시스템 상태를 읽기 좋은 형태의 메타데이터 집합으로 출력할 수는 없을까? 전사 문서가 아니라 제품, 그리고 제품 개발과 관련된 문서로 한정해서.

진지하게 Gitlab의 handbook 문화를 차용해보면 어떻게 될까, 가져온다면 어떻게 시작해볼까, 어디까지 가져와볼까라는 상상을 한다. 실패하더라도 또 이렇게 얻어가는 것들이 있지 않을까?

스프린트의 복잡도도 마찬가지이다. 특정 시기에 2-3주간 했던 작업들을 QA하고 배포해야하기 때문에 사람이 많아질수록 변경 사항 관리가 크게 올라가는 것 같다. 그리고 이번에 배포 타이밍을 놓치면 다음 2-3주를 기다려야 배포를 할 수 있다.

대부분의 테스크 스케쥴이 길어지는 것 같다. 제품팀 업무 관리를 직접 해보지 않아서 적기가 조심스럽지만 스프린트는 테스크 스케쥴이 길어지는 상황에 대해서 유연하게 대응을 하지 못하는 것 같다. 정해진 기한 동안 카드를 치고 그리고 해당 카드들을 배포하고 다음 스프린트에 또 새로운 카드들을 추가한다. 스프린트 주기, 다시 말해 배포 주기가 길어질수록 스토리 포인트 합계의 편차가 더 심해질 것이다.

그래서 테스크 일정이 미뤄지는 상황에 대해 QA, 배포 일정이 유연하게 조정되면 좋겠다고 생각했다. 그러다보니 칸반이 떠올랐다. 배포 주기를 매우 짧게 1주에 한 번 하고 매주마다 오는 기차에 탑승하듯이 배포 준비가 된 카드들은 매주 오는 배포 기차에 실어서 프로덕션에 배포한다. 그리고 백로그에 남은 카드가 N개 이하가 되거나 중요한 비즈니스 결정이 내려졌을 경우 혹은 엔지니어 판단에 따라 필요한 작업이 생기는 경우 카드를 만들어서 정기적으로 혹은 비정기적으로 넣는다. 하지만 이런 과정의 전제는 QA와 배포 프로세스가 가벼워야 한다는 것이다. 왜냐하면 엄청 자주 일어날테니까.

나 포함 두 명이지만 데브옵스팀 매니징을 했을 때 잘했다고 느끼는 것은 우리가 하는 일들을 카테고리화하고 각 테스크별 포인트를 부여하여 1 스프린트 동안 어느정도 태스크를 수행할 수 있을지 수치화했다는 것이다. 데브옵스 업무 전체를 놓고보면 크게 스프린트 업무, Toil 업무, 이슈 대응 세 가지가 있었고 각각에 점수를 부여해서 우리가 1 스프린트 동안 몇 포인트의 업무를 수행할 수 있는지 파악했다. 빠짐없어야 한다는 게 중요하다. 그래서 이슈 대응이 많아지는 경우는 스프린트 업무를 어느정도 끝낼 수 있을지 예측이 됐고 이에 따라 일정을 어떻게 조정해야할지 감이 왔다. 포인트의 경우 매우 쉬움(1점), 쉬움(2점), 보통(5점), 어려움(13점)으로 크게 나누고 각 난이도별 기준을 설정하여 테스크 별 포인트 책정 시간이 오래 걸리지 않도록 했다. 이 중 업무 속도를 높이기 위해서 매우 쉬움, 쉬움 난이도의 테스크는 리뷰 없이 코드 병합(merge)이 가능한데 이는 이 두 난이도의 테스크는 이미 프로세스화 되어 있거나 이미 서로가 충분히 컨텍스트를 많이 공유했기 때문에 결과에 대한 기대치가 비슷한 상태이기 때문이다.

Love

좋은 프로세스, 좋은 시스템이 있다하더라도 개발하고 운영하는 제품과 사람들에게 애정과 관심이 없다면 그 때부터는 하락장이라고 생각한다.