본문 바로가기

전체 글263

[작문] 어린 날의 온도와, 다가오는 삶의 무게 어린 순간을 떠오르게 해주는 만남이 있다.어렸을 적 그때 그 순간의 감정 분위기를 느끼게 해주는 만남이다. 크게 고민 생각 없이, 편하게 이야기를 할 수 있다.담소를 나누며, 한잔 기울이며 예전 그 시절 이야기를 나눈다.어렸을 때는 고민의 무게가 덜했었다. 허나 지금의 대화는 마냥 편하게 웃음의 이야기가 주를 이루진 않는다.개인의 삶보다, 무리의 삶을 책임질 준비를 하는 것이다.삶의 무게를 더 무겁게 느끼는 것이다. 삶이 예측이 가능하면 더 좋겠다는 생각도 든다.그 역시 "무리"의 삶과 안위를 신경 쓰기 때문이다. 우리는 개발자이기 때문에,최근 매서운 속도로 발전하는 기술동향을 비추어보면 지나가는 현재와 다가올 미래에 더 민감하게 반응한다. 정말 마음만 먹으면 개발자 1명이 도메인 전문가로 발돋움 하여.. 2026. 7. 13.

[Redis] PostGIS를 Redis Geo로 바꾸면 정합성은 누가 책임질까? 지역 기반 탐색 프로젝트를 정리하는 중 Redis Geospatial을 주제로 여러 차례 가상 인터뷰를 진행했다.프로젝트의 큰 흐름은 익숙했다. PostgreSQL/PostGIS에서 처리하던 반경 검색을 Redis Geo 읽기 모델로 분리했고, 평균 응답 시간은 약 400ms에서 100ms로 줄었다. "PostGIS 반경 검색이 무거워서 Redis Geo로 바꿨다."틀린 말은 아니지만, 이 문장만으로는 많은 부분이 빠져 있었다. PostGIS는 공간 인덱스를 사용할 수 있고, ST_DWithin 같은 함수는 인덱스를 활용해 후보를 줄일 수 있다.그렇다면 쿼리를 개선하면 되는 문제였는지, Redis를 선택했다면 원본 데이터는 어디에 남는지, Redis 데이터가 누락되면 누가 복구하는지까지 설명해야 했다. .. 2026. 6. 21.

[Message Queue] Outbox를 썼는데도 중복 처리가 생기는 이유 최근 결제 동기화 시스템과 Outbox, Kafka, SQS 관련 내용을 다시 정리하고 있다. 이번 주에 비상 결제 데이터 동기화 시스템을 주제로 가상 면접을 진행했다.프로젝트 흐름은 대략 이랬다. 서버 전면 장애 상황에서 client가 VAN사와 직접 결제를 수행하고, 결제 데이터를 local DB에 저장한다. 서버가 복구되면 Sync Server로 동기화 요청을 보내고, Sync Server는 DynamoDB에 상태를 저장한 뒤 SQS를 통해 Worker에 전달한다. Worker는 Payment App에 동기화 요청을 보내 최종 DB에 반영한다. 처음 1분 설명에서는 전체 구조를 꽤 자연스럽게 말한 것 같았다."장애 상황에서도 결제가 가능하게 하고, 복구 후 sync-id 기준으로 중복 반영을 막는다.. 2026. 5. 24.

[작문] 코드를 쓰는 사람에서 책임지는 사람으로 AI가 내 삶과 일에 들어오고 나서부터,개발자로서 나의 정체성에 대해 큰 혼란이 왔었다. 매우 심도 깊은 숙고 끝에 떠민 첫 타건.반복과 제어와 책임에 따른 설계를 마친 뒤 동료 개발자와 나눈 우리의 컨벤션과 목표.그 때는 그런 일들이 자연스러웠고, 그런 대화가 의미 깊었다. 코드 컨벤션, 아키텍처 등에 대한 이야기를 나눌 때면,테스트에 대한 각자의 입장과 모듈 별 책임 등과 여타 기술 내용에 대한 견해가 오갔고,각자의 오랜 숙련된 습관들을 예로 들며 기술 이야기 꽃을 피웠다. AI Agentic Coding 시대인 지금, 많은 개발 문화가 바뀌었다.주니어는 AI를 통해 기술 견해에 따른 Best Practice를 학습하고,시니어는 AI를 통해 기존 지식을 이용하여 더 생산성 높은 개발 작업을 수행한다... 2026. 5. 22.

[DataBase] PostgreSQL MVCC는 결제 정합성을 어디까지 보장할까? 최근 포인트 결제 시스템 관련 내용을 다시 정리하고 있다. 처음에는 신규 서비스이다보니, 꽤 단순하게 생각했던 것 같다. "결제 승인되고, 포인트 충전하고, 이력을 남기면 되는 거 아닌가?"물론 실제 개발을 할 때도 그렇게 가볍게 본 것은 아니지만, 큰 흐름만 놓고 보면 생각보다 단순해 보였다.그런데 정리하면 할수록 뭔가 계속 찝찝했다. PG callback은 중복으로 들어올 수 있고, 승인 API는 timeout이 날 수 있고, callback과 대사 배치가 같은 결제를 동시에 확정하려고 할 수도 있었다. 게다가 포인트 사용 API와 만료 배치가 같은 point lot을 동시에 건드릴 수도 있다.이런 케이스를 하나씩 펼쳐놓고 보니 결국 질문은 하나로 모였다."PostgreSQL도 쓰고 있고, MVCC.. 2026. 5. 16.

[기술 과제] 비교 견적 문의 벤더 추천, Query방식에서 AI 유사도 검색 도입과 전환기 목차서론 — PO의 한 마디에서 시작된 기술 과제Legacy가 왜 아팠는지 먼저 들여다보자후보 기술 스택 비교가장 무서운 질문 — "안전하게 어떻게 바꿀 것인가"OpenSearch 검색 쿼리 설계Shadow 모드 — 281건의 조용한 실험전면 전환, 그리고 지표 변동의 롤러코스터튜닝의 여정수치로 보는 최종 성적깨지고 배운 것들남은 과제마치며 서론 ☕어느 날 아침, PO 분께서 다가와 말씀하셨다. "견적 문의 추천이 좀… 뜬금없는 벤더가 나오는 거 같아요." 속으로 조용히 "아 그거요…" 하고 수긍했다.우리도 알고 있었다. 꽤 오래전부터. 현재 비교 견적 문의 기능은, 사장님(머천트)이 "서초동 근처 인테리어 견적 받고 싶어요"라고 요청을 넣으면, 시스템이 답변할 가능성이 높은 벤더 30명을 추려서 견적.. 2026. 4. 19.

[회고] 2025년을 보내며 어느덧 BE로 일한 지, 3년차가 되었다.첫 회사 시작 때 3년 뒤에 나는 어떤 모습일지에 대해 떠올렸던 기억이 난다. 그 때의 난, 20대 중반의 나이에 자신감도 넘쳤고 모든 것이 쉽게 보였고, 일에 의욕도 넘쳤다.모든 것이 새로웠으니! 🤓 만 3년이 되니, 이제는 하는 일에 대해 익숙해진 것 같다. 백엔드 엔지니어라는 직군에 적응이 된 것이다.회사에서 앞으로 어떤 일을 해야 할지, 어떻게 팀에 기여해야 할지. + 어떤 문서를 남겨야 할지.단순히 애플리케이션 코딩에 재미를 붙이는 것을 넘어서, 설계와 토론 그리고 업무 환경과 기획에서의 흥미가 더 의미 깊어졌다. 회고를 늦게 쓰는 감이 있는데.. 최근에 너무 정신 없었다. 연말부터 시작 된 결제 시스템 설계 및 개발을 한 달 내에 끝마쳐야 하는 살인적.. 2026. 1. 25.

[기술 부채] Legacy 커뮤니티 프로젝트 표준화 및 비용 및 API Latency 개선기 서론우리 팀에서 관리하는 백엔드 프로젝트 중, community 라는 프로젝트가 있다.회사 앱 내 탭 중 토크 탭의 서버 프로젝트인데.. 정말 어이 없고, 화날 정도 구조다..타 팀에서 우리 팀으로 커뮤니티 책임이 넘어왔을 때, 인수 인계 없이 던져지듯 받았고, 무엇보다 기존 개발자 분들이 퇴사하신 상황이라 파악하는 데 더 시간이 많이 걸렸다. 타 팀에서 커뮤니티 관련 문의를 주시거나, PM이 관련 업무 요청을 주실 때면, 항상 괴랄한 구조 때문에 파악하는데 오래 걸렸다. 무엇보다 에러 로그가 전혀 트래킹 되지 않았다.사내 백엔드 시스템 표준화가 전혀 되어 있지 않았기에, 로그를 회사 내부망에서만 파악할 수 있고, 그마저도 유실 되어 파악하기가 너무 어려웠다. 생각만 하면 한숨만 나오는 프로젝트였다.. .. 2025. 11. 23.

[작문] AI를 사용하면 내 실력이 늘지 않는 것 같아요? 최근 엔지니어링 직군에서, AI를 활용한 다양한 개발적 시도를 많이 하는 추세이다.회사 차원에서도 많이 권유를 하는 분위기이기도 하다. 나의 경우도, 올해 초부터 coding agent들을 참 많이 사용했다.작년까진 거의 GPT만 사용했는데, 올해 초부터 정말 범람하듯이 여러 모델들과 다양한 agent들이 터져 나왔다.Claude Code, Gemini CLI, Cursor 등등.. 뒤처지지 않으려 나올 때마다 관심 가져 사용해 보고, 업무에 적용해보곤 했었다.FE의 경우, 눈을 뜨면 기술 트렌드가 바뀌듯 항상 새로운 기술들이 나왔지만, BE는 상대적으로 덜했었다.나는 BE 개발자지만, 올해만큼은 FE개발자의 마음이 이해가 갔다.정말 매일 아침 눈을 뜨면 새로운 기술들, 모델들이 나왔다.정신없는 와중 뒤.. 2025. 9. 14.

[작문] Product 중심 개발 vs 성과 중심 개발 개발자로 일을 하면서, 일을 잘할 수 있는 방법에 대해 항상 고민을 해왔다.일을 잘할 수 있는 방법은 곧, 내 성과를 드러내는 방법이었기 때문이다.아직 만 3년이 안 되었지만 회사를 옮겨 다니며 각 개발자의 평가 기준에 대해 고민을 주로 해왔던 것 같다. 시간이 지나고 여러 일들을 겪으며 정리된 현재의 결론은 다음과 같다.개발자의 성과란 곧, 여러 기술적인 부채와 개선의 총량과 임팩트로 나타난다는 것이다.내가 스스로 생각한 결론이 아닌, 고용자들 (평가자들, 리더 등)의 말을 기반으로 정리 된 결론이다. 그런 결론으로 마음 먹고 일을 해오다 보니, 다음과 같은 행위를 자연스레 하게 되었다. 내가 한 일이 임팩트가 컸든 적든, 결과에 대한 의미를 부여하고, 목소리를 크게 내는 것이를 테면 슬랙으로 리더 급.. 2025. 8. 31.

[작문] 넌 아직도 일에서 재미를 찾니? 햇수로 벌써 개발 경력 3년 차가 되어 간다.2023년 1월부터 시작했으니, 어느덧 3년 차라는 말이 실감 난다. 오랜만에 후암동의 작은 카페에 왔다. 내 앞에 앉은 친구는 채용 전형 과제를 하고 있고, 나는 그 친구의 결제 테이블 설계에 피드백을 주었다. 꼭 잘 되었으면 좋겠다. 카페 창밖 풍경을 보며 잠시 생각에 잠겼다. 요즘 드는 생각과 회사 동료들과 나눈 이야기들이 머릿속을 맴돈다.나는 요즘 무엇을 위해 일하고 있는지 잘 모르겠다. 정확히 말하면, 요즘 일이 재미가 없다. 취미가 필요한 걸까, 아니면 내가 지금 하고 있는 일에서 더 이상 재미를 느끼지 못하는 걸까? 올해 초까지만 해도 분명히 재미있었는데. 전 회사에 있을 때, 시니어 개발자분이 "코딩은 노가다다."라고 말씀하셨다. 당시의 나는 꽤.. 2025. 7. 20.

[시스템 설계] 3개월 간의 CQRS(mini ver.) 도입기 오래간만에 글을 작성하는 것 같다.최근 상반기 회사 및 개인 업무에 너무 정신이 없기도 해서, 공부하거나 적용한 내용에 대해 정리하지 않았다. 연차가 쌓일수록 회사에서 진행하는 업무를 간단하게 구현만 하는 것이 아닌,개선을 곁들여 적용하는 것을 항상 생각하며 개발을 하려 한다.이번 2분기도 마찬가지였고 저번 주 금요일, 드디어 머릿속으로 생각만 했던 최선의 설계를 운영 환경에 적용하고 나서대략 3개월 간의 일대기를 추후에 볼 수 있게 정리해야겠다는 생각이 들어 시작한다. 이번에 CQRS를 적용해보았다. (하지만 RDBMS로 곁들인..)하고 싶었던 설계가 아니라, 정말 적용해야 할 상황이 왔다.배경은 아래와 같다. Phase.1 [ Data Pipeline 통한 Readonly 제공 ]DA(data ana.. 2025. 6. 22.

[Spring Framework] Bean 등록에 대한 재고 V2 Bean 등록에 대한 재고SpringBoot에서 Bean을 등록하는 방법은 무엇이 있을까. 1. 클래스에 직접 @Component 애노테이션을 사용하는 방식 2. @Configuration 애노테이션을 활용해 @Bean 등록하는 방식 위 2가지 방식이 보편적이다.sweeeetgoguma.tistory.com이전 포스트에 이어 이번에는 Spring Framework의 자랑! Conditional 시리즈를 활용한 Bean 등록에 대해 작성해보려 한다. 시작하며 올해 초부터 정말 일이 많다. 뭐.. 갈 수록 쌓여간다. 기술적 백로그만 몇 십 개 정도 되는 듯하다.덤으로 기술 과제와 부채도 많이 늘어났다. 당장 해결해야 하는 급한 건은 아니지만, 이번 주는 다행히 시간이 여유로운 것 같아 틈틈이 개선을 했다. .. 2025. 3. 18.

올림피아 간다는 마음으로 최근에 운동 관련 유튜브를 보다가, 제목과 같은 댓글을 봤다. 그 댓글을 작성하신 분은 직장인이셨던 것 같은데 정말 열심히 하시는 것 같고 실제로 개인 채널에 업로드하신 운동 영상과 프로필 사진을 봤을 때 어마어마했다.그런 생각이 들었다. 일하면서 운동까지 열심히 하기 쉽지 않을 텐데.. 대단한 사람들 많구나. 내가 한창 운동을 열심히 할 때, 바디빌딩 대회도 관심이 많았다. 전 세계에서 가장 몸 좋은 사람들이 나온다는 Mr.Olympia 는 매 연말에 열렸고, 난 항상 챙겨봤었다.그 대회에 출전하는 선수들은 몸도 물론 탑급이지만, 정신력도 탑급이라는 생각을 했다. (업이니까 그럴 수 있을 것 같다.) 그 선수 분들의 운동 영상을 보면서, 일반인이지만 최대한 키워보고 싶었다.카페인 섭취도 많이 늘리고, .. 2025. 3. 10.

[이벤트 소싱과 마이크로서비스 아키텍처] CH.3 이벤트 소싱 I 이번 챕터를 읽으면서, 기존에 내가 작성하던 스타일의 모호한 개념들이 명확히 정리 되는 느낌이 들었다.이런 개념을 명확히 인지하면서, 앞으로의 코드를 작성할 때면 kotlin 스타일의 패키지 정리에 좀 더 집중해야 되겠다는 생각도 들었다. 모든 내용을 정리하진 않을 것이며, 기존에 알고 있던 내용 이외에 새롭게 받아 들인 내용만 정리할 것이다!! 도메인 이벤트변경의 단위를 비즈니스 처리 과정에서 발생한 결과로 정의이벤트란 사용자가 무엇인가 처리하도록 "시스템"에 요청한 것임을 알 수 있는 힌트이면서 변경이 발생한 이유임을 알 수 있다. 이를 테면, PasswordChanged 라는 객체의 네이밍을 보면, 도메인에서 어떤 일이 일어났는지 즉시 이해가 가능하다. public class QuantityChan.. 2025. 3. 4.

이전 1 2 3 4 ··· 18 다음

티스토리툴바