2024년 회고
2023년도 회고
# 2023년도 목표 달성
- 술술 사이드 프로젝트 출시 (3월 목표)
- 7월 출시 완료
- 새로운 사이드 프로젝트...?
- 청년모아 mini 사이드 프로젝트 합류
- 컨퍼런스, 해커톤 1회 이상 씩 참여하기
- 여럿 시도했지만 결국 둘 다 미달성
- 오픈소스 기여 1회 이상 해보기
- 미달성
생각했던 것 보다 시간이 빠르게 흘렀던 한 해였다.
# 기술적 성장
내가 예상했던 성장 흐름은 hope 선 처럼 선형적 성장이었는데, 실제로 돌이켜보면 로그함수처럼 성장했던 것 같다.
아무래도 23년도 처음 회사에 와서 마구마구 흡수했던 시절은 기술적으로 가장 크게 성장했다고 느껴졌고,
업무가 어느정도 익숙해진 24년도는 그 기울기가 원만해졌다고 느낀 것이다.
23년도는 내 기술적 천장을 가늠했고, 24년도는 천장을 찍기위해 살짝 놓쳤던 부분들을 채우는, 그런 과정이라고 느껴졌다.
중요한건 기울기를 유지하면서도 디테일을 챙기는 것이라고 생각한다.
그림으로 표현하자면
약간 요런 느낌?
25년도에는 천장과 디테일을 조금씩 죽순마냥 같이 키워나가보고 싶다.
---
여담
24년도 하반기에는 라인에서 오신 새로운 서버 개발자분이 합류하셨는데, 항상 독특한 아이디어로 문제 해결 방안을 제시하시는게 인상깊다.
덕분에 우리팀 개발문화도 더 활성화 된 것 같고 기술적으로 자극을 받고 있음을 느껴서 굉장히 즐겁다!
역시 배울 사람이 곁에 있는게 성장에 참 많은 도움이 되는 것 같다.
# 기술 이야기 이모저모
## 분산 트랜잭션 관리
MSA 환경에서의 이종간 디비의 트랜잭션을 적절하게 핸들하지 못 해서 오류가나 트러블슈팅했던 경험이 있다.
기존에도 보상 트랜잭션이나 SAGA 패턴에 관심이 있어서 훑어본적이 있지만 실제로 겪어보니 더 주의있게 다뤄야할 부분이란걸 느낄 수 있었다.
## Redis로 이것저것 해보기
업무를 하면서 올해는 특히 redis를 많이 활용했던 것 같다. 캐시나 분산락으로 많이 활용했고, redis 해시 자료구조를 활용한 노션의 같이보는 기능을 만들었던게 기억에 남는다.
TTL을 설정할 수 있고, 다양한 자료구조를 지원한다는 점이 참 매력적인 저장소인 것 같다.
## 배포전략과 점진적 MIG
새로운 기능을 배포할 때 롤백 전략이나 실패시 대응방안을 고려하는 능력이 많이 길러진 것 같다.
(하도 장애내고 쳐맞아서 생존적으로 배운것일 수도 있다...)
어찌보면 좀 더 보수적이게 된 것일 수도 있는데 안정적인 서비스를 위해서라면 속도보다는 안정성이 더 중요하니까
## 새로운 기술들 찍먹
팀에 새로 합류하신 서버 개발자분이 기술적인 조예가 상당하셔서 많은 인사이트와 영감을 받고 있다.
Spring Cloud 계열 기술들의 분산 추적, 메트릭 컨피그등에 대한 개념을 처음 접해서 적용해보았다.
---
QueryDSL 라이브러리가 유지보수가 되지 않아서 새로운 쿼리빌더 라이브러리를 알아보던 도중 라인에서 만든 kotlin-jdsl이라는 라이브러리를 알게되었다.
https://github.com/line/kotlin-jdsl
QClass를 미리 빌드시점에 만들지 않아서 좋은 점 빼고는 아직 잘 모르겠다. 회사에서도 도입해서 쓰는 팀이 있던데 아직까지 QueryDSL과 차이점을 잘 모르겠다.
3.0버전도 새로나오고 업데이트도 꾸준히 하고 있는 점이 장점아닐까
(QueryDSL은 페이징에 group by을 같이 못 쓰는 버그를 아직도 안 고치는 건지.. 못 고치는건지 방치하고 있다)
여담으로 CTE를 자주 쓸 때가 있는데 이를 JPA나 dsl 라이브러리에서 지원을 안 해줘서 언넝 해줬으면 하는 바람이 있다
보니까 하이버네이트 최신 버전에서는 지원을 시작했다고 하는 것 같더라
---
서버 말고도 프론트도 좀 공부를 해봐야겠다는 생각을 예전부터 갖고있었는데 행동으로 옮기진 못 했다.
올해는 그래도 next로 간단한 퀴즈 앱이랑 어드민 페이지등을 만들어보면서 찍먹해봤다.
역시 css는 어렵다.
# 소프트 스킬과 마인드 셋
회사생활을 하면서 기술적 역량만큼 커뮤니케이션 능력(소프트스킬)이 매우 중요하다고 다시금 느끼고 있다.
1. 요구사항 분석은 매우 꼼꼼하자
알더라도 더블체크 하고, 세부사항을 면밀히 파악해서 일을 2번 안 하기
2. 요구사항이 불명확 할 땐 잠시 기다리기 or 제안하기
개발먼저 와다다 시작하지 말고 잠시 flow 정리나 요건 정리를 먼저하고 하는게 능률이 훨씬 좋았다.
3. 꼭 필요한 일 인지 체크하기
개발자 입장에서의 관점을 제시하거나 커뮤니케이션으로 풀어서 안 해도 될 일이 됐던 적이 꽤 있었다. 먼저 소통해보기
4. 부드럽게 피드백 하기
상대방 기분은 안 나쁘게 하면서, 빙빙돌리지 말고 직설적이게 피드백을 해야하는데 역시 어렵다.
라포를 더 형성하고 사소한 것 부터 상냥하게 피드백을 자주 해보자
5. 항상 겸손하기
업무와 기술에 익숙해지다보면 내가 제일 잘 아는 것 처럼 느껴질 때가 있다. 동료가 어떤 제안을 하더라도 열린 관점에서 경청하고 수용할 수 있는 자세를 잃지 말아야겠다고 생각했다.
아는 것 보다 모르는 것에 더 적극적으로 임하고 "가르치기"보단 "제안하기" 화법으로 대화를 하도록 노력하자고 마음먹었다
6. 조급해하지 않기
cs가 몰려오고 요청도 몰려오고 기한도 촉박할 때 항상 조급함때문에 스트레스를 많이 받았던 것 같다.
사실 한 템포 쉬고 들여다보면 별거 아니였던 것들인데 왜 그렇게 스트레스를 받았는지 모르겠다.
# 사이드 프로젝트에 관하여
나는 꼭 회사일이 여유가 생기면 여가시간에 개발을 하는 이상한 병이 있다(...)
그래서 너무 가볍게 사이드 프로젝트를 시작 했던게 아닐까 싶다.
2023년도에 시작했던 사이드 프로젝트인 '술술'은 결과적으로 실패한 사이드 프로젝트라고 생각한다.
실패라고 생각하는 이유
1. mvp가 너무 컸고, 인원수도 너무 많았다.
직장인들로 구성되다보니 시간투자가 절대적으로 많을 수가 없었고, 여가시간에 하는 '사이드'라는 생각에 취준생 때 하는 그 '사이드'와 절박함(?) 정도도 다들 달랐다.
2. 각 팀원들의 목적이 sync되지 않았다.
어떤 팀원은 출시부터 운영까지, 어떤 팀원은 단순 새로운 기술 경험을, 어떤 팀원은 그냥 협업 경험을... 등등 각각 팀원들이 이 프로젝트로 얻고자하는게 달랐다.
3. 기획과 디자인이 완성되지 않은 상태에서 팀원을 모집했다.
가장 큰 패착사유라고 생각한다. 이것은 100% 나의 실수이다.
너무 들뜬나머지(?) 각 분야 팀원들을 모아놓고 기획을 시작했다.
당연히 기획~디자인까지 시간이 엄청 오래걸렸고, 그 과정에서 지친 팀원들도 많았을 것이다.
결국 일정을 계속 못 지키게 되고 팀원들의 열정도 점점 식어져가면서 서비스의 완성도는 처참했다.
이번 사이드 프로젝트로 깨닫게 된 것들은
1. 기획과 디자인이 명확해지면 개발자를 모으자
2. 순수 개발기간은 맥시멈 1달. (mvp는 진짜 제발 작고작고 제발 작게)
3. 정말 최소 인원으로
정도 이다.
술술 프로젝트를 통해서 단기간에 스프린트 형식으로 맺고끝냄이 명확한 해커톤에 더 관심이 생겼다.
(여담이지만, 한 2~3번정도 해커톤 신청을 하고 팀도 꾸렸었는데 모두 잘 되지 못 했다...)
# 나의 장점과 단점
2년정도 실무 개발을 하면서 나의 개발적 장점과 단점을 어느정도 파악하였는데,
장점
- 개발을 매우 스피디하게 한다.
단점
- 꼼꼼함이 부족하다. (특히 테스트)
이러한 특성 때문에 일을 비효율적으로 했던 적이 종종 있다.
- 업무 요건을 명확하게 파악하지 않고 빠르게만 개발하여 결국 개발을 다시하게 됨
- 엣지케이스를 충분히 고려하지 못 해서 장애 발생
생각해보면 마냥 '빠르게 개발하기'가 장점인지도 모르겠다.
충분한 시간과 여유를 가지고 좀 더 꼼꼼하게 개발을 하기 위해 노력하고 있다.
1. cs 인입, 외부 변수를 충분히 고려하여 내가 가능한 일정 * 1.3정도로 개발일정 산정하기
2. 요건확립을 최우선 적으로. 요건이 확립되더라도 2~3일정도 상호피드백을 거치면서 엣지케이스 체크하기. 개발은 천천히 꼼꼼하게
3. 꼭 실제 호출(실행)테스트 해보고 데이터 확인하기!!!
# 금융감독원 종합검사
토스뱅크가 첫 금융감독원 정기 검사를 받았다.
https://it.chosun.com/news/articleView.html?idxno=2023092126302
난 AML 파트 개발자로써, 검사역과 인터뷰까지 해보는 경험을 해봤다.
자료추출하느라 하루 15시간씩 근무한 적이 많았다.
정말 힘들었지만 또 언제 이런 경험 해보겠나.. 했다.
이번 검사를 통해 엔지니어링 적 리스크 보다 비즈니스 적 리스크를 더 크게 고려해야하는 경우도 있음을 깨달았고,
사소할 것 같았던 이슈가 큰 비즈니스적 임팩트를 불러올 수 있음도 느꼈다.
그간 너무 겁없이(?) 내재화를 속도감 있게 했던 것은 아닐까 하며 되돌아볼 수 있는 시간이었다.
결론적으로 별탈 없이 잘 마무리 되었다! (다행히 짤리지 않았습니다..)
# 독서
도메인 주도 개발 시작하기
https://product.kyobobook.co.kr/detail/S000001810495
회사 동료 추천으로 읽게된 책인데 DDD에 대한 전반적인 개념을 잡을 수 있어서 좋았다.
재밌어서 되게 금방 읽어버렸는데, 나중에 복습할 때 또 읽어도 좋을 것 같다. 추천
좋은 코드, 나쁜 코드
https://www.yes24.com/Product/Goods/109366833
사내 스터디 1번째로 했던 책이다.
생각보다 당연한 이야기를 조금 장황하게 하고 있는 것 같은 느낌이 들어서 별로였다. 비추천
만들면서 배우는 클린 아키텍처
https://www.yes24.com/Product/Goods/105138479
사내 스터디로 2번째로 했던 책이다.
책 내용은 헥사고날 아키텍처에 관한 이야기인데 평소 고민하던 것들을 책에서 명시적으로 정리해주는 것들이 종종 있어서 좋았다.
책도 책인데 읽고 토론했던 스터디 방식이 인상깊었어서 더 기억에 남는다.
파이토치 딥 러닝 프로그래밍
https://www.yes24.com/Product/Goods/111704966
술술 프로젝트를 하면서 딥러닝이 궁금해져서 무작정 구매해서 읽어봤다.
수학과 시절에 배웠던 것들이 코드로 구현되어 모델이 어떻게 학습이 되는지 원리를 코드로 알 수 있어서 너무 재밌게 읽었었다.
딥러닝 실습을 찍먹해보고 싶다면 추천
# 2025년에는?
어느덧 토스뱅크에 입사한지 2년이 지났고 곧 3년차 개발자가 되어간다 (시간이 참 빠르다)
새로운 기술을 접목시켜보고 학습하는것도 즐겁지만, '더 프로다운' 모습은 저거에 더불어
- 어떻게 안정성있는 운영을 할 것인지
- 영향도 파악과 위험요소 식별을 어떻게 더 잘할 것인지
- 어떻게 장애를 안 낼 것인지 (사실 장애를 안 내는건 서비스가 살아있으면 불가능하다고 생각한다.. 그치만 은행으로써 갖춰야할 보장된 안정성과 개발자로써 추구해야할 혁신의 중간에서 잘 조율을 하는게 내년 과제로 삼고싶다)
를 고민해보면서 성장해가고 싶다.
1. 책을 더 많이 읽자 (목표 7권)
2. 해외여행 다녀오기
3. 더 프로답게 일하기