2023년 개발 회고

벌써 2024년 1월1일이 훌쩍 지난 중순이다
티스토리는 2021년에 만들었고, 벌써 3번째 회고글이다!
2022년도 중반에 내 개발자 커리어 ~ 2022.09까지의 첫번째 글을 썼고, 2023년 1월에 2021~2022년도의 두번째 회고글을 작성했었다
돌아보면 2023년 한 해는 정말 많은 발전이 있었다!!
찍먹을 지각에 비유해본다면,, 여러 영역들에 있어서 지각~맨틀 사이정도의 그 어딘가쯤 지식을 쌓았던 것 같다
(맨틀은 엄청 깊다(?))

https://blog.naver.com/tkdgmldn1456/221981656632

 
프론트엔드/데이터베이스/프로그래밍 언어/백엔드/아키텍처/Ops/기타(취미)에 대해서 느낀점, 배운 점을 작성을 해보려고 한다
 

- FrontEnd -

상반기에 이직을 해서 Vue를 최신 문법으로 접해봤다
남들은 React로 시작을 해서 쭉 쓰는데..
난 Angular로 시작해서 Vue를 사용하게 됐다(취준생때는 React를...)
React/Vue/Angular 3대장을 겪어본 결과를 잠깐 말해본다

> Angular(2022)
나는 스프링으로 시작을 해서 그런지 DI를 해서 사용하는 앵귤러가 구조적으로는 제일 깔끔해보였다
Angular는 AngularJS(Angular V1)시절 많은 미움을 받았던게 한국시장에서 점유율이 적은 가장 큰 이유같다.
Angular라고 명명된 Angular2(TypeScript)로 바뀌면서 정말 모든 툴을 갖춘 풀 세트로 나왔지만.. TypeScript의 강제성과 이미 등을 돌린 유저들이 React나 Vue로 넘어간 상황이었기 때문에 Angular1에서 마이그레이션을 하는 회사가 아니면 굳이..? 라는 느낌이 들었을 것 같다
Prototype기반인 JavaScript에 OOP를 녹여내서, 코드를 보면 역할별 분리가 되어 있어 초반 러닝커브만 지나면 정말 편한 도구인 것 같다(다만 RxJS와 TypeScript로 시작을 해야 한다는 것, 구글쪽 Angular UI가 이쁘지 않은 것 등등..이 신입분들한테는 어려울 것 같다)
또한 Angular는 굳이 상태관리를 위해 NgRx를 사용할 필요를 느끼지 못했다. 기본적으로 양방향 바인딩을 지원하고, RxJS 등으로 어느정도 커버가 되기때문이다
개인적으로 이번 Ang17버전이 너무 맘에 들고, 빨리 LTS버전으로 되었으면 좋겠다!!
 
> Vue(2023)
프론트를 처음 접하거나, 자바스크립트 입문자면 나름 쉽게 적용할 수 있을 것 같았다
Vue의 Release가 가장 마지막에 나온 결과로 React + Angular 같은 느낌을 받았다
VueJS의 창시자인 Evan You는 Google에서 AngularJS로 개발을 하다가 좀 더 개선된 프론트엔드 라이브러리/프레임워크를 만들고자 VueJS를 만들었기 때문에 Vue는 Angular를 닮아있다. 그리고 Evan You는 Vue가 React를 많이 닮아있다고 직접 말하기도 했다
상태관리로는 Vuex보다는 Pinia를 더 많이 사용하는 것 같고, 지금 회사도 그렇다.
다만 Vue를 처음 접했을 때, Vue2와 Vue3의 차이. Composition API vs Options API, script setup, js/ts 등등
구글에 검색을 하면 너무 다양한 버전의 결과물들이 나와서 처음에 공부하기 가장 싫고 어려웠다..; 오히려 앵귤러보다 더..!!
다행히 현재 회사가 최신 문법으로 Vue3 + Composition API + script setup + Composable + Pinia를 사용하고 있어서 많은 것을 배우고 적용했다
Vue에서는 ref로 객체또는 값을 반응형으로 만들어주지 않으면, v-model을 사용한 양방향 바인딩을 지원하지 않는다는 점이 Angular랑 달랐다. 또한 Pinia를 이용한 상태관리가 편하게 느껴졌다
 
> React
React는 간단하게만 써봤는데, 개인적으로는 너무 사용할 수 있는 도구들이 많아서 어려운 것 같다
상태관리만 하더라도 Redux, React Query, Context API, MobX, SWR, Recoil..... 등등 너무 복잡하다
단방향 바인딩이라 신경써줘야 할 것도 많고, 사용할 수 있는 방법들도 너무 다양하고, JS 또는 TS를 사용하는지, Redux 등을 사용하는지에 따라서 조직 레벨이 달라지기 때문에(사실 이 부분은 Vue랑 좀 비슷한 부분이 있다) 너무 다양한 테크 스펙트럼이 존재해서 선택하기 어려웠다
약간 한국에서 자바민국(?)이란 소리가 있는 것처럼... 한국에서는 프론트엔드 프레임워크로는 React가 점유율은 1위이다
개인적으로 Next Career에서는 React를 쓰는 곳을 경험해보고 싶다
 
=> Summary
회사에서 각각 1년정도 구식버전과 JS가 아닌, 최신버전과 TS로 익혀본 짧은 소감을 적어봤다
프론트엔드는 진짜 간단하고 빠르게 구현을 할 수 있을 것만 같아도 막상 컴포넌트끼리 state(데이터)를 주고받다보면 마음처럼 안되는 경향이 있는 것 같다
그리고 같은 문제에 대한 해결책이 여러가지가 있는게 흥미로운 사실이다
[ watch(vue)/useeffect(react)로 감지해서 이벤트 emit하는 방법, 이벤트 버스, 상태값 업데이트해서 get해서 쓰기 등등 ]
 

- Database -

> MySQL(2021)
첫 직장에서 MySQL + Mybatis + JPA를 사용했다. 정부관련 프로젝트를 하는 테이블 스키마는 정말 복잡했고, Mybatis를 사용해서 쌩쿼리를 날려서 Map또는 Entity로 조회를 하거나 간단한 쿼리는 JPA를 사용했다
이 때 RealMySQL 8.0 1/2권을 정독했었고, SQLP를 취득하고 싶다는 작은 목표가 생겼다
 
> MongoDB(2022)
두번째 직장에서는 MongoDB를 사용했다
흔히 MERN stack(MongoDB, Express, React, Node)이라고 불리는 기술스택에서 MongoDB - Document Oriented, NoSQL(Not-Only SQL)를 말한다
취준생때 아주 간단하게 써본 MongoDB는 현업에서 어떻게 쓰이는지 개인적으로 궁금했다
mongos/mongod 사용법, Mongo Compass(Tool) 사용법, MongoDB의 꽃인 aggregation등등
그리고 최종적으로 Spring Data MongoDB와 Mongo Template을 써서 기능을 개발했다
Mongo Compass로 Aggregation Stage들을 작업하고, Spring으로 구현했다
InnoDB/MyISAM 스토리지 엔진을 사용하는 MySQL과 다르게 WiredTiger 스토리지 엔진에 대해서 조금 공부했었다
서울에서 열린 MongoDB Conf도 가보고, MongoDB Compass의 UI 중 버그나 불편한 점을 발견해서 이메일을 보내서 근시일 내에 업데이트본을 받아본 적도 있었다
Springboot에서 사용할 때, Hibernate 구현체를 사용한 JPA+MySQL만큼의 호환성은 아니었지만 MongoDB와 Spring Data를 활용한 경험은 신선했고, 유익한 경험이었다
 
> PostgreSQL(2023)
현재 회사에서 사용하고 있는 DBMS이며, MySQL과 유사하지만 비정형데이터도 담을 수 있는 ORDB(Object-Relational DataBase)이다
여러 플러그인들을 설치해서 사용할 수 있으며, json또는 jsonb가 들어가면 ->로 접근하는 등 MySQL과 비슷하면서 다른 부분이 있지만.. 기타 BaaS 오픈소스에서 채택하고 있는 인기있는 DB이다
무료툴로는 pgAdmin이 있지만.. 나는 intelliJ또는 DataGrip에 연결해서 쓰고 있다
MySQL처럼 쿼리질의문으로 CRUD를 다 할 수 있기 때문에 익숙하다. 다만 Spring + JPA와 관련해서 찾아보면 MySQL보다는 자료가 좀 부실하긴 하다
이번에 BaaS로 핫한 Supabase에서 내장DB로 PostgreSQL을 사용하고 있을 정도로 오픈소스의 핫디비인것 같다..
 
=> Summary
여러 DB를 경험해보고 각각의 매력을 느꼈다
정말 복잡한 3~4 Join, Group, Aggregation등을 하라고 하면 뚝딱 나오지는 못하겠지만 왜 그렇게 복잡하게 조회해야 되는지 설계부터 의심할 것 같다
그리고 이제 주니어~중니어로서 Index를 걸어야 하는것, 어떻게 걸어야 하는지 이정도는 기본소양인 것 같고.. Database엔진을 좀 더 공부한다던지 샤딩/파티셔닝/레플리카/레플리케이션/클러스터링/보안 등에 대해서도 알아야 할 레벨이 된 것 같다고 느낀다
 

- Programming Languages -

> JavaScript / TypeScript
Angular를 쓰면서 Typescript를 처음 접했고, 점점 더 잘 쓰게 된 것 같다. 기존에 JS를 쓸 때는 ES6에 집중해서 코드를 짰다면, 이번 직장에서 Vue3 + TS를 쓰며 어떻게 하면 js/ts를 좀 더 잘 쓸까 고민하게 되었다
any사용을 지양하거나 사용하지 못하도록 하며, unknown을 사용하고 type-guard를 한다던지.. Partial, Required, Readonly, Pick, Omit 등을 활용한다던지, 누적이 필요하면 c/java style code보다는 reduce를 쓰는 습관을 들이려고 했다
그리고 아래에 말하겠지만, nest를 쓰면서, backend와 frontend 에서의 Typescript 사용이 조금 다르다고 느꼈다
백엔드에서는 제네릭을 좀 더 쓰는 느낌이 들었고, 프론트에서는 interface나 type을 주로 쓰고, enum보다는 map을 활용하는 쪽으로 했다
프로젝트를 Javascript로 해본적은 없지만, 최근 Plotly로 그래프를 그리면서 공식문서와 index.d.ts의 내용이 다른 것을 봤고, issue로 등록 했었다
Javascript로 간다면 최소한 JSDoc을 붙이거나, Typescript를 쓰는게 더 좋아보인다.
큰 프로젝트를 다루게 되고 자기가 통제할 수 없는 부분이 생기면 javascript는 설명서 없이 조립을 하는 것과 다를게 없다고 느낀다
다만, eslint + prettier를 활성화하면 map, filter, reduce를 쓸 때 타입을 명시해야되서 그건 좀 싫었다
 
> Java
Backend쪽에 또 명시하겠지만, Spring Cloud Gateway를 Reactive로 만들면서 자바를 또 쓰게 되었다
자바21이 나오면서 가상스레드가 핫해졌지만, Dart/Go/Kotlin 등의 언어를 접한 뒤라서 자바라는 언어가 나한테 흥미를 잃게 된 것 같다
하지만 WebFlux나 Multi Thread, Parallel Processing, WebClient등을 대기업수준으로 사용한 적은 없었다
그래서 Spring Cloud Gateway에서 Netty(non blocking I/O)+WebFlux+Reactive Java(Project Reactor)를 써서 mutate로 요청을 빼서 chain filter를 갈아끼우는 걸 해보면서 다른 방식으로 자바를 사용한 경험을 얻었다
그리고 K-Streams(Kafka Stream)를 써서 데이터 파이프라인을 서브로 구현해보면서 Windowing/Peek/Reduce을 쓰는 것을 배웠다. 예전 취준생시절 프로젝트 할 때 Stream API를 썼던 생각이 나서 추억이 돋았다
다시 써본 자바는 견고한 언어라고 느꼈다. 파이썬에서는 GIL(Global Interpreter Lock) 때문에 멀티스레드가 비적합한 것과 반해 자바는 다양한 해결법이 있기 때문이다

> Kotlin
프로젝트를 진행하다가 backend 프레임워크를 셋업할 필요가 있었다. 현 회사에서 백엔드 프레임워크가 명확히 지정되어 있지 않았기 때문에 코프링(코틀린 스프링)을 써보려는 목적으로 코틀린을 배우고, 회사 프로젝트에 적용해봤다
named parameter때문에 인자에 값을 명확하게 넘길 수 있고, 쓸데없는 빌더패턴을 사용하지 않아도 되는게 좋았다. 또한 롬복을 사용하지 않았다
js의 구조분해할당처럼 필요한 변수를 뽑아서 쓸 수 있다는 점도 신기했다
가장 좋았던건 문자열 보간이 간단한게 좋았다. 자바스크립트는 백팃을, 파이썬은 f-string등을 써야 했지만.. $ 기호 하나만으로 되는게 편했다
elvis 연산자와 ?: 처리, apply/takeIf 등등 null safe한 문법이 너무 맘에 들었다!
또한 간단한 코루틴과 suspend의 작동 원리를 배워가며 사용했다
하나의 파일에 class가 없어도 되서 유틸성 파일을 만들 수 있기 때문에 매우 좋았고, 내가 좋아하는 제품의 회사인(편애아냐..?) JetBrains에서 오랜 베타 기간을 거쳐 나온 실용화를 목적에 둔 언어이기 때문에 사용경험이 정말 좋았다
2024년에는 Effective kotlin/Kotlin in action 책을 정독할 예정이고, 코루틴을 좀 더 배워볼 것 같고 Ktor도 심심하면 만들어볼 것 같다

사이드 프로젝트

 
> Dart
Etc에 들어가야 할 것 같긴 한데...ㅎㅎ
2023년 상반기에 취미로 플러터를 배우기 위해 다트를 공부했었다
Kotlin Spring을 프로젝트로 만드는 시점에 Dart를 공부했었는데, Dart는 내가 느끼기로 약간 TypeScript와 Kotlin의 짬뽕? 느낌이 들었다
Kotlin은 안드로이용이 아닌 서버용으로 사용했다면, Dart는 앱 개발을 하기 위해 썼다
lazy, lenient 등이 있다는게 신기했다
노마드 코더에서 클론코딩으로 배웠던 언어라 그런지 아직 완벽하게 내것이 아니다

지금은 잠깐 쉬고있지만... Dart도 다른 언어들처럼 우아하게 사용해보고 싶은 욕심이 있다
 
> Go
위에 Dart에 올렸지만, 노마드 코더에서 Golang을 접했었고, 유데미에서도 강의를 결제해서 보는 중이다
사이드 프로젝트를 하면서 Golang의 매력에 빠졌고, 병렬처리에 강점을 가진 언어라는 것을 배웠다

문법이 그동안 봐왔던 기타 언어와는 조금 달랐다
나는 중학생 때 처음으로 C언어를 배웠고, 2010년도에 대학생 때 2번째로 시작을 했었다
그 당시 보던 포인터와 구조체를 golang에서 봐서 반가웠다
make로 채널을 만들고, 채널로 통신을 주고받고.. python처럼 강력한 기본 내장 패키지 지원 라이브러리 함수들과 접근제한자가 굳이 필요없는 명시적인 export(대문자 함수 이름), defer정리 로직 등등
느슨한 결합의 대명사 docker, k8s는 go 언어로 만들어졌다
메모리를 잘 사용하고 프로그래머의 실수를 방지하기 위해서 포인터 사용을 막는 Java보다는 포인터 접근을 허용하고, 산술을 막은 Golang이 리소스 관리면에서 좀 더 유연하면서 발전된 언어라고 느꼈다
그리고 Docker를 공부하면서 Linux에 대해서 더 공부할 필요가 있다고 느꼈고, Linux와 동시에 Golang에 대한 궁금증이 생겨서 써보게 됐다
24년 가장 맘에 드는 언어는 kotlin, go 2개이다..!! 앞으로 꾸준히 배우고 사용할 것이다

사이드 프로젝트

> C#
취미로 유니티를 하기 위해 공부를 시작했다
닷넷.. 그렇게 친하지 않은 영역이다
그거 아는가? OOP라는 패러다임에서 볼때 C++과 Java가 유사한 것 같지만, C#은 Java와 유사한 언어이다
예전에 LG그램 노트북을 사용할때 심심풀이로 아주 간단하게 Winform을 써서 필요한 윈도우 프로그램을 만들곤 했는데, 2023년에 다시 만나게 될 줄은 몰랐다
아! 그리고 대학생 시절도 C# 수업에서 C#을 배우고 유니티를 활용해봤었다
현재는 Arm Mac을 사용하기 때문에 homebrew로 mono를 설치해서 간단하게 cs파일을 컴파일하고 실행해본다던지, Rider 제품을 사용해서 C#을 공부하고 배우고 있다
취준생시절 C#전문가와 Java전문가에 대해 비교한 것을 들어서 C# 또는 닷넷 전문가로 시작을 하지는 않았지만.. 유니티를 하고, 코루틴을 다뤄보고, 현재의 컴파일 최신 버전으로 사용하다보니까 완성도가 높은 언어라는 것이 느껴졌다
하지만.. For Unity를 위해서 C#을 배우고, For Unreal을 위해서 C++을 배우는 것 이상 이하로 깊게 팔 생각은 없는 언어이긴하다..ㅎ
 
=> Summary
2023년에 정말 많은 언어들을 복습하거나 배웠다. 몇몇 회사를 다녀보며 만난 사람들 중 몇몇사람은 이런 특징이 있었다
Java는 호/JavaScript는 불호, 반대로 JavaScript는 호/Java는 불호한다던지
단순히 컴파일 언어 또는 강타입 언어를 싫어한다던지 등등..
컴파일언어와 달리 인터프리터도 다른 버전에 따라서 코드 해석이 달라지고, 런타임에서만 오류를 잡을 수 있는 단점도 있고..한데 말이다
컴파일 언어도 목적 파일이 만들어기 전 컴파일 레벨에서 코드 오류를 방지할 수 있지만, 컴파일 타임이 생기기도 하고 JVM의 경우 처음 떴을때는 느리게 작동한다던지 등등 장단점이 있고..
이 두 방식은 다르고 서로 장/단점 및 특징을 가진 것일 뿐, 서로의 진영을 이해 못하고 싫어할 이유는 없는 것 같다
나의 이 모든 언어를 경험해 보고싶은 마음과 언어 선택에 불호가 딱히 없는 내 모습을 보고는 회사 동료는 내가 특이한 거라고 한다
그리고 다양한 언어를 경험해보면서 느낀 점은..!! 진짜 다 버전이 올라갈수록 비슷비슷해지려고 한다는 것을 느낀다
Effective/Modern/Action 이 적혀있는 서적을 읽고, 선배 개발자들의 Best Practice를 찾아보고 Side Project로 적용하는 그 순간이 "이 언어를 해봤다" 라고 말할 수 있는 수준인 것 같다
나도 여러 언어들을 정말 기초만 해본 정도라고 생각한다. 내 주 분야는 Web쪽 Back/Front/Infra지만, 주로 사용하지 않는 것에 대한 차별없이 모든 언어와 개발들을 사랑하고 싶다
 

- Backend -

> Spring
위에 Kotlin과 관련해서 회사에서 들어와서 내가 메인으로 한 프로젝트를 Kotlin Spring boot(3.1.0)으로 만들면서 다시 또 스프링에 대한 복습을 했다
MySQL이 아닌 Postgresql와 JPA. 그것도 Kotlin에 적용해본 경험이 매우 신선했다
Long Id가 아닌, UUID - generate_uuid_v4()를 사용하는 UUID를 key로 적용해봤고, 이것 때문에 UUID List 등을 담기 위해 컨버터도 붙여보고, 당연히 EntityListner를 통해 logging처리도 했었다
그리고 개인 프로젝트로 MongoDB를 Kotlin Spring과 엮어서 JPA사용을 data class로 사용을 해봤다. 이건 정말 찰떡이라고 생각했다
Optional을 굳이 사용할 필요가 없는 코프링+JPA에서는 잘 wrapping된 findByIdOrNull로 엮어서 처리를 하거나 findById().orElseThrow { CustomException(ErrCode) }로 처리를 했다
Around에 Continuation을 넘겨서 suspend fun에서도 AOP를 적용해서 임의의 인증처리를 구현했다(Spring Security)

@Around(
    """
        @annotation(io.swagger.v3.oas.annotations.Operation) &&
         args(.., kotlin.coroutines.Continuation)
    """
)

그리고 protobuf, parquet 등의 데이터를 처리하고 파싱해서 응답해주는 작업도 해봤다
Java쪽에 적어놨지만, Spring Cloud Gateway를 구현해보면서 Spring을 다시 사용해서 반가웠고, 잘 만들어진 프레임워크라고 느꼈다

> Nest
회사에서 백엔드를 선택함에 있어서 Nest를 사용하자고 했어서 나도 그에 따라 개발을 참여하게 되었다
Spring으로 취업문을 시작해서 그런가, Nest는 Spring을 닮아 있다고 느꼈다
다만 모듈 방식으로 만들 수 있다는 점, 언어가 TypeScript라는 것이 달랐지만 말이다
Node.js에서 process.env로 env파일을 어떠한 처리 없이 가져오는 것과 다르게 ConfigService라는 것을 활용해서 값이 없다면 예외를 발생시키고 타입체크까지 하는 것이 첫 도입을 함에 있어서 좋았다

 app.connectMicroservice({
    transport: Transport.KAFKA,
    ...
	}
)

KafkaJS를 붙여서 microService로 만들어서 사용중이다
스프링에서만 겪어볼 줄 알았던 순환참조 오류도 Nest에서 겪어보니 의외로 반가웠다(?)
또한 API를 호출 할 때 nest 공식문서에서 나와있는 rxjs를 활용해서 리액티브 데이터를 처리했는데 재밌는 방법이었다
같은 언어를 다른 방법으로 사용해서 개발한다는 것은 내가 모르는 영역을 공부하는 거라고 느끼고, 매번 신나하는 것 같다

async auth(): Promise<XXResponse> {
  const id = this.configService.getOrThrow<string>('ID')
  const pw = this.configService.getOrThrow<string>('PW')
  const { data } = await firstValueFrom(
    this.httpService
      .post('/api/auth/login', {
        id,
        pw,
      })
      .pipe(
        catchError((error: AxiosError) => {
          this.logger.error(error)
        })
      )
  )
  this.logger.debug('Login Success')
  return data
}

메인 프로젝트를 시작한다면 Kotlin Spring으로 만들것 같지만, 인프랩에서 향로님이 23년 초에 Nest를 랠릿 프레임워크로 적용해본 이유를 조금이나마 느꼈달까..
그리고 몇몇 회사에서 프론트엔드 개발은 있는 상황에서(js/ts), 굳이 Java/Kotlin 백엔드 개발자를 채용하기에는 부담스럽거나 어려운 경우 선택할 수 있는 좋은 옵션이라고 느꼈다

> FastApi
이 프레임워크는 딥하게 사용해보지는 않았다
PyCharm Professional Edition으로 새 프로젝트를 만들 때 선택할 수 있는 백엔드 옵션에는 3가지가 있었다

Django는 "모든 것이 준비된" 접근 방식을 취하는 프레임워크로, 많은 표준 기능을 제공
Flask는 필요한 것만 선택하여 사용하는 "최소주의" 접근 방식을 취하는 프레임워크
FastAPI는 고성능, 비동기 처리, 자동 API 문서화 등을 지원하는 "API 웹" 프레임워크
라고 chat에서 말하기에, 개인적으로 궁금했던 FastAPI를 선택해서 공부해봤다
프로젝트를 실행하고 처음으로 당황했던 것은...ㅋㅋ
로그의 색상이었다
나는 호스트 주소를 제외한 부분이 빨간색으로 나오기에 오류가 발생한 줄 알았지만, 아니었다.. ㅡ_ㅡ;;

걍 잘 작동한 것이었다 --;
그리고 기본 포트는 8000번으로 작동한다
또한 가장 맘에 들었던 부분은 /docs로 들어가면 swagger-ui를 자동으로 만들어준다는 것이다

와.. 스프링에서 이거 하려면 Swagger-ui 의존성 추가하고...@Configuration을 구현하고 2.x, 3.x대 버전 차이, 코틀린에서 적용 어려움 등등
반나절 혹은 하루 이상 스웨거 붙이는데 애쓰는 일이 허다한데, api docs 자동생성이 맘에 들었다
그리고 백엔드 언어가 python이기 때문에 좋은 점?
파이썬 언어로 구현되어 있는 AI 모델을 사용해서 바로 서빙이 가능하다는 점이다

그리고 매번 썼던 venv(.venv) 대신 Poetry로 의존모듈을 관리해보기로 했다 - No more requirements.txt
아직 메인 프로젝트로 깊게 개발해본 적은 없지만, 파이썬 언어로 시작하기엔 매우 매력적인 프레임워크처럼 느껴졌다

> Gin / Echo
Go 언어를 기반으로 한 프레임워크이다
니콜라스 강의에서는 echo를 사용했고, 개인적으로는 Gin을 사용해봤다
사실 golang은 파이썬만큼 기본패키지에 다양한 기능들이 구현되어 있기 때문에 굳이 웹 프레임워크까지 필요가 없다고 한다
하지만 무엇이든 경험해봐야 직성이 풀리는 나라서... 그냥 둘다 겪어봤다
GitHub기준 좀 더 사용량이 많은 것은 Gin이다
현재는 go와 golang에 기반한 서비스 혹은 프레임워크를 공부중에 있다
여러 모듈/워크스페이스로 구분하고, export Func들을 import해와서 main 패키지에서 불러서 쓰고 있다

import (
	"backend/custom-error"
	"backend/v1"
	"fmt"
	"github.com/gin-contrib/cors"
	"github.com/gin-gonic/gin"
	"net/http"
)

func main() {
	fmt.Println("Server Starting")
	r := gin.Default()
	r.Use(cors.Default())
	r.Use(custom_error.ErrorHandlingMiddleware())
	v1 := r.Group("/v1")
	{
		scrapGroup := v1.Group("/api")
		scrapGroup.GET("/", v1.GetHome)
		scrapGroup.GET("/news", v1.GetNews)
	}

	r.GET("/ping", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{
			"message": "pong",
		})
	})

	r.Run(":10002")
}

뭐 대충 이렇게 main이 구현된 프레임워크다(코드는 조금 수정)
여러 미들웨어를 붙이고, api들을 그룹화해서 구현할 수 있다

> API(HTTP, gRPC, graphQL)
기존에는 web 데이터를 받는 통신 방식에서 REST HTTP만 써봤다
하지만 HTTP에 REST/SOAP가 있는 것을 알게 됐고, gRPC 통신, API 런타임 graphQL 등을 사용할 수 있다는 것을 알았다
websocket이야 뭐.. ws, WebSocket, Socket.io(Nest), STOMP/SockJS(Spring), Kafka 등을 활용할 수 있다는 것을 알고 있긴 했다
목적에 따라서 다양한 방법으로 request, response를 할 수 있다는 점이 신기했고, 요구사항이 생기고 시간이 남는다면 공부해보려고 한다
 
> BaaS - Low code / No code
BasS란 Backend As A service의 abbreviation(준말)이다
pocketbase, appsmith, appwrite, n8n, supabase 등을 사용해봤는데..
화면은 개발을 할 수 밖에 없고, 빠른 백엔드 개발을 위해서 선택할 수 있는 백엔드서비스를 말한다
처음에 백엔드 코드 없이 어떻게 서비스를 만들지?했었는데 지금은 어느정도 적응했다!
현재는 Supabase를 주로 쓰고 있고, 상태관리 DB와 rest api로 사용중이다
나는 Firebase를 사용하지는 않아봤는데, Supabase가 Firebase의 상위호환이라는 말을 들었다
나는 직접 Kotlin에서 Supabase SDK를 연동해서 개발했고, Spring cloud gateway에서 supabase 서비스를 mapping해서 api를 추상화해보기도 했다
Low/No Code라는건 백엔드 서비스가 간단할 때 이야기고, 조금이라도 커지면 백엔드 서버가 필요하다는게 내 개인적인 생각이다
 
=> Summary
백엔드 프레임워크를 몇 개 해보고, Low/No Code도 써보고, BaaS(Supabase)를 사용하거나 하는 다양한 방법으로 써봤다
아무래도 난 옛날사람이라 그런지, 백엔드 서버가 있어야.. request(입력값)에 대한 validation처리도 하고, 데이터를 transform하면서
엔티티 전체가 아닌 필요한 것만 response하기 위해 백엔드 프레임워크 서버는 있어야 한다고 생각한다
 

- Architecture -

> Event Driven
그동안 전통적인 monolithic의 웹앱 서비스만 다뤄보았다면, Kafka를 통해서 여러 서버들을 도메인에 맞게 나누고, 느슨하게 결합시킬 수 있게 됐다
이벤트로 보내는 메시지는 id값이 포함되도록 했고, 조회/업데이트 시점차이와 validation 처리 등이 중요하다는 것을 알게됐다
그리고 아직 CQRS로 요청을 나누는건 적용하지 않았다
단순히 모놀리식이 싫어서 카프카 하나 붙이고 이벤트로 백엔드 처리했음ㅋ 라는 식의 개발은 위험한 사고라고 생각하고, 나는 이렇게 사고하지도 않는다
개인적으로 DDD(도메인 주도 설계)를 공부하고 좀 더 다양한 아키텍처들의 특/장/단점을 배워야 한다고 생각한다

> Api Gateway
기업에서 제공하는 서비스들을 사용하게되면 Open API 또는 SDK를 언어별로 제공하는데, 기본적으로 curl을 보낼 수 있는 path가 있다
이 경로로 mapping만 해주고 restful하게 api를 구현한다면 굳이 API 서버를 따로 개발하지 않고도 백엔드 구성이 가능한 것이다
나는 기존에 회사에서 tyk.io라는 오픈소스 API Gateway를 사용했었다
yaml파일로 구성되어 k8s 환경과 적합하게 apidefinition으로 사용했다
하지만 2023년 하반기에 k8s gateway api가 새로 GA로 올라오면서, k8s환경에서 api gateway를 지원하는 목록중에서 tyk는 kong 등 다른것들에 비해서 느리게 지원을 한다는 것이다
그래서 롱런하고 있고, 앞으로도 계속 러닝상태일 것 같은 Spring Cloud Gateway를 배우고 적용했다
글로벌 설정은 yaml로 명시하고, 각각 라우트마다 java파일을 만들었다
path regex/rewrite, method, body transform, filter, add global header, authentication, ws 등을 직접 구현했다
weight를 줘서 간단한 lb기능을 한다던지, 특정 시간대만 route가 작동되게 한다던지 등등 괜찮은 기능들이 많았다
계속 고도화를 해가면서 공부를 할 예정이다
 
> Kafka
이번에 카프카를 사용하게 되면서 공부를 했다
고승범님의 "실전 카프카 개발부터 운영까지"라는 책으로 카프카에 대해서 스터디를 하고 n회차 발표도 했다
어떻게 메시지는 순서를 보장하는지, 대량의 데이터를 어떻게 빠르게 처리하는지, 왜 고성능 고가용성이라는 타이틀을 가지게 되었는지, 사용하는데 있어서 적절한 브로커/주키퍼의 개수가 있는지 등등 여러가지에 대해서 공부했다
cli로 사용하는 방법, 도커로 올려서 사용하는 방법, kafka-ui까지 올려서 여러 방법으로 공부했다
카프카를 잘 활용하기 위해서 schema registry, KStreams, KSQL, MirrorMaker, 모니터링(프로메테우스&그라파나)을 추가로 사용할 수 있다
Database도 고수준에서 파티셔닝, Lock, 동시성 제어 등을 알고 다뤄야 하는 것처럼, 카프카도 더 잘 쓰기 위해서 쭈욱 공부할 것이다!
 
=> Summary
2023년에 아키텍처..?라고 해야되나... 스프링 서버 1개가 아니라, 여러 서버를 목적에 맞게 가볍게 만들고, 그 사이를 느슨하게 결합해주는 것들을 적용하면서 공부하다 보니까 아키텍처에도 관심을 가지게 되었다
아키텍처란, 소프트웨어가 전체적으로 잘 굴러가도록 소프트웨어 전체를 설계하고, 그림 그리는 role을 가진 포지션이라고 생각한다
자바를 공부하면서 디자인 패턴을 배웠다면, 이제는 요구사항에 맞는 아키텍처 패턴들도 알아야 하는 때이지 않나 생각한다
거대기업들의 시스템 설계를 보면서 나도 내 지식을 야금야금 늘려야겠다!
https://learn.microsoft.com/ko-kr/azure/architecture/browse/
https://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3

 

- Ops -

> Linux
신입때는 리눅스를 그렇게 사용할 일이 많지 않았다(Spring과 java공부만 했던 시절이라..)
근데 jar파일을 실행시키고 오류를 잡으려고 하니깐 tail이란 명령어도 알게 됐고, 도커를 공부하다 보니 VM을 공부하게 됐고, VM을 공부하다 보니 리눅스를 공부하게 됐다
15년도 대학생 때 ubuntu 수업을 들으며 tree, find, grep 등을 조합해서 파일 탐색기를 만들고, 2p 오델로 게임을 만들었던 기억이 새록새록 나기도 하고...
잡설하고, 리눅스를 공부해야 하는 이유는 너무나 다양하다
super(root) 권한을 가진 계정을 털려서 한 기업의 몇백~몇조원의 가치를 해커한테 줘야 할 수도 있다
또한 docker -p 는 iptables로 비슷하게 구현이 가능하다
정말.. 쿠버네티스를 공부하려고 하니까 도커 지식이 필요하고, 도커를 공부하려고 보니깐 리눅스 지식이 필요했다. 그리고 리눅스를 공부하려고 하다보니깐 OS지식이 필요하고..
결국 견고한 CS지식이 있어야 한다고 느꼈다
curl, jq, make 등을 활용해 쉘스크립트 자동화를 간단하게 만들어 보고, top/btop/htop등을 사용해서 리소스 모니터링도 해봤다
정말.. 리눅스는 공부하면 할수록 매력적이고, 배포를 해서 서비스를 돌리기 위한 시작점이기 때문에 꼭 필수로 공부해야 하는 것 같다
 
> Docker
2023년도에 도커를 진심으로 공부했다
시작하세요! 도커/쿠버네티스, 컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 책을 필요한 부분을 읽었고, Dockerfile, docker-compose.yaml 파일을 작성하고, 이미지를 빌드하고 배포하는 과정 등을 공부했다
처음 신입때는 실 서비스중인 prod 서버에 들어가서 패키지를 업데이트하고, 방화벽을 올리고 서버를 작동시키는 등 그런 Role이 주어지지 않아서 도커를 왜 써야하고, 어디가 좋은지에 대해서 잘 몰랐다
주니어를 지나고 있는 지금 도커는 필수라고 느끼게 됐다
프로그래밍 언어처럼 엄청 빠르게 개발되고 있지는 않아서 CS지식만 충분하다면 업데이트속도를 캐치업할 수 있을 것 같다고 생각한다

> Cloud
2023년 하반기에 AWS, GCP, Azure 인스턴스를 만들어보고 테스트해봤다
각각 인스턴스를 만들어본 결과 부르는 이름이 다르고, 접속하는 console의 차이점, base OS종류 등이 다르다는 것을 알게 됐다
2024년 기준 아마존에서는 Amazon Linux를 밀고, 구글에서는 Debian GNU/Linux 11 (bullseye)계열, 마소에서는 Ubuntu 20.04 LTS가 기본 OS 버전으로 잡혔다
클라우드 서비스만 다 잘 사용할 줄 알고, 비용절감만 해도 회사에서 놓칠 수 없는 인재가 되는건 부정할 수 없는 사실이고 그게 실력이다
나도 AWS를 메인으로, GCP쪽도 더 잘 사용하도록 노력해야겠다

> Logging / Monitoring
보통 Backend layer에서의 Logging/Monitoring이라 한다면, 그라파타&프로메테우스를 기대할 것이다
나는 프론트엔드에서의 로킹 툴을 적용해봤다
Sentry, LogRocket, Rollbar 총 3개를 사용해서 PoC를 했고 각각 장단점과 라이센스 비용 등을 분석하고 프론트엔드에 적용했다
이것을 적용한 이후에, 프론트엔드에서의 런타임에러도 메일/슬랙으로 와서 잘 적용했다고 느꼈다
그리고 중요도로 보면 데이터처리, 즉 백엔드의 로깅 또는 모니터링이 더 중요한건 맞지만, 프론트엔드쪽도 사용자가 어떤 시나리오를 통해 이런 오류를 경험했는지, 어떤 데이터 때문에 이런 에러가 발생했는지 등등 알 필요가 있다고 느꼈다
 
=> Summary
2023년에는 Ops쪽에 대해서 내가 겪어야 했던 것들이나, 필요로 한 것들만 배웠다
Ops도 사실 DevOps/DataOps/MLOps 등등 다양한 포지션이 존재한다
2024년 올해 상반기는 리눅스를 좀 더 공부하고, CI/CD쪽과 관련된 자동화에 대해 공부하고, 하반기에는 로깅/모니터링에 대해 공부해보려고 한다
 

- Etc/Goal -

> JetBrains
2023년 하반기에 개인 카드로 JetBrains의 모든 제품을 사용할 수 있는 All Product Pack을 구매했다

맨 처음에는 IntelliJ로만 충분히 만족했었는데, 다른 언어와 프레임워크를 그에 맞는 프로그램으로 써보고 싶다는 욕심이 생겼다
사비로 구매한 이유는, 1년치를 구독하면 매년마다 조금씩 가격이 낮아지기 때문이다

goland, clion nova, rider 등이 내가 새로 개발을 하는데 써본 툴이고, 매우 편하다고 느꼈다

어쩌다보니 AI Assistant도 구매하게 되었다(위에는 학생때 썼던 학생 라이센스이다)
이 AI는 약간 돈을 버린다고 생각하지만 AI의 스펙과 아웃풋이 궁금해서 결제했다
chatGPT가 좀 더 정확한 답변을 내주지만, 개발 툴 안에서 좀 더 빠르고 관련성 있는 질문이 가능하다고 느꼈다(UI Menu)
또한 vscode를 대체하는 것 같은? fleet도 사용해봤는데, 실행환경을 json으로 구축하더라
그리고 Smart mode라는게 있었고다. smart mode를 disable하면 텍스트 에디터, enable하면 IDE가 되는게 신기했다
 
> Flutter

이 사진처럼 플러터로 클론코딩하면서 찍먹해봤다
앱과 관련해서는 학부시절 안드로이드 수업만 이론/실습으로 들어본 게 전부이다
플러터는 Dart라는 언어를 사용하기 때문에 회사차원에서 개발자를 고용하기도 어렵고(ReactNative는 React개발자들을 조금 전향시켜서 쓸 수 있음)
프로젝트의 규모가 커지거나 커스텀이 들어가야 한다면 네이티브(Kotlin, Swift) 앱으로 돌린다고 들었다
나도 플러터는 취미정도로 해볼 것이고, 좋았던 점은 한번 작성해놓고 빌드 타겟만 바꾸면 안드로이드와 아이폰에서 둘 다 똑같이 실행되는게 너무 신기한 경험이었다
 
> Unity

유니티는 콜로소에서 강의를 결제해서 공부를 했다
VSCode 대신 Rider를 사용했고, JetBrains 러버이다 보니까 큰 무리 없이 잘 사용했다
클론코딩에 얹어서 강의에 나오지 않은 부분까지 고도화를 해서 핸드폰에 설치해봤다
아이폰은 플러터나 유니티가 앱스토어에서 설치받지 않은 앱은 1주일 후에 사용하지 못하는 것 같았다
그래서 안쓰는 예전 안드로이드폰에 설치했당 쿠쿠
학부시절 지구공 튕기기라는 유니티게임을 팀프로젝트이지만 기여도 거의 90%로 만든 적이 있다
나는 백엔드쪽에 가까운 개발자이지만 내가 수정한 코드가 화면에서 다르게 동작하는 것을 보고 있으면 너무 설레고 신기하다
심심풀이로 유니티도 3D를 배우고.. 데스크탑도 하나 사서 언리얼도 해볼까 생각중이다
왜!! 언리얼은 인텔만 좋아하냐고.. ARM Mac 유저는 운다...ㅠㅠ
 
> React
리액트는 사실 취준생때 무료 강의를 보고 아주 간단한 웹앱정도만 만들어 보고, 큰 프로젝트에는 백엔드로 참여해서 프론트코드를 같이 리뷰하는 정도로만 해봤었다
회사를 다니면서 Angular -> Vue 순으로 사용해봤고, 언젠가는 React도 겪어보고싶다
일단 Udemy에 있는 풀 강의를 듣고 사이드프로젝트를 해보면서 레벨업을 해봐야겠다
 
> Scala
스칼라는 wiki에서 검색하면(https://ko.wikipedia.org/wiki/%EC%8A%A4%EC%B9%BC%EB%9D%BC_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)

Java와 다르게, 스칼라는 
커링, 불변성, 느긋한 계산법, 패턴 매칭 등 여러 함수형 프로그래밍 언어의 기능
을 가지고 있다. 스칼라의 자료형 체계는 대수적 자료형, 공변성, 고차 자료형, 익명 자료형을 지원해 Java에서는 이룰 수 없는 높은 수준의 추상화를 달성할 수 있다.

라고 한다
JVM위에서 돌 수 있는(Jython은 말고...)
Java, Kotlin, Scala언어를 배우고, 어떤 것에 적용해보고 싶다
카프카도 스칼라로 쓸 수 있다고 한다. 다만 회사차원에서 퇴사나 이직, 신규직원들을 뽑거나 한다면 자바가 제일 안전빵이긴하다

> Algorithm

백준에서는 골3정도, 프로그래머스는 2024년 기준 618문제중에서 140문제정도를 풀었다

프로그래머스에 올라온 코딩대회이다. 상위 랭크만 해도 어마어마한 상품들을 준다
내가 취준생 시절 올라왔던 대회도 똑같았다. 1등이 자동차라니..!! 물론 난 1등을 할 정도의 실력을 가지진 못했지만, 장려상까지만 가도 갤럭시 버즈 프로를 받을 수 있다
사실 현업에서 알고리즘? 난 웹쪽이라 그렇게 사용할 일이 많지 않다
하지만 최소한 공간/시간복잡도적으로 더 나은 로직을 구현해내는건 알고리즘 영역에서 오는 실력이 뒷받침되어야한다고 생각한다
알고리즘 1도 모르고 단순히 인덱스만 건다고 해서 빨라지는데요?만 하기보다 인덱스의 자료구조 형태와 그에 따라 조회시간이 어떻게 달라지는지 아는 사람이 더 좋다
하지만... 요새는 백엔드보다 프론트엔드가 그래프같은 로직을 처리한다고 알고리즘을 더 많이 알아야 하는 웃픈 상황도 있는 것 같다
잡설하고.. 나는 내가 취준생때 이루지 못한 알고리즘 플래티넘/다이아를 가보고 싶고 여러 대회에도 참가하고 싶다
그리고 알고리즘을 좋아하고 현실의 다양한 문제들을 해결하는 것에 자신 있다고 말할 수 있는 그런 멋진 개발자가 되고 싶다

> Cert
2024 한 해는 또한 자격증도 취득하려고 한다
현재 있는 자격증은 정보처리기사, SQLD, 컴활1급 등이 있다
여기에 내 실력과 매력을 보여줄 수 있는 Linux Master 1급, SQLP, AWS, CKA 자격증들을 취득하고싶다
아.. 몸 한 10개로 늘리고싶다
 
> Blog
나는 블로그에 글을 올릴 때 내가 최근에 구현한 최신 기술을 올리기보다, 뿌리가 될 수 있는 CS 기반지식(옛 것)부터 시작해서 그 CS지식이 IT기술에 어떻게 녹아져 있는지에 대해서 알려주는 글을 작성하고 싶다
종종 프론트엔드 신입분들이 CS지식 알아서 어느 이점이 있는지, 프론트에서는 굳이..? 라는 생각을 갖고 있는 것을 주변에서 간혹 봤다
HTML만 해도 <></>만 안다고 해서 끝이 아니라..!
HTML 자체가 DOM이고, 이 DOM은 Tree 자료구조 형태이다. 그리고 Tree는 Node라고 불리는 요소들의 부모-자식 연결이다
또한 리액트에서 useMemo는 메모이제이션 기법을 사용하며, 캐싱과 재사용 원리를 갖고 있다
내 글을 보는 사람이 CS지식을 바탕으로 문제 해결에 도움을 얻고, 나를 좋아해주면 좋겠다는 생각을 갖고 있다
현실에서는 Supabase, Kotlin Spring, Kafka, Redis, Kubernetes 등등 핫한 기술들을 사용한 프로젝트를 하고 있는 중이고, 포스팅도 할 수 있다. 하지만 나는 앞에서 일어나는 마법의 결과보다는 작동 원리를 차근차근 이해하고, 알려주고 싶다
천천히, 흔들리지 않는 뿌리를 가진 나무가 되어서 팀을 이끄는 리더가 되거나, 시니어 개발자가 되었을 때 누군가가 나를 닮고 싶다는 마음을 갖게 하는 개발자가 되고 싶다
블로그는 나를 나타내며, 결과 1줄만 작성하고 싶지 않다. 나는 블로깅을 통해 소통하고 성장할 것이다!

> k8s
2023년에 리눅스와 도커를 공부하면서 기반을 다졌다고 생각한다
2024년에는 쿠버네티스를 초~중급 레벨로 이해하고 다룰 수 있게 되고싶다
집에 볼 책들과 결제한 강의부터 다 보고 이야기하자...ㅋ

> ci/cd
큰 회사에 가게 된다면 일련의 모든 과정들이 완료되어 있겠지만, 두근두근 스타트업에서는 내가 해결해야 할 문제들이 많다
그리고 CI/CD도 그 중의 하나가 될 수 있다
나는 2는 1+1이게 아니라, 2는 3-1, 1+1, 1*2, 루트2의 제곱 등등 2라는 답이 나올 수 있는 다양한 가짓수가 있다고 말하고 싶다
CI/CD에도 그렇다
젠킨스, TravisCI, TeamCity, CircleCI, ArgoCD, Github Actions, Gitlab Runner...
결국 하나를 깊게 다루게 되겠지만, 과정 중에는 여러 방법들을 비교하고 체험해보고싶다!
 
=> Summary
맨 아래는 2024년 목표에 좀 더 가깝게 글을 쓴 것같다
2023년에 참... 이것저것 찍먹하고, 배우고, 경험해봤다
미래를 위한 토대를 쌓은 값진 시간이었던 것 같다

https://www.joongang.co.kr/article/25197546#home

위에는 그냥 사회가 요구하는 육각형 사람이고, 아래는 최범균님의 육각형 개발자 책이다
세상은 참 다양한 분야에서 뛰어나길 바라는 것 같다
마침 나는 별자리와 띠로 봤을 때 이것저것 잘하는 사주(?)라고 본 것 같다. 잘하는진 모르겠지만, 하고 싶은건 엄청 많다
내 생각은 육각형하고는 조금 다르다. 나는 미리미리 스타트를 해봐야 된다고 생각한다
나중에 가서 나 게임개발자해야지! 한다고 갑자기 유니티/언리얼을 할 줄 알게 되는 것도 아니고, 앱 개발 해봐야지! 한다고 해서 언제 또 시간내서 Kotlin, Swift, Dart, React를 공부하고 있겠는가..
언젠가는 내 분야에 대해서 회의감이나 번아웃이 올 때가 있다고 생각한다
10년 자바 고급 개발자? 멋지지.. 돈도 엄청 잘벌겠다
하지만 그게 맞는 사람이 있고, 맞지 않는 사람이 있듯 나는 여러가지를 해봐야 만족하는 타입이라고 내 스스로를 알게 됐다
나는 학창시절 수학이 질리면 과학을 공부하고, 과학이 질리면 영어를 공부하고 이랬던 것 같다
이때, 알파벳을 모른다면 영어책을 펼쳐도 눈에 들어오는게 없고 아마 책상에 엎드려 자겠지..?
개인적으로 개발도 비슷하다고 나는 생각한다
나중에 취미로 내 분야가 아닌 개발을 한다고 했을 때, 적어도 알파벳은 알아서 영어책 정도는 읽을 수 있어야 한다
그래서 지금 기반지식을 아래서부터 쌓아 올리는 과정이라고 생각한다
 
이 글을 보는 분들 2024년 한 해도 건강하고 행복하고 하는 일 다 잘되길 응원한다