AI는 개발자를 대체하는 것이 아니라 강화하는 것입니다. 반복적이고 지루한 작업은 AI에게 맡기고, 우리는 더 창의적이고 전략적인 사고에 집중할 수 있게 되었습니다.2025년 단순한 코드 자동완성을 넘어 프로젝트 전체를 이해하고 복잡한 개발 작업을 스스로 수행하는 AI 코딩 에이전트들이 등장했기 때문이죠몇 달간 GitHub Copilot, Cursor, Windsurf, JetBrains Junie, Google Jules 등 주요 코딩 에이전트들을 직접 사용해본 결과 마치 옆자리 동료 개발자처럼 요구사항을 이해하고,계획을 세우며, 여러 파일을 동시에 수정하는 진짜 개발 파트너로 페어프로그래밍 하는 느낌을 받았습니다.그래서 이 글에서는 실제 사용 경험을 바탕으로 각 도구의 특징을 분석하고 느낀점을 공유하려 합니다.코딩 에이전트(Coding Agent)는 기존의 코드 자동완성 도구에서 진화하여, 개발자의 자연어 요청을 바탕으로 여러 파일에 걸쳐 복잡한 작업을 계획하고 실행하는 자율적인 AI 개발 도구입니다.JetBrains는 이를 "사용자의 자연어 프롬프트를 기반으로 복잡한 작업을 자율적으로 수행"하는 AI 도구로 정의합니다.즉, 단순 코드 완성을 넘어 프로젝트 전반에 걸친 멀티 파일 수정, 코드 리팩토링 등 복잡한 업무를 스스로 해결할 수 있다는 점이 핵심입니다.왜 최근 기업들은 코딩 에이전트에 주목할까?GitHub에 따르면 Copilot 도입 후 개발 속도가 최대 55% 빨라지고, 개발자의 85%가 코드 품질에 자신감을 느끼게 되었습니다.많은 개발자들이 Copilot 이전으로 돌아가기 힘들다고 언급할 만큼 효과가 입증되었습니다.AI 모델 성능이 비약적으로 향상됨에 따라 단순 자동완성을 넘어 복잡한 티켓 처리, 코드 리뷰 및 Pull Request 생성까지 자동화하는 사례가 늘어나고 있습니다.구글의 한 책임자는 "이제 에이전트식 개발이 프로토타입에서 실제 업무에 도입될 전환점"이라고 평가하기도 했습니다.JetBrains는 Junie 출시 당시 "루틴 작업을 완전히 AI에 위임하여 개발자는 창의적인 업무에 집중할 수 있게 됐다"고 언급하며 개발자 업무 방식의 근본적인 변화를 강조했습니다.Microsoft(GitHub), Google, JetBrains, Replit 등 주요 기업들이 자체 AI 에이전트를 앞다투어 출시하며 IDE 통합, 클라우드 연계 등 각각의 강점을 내세워 생태계 구축 경쟁이 치열하게 전개되고 있습니다.Google은 "에이전트 중심 개발이 프로토타입에서 실제 제품으로 전환되는 전환점에 와 있으며, 곧 소프트웨어 개발의 중심이 될 것"이라고 전망했습니다.주요 코딩 에이전트 사용기GitHub Copilot은 2021년 등장 이후 가장 널리 사용되는 AI 코딩 도구입니다.GitHub Copilot은 가장 먼저 등장한 현대적 AI 코딩 비서로, 오픈AI의 GPT 계열 모델을 기반으로 개발자의 코드 작성을 도와온 도구입니다.Visual Studio Code, Visual Studio, Vim, JetBrains 등 여러 IDE에 플러그인 형태로 통합되어 편리하게 사용할 수 있습니다.처음에는 주로 Tab 자동완성으로 간단한 코드 조각을 제안하는 기능이 핵심이었지만,현재는 Copilot Chat이라는 대화형 창을 통해 코드에 대한 질문 답변이나 리팩토링 힌트도 얻을 수 있고, 터미널 명령어 제안 기능 등도 발전시켜 나가고 있습니다.Copilot의 강점은 간편함과 안정성입니다. 개발 흐름을 해치지 않고 자동으로 등장하는 한 줄~여러 줄의 제안을 통해 “마치 내가 생각하는 대로 IDE가 코드를 이어 써주는” 경험을 제공합니다.예를 들어 함수를 작성하다 주석으로 “// 이 함수는 배열을 정렬합니다”라고 쓰면 바로 아래 정렬 코드를 완성해주는 식입니다.또, 주석으로 #include <파일명>처럼 파일명을 언급하거나, VS Code 기준으로 “Attach Context” 버튼을 눌러 특정 파일을 Copilot에게 고려하라고 지시할 수도 있어 프로젝트 맥락도 일부 반영됩니다 .물론 아쉬운 점도 있습니다.Copilot은 기본적으로 현재 열려있는 파일과 주변 맥락에 기반하여 코드 한두 스니펫을 제안하는 데 집중하기 때문에,프로젝트 전반을 아우르는 대규모 변경 작업이나 다중 파일 수정에는 한계가 있습니다.그럼에도 “개발자라면 이제 Copilot 없이 코딩하기 힘들다”는 말이 나올 정도로 생산성에 큰 도움을 주고 있으며 , 여전히 많은 개발자들의 첫 번째 AI 파트너로 자리잡고 있습니다.안정성, 광범위한 IDE 지원, 자연스러운 워크플로우 통합이 장점이라 느낍니다.Cursor는 VS Code를 포크하여 만든 AI 전용 에디터로, 2024년 하반기부터 개발자들 사이에서 큰 화제가 되었습니다.Cursor는 아예 VS Code 자체를 포크(fork)하여 만든 독립적인 AI 코드 에디터인데요,평소 VS Code에 익숙한 개발자라면 거부감 없이 쓸 수 있는 친숙한 UI에 강력한 AI 기능들을 심어놓은 것이 특징입니다.Cursor 에디터에서 가장 눈에 띄는 것은 우측에 있는 “Composer” 패널과 Chat 인터페이스입니다.Composer에 자연어로 명령을 입력하면, Cursor의 에이전트 모드(Agent mode)가 여러 단계를 자동 수행하여 원하는 작업을 완료해줍니다.예를 들어 “이 프로젝트에 로그인 기능을 추가해줘”라고 입력하면, 관련 파일들을 생성/수정하고, 필요한 라이브러리를 추가하고, 심지어 간단한 테스트 코드까지 작성하는 등의 일련의 작업을 끝까지 수행합니다.이러한 작업은 프로그래머를 중간중간 끼워넣은 채 진행되는데, 필요한 명령어를 터미널에 실행할 때는 먼저 사용자에게 확인을 구하고 실행하며 , 변경된 코드도 diff 형태로 보여줘서 검토할 수 있게 해줍니다.즉, 빠르게 일을 처리하면서도 사용자가 흐름을 통제할 수 있도록 배려한 것이죠 .Cursor의 또 다른 강점은 프로젝트 맥락 이해 능력입니다.Cursor는 자체 임베딩 기반 검색 모델로 코드베이스를 인덱싱하여, 어떤 파일이 어디에서 어떻게 사용되는지를 파악하고 있습니다.그래서 Chat에 “이 버그를 고쳐줘”처럼 질문해도 현

SK하이닉스에서 OCR 관련 프로젝트를 진행하고 있는 담당자 입니다.최근에는 거의 모든 생성형 AI 도구들이 멀티 모달을 지원하고 있고, 또 일상 생활에서 자연스럽게 활용하고 있습니다.활용해보면 굉장히 인식률이 좋고, 자연스럽게 기존 OCR 업무에도 확장해서 사용하는 시도가 많이 보입니다.실제로 현업에서도 VLM (Vision Language Model)을 활용해서 PPT 내용을 읽어오거나, 반도체 Pattern의 결함을 찾는 시도들을 많이 하고 있습니다.실제로 OCR 관련 과제를 할때도 OCR 모델과 생성형 AI 모델을 결합해서 프로젝트를 진행하고 있습니다.그런데, 사실 VLM이 장님이자, 실제 사진을 제대로 보는게 아니라는 충격적인(?) 논문을 보게되어 공유 드리고자 글을 쓰게 되었습니다.VLM을 활용해서 이미지 인식 과제를 진행하시는 분들께서는 꼭 참고해보시면 도움이 될거라고 생각 됩니다.1. 사실 VLM은 장님이다?여기 매우 쉬운 문제가 있습니다. 빨간선과 파란선이 교점을 몇개 가지고 있는지 맞추는 문제인데요.Claude의 최신 모델인 Sonnet-4로 물어봤습니다.정답은 0개로 사실 누구나 맞출 수 있는 문제 인데, VLM은 마치 장님 처럼 틀립니다.위 예시 처럼 논문에서는 유치원생 수준이라면 누구나 맞출 수 있는 "공간 관계" 문제를 주고, VLM 모델들이 얼마나 정답을 잘 맞추는지 테스트 해본 내용이 소개되고 있습니다.총 7개의 Task가 있고, 모두 사람이라면 손쉽게 맞출 수 있는 문제로 구성되어 있습니다.• None 2개의 원이 오버랩 되어있는지 판단하기• None 글자에 빨간색 동그라미를 치고, 동그라미친 단어 맞추기• None 노선도로 갈 수 있는 개수 맞추기전부 쉬운 난이도의 문제지만 아래 벤치마크 결과를 보면 각 Task별 정확도는 상용으로는 전혀 쓰지 못할 수준임을 알 수 있습니다.2. VLM은 통념을 벗어나지 못한다?이 내용도 충격적인데요. 우리가 흔히 통념으로 알고 있는 내용 (개의 다리는 4개, 아디다스 로고는 줄 3개 등)에서 조금만 (개의 다리를 5개도 바꾼다던가) 내용을 바꾸면 VLM은 틀린 답을 내놓습니다.퓨마 그림에 다리 1개만 추가 했을 뿐인데, 우리가 아는 최신 모델이 전부 틀리는걸 확인할 수 있습니다.아디다스 로고에 줄 1개만 추가해도 통념을 벗어나지 못하고 3개로 답변 하네요.실제 논문에서는 위와 같이 우리가 알고 있고, LLM도 알고 있는 통념에 살짝만 변주를 주어도 이미지 분석을 수행 못하게 됩니다.아래 이미지는 기존 통념에 반하는 내용을 넣고, 각 모델별 질문과 정답을 맞췄는지를 보여줍니다.우리가 VLM을 활용하면서 지금까지 생기는 오류들을 기존에는 1) 랜덤 에러 2) 모델 성능 3) 낮은 화질 등으로 생각했지만 실제 VLM은 명확한 구멍이 있으며,실제 현업에 적용하기 전에 위험성(?)에 대해 고민해봐야 할 것 같습니다.특히 반도체 Pattern 같은 자연적인 이미지가 아닌 도형의 공간 정보를 해석함에 취약점을 가지고 있고, 아주 조금의 변경으로도 결과가 완전히 뒤바뀔 수 있습니다.간단하게 VLM의 한계에 관련한 2편의 논문을 살펴보았는데요. 혹시 이미지 인식 관련 과제에 VLM을 활용하시려는 분들께서는 참고가 많이 될 것 같습니다.

안녕하세요, 카카오페이손해보험 플랫폼기술팀의 휴입니다.카카오페이손해보험은 고객의 데이터를 안전하게 보관하기 위해 초기부터 암호화 모듈을 지속적으로 보강하며 운영해왔습니다. 하지만 암호화 모듈의 의존 라이브러리 대부분 초창기 버전에 머물러 있었습니다. 최근 애플리케이션들이 최신 버전으로 업그레이드되면서 애플리케이션과 암호화 모듈이 가지고 있는 라이브러리들의 호환성 문제로 AEM(Application Error Monitoring)이 울리는 가슴 아픈 사례들이 있었습니다.암호화 모듈을 개선하기 위해 코드를 살펴보니 구조가 유틸리티 클래스와 정적 메서드 위주로 짜여 있어, 변화하는 보안 규정을 수용하며 확장하기엔 한계가 분명했습니다. 이에 도메인 개념을 기반으로 리팩토링 하는 것을 팀원들에게 제안하였습니다.리팩토링 과정에서 깨달은 것은 암호화를 제대로 이해하지 않고서는 설계 자체가 어렵다는 사실이었습니다. 이 글에서는 암호화 알고리즘을 사용하는 엔지니어라면 반드시 알아야 할 암호화 기본기를 정리하고, 실무에 적용한 노하우를 소개합니다.IQ 테스트를 해본 적이 있나요? IQ 테스트 문제 중에는 주어진 패턴에서 규칙을 찾아 정답을 고르는 유형이 많습니다. 간단한 퀴즈 하나를 풀어 볼까요? 아래 문자열이 뜻하는 의미는 무엇일까요?정답은 kakaopay입니다. 알파벳을 한 글자씩 뒤로 이동(shift)시키는 고전적 트릭, 즉 시저 암호(Caesar cipher) 를 적용한 결과죠.시저 암호는 기원전 1세기 율리우스 카이사르가 사용한 것으로 전해지는, 가장 오래된 단일 치환 암호입니다.고전 암호는 알고리즘(치환·전치 규칙) 자체를 비밀로 삼는 방식이라 패턴이 단순합니다. 우리도 조금만 돌려 봤을 때 정답을 알아낼 수 있죠.암호문만 가지고도 아래와 같은 기법으로 사람이 직접 해독할 수 있습니다.• 브루트포스 : 시저 암호라면 alphabet 25개의 이동 값을 모두 시도하면 끝• 빈도 분석 : 글자 출현 빈도를 통계적 분포(예: 영어는 E, T, A 빈도가 높음)와 대조실제 사례로 1586년 바빙턴 음모를 들 수 있습니다(영국 국립 기록원(The National Archives)에서 제공하는 교육 자료). 스코틀랜드 여왕 메리 스튜어트는 엘리자베스 1세 암살 계획을 주고받으며 단일 치환 + 코드표를 섞은 노미네이클레이터(nomenclator) 암호를 사용했습니다. 그러나 엘리자베스의 정보국에서 일한 암호 해독관 토머스 펠립스가 빈도 분석으로 이를 해독했고, 그 내용이 반역의 증거가 되어 메리 스튜어트는 처형되었습니다.이 사건은 “알고리즘이 아니라 키를 숨겨야 한다”는 현대 암호학의 대전제를 일깨운 대표적 사례로 자주 인용됩니다.고전 암호는 “공격자가 알고리즘을 모른다”는 가정 아래 설계되었습니다. 그러나 현실에서는 알고리즘이 언제든 노출될 수 있고, 실제로 빈도 분석이나 브루트 포스 공격으로 쉽게 깨질 수 있습니다.이에 현대 암호학은 케르크호프(Kerckhoffs) 원리를 받아들여 다음과 같은 철학으로 전환되었습니다. 위키 백과를 보면 아래와 같은 문구

들어가며소프트웨어 개발 패러다임이 AI 코딩 에이전트의 등장으로 근본적인 전환점을 맞이하고 있습니다. 카카오는 "개발자와 AI는 어떻게 효과적으로 협업할 수 있을까?"라는 질문의 답을 찾기 위해, '바이브 코딩 을 넘어 진정한 '에이전틱 코딩 으로 나아가는 단계별 내부 실험을 진행했습니다.실험 여정 한눈에 보기지난 2025년 3월부터 시작된 저희의 실험은 AI와의 협업 수준을 점진적으로 높여가는 방식으로 설계되었습니다.Phase 1: 신기술 ...

29CM 제주/도서산간 배송비 시스템 구축기: 전체 생태계에 미치는 복잡한 여정안녕하세요, 29CM Purchase & Post Purchase 팀 백엔드 엔지니어 최승원입니다. 저희 팀은 고객이 상품을 장바구니에 담아 주문하는 단계(Purchase)부터, 주문 이후의 배송, 클레임, 정산 등 후속 프로세스(Post Purchase)까지 전반적인 기능을 개발하고 있습니다.오늘은 Purchase 단계 중 하나인 제주/도서산간 배송비 프로젝트의 기획부터 구현까지 전 과정을 공유하고자 합니다. 언뜻 단순해 보이는 배송비 추가 기능이지만, 실제로는 주문부터 정산까지 전체 이커머스 생태계에 영향을 미치는 복잡한 프로젝트였습니다.제주/도서산간 배송지란?제주/도서산간 지역은 도서지역(섬)과 산간지역을 아울러 이르는 말로, 일반적으로 육로로 접근이 어려운 지역을 의미합니다. 한국에서는 주로 섬 지역의 비율이 높으며, 배송 시 육로로 이동이 불가하고 선박이나 항공 이용료, 위탁배송 등으로 인해 추가 배송 비용이 발생하는 지역을 지칭합니다.상품 상세정보 제주/도서산간 추가배송비프로젝트 배경프로젝트 이전에는 29CM에서 제주/도서산간 지역 배송비를 파트너(판매자)와 고객 간 직접 결제로 처리하고 있었습니다. 고객이 주문을 하면 파트너가 주소를 확인하고, 제주/도서산간 지역인 경우 고객에게 직접 연락하여 도서산간 배송비를 입금받은 후 상품을 발송하는 방식이었습니다.주문 완료 후 파트너를 통해 추가 결제 요청을 받기 때문에 고객 불만과 불편이 발생하고, 출고 리드타임이 증가하는 상황이었습니다. 도서산간 배송은 전체 주문의 약 1.1%로 비율은 낮지만, 29CM의 거래 규모가 커질수록 해당 문제의 영향도 점점 증가하고 있었습니다.이 문제를 해결하기 위해 도서산간 배송비 프로젝트를 시작하게 되었습니다.프로젝트 목표 및 성공 지표프로젝트 목표우편번호 기반으로 도서산간 지역을 식별합니다주문 시 제주/도서산간 배송지인 경우 제주/도서산간 배송비를 결제금액에 포함하여 결제하도록 합니다주문, 취소, 반품, 교환 등 주문 이후 모든 프로세스에서 도서산간 배송비가 고려되어 처리되어야 합니다정산 시스템과 연동하여 파트너에게 도서산간 배송비 정산해야 합니다성공 지표 설계프로젝트의 성과를 객관적으로 측정하기 위해 다음과 같은 지표를 설계했습니다핵심 지표 (Primary Metric)도서산간 배송비 결제 시스템 도입: 기존 수동 결제 자동 결제 전환보조 지표 (Secondary Metrics)도서산간 배송비 관련 고객 문의 감소율제주/도서산간 관련 VoP (Voice of Partner), VoC (Voice of Customer) 인입률제주/도서산간 우편번호로 배송되는 주문건 출고 리드타임 개선가드레일 지표 (Guardrail Metrics)주문서 진입 후 이탈 비율 (배송비 추가로 인한 부작용 모니터링)문제 해결 과정: 예상보다 복잡했던 여정도전 과제 1: 시스템 전반의 영향도 파악처음에는 단순히 주문 시 제주/도서사산간 배송비를 추가하는 기능으로 생각했지만, 실제로는 이커머스 전체 생애주기에 영향을 미치는 복잡한 시스템 변경이었습니다.배송비..그것은 빙산의 일각이었다영향을 받는 시스템들주문 시스템: 장바구니부터 주문서까지 배송비 계산 및 표시 로직결제 시스템: 추가 금액 포함한 결제 처리클레임 시스템: 취소/반품/교환 시 배송비 처리정산 시스템: 파트너에게 배송비 정산도서산간 배송비라는 하나의 금액 정보가 주문부터 클레임, 정산까지 모든 단계에 영향을 미치기 때문에 고려해야 할 곳이 굉장히 많았습니다.제주/도서산간 지역 데이터 관리 전략제주/도서산간 배송지역을 판단하는 기준인 우편번호는 Musinsa OMS(Order Management System 이하 MOMS) 정보를 사용했으며, 데이터를 가져오는 방식을 결정할 때 API 호출과 배치 동기화 두 가지 방안을 검토했습니다실시간 API 호출 방식: 주문 시마다 MOMS API로 도서산간 여부 확인배치 동기화 방식: 주기적으로 도서산간 지역 데이터를 동기화하여 자체 저장최종적으로 배치 동기화 방식을 선택한 이유는 다음과 같습니다.확장성: 주문량 증가 시 외부 API 호출 부하 방지의존성 최소화: 외부 시스템 장애가 우리 주문 시스템에 직접적 영향을 미치는 것 방지성능 최적화: 로컬 데이터 조회로 응답 속도 향상안정성 확보: 네트워크 이슈나 외부 서비스 문제로부터 독립적 운영도전 과제 2: 우편번호 체계 변화와 레거시 데이터현재 시스템은 5자리 우편번호를 기준으로 제주/도서산간 지역을 판별하지만, 고객 DB에는 과거 체계인 6자리 우편번호가 다수 저장되어 있었습니다.데이터 규모 파악대상 데이터: 약 7만건의 6자리 우편번호전체 주소 데이터 중 약 1%에 해당UX 중심 의사결정: 6자리 우편번호를 가진 고객에게 새로운 우편번호를 입력하도록 요구할 수도 있었지만, 이는 고객 구매여정에 불필요한 허들이 될 수 있다고 판단했습니다.따라서 고객 경험을 최우선으로 고려하여 백엔드에서 6자리 우편번호를 5자리로 마이그레이션하는 방식을 선택했습니다. 또한 판단에 필요한 정보는 우편번호이기 때문에 변경은 주소가 아닌 우편번호로 제한했습니다.2. 비정규화된 주소 데이터: 단순히 우편번호만 변환하면 되는 것이 아니었습니다. 고객이 텍스트로 입력한 주소들은 다음과 같은 문제들이 있었습니다:오타나 줄임말이 포함된 주소 (예: 서울시 성동구 서울 성동구 , 성수동2가   성수2가 )띄어쓰기나 특수문자 불일치구 주소 체계와 신 주소 체계가 혼재상세주소까지 포함된 경우와 기본주소만 있는 경우의 차이이러한 텍스트로 입력된 정규화되지 않은 주소들을 변환하기 위해 3단계 마이그레이션을 진행했습니다.3단계 마이그레이션 전략1단계: 공식 주소체계 변환 시스템 활용도로명주소 안내시스템의 일괄 변환 기능 사용발견된 문제점하나의 6자리 우편번호가 여러 개의 5자리 우편번호로 매핑되는 다중 대응 케이스이미 주소는 도로명 주소지만 우편번호만 6자리인 데이터가 존재하여 지번주소 기반 변환 로직의 한계2단계: API 기반 변환1차 변환 실패 건에 대해 주소 API 활용한계: 비표준 주소나 오타가 있는 주소 데이

Android 여기어때 앱의 상품정보 화면은 사용자에게 정보를 제공하기 위해 다양한 데이터를 조합하여 데이터를 수집 후 단방향으로 화면을 그리고 있습니다. 이때 조합해야 할 정보가 많을수록 복잡도는 같이 올라갑니다. 여기어때 안드로이드 팀은 Flow를 활용하여 어떻게 복잡도를 극복했는지 같이 알아보도록 하겠습니다.왜 Flow인가?여기어때 안드로이드 앱은 사용자 상호작용이 실시간으로 이어지며, 그에 따라 UI는 끊임없이 변화하는 데이터를 받아 반응해야 합니다.버튼 클릭 → 네트워크 요청응답 수신 → UI 렌더링로딩 중 → 인디케이터 표시실패 시 → 메시지 노출이러한 이벤트는 UI 스레드에서 동기적으로 처리될 수 없으며, 결국 비동기 흐름과 상태 관리가 핵심 과제가 됩니다.Kotlin Flow는 이러한 흐름을 설계하고, 추적 가능하고, 반응적으로 만드는 도구 중 최선의 선택이 됩니다.명령형 구조 vs 데이터 스트림 방식기존 명령형 구조의 한계일반적인 명령형 프로그래밍에서는 상태를 var로 선언하고 직접 갱신합니다.var isLoading = falsevar calendar: CalendarData? = null여러 필드 변수를 통한 상태 관리상태 변경 로직이 이곳 저곳 흩어짐멀티스레드 환경에서는 동기화 이슈 발생상태 변화 흐름을 추적하기 어려움이로 인해 복잡성이 높아지고 유지보수성이 떨어지게 됩니다.데이터 스트림 방식의 장점Kotlin Flow 기반의 함수형 스타일 에서는 상태를 Flow, StateFlow, SharedFlow와 같은 Flow 를 통해 데이터 흐름 안에서 직접 관리합니다.val flow = calendarFlow .flatMapLatest { calendarData -> ... }상태가 흐름 안에서만 생성되고 제어됨불변성 기반으로 side-effect를 최소화코루틴 기반으로 동시성에 강함결론데이터 스트림 방식은 상태 관리를 스트림 내부로 집중시켜, 상태 변화의 흐름과 원인을 명확히 파악할 수 있게 하며, 동시성과 복잡성 문제를 효과적으로 줄여줍니다.상세 화면을 통해 알아보는 실전 케이스여기어때 해외 숙소 상세 화면입니다. 상세 화면을 서버에 호출을 하기 위해서는 다음과 같은 변동성이 있는 정보들이 필요합니다.로그인 상태현재 달력의 날짜/인원 상태쿠폰 더보기 상태위 3가지 변동성 정보를 가지고 해외 숙소 화면을 그리는데 다음과 같은 데이터 흐름이 필요 해 보입니다.실전 케이스를 통해 문제와 해결 방법을 알아보도록 하겠습니다.실전 케이스 — shareIn문제: Cold Flow의 반복 실행val flow = flow { println("API 호출") emit(fetchData())}flow.collect() // API 호출flow.collect() // 또 fetchData API 호출 발생!!!Flow는 기본적으로 Cold Stream 이므로 collect()할 때마다 fetchData() 가 실행이 됩니다. 하지만 해외숙소 상세 화면은 첫 API 호출 결과를 가지고

안녕하세요 웹 프론트엔드 개발자 Felix입니다.올해 업무가 변화가 생기면서 오랜만에 데보션에 글 기고하게 되었네요.작년초와 다르게 올해부터는 본격적으로 AI와 함께 코딩을 하는 시대가 오고야 말았습니다.과거에는 chat gpt 등 AI LLM model이 수많은 할루시네이션(hallucination)을 만들고, 거짓말하고 감히 이런것들로 코딩을 할 수 있을까라는 의문이 있었는데,생각보다 빠르게 LLM 모델이 개선되면서 많은 개발자들, 그리고 비개발자들이 바이브 코딩을 하고 있습니다.저 역시도 처음에는 바이브코딩에 부정적이였지만, 생각이 좀 바뀌었고 상반기에 바이브코딩을 하면서 느낀 점들을 글로 옮겨보려고 합니다.저는 Cursor, Windsurf, chatGPT 를 통해서 바이브코딩 (AI 페어코딩)을 해보았습니다.이 글을 읽으시고, 바이브코딩 하시는 분들 혹은 프론트엔드 개발 하시는 분들의 개발 생산성에 기여를 할 수 있으면 좋겠네요.바야흐로 바이브코딩 시대바이브 코딩(Vibe coding)은 오픈AI 공동 창업자인 안드레 카파시(Andrej Karpathy)가 바이브코딩이라는 개념을 처음 X를 통해 개시했었는데요.안드레 카페시는 바이브 코딩은 코딩에 몸을 맡기고 지수적 증가를 받아들이며 코드가 존재하는 것조차 잊는다고 말합니다.LLM 기능이 너무 좋아지며, AI가 수준 높은 코드를 작성하게 되었습니다.요즘은 예전과 동일하게 AI도구 없이 개발을 할 수는 있지만, 커서, 윈드서프 등 여러 AI도구를 활용하면 개발의 생산성을 올릴 수 있다고 생각합니다.바이브코딩 시대라기보다는 사실 요즘 개발과 뗄레야 뗄 수 없는 키워드가 된 것 같습니다.바이브코딩은 만능 키인가?비개발자와 개발자는 접근법이 달라져야 할 것 같습니다.기획자 등 비개발자는 많은 케이스들에서 보듯이 개발지식이 없어도 개발이 가능합니다. 라이브 환경 배포까지 가능합니다.개발자들은 기존에 혼자 개발하는 것보다 생산성을 높일 수도 있습니다.바이브코딩의 장단점은 많이들 들어보셨겠지만, chatGPT를 사용해서 이 질문에 대한 답을 확인해 보았습니다.chatGPT로 바이브 코딩의 장점과 단점을 물어보았는데, 아래와 같은 답변을 얻을 수 있었습니다.다 맞는 이야기지만 저는 좀 다른 관점에 대해서도 이야기 해볼까 합니다.프론트엔드 개발자가 경험해본 바이브 코딩의 특징은?인터렉션 관련 부분에서 시간을 절약할 수 있었습니다.바이브코딩을 통해 sample을 만들고 그것을 바탕으로 수정하여 실제 개발 소스에 녹일 수 있었습니다.스타일 관련한 부분에서도 오랜만에 CSS 스타일링을 하게 되면 헷갈리는 부분이 있었는데 AI의 도움을 받을 수 있었습니다.예전에는 공식 다큐먼트나 stackoverflow 등에서 찾았지만 AI 프롬프트 한두번 보내면 원하는 결과를 확인할 수 있었습니다.대기업의 경우도 개발조직에 프론트엔드 개발자가 적은경우가 많은데, 이 경우 AI의 도움으로 적은 인력으로 높은 생산성을 만들 수 있다고 확신하게 되었습니다.LLM의 장점이자 단점이 같은 프롬프트라도 결과가 다른 경우가 존재했습니다.그래서 첫 프롬프트의 결과가 아쉬워서 다시 프롬프트를 수정하여 작성하는 경우, 첫번째 결과를 보완되는 내용이 나오는 것이 아니라 전혀 다른 결과가 나오기도 했습니다.Randomness는 AI LLM 모델의 특징으로 어느 경우 한번의 프롬프트로 확인하는 것보다 몇번더 프롬프팅을 하면서 진행해야 더 좋은 결과를 나올 수 있었습니다.우리가 Cursor 등 AI 툴을 사용할때, LLM Model을 잘 이해하는 것이 필요할 수 있습니다.즉 우리가 LLM 모델마다 성능 편차가 존재합니다.aider라는 사이트는 Polyglot benchmark로 불리며 다양한 LLM 모델을 테스트하며 어느모델이 코딩 문제를 잘 푸는지 비교하여 확인 할 수 있는 사이트입니다.절대적인 기준은 아니지만 LLM Model 선택시 참고할 만한 사이트 입니다.많은 LLM 모델들이 파이썬 코딩에 초점을 둔게 많아서 파이썬 코딩은 잘하지만, Low level 코딩은 잘 못하는 경향이 있습니다.프론트엔드 개발자가 경험해본 바이브 코딩 한계와 보완 방법은?커서를 사용할 경우 여러부분을 agent가 수정하게 되는데, 정상적으로 동작되는 기능이 잘 되지 않을 수 있습니다.AI 코딩은 실제 환경에서 빌드하여 테스트를 하지 않기 때문에 AI Agent로 수정하다보면 빌드 에러가 나는경우도 많을 수 있습니다.이러한 상황 방지를 위해 로컬에서 테스트코드를 만들어서 개발소스를 배포하기 전에 테스트 해보는 것이 좋습니다.AI코딩은 기능이 잘 동작되지 않을 수도 있기 때문에 배포 전, 테스트 코드를 통한 확인이 필수적인 것 같습니다.AI Agent가 많은 일을 해야하는 경우 잘 처리하지 못하는 경우가 존재하여 큰일을 맡기기 어려운 경우가 존재했습니다.Cursor와 Windsulf 모두 토큰 제한을 넘지 않게 하기 위해 관련된 핵심 정보만 추려서 LLM에 호출하여 정보를 가져오는 방식을 채택하고 있습니다.이 방법이 효율적이라고 생각 할 수 있으나 복잡한 문제를 풀라고 했을때 원치 않은 결과를 얻을 수 있습니다.첫번째, 이러한 방법 방지를 위해서는 해야하는 일을 잘 쪼개서 LLM을 사용하는 것이 업무에 효율적인 것 같습니다.어떤 개발 업무를 시킬 때, 일을 잘 쪼개서 AI 페어코딩을 해야 합니다. 저 역시 실제 코딩해서 작은 단위로 일 수행을 유도함으로써 생산성을 높일 수 있었습니다.두번째, 프롬프트를 쓰기 난해하거나 익숙하지 않은 경우에는 써야하는 프롬프트를 바로 작성하기 보다는LLM 에 어떤 개발을 해야하는 상황인데 어떻게 프롬프트를 써야하는지 물어보고, 수신 받은 프롬프트를 수정해서 사용하는 것도 좋은 방법입니다.AI Agent로 쉽게 누구나 코딩을 할 수 있습니다. 문장 한줄이면 앱도 만들어내고, 코딩학원에서 오랜 시간 공부해야 코딩이 가능했지만 지금은 다릅니다. 그러다 보니 바이브코딩으로 누구나 개발을 할 수 있지만 전문지식이 약하면 코드 완성도가 떨어질 수 있습니다. 이 점은 서비스에 영향이 없을 수도 있지만 큰 영향을 끼칠 수도 있습니다.금융권이나 리테일 분야에서 하나의 실수는 수

상반기 회사 데이터 엔지니어링 업무중에서 Apache Airflow와 PySpark를 활용해 Spotfire 대시보드를 자동화 구축한 경험을 공유드립니다.이 글은 워크플로우 자동화와 대용량 데이터 처리, 그리고 BI 대시보드 실시간화에 관심 있는 분들을 위한 후기입니다.특히, 제품 생산에 관여하는 모든 팀을 포함한 대시보드를 만들어야 하는 것이 포인트 였습니다.그래서 핵심은 각 팀별로 상이한 기준 정보가 저장된 Google 워크시트와, 수작업으로 조사해야만 확보되는 기준 정보를제조업 데이터 테이블과 결합해 모든 팀의 데이터를 하나의 대시보드로 통합하는 과정이었습니다.대용량 로그 데이터를 정기적으로 수집·가공·분석해야 했고, 결과를 Spotfire 대시보드로 시각화해 실시간 의사결정에 활용하는 것이 목표였습니다.전체 파이프라인은 Airflow로 스케줄링, PySpark로 데이터 처리, Spotfire로 시각화 및 리포팅 구조로 설계했습니다.2-1. Airflow로 데이터 파이프라인 자동화• None Airflow의 DAG(Directed Acyclic Graph) 구조를 활용해 데이터 수집, 전처리, 적재, 대시보드 갱신까지 전체 플로우를 자동화했습니다.• None 각 태스크는 SparkSubmitOperator를 통해 PySpark 스크립트를 실행 하도록 구성했습니다다음은 Python 및 PySpark 코드를 제외한 DAG 구조의 예시 코드 입니다.SparkSubmitOperator를 쓰면 Airflow에서 Spark 클러스터(로컬/원격)로 PySpark 작업을 손쉽게 던질 수 있습니다.최종적으로, Parquet파일로 저장하여 로컬 드라이버나 회사 클라우드 서버에 저장.PySpark는 분산 처리 기반이라 수십 GB 데이터를 빠르게 처리할 수 있습니다.ETL(추출-변환-적재) 작업을 PySpark로 구현해, 데이터 정합성 검증·집계·필터링 등 복잡한 연산을 효율적으로 수행했습니다.Spark 작업 결과는 Parquet 등 컬럼 기반 포맷으로 저장해 Spotfire에서 빠르게 읽을 수 있도록 했습니다.Spotfire에서는 회사의 클라우드나 로컬드라이버와 커넥터를 통해 Spark 테이블 또는 결과 파일(예: Parquet, CSV 등)에 직접 연결할 수 있었습니다.대시보드 데이터 소스를 “Import data table” 또는 “External data table”로 설정해, 필요시마다 최신 데이터를 불러오도록 구성했습니다.그리고 Spotfire의 Schedule Updates 기능을 활용해, 지정된 주기마다 데이터 소스를 자동으로 재조회(리프레시)하도록 설정했습니다.기존에는 Airfow를 사용하지 않고 Spotfire의 데이터 테이블 불러오기 기능을 사용했으며, Python을 이용한 비교적 낮은 용량의 데이터를 전처리 해왔습니다. 그에 비하여Airflow와 Spark의 로그 및 태스크 상태를 한 눈에 모니터링할 수 있어 장애 대응이 빨라졌습니다.PySpark의 분산 처리 덕분에 데이터 처리 시간이 획기적으로 단축되었습니다.4. 사내 데이터 테이블에 존재하지 않는~ 전체 팀마다 차이가 나는 기준 정보 수집• None 메뉴얼 조사 데이터는 정기적으로 갱신 필요성이 있으므로, 담당자와 협업 체계를 구축하는 것이 중요합니다.• None 제조업 현장에서는 생산, 품질, 설비, 물류 등 각 팀이 각기 다른 기준 정보(코드, 명칭, 분류 등)를 Goodocs 워크시트에 관리하고 있었습니다.• None 일부 기준 정보는 시스템에 저장되지 않아, 현장 담당자 인터뷰나 메뉴얼 조사 등 수작업으로만 확보할 수밖에 없었습니다.• None 이질적인 기준 정보와 제조 데이터(생산 실적, 불량, 설비 가동 등)를 통합해, Spotfire 대시보드에서 한눈에 볼 수 있도록 만드는 것이 목표였습니다.• None 각 팀별로 Goodocs에 저장된 기준 정보를 Google Sheets API 로 연동했습니다.• None 워크시트마다 컬럼명, 데이터 포맷, 기준 코드 체계가 달라 일관성 확보가 중요했습니다.• None PySpark에서 각 워크시트 파일을 읽어 공통 포맷(예: 표준 코드, 명칭, 분류 등)으로 정규화하는 스크립트를 작성했습니다.• None 시스템에 없는 기준 정보는 담당자와 협업해 수작업으로 조사·정리했습니다.• None 조사 결과를 별도 CSV로 정리해, PySpark에서 추가적으로 불러와 기준 정보 테이블에 병합했습니다.• None 모든 기준 정보는 표준화된 키(예: 표준코드)로 통합 관리하도록 설계했습니다.• None 제조 데이터 테이블(생산, 품질, 설비 등)과 정제된 기준 정보 테이블을 PySpark에서 조인(Join)하여 통합 데이터셋을 생성했습니다.• None 이 과정에서 누락값 처리, 코드 매핑 오류 검증, 중복 제거 등 데이터 품질 관리에 신경을 썼습니다.• None 통합 데이터셋은 Parquet 등 컬럼 기반 포맷으로 저장해, Spotfire에서 빠르게 조회할 수 있도록 했습니다.6-1 팀간 차이나는 기준 정보 수집• None 팀별 기준 정보가 상이할수록 표준화 작업에 많은 시간과 노력이 필요합니다. 컬럼명, 코드 체계, 데이터 타입을 미리 정의해두면 효율적입니다.• None 사전 검증 로직을 두어 자동으로 감지·알림 처리했습니다.Airflow와 Spark 연동 시, Spark 커넥션 설정(예: spark_conn)과 관련 패키지(airflow-provider-apache-spark 등) 설치를 반드시 확인해야 합니다.PySpark 스크립트는 로컬에서 충분히 테스트한 뒤 ( 행간 점검이 가능한 주피터 노트북을 추천드립니다!) Airflow에 올리면 디버깅이 수월합니다.Spotfire의 Schedule Updates와 Automation Services를 조합하면, 리포트 자동 발송(예: PDF 메일링)까지 자동화할 수 있습니다.데이터 파일 포맷은 Parquet 등 컬럼 기반을 추천하며, Spotfire와의 연동 호환성도 고려해야 합니다.Goodocs 워크시트와 메뉴얼 기준 정보, 제조 데이터의 통합은 쉽지 않았지만,Airflow와 PySpark의 자동화·대용량 처리 능력 덕분

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용Docusaurus와 Typesense를 통해 기존 Redoc 기반 커머스API 문서 사이트를 변경하면서 정리한 Docusaurus 채택 배경과 특징, Typesense 특징 및 인프라 구성, 그리고 배포프로세스 등을 설명합니다. 마지막으로 이러한 변경을 통해 정성적 정량적인 유의미한 결과를 소개하며 개발하면서 겪은 긍정적인 경험 및 남은 과제 등을 공유합니다. 발표 대상API 혹은 다른 문서 사이트를 멋지게 커스터마이즈해서 빌드 배포하고 싶은 분들목차커머스API와 커머스API문서 소개 기존 문서 플랫폼의 한계점 Redoc 기반 플랫폼의 특징과 이해UX 및 사용성 이슈, 커스터마이징의 어려움Docusaurus 채택 배경 오픈소스 선정 배경 및 해외 사례 조사Docusaurus와 docusaurus-openapi-docs의 구조와 관계Docusaurus 커스터마이징 - swizzle을 중심으로 Docusaurus swizzling에 대한 이해커스터마이징 요구사항과 구현Typesense로 검색 시스템 구축 Typesense 도입 배경 및 특징검색 시스템 구성커머스API 문서 크롤링커머스API 문서 버전 별 검색 정책문서 배포 프로세스 구축 Nubes를 이용한 정적 자원 배포 전략Docusaurus 빌드 및 크롤링 수행 환경 구성최종 문서 배포 흐름결과 비교 및 사용자 경험 결과 비교(ui, 다크모드, 검색)웹페이지 성능 비교사용자 경험 변화마치며 긍정적인 경험앞으로 남은 과제 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

이번 글에서는 AI 피처 스토어를 MongoDB와 Spring Cloud Stream으로 새롭게 구축한 이야기를 공유하려고 합니다. 간단히 요약하자면, 기존의 레거시 AI 피처 스토어 시스템에서 발생한 여러 문제를 해결하기 위해 MongoDB와 Spring Cloud Stream을 도입해 새로운 시스템을 개발해 레거시를 대체하는 과정을 다루려고 합니다.우리는 새로운 목적으로 처음부터 새로운 시스템을 구축하기도 하지만, 기존 시스템을 인계받아 문제를 개선하거나 때로는 기존 시스템의 목적을 이어받는 완전히 새로운 시스템을 구축하기도 합니다. 즉, 종종 복잡하고 불완전한 레거시 시스템을 받아 이를 개선하고 대체해야 하는 상황과 마주칩니다. SNS에 올라오는 멋진 프로젝트들처럼 모든 개발 여정이 화려한 것은 아니죠. 이 글은 이와 같이 레거시를 대체하는 새로운 시스템을 개발하는 경험을 공유해 비슷한 상황에 처한 많은 개발자분들께 작은 도움이 되기를 바라며 작성했습니다.이번 글은 특별히 저희 팀이 아닌 Mongo DB의 DBA이신 이세웅 님도 함께 작성해 주셨습니다. 이번 프로젝트의 핵심 과제 중 하나가 그 자체로 또 하나의 도전이라고 할 수 있을 정도로 전례 없는 규모의 대용량 MongoDB 샤딩된 클러스터(sharded cluster)를 구축하는 것이었기 때문입니다. 평소 MongoDB에 관심이 있었던 분들, 특히 대규모 MongoDB 운영 및 구축과 관련된 실제 업무 경험담을 찾고 계신 분들께 도움이 되기를 바라며 본격적으로 이야기를 시작해 보겠습니다.이번 프로젝트는 여러 문제를 안고 있던 레거시 피처 스토어(이하 레거시)를 대체할 수 있는 완전히 새로운 피처 스토어를 개발하는 프로젝트였습니다. 피처 스토어란 AI에서 사용하는 실시간 및 배치 데이터를 저장하고 처리해 피처를 재사용하고 일관성을 유지할 수 있게 만드는 시스템입니다. AI 모델 개발과 운영을 위한 피처 변환(feature transformation), 서빙, 스토리지 등의 기능을 제공합니다(피처 스토어의 역할이나 효용에 대한 보다 자세한 사항은 MACHINE LEARNING FEATURE STORES: A COMPREHENSIVE OVERVIEW를 참고하시기 바랍니다).이전에 대용량 AI 실시간 임베딩 데이터를 효율적으로 다루기라는 글로 AI에 사용하는 실시간 임베딩을 제공하는 고성능 고효율 서버를 구축한 과정과 결과를 공유한 적이 있는데요. 이번에 소개하는 프로젝트는 이전에 소개한 프로젝트와 결합해 더 다양한 종류의 AI 데이터를 제공하는 역할을 담당하는 시스템을 개발하는 프로젝트입니다.두 프로젝트가 다루는 AI 데이터의 성질이 다르고 그로 인해 시스템 구성도 완전히 다르기 때문에 이전 글을 보지 않으신 분들도 이 글을 이해하시는 데 전혀 문제는 없습니다. 다만 두 글을 모두 읽어보시면 데이터의 성질에 따라 시스템 구조가 얼마나 많이 달라지는지, 또한 각각 어떤 DB를 사용했고 그 이유가 무엇인지 비교해 보실 수 있기 때문에 아직 이전 글을 보지 않으셨다면 이전 글도 함께 읽어보시기를 권해 드립니다.개발자들은 간혹 기존에 존재하던 레거시를 인계받아 더 나은 시스템을 만드는 일을 맡게 됩니다. 이때 레거시 개발에 본인이 참여하지 않았다면 기존 시스템을 분석하는 일부터 시작해야 하며, 얼마나 정확히 분석하느냐가 이후 작업에 큰 영향을 미칩니다.레거시 시스템을 분석할 때는 레거시의 기획 의도와 목적, 주변 시스템과의 관계, 인프라 환경과 같은 시스템 환경을 파악해야 하고, 만일 시스템에 문제가 있을 경우 문제의 원인을 정확히 진단해야 합니다. 그래야 기존의 역할을 충실히 수행하면서 문제를 해결할 수 있는 새로운 시스템을 만들 수 있습니다.이번 프로젝트에서도 가장 첫 번째 단계가 레거시 시스템 분석이었으며, 레거시 시스템의 환경과 문제는 아래와 같았습니다.기존 레거시 AI 피처 스토어 시스템의 주요 목표 중 하나는 대용량 파케이(parquet) 파일을 적재하고 관리하는 것이었습니다. 조금 더 구체적으로 말하자면, 매일 또는 특정 주기에 맞춰 AI 서비스용 대용량 파케이 파일을 다운로드하고 이를 검증한 후 정해진 시간 내에 DB에 적재해 AI 모델의 훈련과 실제 서비스에 활용되도록 만드는 것이었습니다.겉으로 보기에는 비교적 단순한 데이터 파이프라인처럼 보일 수 있지만 실제로는 다음과 같은 이유로 높은 성능을 요구하는 까다로운 과제였습니다.• 시스템이 주기적으로 처리해야 하는 파케이 파일은 하나당 수 GB에서 수백 GB에 이르는 대용량 파일이었으며, 이런 파일을 동시에 혹은 순차적으로 수십 개에서 수백 개씩 처리해야 했습니다.• 하루 동안 처리해야 하는 총 데이터량은 수 테라바이트를 초과했으며, 지속적으로 보관해야 할 데이터 규모도 수십 테라바이트에 달했습니다.• 전체 프로세스(파케이 파일 준비 → 다운로드 → 압축 해제 → 검증 → DB 적재 → 상태 변경 및 TTL 만료 데이터 삭제)를 반드시 정해진 시간 안에 완료해야 했습니다.• 만약 처리 지연이 발생할 경우 연관된 후속 작업과 관련 시스템에 연쇄적인 장애가 발생할 수 있어 안정적인 처리가 필수였습니다.• 신규 데이터 적재 작업 중에도 서비스는 중단 없이 실시간 요청을 처리해야 했으며, 이때 응답 시간을 반드시 일정 수준 이내로 유지해야 했습니다.결과적으로 대용량 데이터 처리와 엄격한 시간 제약, 실시간 응답이라는 세 가지 요구 사항을 모두 만족하는 아키텍처 설계가 프로젝트의 핵심 과제였습니다.레거시 시스템은 앞서 말씀드린 목표를 충족하며 작동하고 있었지만 다소의 문제를 지니고 있었으며, 문제는 서버 및 애플리케이션 구성의 문제와, 메인 DB로 사용된 TiDB의 제약으로 나눌 수 있었습니다.서버와 애플리케이션 구성의 문제레거시 시스템의 첫 번째 문제는 서버와 애플리케이션 구성 때문에 서버 자원을 비효율적으로 활용하고 있다는 것이었습니다. 레거시 시스템 개발 시 선택된 서버들은 아래 설명할 파케이 파일에 대한 잘못된 접근법 때문에 CPU 대비 메모리 용량이 비정상적으로 큰 고가 장비들이었고, 단일 노드풀에 집중 배치돼 있었습니다. 그런데 이와 같이 고사양 서버를