본문으로 건너뛰기

프롬프트 체이닝은 항상 정답일까?

· 약 10분
Ryukato
BackEnd Software Developer

LLM을 활용하여 텍스트에서 키워드를 추출하거나 정보를 구조화할 때, 막연히 **프롬프트 체이닝(Prompt Chaining)**이 더 좋은 결과를 만들어줄 것이라 기대보다는 테스트를 통해 단일 프롬프트(single prompt) 방식과 비교 분석하여 어떤 방법이 자신의 상황에 더 적합한지 선택하는 것이 좋을 것으로 생각됩니다.


쿠팡 일용직 퇴직금 미지급 사태를 보며

· 약 16분
Ryukato
BackEnd Software Developer

쿠팡 풀필먼트서비스(CFS)에서 불거진 퇴직금 미지급 사태는 표면적으로는 “퇴직금을 주지 않았다”는 문제로 보일 수 있다.
하지만 조금만 더 들여다보면, 단순히 돈을 떼먹은 사건이 아니라 취업규칙을 악의적으로 개정하고, 그 사실을 근로자들에게 알리지도 않은 구조적 문제라는 점에서 심각성이 훨씬 크다.


RAG Embedding server 구현해보기

· 약 7분
Ryukato
BackEnd Software Developer

이 포스팅에서는 직접 구현한 FastAPI 기반 RAG Embedding Server의 구조, 동작 방식, 설계 의도 등을 설명합니다.
해당 서버는 Qdrant를 벡터 스토어로 사용하며, 테스트 데이터를 기반으로 한 임베딩을 비동기 방식으로 처리합니다.

전체 코드는 rag_embedding_server 에서 확인 가능합니다.

Airflow에서의 heavy data 처리에 대한 단게적 개선

· 약 8분
Ryukato
BackEnd Software Developer

외부 데이터 소스로부터 가져온 raw-data들에 대해 중복 데이터 제거 및 데이터 셋간의 관계 설정 및 데이터 클랜징 처리등의 것들을 하면서 대용량 데이터의 처리에 대해 단계적으로 개선한 내용을 간략히 정리하여 공유 합니다. 본 글의 내용은 성능 병목을 개선하기 위한 단계별 전략을 일반적인 케이스로 정리한 가이드입니다. 각 단계는 실제로 성능 향상에 효과적인 접근법을 순차적으로 나열한 것입니다.

모 기업의 스톡옵션 가치 무효화에 대한 단상

· 약 8분
Ryukato
BackEnd Software Developer

최근 업계에서 주목받는 한 기업이, 직원들에게 부여했던 스톡옵션의 가치를 ‘0원’으로 평가해 논란이 되고 있다.해당 기업은 차액보상형 스톡옵션(* 행사시점 주가와 행사가격의 차이만큼 현금으로 보상하는 방식)을 운영하고 있었던 것으로 보이며, 내부적으로 시가를 0원으로 산정해 실질 보상이 없는 구조가 되어버렸다. 그러나 해당 기업의 스톡옵션에 대한 평가 방식이 정말 합당한 것인지 의문이 든다. 이슈의 내용을 정리한 기사에 따르면 해당 기업은 시리즈 B-1 투자 유치를 하여, 기업 가치 5,000억원정도로 평가 받고, 이에 따라 주당 가격 또한 15만 208원정도로 평가 받았다고 한다. 해당 기업은 다음과 같은 사유로 ‘0원’의 시가 평가를 정당화했다고 주장한다:

  • 특정인 간 일회성 거래
  • 전체 발행주식 총수의 2%에 불과한 소규모 거래
  • 최신 감사보고서 기준, 상속세 및 증여법 상 평가액이 0원이라는 법률 자문

정말 합당한 것일까?

Entity vs DTO 논쟁의 본질: 순수성인가, 실용성인가?

· 약 12분
Ryukato
BackEnd Software Developer

소프트웨어 설계에서 자주 반복되는 논쟁 중 하나는 바로 Entity를 Presentation Layer에서 사용하는 것이 적절한가? 하는 질문이다. 이 논쟁은 단순히 기술적인 분리가 옳으냐를 넘어서, 실용성과 유지보수 비용, 협업의 복잡성, 그리고 조직적 일관성이라는 주제를 포함하고 있다.

이 글에서는 실용주의 관점에서 Entity와 DTO 사이의 경계를 바라보고, 그에 따른 trade-off를 분석하고자 한다.


About Sharding and MSA

· 약 13분
Ryukato
BackEnd Software Developer

🧭 서문

많은 팀과 조직이 데이터베이스의 성능 병목이나 대용량 처리 이슈에 직면했을 때, 가장 먼저 떠올리는 해결책 중 하나가 바로 **샤딩(Sharding)**입니다.
샤딩은 분명히 강력한 수평 확장 전략이지만, 그만큼 도입과 운영에 따르는 복잡도와 위험성도 큽니다.

특히, 샤딩은 단순한 기술적 기능이 아니라 전체 시스템 아키텍처에 영향을 주는 구조적 결정이기 때문에, 도입을 서두르기보다는 샤딩 없이 해결할 수 있는 방안들을 먼저 고려하고, 샤딩이 필요한 시점과 범위를 명확히 판단한 후에 적용하는 것이 바람직합니다.

이 글에서는 샤딩 도입 전 고려할 수 있는 단계, 샤딩의 적용 원칙, MSA 및 vertical slicing과의 관계, 그리고 궁극적으로 나노 서비스 아키텍처와 BFF 구조로의 확장까지 폭넓게 다뤄봅니다.


주 52시간 근무 시간 제도에대한 생각

· 약 15분
Ryukato
BackEnd Software Developer

최근 링크드인 등 SNS에서는 주 52시간 근무제에 대해 부정적인 의견이나, 근무 시간 제도의 자율화를 주장하는 글들을 자주 접하게 된다. 이들 중 상당수는 “지인과 대화해보니 한국 제도는 너무 경직돼 있다”, “회사를 차리면 더 유연한 근로를 허용하겠다”, “젊을 때는 바짝 일하고 나중에 워라밸을 챙기면 된다”는 식의 경험적 혹은 이상적인 주장을 바탕으로 하고 있다.

그러나 이러한 담론에서는 주 52시간 제도가 만들어진 배경이나, 제도의 존재 목적, 사회적 완화 시 발생 가능한 구조적 비용 등에 대한 깊이 있는 고민은 거의 보이지 않는다. 더 나아가, 제도 때문에 기업 성장이 저해된다는 주장조차도 구체적인 데이터나 논리적 근거 없이 반복되곤 한다.

그렇다면 이러한 주장들을 단순한 일부의 개인 의견으로 치부해야만 할까? 솔직히 이 지점에서 나 또한 회의감과 함께 고민이 생긴다. 이 글은 그 고민에서 출발한다.

mTLS Overview

· 약 12분
Ryukato
BackEnd Software Developer

mTLS는 mutual TLS의 약자로, 서버와 클라이언트가 서로를 인증하는 TLS 통신 방식입니다.
일반 HTTPS보다 더 높은 수준의 보안 통신이 요구되는 핀테크, 헬스케어, 마이크로서비스 환경에서 널리 사용됩니다.