트랜잭셔널 메시징이란 “메시지를 데이터베이스 트랜잭션의 일부로 발행하는 것”을 의미한다. 애플리케이션 비즈니스 로직에 의해 데이터베이스를 수정하는 작업과 메시지 큐에 메시지를 발행하는 작업, 두 가지 작업을 원자적으로 수행하여 데이터 일관성을 보장하는 것이다. 이 글에서는 트랜잭셔널 메시징을 구현하는 두 가지 패턴을 소개한다. 이어 포스트그레스큐엘(PostgreSQL)을 이용하여 이를 더 단순하게 만드는 방법을 다룬다. 포스트그레스큐엘과 PGMQ를 함께 사용하면 데이터베이스 단일 트랜잭션으로 두 가지 작업을 묶을 수 있다.

최근 한 개발자 커뮤니티 대나무숲에서 자기소개에 대한 고민 글을 보게 되었습니다. “내일 면접인데 혹시 자기소개는 보통 어떤 식으로 하나요? 무슨 말로 자기소개를 해야 할지, 어느 정도 문장으로 구성해야 할지 고민이네요.” 이 글을 보고 나서 예전에 면접 볼 때 자기소개를 어떻게 했었는지 다시 한번 떠올려봤습니다. 사실 마지막으로 면접을 본 게 거의 3년 전이다 보니, 만약 지금 당장 면접을 본다면 저를 어떻게 소개해야 할지 생각하게 됐습니다. 일반적으로 면접의 시작은 1분 자기소개와 함께하니까요. 1분이라는 시간이 누군가에게는 짧게, 또 누군가에게는 길게 느껴질 수도 있는데요. 이 시간에 나의 장점을 잘 어필하기 위해서는 구조를 다듬고 표현을 정제하는 과정이 필요하며, 철저히 준비해야 실수를 줄일 수 있습니다. 오늘은 이 질문에 대한 답변을 바탕으로 이야기해 보려고 합니다.

GraphQL은 클라이언트가 필요한 특정 데이터만 요청할 수 있도록 하여 보다 효율적이고 유연한 데이터 검색을 가능하게 하는 API 쿼리 언어입니다. 언어의 발전과 함께 점점 더 많은 기업에서 클라이언트-서버 통신 수단으로 GraphQL을 채택하는 사례가 늘어나고 있습니다. 대표적으로 페이스북(Facebook), 깃허브(GitHub), 그리고 핀터레스트(Pinterest) 같은 서비스들이 GraphQL을 채택하고 있다고 합니다. 대형 서비스들뿐만이 아닙니다. 글을 쓰는 현재 기준(24년 10월), 깃허브에서 “GraphQL”이란 키워드를 포함한 공개 레포지토리가 29,865개에 달할 정도죠. 이번 글에서는 이 쿼리 언어의 특징을 살펴보며, 왜 이토록 많은 관심을 받는지 알아보려고 합니다.

저는 다국적 IT 회사에서 10년 가까이 일하면서 다양한 나라의 개발자와 엔지니어를 만났습니다. 오랜 기간 그들과 협업하는 과정에서 개발자의 영어 구사 능력에 자연스레 관심을 가지게 되었습니다. 한편 그 회사에서 일하는 한국인 개발자들과 함께 할 기회도 많았습니다. 그들이 다른 나라 개발자에 비해 뒤지지 않는 뛰어난 개발 실력을 갖추고도, 오로지 영어 때문에 능력을 온전히 평가받지 못하는 모습 역시 보고는 했습니다. 이번 글에서는 개발자가 영어 공부를 해야 하는 이유를 사실과 데이터에 근거해 살펴보고자 합니다. 글의 마지막에는 제 개인적인 견해를 바탕으로 ‘개발자에게 영어가 중요한 또 다른 이유’를 덧붙이고자 합니다.

소프트웨어 산업에는 하루에도 수십 개의 새로운 약어와 개념이 등장합니다. 특히나 빠르게 변하는 AI 기술 같은 경우라면 더욱 말입니다. AI를 제대로 맛보게 해 준 챗GPT와 같은 LLM이 우후죽순으로 등장하더니, 지금은 또 메타의 라마로 대표되는 SLM 혹은 sLLM이라는 게 나오고, AI를 완성시키는 AGI라는 개념도 이해해야 하는데, 또 검색-증강 생성이라며 RAG라는 말이 심심치 않게 들립니다. 배경 개념을 알고 거기에 쉬운 스토리를 붙이면 이해에 어렵지 않습니다. 최소한 이 글을 끝까지 읽으신다면 RAG에 대한 이해는 제가 책임지겠습니다. 자, 시작합니다.

한창 MSA(Microservices Architecture)로의 전환을 진행하는 중이었던 저희 팀은 새로운 branch 전략이 필요한 상황이었습니다. MSA로 전환하면서 기존 정기 배포 방식은 버리고 수시 배포를 하기로 결정했기 때문이었죠. Git-flow, Github-flow, Gitlab-flow를 포함해 여러 branch 전략을 살펴보았지만, 팀 환경에 꼭 맞는 branch 전략은 없었습니다. 그래서 팀의 요구 사항과 환경에 맞는 branch 전략을 직접 만들기로 결정했습니다.

레거시 코드 정리는 모든 개발자에게 피할 수 없는 과제이자 커다란 부담이다. 특히 시간이 지나면서 유지 보수가 어려워진 코드는 점차 기술 부채로 쌓여가며, 프로젝트의 장기적인 성장을 방해하는 요소로 작용하게 된다. 최근 레거시 코드 정리 작업을 맡게 되었고, 최대한 안전하게 코드를 변경할 방법을 찾기 시작했다. 검토할 코드 양이 많아 일정 산정부터 쉽지 않았지만, 동료들에게 조언을 구하며 체계적으로 접근해 큰 문제 없이 마무리할 수 있었다. 내가 얻은 교훈은 레거시 코드를 정리할 때는 무엇보다 코드의 안정성을 최우선으로 해야 한다는 것이다. 오늘은 코드의 안정성을 해치지 않고, 레거시 코드를 정리하는 방법을 이야기해 보고자 한다.

“서비스를 위한 AI를 개발한다”라고 할 때는 학습 데이터셋이 없는 경우가 많습니다. 물론 준비된 경우도 있겠지만, 실무에서는 없는 경우가 꽤 많죠. 테스트 데이터셋도, 어떻게 테스트 할지에 대한 방법도 정해져 있지 않고요. 이게 실제 서비스를 개발할 때 맞닥뜨리는 상황입니다. 그 대신 주어지는 다른 하나가 있습니다. 그게 뭐냐 하면, 서비스 요구 사항입니다. 오늘은 서비스 목적으로 AI를 개발하는 것이 학습 목적의 모델 개발과 얼마나 다른지 중점적으로 알아보고자 합니다. 실제 회사에서 서비스 목적으로 AI를 개발하는 일에 대해 상세히 알아볼게요.

이미 많은 QA 조직에서 시행하고 있는 것처럼 29CM QA팀도 앱 테스트 자동화와 API 테스트 자동화가 실행되고 있습니다. API 테스트 자동화의 경우 API 자체의 수정이 그리 빈번하지 않은데요. 신뢰성에 문제가 발생할 수 있는 부분은 바로 앱 테스트 자동화입니다. 신규 개발 기능이 추가되거나, 기존 기능이 업데이트되는 등 변동과 함께, A/B 테스트로 인한 UI 차이도 계정마다 발생할 수 있습니다. 이로 인해 테스트 자동화 수행 시 테스트 결과가 Fail인 경우가 자주 발생하게 되었고, 결과적으로 테스트 자동화 수행 결과의 신뢰성이 떨어지게 된 것이죠.

기술 말고 내공 있는 데이터 리더로서 성장하는 데 도움을 주는, 변치 않는 방정식을 아낌없이 알려주는 선배, 그리고 10년이 지나도 변치 않을 데이터 과학 원칙을 제시한 아마존 • IDT • 빅쏠 • 우아한형제들 • 코드스테이츠 • 쏘카 • 삼성전자 • 11번가 • 페블러스의 전현직 데이터 리더 9명이 생애 가장 도움이 된 30가지 도서를 소개합니다.