개발 역량 장착하기(1)-Intro
Updated:
INTRO…
필자는 운영 및 개발자로써 8~10년, 그 다음 10여 년간은 PL, QA, BA, AA, PM 및 등 다양한 직무와 역할을 경험하며 지내왔습니다. 가장 최근에 선택한 역할이 애자일 코치입니다. 스스로 선택한 역할도 있지만, 대부분은 회사의 요구와 필요에 따라 그때 그때마다 여러 업무를 전전해 온 것 같습니다.
이 역할들 중에서 가장 흥미로왔던 시기는 그 때가 사회 초년병 시절이어서 그런지는 몰라도, 개발자로써 지냈던 시절이 가장 신나고 즐거웠던 기억이 납니다. 매일 아침 일찍 회사에 출근해 자판을 두드릴 생각을 하면 아무리 피곤해도 불끈불끈 새 힘이 솟아올라 새벽일찍 회사에 출근하는 것을 마냥 기대했던 생각이 떠오릅니다.
하지만 시간이 흐르면서 회사가 or 시장이 요구하는 인재상에 따라 개발에서 손을 떼게 되고, 잠시인 줄 알았던 그 이별이 장기적인 이별이 된지도 어언 10여년이 흘렀네요. 회사에서는 더이상 개발보다는 관리 역량, 보고서 역량, 세일즈 역량, 고객관리 역량, 커뮤니케이션 역량 등 실로 많은 것을 요구해왔고 헐떡헐떡 좇기며 살아온 것 같습니다. 그런데 최근… 사실 몇년전부터 이 업계에 다행인지, 불행?인지 개발자의 계절이 다시 돌아오고 있습니다. 화려했던 개발자의 영광이 부활하고 있는 것이지요.
사실 IT 업종에 종사하는 한, 개발에서 완전히 손을 씻을 수는 없습니다. 대강의 트렌드와 흐름을 따라가면서 비즈니스를 이해하고 다양한 아키텍처를 접하기 위해서는 개발을 직접하지는 않아도 대강 어떤 식으로 개발을 하는지 꾸준히 공부해야 하고, 또 몰라도 아는 척 둘러대기도 하지요. 또한 나름 개발천재라는 말을 들었던 만큼 개발 언어라는 게 뭐 다 거기서 거기지 굳이 뭐 배울 게 있나라는 알량한 생각도 들게 마련입니다.
그런데 말입니다… 최근 몇년간 불어닥친 DT라는 신문물… 그리고 이를 뒷받침하기 위한 Cloud니 MSA니 하는 기술들은 참 신박한 것들이었습니다. 새 것에 대한 호기심 덕분에 어느정도 공부를 하며 개념들을 학습하며 이해할 수는 있었으나 만약 저것을 내가 직접 개발자가 되어 구현해 보게 된다면…? 혼자 터득해서 실행해보기에는 엄청 큰 벽이 느껴졌습니다. 경험과 세월에 안주하여 긴 시간을 보내다 보니 다시 개발과 사랑하고 싶은 생각만 굴뚝같을 뿐 진짜 사랑할 엄두는 턱도 없었던 것이지요.
다행이도 새롭게 바뀐 HR 제도 덕에 개발 역량이 무엇보다 우선시되는 시대가 도래했고 저에게도 새로운 개발 역량을 장착할 기회가 주어졌습니다.
회사의 육성 프로그램인 Cloud Application Development 역량 Level2에 - 아… 이렇게 오래된 경력임에도 Level2부터 다시 시작한다는 것이 슬펐지만 어쩌겠습니까 - 도전하게 된다니 이 참에 그동안 잠자고 있던 개발 세포들이여 다시 깨어나라 마음 속으로 되뇌면서 긴장까지 하게 되더군요.
늘 그렇듯 다 알고 있는 사람들에게는 무지하게 심플한 내용이지만, 초보자에겐 모든 게 새롭지요. Level2 과정에 참여하면서 과정 하나하나 학습하는 내용을 까먹지 않으려고 열심히 메모를 해두었는데요… 요 메모들을 모아서 “개발 역량 장착 이야기”로 풀어 포스팅해보고자 합니다.
학습을 위한 글도 아니고, 지식을 전달하는 글도 아니지만, 새로운 도전을 하기 위해서 어떠한 과정을 겪게 될지 조금은 두려운 분들, 저처럼 개발 경력이 단절되었던 분들이 다시 새로운 세계에 발을 들여놓는 데에 약간이나마 도움이 될 수 있기를 바라며 글을 시작하고자 합니다.
회사에서 제시한 Cloud App. Development LEVEL2 과정은 전체 아래와 같이 구성되었습니다. 마지막 5 ~ 6차시는 그룹과제 및 개인과제 평가 시간이어서 평가 관련 제외하고 총 4 ~ 5회에 걸쳐 개발 역량 장착 과정을 풀어보고자 합니다.
| 차시 | 과목명 | 교육일수 |
|---|---|---|
| 1차시 | Microservice Modeling | 2 |
| 2차시 | Developing Cloud Native Application | 3 |
| 3차시 | CI/CD Pipeline | 1 |
| 4차시 | Container Orchestration(Docker & Kubernetes) | 3 |
| 5차시 | App. Eng. on Cloud Final Project & Assessment(1) | 2 |
| 6차시 | App. Eng. on Cloud Final Project & Assessment(2) | 2 |
1차시 교육 : 마이크로서비스 모델링을 해 보다
1차시 교육은 총 이틀로 먼저 마이크로서비스에 대한 개요와 배경 등을 이해하고 마이크로서비스 모델링을 직접 해보는 것으로 구성되어 있습니다.
마이크로서비스에 대해서 그간 수차례 많은 이론 교육을 들었지만, 마이크로서비스 외부 아키텍처와 내부 아키텍처로 나뉘고 각각의 패턴이 어떤 것들이 있다는 설명을 들으면서 그간 찌라시처럼 수집했던 자잘한 지식들이 머릿속에서 무언가 형태를 잡는 것을 느꼈습니다. 강의가 훌륭해서라기보다는 그동안 그래도 여기저기서 눈동냥, 귀동냥을 해온 것들이 짤처럼 모이고 쌓여져 있다가 일목요연 정리된 내용을 만나면서 시너지를 일으키게 된 것 이지요. 무엇보다 직접 마이크로서비스를 도출하고 모델링까지 하는 것이 크게 도움이 된 것 같습습니다. 사실 프로젝트 이벤트스토밍 실습에도 수차례 참여한 경험이 있는데 어디까지나 내 과제가 아닌 남의 과제여서 그랬을까요? 스스로 직접 그려본다는 점에서 수많은 경우의 수를 생각해 보게 되고, 구현 가능성까지 염두에 두어 최적의 Output이 잘 나올 수 있도록 방향을 정하고 설계해 나가는 과정을 통해 몰입이 잘 되었습니다.
아래 그림이 최초에 그려본 이벤트스토밍 실습 예제입니다.
첫 작품이라 그림이 많이 지저분합니다. ㅎ 일단 위의 다이어그램이 맞는지 or 틀린지를 떠나서 이벤트스토밍을 스스로 해보고 어떻게 마이크로서비스를 나누어야할지 생각해보게 되는 좋은 시간이었던 것 같습니다.
특히, 팀을 짜서 함께 이벤트스토밍을 하게 되면 전혀 실마리가 없을 때 다른 사람이 도움을 주고, 또 내 생각을 다른 사람에게 전달하기 위해 어떻게 표현하는 것이 좋을지 다시한번 생각해보면서 정제하는 과정을 겪게 됩니다. 여기서 중요한 것은 이상하다고 생각되는 부분은 꼭 질문해보는 습관입니다. 질문과 답변을 통해 생각과 아이디어가 교환이 되고 좀 더 견실한 모델링 과정을 겪을 수 있습니다.
이번 실습을 통해 배우게 된 개인적인 또하나의 수확은 Policy에 대한 이해였습니다. 그간 Event와 Command는 워낙 근간이 되는 것들이라 많이 사용해봤는데, Policy를 정의하는 부분은 쉽지가 않았습니다. 마이크로서비스간 데이터를 주고받기 위해 Pub/Sub 패턴을 적용해야 하고 이 과정에서 필요한 Policy를 정의해야 한다는 것을 확실히 알게 되었습니다.
이벤트스토밍 및 마이크로서비스 패턴 등에 대한 내용은 본 사이트에 많은 글이 게재되어 있으니 참고하여 보시기 바랍니다.
다음 포스팅에서는 본격적인 개발 수업에 들어가면서 메모했던 것을 바탕으로 글을 써보고자 합니다.
Appendix : 모델링 실습 결과
아래 내용은 과정 후에 개인 과제를 진행하면서 모델링했던 결과입니다. 멋모르고 지저분하게 했던 모델링 작업이 실제 본인 과제를 하면서 질서정연하게 진행되는 것을 보실 수 있습니다. ㅎ
서비스 시나리오
- Happy Bus는 직원들의 행복한 출근을 위한 통근 버스 예약 시스템이다.
- Happy Bus 예약을 위해서는 토큰을 사용해야 하며, 직원 등록시 통근버스에 탑승할 수 있는 무료 토큰이 기본 2개 주어진다.
- Happy Bus의 운행 스케쥴은 M-1월에 생성되며, 운행 스케쥴이 등록되고 나서 예약이 가능하다.
- Happy Bus의 고정 좌석은 3개이며, 좌석이 모두 예약되면 추가 예약자를 받을 수 없다.
- 버스가 출발하면 해당 일자 예약은 더이상 불가능해진다.
- 토큰이 부족한 경우 추가 구매할 수 있으며, 총 구매내역은 급여처리시 정산한다.
- 예약을 취소하면 차감하였던 버스 토큰을 복원 처리한다.
- 버스 탑승시에는 태깅을 하여야 하며, 비예약자가 태깅시 에러가 발생한다.
- 직원 개인은 myPage를 통해 토큰 사용 이력을 조회할 수 있다.
- 버스 관리자는 대시보드를 통해 현재 버스의 예약자 현황과 탑승 현황을 조회할 수 있다.
이벤트 스토밍 결과
- 시나리오를 바탕으로 주요 이벤트를 도출
- 이벤트에 대한 명령어(Command)와 사용 주체(Actor) 식별
- Aggregate 정의 및 바운디드 컨텍스트 설정
- 마이크로서비스간 연간 관계와 정책(Policy) 정의
< EOF >