기록을 전송

(2편) AI 오해와 사실 - AI는 낱말 조합 글짓기 기계다.

sendkite — Sun, 7 Jun 2026 02:42:09 +0900

올해 초에 회사에서 "AI 온보딩 - 다 함께 AI 성숙도 올리기" 주제로 발표를 했다.

비개발 직군 분들이 이건 알고 AI 쓰면 좋겠다는 마음에 정리 했던 것인데 슬라이드 일부를 공유해본다.

2026 사내 발표

AI의 정체

AI의 시작은 예측이다.
2012년 LLM 관련 초기 논문을 보면
일상의 자연어는 반복적이며 단순해서 예측할 수 있다는 것에서 출발한다.

그런 점에서 LLM은 글짓기 기계다.
입력이 들어오면 가지고 있는 데이터로 답변이 될 내용을 예측해서 글짓기를 해준다.

2025년 젠슨황이 인생을 돌아가면 생물학을 공부할 것이라 언급한적 있다.

아래 시스템 생물학을 보면 왜그런지 공감이 간다.

AI의 기저에는 '예측'이 있다.

이 내용을 알면, AI를 어떻게 사용해야할지 감이 온다.

아래처럼 불필요한 예측을 유발하는 요소는 제거하고

논리적이며, 정제된 내용으로 사용해야한다.

AI 사용의 부적절한 예

AI의 미래

2022년 ChatGPT 등장 이후 스택오버 플로우 질문이 5/1 토막이 났다.

더 이상 우리는 질문하고, 답변하지 않는다.

명확하게 질문하고, 명확하게 답변하던 행위들이 사라졌다.

2022 스택오버 플로우 글 통계

지금의 AI 성능이 좋은 이유는

그 동안 인류의 데이터가 있기 때문이다.

AI 모델 성능을 위해 물류 센터에 책을 수백만권 구매해 스캔 했다고 한다.

그런데, 요즘에는 AI가 생성한 데이터를 AI가 학습하고 있다.

AI Slop이라는 신조어도 나왔다.

잘못되고, 품질이 낮은 데이터를 AI가 벌써 학습을 시작했다.

AI의 성능은 영원할까?

AI를 어떻게 사용할지 보다,

AI에게 줄 데이터를 어떻게 관리하고

출력을 검증하는 것이 중요하다.

2026.05 클린 아키텍처 리뷰 - 읽을 만한 고전인가

sendkite — Sun, 7 Jun 2026 02:11:35 +0900

최근에 아키텍처 스터디에 참여했다.

정확히는 약 두 달 동안 《클린 아키텍처》를 읽는 스터디였다.

AI 열풍으로 할 것도 많은데 왠 아키텍처 싶겠지만,

AI 시대에는 아키텍처가 1순위 역량 아닐까 생각한다.

올해 초에 클로드 코드 유출 사고가 있었는데,

클로드 코드 품질이 형편이 없다 같은 이야기가 있었다.

그래서 유출 코드를 클로드로 평가 해봤는데
아키텍처 영역이 만점에 가깝게 나오더라

클로드 코드 유출 사건

클린 아키텍처는 알라딘에서 몇 년전 구매해 두고 책장 한구석에 꽂힌 책인데

잘되었다 싶어서, 냉큼 스터디에 지원했다.

스터디 후기는 대만족

1. 자리만 차지하던 책을 완독해서 속이 다 시원하다.

2. 9명 인원 스터디로 매주 2명씩 발표해서, 발표 퀄리티가 유지 됬다.

3. 참여 인원 경력이 4-6년차로 비슷해서 좋은 토론 주제가 많았다.

4. 모임장이 부담 없이 일정 구성을 잘 구성했다.

책 - 클린 아키텍처

책 내용은 개발 철학, 설계 원칙, port-adapter 패턴이다.

코드가 없이 추성적이다 보니
ChatGPT에 내가 이해한게 맞는지 spring boot로 예시 요청을 무진장 하며 읽었다.
그렇게 이해한 내용은 스터디에서 토론으로 검증할 수 있어서 좋았다.

열심히 만든 발표 자료 첨부해본다.

https://docs.google.com/presentation/d/1L5yFcqnBSTKbhwtowIVtakwkJgQVSlrphJ4vrOWhnRE/edit?slide=id.p#slide=id.p

20260421_아키텍처(20-24)

5부 아키텍처 20장 업무규칙 (Business Rule) 21장 소리치는 아키텍처 (Screaming Architecture) 22장 클린 아키텍처 (The Clean Architecture) 23장 프리젠터와 험블 객체 (Presenter, Humble Object) 24장 부분적 경계 (Partial

docs.google.com

https://docs.google.com/presentation/d/1RVwH09To1AaGSE6A7TOit6x7YadqklmVsmfhBtcS3F8/edit?slide=id.g3dd3973cb84_0_5#slide=id.g3dd3973cb84_0_5

20260405_클린아키텍처_4부_컴포넌트원칙

4부 - 컴포넌트 원칙 12장 - 컴포넌트 13장 - 컴포넌트 응집도 14장 - 컴포넌트 결합 2026.04.07 전송연

docs.google.com

(1편) AI 오해와 사실 - AI는 멍청하다.

sendkite — Fri, 20 Mar 2026 00:17:59 +0900

최근 좋은 기회로 “AI 시대 인재는 어떠해야 하는가”를 주제로

현업 실무자들의 조언을 듣는 인터뷰에 다녀왔다.

나를 포함해 총 13명의 다양한 분야 종사자들이 참여해,

각자의 관점에서 AI 실무 활용에 대한 이야기를 나누었는데,

요약하면 다음과 같다.

자동차부품 업계 -> 국가 핵심 산업으로 AI를 떠나 인터넷도 사용 불가한 환경
제조업, 물류, 의료기기 업계 -> TF 조직 단위로 엑셀 작업 자동화 시도
수출업, 공공기관 -> ChatGPT, Gemini 같은 도구 적극 사용중
소프트웨어 회사 -> 전 직원이 AI를 사용중이며 모든 업무에 AI를 어떻게 사용했는지 보고하며 인사고과에 반영

결론부터 말하자면, 소프트웨어 기업과 피지컬 기업의 AI 활용도 격차는 생각 이상으로 크게 벌어져 있었다.
왜..
나는 AI의 기본 원리와 한계점에 대한 교육 부재라고 생각한다.

AI 자율성 활용 수준

먼저 살펴보고 가야할 것이 있다.

작년 5월 쯤 등장한 AI 활용 수준을 나타내는 용어다.

AI in the Loop
- 인간이 대부분의 일을 수행하며 AI는 보조자 역할
Human in the Loop
- AI가 대부분 일을 수행하며 인간은 판단(검토, 승인) 수행

개발자 대화방 - 사람이 직접 코드를 작성하지 않는 것은 일상이 되었다.

Human on the Loop
- AI가 완전 자율로 일하며 인간은 최종 결과물 승인

개발 쪽은 Ralph Loop라고 해서 잠자는 동안에도 AI가 24시간 작업하게 하는 도구도 나왔다. 어떻게 될지는 모르겠지만 코딩을 자동화하면 AI 발전이 급속도로 높아질 것라고 한다.

소프트웨어 기업은 AI in the Loop + Human in the Loop + Human on the Loop 로 AI를 활용하는 반면
피지컬 기업은 챗봇 활용 수준의 AI in the Loop 정도로 활용하는 것으로 보인다.

어떻게 하면 Human in the Loop, Human on the Loop 로 활용할 수 있을까?

다시 반복하지만 나는 AI의 기본 원리와 한계점에 대한 교육 부재라고 생각한다.

AI 기본 원리를 살펴보기 위해 가장 빈번한 오해를 살펴보자

AI 오해 (1) - AI는 멍청하다.

대부분 사람들이 ChatGPT와 같은 AI Chabot을 쓰며 ‘멍청한 것 같아’, '자꾸 이상한 말을 한다' 라고 표현한다.

이는 오해다.

사실 AI는 반드시 이상한 말을 한다.

우리가 AI라고 말하는 기저에는 LLM이 있다.

LLM은 완성 문자열의 확률 분포를 학습 데이터 토대로 모델링 하는 것이다.

(이전 결과 바탕으로 다음 단어 예측 반복 하는 것)

과격하게 표현하면 "낱말 조합 글짓기 기계다."

"오늘의 날씨는" 뒤에 확률적으로 "맑다", "좋다", "흐리다" 같은 단어가 올 수 있다.

문제는 확률적으로 가장 높은 확률로 조합하는 것이 아니라 무작위로 조합한다.

"오늘의 날씨는 링가르디움레비오사!" 가 될 수도 있는 것이다.

멍청한 것이 아니다, 모델이 아무리 뛰어나도 확률적으로 반드시 잘못된 결과가 나온다.

좀 들어본 용어로 아래처럼 표현한다.

이런 잘못된 결과 -> 할루시네이션

요청할때 마다 확률적으로 다른 결과 -> 비결정성

AI 오해 (2) - AI는 무료다.

AI에게 질문은 공짜가 아니다.

데이터를 가져올때 질문은 token이라는 것으로 변환되며,

질문할때마다 token 만큼 비용이 발생한다.

지금은 역사상 AI Model 사용료가 가장 낮은 시점이다.

무제한 요금제로 몇 천만원, 몇억씩 사용해봤다는 개발자들이 많았는데

최근에는 임계치를 넘으면 막고 있으며, 모델의 비용이 다각화 되고 있다.

- 가벼운 작업 -> 저렴한 모델

- 추론, 분석 작업 -> 중간 모델

- 복잡한 추론, 리서치 작업 -> 비싼 고급 모델 (월 구독료가 30만원을 넘어간다.)

AI 사실 - 내가 멍청하다.

LLM이 무작위 확률 낱말 글짓기라고 했다.

목표하는 답변이 나올 확률이 높은 질문을 하면, LLM이 올바른 답변을 줄 확률이 올라간다.

좋은 질문을 해야한다.

[좋은 질문이 필수 요소]

- 내가 달성하려는 목적

- 내가 목표를 위해 참고한 것

- 내 작업 환경

- 내가 한 시도들

- 내가 얻고 싶은 답

Prompt 템플릿, 페르소나, Context 다 좋은 질문을 위한 요소일 뿐이다.

그래도 질문하기 어렵다면

요즘은 Meta Prompting이라고 해서 좋은 질문(prompt)을 LLM을 통해 만들 수 있다.

(ex. 이런 작업을 하려고 하는데 더 필요한 건 없을지 날 인터뷰 해줘.. 이런 작업을 하려고하는데 prompt를 생성해줘)

AI 사실 - AI는 반드시 잘못된 결과를 준다.

잘못된 결과는 할루시네이션 뿐만 아니다.

AI가 학습한 데이터가 오염되면 확증 편향의 오류를 가질 수 있다.

학습한 데이터가 편향적으로 학습되어 사실이 아닌데 사실 처럼 줄 수 있다.

(인터넷에 잘못된 블로그 글, AI로 생성한 글, 잘못된 기사, 커뮤니티 글 등.. 얼마든지 학습 될 수 있다.)

Claude를 만든 엔트로픽은 양질의 데이터 학습을 위해 책 수백만권을 스캔하여 학습 시키고 버렸다. (프로젝트 파나마) https://www.aitimes.com/news/articleView.html?idxno=206046

LLM이 학습한 데이터는 최신의 데이터가 아니다.

LLM은 학습시킨 시점의 고정된 정보만 가지고 있다. 구식의 정보를 줄 수 있다.

소프트웨어 회사의 AI

AI가 주는 데이터가 반드시 잘못 되었다는 것을 알고

AI 작업 결과물 검증, 제어, 테스트 작업이 필요하다.

이를 '가드레일'을 만든다고 한다.

(ChatGPT로 예로 들면, 결과물의 출처 링크를 주는 것도 가드레일이다.)

가드레일이 없는 AI는 업무에 사용해서는 안된다.

소프트웨어 회사는 이러한 가드레일을 자동화했다.

(다음편에 계속. . .)

Reference

- LLM의 동작원리 https://www.youtube.com/watch?v=sTdz6PZoAnw

- 팀 하네스 구축 https://toss.tech/article/harness-for-team-productivity
- LUI의 시대 harness : https://toss.tech/article/software-3-0-era
- AI 거품 https://www.wheresyoured.at/the-haters-gui/
- AI 도구 생산성 하락 https://www.theregister.com/2025/07/11/ai_code_tools_slow_down/?ref=wheresyoured.at
- 일자리는 AI가 대체하는게 아니라 소비하고 있는 것이다. https://www.fastcompany.com/91435192/chatgpt-llm-openai-jobs-amazon
- 전체 Ai agent 절반은 소프트웨어 https://garryslist.org/posts/half-the-ai-agent-market-is-one-category-the-rest-is-wide-open

AI 자율성 활용도 수준 - AI 스펙트럼

- https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html

- https://community.ibm.com/community/user/blogs/anuj-bahuguna/2025/05/25/ai-in-the-loop-vs-human-in-the-loop

- https://www.youtube.com/watch?v=mYMvFZDTC_M&t=1s

2025 회고(2) - 개발자 5년차 커리어 회고

sendkite — Tue, 6 Jan 2026 01:51:50 +0900

개발자 5년차의 회고

2026년을 기점으로 5년차 경력이 되었다.
개발자가 될 결심을 했을때 적어도 5년 뒤에 어떤 모습이길 원하는 청사진이 있었다.

“평균보다 잘하는 개발자”
“해외 취업이 가능한 역량 상태일 것”
“생존 걱정하지 않을 만큼의 연봉”
“회사에서 일할때 유쾌하고 행복할 것”

초기에 설정한 목표가 실제로 달성되었는지 반추해본다.

ChatGPT로 생성한 5년차 개발자 이미지

“평균보다 잘하는 개발자”

늦은 나이에 전 재산을 걸고 개발자로 전직했다.
반드시 평균 이상, 가능하면 탁월하게 이 업을 잘하고 싶었다.
시간이 많지 않았기에 지름길을 택했다.
나보다 먼저 간 잘하는 개발자들을 롤모델로 세우고 따라하기로 했다.

롤모델

세미나, 강의, 서적을 통해서 많은 분들을 만났다.
김영재 님(라인) - https://engineering.linecorp.com/ko/blog/author/김영재
- 제품,서비스 기획, 발전 방향, 일의 최적화 인사이트를 주신 분.
  - 지금 업무 스타일의 뼈와 살이 되었다.
- 오프라인 강연 듣고 너무 좋아서 시중에 존재하는 모든 컨텐츠를 반복했다.
  - 유튜브, okky 강연, 마이크로소프트 강연, 인프콘 강연, 라인 블로그, 출판 서적(책 - Design it!)
한정수 님(실리콘 밸리) - https://www.integer.blog/
- 부트캠프 이력서 첨삭 아르바이트로 오셔서 이력서를 봐주신 분이다.
- 첫 취업, 이직할때 너무 큰 힘이 되었다.
- 인프런에 ‘취업 가이드’ 강의를 구매하여 초기에 너무 큰 도움이 되었다.
  - 개발 컨텐츠 노출 (트위터, 기술블로그, 유명한 개발 컨텐츠 등..)
  - 이력서 작성 및 제출 방법
김동욱 님(인프런) - https://jojoldu.tistory.com/
- 실질적인 나의 멘토이자 목표.
- 유튜브 개발바닥 초반 컨텐츠를 보면 35살에 7년차 배민을 퇴사하는 내용이 나온다.
  - 35살에 이 사람 정도의 실력이 있으면 좋겠다라고 생각했다. (https://www.youtube.com/watch?v=kE0qicg9Kl0)
  - 방송하면 뒷편에 있는 책장을 스크린샷 떠서, 따라 구매하고, 모든 컨텐츠를 챙겨 보며 마음을 다졌다.
- 오프라인에서 총 4번 만났다. (동욱 님은 날 모르겠지만)
  - 데스커 행사 - 당시에 회사에서 겪던 조직 갈등, 기술적 문제에 대해 질문해 큰 도움을 받았다.
  - 마이크로소프트 - 인프런 조직에 대한 발표, 조직 문화, 업무 프로세스를 이렇게 까지 좋게 만들 수 있구나 인사이트
  - 데브콘(스파르타) - 문서화 잘하는 방법, 슬랙 더 잘 쓰는 방법, AI 활용, DORA Metric 같은 키워드
  - 스프링캠프 - 매니저급 들의 인사이트
박용권 님(당근) - https://www.linkedin.com/in/arawn/
- 스프링캠프에서 앞으로의 스프링의 방향에 대한 발표를 들은 후 팔로업 한 분이다.
- Nextstep - 모놀리틱 아키텍처 강의
  - Spring momulith를 알게 되고 써보고 싶다는 동기를 주신 분이다.
  - 덕분에 현재 실무에 Spring modulith를 도입하여 쾌적한 아키텍처를 구축할 수 있었다.
  - 스프링캠프 - 토론 할때 요구사항을 정확히 정제하는 질문 법 같은 것을 배운 것 같다.
조영호 님(개인 사업자) - https://eternity-object.tistory.com/
- 개발 코드의 철학을 심어주신 분이다.
- 이분 덕분에 코딩 자체에 대한 재미가 생겼다고 해도 과언이 아니다.
- 작년에 온라인 강의도 2개 내셨는데, 오프라인 강의력이 기가 막히시다.
- 강의
  - 객체지향사실 오해
    - 이 책으로 스터디만 3번 진행했다. 정말 마스터 피스
    - https://www.youtube.com/watch?v=dJ5C4qRqAgA
  - 도메인 주도 설계 사실과 오해
    - 이것 덕분에 DDD 관련 컨텐츠 소비가 너무 수월했다.
    - 현재 팀 모두가 DDD 용어를 이해하고 있으며, 적용되어 있다.
  - JPA 사실과 오해
    - 실무에서 JPA, TypeORM 같은 ORM을 써보면 아래 같았다.
      - N+1은 무조껀 발생하고 있다.
      - 왜 나는지 추적이 어려우며, 성능 손해 원인인데, 다른 업무로 손대지 못한다.
      - 연관관계를 다 끊고 사용하도록 강제
    - 네이버 재직 시절부터 JPA를 사용하시며, 아키텍처적으로 이렇게 사용해야한다. 명쾌한 답을 주신 강의
      - 현재 회사에서는 N+1 문제 없이 연관관계를 쾌적하게 사용중이다.
이태형 님(아이아이컴바인드) - https://jsonobject.tistory.com/
- 첫 회사의 시니어 님이다.
- 내 첫 코드 스타일, 업무 스타일에 너무 많은 영향을 주신 분이다.
- 이분의 빠른 학습 능력은 아직도 따라가기 바쁘다.
손권남 님(네이버) - https://kwonnam.pe.kr/wiki/
- 1세대 개발 파워 블로거,
- 블로그 글들로 많은 것을 배웠다.
  - 특히 개발자 머피의 법칙, 롬복 사용법, 읽기/쓰기 DB 라우팅에서 큰 도움을 받았다.
이일민 님(토비) - https://www.linkedin.com/in/tobyilee/
- 발표력, 강의력이 대한민국 No 1.
- 클린 스프링 강의 시리즈 시간가는 줄 모르고 보면서 많은 인사이트를 받았다.
백기선 님(마이크로소프트)
- 자바 8 강의, 커리어 관련 강의로 도움을 받았다.

나는 평균보다 잘하는 개발자 인가?

평균 보다 많은 개발 컨텐츠를 소비하고, 소화하려고 노력은 한 것 같다.
평균 보다 깔끔한 코드를 작성하고 있다.
- 유지보수, 생산성 좋은 코드를 만들어 내는 것 같다.
평균 보다 많은 스터디 시간을 투자 할애하고 있다.
평균 보다 많은 연봉은 받지 않고 있다. (제일 슬픈 부분)
평균 보다 Database, 인프라에 약하다.
- Redis, Kafka, DynomoDB 같은 Store 기술을 너무 얕게만 알고 사용하고 있다.
평균 보다 테스트 코드를 안짜고 있다.
- 이건 올해 목표다. 작년 팀에서 테스트 코드 기여가 가장 작았다.
- 테스트 코드 커버리지 올려보자
평균 보다 회사 외 활동을 제한적으로 하고 있다.
지식 공유나 발표 횟수가 아쉽다.

⇒ 개인적으로는 지난 5년을 학점으로 평가하면 B학점이다.

“해외 취업이 가능한 역량 상태일 것”

마이크로소프트 직무 연차별 특징 (출처 : 백기선님 - 커리어 강연)

마이크로소프트 재직자의 연차별 역량 요구사항 보고 점검해보자.

넷플릭스 흑백요리사2 - 요리괴물

주니어(SDE) 역량 (1 ~ 3년)
- 업무 범위가 명확한 업무 처리 능력
  - 구체적인 요구사항이 있는 업무 완수하며 신뢰 쌓기
  - 업무 배경지식 파악 (서비스 도메인 이해, 협업 동료 성향 파악)
  - 기술역량, 협업 기술 키우기
    - 의사소통 → 문제를 잘 이해하려는 질문 능력
    - 기술적 구현력
    - 일정 맞춰보는 연습 (ETA 산정 연습)
미들(SDE2) 역량 (3 ~ 5년)
- 조금 덜 분명한 문제, 목표를 독립적으로 달성 능력.
  - 전반적인 프로젝트, 전반적인 E2E, 시나리오 관점에서 업무 바라볼 수 있어야함
    - 업무 범위와 작업량을 적시에 관리
    - 작업 우선순위 판단력
    - 매니저에게 작업 진도 적시 공유
  - 특정 도메인의 특화 담당자가 되어 전문성 키우는 단계
    - 코딩, 설계, 디버깅, 설계 문서 작성, PM 협업, 수치 분석 실천할 수 있어야함
      - 전문성을 바탕으로 설계와 구현까지 독립적으로 수행할 수 있어야함
      - 데이터 통찰력을 가지고, 잠재적인 이슈를 제거하거나 개선사항 찾을 수 있어야함
      - 정기적으로 담당 분야 또는 모듈 이슈를 리뷰하고 개선할 방법을 찾고 개선 작업
  - 효율적인 협업으로 의사소통 최적화 능력
    - PM, 매니저 활용 능력
시니어 (6 ~ 8년, 최고 5+)
- 모호한 업무, 목표 수행 능력
  - 일이 가능한 형태 만들어 의사결정 가능 하도록 업무 수행
    - 중요한 의사 결정에 참여하고, 담당 분야에 명확한 비즈니스 임팩트를 보여줄 것
  - Feature Crew (4-5명 규모 팀) 테크 리더
    - 팀 지속, 발전 방향, 문화에 큰 영향력 행사
      - 팀 구조, 팀 업무 절차 정의 역할
      - 업무 성취 프로세스 개선
    - 풀기 어려운 문제의 전략 수립
  - 타 개발자 업무적 솔선수범 (Lead by example)
    - 좋은 업무 방식, 행동 예시 등 팀의 롤모델이 될 것
  - 팀 내 다른 개발자 서포트
    - 멘토링, 기술적인 스킬 지식 전파
  - 피드백 제공 - 시스템, 서비스, 팀원
  - 조직간 전략적 협업 능력
    - 본인 행동 반추하여 행동을 개선 - 팀, 업무 관계자들과 좋은 의사소통, 관계 유지할 것
수석 엔지니어(Principal SDE) (8 ~ 12년+)
- 프로젝트 범위가 넓고, 시간과 비용이 큰 프로젝트 리딩
  - 4-5팀 규모의 조직 리딩
    - R&R 분산, 협업 환경 조성
  - 1-2년 이상의 장기 프로젝트 리딩하고 큰 비즈니스 임팩트 가져옴
  - 테크 리드
    - 베스트 프랙티스
    - 코딩 및 검증 전략 제공
    - 품질 관련 지표 공유 전파 (성능, 안정성)
      - 배포 버전별 수치 변화 리포트
    - 고객, 제품 데이터 기반 통찰력 있는 설계 및 구현
- 회사 추구하는 핵심 가치 전파, 개발 문화 조성
  - 타 엔지니어의 롤모델
  - 조직 문화 개선, 멘토링
  - 기술적, 문화적 개선사항 식별/개선
시니어 수석 엔지니어 (12년+ ~)
- C Level, 그룹장
- 팀 기술적 자문, 리뷰
- 조직 전체 개발자들의 롤모델로 영감을 주고 업무에 영향력
- 조직 전체 엔지니어링 문화 개선

나는 해외 취업이 가능한 상태인가?

외국어 공부를 너무 안하긴 했는데, AI 도구가 너무 좋아져서 커버할 수 있을 것 같다.
미들(SDE2) 역량은 소화한 것 같다.
코딩 테스트, 외국어 능력만 증명하면 도전해 볼수 있지 않을까

⇒ 개인적인 평가는 A 학점

2025 포르투 여행

“생존 걱정하지 않을 만큼의 연봉”

돈이 없으면 경험 안해도 될 싫은 상황들이 있는데
작년 정신적으로 힘든 일이 너무 많았다.
올해 연봉 협상이 어떻게 될지 모르지만, 커리어/재무관리에 큰 변화가 있을 것 같다.

⇒ 개인적인 평가는 C 학점

2025 포르투 여행

“회사에서 일할때 유쾌하고 행복할 것”

개발 환경적으로는 최신 기술스택에 하고 싶었던 것을 마음껏 펼쳐 본 한해다.
좋은 시니어도 만나, 업무적으로 업무 외적으로 배울 것이 많았다.
처음 개발에 입문해 만난 친구도 다시 동료로 만나 심리적인 든든함이 있었다.
회사에서는 업무적으로 복이 많았던 해이다.

⇒ 개인적인 평가는 A+

무엇보다 내 가족도 같이 유쾌하고 행복한 한해가 되길 바래본다.

2025 리스본 여행

2025년 바르셀로나 호안미로 미술관

결론

“평균보다 잘하는 개발자” (B)

DB, 인프라 (redis, kafka, dynamo…) 역량 강화에 힘쓸 것
AI 활용 늘릴 것
테스트코드 작성 할 것

“해외 취업이 가능한 역량 상태일 것” (A)

이커머스 전반 도메인 역량 강화 할 것
비즈니스 임팩트 주는 성과 만들 것

“생존 걱정하지 않을 만큼의 연봉” (C)

성과 챙기기
TBD

“회사에서 일할때 유쾌하고 행복할 것” (A+)

내 할일 잘해서 신뢰 잃지 말것
팀원, 동료 챙기기

2025 회고(1) - 겨울, 생존, IT의 가치

sendkite — Fri, 2 Jan 2026 01:56:20 +0900

1. 너무 추운 겨울

업계 전반에 구조조정이 일상처럼 확산되면서, 이제는 더 이상 특별한 일이 아닌 ‘보통의 일’이 되어버렸다.

올해 구조조정 뉴스

유니콘 기업도 경영의 기조가 변했다.
- 연이은 흑자 전환 보도가 이어지나, 이는 성장을 포기하고 생존과 회수에 집중한다고 느꼈다.
- 개발 세미나에서도 '무엇보다 회사의 비즈니스, 생존'이 중요하다는 워딩이 자주 들렸다

언더스탠딩 - https://www.youtube.com/watch?v=V2t6wvugHwU

2024년 IT 유니콘의 성장률과, 영업 이익률 - SaaS 기업이 40%가 초과하면 매력적으로 평가 받는다고 한다

개발자들의 지갑도 닫혔다. (AI의 영향일 수 있으나, 개인적인 생각이다.)

인프런 재무재표

2. 회사의 생존

회사가 생존하려면 경쟁에서 이겨야한다.

경영학 3대 거물로 마이클 포터라는 교수가 있다. (피터 드러커, 톰 피터스와 함께)
기업의 '경쟁 전략'을 체계화한 인물로, 경영 전략의 교과서를 만든 사람이다.
이전 회사 CEO님이 경영학과 출신이었는데, 이 분의 이론에 영향을 많이 받으셨는지
신입 온보딩 일주일이 마이클 포터의 경영 전략으로 편성되어 있었다.
덕분에 기업에 생존을 생각하니 마이클 포터가 생각난다.

마이클 포터의 이론을 요약하면 경쟁에서 이기는 전략이다.

1. 경쟁 우위

기업이 지속하려면 경쟁 우위가 있어야한다.
경쟁 우위가 있으면 다른 시장 경쟁자에게 지속적으로 이길 수 있다.

경쟁 우위는 차별화 우위 또는 비용 우위로 나타단다.
둘은 trade off 관계로 둘다 가지려고 하면 실패한다.

ex) 스타벅스(고품질 차별화 우위) vs. 메가커피(저렴한 가격(비용) 우위)
ex) 이전 회사는 '타 회사 대비 저렴한 단가' 비용 우위로 시장 점유율을 1위를 하고 있었다.

마이클 포터 - 경쟁우위

2. Five Forces

내가 참여한 또는 참여할 시장 매력도 평가 프레임워크

마이클 포터 시장 평가 프레임워크

ex) 2022년 새벽배송

동종 업계 - 마켓컬리, 쿠팡 외에 없음
공급자 - 새벽배송 가능한 냉탑차 많지 않음 (조달자 약함)
잠재 진입자 - 물류센터 건립등 초기 투자비용 커 진입장벽 높음
구매자 - 쿠팡, 컬리 따라서 새벽배송 하고 싶은 소비자 넘쳐남
대체제 - 극소수

프레임워크에 따르면 새벽배송은 매력이 넘치는 시장이었다.

=> ex) 2024년 새벽배송

동종 업계 - 마켓컬리, 쿠팡, 신세계 자체 새벽배송, 더운반, 대한통운 ...
공급자 - 새벽배송 가능한 냉탑차 크게 증가하지 않음 (조달자의 힘이 강력해짐)
잠재 진입자 - 기업에서 자체 새벽배송 구축, 대기업 자본 진출
구매자 - 새벽배송 업체가 많아지면서 선택의 폭이 넓어짐 (소비자가 갑이 됨)
대체제 - 대기업 진출 물류로 다수의 선택권

매력도는 고정이 아니다.
시장 참여자에 따라 매력도가 가변하고 기업은 알맞은 전략을 취해야 수익성이 유지 된다.

3. 가치 사슬

기업활동을 작게 쪼개서 어디에서 경쟁 우위(차별화 또는 비용우위)가 만들어지는지 분석하는 개념이다.
ex) 애플의 차별화 우위
- 연구 개발 -> 세련된 디자인, 자체 소프트웨어 생태
- 구매 조달 -> 업계 최고 부품 업체들과 관계
- 물류 -> 애플 매장에 재고가 떨어지려고 하면 공급망 우선 배치 (앞당겨 배송)
- 마케팅 및 영업 -> 수요 예측, 판매력..
- 등등.. 이 유기적으로 연결되어 경쟁우위라는 것이 생긴다.

마이클 포터 - 가치사슬 (https://boardmix.com/kr/skills/value-chain-analysis/)

IT가 주는 경쟁 우위는 뭘까

IT는 주로 사업의 공격수 보다 서포트다. (게임이나, 솔루션, 네카라쿠당토 같은 IT 서비스가 상품인 곳은 공격수다)
서포트 역할의 IT가 가치사슬에서 제공해야할 것

IT의 경쟁우위 가치는 시간, 경험, 돈이다.
- 클릭 수가 줄어든다. (시간 단축 - 딸깍)
- 업무 자동화 된다.(사람이 줄어든다. )
  - 사람이 줄어든다.
    - 인건비가 줄어든다.
    - 실수가 줄어든다. (ex 푸시알림)
  - 낭비를 줄인다.
    - 운영 비용 (자동 정산, 분류 자동, 광고 최적화, 물류 최적화, ERP 회계 자동)
  - 리스크 감소
    - 규정 준수 자동화
- 기다림이 줄어든다.
  - 검색, 결제, 예약, 배달.. 등등 간소화
- 욕망 충족
  - 즐겁다.
  - 멋지다.
  - 감정 충족, 도파민.

위 가치를 B2C와 B2B로 나눠보자

서비스가 어떤 경험을 줘야하는지 정의하면
어떤 수치를 추적해야하고, 집중해야하는지 대략 이럴 것 같다.

✅ B2C 가치

감정적 만족 (즐거움, 편리함, 자존감)
- 귀찮음 최소화 - 세션 길이 / 체류 시간, 페이지 뷰,
  - 찾기 쉬움
  - 선택하기 쉬움
  - 결제하기 쉬움
  - 이해하기 쉬움
- 재밌음
  - 페이지 뷰
  - 컨텐츠 소비 완료율
  - 추천 클릭률
  - 콘텐츠 기반 전환률
  - 저장/스크랩/위시 비율
  - 공유율
습관 형성 (중독성, 매일 쓰게 하는 루프)
- Retention
- Frequency, Interval
- 핵심 행동 반복율
  - 재입고 알림 설정
  - 리뷰 작성
  - 장바구니 저장 후 구매율
  - 특정 콘텐츠, 카테고리 재방문율
친구가 쓰니까 쓰게 되는 네트워크 효과
- UGC 생성 비율 (사진 리뷰, 후기)
- 공유율

=> 사용자 삶을 변화

✅ B2B 가치

매출 증가 (Revenue)
- 구매 전환율 (탐색 -> 장바구니 -> 결제)
  - 탐색 시작부터 구매까지 얼마나 걸렸는가 (TTV)
  - 결제 완료율 / 결제 실패율
  - 장바구니 이탈율
  - 검색 실패율(검색 후 무행동)
  - 필터/정렬 사용률과 전환율
  - 클릭 수 / 단계 수
  - 로그인 / 인증 이탈율
  - FQA 작성후 구매 전환율 혹은 이탈률
- 반복 구매(Retention) 증가
- 신뢰(배송 예측 가능성, 클레임(VoC)) -
  - 주문/배송/취소/교환/반품 CS 인입율
  - 컬러/사이즈 관련 반품 비중
  - 사용자가 결정에 필요한 정보 제공
비용 감소 (Cost)
- 운영 효율 (물류/CS/정산)
리스크 감소 (Risk)
- 오배송률 관리
- 중복배송 관리
- 정산오류율 관리
- 재고 정확도 관리
생산성 증가 (Productivity)

계층형 아키텍처 (Layered Architecture) - 지금은 일단 아키텍처 고민할 때가 아니야, 생존부터 해야지

sendkite — Mon, 7 Jul 2025 00:42:30 +0900

스타트업에서 신규 프로젝트가 시작되면

어디서 시작되었는지 모를 스켈레톤 탬플릿으로 코드베이스, 인프라가 뚝딱 나온다.

100이면 100 Layered Architecture였다.

몇년 지나면 해당 프로젝트는

'지금은 일단은 아키텍처 고민할 때가 아니야, 생존부터 해야지' 라는 논리로 Layered Architecture가 오남용된다.

Layered Architecture가 무엇이며 잘쓰는 법을 살펴보자

1. 계층형 아키텍처(Layered Architecture)란?

프로그래밍을 관심사를 기준으로 분리해서 계층 형태로 사용하는 패턴이다.
1990년대 중반에 등장한 개념으로 엔터프라이즈급 시스템에서 확장성, 유지보수성 문제를 해결하기 위해 제안됬다.
특히 Java, .NET, Oracle, SAP 등의 플랫폼에 본격적으로 채택되며 확산
사용자 입/출력 처리, 비즈니스 로직 처리, 데이터 저장소 같은 관심사를 분리해서 설계 시점 유연성, 재사용성, 유지보수성을 목적으로 탄생했다.
사실상 업계 표준으로 이해하기 쉽고, 적응이 쉽다.

책 - 클린 아키텍처 : 관심사를 분리하면 DB나 UI는 언제든 교체 가능한 선택을 가질 수 있다.

책 - 클린 아키택처 : 계층 예시

[계층형 아키텍처 - 계층별 설명]

계층	역할	구현 (스프링 기준)
Presentation (=UI, WEB, API)	요청, 응답 반환 책임	@Controller
Business Logic (=Service, Application)	도메인 로직 처리 (Domain Model, Transaction Script)	@Service
Data Access (=Persistence Layer)	DB 직접 통신	@Repository

제약 조건 :
- 계층은 같은 계층 또는 하위 계층만 의존할 수 있다.
- 하향식으로 의존한다. (ex. Business Logic은 상위 계층인 Presentation Layer를 의존할 수 없다.)
- 하위 계층이 상위 계층의 존재를 알아서는 안된다.
제약 조건을 위반하면, 계층간 결합, 순환 참조가 발생해 코드 복잡도가 기하 급수적으로 늘어난다.
아래 예시 의존 방향성은 계층형 아키텍처를 사용한다면 반드시 사수한다.

책 Design it - 개발자에서 아키텍트로

단점
- 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.
  - JPA 같은 ORM을 사용하면, Entity와 Domain이 결합되어 유연성이라는 품질속성을 잃는다.
  - (그러나, DB를 mysql -> postgress 같은 변경은 실무에서 0%에 가깝다. Entity, Domain 분리는 나중에 해도 늦지 않다.)

책- 만들면서 배우는 클린 아키텍처

지름길을 찾기가 쉽다.
- 특정 계층에서는 같은 계층 컴포넌트나 아래 계층만 접근 가능한데, 코드에서 강제하는 것이 아니다 보니 사람은 금방 위반하게 된다.
테스트 하기가 어렵다.
- 규모가 커지면 영속성이 복잡해지면서 종속성을 이해하고, mock하는데에 더 많은 시간을 보내게 된다.

2. 멀티 계층형 아키텍처 (Multi Layered Architecture)

2000년대에 접어들면서 Layered Architecture는 3계층(3 tier)의 단점을 보안하기 위해 멀티 계층 패턴(N-tier architecture)으로 진화했다.
현업에 대부분 적용중이다.

4계층 아키텍처

마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처에서 설명된 개념이다.
위에서 설명한 3계층에서 Domain Layer를 추가한 모습니다.
도메인 모델 패턴을 사용해, 재사용성, 유지보수성, 테스트 가능성 품질을 높일 수 있는 전략이다.

[4계층 아키텍처- 계층별 설명]

계층	역할	구현
Presentation	요청, 응답 반환 책임	UI, Controller
Application Service	작업의 흐름, 트랜젝션 조정	Service, Use Case, Application Facade
Domain	Domain Logic	Entity, Domain Service, Aggregate
infra	데이터 저장소, 외부 시스템 연동	Repository, ORM, DAO

조영호님 DDD 강의 - 4계층 아키텍처 강의 슬라이드

N계층 아키텍처

필요에 따라 아래 같은 Layer를 추가한다.
- API Gateway
- BFF(Backend for Frontend)
- Messaging Layer
- 등등..
MSA 형태로 서버가 분리되어도 좋다.
유지보수성, 확장성, 테스트 용이성과 같은 품질 속성을 끌어 올릴 수 있다.
(단, 비용이 따른다. 이래서 리소스 제한이 아키텍처에 영향을 준다.)

완화된 계층 아키텍처

"계층은 같은 계층 또는 하위 계층만 의존할 수 있다. '는 제약 조건을 완화한 계층형 아키텍처다.
마틴 파울러가 사실상 제약을 완벽히 따르기 어렵다는 것을 시사하며, Presentation에서 Data Access로 바로 의존하여도 괜찮다는 내용이다. (그래도 하향식 의존이라는 큰 틀은 반드시 지켜야한다.)
화면 그릴때 필요한 데이터 조회 QueryDsl Repository를 Controller에서 바로 사용하는 것과 같은 경우가 이 경우에 속한다.

결론

목표하는 서비스 규모, 품질 속성을 명확히 하자.
- 규모가 작다면 3계층 아키텍처가 가장 단순하며 충분하다고 생각된다.
아키텍처에 정답은 없는데, 제약조건은 정답이다. 반드시 지키자.
- 계층형 아키텍처를 사용할때는 하위 계층이 상위 계층을 모르게 만들다. 계층형 아키텍처의 핵심이다.
팀원들이 계층형 아키텍처 사용법을 위반했을때 잡아낼 방법을 만들자.
- ArchUnit
- Spring Modulith
- 코드 리뷰 문화
시스템 복잡도, 요구사항에 따라 멀티 계층 아키텍처를 옵션으로 고려해보자.

참고

- https://jojoldu.tistory.com/603

계층형 아키텍처

학교 다닐때 잠깐 JAVA 관련 수업을 들은적이 있다. 그때 수업 내용은 넷빈즈(Netbeans) IDE를 통해 JAVA로 윈도우 애플리케이션을 만드는 것이였다. 간단한 시간표 관리 프로그램을 만드는 과제는 얼

jojoldu.tistory.com

- https://herbertograca.com/2016/06/27/peaa-1-layering/?utm_source=chatgpt.com

PEAA.1 – Layering

Layering is a common practice to separate and organise code units by their role/responsibilities in the system. In a layered system, each layer: Depends on the layers beneath it; Is independent of …

herbertograca.com

2025.05.09 - 켄트 백의 Augmented Coding(증강 코딩): Explore, yes, expand & extract not so much (yet)

sendkite — Sun, 6 Jul 2025 00:16:50 +0900

TDD 창시자 켄트백 아저씨의 GenAI 사용법을 살펴보자

영문 Live로 들은 것을 정리한 것이라 오역이 있을 수 있습니다.

배경

최근에 켄트 백님이 Augument Coding이라는 개념을 제시하고 Prompt를 공유 했다. (https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes)
개발자가 GenAI를 생산적으로 쓰는 방법에 대한 공유다.
기존 바이브 코딩(Vibe Coding)은 AI가 만든 결과를 시스템의 최종 동작에 초점을 두는 반면, (코드 품질, 구조 보다는 돌아가는 것에 집중)
증강 코딩(Augument Coding)은 코드 품질, 복잡도, 테스트 등을 중요하게 생각하며, 개발자가 주도권을 가지고 도구로 AI를 활용하는 법이라고 설명한다.
25년 5월에 오라일리에 나오셔서 Augmented Coding에 대한 세미나를 진행했었는데, 세미나에서 나왔던 내용을 정리해본다.

5월에 진행했던 Oreilly AI 세미나

3X Thinker (2018 - facebook Kent Back에 소개했던 개념)

켄트 백은 AI와 개발을 3단계로 나눠서 실험하고 다음과 같은 결과를 얻었다.

개발은 - 탐색(Explore), 확장(Expand), 정제(Extract) 순서로 진행된다.

Explore : 탐색
- 빠르게 구현하는 단계다, 구현 하면서 아이디어, 학습 등등이 이루어진다.
- AI코딩 : AI가 추천하는대로 빠르게 만들면서 아이디어제이션, 학습, 구현을 할 수 있었다.
- 만족으러운 AI (Yes)
Expand : 확장
- 학습을 토대로 코드의 structure, design를 잡는 단계다. 큰 틀, 방향을 정한다.
- AI 코딩 : AI가 만든 코드의 structure, design 수정 작업을 한다.
- 만족스럽지 못하다. 켄트 백이 직접 고쳐야하는 작업이 많다. (아직 AI 역량 부족하다. 지금은 그런데 앞으로는 어떻게 될지 모르겠다.)
Extract : 정제
- 구현을 멈추고 큰 구조, 실수, 엣지케이스 등의 개선하는 단계
- AI 코딩 : AI가 만든 코드를 테스트, 엣지케이스, 수정 등의 개선 작업을 한다.
- 만족스럽지 못하다. 개발자가 관리, 감독 역할을 제대로 수행해야한다. (아직 AI 역량 부족하다.)

각 단계는 맥락에 따라 반복적으로 순환한다. 순환 주기는 맥락에 따라 하루일 수도, 3개월일 수도 1년일 수도 있다.

AI와 코딩할때 단계마다 자아를 3개로 분리 해보자

(프로이드 심리학에서 소개된 인간의 정신 구조의 3 요소를 적용해서 각 단계별로 AI 역할, 인간 역할 코딩 접근을 달리 해본다.)

Id(이드) - 쾌락만을 쫒는 빠른 코딩 아이디어, 실험 코딩
Ego(이고) - design, structure를 정리하는 코딩
Superego(슈퍼이고) - 정제, 테스트, 실수 해결하는 코딩

켄트 백 - 강의 슬라이드

결론

GenAI가 주는 도움을 적재적소로 활용하여 생산성을 극대화 시킨다.
시스템 구조, 디자인, 테스트, 엣지케이스 관리는 인간의 사고에 의존한다. (아직이다. 앞으로 어떻게 될지는 모르겠다.)
인간의 능력, AI 능력에 균형이 필요하다.
전적으로 AI에 의존하는 Vide Coding 보다 Augmented Coding으로 전환하자.

참고

Oreilly AI 코딩 세미나

https://www.oreilly.com/CodingwithAI/

(Augmented Coding)

(바이브코딩 vs 증강코딩) https://brunch.co.kr/@graypool/2363
(켄트 백 님의 증각 코딩 포스팅 ) https://tidyfirst.substack.com/?utm_source=navbar&utm_medium=web
(토비의 스프링 토비 님의 증강코딩 포스팅) https://www.linkedin.com/pulse/%EC%BC%84%ED%8A%B8-%EB%B2%A1%EC%9D%98-augmented-coding-beyond-vibes-%EC%9A%94%EC%95%BD-%EB%B0%8F-%EC%B6%94%EA%B0%80-%EC%9D%98%EA%B2%AC-toby-lee-mcy8e/

(켄트 백님의 3X Thinker 개념에 대한 글과 발표)

눈 떠보니 레거시 (레거시에도 철학이 있는데 저희 서비스는 철학이 없어요. feat. 아키텍처)

sendkite — Sat, 5 Jul 2025 22:11:34 +0900

1. 배경

올해 내가 가장 관심 있었던 개발 관심사는 무엇이었을까.
최근 AI 컨텐츠가 물밀듯이 나오고 있는데, 뒤쳐지는 것은 아닌가 걱정되어 회고 해보니
아키텍처에 앞도적으로 많은 관심과 시간을 소비했다.
아키텍처에 대해 공부를 한 이유와 지난 7개월의 인사이트를 남겨본다.

빠르게 훑어 읽어본 아키텍처 서적

2. 아키텍처란?

아키텍처는 시스템의 토대이자, 팀의 나침반이며, 미래를 여는 설계 언어다.

무릇, 소프트웨어에는 시스템적으로 구조적인 형태가 있다.
이러한 구조적 형태를 아키텍처라 하며 아키텍처는 ‘어떤 품질 속성’을 목표한다.
품질 속성에는 성능, 테스트 가능성, 확장성, 재사용성, 유지보수성, 적응력 같은 것이 있다.
모든 품질을 만족하는 은총알은 없다. 상황에 맞는 trade off만이 있을 뿐이다.
한번 정해진 아키텍처는 프로덕트 전반의 코드 배치, 팀 협업 등 모든 개발 영역에 큰 영향을 미친다.
아키텍처에는 지켜야하는 제약 조건이 따른다. (ex. 계층형 아키텍처는 계층끼리 단방향 의존, 하향식 의존을 따른다, MSA에서 프론트 N개 직업 연결하지 않는다..). 제약이 지켜지지 않으면 품질 속성을 잃을 수 있다.
아키텍처 변경은 큰 비용이 필요하다,

잘 정돈된 아키텍처는 잘 정돈된 도로 같은 것 아닐까

클린 아키텍처(엉클밥) - 아키텍처의 의미

3. 망가진 아키텍처 (큰 진흙 공 패턴)

“레거시에도 철학이 있는데 저희 서비스는 철학이 없어요.” - 동료 개발자 김00님

그런데, 스타트업 환경에서 일해보면 이러한 아키텍처가 무너져있는 상황을 마주한다.
- 제약 조건을 위반하여 아키텍처의 품질 속성을 잃어버린 단점만 남은 아키텍처
- 의미를 알 수 없는 모듈/컴포넌트 분리, 경계 짓지 않은 강결합 코드
이러한 망가진 아키텍처를 큰 진흙 공 패턴(https://blog.codinghorror.com/the-big-ball-of-mud-and-other-architectural-disasters/)이라 부르며, 재앙이라고도 불린다.
- 재앙 인 이유는 개발자의 생산성 하락 (투입 시간 대비 낮은 퍼포먼스)
- 개발자의 심리적인 자존감 하락 (이직하고 싶게 만든다)
- 모든 개발 업무를 노동 집약적으로 탈바꿈

망가진 아키텍처는 이런 모습 아닐까

내가 경험한 프로젝트도 예외가 아니다.
- 아키텍처에 제약이나, 목표하는 품질 속성이 없었고 이미 아키텍처로 부를 수 없는 상황이었다.
- 기능 개발할때 평균 1.5배-2배는 더 일하게 만들었다.

4. 왜 아키텍처가 망가질까

사실 아키텍처가 망가지는 것은 너무 쉽다.
친절하게 아키텍처 설계 의도, 철학을 공유해주는 시니어는 존재하지 않았다.

1-2년 후에 시니어는 이직하고, 혼자 남은 주니어는 이해 없이 일정에 쫒겨 기능을 찍어낸다.
몇년 지나고 보니 프로덕트는 ‘너무 급하게 만들어서’, ‘잘 모를때 만들어서’ 레거시가 되어 있다.
레거시를 만든 직원은 다른 프로젝트로 차출 되어 사라진다.

아키텍처가 망가지는 이유
- 지금은 이상해도 과거에는 최선의 아키텍처인 경우가 있다.
  - 서비스, SW, 조직의 성장으로 특이점이 넘어 기술부채가 된 경우
- 속도가 모든 것을 이길 때
  - 전략 없이 당장의 기능 출시만 이어가서 방향 설정을 하지 못한 경우
- 너무 빠른 요구사항/정책 변경
  - 화면 개편, 정책 개편
- 사람이 너무 자주 바뀌는 경우
  - 처음 만든 사람이 떠난 뒤에 설계 의도 단절
  - 잦은 이직
  - 외주 사용 (외주는 회사의 장기 설계 계획을 알 수 없고, 관심도 없다.)
- 개발자의 경험 부족, 리소스 제한
  - 팀 구성원 전체 이해도 높지 못하면 순식간에 망가진다.
  - 팀의 평균 숙련도가 중요하다.
- 설계 원칙, 철학은 생략하고 “기능이 되게 하는 것”만 집중

개발자에서 아키텍트로 - 아키텍처 설계는 팀 활동이 되야한다.

5. 망가진 아키텍처를 고치는 법

결국 망가진 아키텍처가 가져오는 고통은 사업팀, 운영팀도 아닌 ‘개발팀’만 느낀다.
코드를 짜는 개발팀이 코드 방향을 결정하는 최종 권한을 가지고 있다.
내가 고치려고 해본 노력들을 작성해 본다.

사전조건

주어진 업무를 쳐내면서 팀 동료들의 충분한 신뢰를 확보한 상황

1) 공통 개념의 부재 매우기

Object Oriented(객체지향설계), DDD(Domain Driven Design) 개념 전파하기
- 추상화, 주요 관심사, 공통의 디자인 재료가 된다.
- 코드를 작성에 옳고/그름의 기준으로 동작하는 정신 모델로 OOP와 DDD를 선택한다. (이래야 시스템 디자인 이야기를 리뷰에서 할 수 있다.)
- 객체지향, DDD 주제로 스터디를 만들어서 조용하게 스며들게 한다. (같이 스터디 하신 분들은 모르셨겠지만, 다 계획이 있었다...)

팀원 다같이 외부 세미나를 수강

2023년, 2025년 객체지향 사내스터디 주도

2) 팀이 공통적으로 가지고 있어야할 규칙을 만든다.

이렇게하면 이러이러해서 안좋다고 한 글이 있던데(글 첨부) 이번에 이러이러하게 해보면 어떨까요? 로 제안하듯이 코드 리뷰 형태로 스며들게 한다.
동의를 얻어 적용된 것은 문서로 정리해서, ‘문서로 한번 만들어 봤어요!’ 라고 말하여 코드 리뷰 규칙으로 박제한다.

규칙 예시.. 코드리뷰할때 위반 발생하면 링크 재사용

3) 제약 조건 강제화

경계 조건 강제화
- ArchUnit으로 의존 방향 강제화
- Spring Modulith 적용
- SonarCube, Linter 기능 사용
- 언어 접근자 활용
package by feature 전략으로 패키지 구성하여 코드 캡슐화

만들면서 배우는 클린 아키텍처 - ❌ 좋지 않은 패키지 구조 - 작은 프로젝트에 적합

만들면서 배우는 클린 아키텍처 - ✅ 가독성 좋은 패키지 구조

4) 벤치마킹 (다른 회사는 어떻게 접근하는지 참고)

많은 영감을 준 네이버 쇼핑의 개선 사례
- 시니어의 대규모 엔터프라이즈 시스템 개선 경험기 (https://www.youtube.com/watch?v=UwAoUshVpgM&t=1s)
- 주니어의 대규모 엔터프라이즈 시스템 개선 경험기 (https://www.youtube.com/watch?v=u_y6UGzOPUk)
라인 개선 사례 (https://techblog.lycorp.co.jp/ko/techniques-for-improving-code-quality-list)
올리브영 개선 사례 (https://oliveyoung.tech/2025-01-24/store-service-journey-1/)

결론

아마 망가진 아키텍처의 경험이 너무 좋지 못해서, 올바른 아키텍처에 대한 열망이 컸던거 같다.
- (요즘은 팀장님의 아키텍처 설계를 보며 아키텍처의 힘을 다시금 느낀다. 참 감사하다)
아키텍처 제약 사항을 꼭 지키자.
팀이 공유하는 규칙이 생기고 익숙해지는 것이 함께 성장하는 것 아닐까. (같이 지키자)
일터(코드베이스)가 원하는 방향으로 가고 있다는 점에서 스스로의 만족이 가장 크다.
계층형 아키텍처은 3계층, 4계층, 완화된 아키텍처 등 같이 변경돤 종류가 있다. (https://yeoon.tistory.com/197)

스프링캠프 2025 후기

sendkite — Sat, 28 Jun 2025 19:08:08 +0900

2023년, 2024년에 이어 2025년에도 스프링캠프에 다녀왔다.

3년 연속으로 참석하게 된 셈이다. (발표 자료 -> https://github.com/springcamp/presentations/tree/main/SpringCamp-2025-Presentations)

2023년에는 첫 개발 오프라인 컨퍼런스라는 설레임으로,

2024년에는 기술적인 갈증으로,

그리고 2025년에는 오로지 ‘동기부여’를 위해 참석했다.

0. 현장 분위기

올해 스프링캠프는 10주년을 맞은 만큼 뜻깊은 행사였다.
그래서였을까, 무려 13명이 내가 평소에 링크드인이나 트위터로 팔로우하던 분들이었고, 덕분에 마치 팬사인회에 가는 마음으로 행사장을 찾게 되었다.

3월 스프링캠프 모집 공고

올해는 예년과 달리 인프런에서 선착순이 아닌 추첨 방식으로 참가자를 모집했다. (비용은 4만원으로 비싸졌다.)
인프런에서 연차나 성비 등을 고려해 추첨한 덕분인지, 여자 개발자나 시니어로 보이시는 분들의 비율이 늘었다. 그래도 압도적으로 주니어가 많았다.
KSUG 가을 세미나 또는 김영한의 50만 기념 세미나와 같은 패널 토크 형태의 발표가 3시간이나 생겼다.
- 미리 시전 질문을 받아서 해당 주제로 토론하는 형태 (팟캐스트 처럼)
- 취지는 참 좋았지만, 아쉬운 점도 있었다. 참가자 대부분이 주니어 개발자였던 탓인지, 질문의 깊이가 주니어에 맞춰진 느낌이 강해서 아쉬웠다.
채용부스가 전멸했다. 항상 채용 상담과 같은 부스가 있었는데 올해는 찾아 볼 수 없었다. 경제가 진짜 힘든것 같다.
- 올리브영, Flex, 카카오뱅크, AWS가 있었으나 채용보다는 회사 홍보만 진행
코틀린 코너가 없어졌다. 대신 발표 내용 예제 코드가 다 코틀린이었다. (내가 들었던 세션은 그랬다)

드디어 이상한 손선풍기 대신에 힙한 굿즈를 나눠주는구나..

flex 부스에서 나눠준 아메리카노.. 센스

본론으로 발표 내용 정리해본다.

1. 난 spring에서 ml 서빙을 해봤어요 (김수원 님 / Sionic ai)

네이버 ML, 토스 ML 엔지니어 출신, ML 전문 회사 CTO의 JVM 환경에서 ML 서빙 경험 공유
이미 Spring으로 ML 서빙하며 백엔드 서비스 운영 중
ML을 JVM에서 서빙하는 이유, 어떻게 할 수 있는지를 공유
Python이 중심인 ML 서빙 환경
- Python을 빼놓고 ML을 이야기 할 수 없다.
- 모델을 만드는 도구가 python 베이스이기 때문이다. e.g) LangChain, PyTorch, TensorFlow, Llamalndex . . .
- 그러나 Python으로 대규모 프로덕션 운영 하는데 어려움이 있다.
  - python은 GIL(Global Interpreter Lock) 영향으로 성능, 병렬처리 한계가 있다.
  - 패키지 및 환경 관리가 복잡하다. (라이브러리 업데이트 직접 관리)
  - 운영 한계 (타입 안정성 문제)
  - 물론 Python으로 운영 가능은 하지만, 난이도가 높다.
Python 말고 다른 대안은 없을까?
- ML 추론 서버/엔진 사용 방법이 있다.
  - 엔진종류
    - 엔비디아 트라이톤
    - vLLM
    - AWS
    - OCI
  - 그러나 구축 및 운영 복잡성, 벤터 종속성 및 기술 지원 한계가 분명하다.
  - 리소스 및 비용 부담, 문제가 생겼을때 Rust, Go를 뜯어 고쳐야하는 비용
- JVM 기반으로 ML 서빙하는 방법
  - JVM에서 ML 서빙 지원하는 라이브러리
    - ONNX (저수준 - 최적화 필요)
    - TensorFlow (저수준 - 최적화 필요)
    - DJL (고수준 - 추상화 잘되서 최적화 필요 없음)
  - DJL
    - Java 개발자들의 ML 진입 장벽은 Python, AI을 모른다는 것이다.
      - Python 언어, 아키텍처, 라이브러리, 추론/서빙, GPU/환경에 대한 이해 선행되어야 한다.
    - 그러나 DJL은 "Python, AI/ML을 몰라도 ML 서빙을 할 수 있게 만든다"는 슬로건으로 Java만 알아도 사용 가능하다.
    - 다양한 모델 지원함
      - 자체 모델 지원
      - Hugging Face(전세계 모델러들의 오픈소스 허브)와 연결 되어 오픈소스 모델 부분적으로 사용 가능
    - 예시 (리뷰 노출, 판매자 패널티)
    - DJL은 Netflex에서도 활용하고 있다. (https://aws.amazon.com/blogs/opensource/how-netflix-uses-deep-java-library-djl-for-distributed-deep-learning-inference-in-real-time/)

JVM에서 ML 서빙의 한계도 분명하다.
- CPU 48코어 사용
- 메모리 몇 백기가 할당하기도 함
- 하드웨어 성능을 0.000001%까지 쥐어짜야한다.
- DJL은 저수준 제어가 어렵다.
ONNX, TensorFlow를 사용하면 하드웨어 극한으로 쓸 수 있다.
- GPU 설정
- GPU 병렬처리 직접 설정
- 동적 배치처리
- Zero-copy 메모리 최적화
- 모델 안 최적화
  - 모델 튜닝, 코사인 유사도 빠르게 동작하게 튜닝 가능
  - 1000만개 문서 1s 이하

끝내며,, JVM 서빙하는 것이 정답일까?

단점도 많다.
- (모델 구조 직접 만들어야하고, 추론 코드 직접 짜야하는 것)
- 하드웨어 튜닝
- Spring AI 라이브러리의 미성숙도 (이제 1.0이 출시한 것이 지난달)
각자의 환경, 해야하는 테스크에 맞게 환경 구성하고 서빙하면 좋을 것 같다.
반드시 python을 사용하는 경우가 있으며 python 사용은 필수 불가결하다.
- ML 테스크 중 라이브러리를 써야하는데, python에만 있을 경우, 최신성을 반영 해야하는 경우 (java는 업데이트가 느리다.)

2. Talk 1 - 개발자 커뮤니티 (패널 토크)

(박용권 님 (당근), 김지헌 님(컬리), 이상훈 님(야놀자))

아래와 같은 주제로 50분간 토론했다.

홀로 선 개발자의 고민, 커뮤니티의 필요성
커뮤니티에 발을 들이고 인연을 연결하는 방법
커뮤니티 속에서 무엇을 얻을 수 있을까
커뮤니티를 만들어가는 입장에서 지속가능한 커뮤니티는 뭐가 있을까

결론은, 개인이 뚜렷한 목적을 가지고 스터디나 커뮤니티 활동을 하고,

커뮤니티를 통해 다른 회사 분위기 파악, 본인 PR이 가능하며, 일단 용기내서 말을 걸어보자

3. Talk 2 - 함께 성장하기 (패널 토크)

(박재성(우아한형제들, Nextstep 캡틴), 변정훈(당근), 이경일(네이버))

함께 성장 한다는 것은 무엇일까?
- 구성원의 성과 == 나의 성과 인 것
- 그 조직이 가지고 있는 Domain Knowlege 전파 (조직만의 도메인 지식의 전파)
- 과거 개발자는 탁월한 기술적으로 신기술 빠르게 적용하는 사람이었는데, AI가 등장하고 도메인의 시대가 온 것 같다. AI가 대체 할 수 없는 Domain쪽에 관심을 가지고 성장해보자.
좋은 개발 문화란?
- 문제 없는 조직은 이 세상에 존재하지 않는다. 빅테크 여러곳 다녀봐도 실망스러운 팀, 조직이 많았다.
  - 나 조직 분위기 탓하지 말고, 좋지 않다면 바꾸면서 성장할 기회다.
  - 바꾸고, 기여하면서 성장할 수 있다. 도망가려하지 말고 변화 시켜보려는 마인드가 필요하다.
  - 예를 들어 IT 개발자는 staff 직군인 회사에 있으며 해볼 수 있는 것 찾아서 해결 해보았다.
    - 배포 - FTP로 배포하던 것 배포 시스템 작성
    - 캐싱 시스템 제작
    - 관리자 배포 시스템 작성
좋은 문화를 만들기 위해서는?
- 변화를 만들고 도입하기 위해서는 신뢰 자산이 필요하다.
  - 빠른 도입은 불가하다.
  - 6개월 이상 팀원 신뢰를 만들고, 천천히 작은 성공을 반복한다.
  - 조직 상황, 서비스 특성을 고려해야한다.
- 좋은 문화, 변화는 반드시 회사 성과로 이어져야한다.
심리적 안정감이 있는 조직 이란?
- 심리적 안정감이 있는 조직은 전적으로 리더에게 달렸다.
  - 비난 받지 않는 환경, 의견 개진 쉬운 환경 조성
  - 보통 리더가 되고, 리더가 되는 준비를 하는데 그러지 마라
  - 주니어 한계를 두지 말아라 코딩 외에 소프트 스킬, 코칭 역량 쌓아가는 노력을 해야한다.
  - 스터디가 활발하고 지식 공유가 잘되는 조직 왜 안될까?
  - 그런 팀/문화 만드는 것은 엄청 힘들다. 리더가 문화를 만들고, 동기부여, 변화를 만들어야한다.
  - 문화, 동기부여, 지식 전파와 같은 일은 AI 시대에 더욱 중요하다. (대체 될 수 없다)
- 심리적 안정감이 없는 조직
  - 항상 노트북을 들고 다녀야한다.
  - 휴가만 가면 3년간 쓰지 않았던 api가 호출된다.
  - ‘나’ 말고는 대응할 수 있는 사람이 없는 것
    - 공유가 이루어지지 않는 것
- 심리적으로 안정감이 있는 조직
  - 노트북을 안들고 다녀도 된다.
  - 장애가 나도 ‘아 이거 다음에 할께요. 천천히 하면 되요’가 되는 환경
동료 피드백하는 좋은 방법이 있다면?
- 피드백을 팀원들과 원온원, 회고 문화를 가진다.
  - 개선점을 찾고 액션 플랜을 만드는 것 외로 일하면서 느낀 감정적 피드백 교류 환경이 필요하다.
- 재택으로 온라인상 커멘트로만 피드백이 이루어지니, 감정이 전달되지 않아서 아쉬웠다.
- 코드 리뷰가 힘들 정도로 규모가 크다면 설계도를 만들고, 대면으로 공유/피드백 한다.
  - tip )Code Rabbit
    - 다이어그램, 호출 관계 그려줌
- 코드 리뷰에서 부정적인 내용 피드백 하는 방법은?
  - 코드상의 리뷰 : (쿠션어 사용하기) 꼭 수정하지 않아도 되는데요, 꼭 바꾸지지 않아도 되는데요..
    - 최종 결정은 구현자가 한다.
  - 대면 리뷰 - 칭찬으로 시작해서, 다 좋은데 이것만 좀 바꿔볼 수 없을까요?
  - 많은 개발자가 내가 짠 코드와 나를 일치화 하는 경향이 있다. 그러면 안된다.
    - "널 비난 하는 것은 아니고, 나는 옛날에 이런식으로 해보니까 좋았다." 같이 존중하는 감정이 전달되야한다.

4. 실전! MSA 트랜잭션 개발 가이드 (김용욱 님 / 삼성 SDS)

미리 설계를 해보는 것이 좋다. 트랜잭션 가이드를 소개하고 우리 상황에 필요한 것들을 찾아보자.

실무에 필요한 것은 모든 것이 아닌 일부다.

트랜잭션 개발 가이드
- 데이터 오너십 원칙 (서비스 간 쓰기 - 이 데이터는 저만 변경합니다! 를 정한다. - 속성별로 나눌수도 있다)
- 실패한 트랜잭션 처리
  - 취소/재시도
  - privot transaction (from SAGA)
  - saga transaction
- 트랜잭션 격리성 보완
  - Eventual Consistency
  - Semantic Lock (업무적인 의미의 중간 상태 값 추가)
  - TCC (Try, Confirm, Cancel) 커밋의 단계를 나눠서 try commit, confirm commit, try에 실패하면 cancel
  - Offline Lock
- 신뢰할 수 있는 트랜잭션 구현
  - API/Event
  - 진짜 실패와, 가짜 실패 구분
  - 중복 실행, 순서 꼬임 처리

Talk 3 - 기술 Talk (설계)

(향로님, 조영호님, 안영회님)

객체에게 책임을 부여한다는 것은?
- 객체를 지우고 Context 부터 생각해야한다.
- 요구사항이 주어지면 연극 시나리오를 작성하는 것 처럼, 필요한 행동, 상호작용을 떠올리고 동적인 관점에서 설계한다.
- 행동부터 생각하고 객체를 식별하자.
JPA Entity vs Domain 나눠야할까?
- 모든 경우에 좋은 것은 없다. trade off만 있을 뿐이다.
- JPA Entity는 데이터를 처리하고, Domain은 비즈니스 로직을 처리한다.
- 데이터 변경 속도와 도메인 변경 속도가 동일하다면 두개를 나눌 필요가 없다.
  - ex) shared DB가 존재하고 우리팀이 컨트롤 하지 못하는 상황과 같이 데이터 변경 속도와 비즈니스 변경 속도가 다를때 분리하면 좋다.
- 변경 속도를 알 수 없다면 합쳐서 개발하고, 나중에 나눠도 늦지 않다.
- 나누는 것이 초반 결정이 아니었으면 좋겠다. (효율 떨어짐)
OOP(객체지향), FP(함수형프로그래밍) Next는 무엇일가요?
- Agentic AI 라고 생각한다. 미국 IT 투자금 절반이 흘러들어가고 있다.
- Agentic AI 또한 modularity 분할하며 합치는 것이 핵심
확장성 vs 오버엔지니어링
- 사업적으로 10%만 성공한다. 너무 큰 확장성은 좋지 않다.
- 문제의 복잡도에서 가장 단순한 전략을 선택한다. (나중에 이해하기 쉽게)
- 변경이 진짜 이루어지는지 알수가 없다. 지금 가지고 있는 지식에서 가장 단순한 해결책을 선택한다.
빠르게 만들어야한다, 성과 내야한다는 논리로, 레거시 코드를 반복하는 상황에서 설득하는 방법이 있다면?
- 설득하지 않고 바꾸고 성과를 만들면 알아서 느끼더라, 가장 좋은 설득 방법은 보여주는 것이다.
설계 철학 vs 조직의 제약
- 이분법은 존재하지 않는다. 회사 돈을 받고 일하는 이상 회사가 옳다.
- 설계는 팀의 결정이다. 팀의 전체 퍼포먼스가 좋아지면 정답이다.
- 좋은 설계는 협업하기 좋은 코드다.
- 남 탓하면 안된다. 당신은 뭐든 할 수 있다. 당신의 코드가 훨씬 많아져서 기존 코드를 잠식하면 된다. (XP)
- 설계는 나를 위한 것이 아니다. 다른 사람이 내가 짠 코드를 고칠때, 사전 지식이 없을때 읽기 좋은 코드를 위한 것이다.

레일웨이 지향 프로그래밍과 스프링 (이선협 / 마플코퍼레이션)

레일웨이지향 프로그래밍 2014년 등장
개발 방법론은 사고와 기술로 바라볼 수 있다.
- 사고 : 어떻게 소프트웨어를 바라볼지
- 기술 : 실천 방법
레일웨이지향의 사고는 소프트웨어를 성공과 실패로 바라보는 것이다.

성공과 실패(예외)에 대한 처리 중심으로 코드를 작성한다.
기술 : Monad라는 개념과 함수형 프로그래밍을 통해 코드를 작성한다.

Spring Data Redis 설정(1) - RedisTemplate 설정

sendkite — Sun, 27 Apr 2025 16:57:14 +0900

Redis 설정 관련하여 아키텍처, 직렬화/역직렬화에 대한 기록

1. Redis 아키텍처

설정에 앞서 아키텍처에 따라 Connection 설정 방법에 차이가 있어 아키텍처를 살펴본다.
Redis를 사용하는 아키텍처는 크게 4가지가 있다. (참고 - https://docs.spring.io/spring-data/redis/reference/redis/connection-modes.html)

1) StandAlone

1대의 Redis 서버

2) Redis Replication (master/slave 구조)

master (읽기/쓰기), slave (master 데이터 복사 - 읽기전용)로 구성
master → slave 복사시간이 1-2초 소요되는 단점이라 잘 쓰이지 않는 구조이다.
redis cluster를 잘 운영하지 못할때 사용한다.

master, slave 구조

3) Redis Sentinel

master/replica 구조에서 primary 장애 시 자동 장애 조치(auto failover)를 수행 구조
sentinel 노드 과반 수 이상이 master 장애를 감지하면 slave 하나를 master로 승격
- 지속적으로 모티터링/감시만 하는 node(sentinel)를 따로 관리해줘야한다.
  - client가 올바른 노드를 찾을 수 있도록 도움
  - 최소 3개 이상의 노드를 권장
  - 감시 역할은 Redis와 동일한 노드에 구성해도 되고, 별로로 구성해도 됨
일반적으로 단일 master로 구성함,
- master 하나가 모든 쓰기 작업을 처리해야하는 단점 있음
- 대규모 쓰기 작업시 병목 발생
- Slave에 복제되는 Latency 증가

Sentinel

4) Redis Cluster

최소 3대의 마스터 노드 필요, 각 노드 당 최소 Slave node 필요함
데이터는 16384개 슬롯으로 나뉘어 특정 Master에 할당
모든 데이터는 master 단위로 sharding되고, slave 단위로 복제됨 (즉 슬롯으로 sharding함)
설정과 관리가 매우 복잡하고 특정 작업(ex - 다중키 작업)은 일부 제한이 있을 수 있음

Cluster 구조

application.yml에서 어떤 Connection mode인지에 따라서 다른 환경 변수를 사용할 수 있다.

Spring Data Redis에서 제공하는 환경변수

3. Redis 설정

OMS는 본격적으로 Redis를 활용하는 구조가 아니기 때문에 StandAlone으로 설정을 진행한다.

Redis 접속 설정

Lettue, Jedis 선택지가 있으나 Lettue가 성능상 더 좋다.

@Configuration
class RedisConfig {
    @Bean
    fun connectionFactory(): LettuceConnectionFactory {
        val redisConfig = RedisStandaloneConfiguration("localhost", 6379)

        val clientConfig =
            LettuceClientConfiguration
                .builder()
                .commandTimeout(Duration.ofSeconds(30)) // 명령 실행 타임아웃
                .clientOptions(
                    ClientOptions
                        .builder()
                        .autoReconnect(true)  // 자동 재연결
                        .socketOptions(
                            SocketOptions
                                .builder()
                                .connectTimeout(Duration.ofSeconds(5)) // 네트워크 연결 타임아웃
                                .build(),
                        ).disconnectedBehavior(ClientOptions.DisconnectedBehavior.REJECT_COMMANDS) // // 연결 끊겼을 때 처리 방식
                        .build(),
                )
                .build()

        return LettuceConnectionFactory(redisConfig, clientConfig)
    }
 }

disconnectedBehavior 옵션 다른 선택지
- DEFAULT: 요청을 큐에 쌓았다가 나중에 처리 (❗️주의: 메모리 소비 증가 가능)
- REJECT_COMMANDS: 연결이 없으면 명령을 즉시 거부 (→ 예외 발생)
- ACCEPT_COMMANDS: 연결이 끊겨도 명령을 계속 받아서 큐에 저장

RedisTemplate 설정

Key-Value 구조가 <String, String> 이라면 StringRedisTemplate를 사용한다.
라이브러리 자체에서 최적화 설정이 되어 있기 때문이다.

 @Bean("stringRedisTemplate")
 fun stringRedisTemplate(
     @Qualifier("connectionFactory") connectionFactory: LettuceConnectionFactory,
 ): StringRedisTemplate = StringRedisTemplate(connectionFactory)

라이브러리 내부 직렬화 최적화

1) RedisTemplate<String, Object> - 가장 기본적인 사용 방법

아래와 같이 String은 StringRedisSerializer로, Object는 GenericJackson2JsonRedisSerializer로 객체를 JSON 형태로 직렬화하여 저장한다.

   @Bean
   public RedisTemplate<String, Object> redisTemplate() {
       RedisTemplate<String, Object> template = new RedisTemplate<>();
       template.setConnectionFactory(redisConnectionFactory());

       // 직렬화 설정
       template.setKeySerializer(new StringRedisSerializer());
       template.setHashKeySerializer(new StringRedisSerializer());
       template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
       template.setValueSerializer(new GenericJackson2JsonRedisSerializer());

       return template;
   }

이 방식의 단점
- Json 객체를 그대로 바이트 배열로 변환하여 저장하므로, 저장 공간이 많이 사용됨
- 설정에 따라 직렬화 시에 클래스 정보가 포함되어 여러 문제가 생길 수 있음
- ObjectMapper를 사용하여 직렬화를 시도함
- 참고 - Spring Redis 직렬화의 한계 / https://mangkyu.tistory.com/402
Redis에 저장 데이터가 크다면 직접 직렬화를 구현하여 압축 저장하는 방법도 있다.
- https://mangkyu.tistory.com/411

2) RedisTemplate<String, ByteArray>로 구현하고 ObjectMapper를 커스텀하는 방식

Redis에 byteArray로 관리하고, ObjectMapper를 직접 구현하여 저장 포멧을 최적화한다. (smile, avro..)
- (참고 https://jsonobject.tistory.com/390- )

@Bean("objectRedisTemplate")
fun objectRedisTemplate(
    @Qualifier("connectionFactory") connectionFactory: LettuceConnectionFactory,
): RedisTemplate<String, ByteArray> {
    val redisTemplate = RedisTemplate<String, ByteArray>().apply {
        keySerializer = StringRedisSerializer()
        hashKeySerializer = StringRedisSerializer()
        setConnectionFactory(connectionFactory)
    }
    return redisTemplate
}

@Bean("redisObjectMapper")
fun redisObjectMapper(): ObjectMapper {
    return SmileMapper().registerModules(JavaTimeModule())
        .configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, true)
        .configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false)
        .configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false)
        .setSerializationInclusion(JsonInclude.Include.ALWAYS)
        .disable(MapperFeature.USE_ANNOTATIONS)
}

smile로 저장함으로 JSON 문자열 대비 2/3 절약된 크기 저장
전반적인 고성능
단점으로는 ObjecMapper 커스텀 구현 및 redis 저장소에서 데이터 읽기가 불편할 수 있다.