(1) 낯선 환경에 적응하기
‘적응’, 2023년 인생을 가장 대표하는 한 단어이다. 1월 초 신규 부서에 와서 클라우드 사용만 해봤던 내가 클라우드를 제공하는 입장이 되었다. 클라우드 인프라에 대한 지식 습득, 새로운 사람들과의 만남, 회사라는 곳에 적응하는 등 많은 것들이 낯설고 새로웠다. 또한, 회사의 보안 규정이 너무 심해서 방화벽 신청, 재택을 위한 VDI 접속 후 Local pc에 접속 해야하는 등 네트워크, 보안 관련해서도 낯선 부분이 많았다. 이전 회사에서 다짐 하길 새로운 회사에 가게 되면 누구보다 빠르게 도메인 파악을 하자 라는 것이었다. 이런 생각을 하게 된 이유는 이전 회사에서 약 1년 동안 도메인 파악을 다 하지 못했기 때문이다. 도메인 파악을 못한 페인 포인트를 생각해보면 패션 유통이라는 생소한 도메인과 DB 중심의 서비스로 인해 디버깅이 힘들었기 때문이다. 다행히 이번 회사는 어플리케이션 중심의 서비스였고 도메인 리더 분께서 충분히 도메인을 설명을 해주셨기 때문에 기본 지식에 대한 뼈대를 잘 세울 수 있어서 도메인 이해가 상대적으로 잘 되었던 것 같다. (그래도 6개월이라는 시간이 걸렸다…) 이번 년도 내에 도메인에 대한 깊은 이해를 끝마치고 내년부터는 개발 지식 관련된 내용을 학습하는 것이 목표였으나 인프라 도메인은 깊게 들어가면 갈 수록 알아야 할 부분이 너무 많았다. 특히, 네트워크 가상화 부분이 무궁무진했다. 내년에는 가상화라는 큰 주제와 물리 장비라는 두 가지 도메인에 대한 학습을 해야겠다고 다짐을 해본다.
(2) 새로운 기술 적용하기
도메인 뿐만 아니라 새로운 IT 프레임워크와 아키텍처를 배운 시기이기도 하다. 4월부터 10월까지 Webflux, Event Driven Development, Hexagonal Archtecture에 대한 개념 학습 및 신규 프로젝트를 진행했다. Webflux란 spring mvc를 활용해 동기 방식으로 개발하는 하는 것이 아닌 node.js 처럼 모든 것이 비동기 방식으로 개발할 수 있게 하는 프레임 워크이다. 하나의 톰캣 서버는 기본 200개의 세션을 제공하는데 만약 동시에 1000개의 요청이 발생하면 모두 처리할 수 없다. 이때 webflux를 사용한다면 요청이 비동기로 처리 되기 때문에 보다 효율적으로 동시 요청을 처리할 수 있다. 하지만 webflux를 사용하면 java를 사용해서 개발하던 방식과 완전히 다른 개발을 하게 된다. 기본적으로 Mono, Flux를 통한 Wrapper를 통해서 데이터를 주고 받고 요청부터 응답까지 block을 할 수 없기 때문에 요청 순서가 정해져 있는 것은 webflux로 처리하기 어렵기 때문이다. (callback 구조를 사용해서 순서 보장을 해줘야 하기 때문에 코드량이 상당히 많아진다.) 그렇기 때문에 개발 생산성과 성능 개선을 잘 따져서 신중히 프레임 워크를 정해야한다.
Event Driven Development에서 가장 인상 깊었던 점은 이벤트에 대한 처리 책임은 publish가 아닌 subscribe에 있다는 점이다. publish는 이벤트를 방행하면 그 역할은 끝난 것이다. 발행된 이벤트를 처리하는 것은 subscribe이다. 이 말은 publish와 subscribe간의 의존성이 없다는 것이다. 예를 들어. 1개의 publish가 있고 3개의 subscribe가 있을 때 3개의 subscribe는 이벤트를 구독하지만 messageKey 등을 이용해서 자신이 처리할 이벤트가 아니라면 관여하지 않는 것이다. 즉, EDD의 장점은 서비스간의 결합이 느슨하다는 점이다. 이벤트를 발행하는 서비스는 이벤트 발행을 하면 책임을 다한 것이며 이벤트를 구독하는 서비스는 자신이 처리해야할 이벤트가 오면 처리만 하면 되는 것이다. 이렇게 서비스 간의 분산 처리를 고려할 때 EDD를 사용할 수 있다. 반대로 하나의 서비스에서 내부 계층 간의 의존성을 줄이기 위한 방법은 Hexagonal Archtecture가 있다.
Hexagonal Archtecture는 port & Adapter archtecture인데 간단하게 도메인을 가장 우선시하는 것이다. 일반적으로 Database 관점으로 설계를 하고 개발하는 경우가 많은데 이러면 domain entity가 DB에 종속적이게 된다. DB 변경이 발생하게 되면 관련된 어플리케이션 코드도 모두 수정하게 되어야한다는 단점이 있다. 또한, 새로운 개발자가 프로젝트에 투입 되었을 때 DB 중심으로 서비스를 파악해야 하기 때문에 서비스를 이해하는데 어려울 수 있다. 하지만 도메인 중심으로 서비스를 개발하면 도메인을 파악함으로써 서비스를 보다 쉽게 이해할 수 있다는 장점이 있다. 또한 Hexagonal archtecture를 사용하면 Adapter layer (controller, persistence, http 등) 외부와 통신하는 부분, Port Layer (인터페이스를 통한 도메인과 연결 시켜주는 부분)를 통해서 각 계층의 의존성을 확실하게 격리 시켜준다. 물론, 클래스, 인터페이스 관련된 코드 수가 2배 이상으로 많아 진다는 단점이 있다. 장기적으로 보면 유지 보수, 클린 코드 등 이점이 있지만 신속하게 개발 해야하는 프로젝트라면 생산성이 떨어진다는 단점이 존재한다. 약 6개월간 프로젝트를 하면서 배운 내용은 위와 같다.
(3) 개인적인 회고
한 가지 아쉬운 점은 좀 더 능동적인 자세가 있었다면 어땠을까 싶다… 효율적인 방법이 있으면 적극적으로 설득해서 도입을 한다던지 개발하면서 발생했던 이슈나 지식을 정리하면서 갔으면 조금 더 만족했을 프로젝트가 됐을 것 같다. 그래서 내년에는 개발을 하면서 얻은 지식을 틈틈이 정리 및 공유하면서 능동적인 자세를 가져야겠다고 다짐한다.
개인적으로 이번 년도에 부족했던 점은 개인 공부에 너무 소홀 했던 점이다. 클라우드에 대한 학습을 다짐했으나 막상 제대로 된 공부를 한 적도 없고 인프라 (switch, router, database, server 등) 같은 세부적인 학습도 하지 않았다. 뭔가…유독 이번 년도는 공부가 잘 되지 않았던 한 해이다. 집중도 잘 되지 않았고 그냥 놀고 싶었다……그래서 회사 업무에 집중만 하고 남는 시간은 그냥 즐겁게 보냈던 것 같다. 12월에 노트북을 켜고 무슨 공부를 할 까 생각을 해보는데 막상 무엇을 해야 할 지 감이 잡히질 않았다. 회사를 제외하고 어떤 개발자가 되어야 할지 궁극적으로 내가 추구하는 방향성은 무엇인지 정리가 필요하다고 생각한다. 단순히 업에 관련된 방향성이 아닌 인생의 방향성을 세워야 하는 시기가 온 것 같다. 방향성과 목표가 뚜렷하다면 무엇을 해야 할지 고민하는 것 보다 목표를 달성하기 위해서 시간 관리를 어떻게 해야 할지 생각하지 않을까??… 1월 초에 스페인 여행을 가서 개인적인 시간을 가지면서 생각을 해봐야겠다.
잘했던 점은 최선을 다해서 신규 프로젝트에 임했던 점이다. 신규 프로젝트를 진행하면서 나는 야생형 개발자라는 것을 다시 한번 깨달았는데 이론을 깊게 학습하고 개발하는 것이 아닌 개발을 하면서 경험을 통해서 개념을 체화 시키는 것이 나에게는 더 잘 맞는다는 것을 깨달았다. 때문에 IT 서적을 읽을 때도 빠르게 한번 훑어보거나 개발을 하면서 모르는 부분을 찾아보는 것이 나에게 더 잘 맞을 수도 있겠다라는 생각이 들었다. 개발적인 성장 뿐만 아니라 개인적으로 해보고 싶었던 것도 몇 가지 이루었다. 테니스 대회 나가보기, 수영 배우기, 나만의 블로그 사이트 가지기, 글또 참여하기!!!
글또를 시작하게 된 계기는 머리 속에 있는 지식에 대한 전달력을 높이고 싶기 때문이다. 생각을 하면서 글을 쓰다 보면 문장 구성, 단어 선택에 대한 생각이 많아지고 좋은 전달력을 가지게 된다고 확신을 한다. 이 가설이 틀렸을 수도 있지만 개발자에게 가설은 필수적인 존재니깐… 가설을 세우고 실행에 옮기고 보완하고를 반복하는 것이 좋은 개발자가 되는 것 뿐만 아니라 장기적인 인생에 있어서 많은 인사이트를 얻을 수 있지 않을까 싶다. 나는 다경험주의를 지향하니깐!