안녕하세요! 정산시스템팀의 박우빈입니다.
오늘은 팀 내에서 진행했던 세미나 이야기를 한번 들고 와봤습니다.
가볍게 읽어주시면 감사하겠습니다. 🙂

목적 중심의 팀

정산시스템팀은 목적 중심의 팀으로, 직군별로 나뉘는 ‘역할 중심의 팀’과는 달리 기획자, 개발자가 ‘하나의 목적을 영위하기 위해 모여있는 팀’입니다.
그렇기 때문에 저희 팀에서는 하나의 도메인, 프로젝트 내에서 통용되는 유비쿼터스 언어(Ubiquitous Language)가 매우 중요한데요.
모든 팀원이 다 같이 문맥을 공유하는 유비쿼터스 언어가 제대로 정의되지 않은 상태에서 프로젝트를 진행하다 보면 결국 커뮤니케이션 비용이 필요 이상으로 발생할 수 있기 때문입니다.

작년부터 팀에서 여러 가지 일을 하면서 느꼈던 것 중 하나는, ‘도메인에 직접적으로 관련된 유비쿼터스 언어도 중요하지만, 단순 커뮤니케이션을 더 원활하게 할 수 있는 기반 지식도 서로에게 공유가 되면 좋겠다’는 것이었습니다.

예를 들어, 보통 저희 팀에서는 하나의 일감(티켓)을 진행할 때 기획자 1명, 개발자 1명으로 담당자를 지정합니다.
그 과정에서 담당 기획자와 개발자는 다음과 같은 긴밀한 협의를 진행하게 됩니다.

• 개발 이후 QA를 언제 진행할 것인지
• 공통으로 사용하는 베타 환경에서 다른 일감을 진행하고 있는 분들과 동시에 QA를 진행해야 하는 경우 어떻게 할 것인지
• 베타 환경 QA 이후 운영 환경에 배포하기 전에 스테이징 환경에서 확인해 볼 수 있을지
• (관련 작업인 경우) 내부 어드민 시스템에서 수정된 결과를 확인하기 위해 구체적으로 어떤 검증을 해야 할지
• (관련 작업인 경우) 배치 작업을 신규로 구성해야 하는 경우 스케줄링 및 모니터링은 어떻게 해야 할지

이런 논의들은 작게는 개인에서부터 크게는 파트 및 팀 단위로 수시로 일어나게 되는데요.
논의에서 발생하는 여러 가지 결정 사항들을 뒷받침하고 있는 개발 관련 기반 지식이 팀 내에서 충분히 공유되면, 조금 더 서로가 효율적으로 소통하고 유기적인 협업을 할 수 있지 않을까 하는 생각이 들었습니다.
(물론 한두 번의 공유 시도로 단기간에 큰 효과를 보기는 어렵겠죠 ㅎㅎ)

그렇게 별로 안 궁금했지만 막상 들어보니 은근 궁금했던 개발 이야기 라는 제목으로 팀 내 세미나를 준비하게 되었습니다.

이야기 보따리

팀원분들께 발표한 이야기 주제는 크게 네 가지였는데요.
어떤 내용을 어떤 방식으로 전달드렸는지, 왜 이런 주제를 선택했는지 하나씩 소개해 보도록 하겠습니다.

Git, 버전 관리 도구

가장 먼저 버전 관리 도구인 Git에 대해서 다루었습니다.
Git을 첫 번째 주제로 삼은 이유는 팀에서 다음과 같은 상황이 있기 때문인데요.

저희 팀의 베타 환경은 모두가 사용하는 공통 환경입니다.
서론에서도 말씀드렸듯 각자의 피처(기능) 개발이 끝난 후에는 베타 환경에서 담당 기획자분과 QA 테스트를 진행하게 되는데요.
QA를 위한 베타 배포 과정에서 혹시라도 먼저 QA로 베타 환경을 사용하고 있는 분이 있지 않은지를 안전하게 슬랙에서 체크하고 있었습니다.

예를 들어 A라는 기능을 배포해서 테스트하고 있었는데, 누군가가 B라는 기능을 가진 다른 브랜치로 배포를 해버린다면 A 기능은 갑자기 누락되는 상황이 발생하기 때문이죠.
(추후에는 팀 차원에서 베타 환경의 개인화를 고려하고 있습니다.)

A 버전으로 배포하다가 B 버전으로 배포하거나 하는 경우, 발생할 수 있는 여러 가지 복잡한 상황에서 여러 QA의 우선순위를 정하거나 조율을 해야 할 경우가 생기기 때문에, 이런 상황에 대한 원리적인 접근을 공유해 드릴 수 있다면 더 원활한 소통이 이루어질 수 있지 않을까 기대해 보았습니다.

이런 맥락에서, 배포를 위한 코드 버전을 다르게 가져갈 수 있다는 내용을 말씀드리기 위해 Git에 대한 이야기를 시작했습니다.
먼저, 버전 관리 도구가 존재해야 하는 이유를 다음과 같이 정리했습니다.

• 개발해야 하는 프로젝트 저장소는 하나인데, 가져가서 개발해야 하는 개발자는 여러 명이다.
  • 즉, 하나의 코드 문서를 여러 사람이 수정 반영 해야 하고, 충돌이 생길 수 있다.
• 개발하다가 옛날 코드 상태로 다시 돌아가고 싶은데, 어디를 얼마나 고쳤는지 확인할 수가 없어서 돌아갈 수가 없다.

그리고 아래와 같이 라인 단위로 변경사항을 관리하는 Git의 간단한 원리(커밋)를 소개해 드렸습니다.

라인 단위로 변경된 사항을 묶어서 커밋을 만드는 행위를 메밀소바에 비유하기도 했는데요.
아래처럼 Git graph를 이야기하면서 줄줄이 메밀소바(..) 같은 느낌이라고 표현했습니다.

그리고 이어서 여러 사람이 협업을 할 수 있게 하는 브랜치에 대해 이야기했습니다.
협업 과정에서 코드를 합치다 보면 충돌도 발생할 수 있다는 점과, 현재 베타 환경에서 일어날 수 있는 서로 다른 배포 버전에 대한 이야기를 실제 예시와 함께 말씀드렸습니다.

이렇게 코드 레벨의 이야기를 마무리하고, 이번에는 서버 이야기로 넘어가게 됩니다!

무중단 배포, 스테이징 환경의 원리

2020년, 핀테크 업계 최초로 정산시스템은 온프레미스 환경에서 AWS 클라우드 환경으로 100% 전환에 성공합니다.
이에 따라 IDC 환경에서는 지원받지 못했던 사내 플랫폼들을 뒤늦게 사용할 수 있게 되었는데요.
대표적으로, 간편하게 파이프라인 형태로 배포를 진행할 수 있는 전사 배포 플랫폼인 Simploy를 적용하게 되었습니다.

그러다 Simploy에 있던 여러 기능 중, 최종 운영 배포를 수행하기 전 마지막 테스트를 진행해 볼 수 있는 스테이징 환경 구성 기능을 비교적 최근에 사용하게 되었는데요.
베타 QA와 운영 QA만 진행하다가 새로운 스테이징 환경이 생기니 팀 내에서 환경에 대한 사용법이나 적용할 수 있는 상황에 대한 가이드가 필요한 상황이어서, 팀 차원에서 가이드가 공유되었습니다.

스테이징 환경은 Blue/Green 무중단 배포 시 신규로 구성한 Green 그룹에 미리 접근해서 배포한 버전을 확인할 수 있도록 하는 구성인데요.
(위 장표에서는 설명의 간편함을 위해 로드밸런서가 하나인 것처럼 표현했지만, 실제로는 스테이징용 로드밸런서가 Green 서버 군에 별도로 붙습니다.)

실제 운영 환경으로 스위칭이 될 애플리케이션 환경이기 때문에 베타 환경과 달리 릴리스 내용의 반영 사항을 운영 환경의 설정 그대로 확인할 수 있다는 장점이 있지만, 운영 DB를 바라보고 있기 때문에 사용 시 주의해야 할 점들이 있었습니다.
예를 들어, 정산시스템 어드민에서 가장 중요한 기능 중 하나인 ‘지급 요청’, ‘지급 승인’ 기능은 운영 어드민에서 특정 권한을 가진 운영자만 수행이 가능한데, 스테이징 환경에서 테스트를 목적으로 해당 기능을 테스트하게 되면 실제 운영 DB의 상태 값을 변경하기 때문에 의도치 않은 상황이 벌어질 수 있습니다.

앞서 Git 섹션에서의 이유와 마찬가지로 스테이징 환경에 대한 기저 맥락이 공유된다면 이러한 주의사항 등에 대한 가이드가 더 자연스럽게 공유되지 않을까 하는 마음에 두 번째 주제로 무중단 배포와 스테이징 환경에 대한 내용을 넣어보았습니다.

다음과 같은 순서로 내용을 전개하였습니다.

• 서버란 무엇일까?
• 원래 배포하려면 서비스(서버)를 중단해야 한다.
  • 하지만 배포를 위해 서비스 중단을 원하는 곳은 없다.

• 30초 만에 이해하는 무중단 배포
  • (진짜 30초 시~작! 하고 시간 재면서 설명해 드리다가 진땀 뺐습니다)
  • 사용자가 현재 v1 버전의 서버에 네트워크 요청을 하고 있다.
  • 사용자와 기존 v1 서버 사이에 로드밸런서라는 친구를 두고 이 친구를 통해 서버에 요청을 하게 한다.
  • 신규 버전이 적용된 v2 서버 군을 새로 띄우고 준비가 되면 로드밸런서에서 쇽(!) 하고 사용자 요청을 v2 서버로 보낸다.
  • 배포 완료!
• 스테이징 환경은 요청 스위칭 전 미리 v2 서버에 접근해 보는 과정이다.
  • 스위칭을 통해 실제 운영 환경이 될 서버라 운영 DB를 바라보고 있어서, 크리티컬한 기능 테스트는 주의해야 한다.

보너스 섹션으로 (저희 팀에서는 하고 있진 않지만) 카나리 배포에 대해서도 설명을 드렸습니다.

• 카나리 배포는 광부들이 광산의 유독가스 발생 여부를 확인하기 위해 카나리아라는 새를 미리 날려 보내던 것에서 유래했다.
• 이처럼 사용자 요청의 일부를 신규 서버로 미리 보내보면서 점진적으로 배포를 진행하는 방법이다.

Jenkins, 배치 관리 도구

다음 섹션은 저희 팀에서 배치 관리 도구로 사용하고 있는 젠킨스에 대한 내용입니다.
사실 팀에서 이미 여러 번 젠킨스에 대한 논의가 있었기에, A to Z로 모든 내용을 넣지는 않았고요.
다음과 같은 포인트를 중심으로 이야기를 풀어나갔습니다.

• 배치란 무엇인가?
• 배치 관리 도구로서의 젠킨스
  • 여러 가지 배치가 있고, 수행 시 파라미터를 넣어서 원하는 방향으로 작업을 수행할 수 있다.

• 젠킨스 배치 잡(Job)을 구성하는 방법은 다음과 같은 것들이 있다. (이름은 임의로 붙인 것)
  • Simple Job
    • 가장 간단한 형태의 작업. 배치와 1:1 관계
  • Pipeline Job
    • 여러 개의 Job을 순차적으로 실행할 수 있다.
  • Trigger Job
    • 다른 Job을 특정 파라미터로 실행시키고 자기 자신은 종료된다.

젠킨스 배치 잡 구성방식에 대해 이야기를 꺼낸 이유는 다음과 같습니다.
정산시스템 어드민에서는 젠킨스에 존재하는 주요 배치들을 등록 및 관리하여 시작일시/종료일시 등을 체크하고 있는데요.

위에서 소개한 Trigger Job의 경우 다른 배치를 실행시킨 후 자기 자신은 종료되기 때문에 해당 Job을 모니터링 용도로 등록하게 되면 시작일시와 종료일시가 동일한 시각으로 나오게 됩니다.
이런 부분을 개선하기 위해서는 Trigger Job을 트래킹하는 대신, 실제 실행되는 하위 배치의 시작일시/종료일시를 조회하도록 고도화하는 방법이 있겠습니다만, 현재로서는 해당 건에 대한 우선순위가 많이 떨어지기 때문에 그대로 유지하고 있는 상황입니다.

정산시스템 어드민에서 어떻게 배치 Job들을 모니터링하고 있는지가 궁금하시다면 이 포스팅을 참고해 보시면 되겠습니다 🙂

크롬 개발자 도구, Network 탭

대망의 마지막 섹션으로는 개발자 도구 네트워크 탭에 대한 간단한 사용법을 소개해 드렸습니다.

기획자분들께서 QA를 진행하시다 보면 어드민 등에서 의도한 대로 동작이 안 되거나, 예상한 결과가 나오지 않을 경우 항상 담당 개발자를 통해야 문제의 원인을 파악하실 수 있었는데요.
그 전에 해당 기능의 어떤 점이 문제인지 개발자도구를 통해 미리 간단하게라도 파악해 볼 수 있다면 더욱 명확하고 구체적인 이유로 담당 개발자를 혼낼 수 있습ㄴ.. 농담입니다. 소통을 더 빠르게 할 수 있습니다.

• 단축키
  • mac : option + cmd + i
  • win : F12
• 여러가지 탭이 있지만 네트워크 탭 하나만 잘 파악할 수 있어도 아주 편리하다.
  • 서버에 날린 요청들
  • 걸린 시간
  • Headers에서 API 요청 시 같이 보낸 파라미터들을 확인할 수 있다.
  • Preview에서 요청 후 받은 응답값을 정제된 JSON 형태로 확인할 수 있다.

이렇게 해서 4가지의 이야기 주제로 특별 팀 세미나를 마무리 하였습니다 😉

혹시 지금 마음이 동하신다면

보시면서 ‘어? 이런 내용 우리도 공유 필요한데..’ ‘아 우리 팀에는 요런 저런 내용 전달해 보면 좋긴 하겠다’라는 생각이 드시는 분, 그대로 조직장님께 가셔서 조용히 손을 들어주세요 🙋
내가 알고 있는 것을 잘 소화한 후 필요한 곳에 전달하는 행위가 결국 부메랑처럼 자기 자신에게도 많은 도움이 되는 것 같습니다 🙂

진행하면서 주제마다 설명을 쉽게 하려고 하도 쇽! 이라는 효과음을 넣었더니 ‘쇽우빈’이라는 별명이 생겨버렸습니다.
세미나가 끝나고 긍정적인 반응을 많이 주셔서 준비한 보람도 가득 느꼈습니다 호호
다음 편도 또 해달라고하셨지만 그건 개발 파트 내 다른 분들께 기회를… 쿨럭

팀이 존재 목적에 맞게 하나의 유기적인 공동체로 역할을 할 수 있도록 앞으로도 다방면으로 열심을 내보겠습니다.
이상 별로 안 궁금했지만 막상 들어보니 은근 궁금했던 개발 이야기 팀 세미나 이야기였습니다.
읽어주셔서 감사합니다!