개발 일기

드링클리 프로젝트에서 멤버 회원가입 로직을 구현하는 과정에서 두 가지 주요 작업을 처리해야 했습니다. 첫 번째는 DB에 유저 정보를 저장하는 작업, 두 번째는 팀 Slack 채널에 회원가입 요청이 들어왔고 처리되었다는 정보를 전달하는 작업입니다. 처음에는 두 작업 모두 동기 방식으로 처리했지만, Slack 처리 부분은 반드시 동기적으로 처리할 필요가 없다고 판단하게 되었습니다. 이를 통해 성능을 개선할 수 있을 것이라 생각하여, Slack 처리 부분을 비동기 처리 방식으로 변경하기로 했습니다. 이 과정에서 ApplicationEventPublisher와 같은 비동기 처리 기법을 활용해 두 방식의 성능 차이를 비교해보기로 했습니다. 1.  단순 동기 처리 방식위 코드에서처럼 처음에는 회원가입 로직을 동기 ..

드링클리 프로젝트에서 모놀리틱에서 마이크로서비스로 전환하게 되면서 한 가지 의문이 발생했었습니다.기존 모놀리식 시스템에서는 단일 데이터베이스 내에서 모든 작업이 하나의 트랜잭션으로 묶여 원자성이 보장되었지만, 마이크로서비스 환경에서는 각 서비스가 독립적으로 트랜잭션을 가져가기 때문에 원자성이 깨졌고 해왔던것 처럼 처리했을때 일관성있게 관리하는데에 한계를 느꼈습니다.그래서 MSA와 같은 분산환경에서는 어떻게 트랜잭션을 관리하는지 알아보고자 블로그를 작성하게 됐고 이때 토스에서 올린 세미나를 참고했다. 토스ㅣSLASH 24 - 보상 트랜잭션으로 분산 환경에서도 안전하게 환전하기분산 트랜잭션이 필요한 이유?해당 예시에서 상황은 기존 Corebanking 시스템은 하나의 데이터베이스를 바라보고 있는 모놀리식 아..

드링클리 프로젝트에서 MSA로 전환하면서 Feign으로도 다 처리가능한데 왜 다들 Kafka 비동기 처리에 목숨을 거는건지 잘 이해가 되지 않아 정리하게 됐다.회원시스템 이벤트기반 아키텍처우선 Micro-Service Architecture 왜 필요한가?마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 자향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.이때 마이크로서비스 얘기가 나오면 Event-Driven Architecture가 나오는 이유 또한 이 이벤트 기반 아키텍처가 느슨한 결합을 돕기 때문이다. 왜 느슨한 결합이 필요한데?정보처리기사나 Software Engineering과목을 수강하면서 수도 없이 들은 Coupling 낮추기를 반복적으로 학습했었..

하나 금융 그룹에서 진행한 프로젝트에서 프롬프트 엔지니어링이 할 일이 있었어서 최적    화 기법들에 대해서 정리해보았다. 우선 프롬프트 엔지니어링이 뭘까?프롬프트 엔지니어링(Prompt Engineering)최근 약 3년동안 Chat GPT / BARD / LLaMA 그리고 최근에는 DeepSeek 까지 다양한 생성형 AI 모델들이 IT 시장에서 뜨가운 감자이다.프롬프트 엔지니어링은 위와 같은 대규모 언어 모델(Large Language Model, LLM)에서 원하는 결과를 얻기 위해 프롬프트를 공들여 만들고 최적화하는 과정이다.적절한 프롬프트의 설계는 LLM 성능을 크게 향상 시킬 수 있다고 한다. 그렇다면 프롬프트란 무엇일까? AI 모델에서 출력을 생성하기 위해 입력하는 텍스트 이다.프롬프트의 구..

Apache Kafka 공식 홈페이지에 들어가보면 설명이 있다.Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. 개인적으로는 distributed event streaming platform에 집중하면 좋을 것 같다. 왜 distributed인지는 Kafka의 구조를 찾아보니 감을 잡을 수 있었다.Kafka의 기본 구조Kafka의 전체적인 구조를 정리하면 다음과 같다.Kafka 클러스..

https://ai-back-end.tistory.com/143 [Spring Cloud] Spring Cloud Config Server - 1기존의 단일 프로젝트 멀티모듈 아키텍처에서는 GitHub Submodule을 사용하여 민감한 정보를 관리하고, 설정 파일이나 시크릿을 별도의 Private Repository로 분리하여 관리했다. 그러나 현재 마이크로서ai-back-end.tistory.com 이전 게시글에서 Spring Cloud Config Server가 뭐하는 놈이고 어떻게 구성되어있으며 어떻게 동작하는지 알아봤다.그런데 이때 Config Server를 이용하면 설정 정보들이 변경되어도 서버를 다시 빌드하지 않아도 된다는 장점이 있다고 했는데  /actuator/refresh를 통한 설정 ..

기존의 단일 프로젝트 멀티모듈 아키텍처에서는 GitHub Submodule을 사용하여 민감한 정보를 관리하고, 설정 파일이나 시크릿을 별도의 Private Repository로 분리하여 관리했다. 그러나 현재 마이크로서비스 아키텍처로의 이전 과정에서는 각 서비스마다 GitHub Submodule을 별도로 관리해야 하는 상황이 발생했다. 이로 인해 각 서버마다 서브모듈을 갱신하고 설정을 수정한 후 다시 빌드 및 배포하는 과정이 필요해져, 관리 오버헤드가 크게 커졌다.그래서 위의 문제를 해결하기위해 중앙 집중식으로 처리해줄 수 있는 Spring Cloud Config Server에 대해 정리해보게 됐다.Spring Cloud Config란?Spring Cloud Config는 분산 시스템에서 외부화된 설정 ..

기존에 단일 프로젝트의 멀티 모듈 아키텍처에서 인증·인가를 담당하는 auth 모듈을 구축했다.이때 해당 auth 모듈을 통해 각 api 모듈로 요청을 라우팅할 수 있으면 좋았겠지만, 단일 애플리케이션 내에서는 API Gateway 패턴을 적용할 수 없었고 결국, auth 모듈을 각 api 모듈에서 직접 의존하여 인증·인가를 처리하는 방식으로 구현해야 했다. 해당 방식은 어쨋든 인증·인가 로직을 하나의 모듈에서 처리하고, 라이브러리처럼 필요한 api 모듈에서 이를 의존하여 사용하는 형태였지만, 아키텍처적으로는 중앙 집중식으로 처리하는 API Gateway 패턴과는 차이가 있어 아쉬웠다. 그러나 이번에 Eureka 기반의 MSA 아키텍처를 구축하면서 Spring Cloud Gateway를 도입하게 되어 정리..