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 호출 결과를 가지고