요즘 온프레미스 환경 구축을 활발히 진행하고 있습니다.특히 GPU가 장착된 서버를 다루고 있는데, 이 서버들이 헤드리스 상태로 운영되기 때문에 GUI를 활용해야 할 경우에 대한 솔루션이 필요했습니다.GPU 가속 컴퓨팅 환경(예: 머신 러닝, 과학적 시뮬레이션 등)에서는 서버가 헤드리스(headless) 상태로 동작하기 때문에 그래픽 사용자 인터페이스(GUI)가 없는 경우가 많습니다.하지만 디버깅, 시각화, 또는 그래픽 애플리케이션 관리를 위해 원격으로 GUI에 접속해야 하는 상황이 종종 발생합니다.이번 글에서는 XRDP(원격 데스크톱 프로토콜 서버)를 Ubuntu 시스템에 설정하고, Mac에서 Windows App 을 사용해 GUI로 원격 접속하는 방법을 쉽게 설명해 보겠습니다.xrdp는 마이크로소프트 RDP(원격 데스크톱 프로토콜)를 리눅스, BSD 등 윈도우 외의 운영체제에서 사용할 수 있도록 하는 오픈 소스 구현체입니다.이를 통해 RDP 클라이언트를 사용하여 원격으로 시스템에 접속하여 그래픽 환경을 제어할 수 있습니다.• None Ubuntu 서버(예: Ubuntu 22.04)에 GPU가 설치되어 있어야 합니다.• None 서버에 관리자(sudo) 권한이 있는 계정• None Mac에 Windows App이 설치되어 있어야 합니다(Mac App Store에서 다운로드 가능)XRDP는 표준 RDP 클라이언트를 사용해 Linux 시스템에 접속할 수 있는 오픈소스 원격 데스크톱 프로토콜 구현입니다. 다음 단계를 따라 XRDP를 설치하고 설정할 수 있습니다.최신 패키지 정보를 가져옵니다.이 명령어는 XRDP와 함께 libfuse2, xorgxrdp 같은 필수 패키지를 설치합니다. 출력 결과는 다음과 비슷할 것입니다.부팅 시 XRDP가 자동으로 실행되도록 설정하고, 즉시 시작하게 합니다.XRDP 사용자를 ssl-cert 그룹에 추가XRDP가 SSL 인증서에 접근할 수 있도록 합니다.변경 사항을 적용하려면 XRDP를 재시작합니다.헤드리스 서버에는 기본적으로 데스크톱 환경이 설치되어 있지 않을 수 있으므로, 데스크톱 환경을 설치해야 합니다.XRDP와 호환되는 경량 데스크톱 환경(예: XFCE)을 설치합니다.사용자별 XRDP 시작 파일을 생성하거나 수정합니다.XRDP 설정 파일을 편집해 XFCE와의 호환성을 보장합니다.파일 상단, 세션 확인 코드 전에 다음 줄을 추가하세요.저장하고 종료합니다(Ctrl+O, Enter, Ctrl+X).변경 사항을 적용하려면 다시 재시작하세요.XRDP의 기본 포트(3389)가 원격 접속을 허용하도록 열려 있는지 확인하세요.4단계: Mac에서 Windows App으로 접속Mac App Store에서 앱을 다운로드하여 설치합니다.앱을 열고 "+" 버튼을 클릭한 뒤 Add PC를 선택하세요. 다음 정보를 입력하세요:• None PC 이름: Ubuntu 서버의 IP 주소 또는 호스트 이름(예: 192.168.1.100).• None 사용자 계정: Add User Account를 선택하고 Ubuntu 서버의 사용자 이름과 비밀번호를 입력하세요.• None 별칭(선택 사항): 연결에 "Ubuntu GPU 서버" 같은 이름을 지정하세요.Windows App 에서 추가한 연결을 더블클릭하세요.인증서 경고가 나타나면 수락하세요(XRDP가 자체 서명된 인증서를 사용할 경우 발생 가능). Ubuntu 서버의 XFCE 데스크톱 환경이 표시됩니다.아래와 같이 firefox를 열고 다양한 작업을 진행할 수 있습니다.• None 데스크톱 환경(예: XFCE)이 올바르게 설치되고 설정되었는지 확인하기• None 포트 3389가 열려 있고 Mac에서 접근 가능한지 확인하기• None 앱에 입력한 사용자 이름과 비밀번호가 Ubuntu 서버의 유효한 사용자와 일치하는지 확인하기• None XRDP 사용자가 ssl-cert 그룹에 추가되었는지 확인하기• None XRDP는 GPU 가속 렌더링을 완전히 활용하지 않을 수 있습니다.• None 느린 연결에서는 앱에서 디스플레이 해상도를 낮춰 성능을 개선할 수 있습니다.• None 성능 문제가 이슈라면 별도의 유료 솔루션인 HP Anyware를 통해 xrdp의 단점을 극복할 수있습니다. NVIDIA GPU와 같은 고성능 그래픽 하드웨어와 잘 통합되어 있어, 원격 세션에서 더 나은 성능을 제공할 수 있습니다.처음에는 GUI를 볼 수 없어 당황했지만, 효율적인 IT환경을 활용하고 운영하는 데 적합한 오픈소스 솔루션은 존재하였고, 사용자 친화적인 워크플로 환경을 구성할 수 있었습니다.Ubuntu 서버에 XRDP를 설정하고 Mac에서 Windows App 을 사용하면, GPU 서버에 로컬 디스플레이 하드웨어 없이도 원격에서도 GUI 환경에 접속할 수 있습니다.이 설정은 그래픽 애플리케이션 관리, 디버깅, 또는 작업 모니터링에 특히 유용합니다.

AI는 이제 소프트웨어 개발 환경에서 선택이 아닌 필수 도구로 자리 잡고 있습니다. ChatGPT, GitHub Copilot, Replit Ghostwriter 등 다양한 도구들이 빠르게 확산되며, 개발자들은 AI의 보조를 통해 단순 반복 작업을 줄이고 더 창의적인 업무에 집중할 수 있게 되었습니다.전통적인 개발 방식은 주로 명령 기반의 수동적 흐름이지만, AI 기반 개발은 협업 중심의 인터랙티브한 환경으로 변화하고 있습니다. 실시간 코드 생성뿐 아니라 테스트 자동화, 코드 리뷰 자동화 등 AI가 전 과정에 스며들면서 개발 효율성과 품질 향상에 도움을 주고 있습니다. 이러한 변화는 개발 주기의 전반적인 속도와 정확도를 높이며, 반복 작업에 소요되는 부담을 줄여주고 있습니다.그중에서도 최근 주목받고 있는 ‘바이브 코딩(Vibe Coding)’이 무엇인지, 어떻게 활용되는지 알아보겠습니다.‘Vibe Coding’이라는 용어는 ‘Vibe(분위기, 감각)’와 ‘Coding(코딩)’의 결합으로, 단순한 명령어 입력을 넘어 감각적으로 몰입할 수 있는 개발 환경을 의미합니다.이 개념은 실시간 상호작용, 자연어 기반의 커뮤니케이션, 그리고 개발자와 AI가 마치 팀처럼 협업하는 흐름에서 비롯되었으며, 기존의 딱딱하고 형식적인 코딩 경험과는 대조적인 ‘자유롭고 직관적인 흐름’을 강조합니다.바이브 코딩(Vibe Coding)은 단순히 코드를 ‘작성하는 행위’를 넘어서, 개발자와 인공지능(AI)이 실시간으로 상호작용하며 소프트웨어를 만들어가는 새로운 개발 문화입니다. 기존의 명령형 중심 코딩에서 진화해, 감각적이고 몰입도 높은 협업 환경이 가능해졌습니다.즉, 개발자가 마치 AI와 대화를 나누듯 “이 기능을 추가해 줘”, “에러가 나는 부분을 고쳐줘” 등 자연어로 요청하면, AI는 이를 이해해 실질적인 코드로 구현해 주는 방식입니다.바이브 코딩의 핵심 요소바이브 코딩 주요 도구바이브 코딩은 “소프트웨어가 무엇을 해야 하는가”에 집중하고, “어떻게 구현할 것인가”라는 AI에게 맡기는 방식입니다. 이 과정은 반복적인 상호작용을 통해 AI의 출력물을 프롬프트로 조정하며 원하는 결과, 즉 원하는 ‘바이브’를 얻어 가는 방식입니다.• ex) “회원가입 폼을 만들어줘”, “Next.js를 이용해 블로그를 생성해 줘”• AI는 이 요청을 바탕으로 대량의 코드를 생성• 생성된 코드를 자세하게 리뷰하기보다는 간단하게 실행해 보며 동작 여부를 확인(3) 프롬프트를 통해 반복적으로 수정• 기대한 결과가 아니면, 코드를 직접 수정하는 대신 AI에게 고쳐 달라고 요청• ex) “버튼 정렬을 고쳐줘.”, “에러 처리를 추가해 줘.”“블로그를 반응형으로 바꾸고 진행 상태 표시기도 수정해 줘.”“비밀번호 없이는 제출하지 못하도록 유효성 검사를 추가해 줘.”(4) 반복 작업을 통해 원하는 결과 생성• AI에게 점진적으로 지시를 내려 코드를 다듬거나 조정• 생성된 코드를 복사해 기존 코드 베이스에 통합• 소프트웨어가 의도한 대로 작동하는지 확인Lavable을 통해 블로그의 글을 SNS에 올리기 위해 불필요한 마크다운을 제거해 주는 기능을 만든 예시를 소개해 보겠습니다.프롬프트만 잘 써준다면 비개발자도 간단한 기능을 만들 수 있습니다. Lavable 좌측에 프롬프트를 입력하면, 우측에서 실행 화면을 바로 확인할 수 있습니다.Github Copilot with VSCode는 자연어 기반으로 코드를 생성하고, 생성한 코드를 바로 VSCode(개발 IDE 툴)에 적용할 수 있는 플러그인입니다.또한, VSCode에서 파일 수정 시, 예측되는 연관 코드를 추천해 주며 개발 업무 효율을 높여 줄 수 있습니다.다음은 클릭 한 번으로 프로젝트를 생성해 보는 예시입니다.바이브 코딩의 기대효과1. 진입장벽이 낮아진 애플리케이션 개발바이브 코딩(Vibe Coding)의 큰 기대효과 중 하나는 개발 지식이 부족한 사람도 자연어 기반의 질의응답만으로 애플리케이션을 빠르게 만들 수 있다는 점 입니다. 이는 복잡한 프로그래밍 언어나 코드 작성 없이도, 사용자가 자신의 요구사항을 평소 말하듯 입력하면 시스템이 이를 이해하고 자동으로 적절한 코드를 생성하거나 필요한 작업을 수행해 주는 방식입니다.(1) 자연어 명령만으로 코드 자동 생성예를 들어, 사용자가 “사용자 로그인 기능이 필요해요”라고 입력하면, 바이브 코딩은 이에 필요한 백엔드 인증 로직, 데이터베이스 스키마, 프론트엔드 입력 폼 등을 자동으로 구성해 줍니다. 이렇게 되면, 전통적인 방식으로는 개발자들이 수십 줄의 코드를 짜야 하는 작업을 몇 마디 문장으로 대체할 수 있어 개발 속도가 획기적으로 빨라집니다 .이러한 자연어 기반 인터페이스는 진입장벽을 낮춰, 개발자뿐만 아니라 기획자, 디자이너, 심지어 일반 사용자도 자신의 아이디어를 직접 구현해 볼 수 있는 기회를 제공합니다. 이로 인해 다양한 배경을 가진 사람들이 기술적인 제약 없이 창의적인 아이디어를 현실화 할 수 있게 됩니다.(3) 반복 작업의 자동화로 높은 생산성또한, 바이브 코딩은 반복적이고 표준화된 작업을 자동화 함으로써, 사람은 더 창의적이고 고차원적인 문제에 집중할 수 있도록 도와줍니다. 결과적으로 프로젝트 전체 개발 시간과 비용을 줄이고, 빠른 MVP 제작 및 시장 반응 테스트가 가능해지며, 됩니다.이러한 기술은 특히 스타트업, 소규모 팀, 비개발자 중심 조직에 큰 도움이 되며, 개발 리소스가 부족한 환경에서도 경쟁력 있는 서비스를 빠르게 구축할 수 있도록 돕습니다.2. 새로운 언어 및 프레임워크 도입을 통한 러닝 커브 감소(1) 사전 지식 없이도 가능한 신기술 활용사용자는 새로운 프레임워크나 프로그래밍 언어, 라이브러리에 대한 사전 지식 없이도 원하는 기능을 구현 할 수 있습니다. 예를 들어, “Vue.js로 로그인 페이지 만들어줘”라고 입력하면, Vue의 문법이나 구성 방식을 몰라도 해당 기능이 자동으로 구성됩니다. 이러한 방식은 새로운 기술을 배우기 위한 시간과 노력을 크게 줄여줍니다.(2) 급변하는 기술 환경에서 러닝 커브의 극복특히 기술 트렌드가 빠르게 변화하는 환경에서는 새로운 프레임워크에 대한 러닝 커브가 개발 속도의

지난 5월, 국내 최대 규모의 IT 컨퍼런스인 AWS Summit Seoul이 올해도 어김없이 뜨거운 열기 속에 막을 내렸습니다. 수많은 최신 기술 업데이트와 고객 사례 발표 속에서도, AWS 커뮤니티 현업 개발자들의 생생한 경험과 노하우가 공유되는 Community Session은 언제나 큰 주목을 받고 있습니다.이번에는 저희 팀 무신사의 개발자 두 분이 Community Session의 연사로 당당히 참여하여 자리를 빛내주셨습니다. 클라우드 기술에 대한 깊은 고민과 동료 개발자들과 성장 경험을 나누고 싶다는 열정 하나로 시작된 도전. 그 치열했던 준비 과정과 발표 현장의 생생한 열기를 여러분께 고스란히 전해드리고자, 두 분을 모시고 특별한 인터뷰를 진행했습니다.Q. 먼저 두 분 자기소개를 부탁드립니다. ‍ 재영님:안녕하세요, 무신사에서 MLOps를 담당하고 있는 이재영입니다.이번 AWS Summit 2025에서, 기존 EKS Node뿐만 아니라 2024년 12월 출시된 EKS Hybrid Node와 EKS Auto Mode를 모두 활용하여 고가용성을 확보하면서도 비용을 효과적으로 절감하는 방안을 주제로 발표를 진행했습니다. ‍ 준영님:안녕하세요, 무신사에서 소프트웨어 엔지니어로 일하고 있는 엄준영입니다.이번 AWS Summit 2025에서는 무신사, 실시간으로 콘텐츠를 잇다   경험을 바꾼 통합 아키텍처 이야기 라는 주제로, 기술로 커뮤니티의 경험을 어떻게 변화시킬 수 있는지 실제 사례와 함께 공유했습니다.Q. 어떤 경험이 지금의 발표 주제로 이어졌나요?보통 이 고통, 나만 겪을 순 없지! 하는 마음이나, 반대로 이 즐거움, 나만 알기엔 너무 아까워! 하는 마음이 발표 주제가 되곤 하잖아요. 두 분은 어떤 경험을 하셨기에 지금의 주제를 청중에게 소개하기로 마음먹으셨나요? ‍ 재영님: 제가 겪은 시행착오, 다른 분들은 반복하지 않으셨으면 했어요.HybridNode를 반드시 도입해야 하는 상황이었는데, 2025년 1월 AWS Korea에 문의해보니 출시된 지 얼마 되지 않아 국내에는 관련 구축 사례가 전무하다는 답변을 받았습니다. 말 그대로 맨땅에 헤딩 을 시작해야 했죠.직접 구축하면서 시행착오와 어려움도 많았지만, 제가 겪은 시행착오를 다른 분들은 반복하지 않으시길 바라는 마음에서 이번 발표를 준비하게 됐습니다. ‍ 준영님: 끊어진 고객 경험을 기술로 다시 연결하고 싶었어요.무신사 커뮤니티가 빠르게 성장하면서 스냅, 브랜드 스냅, 코디샵 등 좋은 콘텐츠와 서비스가 정말 많아졌어요. 하지만 한편으로는 각각의 서비스가 분리되어 있어, 고객이 원하는 연결된 스타일 경험 을 제공하는 데 한계가 보이기 시작했습니다. 연결되지 않은 콘텐츠는, 경험이 될 수 없다 는 고민에서 출발해 실시간 스트리밍 아키텍처로 끊어진 경험의 흐름을 기술로 어떻게 복원할 수 있었는지 이번 발표에서 정리해보고 싶었습니다.Q. 기술적으로 가장 어려웠던 점은 무엇이고, 어떻게 해결하셨나요? ‍ 재영님: 공식 문서도 틀릴 수 있다 는 의심이었습니다.제가 다뤘던 기술이 워낙 초기 릴리즈 버전이다 보니, 웃지 못할 일들이 많았습니다. 예를 들어, AWS 공식 문서(Document)를 업데이트할 때 일부 내용이 누락되었는지, 그대로 따라 해도 전혀 동작하지 않는 경우가 있었어요. 그리고 AWS Support Center에 문의해도 팀별로 답변이 달라서 고생 했던 기억이 있습니다.그때 깨달았습니다. 아, 이건 큰 기술 테크닉의 문제가 아니구나. 접근법 자체를 바꿔야겠다. 그래서 기존의 공식 문서와 서포트 센터가 맞을 것이다 라는 믿음을 버리고, 공식 문서와 서포트 센터 모두 틀릴 수 있다 는 새로운 전제에서 출발했습니다. 그 후로는 발생하는 에러 로그 하나하나에만 집중하며 직접 원인을 파고들어 해결해 나갔습니다. ‍ 준영님: 가장 큰 숙제는 중단 없는 실시간 통합 이었습니다.아이디어는 명확했지만, 기술적인 복잡성이 정말 컸습니다. 여러 데이터베이스에 흩어져 있는 다양한 포맷의 데이터를, 무엇보다 서비스 중단 없이 실시간으로 통합하는 것이 핵심 과제였어요. 운영 중인 서비스에 영향을 주지 않으면서, 장애가 발생했을 때 빠르게 감지하고 복구하는 안정성까지 확보해야 했죠.이를 위해 Kafka, CDC(Change Data Capture), Debezium, Kafka Streams 같은 다양한 오픈소스와 AWS 서비스를 조합해야 했는데요. 마치 레고 블록처럼, 저희 상황에 맞는 최적의 아키텍처를 찾기 위해 수많은 실험과 검증을 반복해야 했습니다. 단순히 연결만 하면 될 줄 알았는데, 현실은 다르더라고요. 처음에는 CDC 파이프라인을 그저 데이터 소스와 목적지를 연결하는 관 정도로 단순하게 생각했어요. 하지만 막상 구축하고 보니 데이터 볼륨, 메시지 포맷, 정합성 등 예상치 못한 문제들이 계속 발생했습니다. 특히 대용량 데이터를 다루면서 실시간성을 유지하는 동시에 데이터 중복을 완벽히 제거하고, 장애에 대응하는 세 가지가 가장 어려운 부분이었습니다.이 문제를 해결하기 위해 기술의 디테일 속으로 깊이 파고들어야 했습니다. 예를 들어, Debezium 커넥터의 SMT(Single Message Transforms)나 Topic 필터 기능을 활용해 파이프라인을 경량화하고, Kafka Streams의 Deduplication Store와 Dead Letter Topic을 적용해 데이터 중복과 예외처리를 자동화하는 방식으로 실전적인 해법들을 찾아 나갔습니다. 결국 단순 연결이 아닌, 운영과 예외 상황까지 모두 고려한 똑똑한 파이프라인 을 만드는 과정이었던 셈이죠.Q. 발표 후, 가장 기억에 남는 피드백이 있었나요?발표라는 긴 여정을 마친 뒤 듣는 청중의 피드백은 무엇보다 값진 선물이죠. 두 분에게는 어떤 피드백이 가장 기억에 남았을까요? ‍ 재영님: 단순한 립서비스가 아니었구나, 진심으로 확신하게 됐어요.발표를 마치고 AWS Korea User Group 부스 앞에서 몇몇 분들과 이야기를 나누고 있었어요. 그런데 지나가시던 분들이 오늘 들은 발표 중에 가장 좋았다 , 실제 트러블슈팅 경험을 날것 그대로 들을 수 있어 정말 인상적

언더커버사일로 비하인드 토크, 재미있게 보셨나요? “토스 참 쪼잔하다”는 유저의 말 한마디에 1억을 태웠던 만보기 사일로의 코멘터리가 돌아왔습니다.지난 편에서 가장 뜨거운 반응을 얻었던 바로 그 이야기, 지금부터 더 깊게 파고들어 보겠습니다.토스 만보기, 전국민의 사랑을 받던 서비스가 겪은 가장 큰 위기만보기는 2019년에 시작됐어요. 당시 토스의 가장 큰 숙제는 MAU, 즉 월간 활성 사용자를 늘리는 거였죠. 지금은 전연령이 쓰는 토스가 되었지만, 당시에는 30대~ 50대 사이의 사용자가 상대적으로 적었어요. 해당 연령대의 데이터를 살펴보니, 그분들이 만보기 앱을 많이 사용하시더라고요. '아, 이거다!' 싶었죠.토스가 만보기 서비스를 오픈한 후, 유저 수를 늘리기 위한 여러 차례의 실험이 진행됐어요. 처음엔 친구 추가 기능으로 바이럴을 일으켜 사용자를 키웠어요. 근데 바이럴 효과가 떨어지면서, '올리브영 가면 몇 원 줄게' 같은 개인 미션을 만들었죠. 건강도 챙겨드리고 싶었고요. 그런데 여기서 예상치 못한 문제가 터졌어요. 저희가 유저분들에게 리워드를 드리기 위한 큰 비용을 지출하는데도, 이게 진짜 효과가 있는 건지 성과 측정이 불가능해진 거예요. 결국 만보기는 유저가 증가할 수록 끝없이 비용도 비례하여 증가하는 비용 사업이 됐습니다. 팀 내부에서도 ‘이게 맞나?’ 하는 회의감이 들었죠.1라운드: 만보기, 존폐의 위기 앞에서2022년 이전까지 만보기는 혜택 탭의 ‘기둥’ 같은 존재였어요. 이걸 없애는 건 상상할 수 없었죠. 사용자들이 만보기를 쓰러 왔다가 ‘행운복권’도 써보고, ‘버튼 누르고 10원 받기’ 같은 다른 혜택들을 자연스럽게 경험했거든요. 만보기가 혜택 탭 전체로 사용자를 이끄는 가장 중요한 입구였던 셈이에요.그러다 ‘함께 토스 켜기’처럼 더 쉽고 강력한 서비스가 생기면서, 데이터상 만보기의 1위 자리를 내주게 됐어요. 내부에서는 당연히 ‘이제 만보기를 닫아야 하는 거 아니냐’는 목소리가 나오기 시작했죠. 하지만 데이터를 깊게 들여다보니, 떠났던 사용자를 다시 불러오고(부활 유저), 여전히 혜택 탭을 꾸준히 쓰게 만드는 힘은 만보기에 있더라고요.사실 (토스 대표인) 승건님과 만보기를 닫는 문제로 논쟁이 붙기도 했어요. 당시 만보기는 이용하는 유저 규모만큼의 비용을 무조건 지출해야하는 구조였는데, 이 비용을 메꿀만큼 이익을 내려면 무조건 그 이상의 추가적인 가치를 만들어내야 했죠. 그때 제가 광고를 담당하는 토스 Ads Product 팀에 있었는데, 솔직히 7개월 안에 그만한 성과를 낼 자신이 없었습니다. 그래서 제가 직접 하겠다고 나선 거예요. 만보기를 그만두는 대신, 어떻게든 수익화해서 이 문제를 풀어보자고 결심한 거죠. 만보기 자체의 가능성을 더 믿었던 것 같아요.주변에서 계속 ‘이제 그만하자’는 의견에 더 거세질 때도, ‘딱 2주만 더 해보자’고 버텼습니다. ‘나 같은 사용자라면, 보상이 10원에서 8원으로 줄었다고 해서 이 서비스에 아예 등을 돌리진 않을 텐데’ 라는 믿음이 있었거든요. 그 2원의 차이가 사용자를 떠나

안녕하세요. 스튜디오 킹덤 클라이언트 개발자 이한나입니다. 이 글은 제가 신입으로 입사하여 3년 차인 지금까지 일하며 실수한 것들을 돌아보고 되새겨 보는 글입니다. 이 글이 저처럼 신입 또는 주니어 클라이언트 개발자분들께 작게나마 도움이 되기를 바라며 저의 경험을 나누고자 합니다.일하다 보면 종종 내가 이해한 것과 기획자가 의도하는 방향이 다른 경우가 생깁니다. 확신이 가지 않는 부분은 당연히 물어봐야 합니다. 설계를 하고 있을 때, 작업을 진행하고 있을 때, 작업을 완료 했을 때까지, 늦었다고 생각할 때가 가장 빠른 질문 타이밍입니다."10번 뽑기 기능"을 만드는 상황을 예시로 들어보겠습니다.여기서 질문을 하지 않는 개발자가 1번 뽑기를 10번 반복하는 것으로 이해하고 (음! 전부 이해했어!) 작업을 진행합니다.그리고 마감날이 되어 테스트를 돌려본 기획자가 물어봅니다.기획자 : 이거 뽑기 10번을 전부 보여주고 있네요? 뽑기는 1번만 보여주고 보상을 10개를 줘야 하는데 다르게 나오는 것 같아요. 확인 부탁드립니다.그동안의 시간과 노력을 지우고 다시 작업을 하는 상황이 되어버렸습니다. 눈물을 머금고 다시 작업을 하고 싶지 않다면 자신이 이해한 것 그리고 작업 방향이 기획자가 의도하는 방향과 맞는지 물어보고, 기록하고, 작업을 진행하도록 합시다.추가로 작업하면서 중간중간 결과물을 영상으로 찍거나 스크린샷으로 캡쳐해 공유합시다. 구현 방향을 공유하는 의미도 있고, 나중에 리팩터링하거나 기능이 추가될 때 원본 기능이 어땠는지 참고하기 좋아서 기록 차원에서라도 남겨두는 게 좋습니다. 그리고 귀여운 작업물을 만들었다면 자랑할 수 있다는 장점도 있습니다.다른 프로그래머의 코드를 수정할 때도 비슷합니다. 코드에는 의도와 맥락이 있습니다. 왜 이런 코드가 있는지 물어보고 의도에 맞는 방향으로 작업해 야 합니다. 그리고 수정 방향에 대해 얘기하다 보면 생각지 못한 더 좋은 코드가 떠오르거나 어딘가에 있는 동일한 코드를 가져다 쓸 수 있음을 알게 될 수 있어서, 어떤 코드에 대해 수정이 고민이 된다면 담당 프로그래머와 얘기해 보는 것이 좋습니다.데이터 수정은 기획자에게 요청하자"쿠키런: 킹덤"에서는 기획자가 퀘스트 내용이나 쿠키의 능력치 같은 게임 데이터를 작업합니다. 적은 양의 데이터 수정일지라도 어떤 데이터는 서로 연결되어 있어 규칙에 맞게 입력해야 하고, 또 그 데이터를 수정하고 번역 요청을 하는 등 관리가 필요합니다. 따라서 데이터 수정은 담당 기획자에게 요청하는 것이 가장 안전합니다. (담당자한테 물어보자는 위 문단의 내용과도 유사합니다.)네트워크 환경이 항상 최선의 상태가 아닐 수 있음을 고려하자예를 들어서, 클라이언트는 서버와 통신을 할 때, 클라이언트가 서버에 보내는 모든 요청이 실패할 수 있음을 고려해야 합니다. 유저의 네트워크 환경이 다양하기 때문입니다. 요청이 실패하면 경우에 따라 유저가 말을 걸어도 NPC 가 반응을 하지 않는 등 의도하지 않게 게임에 갇힐 수 있습니다. 그래서, 요청이 실패했을 때 화면이 어떻게 나와야 하는지, 다

안녕하세요, SK플래닛 DevRel 매니저입니다. 오늘은 최근 화제가 되고 있는 개발자 소프트스킬 도서, "코드 너머, 회사보다 오래 남을 개발자"의 요약 및 독후감을 작성하여 보았어요~ (요즘 학교에서는 "독후감"이라는 표현보다는 자유롭게 책을 읽고 기록하며 생활 속에서 실천을 강조하는 "독서생활본(讀書生活本)"의 작성을 권장한다고 하는데요, 웬지 성찰/학습/개선이라는 패턴의 개발자 회고(Retrospect)와도 유사한 점이 많은 것 같습니다. 나의 업무와 회사의 문화를 회고하는 마음으로 퀵하게 작성해 보았사오니 참고 부탁드립니다!)돌아오는 7월 25일 (금) 19:00 ~ 22:00, 서울 서대문구 연희로2길 62 한빛미디어 B동 1층 리더스홀에서 100명의 청중을 모시고 "기술보다 강한 '나'를 만드는 실전 커리어 전략" 이라는 제목으로 본 책의 북토크를 진행하오니 관심있는 분들께서는 참고하시기 바랍니다(본 글을 포스팅하는 시점에는 이미 마감되었다고 합니다). 기타 자세한 사항은 여기를 참조하세요 => https://techtopic.skplanet.com/techseminar2025-2h/ (삼성전자, 우아한형제들, SKT, 카카오페이, (전)토스 DevRel 실무자의 생생한 이야기를 소개합니다!)1. 왜 이 책이 화제일까요?본 도서는 소프트스킬, 개발문화, 퍼스널 브랜딩 이라는 세 영역에서 주 독자인 개발자와 예비 개발자들에게 현업 사례와 경험과 함께 이들의 중요성을 전해 주는 실무서입니다. 문득 이 세 영역을 삼각형 으로 도식화해보고 싶은 생각이 들었는데요(책에는 없는 내용입니다 ^ ^), 각 꼭짓점인 소프트 스킬, 개발 문화, 퍼스널 브랜딩은 상호 보완하면서 개발자의 성공을 이끌어나가게 됩니다.• 소프트 스킬: 조직 안에서 협업을 가능하게 하는 또 하나의 "역량"• 개발 문화: 그런 소프트 스킬이 존중받고 발휘되는 환경• 퍼스널 브랜딩: 그 과정을 외부로 확장하여 커리어 기회를 넓히는 요소로 피드백 루프를 형성• 삼각형의 중심은 "지속 가능한 개발자의 성장" 을 추구 (개인적인 의견입니다)참고로 도서 정보는 다음과 같습니다.• 도서명: '코드 너머, 회사보다 오래 남을 개발자'• 핵심 메시지: 당신의 코드보다 '당신'을 기억하게 하라• 주요 주제: 소프트 스킬, 개발문화, 퍼스널 브랜딩으로 확보되는 결정적 경쟁력• 집필진: 국내 주요 IT기업의 만렙 DevRel 매니저님들 ^ ^본 챕터는 크게 "대화의 기술(휴먼은 코드로(만) 소통하지 않는다)"과 "회의의 기술(회의에서 눈도장 찍고 스카웃되기?)"의 두 파트로 크게 나눌 수 있는데요, 인간의 기본 활동인 듣기와 말하기가 회사라는 필드에서는 커뮤니케이션과 회의에서 나타나는데요, 나와 회사에서 바로 도입할 수 있는 실제적인 "스킬" 중심으로 정리되어 있는 것들이 인상적이었습니다. 자세한 내용은 책을 참조 부탁드리며, 저의 눈에 들어왔던 내용 일부만 공유드립니다.• 상대방을 진심으로 인정하는 것이 경청의 시작• 대화를 이어나갈 수 있는 질문 '스킬' 익히기• 왜(Why) 보다는 '무슨 이유로', '어떤' 을 선호하기• 말하기와 듣기의 비율은 3:7 로 유지• 상어 같은 대화자 vs. 고래 같은 대화자• 조언보다는 인정과 공감하기 등(2) 우테코 리사 코치가 말해주는 소프트 스킬의 중요성참고로 우테코는 "우아한테크코스", 즉 우아한형제들 회사 내 외부개발자 양성을 위한 교육조직으로 수 년간 좋은 개발자들을 양성하고 있습니다 - 박재성(포비) 님을 비롯하여 다양한 직무별 강사 및 소프트스킬 코치님들이 도움을 주고 계세요.이 챕터에서는 정확한 자기 인식의 힘이 나와 조직 성장의 시작점이라고 정의를 내리고 있는데요, (1) 개인 관점에서는 자기 인식에서 시작하여 자기 효능감과 회복 탄력성을 길러 나가고, (2) 조직과 리더 관점에서는 심리적 안전감을 잘 제공해 줄 수 있으면 행복한 개발자 문화가 이루어지겠구나 하는 생각이 들었습니다(제 의견은 책의 내용과는 살짝 다르지만 개인만으로는 힘들 수도 있다고 생각하거든요). (3) 유연성과 자기 결정력은 그 정반합(?)의 결과일 수 있겠다는 생각이 들었습니다. 개인적으로 좋아하는 내용들, 고민하는 내용들이 나와서 매우 반가왔고 동시에 이러한 요소들이 실제로 잘 Working하는지가 궁금하기도 했던 터라 흥미있게 읽었습니다(실은 독후감 초안은 이미 써놓았다가 포스팅을 못하고 있었...). 주요 내용은 다음과 같습니다.덧. 그러다가 어제 우형 피플실에 근무하시는 분께서 쓰신 일터의 설계자들이라는 책을 병행해서 읽게 되었는데 내용들이 상호보완되어 좀더 이해가 잘 되었고 "정말 회사에서 이런 부분까지 다뤄준단 말이야?" 하는 생각 역시 함께 들었습니다(조직 레벨에서 이 부분을 다뤄 준다면 개발자는 몰입할 수 있고 따라서 행복할 수 있겠네요. 다만 모든 회사가 규모나 상황상 이렇게 하기는 쉽지 않으니 어떤 펑션으로 도움을 받는 것도 현실적으로 필요하겠다는 생각이 듭니다). 참고로 이 책에서도 "관리보다 관심을", "심리적 안정감을 키우는 일터의 조건" 등의 컨센서스가 보였습니다.(3) 공유와 소통으로 키워가는 성장의 선순환이 챕터를 한줄 요약하면 "커뮤니티 및 기술 블로그와 함께 성장하기(feat. SK데보션 빌드업 스토리)" 로 적을 수 있을 것 같아요.소속 특징(?) 때문에 데보션 커뮤니티와 담당자를 종종 뵙고 있지만 감탄하는 것 중 몇 가지는 다음과 같은데요, (1) SKT에서 시작하였지만 이를 넘어 하이닉스, AX, 플래닛 등 SK ICT의 엔지니어를 아우르는 개발자 커뮤니티를 만들어 냈다는 것 (2) 오프라인 커뮤니티와 온라인 테크 블로그를 융합하여 운영하고 있다는 것 (3) 올해는 좀 성격이 바뀌었지만 수 년간 데보션을 채용 브랜드로까지 이끌어 냈다는 점입니다.아울러 올해는 역량개발 플랫폼으로의 새로운 도전 중으로, 다양한 스터디 모임을 진행하고 외부 전문가와의 교류를 추진하는 것으로 알고 있습니다(지난 주 판교 밋업 때는 엔비디아와의 개발자 협력 프로그램도 소개해 주셨네요!). 저도 작년부터 업무 관련해서 데보션 프로 활동으로 기여하고 있지만 개인적으로도 이 커뮤니티

• None 핵심 기술은? CLIP을 통한 이미지 임베딩• None 어떻게 만들었을까요?• None 예시 결과를 살펴볼까요?안녕하세요! 검색서비스팀에서 최근에 개발 중인 프로젝트를 소개하려고 합니다. 바로 “음식 사진을 넣으면 유사한 맛집 사진을 찾아주는 AI 시스템” 입니다.요즘 맛집을 찾을 때 사진 검색이 꽤 중요하다는 사실, 공감하실 겁니다. 그런데 먹고 싶은 음식은 있는데 어디서 파는지 모를 때는 어떨까요?예를 들어, “이 음식 진짜 맛있어 보이는데, 어디서 먹을 수 있지?” 라는 생각이 드는 순간, 그 사진을 넣기만 하면 비슷한 메뉴를 파는 식당을 추천해주는 AI가 있다면 정말 편리하겠죠.이런 니즈에서 출발해, 음식 사진 기반 맛집 검색 시스템을 개발하게 되었습니다.실제 사용 시나리오는 다음과 같습니다.• None 사용자가 음식 사진 한 장을 업로드합니다.• None 시스템이 유사한 맛집 이미지들을 찾아서 보여줍니다.• None 사용자는 이미지 결과를 보고, “오! 내가 딱 원하던게 여기에 파네! 여기 가야겠다” 하고 결정할 수 있습니다.핵심 기술은? CLIP을 통한 이미지 임베딩CLIP이란 무엇인가요?• None CLIP(Contrastive Language–Image Pretraining)은 OpenAI에서 발표한 모델로, 이미지와 텍스트를 동일한 임베딩 공간에 매핑할 수 있는 강력한 특성을 가지고 있습니다. 이 특성 덕분에 CLIP은 "이미지 검색", "텍스트-이미지 매칭", "멀티모달 분류" 등 다양한 작업에 활용됩니다.CLIP의 구조는 아래와 같습니다.• None 이미지 인코더: 주로 Vision Transformer (ViT) 또는 ResNet이 사용됩니다.CLIP은 다음과 같은 방식으로 학습됩니다.• None 대규모 웹 데이터 수집: 인터넷에서 수집된 수억 개의 (이미지, 캡션) 쌍을 학습 데이터로 사용합니다.• None 쌍별 유사도 학습 (Contrastive Learning): 이미지와 텍스트를 각각 임베딩한 후, 정답 쌍은 서로 유사하게, 나머지는 멀리 떨어지도록 학습합니다.• None 멀티모달 임베딩 공간 매핑: 학습을 통해 이미지와 텍스트가 같은 의미를 공유할 경우, 두 임베딩이 가까운 위치에 오도록 매핑됩니다.이 시스템에서는 CLIP의 이미지 임베딩 기능만 사용했습니다.즉, 텍스트는 사용하지 않고, 다음과 같은 흐름으로 진행했습니다• None 음식 이미지와 맛집 이미지 모두 CLIP의 이미지 인코더를 통과시켜 임베딩 벡터로 변환합니다.• None 벡터 공간상에서 사용자 이미지와 가장 가까운 맛집 이미지를 코사인 유사도 기준으로 검색합니다.• None 유사 이미지에 연결된 맛집 정보를 기반으로 사용자에게 식당을 추천합니다.CLIP은 학습 과정에서 이미지의 "의미"를 추상화해서 인코딩하기 때문에, 단순한 픽셀 유사도보다 훨씬 더 의미론적 유사도(semantic similarity) 를 잘 포착할 수 있습니다.예를 들어, 두 라멘 사진이 촬영 각도나 조명은 다르지만 “빨간 국물 + 파 토핑”이라는 시각적 패턴이 비슷하다면, CLIP은 이를 높은 유사도로 인식해줍니다.이처럼 CLIP은 단순한 이미지 분류기와는 달리, 이미지 간 의미적 관계까지도 이해하고 비교할 수 있는 강력한 멀티모달 모델입니다.이번 프로젝트에서도 그런 특성이 유사한 음식 사진을 정확하게 찾아주는 데 큰 역할을 했습니다.어떻게 만들었을까요?대략적인 구조는 다음과 같습니다. 음식 이미지와 위치 정보를 바탕으로, 사전 임베딩된 데이터에서 시각적으로 유사하면서도 반경 내에 위치한 음식 이미지를 검색한 뒤,해당 이미지에 연결된 메타데이터를 활용해 실제 식당 정보를 추천합니다.서비스의 기반이 되는 데이터는 내부적으로 보유한 맛집 데이터셋입니다. 맛집에 매칭되는 음식 이미지에 다음과 같은 정교한 메타데이터를 함께 연결해 저장했습니다• None 이미지가 소속된 식당의 고유 ID• None 음식점의 위도 및 경도 좌표음식 이미지를 이해하고 비교하기 위해 OpenAI의 CLIP-ViT-B/16 모델을 사용했습니다.이 모델은 이미지 하나를 입력받으면 512차원의 벡터(임베딩)으로 변환해주며, 이 벡터는 그 이미지의 시각적 특징을 압축해 표현하고 있습니다.예를 들어, 김치찌개 사진을 넣으면 [0.043, -0.112, 0.201, ..., -0.038] 처럼 변환되고 이 벡터는 김치찌개의 비주얼적인 특징인 붉은 국물색, 고기와 채소의 배치등을 담고 있습니다.이러한 방식으로 openai/clip-vit-base-patch16 모델을 사용해, 내부적으로 보유한 모든 음식 이미지에 대해 사전에 임베딩 벡터를 생성해두었습니다.사용자가 이미지를 업로드할 때마다 보유한 모든 음식 이미지와 하나씩 비교하는 방식은 계산량이 선형적으로 증가하기 때문에, 데이터가 많아질수록 성능 저하가 급격하게 발생합니다.예를 들어, 10,000장의 음식 이미지가 있다면 단 한 장의 쿼리 이미지를 비교하기 위해도 10,000회의 유사도 계산이 필요합니다.이를 해결하기 위해 사전에 모든 이미지에 대해 임베딩을 생성한 뒤, 고속 유사도 검색을 지원하는 FAISS 라이브러리를 사용해 다음과 같이 모든 음식점 이미지에 대해 색인하는 과정을 거쳤습니다.• None 사전 수집된 음식 이미지 데이터셋의 각 이미지를 CLIP 모델에 입력합니다.• None 각 이미지에 대해 512차원 임베딩 벡터를 생성합니다. (이 벡터는 이미지의 시각적 특징을 압축 표현한 것으로, 다른 이미지와의 유사도를 계산할 수 있는 기준이 됩니다.)• None 모든 임베딩 벡터를 FAISS의 인덱스 객체에 추가하여, 벡터 검색 인덱스를 구성합니다.이렇게 구축된 인덱스를 통해, 사용자는 쿼리 이미지 한 장만 업로드해도 수천~수만 개의 음식 이미지 중에서 가장 유사한 후보를 빠르게 검색할 수 있게 됩니다.이미지 임베딩과 FAISS를 이용해 시각적으로 유사한 음식 이미지를 검색할 수 있게 되었지만, 한 가지 문제가 남아 있었습니다. 바로 지역과 관계없는 음식이 추천될 수 있다는 점입니다.예를 들어 사용자가 서울 강남에 있으면서 마라탕 사진을 업로드했는데, 부산에 있는 마라탕

데이터와 AI 기반 서비스를 개발하며 느낀 것 중 하나는, AI의 발전 속도가 우리의 상상을 뛰어넘는다는 점입니다.특히 최근 LangChain Academy에서 공개한 'Building Ambient Agents with LangGraph' 강좌를 살펴보며, AI 에이전트의 패러다임이 완전히 바뀌고 있음을 실감했습니다.챗봇에서 앰비언트로, 패러다임의 전환우리가 지금까지 알던 AI 에이전트는 대부분 챗 인터페이스 기반의 일회성 상호작용이었습니다.질문하면 답하고, 요청하면 처리하는 방식이죠. 하지만 이제는 다릅니다.Ambient Agents는 말 그대로 '주변 환경'에서 자율적으로 작동하는 에이전트입니다.Slack 메시지가 오면 자동으로 분석하고, GitHub 이슈가 생성되면 스스로 처리 방향을 결정하며,이메일함을 지속적으로 모니터링하여 중요한 메일을 분류하고 응답까지 준비합니다.제가 직접 개발한 여러 서비스들을 운영하면서 느낀 점은, 반복적이고 패턴화 된 작업들이 생각보다 많다는 것입니다.고객 문의 분류, 데이터 전처리, 보고서 생성 등... 이런 업무들을 사람이 계속할 필요가 있을까요?⚙️ 앰비언트 에이전트의 핵심 특징기존 에이전트: "이메일 정리해 줘" → 처리 → 끝앰비언트 에이전트: 새 이메일 감지 → 자동 분석 → 중요도 판단 → 적절한 조치단순한 질답이 아닌, 며칠에 걸친 프로젝트 관리도 가능합니다.예를 들어, 고객의 요구사항을 분석하고, 관련 팀원들과 협의하며, 최종 결과물까지 추적하는 전 과정을 자율적으로 수행할 수 있죠.하나의 에이전트가 아닌, 수천 개의 전문화된 에이전트들이 백그라운드에서 각자의 역할을 수행합니다.마치 잘 조직된 회사의 각 부서처럼 말이죠.왜 인간의 개입이 여전히 중요한가?여기서 중요한 점은 '앰비언트'가 '완전 자율'을 의미하지 않는다는 것입니다.실제 서비스를 운영해 보면 알겠지만, 아무리 정교한 AI라도 100% 완벽할 수는 없습니다.특히 민감한 업무(이메일 발송, 고객 응대, 결제 처리 등)에서는 인간의 최종 승인이 필수적이죠.LangGraph가 제공하는 Human-in-the-loop 시스템은 다음과 같은 방식으로 작동합니다.• None 행동 승인/거부: "이 이메일을 정말 보낼까요?"• None 도구 호출 수정: "API 호출 전에 파라미터를 확인해 주세요"• None 명확성 질문: "이 고객의 의도가 A인가요 B인가요?"• None 상태 재검토: "현재 진행 상황이 올바른 가요?"이런 상호작용을 통해 결과 품질 향상, 신뢰도 증진, 에이전트 학습 및 성능 개선이 가능합니다.LangGraph는 단순한 프레임워크를 넘어 대규모 에이전트 운영을 위한 완전한 인프라를 제공합니다.• None 퍼시스턴스 레이어: 에이전트의 상태를 지속적으로 저장하고 관리• None 확장성: 급증하는 작업량에도 유연하게 대응• None 메모리 시스템: 피드백을 학습하고 점진적으로 개선제가 노코드 도구들로 서비스를 구축할 때 항상 고민되는 부분이 확장성과 안정성이었는데, LangGraph는 이 문제를 근본적으로 해결해 주는 것 같습니다.✉️ 실전 예제: 이메일 관리 앰비언트 에이전트강좌에서 다루는 이메일 관리 에이전트는 정말 실용적인 예제입니다.• None 기본 LangGraph 설정 - 에이전트의 기본 구조 구축• None Langsmith 평가 - 에이전트 성능 측정 및 개선• None 고객 불만 메일 즉시 에스컬레이션창업자 관점에서 본 Ambient Agents의 가능성데이터 기반 서비스를 여러 개 운영하면서 느낀 것은, 반복 업무의 자동화가 곧 경쟁력이라는 점입니다.• None 24/7 서비스: 인간의 근무시간에 구애받지 않는 지속적 서비스• None 일관된 품질: 감정이나 컨디션에 영향받지 않는 안정적 결과• None 확장성: 고객 증가에 따른 선형적 비용 증가 방지• None 데이터 활용: 축적된 패턴을 바탕으로 한 지능적 판단• None 통합 관리: 여러 시스템을 아우르는 통합된 워크플로우⏭️ 앞으로의 전망과 준비 방향AI 모델의 성능이 7개월마다 두 배씩 향상되고 있다는 것은, 우리가 상상하는 것보다 훨씬 빠르게 변화가 올 것이라는 의미입니다.앞으로 아래 내용을 바탕으로 미래를 위해 전략적으로 준비하고 공부하려고 합니다.• None 데이터 품질 관리: 에이전트 학습을 위한 양질의 데이터 준비결론적으로, Ambient Agents는 단순한 기술적 진보가 아닌 일하는 방식의 근본적 변화를 의미합니다.이제 우리는 AI와 협업하는 것이 아니라, AI가 우리를 위해 일하는 시대로 접어들고 있습니다.이 변화의 물결에 뒤처지지 않으려면, 지금부터라도 LangGraph와 같은 최신 기술을 학습하고 실제 프로젝트에 적용해 보는 것이 중요하다고 생각합니다.여러분도 곧 수많은 AI 에이전트들이 백그라운드에서 묵묵히 일하며, 정말 중요한 창의적 업무에만 집중할 수 있는 그런 미래를 경험하게 될 것입니다.

Flutter에는 다양한 상태 관리 라이브러리가 존재합니다. 대표적으로 Provider와 GetX, BLoC 등이 있는데요. 이전에 Flutter 인기 아키텍처 라이브러리 3종 비교 분석 - GetX vs BLoC vs Provider라는 글에서 이들 라이브러리의 고유한 특징과 장단점을 비교해 봤습니다.이번 글에서는 최근 인기를 얻고 있는 Riverpod을 소개하려고 합니다. Riverpod은 기존 Provider 라이브러리의 한계를 보완하기 위해 개발된 라이브러리로, 더 유연 하면서 강력한 기능을 제공해 개발자가 보다 쉽게 상태를 관리할 수 있도록 돕습니다. 먼저 Riverpod을 소개하고, Riverpod의 특징과 응용법, 유의할 점을 알아보면서 공식 사이트에는 없는 저만의 몇 가지 사용 기법을 공유하겠습니다.'상태'란 앱의 현재 상태를 나타내며, 다음과 같은 요소들이 상태에 해당합니다.상태 관리는 앱의 복잡성과 사용자 경험에 직접적인 영향을 미칩니다. 잘못된 상태 관리는 앱의 성능 저하, 예기치 않은 오류, 복잡한 디버깅 과정을 초래할 수 있습니다. 따라서 올바른 상태 관리 도구를 선택하는 것은 매우 중요한데요. 일반적으로 상태 관리 라이브러리는 다음과 같은 기능을 제공합니다.Riverpod을 처음 접하는 독자들을 위해 간단한 사용법부터 소개하겠습니다. Flutter에서 새 프로젝트를 생성하면 아래와 같은 ‘버튼을 클릭하면 숫자가 증가하는 간단한 앱’이 기본 샘플로 제공되는데요. 이렇게 제공되는 기본 코드와 Riverpod을 이용해 구현한 코드를 비교해 보겠습니다.아래 코드는 샘플 앱 생성 시 자동으로 생성되는 코드입니다.다음은 Riverpod으로 같은 예제를 구현한 코드입니다. 먼저 상태를 관리할 를 정의하고, 이를 화면(view)에서 사용하면 됩니다. 개발자가 정의한 의 생명 주기는 Riverpod이 자동으로 관리해 주기 때문에 개발자는 따로 신경 쓸 필요 없이 코드 작성에만 집중하면 됩니다.Riverpod만의 특징Riverpod의 사용법을 간단히 살펴봤는데요. 다음으로 다른 상태 관리 라이브러리와는 다른 Riverpod만의 특징을 소개하겠습니다.다른 상태 관리 라이브러리와 다르게 Riverpod은 서버에서 데이터를 가져와 출력하는 애플리케이션 구현에 초점을 두고 있으며, 이를 위해 아래와 같은 기능을 제공합니다.• 서버나 외부 모듈에서 데이터를 가져오는 동안 로딩 상태를 표현함• 한 번 불러온 데이터의 재사용과 유효 기간 설정다른 상태 관리 라이브러리는 위와 같은 기능을 구현하려면 별도의 상태를 기록하거나 로직을 작성해야 하는데요. 반면 Riverpod에서는 이런 기능들을 기본적으로 제공하고 있기 때문에 반복적인 코드 작성을 줄일 수 있습니다. 이는 개발 생산성을 높일 뿐 아니라 테스트할 항목도 줄이고 유지 보수 부담도 줄여 줍니다.Riverpod은 사용자가 작성한 의 생명 주기와 데이터 참조를 관리해 줍니다. 어디에서든 의 데이터를 필요로 할 때 이를 알아서 연결해 줍니다. 따라서 개발자는 복잡한 순서를 신경 쓸 필요가 없습니다. 또한 계층 구조가 아니기 때문에 가 특정 화면 구조에 묶여 있지 않습니다.지금부터는 공식 사이트에도 없는 활용 방법을 소개해 드리고자 합니다. 이를 위해 예시로 글 목록과 상세 화면이 있는 SNS 앱을 만들었는데요. 이 앱에서는 , , , 이렇게 총 세 개의 를 생성합니다.• : 글 목록에서 글쓴이로 검색하거나, 즐겨찾기 항목만 볼 수 있도록 필터를 제공합니다.• : 서버에서 글 목록을 불러와 화면 객체에 전달합니다. 리스트에서 특정 글에 대해 즐겨찾기 기능을 제공합니다.• : 서버에서 글의 상세 내용을 불러와 화면 객체에 전달합니다. 즐겨찾기 기능을 제공합니다.글 목록 화면에서 상단의 필터 조건이 변경되면 자동으로 글 목록을 새로 받아와 업데이트하도록 만들 수 있습니다. 즉, 글 목록 필터를 조작하는 코드를 일일이 찾아서 를 하는 기능을 넣을 필요가 없습니다.글의 상세 화면으로 이동할 때 이미 불러온 내용은 로딩 없이 먼저 표시할 수 있습니다.네트워크 상태에 따라 온라인과 오프라인 데이터를 유연하게 결합해 사용자에게 끊김 없는 화면을 제공하고, 오프라인 환경에서도 안정적으로 작동하는 앱을 구현할 수 있습니다.글의 상세 화면에서 업데이트된 데이터가 글 목록에도 반영되게 만들 수 있습니다.간단한 기능이라면 위와 같이 구현해도 되지만, 위 구조는 잠재적으로 문제가 발생할 수 있습니다. 즐겨찾기 기능이 있는 화면이 추가될 때마다 기존에 작성한 도 수정해야 하기 때문입니다. 기능이 추가될 때마다 기존 기능에 부작용이 생길 수 있는 구조는 좋은 구조가 아니므로, 아래와 같이 공통 부분을 분리해 를 추가로 생성하는 구조로 만드는 것이 좋습니다. 이곳에서는 글 목록 불러오기, 글 상세 불러오기, 즐겨찾기를 제공합니다.다음으로 Rivepod 사용 시 유의해야 할 점 세 가지를 알아보겠습니다.간 참조가 많아질수록 코드가 복잡해질 수 있습니다. 이는 유지 보수를 어렵게 만들 수 있으며, 특히 새로운 개발자가 프로젝트에 참여할 때 이해하기 어렵게 만들 수 있습니다. 따라서 를 설계할 때에는 가능한 한 단순하게 유지하는 것이 좋습니다. 각 의 책임이 명확해지도록 설계하고, 불필요한 참조를 최소화해 복잡성을 줄이는 게 좋습니다. 이와 관련해 두 가지 원칙을 적어 봤습니다.• Provider 간 참 조는 되도록 한 방향으로만 이뤄지도록 합니다. 예를 들어 즐겨찾기 가 사용자 프로필 를 참조한다면 반대 방향의 참조는 피합니다.• 양방향 참조가 필요하다면 중앙에서 상태를 관리하는 중간 를 만드는 것을 고려합니다. 앞서 '응용하기 4: 화면 간 데이터 동기화'가 그 예제입니다.안에서 를 사용할 때에는 성능 이슈를 고려해야 합니다. 너무 많은 는 잦은 데이터 로딩을 발생시켜 성능을 저하할 수 있습니다. 예를 들어 리스트 화면을 보고 있지 않아도 리스트가 여러 번 업데이트되는 경우가 발생할 수 있으니 필요한 부분에서만 상태를 구독하도록 설계해야 합니다.다중 사용이 불가피한 경우에는 나 을 적절히 사용해 이를 회피할 수도 있습니다.• : 지정된 시간 동안 새로운 이

시각장애인 전용 얼굴 인증 화면을 만든 이유토스에서는 송금이나 결제를 할 때 이상 거래가 감지되면, 보안을 위해 기능이 일시적으로 차단돼요. 이때 얼굴 인증으로 본인 확인을 해야 차단이 해제되죠. 대부분 사용자에게 얼굴 인증은 몇 초 만에 자연스럽게 지나가는 과정일 수 있지만, 시각장애인 사용자에게는 전혀 다른 경험일 수 있어요.정확한 지시 없이 카메라를 바라보며 시선을 고정하는 건 쉬운 일이 아니거든요. 다른 사람이 옆에서 “왼쪽으로 조금 더 고개 돌려보세요” 등의 도움을 줘야만 인증을 마칠 수 있는 경우가 대부분이었죠. 인증 없이는 송금 등 주요 기능을 사용할 수 없기 때문에, 시각장애인이 도움 없이 혼자서 인증 할 수 있는 환경을 만드는 건 꼭 필요한 일이었어요.그래서 인증팀과 논의 끝에 스크린리더 사용자 전용 얼굴 인증 과정을 따로 만들기로 했어요. 시각장애인 사용자를 직접 초대해 UT를 진행했고, 계속 이터레이션하며 새로운 흐름을 설계했죠.이 글에서는 UT에서 발견한 점을 시안에 어떻게 적용해갔는지 하나씩 소개해볼게요.얼굴 인증은 안내에 따라 여러 방향으로 고개를 돌리고, 몇 초간 가만히 있어야 해요. 처음에는 고개 돌리는 동작이 어렵지 않을까 싶어, 자세한 텍스트 안내를 준비했는데요. 막상 테스트해보니 대부분의 사용자가 무리 없이 잘 따라 하셨어요.문제는 그다음이었어요. 지금 얼굴이 제대로 인식되고 있는지, 내가 잘 하고 있는지 알 수 없다는 점이었죠. 기존 화면에서는 프로그레스 바로 진행 상태를 시각적으로만 안내하고 있었기 때문에, 스크린리더 사용자 입장에선 현재 상태를 파악하기 어려웠어요.단순히 숫자를 읽어주는 방식보다는, 프로그레스 바처럼 시각적인 요소를 청각적으로 더 직관적으로 전달하는 게 중요하다고 생각했어요. 그래서 ‘진행 중’ 사운드와 ‘완료’ 사운드를 인증 흐름의 각 단계에 삽입했어요.사용자들은 진행 과정에서 큰 불안 없이 훨씬 더 수월하게 따라올 수 있었어요. 청각 UX란 단순히 텍스트를 소리로 읽어주는 것을 넘어, 시각적으로 의미 있는 모든 피드백을 ‘소리’로 전환하는 일이라는 점을 다시금 실감할 수 있었죠. 이번 얼굴 인증 접근성 개선의 핵심도 바로 여기에 있었어요. 처음엔 텍스트만 읽히면 충분하다고 생각했지만, 실제로는 프로그레스 바와 같은 그래픽 요소에도 중요한 정보가 담겨 있었죠. 이 시각적 정보를 사운드로 ‘번역’하면서 비로소 사용자에게 직관적으로 느껴지는 UX를 구현할 수 있었어요.기존 얼굴 인증 플로우는 30초 동안 얼굴 인식에 실패했을 때, ‘다시찍기’ 버튼을 눌러야 해요. 그런데 UT 중 시각장애인 사용자가 이 버튼을 찾기 위해 화면을 더듬다가 자세가 흐트러지고, 다시 얼굴을 맞추기 어려워져 인증을 실패하는 경우가 있었어요.그래서 이 흐름을 바꿔보기로 했어요. 오류 피드백은 “얼굴이 원을 벗어났어요”처럼 간단한 토스트 메시지로 전달하고, 곧바로 다시 안내가 이어지도록 구성했어요. 버튼을 누르지 않아도 흐름이 자연스럽게 이어지도록 한 거죠. 사실 오류 메시지만 정확히 전달된다면, 굳이 버튼을 누