2021 전체 회고

2021년은 많은 다양한 것들을 해보았던 해

2021?

2021년은 저에게 있어서 새로운 스타트를 시작했고,

많은 것을 경험하게 해준 한해였습니다.

 

본격적으로 IT 서비스 회사에서 근무를 시작하게 되었고,

서비스에 대한 비즈니스 로직과 비즈니스를 제공하기 위한 기술에 대해 많은 것을 공부했었네요

 

새롭게 언어를 배웠던 kotlin 부터 시작해서 JPA Feign Vue3 .. 등 다양한 기술스택을 경험할 수 있었어요

기술스택에 대한 새로움도 있었지만 새로운 도메인을 파악하고 문제를 해결하기 위한 시도들도 많이 해본 한해였네요

와 너무 정신없었지만 드디어 끝났다

 

블로그에는 제가 도메인 관련한 내용들을 적을 순 없으니..

개발자로써 비즈니스에 대한 해결방식과, 새롭게 배운 기술 스택에 대해 한번 회고하는 시간을 가져보도록 하겠습니다.

 

개발자에게 비즈니스란?

비즈니스를 직접 경험해볼 수 있는 새로운 한해였기에 많은 깨달음을 얻었는데요.

 

약간 간단한 문장(?) 으로 표현해보자면

개발자에게 비즈니스는 객관식 문제집의 총집합 이라고 생각합니다

 

어떤 비즈니스를 제공하기 위해서는 다양한 것들을 고려해야 되는데요

• 어떤 기술 스택을 선택하여 적용할 것인지
• 비즈니스 로직을 작성할 때 어느 부분에 대해 확장성 포인트를 둘 것인지
• 각각의 모듈이 가지는 책임은 어떠한 것인지
• MSA 라면, 다른 외부 연동하는 서버의 역할과 우리가 가져가야할 역할은 무엇인지

너무 기술 스택에 취한 나머지 이것을 왜 적용해야되는지 명확한 이유가 없다면

추후에 유지보수할 때 많은 어려움을 겪고, 트러블 슈팅에 대한 어려움을 가질 수 있습니다.

 

예를 들어 리액티브를 적용하고 싶다면 왜 꼭 리액티브여야 하는가?

스스로에 대한 질문을 하고 스스로 납득이 되고 나서야 기술 스택을 선정하는 것이 좋을 것 같습니다.

 

확장성 포인트(OCP) 및 모듈이 가지는 책임(SRP) 은 사실 객체지향의 원칙과 유사하지만

이는 구조를 설계할 때도 똑같은 원칙을 적용할 수 있습니다

 

위에서 언급한 것들은 비즈니스를 구현상으로 어떻게 해결할 것인지에 대한 설명이었다면

비즈니스에 따라서 앞으로 어떤 역할을 가져가야할 것인지 정의하는 것이 더 중요합니다

Running

비즈니스는 단거리 달리기가 아니고 마라톤이라고 생각합니다

현재 비즈니스에 정신없어서 한순간의 앞만보고 코드를 작성하다가는 정말 버려지는 시스템이 될 수 있기 때문이에요

비즈니스는 현재를 보는 것도 중요하지만, 멀리 내다 보는 것도 중요합니다

큰 그림을 그리고 앞으로 나아가야할 방향성을 정하고 정한 방향성 대로 나아가야 굳건한 시스템을 만들 수 있습니다

 

여러분들도 개발자라면

크게 그려나가는 설계 능력을 통해 많은 서비스 이용자들에게 훌륭한 비즈니스를 만드셨으면 좋겠습니다

 

Kotlin

새롭게 배운 Kotlin

Kotlin 을 새롭게 배운 한해였는데요 

정말 농담안하고 이제는 Java 로 개발못하겠습니다 하하

 

코틀린에 대해서는 제가 정말 감명을 많이 받아서 많은 게시글들을 올렸었어요

https://huisam.tistory.com/entry/kotlin-collection?category=705896 

Kotlin Collection Util Method - 코틀린의 Collection Util 함수들을 파헤쳐보자

 

위 링크와 유사하게 Collection 기반으로 동작하는 asSequence 에 대한 성능도 궁금해서 찾아보고 그랬었네요.

대표적으로 Java8 stream 과 유사한 asSequence 의 performance에 대한 고찰도 했었어요 ㅎㅎ

https://typealias.com/guides/when-to-use-sequences/

When to Use Sequences

 

어쨌든 올해 코틀린에 대해 많은 것을 해보고 탐구해본 결과 Java 랑 비교했을 때 아래와 같은 장점들이 있었어요

• Java와 Kotlin에 대해 똑같은 코드를 작성해도 Kotlin 코드가 훨씬 더 간결하고 명확하다
• Java 에서는 자료구조 유틸들을 Guava 에 의존하는 경향이 있는데, Kotlin 은 유틸 function 이 많기 때문에 굳이 그럴 필요 없다.
• Nullable, Non-Null 에 대해 정확히 파악할 수 있다
• 직관적인 함수형 코드를 작성할 수 있다

저한테 있어서 코틀린의 제일 큰 장점은 바로 Nullable Non-Null 필드를 정의할 수 있는 것 입니다

Java 에서는 특정 필드가 Null 인지 아닌지 많이 등한시하고, NPE 를 맞는 경우가 비일비재했었는데요

 

Kotlin 을 경험하고 나서 NPE 에 대한 경험은 거의 없었습니다.

그만큼 어떤 필드가 어떻게 쓰이는지 정확하게 흐름을 파악할 수 있었죠

그러다보니 유지보수 하는 입장에서도 편리하고 특정 필드를 정의할 때 더 많은 고민을 하게 되는 것 같습니다.

 

Feign Client

외부와 통신하는 클라이언트를 Feign Client 로 했던 것은 정말 저한테는 혁신이었습니다.

Client 코드를 엄청 간결하게 작성할 수 있고, 생산성이 정말 뛰어났었습니다.

https://spring.io/projects/spring-cloud-openfeign

Spring Cloud OpenFeign

Spring Cloud 진영에서 제공하는 Client 인데 정말 너무나 좋습니다

 

Feign 이 제공하는 다양한 장점은 아래와 같습니다

• 실제 Client 구현체는 개발자가 선택할 수 있다. ( Apache Http client4, Apache Http client5, okhttp )
• 재시도 정책을 쉽게 정의할 수 있다
• 생산성이 빠르다. 

실제로 다소 난잡함이 많은 WebClient 를 쓰다가 넘어오게 되니 엄청난 효율을 뽐내고 있었습니다

 

이에 대해서도 올해는 제가 많은 게시글을 작성한 것 같네요 ㅎㅎ;

https://huisam.tistory.com/entry/feigntest?category=759193 

Spring Cloud Feign Testing - Feign Client를 테스트해보자

Spring Client 를 적용하는 아주 간단한 기초 방법에 대한 소개에 대한 글과

 

https://huisam.tistory.com/entry/apache-http-client5

[Kotlin/Feign] Apache Http Client5 에 대해 알아보자

Apache Http client 5 를 Spring Feign 에 적용하는 방법

 

여러분들도 Spring Feign 에 대해 많이 사용하면 좋겠네요 ㅎㅎ;

더 좋은 Client 가 나온다면 옮길 생각도 하고 있지만, 아직까지는 개인적으로 원톱이 아닌가 싶습니다

 

JPA

JPA

사실 장점을 나열하자면 정말 끝도 없는 기술스택입니다 ㅎㅎ;;

물론 known issue 로 알려진 버그도 많고 특정 기능이 동작도 안할 때도 있지만 생산성의 편리함 때문에 사용하고 있습니다

JPA 관련해서 제가 생각한 장점은 아래와 같습니다

• 엔티티 모델과 DB Schema 를 쉽게 Mapping 할 수 있다
• Fetch 전략과 Cascade 방식을 통해 어떻게 저장하고 어떻게 꺼내올 것인지 유연하게 대처할 수 있다
• JPQL 을 기반으로 엔티티 전체 조회가 아닌 통계를 위한 DTO 조회도 가능하다

하지만 편리한만큼 단점도 많으니..

• 제대로 사용할려면 알아야될 게 많습니다
• 특정 기능이 제대로 동작하지 않습니다. ex) FetchType.Eager

https://huisam.tistory.com/entry/persistContext?category=759193 

Spring Data JPA - 영속성 상태에 대해서

역시나 JPA 도 제가 다양한 게시글을 작성했었죠 ㅎㅎ

https://huisam.tistory.com/entry/routingDataSource?category=759193 

[JPA] DataSource 를 연결하는 방법 & RoutingDataSource 설정

물론 더 작성해야 될 것은 많습니다 

개인적으로 2022년에는 JPA 에 대한 습득 완성을 하는 것을 목표로 하고 있습니다

 

Vue3

저는 Backend 개발자 지만 프론트에 대한 개발 경험을 처음으로 하게 된 기술이었습니다.

Vue3 와 TypeScript

프론트에서 상태(state) 를 왜 관리해야 되는지

각각의 Component 는 어떻게 쪼개야하고, 어떻게 LifeCycle 을 가지고 있는지 등

 

프론트에 대한 배경지식이 하나도 없는 저에게는 학습할 때 많은 어려움이 있었지만,

하나씩 배워가는 재미로 했었던 것 같아요

https://v3.ko.vuejs.org/guide/introduction.html 

시작하기 | Vue.js

Vue 같은 경우에는 공식문서가 너무나 잘되어 있기 때문에, 공식문서를 참조하면서 공부하는 재미도 있었어요

 

제가 생각하는 Vue3 의 장점은 아래와 같습니다

• Component 간의 역할 분리와 state 를 통해 데이터의 상태관리를 가져갈 수 있다
• Composition API 를 통해서 Component 간의 View에 대한 책임을 분리하고 논리적 관계를 명시할 수 있다
• 백엔드 개발자가 다소 쉽게 입문할 수 있다(React 대비)

https://huisam.tistory.com/entry/vue3-composition?category=892848 

백엔드가 정리하는 Vue3 - Composition API

그래서 감명을 받아서 작성한 게시글도 있습니다 ㅎㅎ

 

정리하며

올해는 정말 많은 기술 스택을 배우고 많은 것을 경험했던 한해였습니다.

너무 많은 것을 경험한 나머지 디테일하게 파악하지 못하고 넘어갔던 부분들이 많았어요 ㅠㅠ

정신없게 비즈니스를 해야했기도 했고, 배워야 되는 기술스택은 정말 많았기 때문입니다.

 

그래서 2022년에는 새로 접했던 기술 스택들에 대해서 더 깊이 있게 배울 수 있도록 더 나아갈 생각입니다

 

앞으로 제 블로그 포스트 게시글들을 많이 기대해주세요 :) 

더 유용한 글과 깊이 있는 게시글로 찾아뵙도록 하겠습니다.