No, Limit

※ 자세한 솔루션 명칭과 기업 내부 정보는 제거하였습니다. 사내에서 반복되는 문의에 답하는 자동응답 봇을 만들었습니다. 기존 솔루션으로는 답을 우리가 손볼 수 없어 관련 팀의 부담이 계속 쌓였고, 틀린 답이 나가도 바로잡을 방법이 마땅치 않았습니다. 비용도 직접 만드는 편이 더 저렴하겠다는 판단이 더해져, 결국 직접 만들기로 했습니다. OpenAI API 및 RAG를 처음 경험하였습니다. 이 글은 봇을 완성한 결과보다, 검색과 프롬프트를 조정하며 무엇을 LLM에 맡기고 무엇을 코드로 막아야 하는지 배워간 과정을 정리한 기록입니다.코드는 틀리면 알려주기라도 한다시작하고 나서 가장 당황스러웠던 건, 이게 제가 알던 개발과 결이 달랐다는 점이었습니다. 적어도 제가 익숙했던 코드에는 오류를 발견할 장치가 있었습..

최근 운영 중인 Spring Boot 서비스에서 오전부터 메모리가 계속 오르다가 오후에 OOM으로 죽는 이슈를 겪었습니다.이번 글은 "무엇이 진짜 원인이었는지", "내가 어디서 헷갈렸는지", "다음엔 어떻게 막을지"를 정리한 기술 회고입니다.장애 요약항목내용현상09:00 메모리 상승 시작 → 14:00 OOM 종료환경Spring Boot, Java 17, G1 GC, Kubernetes핵심 결론단일 메모리 누수 1건이 아니라, 대형 byte[] 처리 + 배치성 부하 + GC 회수 한계가 겹친 누적형 메모리 압력 이슈타임라인09:00 — 메모리 상승 시작오전~점심 — 완만하지만 지속 우상향14:00 — Pod OOM (프로세스 종료)이 패턴은 "순간 스파이크"보다는 "지속 누적"에 가깝습니다.처음에 헷갈렸..

최근 이벤트 기반 아키텍처(EDA)와 Kafka를 공부하면서 가장 자주 등장하는 패턴 중 하나가 Transactional Outbox 패턴이었다.특히 핀테크 도메인에서는 결제, 정산, 송금 같은 데이터가 이벤트로 확산될 때 정합성이 굉장히 중요하기 때문에 이 패턴을 이해해둘 필요가 있다고 느꼈다.DB 저장과 Kafka 발행은 왜 문제가 될까?보통 주문 생성이나 결제 승인 같은 상황에서DB에 데이터를 저장하고Kafka로 이벤트를 발행해서다른 서비스들이 해당 이벤트를 처리하는 구조를 많이 사용한다.간단히 보면 이런 코드가 될 수 있다.@Transactional public void pay() { paymentRepository.save(payment); kafkaProducer.send("payment-..

핀테크 개발자로 성장하기 위해결제 · PG · 정산 도메인 이해를 목적으로 정리한 아티클 목록입니다.PG · 전자결제 기본 개념PG란?https://docs.tosspayments.com/resources/glossary/pg사장님이 꼭 알아야 할 PG 용어 정리https://www.tosspayments.com/blog/articles/21234사업자가 꼭 알아야 할 전자결제의 모든 것https://www.nhn-commerce.com/main/blog/32/%EC%82%AC%EC%97%85%EC%9E%90%EA%B0%80-%EA%BC%AD-%EC%95%8C%EC%95%84%EC%95%BC-%ED%95%A0-%EC%A0%84%EC%9E%90%EA%B2%B0%EC%A0%9C%EC%9D%98-%EB%AA%..

Node.js, PHP, Java로 분산된 서버를 Spring Boot 기반으로 통합한 실전 사례. 올라핀테크 백엔드팀의 서버 통합과 이벤트 기반 아키텍처 전환 기록.빠르게 성장하는 스타트업, 그리고 함께 커진 과제올라는 이커머스 셀러를 위한 선정산 서비스로 빠르게 성장해왔어요. 빠른 성장은 좋은 신호지만, 기술팀에게는 새로운 과제를 안겨주기도 했죠. 초기에는 빠른 개발과 검증을 위해 상황에 맞는 다양한 기술을 선택했어요. 어떤 서비스는 Node.js로, 어떤 서비스는 PHP로, 또 다른 서비스는 Java로 개발되었고, 각 기술은 당시의 요구사항에 맞는 최선의 선택이었습니다.당시 서버 구성Node.js 서버: 셀러가 직접 사용하는 핵심 API 서버Node.js 배치 서버: 선정산 금액 회수, 실시간(분단..

회사에서 JDK 17 버전에서 21로 변경하며 Virtual Thread를 도입하기 위해 학습한 내용을 기록하였습니다.Virtual Thread 개념 정리Java 19에서 프리뷰로 도입되고 Java 21에서 정식 출시된 Virtual Thread(가상 스레드)에 대해 학습하였습니다. 기존 Platform Thread와 비교하면 상당한 차이가 있었습니다. 기존 Platform Thread의 한계점스레드당 약 2MB의 메모리 사용생성 및 삭제 비용이 높음일반적으로 수십~수백 개 정도만 생성 가능Virtual Thread의 개선점스레드당 약 10KB로 매우 가벼움수십만~수백만 개까지 생성 가능I/O 대기 시간을 효율적으로 활용동작 원리 학습Virtual Thread는 Platform Thread 위에서 동작하..

매일 오후 6시에 멈추는 지급, 24시간 자동화 시스템으로2024년 프로젝트 회고 올라핀테크에 합류하고 가장 먼저 맡은 프로젝트가 지급 자동화였습니다. CX팀이 매 정각마다 반복하던 지급 작업을 24시간 자동화 시스템으로 전환하고, PHP, Node.js, Java로 분산되어 있던 지급 로직을 통합하며, 병렬 처리와 체계적인 예외 처리로 안정성을 확보한 과정을 기록합니다.입사 당시 지급 시스템입사 당시 지급 시스템은 이랬습니다:CX팀 지급 담당자가 매 정각마다 수기로 처리평일 9~18시에만 지급 가능6시 이후 신청? 다음날까지 대기주말은 12시쯤 한 번만 일괄 처리"이걸 24시간 자동화할 수 있을까?"처음 하는 핀테크 업무였습니다. 이전까지는 금융과 무관한 개발을 해왔기에, "한 푼의 오차도 허용되지 않..

시작하며Node.js 서버에서 금전적인 행위를 처리하는 배치 작업이 종료(Shutdown)될 때 안전하게 종료되지 않아 특정 유저의 출금이 두 번 발생하는 문제가 종종 발생했다. 원인을 분석해보니, Shutdown 시점에 출금 처리는 되었으나 데이터 처리까지 완료되지 않아, 다음 배치 작업에서 중복 출금이 발생하는 문제였다. 이를 해결하기 위해 Graceful Shutdown을 도입하는 과정에서 배운 점들을 기록하였다.Graceful Shutdown이란?직역하면 우아한 종료로, 애플리케이션이 완전히 종료되기 전에 진행 중인 모든 작업을 마무리하고, 리소스를 해제하며 데이터의 무결성을 유지한 상태로 안전하게 종료되는 과정을 의미한다.Node-schedule 사용Node.js에서 스케줄업무를 하는 라이브러리..

보호되어 있는 글입니다.

시작하며Readable Code: 읽기 좋은 코드를 작성하는 사고법 강의를 보고 정리한내용으로,회사의 서비스 개선을 준비하는 단계에서 우리팀에 적용해보면 좋겠다. 라는 생각이 들어 정리한 내용입니다. 이름짓기1. 단수와 복수를 구분하기~(e)s를 붙여 변수, 클래스 등 단수인지, 복수인지 구분2. 이름줄이지 않기관용어처럼 많은 사람들이 자주사용하는 줄임말 정도만 사용하고, 무분별한 줄임말은 자제 또한, 줄임말이 이해될 수 있는 것은 문맥때문이기에 문맥을 잘 활용ex) column -> col, latitude -> lat, longitude -> lon 3. 은어 / 방언 사용하지 않기일부 팀원 / 현재의 우리팀만 아는 용어금지새로운 사람이 팀에 합류했을때 용어를 이해하기 힘들다.도메인 용어 사용하기팀단..