2018년 상반기 회고
기승전 포인트 시스템 개편
2017년 회고에서 얘기했었지만, 이제부터는 1년 단위가 아닌 분기 혹은 반기 단위로 회고를 남길 계획이다.
원래는 분기 단위로 하려고 했었지만, 3월에 개인 사정으로 1분기가 그냥 지나가버리고 4월부터는 신규 프로젝트로 바빠서 어쩔수 없이 상반기로 회고를 하게 됐다.
상반기인데 7월도 아니고 웬 8월에 상반기 회고냐 라고 생각할수도 있다.
회사 프로젝트가 7월 말에 최종 오픈하고 8월 초에는 오픈 안정화를 하다보니 늦어지게 됐다.
그래도 프로젝트가 잘 끝나서 기분 좋게 회고를 쓴다.
회사
회사의 일은 2개의 챕터로 분리할 수 있을것 같다.
1 ~ 2 월 - 정산 시스템 운영
기억이 가물가물해서 Jira 티켓을 보니 1월까지는 신규 SAP 연동 시스템 연동작업을 계속 했었다.
작년 연말에 정산 파트의 연동이 있었고, 1월에는 포인트, 세금계산서 등등 정산 외 다른 서비스들의 연동을 진행했었다.
기존에 정산 연동을 진행할 때부터 플랫폼 형식으로 연동 시스템을 구축했기 때문에 추가로 연동하는 것에 크게 문제가 될 건 없었다.
다만 이 플랫폼 형식이라는게 중요한데, 어설픈 프레임워크 형태로 만드는건 안하니만 못하다는 생각을 하게 됐다.
너무 추상화시키고, 재사용성을 강조하다보니 내가 열어놓은 부분 외에는 추가하기가 정말 어려웠다.
잘못된 추상화가 얼마나 부담스러운지 직접 경험하게 되었다.
2월은 대부분이 검증 로직과 자동화 작업, 운영 업무였다.
엑셀로 검증하던 작업을 플랫폼 내에서 해결한다던지, 각 서비스에서 넘어오는 매출 데이터들에 대한 사전 검증 로직을 좀 더 촘촘하게 추가하는 등의 일을 진행했었다.
어느 회사에서나 하는 운영업무와 개선 작업을 했다고 생각한다.
이 기간에 확실히 깨닫게 된 것은 Jenkins + Spring Batch 조합은 환상적이란 것이다.
모든걸 Spring MVC + Tomcat (Spring Boot Web) 으로만 해결하려고 했던 나에게 아주 좋은 시간이였다.
4 ~ 7월 - 신규 포인트 시스템 구축
기존 포인트 시스템이 회사 초창기에 만들어져 있었다.
너무 오래된 시스템이다보니 더이상 확장은 어렵고 유지보수하기는 더더욱 어려운 상황에 도달했다.
뭐 어디든 레거시 시스템이란게 다 이런 형태일꺼라 아마 많은 분들이 이해 하실것 같다.
더 하고 싶은 말은 많지만 해봐야 회사 욕이니 그냥 여기서 Stop..
어찌됐든 기존에는 다른 팀이 대신 운영해주었지만, 이제는 더 그럴수 없어 우리 팀이 포인트 시스템을 가져가야하는 시기가 되었고 팀장님은 개편을 결정하셨다.
팀에서 운영하던 결제 시스템과 정산 시스템은 정책상 클라우드 서비스를 못쓰지만 포인트의 경우 클라우드 서비스가 가능하기에 팀에서도 확장성을 고려해서 AWS로 구축을 결정하게 됐다.
근데 나는 AWS를 운영 서비스에 써본적이 없었다.
물론 그전부터 회사 인프라가 모두 AWS 기반으로 구동되고 있었기에 AWS를 해야한다는 생각이 있었고, 토이 프로젝트로 이것 저것 만들어보면서 사용 중이였다.
하지만 토이는 토이다.
대규모 트래픽 맞아보고 네트워크 튀는거 경험하고 제한적 상황에서 구현 하는 등 그런 경험이 없다면 경험했다고 할 수는 없다고 생각했다.
운영 AWS 환경을 구축한다는 것이 많이 부담되어 3월에 쉬면서 본격적으로 AWS 공부를 시작했다.
덤으로 신규 포인트 도메인을 나라면 어떻게 구축할까 고민하고 구현해봤다.
근데 실제로 이 도메인, 코드대로는 안갔다.
회사 복귀하고 팀 분들과 논의하고 회사 포인트 도메인을 까보니 고민했던대로는 도저히 안되겠더라.
그래도 훨씬 더 좋은 아키텍처와 도메인 구조로 가게 됐다.
3월에 이것저것 실컷해보고 4월에 긴장반 설렘반으로 복직했다.
개편 일정을 논의 하던 중, 4월 중순에 시작해서 7월에 오픈하고 인원은 개발자 3명이라고 한다.
이게 3명이서 3개월만에 가능한건가 라고 잠깐 생각을 했었다.
음.....팀 전체 인원이 6명 (팀장님 빼면 5명)이고 결제 시스템과 정산 시스템 운영도 해야하고, 한 분은 출산 휴가도 가셔야 했기 때문에 추가할 수 있는 여력이 없긴 했다.
와 근데 하반기는 더 큰 산이 있을 줄이야.. 이건 하반기 회고때…
팀장님의 강력한 믿음(?)으로 열심히 달리고 일정에 맞춰 오픈했다.
일정 딜레이 없이 진짜 7월에 오픈했다.
순탄하지는 않았다.
정산쪽에 갑자기 이슈가 많아 그 대응으로 5월에 많은 시간을 보내고(회사 소풍일에 소풍도 못가고…ㅠ), 프로젝트 오픈 한달전 팀장님과 메인 기획자분이 바뀌기도 했다.
뭔가 문제가 있어 변경된건 아니고 더 중요한 목표를 위해 변경된 것이니 오해는 금물!
팀장님들도 인수인계만으로도 정신이 없으셔서 구현이 끝난 뒤, 성능 테스트와 QA, 정책 결정 등은 우리 꼬꼬마 주니어들끼리 진행했다.
그래서 엄청 걱정했다.
아 진짜 이렇게 하면 오픈되는게 맞나 싶기도 하고, 한달만 더 있었으면 좋겠다는 생각도 많이 했었다.
그래도 일정에 차질 없이, 큰 오류나 버그 없이 잘 오픈 되었고 현재까지 안정적으로 운영중이다.
이 프로젝트로 몇억건의 데이터를 가진 노후화된 레거시 프로젝트 개편을 A부터 Z까지 진행한 경험을 얻었다.
시스템 전환 노하우도 많이 얻었다.
이번 신규 포인트 시스템은 오픈하면서 서비스 다운 없이 진행했다.
즉, 서비스가 운영되는 와중에 포인트 시스템이 전면 교체된 것이다.
(서버, DB 서버, 테이블 구조, 프로젝트 코드 전체가 다)
사용자 분들은 포인트 시스템 교체 작업이 있었는지 전혀 체감하지 못했을것 같다.
포인트 적립도, 취소도 전부 돌아가고 있는 상태에서 교체했으니깐.
(포인트 사용은 잠깐 막았다.)
이걸 위해서 서비스 오픈을 3단계로 나눠서 3번 진행했었다.
기존 도메인을 도저히 그대로 쓸 수 없던 형태였기 때문에 도메인도 완전히 개편되었고, 테이블 역시 새로 구조를 잡았고 데이터도 새 도메인 형태로 전체 마이그레이션까지 진행했다.
(몇 천만건도 아니고 몇 억건을 마이그레이션 다했다.)
도메인 구조까지 완전히 전환되는 개편에서 어떻게 안정적으로 오픈하면 되는지에 대해서 제대로 익힐 수 있었다.
위 얘기와 별개로 개인적인 소감이지만, 이 프로젝트로 팀의 파워가 올라갔다고 생각한다.
우리팀은 팀 조합이 정말 좋다.
인프라, 도메인 지식, 어플리케이션 구현 등등 각자 자신의 전문 분야가 확실하고 부족한 부분을 서로가 잘 메꿔주고 있다.
이건 장점이면서도 확실한 단점인데, 한 사람이 빠지면 구멍이 굉장히 크다.
가령 우리팀에는 인프라를 정말 잘하시는 분이 계신다.
그리고 우리 팀은 사내에서 유일하게 AWS를 쓰지 않고 국내 IDC를 쓰고 서버/DB를 직접 다 관리하고 있었다.
(이젠 포인트 시스템 때문에 AWS도 쓰고 있는 팀이 됐다.)
관리하는 서버 대수만 수십대이고 (개발/QA 서버 빼고), DB 백업이나 my.cnf 튜닝, HA 구성, 테이블 파티셔닝까지 그 분 혼자서 다하고 있었다.
그러다보니 만약 이번 포인트 시스템도 그 분이 인프라를 구축하게 되면 그 분은 우리팀의 SPOF (Single Point Of Failure)이 된다.
팀의 입장에서 봤을때 너무 위험한 구조였다.
그래서 일부러 이번 프로젝트에는 그 분이 인프라를 못하게 했다.
그리고 어플리케이션 구현 위주로 담당하셨다.
개편을 진행하던 3명이서 서로 잘하는 분야 절반, 가장 못하는 분야 절반씩을 맡아서 진행했다.
자신 없는 분야를 100% 맡아 공부하면서 진행하기엔 일정상 무리였다.
같이 진행 했던 다른 한분은 수억건이 넘는 레거시 데이터를 새로운 도메인 모델로 마이그레이션을 진행해주셨다.
마이그레이션을 위한 인프라 환경 구축과 프로젝트 구성도 그 분이 직접 다 하셨다.
레거시를 개편해보신 분들은 아시겠지만, 시스템 개편의 성공과 실패는 마이그레이션이 좌지우지한다.
예전 데이터를 신규 모델로 마이그레이션 못하면 서비스는 오픈 하지 못한다.
특히 포인트 같은 경우엔 과거의 데이터가 다 마이그레이션 되야만 했다.
2011년 부터 쌓인 모든 데이터를 신규 모델로 완전히 마이그레이션했다.
테이블 형태가 완전히 달라서 3개월 안에 혼자서 마이그레이션이 가능할까 걱정이 됐다.
특히 Update가 되는 데이터들은 그 이력이 제대로 남겨져 있지 않아 틀어진 데이터 맞추는게 지옥이다.
그럼에도 틀어진 수억건의 데이터를 어떻게든 맞춰서 기간내에 마이그레이션이 끝났다.
그리고 나는 신규 시스템의 AWS 인프라와 배포 환경, 완전히 개편된 신규 도메인 모델의 API 구현과 프로젝트 전체 구조를 잡았다.
자신 있는 분야가 없지만, 특히나 인프라를 못했던 내 입장에서는 정말 좋은 기회였다.
현재 포인트 시스템의 인프라는 그 분은 Sub로, 내가 Main으로 다루고 있다.
3번째 회사까지 오면서 느낀거지만 팀에는 항상 SPOF가 존재한다.
인프라, 도메인 지식이 특히나 심한데 어플리케이션 구현은 팀의 모든 사람이 하지만, 인프라와 도메인 지식은 특정인들만 다루는 경우가 많다.
이러면 진짜 위기감을 느끼고 그 일들을 분배시킬 수 있어야 한다.
도메인 지식에 대해서 과소평가하는 경향이 있는데, 도메인/정책을 모를때 특정인에게 계속 물어보고 있다면 어서 빨리 본인이 도메인 지식을 쌓을려고 노력해야만 한다.
인프라도 마찬가지로 한 사람이 다 하고 있다면 큰일이다.
(출처: 권남님 Wiki - 신규 Web 서비스시 고려해 볼 사항)
이번 포인트 프로젝트가 이런 문제를 해결하는 좋은 사례가 된 것 같다.
물론 이걸 했다고 해서 이제 인프라에 대해서 좀 알게 됐다 이런 건방진 이야기를 하는건 아니다.
그냥 해봤다 정도다.
요즘도 열심히 그 분께 인프라를 많이 배우고 있다.
구현 외에도 성능 테스트, RDS 페일오버 테스트, 각종 타임아웃 테스트도 직접 진행했다.
실제 신규 서비스 오픈전에 성능 테스트를 진행하고 튜닝을 처음 해봤다.
Connection Pool, 커널 파라미터, Nginx, RDS 파라미터 등등을 하나씩 수정하고 테스트하면서 정말 즐거웠다.
진짜 신나게 설정값 바꿔가면서 성능 테스트를 진행했다.
기존에 애매하게 알고 있었던 개념들에 대해서도 제대로 검증해볼 수 있는 좋은 기회였다.
도메인 측면에서 보면 이번 포인트 시스템은 Upadte/Delete를 완전히 뺐다.
즉, 포인트 차감/만료 등의 데이터 변경이 필요한 이벤트들까지 전부 Insert만으로 구현되어 있다.
뭔가 거창한 방법론을 이야기 하고 싶은건 아니다.
그냥 주요한 비지니스와 관련된 모든 테이블은 수정/삭제가 없다.
그런 데이터 모델을 구현하고 실제 운영 서비스와 수억건이 넘는 데이터에 반영 해봤다.
개인의 만족을 위해 기술을 쓴게 아니다.
기존의 문제와 앞으로의 문제를 해결하기 위해서는 현재와 같이 Update 모델에선 불가능하기 때문에 이 모델을 썼고 제대로 적용했다.
데이터 모델 설계로 코딩 한줄 못하고 몇주를 보낼때 진짜 스트레스 많이 받긴 했었다.
그래도 그렇게 고민한 결과 현재까지 틀어진 데이터 없이, 로직상 오류 없이 잘 수행되고 있다.
그리고 기존에 있던 문제들도 오픈후 더이상 발생하지 않고 있다.
나는 신기술 쓰는걸 정말 싫어한다.
그 기술을 썼다가 문제가 발생하면 해결을 해야한다.
나만의 만족으로 썼다가 문제 나서 해결 못하는 것만큼 꼴불견은 없다고 생각한다.
새로운 기술, 새로운 모델을 쓰는건 현재 환경에선 더이상 문제를 해결할 수 없다고 느낄때만 엄청 엄청 부담감을 느끼면서 적용한다.
어찌 됐든 이번 포인트 프로젝트를 진행하면서 한단계 더 성장했다는걸 많이 느꼈다.
정말 많이 체감했고, 기분이 너무 좋았다.
(스트레스는 엄청 받았지만…)
블로그
2018년 1월 ~ 7월까지 총 72개의 글을 썼다.
월 평균 10개의 글을 쓴 셈이다.
평균 작성수가 많아진 이유는 아무래도 시리즈물이 많아서 그런것 같다.
스프링부트로 웹 서비스 출시하기 (10부작)
3번째 직장에 오기까지 (6부작)
AWS Code Deploy로 Jenkins & Spring Batch 배포 및 운영하기 (3부작)
텔레그램 & AWS 서비스 연동하기 (3부작)
Jenkins로 Gradle Multi Module 프로젝트 AWS Beanstalk에 배포하기 (3부작)
AWS Beanstalk으로 진행하는 성능 튜닝 시리즈 (4부작)
아마 올 한해가 끝날때 쯤엔 100개 이상 될 것 같다.
특히 현재 쓰고 있는 Spring Batch In Action 시리즈는 가장 긴 시리즈가 될 것 같아서 기대중이다.
블로그에 글 쓰는건 여전히 즐겁기 때문에 하반기에도, 내년에도 계속 꾸준히 할 수 있을것 같다.
다만, 브런치에 대해서는 다시 생각중이다.
다른 것보다 블로그에 비해 브런치의 장점을 느끼지 못하고 있다.
브런치가 티스토리보다 좋은 건 분명 몇가지 있다.
웹 에디터는 확실히 브런치가 좋다.
전용 모바일 앱이 있다.
별다른 디자인 없이도 UX가 이쁘게 나온다
하지만 나는 글을 VS Code와 마크다운으로 작성하다보니 브런치가 더 불편하다.
웹 에디터는 단순 텍스트 외에 다른 효과를 주려면 마우스에 손이 갈 수 밖에 없는데, 마크 다운은 그럴 필요 없이 키보드로 쭉 치면 된다
더군다나 VS Code의 단축키를 IntelliJ Key Mapping으로 맞춰서 쓰니 기존에 사용하던 단축키 그대로 사용할 수 있는데 굳이 웹 에디터를 쓰고 싶지 없다.
VS Code와 마크다운으로 글 쓰는게 너무 편리하다.
이건 그 어떤 웹 에디터에서도 못따라갈 것 같다.
미디움이나 스팀잇, 네이버 블로그등과 같은 대세 플랫폼을 안쓰는 이유도 이것 때문이다.
브런치에서 티스토리처럼 오픈 API를 제공한다면 고민해볼것 같다.
그러면 스크립트로 작성된 마크다운을 브런치 오픈 API로 쏘면 되니 티스토리처럼 편하게 쓸 수 있을것 같다.
물론 브런치로 책을 낼 수 있다는 장점도 있다.
하지만 그 조건이 굉장히 까다롭다.
이런 저런 이유로 개발자로서 브런치라는 플랫폼은 티스토리에 비해 크게 메리트가 없다고 느껴진다.
굳이 익숙한 개발툴과 단축키로 글을 쓸 수 있는 상황에서 브런치는 잘 모르겠다.
8월이면 티스토리에도 https가 지원되서 더 많이 사용할 것 같다.
뭐 이런 대규모 개편이 한번에 될리 없어서 바로 될지는 모르겠지만..
교육
올해 상반기에는 하나의 교육을 수강했다.
과정은 워크샵이란 타이틀에 맞게 AWS 배포/모니터링 등에 대한 초보자들을 위한 내용이였다.
하지만 내가 AWS 초보자였기 때문에 더할나위 없이 좋은 강의였다.
회사에서는 Beanstalk을 통해서 배포와 운영을 하고 있지만, 이 강의는 Code Deploy를 기반으로 진행됐다.
그래서 둘 다 경험해볼 수 있었다.
특히 강사님이 리멤버에서 Devops로 계시다보니 리멤버에선 어떻게 배포와 AWS를 운영하는지 들어볼 수 있어서 좋았다.
포인트 시스템에선 배포/운영 환경을 어떻게 구축해야겠다는 구상을 미리 해볼 수 있는 계기가 되었다.
이 강의를 들으면서 본격적으로 AWS에 관련된 글을 계속 올리게 되었다.
그만큼 이제 Spring, 테스트 코드에 대한 관심과 AWS에 관한 관심의 비중이 거의 비슷해졌다.
AWS의 기본기를 제대로 알려주셔서 정말 감사했다.
강사님이 발표때 이번이 마지막 기수라고 하셨는데, 혹시나 다음 기수가 생긴다면 AWS에 관심 있으신 분들은 꼭 수강해보시길 추천한다.
오픈소스
올해 상반기에는 1개의 오픈소스를 만들었다.
AWS의 메세징 큐 서비스인 SQS와 동일한 인터페이스를 가진 ElasticMQ를 Spring Boot에서 임베디드로 사용할 수 있게 랩핑한 라이브러리이다.
즉, 의존성만 추가하면 H2 사용하듯이 SQS를 사용할 수 있게 해준다.
당장은 부족한게 아직 많다.
(Mock SQS의 종료 라이프 사이클을 SQS Listner Bean 보다 후 순위로 둬야하는 등 고칠점이 많다.)
그럼에도 이 오픈소스 자랑을 조금 하고 싶다.
이번 포인트 시스템은 AWS SQS가 핵심이다.
DB가 죽어도 적립/적립취소/사용취소 등은 처리되어야 한다
누락되는 요청 없이 언젠가는 요청이 처리된다
라는 2가지 전제조건을 처리하기 위해서 메세지 큐 서비스가 필수였고, 우린 AWS SQS를 선택했다.
그러다보니 모든 기능은 SQS를 기반으로 구성해야만 했다.
하지만 격리된 환경에서 사용할 Mock 제품이 없었다
다른 서비스는 대체품이 존재했다.
RDS : H2
Elastic Cache Redis : Embedded Redis
헌데 SQS는 보편적인 Mock 솔루션이 없었다.
개발용 AWS를 사용해선 안된다.
모두가 접근할 수 있는 공용 저장소를 사용하는 순간 서로가 서로의 테스트를 침범하게 되어 격리된 테스트 환경 구축을 못하게 된다.
(내가 넣은 SQS 메세지를 다른 사람의 테스트에서 수신해버려서 내 테스트가 깨지는 등)
그래서 이런 Mock 제품이 필요하다고 생각을 했고, ElasticMQ가 SQS와 동일한 인터페이스를 제공한다는걸 발견하게 되서 Spring Boot에서 쉽게 사용할 수 있도록 랩핑하였다.
이렇게 라이브러리를 만들고 포인트 시스템 구축시에 사용해보니 로컬 개발하면서 한번도 서버를 실행해본적이 없다.
모든걸 다 테스트 코드로만 실행하고 검증했다.
내가 만든 SQS Listner가 제대로 메세지를 수신하는지
내가 만든 QueueTemplate이 메세지를 제대로 송신하는지
내가 지정한 횟수만큼 실패시 Dead Letter Queue에 전달하는지
메세지가 원하는대로 JSON 전환되어 전달되는지
등등 Mocking으로 해결할 수 없는 테스트를 완전히 구현할 수 있었다.
브라우저로 테스트하는 것은 개발서버에 배포한 뒤에나 했다.
근데 아무런 문제가 없었다.
Spring Boot AWS Mock 을 기준으로 구현한 모든 코드들과 테스트 코드들이 실제 AWS 위에서도 의도한대로 잘 작동되었던 것이다.
이걸 계기로 AWS SQS도 테스트 코드를 작성할 수 있게 되었다.
Jenkins에서 지속적으로 통합테스트를 수행할때도, 개발자 개개인의 로컬 PC에서 테스트를 수행할때도 서로 격리된 환경에서 SQS 관련 테스트 코드를 수행할 수 있게 되었다.
개인적인 가치관이지만, 좋은 프로젝트는 git에서 clone 받으면 바로 로컬에서 실행될 수 있어야 한다고 생각한다.
git clone 받은 뒤에 이것도 해야하고 저것도 해야하는 등등의 추가 작업이 필요하면 그것 역시 비용이라고 생각한다.
하반기에는 이 라이브러리를 좀 더 고도화시켜서 (Redis, S3등 추가 및 버그 수정) AWS 서비스를 사용하는 프로젝트에서는 필수 라이브러리가 되게 하고 싶다.
발표
상반기에 생애 처음으로 커뮤니티에서 발표를 진행 했다.
(2월) KCD 2018 - IntelliJ IDEA만으로 개발하기
작년 12월에 JetBrains Korea User Group의 우성님, 용근님과 함께 세미나를 기획하게 되었다.
아무래도 운영진으로 활동하면서 본격적으로 커뮤니티 활성화가 필요하다는 생각을 하게 되었고, KCD는 아주 좋은 자리라고 생각했다.
그래서 1월부터는 블로그에 발표 내용을 분할 정리하면서 조금씩 준비를 했다.
중간에 팀내에서 한번 발표하면서 최종 점검을 하고 팀 분들의 코멘트로 발표 내용을 좀 더 보강했다.
발표일에는 막 떨리고 그러진 않았다.
다만 이 내용을 다들 알고 계시면 어쩌나 하는 걱정이 있었다.
다행히 발표 중에 들으시는 분들 표정에서는 다들 신기해하시면서 보셨던 것 같다.
반응이 꽤 좋았던 것 같아서 준비했던 시간이 아깝지 않았다.
세미나가 끝나고 우성님과 얘기를 하면서 다음 발표에 대해서도 한번 더 고민해보게 되었다.
사내 밋업 행사에서 발표한건 완전 예상치 못했던 일이다.
3월에 쉬던 중에 회사에서 연락을 받고 발표 주제를 고민하게 됐다.
좋은 소식이라...4월에 회사 복귀하고 나서 주제를 계속 고민했다.
2개 주제에서 갈팡지팡 하다가 결국 "만 3년차가 배민에 와서 배운것들" 이란 주제로 결정하고 준비를 하게 됐다.
(입사 할때가 만 3년이였다.)
나머지 1개 주제는 "테크캠프 떨어지면 뭘하면 좋을까" 였다.
다크포스 좔좔이라 탈락했다.
만 3년차 백엔드 개발자가 배민에 와서 배운것들 중에는 기술적인 면도 있고, 비기술적인 면도 있었다.
그 내용을 발표했다.
기술적인거야 이미 블로그에 잘 정리하고 있었으니 여기서 또 얘기할 필요는 없을것 같다.
비 기술적인면은 "일이 되게 한다는게 무엇인지" 에 대해 많이 배웠다.
이 회사에 오고나서 처음으로 같이 일했던 사수분이나 (지금은 딴팀 갔지만) 팀장님이나 (이분도 딴팀 가셨네) "일이 되게 하는 사람"이셨다.
우리팀이 손해를 보더라도 그게 전체 아키텍처 방향에 맞다면 진행하는 걸 보면서 일이 되게 한다는게 어떤건지 바로 옆에서 많이 배웠다.
이번 포인트 시스템을 진행하면서 내가 어떻게 행동했나 돌이켜보면 아직 한참 멀었다는 생각을 하게 된다.
이 주제는 현재 여름 인턴을 하고 계신 분들께 버전2로 한번 더 발표하긴 했었다.
(재탕 죄송합니다 ㅠ)
발표 하고 나서 너무 꼰대스러웠던것 같고, 너무 잘난척 한것 같고 막 이런 저런 생각이 들어서 후회도 조금 됐었다.
그래도 들으셨던 인턴 분들이나 팀 분들이 좋았다고 해주셔서 나름 위로를 했었다.
다음부터는 그래도 이런 기분이 안들게 조심해야겠다.
하반기에는?
일단 2가지 교육을 신청했다.
패스트캠퍼스의 DevOps로 활용하는 클라우드 플랫폼 Workshop
사내 Java 교육
패스트캠퍼스의 DevOps로 활용하는 클라우드 플랫폼 Workshop를 수강한 이유는 간단하다.
코드로 인프라를 관리하는 방법을 배우고 싶기 때문이다.
나는 모든걸 코드로 관리하고 Git으로 형상관리를 할 수 있어야 한다고 생각한다.
예를 들어 우리팀은 IntelliJ의 .http를 사용하도록 권장하고, Postman은 쓰지 않도록 하고 있다.
API 요청 스펙도 Git 으로 형상 관리를 하게 되었고, 실제로 써보니 정말 유용한걸 느끼고 있다.
그래서 인프라도 마찬가지로 Code로 작성하여 형상 관리 하고싶다는 생각에 Terraform을 배우고자 수강하게 되었다.
스칼라, 코틀린, 파이썬 혹은 새로운 언어와 프레임워크를 공부에 왜 포함시키지 않냐고 할 수도 있다.
하지만 다양한 언어를 다루는 사람이 되고 싶은 마음은 전혀 없다.
서비스를 구현하는 언어와 프레임워크는 최대한 1 ~ 2개로 좁혀서 진행하는게 좋다고 생각한다.
솔직히 1개도 제대로 하는건 어렵다고 생각한다.
주력 언어와 프레임워크 조차 제대로 모르면서 다양한 언어를 쓰고 있다는걸 장점으로 내세우는건 도대체 무슨 의도인지 모르겠다.
대신 백엔드의 전반적인 기본기를 잘 쌓고 싶다.
네트워크, 리눅스, RDBMS, 메세징 서비스, 시스템 디자인, DDD, 테스트 코드, 클린 코드, 리팩토링 등을 더 잘하고 싶다.
이 중에서 특출나게 잘하는게 없을수도 있지만, 그래도 두루두루 기본은 했으면 좋겠다.
풀스택 개발자, DevOps 엔지니어와 같은 그런 거창한 단어를 붙이고 싶은게 아니다.
그냥 백엔드 개발자로서 어떤 문제가 발생하면 Java 코드만 쳐다보는 개발자가 되고 싶지 않다.
문제를 해결할 수 있는 개발자가 되고 싶은거다.
Terraform외에도 NoSQL 계열을 하나 익혀야할 것 같다.
지금 포인트 시스템에 데이터 쌓이는 속도가 너무 가파르다.
장애 나면 진짜 스트레스 엄청 받기 때문에 최대한 RDBMS로 버티고 싶었다.
근데 지금 속도라면 더이상 RDBMS로는 안될수도 있다고 생각한다.
그래서 오픈전부터 이 문제를 어떻게 해결해야하나 고민하고 있고, 여러 방법을 고려중이다. 그 중 하나로 NoSQL을 생각을 하고 있는데, 막상 그때가 되서 쓸려고 하면 시간이 너무 오래 걸린다.
그래서 미리 공부해놓을 계획이다.
공부했지만 안쓰면 어쩔수 없다 정도다.
내가 공부했다고해서 회사에서 꼭 써야할 이유는 없다.
적정 기술을 쓰면 된다고 생각한다.
나는 어떤 기술을 익힐때 항상 예습과 복습만 한다.
회사에서 쓰고 있는 기술을 좀 더 확실히 제대로 사용하기 위한 복습과
회사에서 앞으로 쓰게 될 기술을 미리 연습해놓는 예습 2가지만 한다.
무조건 회사가 기준이다.
회사에서 쓰지 않을 기술에 대해서는 일절 관심 없다.
결국 트래픽 맞아봐고 비지니스에 녹여봐야 내 것이 되는데, localhost:8080에서만 쓸 기술에 대해서 관심 없다.
그리고 개인적으로 인생의 부채로 생각만 하고 있는 영어 공부를 시작하려고 한다.
조은님의 패스트원 후기를 보고 진짜 시작해야겠다고 생각했다.
막연하게 영어 공부를 해야겠다고만 생각하면 진행이 잘 안되어서 배운 영어로 단기간에 해낼 수 있는 목표를 세웠다.
이건 달성하게 되면 그때 공개할 예정이다.
(안하면 부끄러우니깐)
느낌은 달성할 수 있을것 같아서 목표 자체는 잘 세운것 같다.
당장은 시작 못한다.
회사의 중요한 프로젝트에 합류하게 되어 10월까지는 굉장히 바쁠것 같다.
10월까지는 잘 참아봐야겠다.
마무리
처음 개발자로 취업을 한건 2014년 2월이였다.
벌써 4년 6개월이 지나가고 있다.
시간이 너무 빨리 지나간다.
눈깜짝 할 사이에 7년차, 10년차가 되겠지.
그때도 회고를 쓰고 있을까?
최소한 하반기 회고에는 할 말이 많았으면 좋겠다.
