2년차의 마지막에 처음 써보는 개발자 회고 (2018-2019)

다른 개발자 분들의 글만 보다가 오늘까지의 내가 무엇을 해왔는지 기록해두기 위해 남겨보려고 한다. 글을 읽는 것을 별로 좋아하지 않아서 다른 분들이 쓰신 회고 글이 어떤 내용과 형식을 다루고 있는지는 모르겠지만, 단순 일기 식으로 쭉 써내려가려고 한다. 입사 초 (2018.03 ~) 부터 현재까지의 내용을 기록할 것이기에 내용이 길다.
개발과 관련된 이야기를 주로 하겠지만, 개발 외적인 매우 주관적인 생각도 포함할 것이다. 내가 기록하자고 쓴 내용이고, 보더라도 어차피 개발자가 아니면 이 글까지 굳이 볼 일은 없을 것이라 생각한다.

친구와 대화하다보면 사람마다 정의가 다른 것 같긴 하지만, 분류하자면 "웹 개발자" 라고 할 수 있고
사용자와 트래픽이 너무 적지도 많지도 않은, 조금은 오래된 서비스의 개발을 하고 있다.

1년차 (2018)

교육

위에서 언급했다시피 오래 운영 중인 서비스이다보니 기존에 구축이 되어 있는 많은 사항들이 있어 해당 내용에 대한 교육이 이루어졌다. 이 외에도 사내 교육 플랫폼을 통하여 다른 교육도 듣도록 가이드가 있었다.

* 서비스 관련
중요 DB 구조 및 테이블 스키마, 사용하고 있는 기술 스택 및 기타 서버 구성
* 교육
MySQL (사내 플랫폼), Inside JavaScript, 멘토 (사수) 와의 Effective Java 2판 정독
* 기타 업무
웹 접근성 개념, ...

테이블이 어떻게 구성되어 있는지 들었을 때는 멘토 분께서 "오래되서 이런 구조이다" 라고 말씀을 해주셨는데, 사실 다른 구조를 본 적이 없어서 '큰 서비스를 운영하려면 이런 구조를 가져야하는구나' 라고 이해했다. 서버도 컴포넌트가 굉장히 많고 대수도 상당하여 처음 들었을 때 매우 놀랐다. 후술하겠지만 충격받은 부분은 검색해도 결과가 없는.. 기술 스택이었다.

교육에서는, 개인적으로 데이터베이스에 대한 부분이 (현재까지도) 굉장히 취약하다고 판단하는데, MySQL 은 동영상 강의가 있어 해당 내용으로 습득이 학교 수업보다 훨씬 도움이 많이 되었다.
Effective Java 는 많이 어려웠고 현재 시점에서 특별히 기억나는 내용이 없긴 하지만, 코드 리뷰에서 크게 어긋나지 않은 것을 보면 그래도 체득된게 있긴 한가?에 대한 생각이 들긴 한다. 현재 시점에서 다시 볼 필요가 있을 것 같다.
사실 자바로 개발하는 것에 대해서 많이 걱정했는데, 얼마 전에 작성한 학생 개발자 시절 회고에 남겨두었지만 자바스크립트에 대한 개발만 했고 아무런 지식이 없었기 때문이다. (면접에서도 자바 관련으로는 답변을 거의 못했고, 그로 인해 이 팀에서 나를 왜 뽑았는지에 대해서도 의문이 있었다)

개인 기기가 늦게 도착해서 2주 간은 대부분 교육과 로컬 환경 설정으로 지나갔고, 설정이 끝난 후에는 교육을 병행하면서 일을 시작했다.

실무 시작

웹 접근성 (상세 내용은 별도 검색 바람)
데이터 추출, 업데이트 (스크립트 작업)
내부 운영용 기능 개발
대규모 화면 개편
기타 소규모 유지보수

웹 접근성

대부분 타 팀에 계시는 마크업 전담 개발자 분께서 수정해주신 부분을 내가 적용하는 일이 전부였다. 다만 오래된 라이브러리를 사용하는 부분은 내부에서 가이드에 맞춰 알아서 수정해야하는데, 상세하기 언급하자면 길어져서 생략하지만 기존 마크업 위치 등의 문제로 까다로웠다. 이 작업을 하다가 특정 기능이 동작하지 않는 소규모 장애를 맞기도 했다.

데이터 추출, 업데이트

간단히 말하면 기획/운영 쪽에서 요청하는 특정 기간의 데이터를 추출해서 전달해주는 일이다. 중요 지표는 내부 기능으로 기간별 확인이 가능하도록 이미 만들어져 있으나, (사실 크게 쓸모가 있는지 모르는) 서비스 스펙이 산더미여서 그에 대한 추가 요청이 꽤 들어오는 편이다. 이미 만들어져있는 테이블에 별도의 기간 쿼리를 작성하여 추출하는 작업이고 이 때 중요하게 보는 것이 해당 쿼리가 기존에 만들어진 인덱스를 타는지에 대한 것이다. 또한 이런 데이터들의 경우 서비스에서 사용하지 않는 제일 마지막 slave 데이터베이스를 대상으로 추출이 진행된다.

기타 버그로 인해 데이터가 어긋나는 부분도 간혹 발생하는데, 간단한 수정에 대해서는 별도로 쿼리를 작성하여 master 데이터베이스에 서비스에 영향이 가지 않을 정도의 간격을 두어 업데이트하는 작업도 있었다.
(작업에 사용하는 기술 스택이 엄청난 히스토리를 가지고 있는데, 올해 초 혼자 만들어보았고 이후 다룰 예정이다.)

내부 운영용 기능 개발

내부에서 사용하기 위한 기능을 개발하기 위해 기존의 코드들이 어떻게 이루어져있는지 먼저 파악했다. DAO, BO, Action (;;) 등의 처음 보는 형태들과 xml 설정들을 마주하고 나니 조금은 헤매긴 했지만 동작과 역할 구분에 대한 파악을 어느 정도 할 수 있었다.
개발하고 나서 PR 을 요청했고 많은 코멘트들과 마주했다. 주석을 어떻게 달아야 하는지에 대한 것부터, 코드 스타일, 쿼리 튜닝 등과 같은 모든 내용에 대한 코멘트가 아마 15개 내외로 달렸던 것으로 기억한다. 코멘트를 마주하고 나니 조금은 위축되긴 했지만, 관련 내용을 수정하고 머지하여 배포가 될 수 있었다.

이 작업을 하면서 충격을 받은 부분은 기술 스택이다. 엄청 오래된 Spring 버전을 사용하고 있었고 심지어 사내에서 만들어둔 플랫폼으로 한 번 감싸둔 형태였다. 여기에 더해서 struts 라는 것도 처음 들어보는데 그것보다 한 단계 더 이전의 프레임워크(?) 를 사용하여 구글링해봐도 아무런 정보가 없었다. (여기에 충격받아 React 를 해보자고 시작은 해봤지만 중단했다.)

대규모 화면 개편

우리 서비스의 모든 화면은 (지금까지도) 너무 올드하다. 그 중 대부분의 트래픽을 받는 페이지의 개편 작업에 투입되었는데 동시에 내부 구조에도 많은 변화를 시도했다.

기존에는 하나의 컴포넌트에 화면 + 서버 로직까지 전부 가지고 있었고, 서버 로직을 "core" 라는 공통 서브 모듈 방식으로 포함하여 모든 컴포넌트가 core 를 가지고 배포하는 방식을 취하고 있었다. (사실 개발자가 부족한 우리 팀의 입장에서는 지금 생각해보면 관리하기는 편한 구조였다고 생각하긴 한다.)
하지만 다른 과제를 통하여 "프론트엔드와 백엔드 부터라도 분리해보자" 라는 결론이 도출되어 작업이 진행되었고, 이번 과제에서부터 본격적으로 대규모 트래픽을 받는 페이지를 새로 분리한 프론트엔드 컴포넌트로 이관시키는 작업이 시작되었다.

트래픽의 대부분을 차지하는 페이지이다보니 별의 별 기능이 덕지덕지 붙어있었고, 그에 관한 오래된 코드의 양도 엄청나게 많았다. 내부적으로 관련 기능을 크게 몇 가지로 나누고 각 1개 씩을 다른 선배 개발자 분들께서 나누어 가졌으며, 막 들어온 입장인 나는 큰 분류에 포함되지 않는 기타 작은 기능들을 모두 끌어안는 것으로 시작했다.

화면 작업으로 10년이 넘은 페이지 레이아웃 구조를 새로 뜯어 고치는 것부터 시작했다. 크게 어렵진 않았고 페이지가 몇 백 단위가 넘다보니 전부 확인하느라 조금은 귀찮은 작업이었다.
js 코드들은 외부 개발자 분들은 전혀 모르는 라이브러리로 작성이 되어 있는데, 그나마를 jQuery 로 옮기는 작업을 진행했다. 이 작업을 하면서는 새로 옮겨놓은 코드가 정상적으로 화면에서 동작하는 것을 보고 보람을 느꼈다.

이 프로젝트의 백엔드 작업을 통해서 나는 처음으로 Java 8+ 에 대해 입문을 했다. 다른 팀원 분들께서는 (물론 실제적인 개발은 처음이시지만) 내가 들어오기 직전에 이 스터디를 진행한 것으로 위키 문서를 통해 파악했는데, 나는 아는 바가 없어서 따로 책도 들여다보고 하느라 조금은 힘들었다.
다른 팀원 분께서 미리 적용해주신 Spring WebClient 도 보면서 굉장히 흥미로움을 느꼈다. 사실 나는 RestTemplate 이나 Apache Client 를 많이 사용해보지 않은 입장에서, 이 2개를 사용하라고 하면 거부 반응을 일으킬 정도로 WebClient 코드가 보기 좋다고 생각한다. WebClient 관련 버그가 있어 올해 패치도 진행하긴 했는데, 다른 글로 작성할 예정이다.

기타 소규모 유지보수

크게 할 이야기는 없지만, 레거시에 대해 엄청나게 놀랐다. 도대체 왜 이렇게 코드가 짜여있는지에 대한 생각만 엄청 했던 것으로 기억한다. 이게 운영 중인게 신기했고 언젠가는 대규모 리팩토링이 필요하다고 생각했다.

팀 스터디

내가 입사하고 나서 2018년에는 총 2개의 팀 스터디를 진행했다. "Spring 5 를 이용한 마이크로서비스" 에 대한 내용과 "React" 에 대한 내용이다. 막 바로 적용할 내용들이 아니어서 크게 도움이 되지 않긴 했고, 당시 내가 스터디를 어떻게 하는 지에 대한 자체에 대한 개념이 없어 조금 민폐 수준이었다. 적을 내용이 많이 없다.

기타 개발

React 써보기 (중단)
slack bot 개발

React 는 화면 개편 투입 전, 재미가 없다고 생각하여 경험이나 해보자고 시작했지만 투입 후 재미를 찾아서 접었다. 대학생이었던 친구와 같이 하려고 했는데 굉장히 미안했다.

slack bot 은 18년 7월 즈음에 내부적으로 slack 도입이 진행되었는데, 관련 내용을 찾아보다가 9XD 에서 만든 봇이 재밌어보였다. 몇 달간 시간나면 만들어야지 하고 있다가 11월 즈음 팀 내부용 점심 구내식당 봇을 만들어서 내부 동의를 얻고 vm 에서 구동을 시작했다 (사실 구내식당 로직은 다른 팀의 친구가 만들어두고, 조금 고쳐서 가져오긴 했다). 몇 개 기능을 더 붙였고, 지금은 kubernetes 에 올려서 구동 중에 있다.
원래 hubot 은 coffeescript 혹은 es5 기준으로 가이드가 있는데, es6 로 만들고 babel 로 변환하여 구동하는 방식으로 진행했다.

9개월 간 배운 것

위에 언급한 것들 외에도 습득한 것에 대해 단어 위주로 간단하게만 적고 넘어가려고 한다.

캐싱 (로컬, 분산 환경)
(간략한) IDC 이중화
Java 8, Spring 5, Boot 2, ...
static resource (js, css, ...) 관리, merge - minify 개념
MySQL 실무 개념
kerberos, serverless, MQ, batch, XSS, CSRF, ...

 

2년차 (2019)

작년 말 - 올해 초 사이 타노스가 한 번 다녀갔다. 정말 매우 혼란한 시기였다.
이런 식으로 되도 괜찮은 것인지에 대해 생각을 많이 했지만 그 사이에도 나름의 하고 싶은 일을 하긴 했다.

혼자 진행한 개발

데이터 추출/업데이트 작업 개선
사내 메신저 bot 만들기

데이터 추출/업데이트 작업 개선

나는 우리 팀에서 데이터 작업 진행이 굉장히 불편하고 비효율적이라고 생각했다. 해당 작업에는 Java 로 넘어오기 전에 사용한 php 를 이용했고, 심지어 버전이 너무 낮아 구글링을 통해 찾은 함수도 사용할 수 없었다. 더군다나 로컬 환경에서 php 를 구동할 수 있는 환경조차 구성되어 있지 않아 실제 스크립트는 서버에 들어가서 CLI 상으로 구동시켜야하고, 당연히 동작 중 발생한 버그도 서버에서 실행을 해야만 발견이 가능했다.

현재의 작업 flow 를 그대로 가져오면서 로컬에서도 구동할 수 있고 모두가 큰 설정없이 사용할 수 있는 새로운 무언가를 만들어보기로 했다. 기능 산정 기간은 특별히 없어 작업하는 도중에 불편했던 사항을 틈틈이 기록했고, 혼란한 시기 중 1주를 잡아 개발을 완료했다. 사용한 것은 다음과 같다.

Java 8
Spring boot 2.1 (starter-web, ...)
Spring JDBC
jQuery

Java 11 을 기준으로 개발을 하고 싶었지만 사용 중인 IntelliJ 와 Gradle 버전 관련 호환이 되지 않는 문제로 8을 기반으로 작업했다. 아마 현재로 진행했다면 11로 설정한 다음 로컬 docker 에 올려서 사용하도록 가이드를 했을 것 같다.
데이터베이스 설정들은 기존에 다른 컴포넌트에서 사용 가능하도록 서브 모듈 식으로 빠져 나와있었고, 해당 부분을 이 컴포넌트에도 추가하여 DB 연결을 맺도록 하였다. 다른 팀원 분들이 설정해두었던 컴포넌트의 기반들을 참고하면서 이 작업을 진행했고, 덕분에 이전부터 계속 생각해오던 "우리 서비스 애플리케이션의 밑바닥은 어떻게 구성되어 있을까" 에 대한 의문을 조금은 해소하게 되었다.

다른 서비스들은 보지 못했지만 우리 서비스는 xBatis 를 사용하고 있다. 개인적으로 나는 xml 자체를 매우 혐오하는 편이고 xBatis 를 여기서 적용하는 경우 Java 단에서 원하는 쿼리를 만들지 못하기 때문에 다른 대안을 찾다가 Spring JDBC 를 사용했고 생각보다 쉽게 적용할 수 있었다. 현재 적용한다면 이 글을 참고했을 것 같다.

개선하는 하나의 과제로 뜬 것은 아니지만, 다행히 다른 팀원 분들께서도 잘 사용해주셔서 뿌듯했다.

사내 메신저 bot 만들기

테스트를 진행하는 팀은 타 회사 소속으로, 공통으로 사용하는 메신저가 있다. 대부분의 서버들이 blue/green 이 적용되어 있지 않고 당장 적용하기 어려운 상태여서, 테스트 기간 동안은 개발자가 서버를 재시작 할 때 메신저 방에 재시작 공유를 별도 타자를 입력하여 공유한다.
개인적으로 이 과정이 귀찮다고 생각하는데, 서버 빌드 스크립트가 실행되고 완료되면 자동으로 메신저 방에 공유해주는 bot 을 만들면 어떨지 작년부터 생각해왔다. (이 개발도 귀찮아서 계속 미뤄지만..)

이 프로젝트는 막 시작했으며 내년까지 끌고 갈 가능성이 있다. 이전에 slack bot 을 만들긴 했지만 hubot 기반이기 떄문에 원하는대로 확장이 어려워서, Java 로 만드는 bot 컴포넌트를 구상 및 개발 중에 있다. slack bot 도 여유가 되면 hubot 에서 제공해주는 형태가 아닌 slack API 를 직접 호출하는 형태로 여기에 이관시킬 생각도 있다.
hubot 은 es6 로 설정하고 (coffeescript 였다면 끔찍..) 나만 관리하고 있지만, 이렇게 만들어두면 내가 아닌 누군가가 기능을 추가하기에도 더 용이할 것으로 생각한다. 

Java 11
Spring boot 2.2 (webflux, ...)

이전부터 webflux 를 통한 reactive programming 에 관심이 있었는데 이번에 시도해보고 있다. DB 연결도 없고 대부분 API 호출이기 때문에 이번에 시도해보기에 적합한 것으로 판단하고 있다.

업무 개발

올해는 한 일이 많긴 한데, 공개할 만한 것들에 대해서 (최대한 간략히) 적어보려고 한다.

유지보수, 배포, 고객문의
개발 외주
코드 이관
내부 신규 서비스 과제 1
내부 신규 서비스 과제 2
기타 이슈 대응

유지보수, 배포, 고객문의

작년까지는 전담하는 사람들이 계속 했다면, 올해부터는 위 업무들을 담당하는 기간/인원을 두고 순환하며 진행되었다. 각종 외부 업체나 내부의 타 팀의 문의와 고객문의로 넘어온 것들을 대응했다. 배포에 대해서는 인수인계를 받으면서 서비스 구조에 대해 다시 설명을 듣고, 순서와 같은 사항들도 전달 받았다. 서비스 구성이 크다보니 배포만 진행하다 하루가 다 가는 것을 보고 진이 빠졌다.

배포도 사내 플랫폼이 있었는데, 이것만 봐서는 실제 서버에서 어떻게 배포가 진행되는지 정확히 알 수가 없었다. 서버 디렉토리부터 해서 배포 스크립트가 어떻게 되어있는지 궁금해서, 개인적으로 실제 운영 중인 서버로 들어가서 파악하는 과정을 가졌다. 여기서도 오래된 부분들을 보며 뜨악하는 것들이 많았는데 이 과정을 통해서 다음 외주 부분에 약간의 개선을 진행했다.

이 기간동안 다른 도전을 해보라는.. 말이 있어서 기존 Jenkins job 을 pipeline 으로 바꾸는 작업도 해보았는데 SonarQube QualityGate 가 동작이 제대로 안 되어 적용까지 못하게 되었다. pipeline 도 무엇인지도 몰랐다가 해보니 MSA 로 간다면 유용할 것 같다는 생각이 들었다.

개발 외주

개인적으로 마음에 들지 않는 과제였지만 어쩌다 내가 맡게 되었다. 이왕 맡은거 내 맘대로 재밌게 해보자는 마음으로 이것 저것 다 해보긴 해서 그래도 재밌게 진행하긴 했다. 어떤 부분이 외주인지 말하기에는 무언가 걸릴 것 같아 생략한다. (이 부분은 간략하게 적기 어려울 것 같다.)

새로운 서버를 받아서 초기 설정을 진행해야 했는데, 개발 환경을 수작업으로 진행하다보니 운영 환경의 여러 서버들을 전부 수작업으로 하기에는 너무 리소스가 많이 들어갈 것 같았다. 그래서 서버를 설정하는 (트러블 슈팅을 통해 적어도 20번의 커밋을 통과한) bash script 를 만들어서 성공적으로 진행했다. 만들어둔 스크립트가 버그가 조금 있었는지 수정이 되긴 했지만, 다른 과제에서도 사용되어 보람이 있었다.

기존에 사용하던 apache httpd 버전이 오래되어 이 과제에서 새로 올리는 작업도 진행했고, 거기에 더불어 팀원 분께서 nginx 를 적용해보면 어떻겠냐는 제안을 해주셔서 거기에 용기를 얻어 전환을 하는 작업까지 진행했다.
nginx 로 바꾸면서 기존에 ajp 로 애플리케이션을 연결하던 부분을 http proxy 로 수정하고, 거기에 더해서 나름의 blue/green 을 구현하여 실제 운영 환경까지 배포를 진행했다.

기존에는 물리적으로 L4 에서 서버를 제외시킨 후 애플리케이션을 죽이고 새로 띄워서, 1대의 서버만 본다면 중단이 발생했다. 이번에 적용한 방식은 blue/green 을 맞게 구현한 것인지는 모르겠지만, 2개의 포트를 두어 blue 와 green 으로 번갈아가며 사용하는 방식이었다.
다른 기존 컴포넌트들은 아직 ajp 여서, 여기서 밖에 쓰지 못하는게 아쉽긴 하다.

코드 이관

2018년의 화면 개편에서 같이 진행된 새로운 컴포넌트로의 코드 이관 작업의 연장선이다. 아마 새로 이관된 코드까지 포함하여 우리 서비스 코드가 거의 200만 라인이 넘을 것으로 생각하는데, 거의 절반은 구 코드들일 것이다. 이것을 Java 8, Spring Boot 로 이관하는 작업을 진행했다. 물론 일부만 이관되고 전부 진행은 못했다.

이전에 진행했던 여러 과제들을 통하여 개인적으로는 코드 작성에는 자신감이 붙어있던 상태였기 때문에, 이관하면서 기존의 이상한 부분의 코드는 리팩토링을 진행하였다. 배포 후 문제없이 잘 동작한 것이 굉장히 기분이 좋았다.
이 외로 외부에서 오신 경력 팀원 분께서 주신 PR 코멘트를 보며 기존에 내가 작성하던 코드 스타일에 대한 고민, 변화가 있었던 과제였다.

내부 신규 서비스 과제 1

다른 팀원 분들이 진행하는 서비스 과제를 보면서 '도대체 저게 우리 서비스에 뭐가 도움이 될까, 왜 통과가 되서 개발이 진행되는가' 에 대한 생각을 많이 했는데, 이번에 진행하는 서비스 과제는 개인적으로 아이템이 정말 좋았기 때문에 재밌어보였다.

이 과제에서는 내가 한 작업은 외부 API 연동과 서비스 목록 페이징 처리, 기타 내부 로직에 대한 부분이었다. 이전에 사용한 WebClient 를 사용하여 연동을 했는데, 기존에 에러 처리 코드가 산발적으로 되어 있고 로그 추적이 조금 어렵게 되어 있어 처리하는 Util 을 따로 만들었다.
목록 페이징은 기존에 서비스에 적용된 다른 코드들을 참고했다. 사용자 차단이나 미성년자 열람 제한과 같은 다양한 필터링 조건이 있는 것을 파악하고, 페이징을 위해 기준 타임스탬프를 잡고 진행되는 것도 처음 알게 되었다.

MySQL 5.7 에서 DATETIME 사용 시 ms 단위가 반올림되는 버그가 있었다. (59.999 -> 00.000 으로 반올림)
DB 자체 버그라고 찾긴 했는데 드라이버도 문제가 있지 않을지? 싶다.

내부 신규 서비스 과제 2

내키지 않던 과제이지만.. 할 일이 굉장히 많았고 내가 원하는 부분을 개발할 수 있었다.

내부 컴포넌트를 분리하여 해당 부분은 DDD 를 적용하여 개발하였다. 기존 Service - Repository 방식이 아니었고, 객체 내부에서 로직을 진행하는 것을 보고 기존에 가지고 있던 생각이 조금 다르게 전환이 되긴 했다. 또한 개발을 진행하면서 관련 팀원끼리의 논의가 활발하고 생산적으로 이루어졌다고 생각한다. 물론 DDD Start! 책만 읽고 진행해서 겉핥기 수준였다고 생각하고 따로 책을 사긴 했는데, 아직 초반에서 벗어나진 못했다.

내가 단독으로 개발한 부분도 있었는데, 본래 단독 컴포넌트로 분리되길 원했으나 내 역량이 그 정도까지는 아닌 것 같아 기존 컴포넌트에 기생하는 식으로 개발이 되었다.
개인적으로 잡은 중점은 '이 코드를 사용하는 입장에서 최대한 편하게 개발', '떼어 내기 편한 구조로 개발' 였고, 완벽하진 못하지만 최대한으로는 반영이 된 것 같아 다행으로 생각했다. 이 코드가 사용되고 크게 이슈가 발생하지 않아 굉장히 뿌듯했다.

Duration 으로 두 날짜 사이의 일 수나 시간을 구했는데, 간혹 1분이 빠지는 버그가 있었다. 로그를 보니 LocalDateTime.plusDays() 에서 간혹 ms 단위가 이전 .888 에서 연산 후 .887 로 변경이 되어 나타나는 현상이었다. Duration 계산 시 .truncateTo(SECONDS) 를 통해 ms 단위는 버리는 것으로 해결하였다.

기타 이슈 대응

타노스가 다녀가서 그런지 갑자기 vm 이 죽거나, 무언가 동작이 하지 않는 등 다양한 이슈들이 많이 발생했다. 내가 일으킨 것도 있었지만 전체적으로 빠른 원인 파악과 수정에 도움이 된 것 같다.

스터디

팀 스터디로는 클린 코드, 오브젝트 (일시 중단) 등이 있었다. 올해 초 리팩토링이나 레거시 코드 활용에 대한 스터디도 있긴 했지만 개인적으로 관심이 가지 않아 참여하지 않았다.

개인적으로는 MSA 에 대한 관심이 많아져서 "마이크로서비스 아키텍쳐 구축" 이나, 과제 2에서 진행했던 DDD 와 관련된 내용을 공부했다. 기타 업무적으로는 Mono/Flux 에 대한 개념도 찾아보고, 현재는 Zookeeper 에 관심이 있어 보고 있는데 이해가 어렵다.

올해 배운 것

페이징
배포, 산출물 관리, rsync, 기타 서버 설정 및 관리에 관한 지식, ... 
apache, nginx
bash script
사내 교육을 통한 Maven, MySQL, MongoDB, kubernetes
MSA, DDD, RabbitMQ, CI/CD, ...

 

마무리

작년도 올해도 뚜렷한 목표가 없이 그때그때 하고 싶은 것을 개발하고 찾아보는 것이 전부였지만, 내가 재밌는 것을 하고 싶고 그 과정에서 얻는게 있기 때문에 나쁘다고 생각하진 않는다.
물론 지금의 나는 겉핥기만 하는 것 같고 언젠가는 밑천이 드러날 것 같다. 그리고 대충 아무거나 해보는 응용 프로그램 개발자인 것 같다. 이런 상태가 언제까지 갈지 확신이 언제 생길지는 잘 모르겠다.

2019년이 되면서 티스토리에 한 달에 하나의 글은 작성하자는 목표를 잡긴 했는데.. 실패했다. 다음에 쓸 글감은 하나 있지만 실제 배포되어 적용이 된 후 확인하여 적을 예정이다.

다음 회고는 언제 쓸 지는 모르겠으나 내년에 꼭 쓰도록 노력해야겠다. 2년을 몰아쓰려니 너무 길어졌다.