블로그 모아보기 - 인프런

서버와 연결을 유지하는 가장 단순한 방법, 폴링(Polling)

HTTP는 요청과 응답만 주고 받으면 통신을 종료합니다.클라이언트와 서버가 한 번만 메세지를 주고 받고 끊기는데, 이러한 특성을 '비연결성'라고 부르기도 하죠. 덕분에 HTTP는 확장성과 단순성을 확보할 수 있는데, 지난 30여년 웹의 역사가 이를 보여줍니다. 그러나 실시간성을 필요한 서비스에는 이러한 비연결성은 한계로 작용합니다."실시간으로 소식을 받고 싶다"이러한 요구를 어떻게 구현할 수 있을까요? 가장 단순하고 직관적인 방법은 끊임없이 요청을 보내는 것입니다. 점을 계속 찍으면 언젠가 선이 되듯이, 요청을 반복해 항상 연결되어 있는 것처럼 만드는 방식이에요.이러한 기법을 폴링(Polling)이라고 부릅니다. 원리이름 그대로 "끌어당기는 것"를 의미합니다. 클라이언트가 일정한 간격으로 서버에 "새로운 데이터가 있나요?"하고 묻는 요청을 보냅니다. 그럼 서버는 다음과 같이 응답합니다.새로운 데이터가 없으면: 빈 응답이나 204 No Content 상태코드를 실어 응답하고,새로운 데이터가 있으면: 최신 정보를 본문에 실어 응답합니다.클라이언트는 이 응답을 받은 뒤, 일정 주기가 지나면 같은 요청을 반복합니다. 이렇게 주고 받기를 무한이 이어가면서 서버의 최신 상태를 추척하는 원리에요. 비유폴링을 쉽게 이해하려면 "전화"에 비유해 볼 수 있어요.매번 전화를 걸어 "새로운 소식 있나요?"라고 묻습니다. 상대방은 소식이 있으면 알려주고, 없으면 "없어요"라고 대답합니다.이 전화를 하루에도 수십 번, 수백 번 거는 것입니다. 다만 전화 요금은 계속 쌓이고, 상대방은 꽤나 귀찮아할 할지도 모르겠습니다. 활용폴링은 초기의 채팅 애플리케이션이나 단순한 알림 시스템 따위에 제격입니다.예를 들어, 클라이언트가 5초마다 서버에 요청을 보내 최신 메시지가 있는지 확인합니다.서버에 메시지가 없으면: 204 NoContent 를 돌려주고,서버에 메시지가 있으면: 본문에 실어 응답합니다. 클라이언트는 서버로부터 받은 메시지를 화면에 표시하고, 5초 뒤 다시 요청을 보냅니다.이 단순하고 반복적인 구조만으로도 간단한 채팅은 충분히 구현할 수 있습니다. 특징과 한계폴링은 한 가지 매우 뚜렷한 특징을 가지고 있는데요.단순한 구현: 특별한 프로토콜이 필요 없고, 기존 HTTP 요청/응답 구조만 사용합니다. 개발자 입장에서는 빠르게 실험하고 결과를 확인하기 좋은 방식입니다. 단순하고 구현하기 쉽지만 단점도 있습니다.제한적 실시간성: 서버에 새로운 데이터가 있더라도, 클라이언트는 요청을 보내고 응답을 받을 때까지 기다려야만 이를 알 수 있습니다. 요청 주기가 길면 더 지연되고, 짧게 잡으면 서버 부담이 커질 수도 있어요.많은 트래픽: 데이터가 없어도 요청을 계속 보냅니다. 특히 사용자 수가 많을수록 트래픽은 더 늘어납니다. 대안물론 효율성과 실시간성을 동시에 확보하기 위한 다른 방법도 있습니다.롱 폴링(Long Polling): 서버가 새로운 데이터가 생길 때까지 응답을 지연시키는 방식입니다. 불필요한 응답은 줄일 수 있지만 여전히 비효율적인 부분이 있습니다.SSE(Server Sent Event): 서버가 클라이언트로 직접 이벤트를 푸시하는 방식입니다. 단방향 전송과 끊겼을 때 자동으로 재연결하는 것이 특징입니다.웹 소켓(WebSocket): 클라이언트와 서버가 양방향 연결을 유지하면서 실시간으로 데이터를 주고 받을 수 있습니다. 가장 강력하지만 환경 제약이 있을 수도 있습니다.폴링은 이들 기술의 출발점이라 할 수 있습니다. 가장 단순한 방법에서 출발해 점차 효율적인 방식으로 발전해온 흐름을 이해하는 것이 중요합니다. 정리폴링은 HTTP 연결을 유지하기 위해 주기적으로 요청을 반복하는 기법입니다.장점: 단순한 구현, 어디서나 동작 가능단점: 네트워크와 서버 자원 낭비, 지연 시간 존재비유: 계속 전화해서 "소식 있나요?"라고 묻는 것 폴링은 다소 비효율적이지만, 초기 웹에서 실시간성을 구현하는 첫걸음이었고, 지금도 간단한 용도로 사용하기 충분합니다. 무엇보다 롱 폴링, SSE, 웹 소켓과 같은 진화된 기술을 이해하기 위한 관문으로써 중요한 위치를 차지합니다.---폴링을 포함한 추가 프로토콜에 대해 깊이 이해하고 싶으시다면, 제가 준비한 강의 「웹 개발의 핵심, HTTP 완벽 가이드」 의 4편을 참고하시면 도움이 될 것입니다. 여기서 배운 지식을 실제 프로젝트에 활용해, 한 단계 성장한 개발자로 나아가실 수 있을 것입니다.이 강의에서 다루는 내용1편. HTTP 기본2편. 브라우져3편. AJAX4편. 추가 프로토콜5편. 보안6편. 성능

웹 개발･HTTP･네트워크･Polling

6

5

2차 효과는 피할 수 없다: 디자이너가 설계할 것은 ‘회복력’

통제 불가능한 세상에서 ‘손 놓지 않는’ 방법서비스를 설계할 때 우리는 늘 “이 버튼을 누르면 전환이 오를 거야”, “리뷰 리워드를 주면 후기 수가 늘 거야” 같은 1차 효과를 기대한다. 그런데 현실은 대부분 2차 효과로 돌아온다. 사람들이 우리의 의도를 그대로 따르지 않고, 보상과 규칙이 만드는 가장 쉬운 길을 찾아 움직이기 때문이다.문제는 간단하다. 2차 효과를 완벽하게 예측하고 제어할 수 있을까? 솔직히 불가능에 가깝다. 하지만 불가능하다고 해서 손을 놓을 수는 없다. 디자이너가 할 일은 “완벽 통제”가 아니라, 부작용이 생겨도 시스템이 무너지지 않게 만드는 것이다.이 글은 그걸 위해 꼭 알아야 할 5가지 렌즈(Perverse incentive, Cobra effect, Goodhart, Campbell, Reward A hoping for B)를 배달앱 리뷰 사례로 설명하고, 마지막에 “디자이너가 실제로 할 수 있는 일”을 정리한다. 배달 리뷰 리워드가 ‘역효과’로 변하는 이유0. 먼저 A와 B를 나누자B(진짜 목표): 주문 전에 도움이 되는 리뷰가 늘어나서, 사용자의 실패 주문이 줄어드는 것A(우리가 실제로 보상하는 것): “리뷰를 작성했다”는 사실(개수), 혹은 별점 평균 같은 쉬운 지표여기서부터 대부분의 문제가 시작된다. 1. Reward A, hoping for B: A를 칭찬해놓고 B를 기대하는 실수배달앱에서 흔한 문구: “리뷰 쓰면 서비스 드려요.”이건 사실 “리뷰 작성(A)”을 보상하면서, “유용한 리뷰(B)”가 늘어나길 기대하는 설계다.하지만 사용자는 이렇게 최적화한다:혜택을 받는 가장 쉬운 방법 = 짧게라도 리뷰를 남기는 것 그 결과 “맛있어요/굿/재주문각” 같은 리뷰가 쌓이고, 리뷰 수는 늘어도 정보 가치는 올라가지 않는다. 2. Goodhart’s Law: 숫자가 목표가 되면 숫자만 올리는 요령이 생긴다리뷰 ‘수’가 목표가 되는 순간, 리뷰는 정보가 아니라 점수판이 된다.최소 노력으로 점수를 올리는 방법: 복붙, 한 줄, 의미 없는 사진KPI는 상승하지만, 구매 결정에 도움은 줄어든다.즉, “리뷰가 늘었다”는 숫자보다 중요한 질문은 이것이다:“리뷰가 늘어서, 사용자가 더 잘 선택하게 되었나?” 3. Campbell’s Law: 걸린 게 크면(돈/노출/평가) 왜곡·조작이 늘어난다별점/리뷰가 노출·매출·패널티와 직결되는 순간, 평점은 정보가 아니라 ‘이해관계가 걸린 전장’이 된다.“별점 올려주면 서비스 더 드릴게요” 같은 거래 유인이 생기고경쟁/불만이 쌓이면 별점 테러, 분쟁, 의심 사례가 늘어난다.리뷰 요청 카드/메시지가 ‘별점 5점이면 서비스’처럼 사실상 거래가 되는 순간, 평점은 쉽게 왜곡된다.핵심은 “사람이 나빠서”가 아니라, 시스템이 그렇게 행동하도록 만든다는 것. 4. Cobra effect: 문제를 줄이려다 문제를 키우는 루프가 생긴다코브라 효과는 “문제를 없애려고 보상을 걸었더니, 누군가 그 문제를 ‘생산’해서 보상을 타먹는” 패턴이다.배달 리뷰에서 이게 강하게 나타나는 순간은 보통 이럴 때다:리뷰 보상이 확정적이고(100%)검증/상한이 약하고어뷰징 ROI가 높을 때(다계정/반복 주문/형식 리뷰 등)배달 리뷰는 대체로 Goodhart/역인센티브에 가깝지만, 다계정·반복 주문·리뷰 공장처럼 ‘리뷰를 생산’하는 구조가 붙는 순간 코브라 효과에 가까워진다. 5. Perverse incentive(역인센티브): 숫자는 좋아졌는데 가치가 나빠지는 결과정리하면, 배달 리뷰 리워드는 이런 결과를 만들 수 있다.리뷰 수는 늘었는데리뷰 신뢰가 떨어져사용자는 더 자주 실패 주문을 하고CS/환불/불만이 늘어난다.이게 역인센티브(Perverse incentive)다. “좋아지려고 한 설계”가 “나빠지는 결과”를 만드는 것. 결론: 디자이너는 ‘통제’가 아니라 ‘회복력’을 설계한다2차 효과를 0으로 만드는 건 불가능하다. 그렇다면 디자이너의 역할은 무엇일까?디자이너는 결과를 완벽히 통제하는 사람이 아니라,부작용이 생겨도 시스템이 무너지지 않게 만드는 사람이다.그걸 위해, 제품 안에 3가지를 심어야 한다.가드레일(Guardrails): KPI와 함께 품질/신뢰/안전 지표를 같이 둔다.예: 리뷰 수↑와 함께 (저품질/복붙 비율, 신고율, 리뷰 열람 후 주문 전환, CS 분쟁)을 동시에 본다.속도 조절 장치(Controls): 상한/쿨다운/검증/정렬 보정한다.“예: 단순 리뷰 작성이 아닌, "맛/양/포장/배달 체크+한 줄 코멘트" 같은 정보성 리뷰를 입력할 수 있도록 유도한다.롤백과 학습 루프(Recovery loop): 이상하면 멈추고, 규칙을 업데이트한다.예: 중복률/신고율이 임계치를 넘으면 즉시 ‘보상 조건 강화’ 또는 ‘상단 노출 로직 변경’을 적용한다. 2차 효과는 피할 수 없다. 하지만 우리가 설계할 수 있는 건 있다. 안전하게 실험하고 빠르게 회복하는 시스템. 그게 디자이너가 할 수 있는 가장 현실적인 ‘통제’일 것이다. 디논과 함께하는 독서모임의 일환으로 작성되었습니다.⬇ 독서모임 링크 ⬇https://inf.run/owwZX

UX/UI･UIUX･심리학･UX디자인･인프런챌린지･독서모임･디논

5

4

웹 보안을 이해하는 첫 걸음, XSS(Cross-site Scripting)

조금이라도 틈이 보이면 공격자는 이를 비집고 들어와 어플리케이션을 망가뜨릴 수 있습니다. 이런 위협을 미리 탐지하고 차단하는 것이 보안인데요. 다행히도 브라우져에는 기본적인 보호 장치가 있어서 웹 어플리케이션을 안전하게 지킬수 있습니다.이 덕분에 개발을 하면서 보안에 대해서 크게 신경쓰지 않았던 것 같습니다. 만약 브라우져의 보안 매커니즘과 이를 활용한 개발 지식을 잘 이해하고 있다면, 더 좋은 품질의 제품을 만들 수 있을 것이라고 생각합니다.이번 글에서는 보안 공격 가운데 대표적인 기법인 XSS에 대해 알아보겠습니다. 공격웹 문서는 기본적으로 정적입니다. HTML로 문서의 내용을 표현하고, CSS로 꾸미죠. 웹 어플리케이션이라고 부르는 핵심에는 자바스크립트의 역할이 큰데요. 돔(DOM)을 제어하고, 서버와 통신하기 위해 HTTP 요청 보내는 등, 웹을 "동적으로" 만드는 거의 모든 역할을 맡고 있기 때문입니다.그런데 바로 이 동적 특성 때문에 문제가 생길 수도 있어요. 소프트웨어가 의도하지 않은 방식으로 동작하게 만들 여지가 생기기 때문이죠. 예를 들어, 사용자가 폼에 이런 문구를 입력한다면 어떻게 될까요?"<script>alter('bump')</script>"겉보기에는 단순한 텍스트처럼 보이지만, 브라우져는 이를 단순한 문자열이 아니라 실행 가능한 자바스크립트 코드로 이해합니다. 만약 이 값이 검증되지 않고 웹 페이지에 삽입된다면, 우리가 의도하지 않았던 코드가 그대로 실행될거에요. 사용자는 화면에서 갑작스러운 알림창을 보게되는데, 다양한 공격의 시작점이 될 수 있습니다. 세니타이즈자바스크립트를 활용한 공격을 막기 위해서는, 사용자가 입력한 문자에서 위험한 스크립트를 찾아내고 제거해야 하는데요, 이를 "세니타이즈(sanitize)" 라고합니다. '살균처리'라는 의미로, 신뢰할 수 없는 코드나 데이터를 제거해서 웹 페이지가 안전하게 동작하도록 만드는 과정을 말해요.대표적인 도구가 바로 DOMPurify인데요, 플레이그라운드에서 아래 코드를 입력하면, 이 라이브러리가 렌더링에 안전한 문자만 남기고, 위험한 스크립트를 모두 제거할 겁니다."text <script>alert('bomb!!!')</script>" 이스케이프자바스크립트 뿐만 아니라 HTML 코드를 입력하는 것도 공격이 될 수 있어요."<h1>Bomb!!!</h1>"사용자가 폼에 이 텍스트를 입력한다면, 렌더링 과정을 통해 다른 문자와 달리 크고 굵게 표시될 거에요. 개발자가 의도하지 않은 디자인으로 보이는 거죠. 폼을 통해 비정상적인 코드를 주입한 공격입니다.어플리케이션 측면에서 보면 사용자가 입력한 데이터를 그대로 보여주는 것이 맞긴 합니다. 하지만 개발자는 사용자가 HTML이나 스크립트 코드까지 입력할 것이라고는 기대하지는 않았을 거에요. 이런 상황에서는 사용자가 입력한 문자를 마크업으로 해석하지 않고 텍스트로만 표시하는 것이 안전합니다.이스케이프(escape)는 원래 '도망치다', '따돌리다'라는 뜻을 갖는데요. 브라우져가 특정 문자나 태그를 해석하지 못하도록 안전한 형태로 변환하는 기법을 의미합니다. 즉, 브라우져가 위험한 문자를 잘못 처리하지 않도록 그 해석을 우회하게 만드는 것이죠."<" → "<"">" → ">"이러한 변환 작업을 통해 브라우저는 사용자가 입력한 값을 HTML 태그나 스크립트로 해석하지 않고, 텍스트 그대로 렌더링할 수 있습니다.Lodash 라이브러리의 escape 같은 함수를 이용하면, 사용자 입력값을 브라우져 렌더링에 안전한 텍스트로 변환할 수 있습니다. 다른 공격의 기점이 된다소개한 두 가지 공격은, HTML 문서를 제공한 곳과 다른 출처(Cross-Site)에서 만든 스크립트(Script)가 실행되는 데서 비롯됩니다.웹 페이지가 신뢰할 수 없는 입력 값 - 여기서는 사용자가 입력한 스크립트 - 을 그대로 처리하게 되면, 애플리케이션 의도와 무관하게 악성 코드가 주입될 수 있죠. 이런 취약점을 악용한 공격을 크로스 사이트 스크립팅(Cross-Site Scripting), 줄여서 XSS라고 부릅니다.XSS는 단순히 스크립트 한 줄이 실행되는 수준에서 그치지 않습니다. 이것을 발판 삼아 2차, 3차 공격으로 이어질 수 있다는 점에서 중요한데요. 사용자의 브라우저 환경을 직접 공격할 수 있다는 점에서 웹 개발자는 반드시 이해하고 있어야 합니다. 정리XSS를 기반으로한 공격은 외부 코드를 처리하는 것만으로는 충분하지 않습니다. 콘텐츠 보안 정책(CSP), 쿠키 설정(HttpOnly, Secure, SameSite) 등의 브라우져의 보안 정책 뿐만 아니라, HTTP의 보안 속성까지 잘 이해하고 있어야만 우리의 애플리케이션을 안전하게 보호할 수 있습니다. ---이 외에도 웹 개발에서 자주 등장하는 CORS, HTTPS 등의 주요 보안 기술 대해 깊이 이해하고 싶으시다면, 제가 준비한 강의 「웹 개발의 핵심, HTTP 완벽 가이드」 5편을 참고하시면 도움이 될 것입니다. 이 강의에서 다루는 내용1편. HTTP 기본2편. 브라우져3편. AJAX4편. 추가 프로토콜5편. 보안6편. 성능

웹 개발･HTTP･네트워크･보안･XSS

4

가장 먼저 떠오르는 것이 판단을 만든다

뉴스에서 항공 사고 장면을 연달아 본 날이면, 평소엔 아무렇지 않던 비행기 탑승이 갑자기 두려워지곤 한다. 통계로는 자동차가 더 위험하다는 말을 들어도 마음이 쉽게 바뀌지 않는다. 머릿속에서 선명하게 재생되는 장면이 판단의 첫 재료가 되기 때문이다. 이처럼 ‘쉽게 떠오르는 것’이 곧 ‘자주 일어나는 것’처럼 느껴지는 현상을 ‘가용성 휴리스틱’이라 한다. 일상은 ‘한 사례’로 쉽게 과장된다가용성 휴리스틱은 복잡한 확률을 계산하기 어려울 때 사람이 쓰는 지름길 사고다. 떠올리기 쉬운 사례일수록 더 그럴듯하고 더 흔하다고 판단한다. 그리고 그 판단이 굳어져 실제 확률을 체계적으로 과대평가하는 단계에 이르면 가용성 편향이 된다. 뉴스에서 사고를 자주 봐서 ‘사고 장면이 쉽게 떠오르는 것’은 휴리스틱의 작동이고, 그래서 ‘비행기는 실제보다 훨씬 위험하다’고 믿게 되는 것은 편향의 결과다. 이 과정은 감정과 결합될수록 강해진다. 충격적이고 시각적인 정보는 더 생생하게 남아 쉽게 가용해지고, 떠올린 이미지에 붙은 불안이나 분노가 위험 판단을 더 크게 부풀린다. 전체 발생률보다 한두 개의 사례를 더 믿는 ‘기저율 무시’도 곁에 붙는다. 결국 우리는 확률을 읽는 대신 기억을 읽는다.이 현상은 일상에서도 자주 드러난다. 강력 범죄 보도를 며칠 연속으로 본 뒤 “요즘은 밖이 너무 위험하다”는 말이 자연스럽게 나오고, 외출 자체를 피하게 된다. 친구 한 명이 중고거래 사기를 당했다는 이야기를 들으면 전체 거래가 ‘거의 다 사기’처럼 느껴져 정상적인 거래까지 의심하게 된다. 확률이 아주 낮은 사고를 한 번 상상한 뒤 “절대 하면 안 된다”로 결론 내리는 것도 비슷한 흐름이다. 떠오름이 강해질수록, 실제 빈도보다 ‘최악의 시나리오’가 판단을 밀어붙인다. 디지털 서비스에서는 이 심리가 어떻게 적용될까?디지털 서비스는 이 심리를 ‘이용’하기도 하고 ‘교정’하기도 한다. 예를 들어 지도 앱의 혼잡도 그래프는 사용자가 “지금 가면 붐빌까”를 판단할 때 떠올리는 근거를 바꾼다. 기능이 없으면 지난번 토요일 저녁의 혼잡한 기억 한 장면이 모든 판단을 지배한다. 그러나 그래프가 눈앞에 있으면, 사용자는 자신의 기억보다 화면에 보이는 수치를 더 먼저 떠올린다. 즉, 서비스가 사용자의 가용한 단서를 ‘기억’에서 ‘데이터 표시’로 재배치하는 셈이다. 이는 선택 피로를 줄이는 장점이 있지만, 동시에 그래프가 정답처럼 보일 때 과신을 낳을 위험도 있다. 주변 행사 같은 특수 상황, 표본이 적은 지역의 오차, 갑작스러운 유입 같은 변수를 사용자가 떠올릴 기회가 줄어들기 때문이다.그래서 좋은 설계는 정보의 가용성을 높이되, 불확실성도 함께 가용하게 만든다. 혼잡도 옆에 신뢰도 배지를 두거나, “오늘은 주변 행사로 변동이 클 수 있다” 같은 한 줄을 고정해 두면 사용자는 ‘가능한 오차’를 판단 재료로 다시 끌어올릴 수 있다. 수치 하나로 단정하기보다 범위를 보여주는 방식도 같은 목적을 가진다. 더 나아가 혼잡이 높거나 신뢰가 낮을 때 덜 붐비는 시간대나 비슷한 대안 장소를 바로 제시하면, 사용자의 머릿속에 떠오르는 선택지가 넓어진다. 여기서 핵심은 사용자가 떠올릴 수 있는 ‘대안’을 화면이 먼저 만들어 주는 데 있다. 그래프가 만든 단서의 힘을, 다시 다양한 선택으로 분산시키는 방식이다.보안 경고는 가용성 편향이 가장 강하게 작동하는 무대다. 해킹은 자주 겪지 않으니 대부분의 사용자는 “난 아직 문제 없었다”는 부재의 경험으로 위험을 낮게 평가한다. 반대로 “비밀번호가 노출되었다” 같은 경고는 피해 이미지를 즉시 소환해 위험을 크게 느끼게 한다. 이때 경고가 공포를 자극하는 방향으로만 설계되면 과잉 반응과 경고 피로를 동시에 부른다. 자주 뜨는 강한 경고는 결국 ‘또 뜬다’는 무감각을 더 가용하게 만들고, 공격자가 비슷한 패턴을 모방하기도 쉬워진다. 따라서 경고의 목표는 겁을 주는 것이 아니라, 사용자가 실행할 절차를 가장 선명한 단서로 만드는 데 있어야 한다. 위협 메시지 대신 “지금 가장 효과적인 조치 2가지만 하면 된다”는 식의 단계형 체크리스트가 앞에 오고, 나중에 하기 같은 선택권도 숨기지 않아야 한다. 사용자의 자율성이 보장될 때 경고는 압박이 아니라 도움으로 읽힌다.콘텐츠 추천에서도 가용성은 조용히 방향을 만든다. 넷플릭스의 Top 10 같은 행은 홈에서 반복 노출되며 특정 작품을 ‘가장 먼저 떠오르는 후보군’으로 만든다. 선택의 순간 사람은 수백 개 목록을 평가하지 않고, 떠오르는 몇 개 중에서 고른다. 여기에 “남들이 많이 본다”는 사회적 증거가 붙으면, 인기 자체가 품질 신호처럼 작동한다. 문제는 이 신호가 너무 강해질 때 탐색이 죽고 다양성이 줄어든다는 점이다. 또한 계산 방식이 불명확하면 “조작된 것 아닐까”라는 불신이 생긴다. 그래서 Top 10을 노출하더라도, 바로 옆에 ‘숨은 보석’이나 ‘취향과 비슷하지만 Top10 밖’ 같은 대항 레일을 페어로 붙여야 한다. 인기 외의 판단 단서인 장르, 길이, 톤, 완결 여부를 전면에 두면 사용자는 ‘인기’ 하나만 떠올리지 않게 된다. “최근 7일, 지역 기준”처럼 최소한의 범위를 명시하는 투명성도 불신을 줄이는 안전장치가 된다.노출을 늘려 익숙함을 쌓고 싶다면 더더욱 타이밍이 중요하다. 결정 직전에 “이게 정답”을 반복하면 정보가 아니라 압박이 된다. 대신 행동 이전에는 존재를 알리고, 행동 순간에는 화면을 단순하게 두며, 언제든 다른 선택으로 쉽게 이동할 수 있게 해야 한다. 무엇이 먼저 떠오르게 할 것인가결국 가용성 휴리스틱은 인간의 결함이라기보다, 제한된 자원으로 살아가는 방식이다. 문제는 그 지름길이 언제든 왜곡으로 넘어갈 수 있다는 데 있다. 디자이너가 만드는 UI는 사용자의 머릿속에 무엇을 쉽게 떠올리게 할지 결정한다. 한 줄의 문구, 색 하나, 배지 하나, 반복 노출되는 레일 하나가 판단의 출발점을 바꾼다. 그러므로 설계의 질문은 “무엇을 보여줄까”를 넘어 “무엇이 가장 먼저 떠오르게 될까”로 바뀌어야 한다. 편의를 주되 과신을 막고, 위험을 알리되 공포를 팔지 않고, 인기를 보여주되 대안을 숨기지 않는 방식으로 가용성을 다루는 것이 장기 신뢰를 지키는 길이다. 결국 그 균형이 사용자 경험을 만든다. 디논과 함께하는 독서모임의 일환으로 작성되었습니다.⬇ 독서모임 링크 ⬇https://inf.run/owwZX

UX/UI･UXUI･심리학･UX디자인･인프런챌린지･독서모임･디논

4

3

AI와 대화는 늘어나는데, 왜 더 외로워지나

AI와 대화하는 일이 일상이 됐다. 질문을 던지면 즉시 답이 오고, 감정을 털어놔도 비난받지 않는다. 그런데 이상하다. 더 많이 연결된 것 같은데, “관계가 얕아지고 외로움이 커진다”는 말이 자꾸 들린다. 이 역설은 왜 생기는가. 답은 단순하다. 대화가 늘어난 것과 관계가 쌓이는 것은 다른 일이기 때문이다. 사람은 ‘사람’을 너무 쉽게 만들어낸다가로등 두 개가 멀리서 보이면 순간 얼굴처럼 느껴질 때가 있다. 점 두 개만 있어도 뇌가 “눈”을 먼저 찾아내는 성질이 있기 때문이다. 이런 현상을 파레이돌리아라고 부른다.여기에 말투나 반응이 조금만 더해지면, 우리는 기계를 기능이 아니라 “누군가의 태도”처럼 받아들인다.“제가 도와드릴게요” 같은 1인칭 말투타이핑 중… 같은 신호기다림과 반응의 리듬이런 단서가 붙는 순간, 화면 속에 ‘거기 있는 느낌’이 생긴다. 이게 사회적 현존감이다. 문제는 여기서부터다. 그 ‘거기 있는 느낌’이 너무 편하면, 실제 사람에게 연락할 에너지가 줄어든다. “충분히 이야기한 것 같은 기분”은 생기는데, 정작 관계는 쌓이지 않는 상태가 된다. 편리함은 관계의 ‘불편’을 지워버린다사람 관계에는 불편이 있다. 타이밍을 맞춰야 하고, 거절당할 수도 있고, 말이 어긋날 수도 있다. 반면 AI는 기다릴 필요가 없고 상처받을 위험도 적다. 사람은 자연스럽게 위험이 적은 쪽으로 이동한다.이 선택이 반복되면, 사람 관계를 유지하는 작은 근육이 약해진다.먼저 연락하기어색함을 견디기갈등을 조정하기그러다 보면 사람 관계가 더 어렵게 느껴지고, 다시 AI로 돌아가게 된다. “더 편한 쪽”이 “더 익숙한 쪽”이 되기 때문이다. ‘진짜 소외된 사람들’에게는 도움이 된 사례도 있다“AI는 다 나쁘다”가 아니다. 진짜로 고립된 사람들, 특히 노인 외로움에서는 기술이 ‘작은 행복’을 만든 사례가 있다.말이 많지 않아도, ‘반응하는 존재’가 위로가 되는 경우뉴욕주 노인복지국(NYSOFA)은 사회적으로 고립된 노인에게 움직이고 소리를 내는 로봇 반려동물을 제공해왔다. 만지면 반응하는 작은 존재가 “누군가가 곁에 있는 느낌”을 만들고, 정서적 안정에 도움을 주는 방식이다. 이 사례가 시사하는 점은 간단하다. 외로움이 심한 순간에 꼭 “깊은 대화”가 필요한 게 아니다. 따뜻한 반응 하나가 하루를 버티게 하기도 한다.요양시설에서 동반 로봇이 외로움을 낮춘 연구도 있다. 물범 모양 동반 로봇 PARO는 요양시설 환경에서 진행된 무작위 대조 시험에서, 로봇과 상호작용한 집단의 외로움이 감소했다는 결과가 보고됐다. 핵심은 “사람을 대체하는 친구”가 아니라, 정서적 완충을 만드는 장치였다는 점이다.AI가 먼저 말을 걸고 루틴을 제안하는 ‘ElliQ’ 같은 시도NYSOFA는 노인 대상 AI 동반 로봇 ElliQ 프로그램을 운영하며 외로움 감소를 보고한 바 있다. 여기서 중요한 포인트는 “그냥 대화 상대”가 아니라, 먼저 제안하고, 작은 행동을 꺼내주는 설계에 있다. 행복을 주되, 의존은 키우지 않으려면 ‘다리’가 필요하다이쯤에서 결론은 단순해진다. AI/로봇이 행복을 줄 수 있느냐는 “기술의 선악”이 아니라 어떤 방향으로 설계했느냐에 달려 있다. 여기서 기준이 두가지 있다.대체(Substitute): AI 안에 오래 머물게 만들어 사람 관계를 약화시키는가다리(Bridge): 잠깐 안정시킨 뒤 사람/현실로 이어주는가 대화의 끝은 ‘더 대화’가 아니라 ‘현실 행동’이어야 한다.“한 줄 안부 보내기”, “내일 산책 약속 잡기” 같이 부담 없는 행동으로 닫아야 한다.친밀함은 기본값을 낮게, 필요할 때만 올려야 한다.너무 사람 같은 말투/애칭은 쉽게 의존을 만든다. “따뜻함 다이얼”처럼 조절 가능해야 한다.과사용 신호에는 ‘부드러운 쉬어가기’를 줘야 한다.심야·장시간·반복 사용일수록 “잠깐 쉬기/타이머로 마무리” 같은 선택지가 필요하다. AI를 더 사람처럼 만들기보다, 사람에게 더 닿게 만들어야 한다AI는 점점 더 사람처럼 느껴지게 된다. 그건 사실이다. 그리고 그 덕분에, 특히 고립된 노인처럼 “진짜 소외된 사람들”에게는 작은 안도감과 일상의 버팀목이 될 수도 있다. 다만 방향을 잘못 잡으면, 따뜻함이 관계를 대신해버릴 수 있다. 그래서 AI는 친구가 아니라, 연결의 다리로 설계되어야 한다. 그때 비로소 기술은 외로움을 덮는 것이 아니라, 행복을 조금씩 회복시키는 쪽으로 작동할 것이다. 디논과 함께하는 독서모임의 일환으로 작성되었습니다.⬇ 독서모임 링크 ⬇https://inf.run/owwZX

UX/UI･UXUI･심리학･UX디자인･인프런챌린지･독서모임･디논

3

[군대에서 6개월 동안 만든 프로젝트] 피드백 부탁드립니다!

1. 프로젝트 정보프로젝트명: NewCodes프로젝트 소개: 각 기업의 기술 블로그와 유튜브를 한 곳에서 만날 수 있습니다!링크:https://newcodes.net/기술 스택: Spring Boot, Java, MySQL, Docker, NginX, AWS, Prometheus, Grafana작업 기간: 2025.05 ~ ing각 기업에서는 좋은 글을 꾸준히 쓰고 있습니다.하지만, 막상 그 좋은 글에 들어가보면 댓글은 전혀 달리지 않는 모습에 안타까웠습니다.이렇게 좋은 컨텐츠를 개발자들 사이에 더 널리 알리고 싶었습니다.그래서 만들었습니다! 2. 피드백 받고 싶은 내용주로 사용성과 기능 개선에 대해서 피드백을 받고 싶습니다.더 있으면 좋을 것 같은 기능, 혹은 업그레이드 했으면 하는 기능이 있다면 알려주시면 감사하겠습니다. 또, 기술적으로 도전해볼 법한 부분을 말씀주셔도 좋습니다.솔직히 이력서에 적을만한 날카로운 경험이 많이 있진 않습니다.캐시 관련해서 로컬 캐시 도입, NginX 및 CDN 도입, event 기반으로 캐시 evict사용자 피드백 반영해서 기능 구현했던 경험 (ex. A 필요해요! => A 구현)운영 중 크롤링 chrome 프로세스로 인한 memory leak 감지 및 대처N+1 문제 해결 및 쿼리 튜닝, 인덱스 도입현재 이 정도 있습니다. 그나마 어필할만한 경험은 1번, 3번이라 생각합니다.해당 프로젝트에서 또 어떤 도전과 경험을 통해 제 기술적 실력을 증빙할 수 있을지 고민입니다. 3. 기타 참고사항이 웹은 제가 2025년 5월부터 군대에서 만들기 시작한 프로젝트입니다.남는 시간을 틈틈이 활용하여 사지방에서 개발을 해왔습니다.보통 하루에 2시간 정도는 투자했었습니다.개발 환경이 많이 제약되어 있어서 어려움도 많이 겪었습니다.사회에서 평소 개발하던 만큼의 효율이 나오지 않아 속으로 답답했던 적도 있었습니다.하지만 그래도 매일 꾸준히 하다보니 결국 최소한의 완성을 할 수 있었습니다.NewCodes는 앞으로도 양질의 컨텐츠를 널리 알리기 위해 힘쓸 예정입니다.제가 군 복무하는 동안만큼은 꾸준히 관리할 계획입니다. (26년 12월 전역이네요 하하..)

웹 개발･개인프로젝트･피드백

3

2

기다림이 사라진 대신, 참을성이 사라졌다

#사소한 짜증이 너무 자주 생긴다로딩 화면이 잠깐 멈추면 괜히 휴대폰을 내려놓게 된다.메신저에 ‘읽음’이 찍혔는데 답장이 오지 않으면, 별일 아닌데도 신경이 쓰인다.결제 버튼을 눌렀는데 바로 완료 화면이 뜨지 않으면 다시 한 번 더 누른다.엘리베이터 버튼도 한 번이면 충분한데, 괜히 두 번 누른다.이런 순간들이 하루에 몇 번이나 반복된다.크게 화가 나는 것도 아닌데, 마음이 자꾸 바빠진다.문득 이런 생각이 들었다.나는 언제부터 이렇게 참을성이 없어진 걸까? #성격 문제라고 넘기기엔 너무 많은 사람들이 비슷하다처음에는 그냥 성격 탓을 했다.요즘 사람들이 다 그렇지 뭐, 나만의 문제는 아니라고.그런데 가만히 주변을 보면 나만 그런 것도 아니다.카페에서 주문이 조금 늦어지면 주변을 둘러보게 되고,배달 앱에서 라이더 위치가 멈춘 것 같으면 괜히 화면을 새로고침한다.영상이 끊기면 바로 뒤로 가거나 다른 콘텐츠를 찾는다.이쯤 되면 개인의 인내심 문제라고만 보기에는 이상하다.그래서 질문을 바꿔보게 된다.내가 참을성이 없어졌을까,아니면 참을 수 있는 상황이 사라졌을까? #우리는 정말로 ‘기다리지 않게’ 되었다요즘의 디지털 환경은 기다림을 최소화하는 방향으로 설계되어 있다.앱은 누르는 즉시 반응한다콘텐츠는 끝나기 전에 다음 편이 자동 재생된다배송은 ‘언젠가’가 아니라 ‘내일 도착’이 기본값이다메신저에서는 상대가 접속 중인지, 입력 중인지까지 보인다기다림은 점점 줄어들었고,우리는 기다리지 않아도 되는 환경에 익숙해졌다.문제는, 기다림이 사라지면서그 사이에 있던 시간도 함께 사라졌다는 점이다. #기다림은 단순한 공백이 아니었다예전의 기다림은 아무것도 하지 않는 시간이 아니었다.답장을 기다리며‘아직 바쁜가 보다’라고 스스로를 진정시키는 시간이 있었고,결과를 기다리며기대치를 조금 낮추고 마음의 여지를 만드는 과정이 있었다.기다림은 감정을 정리하고 조절하는 시간이었다.조금 불안해도, 조금 답답해도그 시간을 지나며 마음이 한 번 가라앉았다.하지만 지금은 다르다.결과는 즉시 주어지고, 감정은 준비할 틈이 없다.그래서 아주 사소한 지연에도 감정이 바로 튀어나온다. #예민해진 게 아니라, 완충 장치가 사라진 것일지도 모른다요즘 사람들은 유난히 예민해 보인다.작은 지연에도 불안해하고,조금만 예상과 달라도 쉽게 짜증을 낸다.하지만 이걸 단순히 “요즘 사람들은 참을성이 없다”라고 말해도 될까.어쩌면 우리는 예민해진 게 아니라,감정을 완충할 시간을 잃어버린 상태에 가까운지도 모른다.기다림이 사라진 자리에는즉각적인 반응만 남았고,그 사이를 메워주던 여유는 점점 줄어들었다. #그래서 조급함은 개인의 문제가 아니다책에서는 사람들이 불확실한 상황을 견디는 데 생각보다 많은 에너지를 쓴다고 말한다.기다림은 바로 그 에너지를 천천히 쓰게 해주는 장치였다.하지만 즉각적인 피드백이 기본이 된 환경에서는그 에너지를 쓸 기회 자체가 줄어든다.그러다 보니 우리는 스스로를“왜 이렇게 참을성이 없지?”라고 탓하게 된다.사실은 사람이 달라진 게 아니라,사람을 둘러싼 조건이 달라진 것에 가깝다. #기다리지 않아도 되는 세상에서어쩌면 요즘의 조급함은 개인의 성격 문제가 아니라너무 매끄러워진 디지털 환경이 만들어낸 부작용일지도 모른다.기다리지 않아도 되는 세상에서우리는 점점 기다리는 법을 잊어가고 있다.그리고 그 사실을,참을성이 없어진 나 자신의 문제로 오해하고 있을지도 모른다.

UX/UI･UI･기다림･참을성･심리학･디자인･디논･독서모임･챌린지

2

디지털 디톡스 사례로 살펴본, 행복을 주는 디자인

요즘 디지털 환경에서 느끼는 피로는 단순히 사용 시간이 많아서라기보다,계속해서 무언가에 반응해야 한다는 압박감에서 오는 경우가 많다.이번 주차 미션에서는 이러한 문제의식 속에서디지털 디톡스를 고려한 디자인 사례들을 ‘행복을 주는 디자인’의 관점으로 살펴보고자 했다.아래 사례들은 모두 사용자를 더 오래 붙잡기보다는,사용자가 스스로 디지털과의 거리를 조절할 수 있도록 돕는 디자인이라는 공통점을 가진다. #디지털 디톡스를 고려한 디자인 사례1. Apple의 집중 모드(Focus Mode)애플의 집중 모드는 모든 알림을 무조건 차단하는 방식이 아니라,상황에 따라 필요한 알림만 선택적으로 허용할 수 있도록 설계되어 있다.‘업무 중’, ‘휴식 중’, ‘수면 시간’처럼 사용자의 상태를 기준으로 디지털 환경을 재구성해 준다는 점이 특징이다.이 기능은 사용자가 알림을 무시하고 있다는 죄책감을 느끼지 않게 만들고,지금은 반응하지 않아도 괜찮은 시간이라는 신호를 시스템 차원에서 제공한다. 2. Instagram의 ‘Take a Break’ 기능인스타그램은 일정 시간 이상 콘텐츠를 소비하면“잠시 쉬어가도 괜찮다”는 메시지를 사용자에게 보여준다.계속해서 스크롤하도록 유도하는 대신, 의도적으로 멈출 수 있는 계기를 제공하는 디자인이다.이 기능은 사용자의 행동을 강제로 제한하지 않지만,계속 머물러야 할 이유가 없다는 점을 부드럽게 상기시킨다. 3. YouTube의 자동 재생 제어유튜브의 자동 재생 기능은 한때 ‘계속 시청’을 자연스럽게 만드는 대표적인 설계였다.하지만 최근에는 자동 재생을 끄거나, 사용자가 다음 행동을 선택하도록 하는 구조가 강조되고 있다.이 변화는 콘텐츠 소비의 흐름을 끊고,“여기서 멈춰도 된다”는 선택지를 사용자에게 돌려준다. 앞서 살펴본 사례들은 모두 사용자의 감정을 직접적으로 자극하거나 조작하려 하지 않는다.대신 사용자가 디지털 환경을 어떻게 해석하고 인식하는지에 초점을 맞춘다.이는 책에서 설명한 파레이돌리아(paraeidolia) 개념과도 연결된다.사람은 의미 없는 자극에도 의미와 의도를 부여하는 경향이 있으며,디지털 환경에서는 알림, 숫자, 반복적인 반응이 실제보다 훨씬 더 중요한 신호처럼 인식되기 쉽다.이러한 인지 특성 때문에 사용자는 단순한 알림에도 ‘지금 반응해야 할 것 같은 느낌’을 받거나,디지털 서비스와 마치 관계를 맺고 있는 것처럼 감정을 투사하게 된다.책에서 AI나 디지털 대상이 사람처럼 느껴지는 이유 역시이러한 반복적인 상호작용과 감정 투사 때문이라고 설명한다. #감정을 줄이는 것이 아니라, 해석의 단서를 줄이는 디자인내가 찾은 디지털 디톡스 사례들은 사용자의 감정을 억제하거나 차단하려 하지 않는다.대신 감정이 과도하게 발생할 수 있는 단서 자체를 줄이는 방식을 선택한다.알림의 빈도를 줄이고,계속 이어지는 상호작용의 흐름을 끊고,사용자가 스스로 멈출 수 있는 선택지를 제공함으로써디지털 대상과의 관계가 과도하게 형성되는 것을 방지한다.그 결과 사용자는 디지털 환경 속에서도 감정 소모 없이 머물 수 있게 되고,이 안정감은 ‘편안하다’, ‘괜찮다’라는 감정으로 인식된다.이러한 감정이 바로 책에서 말하는 '행복한 사용자 경험'의 한 형태라고 생각한다. #행복을 주는 디자인이란...이 사례들을 정리하며나는 행복을 주는 디자인을 다음과 같이 정의하게 되었다.행복을 주는 디자인이란사용자를 계속 붙잡는 디자인이 아니라,사용자가 스스로 거리를 조절할 수 있게 해주는 디자인이다.디지털 디톡스를 고려한 디자인은 즉각적인 즐거움을 제공하지는 않을 수 있다.하지만 사용자가 디지털 환경 속에서도 자신의 리듬을 잃지 않도록 돕는다는 점에서장기적인 안정감과 안도감을 제공한다.그리고 이것이 바로 ‘사용자를 행복하게 하는 UX’가 아닐까 생각한다. #참고 문헌 : https://www.frameout.com/insight-news/designing-for-digital-wellbeing##디논과 함께하는 독서모임의 일환으로 작성되었습니다.#독서모임 링크 : https://inf.run/hYv8f

UX/UI･UI･디지털디톡스･심리학･디자인･디논･독서모임･행복한디자인･챌린지

2

1

인공지능과 추천 시스템 강의 노트 - 2025.10.4(5주), 2025.10.10(6주)

2025.10.4. / 2025.10.11들어가며학기 초부터 예상을 한 것이긴 하지만, 대체 휴일을 포함하며 매우 긴 추석 연휴가 주어지며, 토요일 수업을 진행하는 입장에서 꽤 난감한 상황이 되었다. 토요일에 수업을 배정할 때부터, 소위 빨간 날인 휴일은 아니지만 그렇다고 열흘 연휴 중 두번이나 여의도에 등교하는 것을 강제하는 게 적절한가 등의 고민이었고.. 나도 개인적으로 명절을 한국에서 보내기 여의치 않은 상황이어서 두 번의 강의를 온라인으로 진행하는 것으로 하기로 하였다.그래도 라이브 유튜브 하는 것처럼 댓글도 달리고 하면 좋겠다는 생각을 했지만, 미국의 금요일 밤 11시나 한국의 오후 3시나 여의치 않은 상황이어 녹화 영상을 송출하는 방식으로 진행했다. 팟캐스트 등의 댓글로 서로 궁금한 걸 나누면 좋을텐데, 이건 내 역량의 한계인가 싶기도 하다.같이 보면서 이야기나눌 수 있는 내용들을, 한편으로는 가볍게 보았으면 하는 마음으로 링크들을 공유했는데, 수업의 특성 상 반강제로 끝까지 보아야 출석 인정이 되게 되었다. 기왕이면 이전에 보지 않은 클립들이면 싶고, 흘려 듣더라도 내가 받았던 감동을 받으면 좋겠다는 생각이다. 이번 글은 나누었다기보다는 그냥 준비한 내용들을 흘려 보낸 에 가깝고, 후속으로 나누고 싶은 이야기들은 언제든지 환영한다. 준비한 내용들 - 5주5주) 강의 updateSearch by GoogleGoogle — 25 Years in Search: The Most Searched ( 2024, 4min )Google — Year in Search 2024 ( 2024, 4min ) The Evolution of Search ( 2011, 6 min )How Google makes improvements to its search algorithm ( 2011, 4 min )Search Quality Meeting: Spelling for Long Queries (Annotated) ( 2012, 8 min ) Google Instant Launch Event ( 2010 , 1h 26m ) - Google Instant ( 15 ~ 52, 37min )Inside Search Event ( 2011, 59 m ) - Google instant pages , ( 0 ~ 23, 10 min ) Google I/O 2015 - Smarter user acquisition with App Indexing, AdWords and Google Analytics (2015, 20 min ) 5번째 주는 구글 검색에 대한 내용들을 모았다. 개인적으로 일에 관련된 모든 것들을 좋아하던 시절의 이야기들이고, 기술적인 챌린지들도 내용도 꽤 아는 이야기들을 press event 로 녹여 내던 시기의 이야기들을 주로 담았다. 개인적으로는 search quality review meeting 이 밖으로 더 널리 알려지면 하는 바람도 있고, 자주는 아니지만 google I/O 에 검색팀이 나가야만 했던 그 시절 상황도 알려지면 하는 생각이다. 이후의 Google I/O 이벤트들은 전문가들의 손길이 다양한 데서 닿았던 거라 그시절의 낭만은 더이상 없는 듯해서인지 그래서 좋은 기억으로 남아 있는 거 같다. 준비한 내용들 - 6주AI until 2025Ted Talk : How we're teaching computers to understand picturesby Fei-Fei Li ( March 2015 , 18 min )Ted Talk : How AI could empower any business by Andrew Ng ( April 2022, 11 min ) Ted Talk : Why AI is incredibly smart and shockingly stupid by Yejin Choi ( April 2023 , 16 min )Building AI for Everyone | Jeff Dean Senior Fellow in Google AI ( 2018, 세바시 강연, 16 min ) The future of computing: a conversation with John Hennessy (Google I/O '18) ( May 2018, 25 min )Jeff Dean (Google): Exciting Trends in Machine Learning ( 2024, 70 min ) 6번째 주는 AI 관련된 몇몇 talk 들을 역시 사심을 담아 공유하였다. AI 쪽으로 발을 디딜 때 접하게 되었던, data driven 의 세상을 접하면서 알게 된 감동을 하나씩 공유하려 주고 싶었지만, 요즈음의 AI 는 그당시 쥐어 짜던 시절의 ML/DL의 조금은 수줍던 접근이 더이상 아닌 거 같아 살짝 아쉬운 부분이 있다.구글에 10여년 다니며, 지금은 전직장 동료(?)가 노벨상을 받았다는 억지스런 자랑거리도 있다지만, 말로만 듣던 대가들을 살짝 가까이에서 볼 수 있었던 것에 대한 감동, 또 그들이 자기자신들의 한계를 넘는 모습을 접할 때 큰 울림이 있어 왔다. 물론 그들의 한계라는 것조차 내가 임의로 그린 것이겠지만… 그 중 몇몇은 지금 보아도 전율이 이는데, 살짝 길지만, 그 중 두명의 이야기를 나누고 싶었다.하나는 2018년 google I/O 때 John Hennessy 옹(? 님?)께서 훑어 주신, 컴퓨터 구조에서 시작한 ML / domain specific programming 에 대한 이야기로, 마치 지금의 transformer 지배적인 세상을 예측한 듯한 대가의 말씀, 그것도 엄청나게 열정적인 자세로… 진정 저렇게 나이 들고 싶다는 생각을 했었다. 다른 하나는 Jeff Dean 의 구글 AI/ML summary. 당시 Brain 팀의 수장이었지만, 그 누가 이토록 꿰뚫는 이야기를 할 수 있을까, 그리고 그걸 듣는 입장에서 수긍할 수 있을까 등의 감정으로 보았던 내용들이라 하겠다. 제품과 기술 둘 중에서 꽤 많이 기술 이야기이긴 하지만, 기술자 identity 인 나의 시각에서 수업에 지장이 안 간다면 꼭 나누어 주고 싶은 이야기들이 클립들에 담겨 있다 하겠다. 약간의 사족구글에 조인할 때 founder, celebrity 들을 보고 선택을 한 건 아니었지만, 이후에 내가 tech 회사를 차린다면 혹은 조인한다면 Jeff Dean 혹은 Craig Silverstein 같은 사람을 회사 내에서의 코드나 업적으로 만나길 바라게 되었다. 이후에 나타난 회사를 옮겨 다니는 네임드들을 접할 때, 이들이 구글에서 이루어 낸 '업적'을 고려해 보게 되는데, 훨씬 더 다양한 일들이 있게 되는 복잡해 진 요즘 세상에, 특히 engagement 를 고민하게 될 때 그 시절의 낭만은 꽤 그립다.

대학 교육 기타･인공지능･추천시스템

1

5%의 복잡도로 80%의 성능을 제공하는 DB Router routemate 소개드립니다.

안녕하세요.최근 개인적으로 사용하기 위해 만들었다가 오픈소스로 공개한 DB Router 라이브러리 routemate를 소개드립니다.왜 만들었나실무에서 다음과 같은 상황을 자주 겪었습니다.Read/Write DB 분리가 필요하지만ShardingSphere, Vitess 같은 솔루션은 도입 비용이 너무 큼단순한 R/W 분기만 필요한데 설정과 학습 비용이 과도함트랜잭션, AOP, ThreadLocal, DataSource 라우팅을 매번 직접 구현결국 매 프로젝트마다“비슷한 코드를 또 만들고, 또 검증하고, 또 사고를 치는” 상황이 반복됐습니다.그래서 목표를 이렇게 잡았습니다.복잡한 기능은 과감히 버리고실무에서 가장 많이 쓰는 80%만 아주 단순하게 제공하자Routemate는 무엇인가Routemate는 Spring 기반 환경에서 사용할 수 있는경량 Read/Write DB Router 라이브러리입니다.Read / Write DataSource 자동 분기Spring Transaction 연동AOP 기반으로 투명하게 동작최소한의 설정Starter 형태로 바로 사용 가능Sharding, 분산 트랜잭션, 멀티 키 라우팅은 지원하지 않습니다.의도적으로 지원하지 않습니다.설계 방향1. 설정은 최대한 줄인다application.yml 몇 줄로 끝복잡한 rule DSL 없음DataSource 개수만 알면 바로 사용 가능2. Spring이 이미 제공하는 걸 최대한 활용한다@Transactional(readOnly = true) 기반 라우팅ThreadLocal 최소 사용Spring AOP 라이프사이클에 자연스럽게 녹임3. “왜 이렇게 동작하는지” 바로 이해 가능해야 한다코드 양이 적음내부 로직이 단순함디버깅 시 추적이 쉬움언제 쓰면 좋은가단일 Master + 다수 Replica 구조Read 부하가 높은 서비스Sharding까지는 필요 없는 서비스언제 쓰면 안 되는가복잡한 샤딩 전략이 필요한 경우멀티 테넌트 기반 라우팅DB 레벨의 강력한 일관성 제어가 필요한 경우이 경우에는 기존 대형 솔루션이 더 적합합니다.현재 상태Maven Central 배포 완료Spring Boot Starter 제공개인 프로젝트 및 토이 프로젝트에서 사용 중문서 및 예제 지속 보완 중GitHubhttps://github.com/KrongDev/routemateREADME에 개념 설명, 설정 방법이 정리되어 있습니다.마무리이 라이브러리는“정답 솔루션”을 만들고 싶어서 시작한 게 아니라,실무에서 반복되던 불편을 조금이라도 줄이기 위해 만들었습니다.혹시 비슷한 문제를 겪고 계셨다면가볍게 한 번 살펴봐 주셔도 좋겠습니다.피드백, 이슈, PR 모두 환영합니다.읽어주셔서 감사합니다.

opensoruce･java･router･spring

1

'AI 취업 비서' 서비스를 만들어봤어요 피드백 부탁드립니다

안녕하세요! 저는 컴퓨터학부 4학년에 재학 중인, 프론트엔드 개발자를 꿈꾸는 학생입니다. 🧑‍💻취업 준비를 하다 보니 노션, 메모장, 파일 폴더... 자기소개서가 여기저기 흩어져 있어 관리가 너무 힘들더라고요. 특히 작성하려고 하는 주제와 관련된 내용의 자기소개서를 찾는 게 어려웠습니다. 지원 현황부터 자기소개서 관리, 자기소개서를 작성하면서 기존 자료 참고, 자신의 자기소개서를 기반으로 AI 초안, AI 맞춤법 교정, AI 예상 면접 질문까지 한 서비스에 모두 담았습니다!1인 개발이라 아직 부족한 점이 있을 수 있지만, 여러분의 피드백을 받아 더 좋은 서비스로 발전시키고 싶습니다. 많은 관심 부탁드려요![🔥 주요 기능 소개]1⃣ 지원 현황 칸반보드 📊 "이 회사 마감 언제였지?" 노션 정리는 그만! '작성 중 → 지원 완료 → 면접 → 결과' 프로세스를 칸반 보드로 시각화하여, 드래그 한 번으로 지원 현황을 관리하세요.2⃣ 태그 기반 자소서 관리 & 검색 🏷#리더십#직무경험 태그만 검색하면, 과거에 썼던 모든 경험이 카드로 정리되어 나옵니다. 필요한 문장만 쏙쏙 뽑아 쓰세요.3⃣ 나를 학습한 AI 초안 작성 🤖 빈 화면만 보면 막막하신가요? 핵심 키워드만 입력하세요. AI가 내 경험과 문체를 학습하여 나만의 이야기가 담긴 초안을 써줍니다.4⃣ 전문 에디터급 AI 교정 ✨ "이 문장 좀 어색한데..." 싶을 때 버튼 하나만 누르세요. 단순 맞춤법 검사를 넘어, 신뢰감 있는 어조로 문장을 매끄럽게 다듬어 드립니다.5⃣ AI 면접 예상 질문 💬 서류 합격 후가 걱정되시나요? 내가 쓴 자소서를 AI가 분석해 면접관이 물어볼 법한 날카로운 질문을 미리 뽑아드립니다.👉지금 바로 사용해 보기:https://jobsecretary.lat(피드백은 언제나 환영입니다! )#취업준비 #자소서 #AI자소서 #JobSecretary #취업비서 #칸반보드 #면접준비 #대학생 #취준생 #무료배포

AI 코딩･프로젝트･개인프로젝트･웹개발･취업

1

소액결제 현금화 정보글

🔥 소액결제 현금화? 어렵게 하지 말고 이렇게 해! (진짜 현실 꿀팁)소액결제 현금화 처음 해보면“이거 맞나…?” “사기 아닌가…?” 이런 생각부터 들지?근데 제대로 된 업체만 잘 고르면 걱정할 게 하나도 없어.오늘은 내가 자주 쓰는 용용티켓.com 기준으로 꿀팁 정리해줄게.⭐ 1. 불필요하게 돌아다니지 말고 바로 ‘전문업체’ 찾기현금화는 빨리 끝내야 편해.사이트 여러 개 비교한다고 시간만 날리는 경우가 많거든.용용티켓은 상담 → 결제 → 입금까지 한 흐름으로 딱 정리돼 있어서초보도 그냥 안내대로 하면 바로 끝남.⭐ 2. 입금 속도는 ‘진짜’ 중요함급해서 현금화하는 건데 10~20분씩 기다리면 의미가 없음…나도 다른 곳 써봤다가 괜히 스트레스만 받은 적 있어 ㅋㅋ용용티켓은 말 그대로 바로 들어옴.평균 1~3분 컷이라 체감상 거의 즉시입금 느낌.⭐ 3. 수수료 몰래 올리는 곳 조심애초에 수수료를 제대로 안 알려주는 곳은 무조건 피해야 해.견적이랑 실제 입금액 다르면 답도 없고, 따지기도 애매하거든.용용티켓은 상담 때 ‘정확히 얼마 받는지’ 미리 확정해서 알려줘서생각보다 더 편함.⭐ 4. 후기 + 인증샷 꼭 확인하기요즘 사기 사이트들 디자인만 번지르르하게 해놔서 속기 쉬움.근데 후기랑 인증샷은 절대 속일 수가 없음 ㅋㅋ용용티켓은 후기 꾸준하고 인증샷도 계속 올라와서확실히 오래 운영한 곳이라는 느낌이 있더라.⭐ 5. 늦은 시간에도 바로바로 됨나는 급한 돈이 대부분 밤에 필요하더라…근데 24시간 대응 안 되는 곳은 답답해.용용티켓은 새벽에도 상담되고 처리돼서그럴 때 진짜 고마웠음.👍 결론소액결제 현금화는 진짜 ‘어디서 하느냐’가 전부임.복잡하게 생각할 필요도 없고, 위험하게 이것저것 비교할 이유도 없음.나는 항상 용용티켓.com에서 하는데빠르고, 친절하고, 수수료 명확해서 그냥 계속 이용하게 됨.소액결제로 급하게 현금 필요하면그냥 용용티켓.com이 답이야.한 번 써보면 왜 그런지 바로 느낌 올걸? 🙂

금융 · 재테크･소액결제･소액결제현금화

1

세계가 연결되는 도시, 부산 데이터센터 허브

데이터가 바다를 건너, 기회의 문을 열다우리는 지금, 데이터가 국경을 넘어 흐르는 시대에 살고 있습니다.누군가의 선택 하나가, 한 기업의 기술이, 한 도시의 미래가‘연결’이라는 단어 하나로 무한히 확장되는 순간.그 중심에 부산이 놓여 있습니다.오늘은 이 이야기가 어떤 이야기인지에 대해서 포스팅 해보려고 합니다.부산은 더 이상 단순한 해양 물류의 거점이 아닙니다.이제는 세계 데이터 흐름의 시작점,글로벌 클라우드 서비스와 디지털 산업이 모여드는글로벌 데이터 허브로 도약하고 있습니다.부산의 데이터는 이미 세계와 연결되고 있습니다기업들이 부산을 선택하는 이유는 단순한 환경이 아닙니다.부산은 세계적인 데이터 네트워크의 관문,아시아·태평양을 잇는 해저케이블의 핵심 위치에 서 있습니다.부산 데이터센터는글로벌 클라우드 서비스와 실시간 연결된 망 인프라를 기반으로전 세계 기업의 비즈니스 운영을 지원하고 있습니다.데이터는 이제 바다를 건너고,부산은 그 데이터가 지나가는 전략적 관문이 되었습니다.세계와 함께 성장하는 도시, 부산부산은 기술 인프라를 기반으로아시아 주요 도시들과 실시간 데이터 교류가 가능한 도시로 성장하고 있습니다.단순히 서버를 모아둔 집적단지가 아니라글로벌 산업이 함께 확장되는 네트워크의 중심입니다.해외 투자 유입 가속국제 데이터 교류 중심도시로의 도약글로벌 경쟁력 강화데이터는 부산의 산업지도를 바꿉니다.그리고 그 중심에는 세계가 선택하는 데이터 허브라는 새로운 정체성이 자리 잡고 있습니다.데이터가 바다를 넘어 세계로 향하는 곳, 부산우리는 지금 거대한 변화의 초입에 서 있습니다.데이터는 도시의 미래를 바꾸는 에너지이고,도시는 그 에너지를 어떻게 설계하느냐에 따라세계를 향한 문을 여는 힘을 갖게 됩니다.산업에서 시작해사람으로,세계로 확장되는 여정.부산은 지금글로벌 데이터 경제의 중심에서새로운 미래를 여는 도시로 나아가고 있습니다.

데이터 사이언스 기타･부산그린데이터센터･데이터센터･EDC･부산정보산업진흥원･그린데이터센터･부산･글로벌데이터･에코델타시티･강서구

1

왜 내 배치는 로컬 JobParameter로 실행됐을까?

신규 배치 잡을 개발하면서, 로컬에서 먼저 실행해 정상 동작을 확인한 뒤 개발 서버에 배포해 실행해보았다.그런데 이상한 문제가 발생했다.배치 실행 시 항상 로컬에서 사용했던 JobParameter로만 실행되는 것.Jenkins에서 jobParameter를 넘겨 실행해도, 스프링 배치는 계속 로컬에서 실행한 JobParameter를 고정해서 사용했다.새로 만든 잡에서는 동일 JobParameter로도 배치를 반복 실행할 수 있도록 RunIdIncrementer를 사용한다.이 incrementer는 run.id를 자동으로 증가시켜 새로운 JobInstance를 만들 수 있게 해주는 기능이다.그런데 RunIdIncrementer로 인해 run.id는 정상적으로 1, 2, 3… 증가하는데,정작 내가 설정한 jobParameter가 아니라 로컬에서 실행한 파라미터만 계속 적용되고 있었다.그래서 원인을 제대로 파악해 보기로 했다.RunIdIncrementer는 정확히 무엇을 할까?스프링 소스코드를 보면 역할은 매우 단순하다.public JobParameters getNext(@Nullable JobParameters parameters) { JobParameters params = (parameters == null) ? new JobParameters() : parameters; JobParameter<?> runIdParameter = params.getParameters().get(this.key); long id = 1; if (runIdParameter != null) { id = Long.parseLong(runIdParameter.getValue().toString()) + 1; } return new JobParametersBuilder(params).addLong(this.key, id).toJobParameters(); } 즉:기존 JobParameter에서 run.id가 있으면 +1없으면 1그 외 나머지 JobParameter는 건드리지 않고 그대로 사용즉, RunIdIncrementer는 오직 run.id만 증가시키고그 외 파라미터는 건드리지 않는다.그럼 “그 외 파라미터”는 어디서 오는 걸까?JobParametersBuilder.getNextJobParameters스프링은 다음과 같은 순서로 JobParameter를 만든다.JobInstance lastInstance = jobExplorer.getLastJobInstance(name); JobExecution previousExecution = jobExplorer.getLastJobExecution(lastInstance); nextParameters = incrementer.getNext(previousExecution.getJobParameters()); ... nextParametersMap.putAll(this.parameterMap); // 현재 실행 파라미터 우선 요약하면:이전에 실행한 동일 Job의 JobParameter를 조회한다.RunIdIncrementer로 run.id를 증가시킨 nextParameters를 만든다.이번 실행에서 전달한 jobParameter를 맨 마지막에 merge한다. (가장 높은 우선순위)즉 스프링 배치의 JobParameter 우선순위는 다음과 같다.Spring Batch JobParameter 우선순위이전 실행의 JobParameterIncrementer(getNext) 결과이번 실행 시 전달된 JobParameter (최우선)그렇다면 이번 실행에서 넘겨준 파라미터가 최우선인데 왜 적용되지 않았던 걸까? 전달되지 않을 것 같아 배치 실행 부분을 살펴봤다.문제의 진짜 원인: Jenkins → Docker 실행 시 파라미터가 전달되지 않음스프링 배치 로직상으로는 “이번 실행 파라미터가 가장 우선순위”가 맞다.그런데 실제로 Jenkins에서 JobParameter를 넘겨줘도 실행 결과에는 반영되지 않았다.조사해보니:Jenkins가 전달한 jobParameter를 Dockerfile 내부에서 배치를 실행할 때 넘겨주지 않고 있었다.즉,Jenkins → Docker run → Spring Boot이 체인을 따라 파라미터가 전달되지 않아서스프링은 “이번 실행 파라미터 없음”그럼 당연히 이전 JobParameter를 그대로 가져다 씀incrementer는 run.id만 증가결과적으로 run.id만 달라지고 나머지는 로컬 실행 때의 파라미터가 계속 유지됨그래서 Dockerfile을 수정해 Jenkins에서 받은 파라미터를 그대로 전달해 실행하도록 수정했고문제는 바로 해결되었다.결론1) RunIdIncrementer는 run.id만 올려주는 단순한 기능이다.다른 파라미터는 절대 건드리지 않는다.2) Spring Batch는 이전 실행의 JobParameter를 기본값으로 사용한다.그리고 incrementer를 적용한 뒤,이번 실행 파라미터를 merge한다.3) 이번 실행의 JobParameter가 적용되지 않은 이유는Dockerfile에서 파라미터를 누락해서 전달되지 않았기 때문.4) 따라서 Jenkins → Docker → Spring Boot 실행 구조를 사용할 때는반드시 jobParameter 전달 경로를 점검해야 한다.

백엔드･SpringBatch･스프링배치

1

PostgreSQL alias는 소문자로 나오는데 DTO 매핑은 잘 될까?

TL;DRPostgreSQL은 따옴표 없는 alias를 전부 소문자로 변환하지만,JDBC 드라이버의 findColumn()은 대소문자를 구분하지 않고 컬럼을 탐색하며,SimplePropertyRowMapper는 DTO 필드명 그대로→snake_case 순으로 컬럼을 찾는다.덕분에 AS blogId로 alias를 줘도 DTO의 blogId 필드로 정확히 매핑된다.예를 들어 다음과 같이 Spring의JdbcClient 를 사용해 PostgreSQL 쿼리 결과를 Kotlin data class로 매핑한다고 해봅시다val sql = """ SELECT t.parent_id AS blogId, t.id AS tagId, t.name AS tagName FROM tags t """.trimIndent() jdbcClient.sql(sql) .query(TagByBlogDto::class.java) .list() 그리고 매핑 대상은 아래처럼 단순한 data class입니다data class TagByBlogDto( val blogId: Long, val tagId: Long, val tagName: String, ) PostgreSQL은 AS blogId를 내부적으로 소문자(blogid) 로 변환하지만,JdbcClient는 이 컬럼을 TagByBlogDto.blogId에 정확히 매핑합니다.어떻게 이런 일이 가능한 걸까요?PostgreSQL alias 규칙PostgreSQL 공식 문서에 따르면 👇“Quoting an identifier also makes it case-sensitive, whereas unquoted names are always folded to lower case.For example, the identifiers FOO, foo, and "foo" are considered the same by PostgreSQL,but "Foo" and "FOO" are different from these three and each other.”— PostgreSQL Docs: Identifiers and Key Words즉,AS blogId → 내부적으로 blogidAS "blogId" → 대소문자 그대로 유지작성 형태 실제 인식되는 이름 AS blogId blogid AS “blogId” blogId AS BLOGID blogidJdbcClient는 어떤 매퍼를 사용할까?JdbcClient는 .query(Class<T>) 호출 시 내부적으로SimplePropertyRowMapper 를 사용합니다 👇public <T> MappedQuerySpec<T> query(Class<T> mappedClass) { RowMapper<?> rowMapper = rowMapperCache.computeIfAbsent(mappedClass, key -> BeanUtils.isSimpleProperty(mappedClass) ? new SingleColumnRowMapper<>(mappedClass) : new SimplePropertyRowMapper<>(mappedClass) ); return query((RowMapper<T>) rowMapper); } 즉, TagByBlogDto처럼 DTO를 넘기면new SimplePropertyRowMapper<>(TagByBlogDto.class)가 생성되어 필드 단위로 매핑됩니다.SimplePropertyRowMapper의 동작 원리SimplePropertyRowMapper는 생성자 파라미터명을 기준으로 ResultSet에서 컬럼을 찾습니다.핵심 부분은 아래와 같습니다 👇for (int i = 0; i < args.length; i++) { String name = this.constructorParameterNames[i]; int index; try { // ① 필드명 그대로 컬럼 탐색 (예: blogId) index = rs.findColumn(name); } catch (SQLException ex) { // ② 실패 시 snake_case 변환 (예: blog_id) index = rs.findColumn(JdbcUtils.convertPropertyNameToUnderscoreName(name)); } Object value = JdbcUtils.getResultSetValue(rs, index, td.getType()); args[i] = this.conversionService.convert(value, td); } 즉, 매퍼는 다음 순서로 필드 매칭을 시도합니다:findColumn("blogId")실패 시 findColumn("blog_id")PostgreSQL JDBC 드라이버(PgResultSet)의 findColumn 로직이제 핵심입니다.PostgreSQL JDBC 드라이버는 ResultSet.findColumn() 호출 시 대소문자를 모두 무시하고 컬럼을 찾습니다.아래는 실제 PgResultSet 코드 일부입니다private int findColumnIndex(String columnName) { Integer index = columnNameIndexMap.get(columnName); if (index != null) return index; // 1️⃣ 소문자 비교 index = columnNameIndexMap.get(columnName.toLowerCase(Locale.US)); if (index != null) { columnNameIndexMap.put(columnName, index); return index; } // 2️⃣ 대문자 비교 index = columnNameIndexMap.get(columnName.toUpperCase(Locale.US)); if (index != null) { columnNameIndexMap.put(columnName, index); return index; } return 0; } 즉, rs.findColumn("blogId")를 호출하면 드라이버가 내부적으로blogId, blogid, BLOGID를 모두 비교하기 때문에 일치하게 됩니다.

백엔드･jdbcClient･spring

1

데이터센터, 부산에 새로운 기회를 열다.

데이터센터가 열어가는 기회의 도시 "부산"요즘 "데이터센터"라고 하면 단순히 거대한 서버 건물이나, 전력 사용량 같은 단어들이 먼저 떠오르죠.하지만 지금 부산에서 준비하고 있는 데이터센터 이야기는 조금 다릅니다.오늘은 이 이야기가 어떤 이야기인지에 대해서 포스팅 해보려고 합니다.부산의 성장 밑바닥에는 "데이터"가 흐른다.우리가 사용하는 거의 모든 서비스 뒤에는 데이터가 있는데요.결제, 물류, 금융, 교육, 게임, 콘텐츠, 행정 서비스까지우리가 누리고 있는 모든 서비스! 이 모든 것을 뒷받침하는 인프라가 바로 데이터센터입니다.부산은 "기술이 일자리를 줄인다"는 불안 대신,기술로 새로운 일을 만들고, 새로운 기회를 여는 도시가 되기를 선택하고 있다고 하는데요.부산이 기회를 여는 방식은 간단합니다!데이터를 저장하고, 연결하고, 활용할 수 있는 환경이 갖춰질수록도시는 더 많은 산업을 품을 수 있고, 더 다양한 사람들에게 기회를 나눌 수 있기 때문인데요.부산은 지금 그 환경을 만드는 지점에 서 있다고 하네요!부산의 데이터센터는 산업과 경제를 움직이는 숨은 엔진으로 부상중인데요.이 엔진이 돌아가면서 부산에서는 이런 변화가 나타나고 있다고 합니다!기술 일자리 증가, 데이터 기반 서비스 스타트업 창업 붐 확산, 지역 대학과 연계해서 인재를 양성즉, 데이터센터가 생기면 끝이 아니라,그 주변에 새로운 직무, 새로운 기업, 새로운 교육 기회가 연쇄적으로 생겨나는데요.특히나 부산은 전력 안정성, 해저케이블, 냉각 인프라 등데이터센터 운영에 필요한 핵심 조건들을 갖추고 있기에, 이 변화가 일회성이 아니라 지속가능한 구조로 자리 잡을 수 있는 도시라고 하네요!!왜 하필 부산일까요?데이터센터는 단순히 건물 몇개를 짓는 수준이 아니라,공간-사람-기업이 함께 움직이는 구조를 만들고 있다는 뜻입니다.부산에서 이루어지는 구조인데이터센터+인재+기업 생태계가 연결 된 도시의 대표적인 키워드들을 정리해보면강서구 지역의 데이터센터 집적단지미음지구 클러스터LG CNS,MS, BNK 등 글로벌*금융*IT 기업의 참여부산정보산업진흥원을 중심으로 한 데이터센터 기반 인재양성 사업이 모든 축이 연결되면서,데이터센터는 "서버를 쌓아 놓은 공간"이 아니라기업이 태어나고, 기술이 자라고, 청년이 자신의 커리어를 설계할 수 있는 도시 인프라로 성장하고 있습니다.기회는 "기술"이 아니라, "준비된 도시"에서 만들어진다.데이터센터 자체는 하나의 "기술 인프라"에 불과합니다.하지만 그 인프라를 어떻게 도시 전략과 연결하느냐에 따라,어떤 곳에서는 갈등과 비용 문제로 남고,어떤 곳에서는 산업*일자리*교육을 동시에 끌어올리는 동력이 됩니다.부산은 지금,데이터센터를 미래 산업의 성장 엔진이자, 기업과 시민 모두에게 열린 "기회의 플랫폼"으로 바라보고 있습니다.부산에 있는 기업이라면,"우리 비즈니스를 데이터 기반으로 한 단계 더 확장할 수 있을까?"부산에서 일하고 싶거나 창업을 꿈꾸는 청년이라면,"데이터센터와 연결 된 새로운 직무, 새로운 시장은 어디에 있을까?"이 질문을 던지는 순간,데이터센터는 더 이상 남의 이야기가 아니라지금, 내가 서 있는 도시의 기회 이야기가 됩니다.이번주도 마찬가지로 부산 그린데이터센터 집적단지 인스타그램에서 OX퀴즈를 통해 소정의 선물을 드리는 이벤트를 진행하고 있습니다!아래 이미지 링크를 이용하여 많은 관심 가져주시면 감사하겠습니다![출처]데이터센터, 부산에 새로운 기회를 열다.|작성자2025 지역 데이터센터

인공지능 기타

1

데이터센터 기반으로 확장되는 AI 산업혁신도시, 부산

안녕하세요! 오늘은 데이터센터가 어떤 형태로 산업에 영향을 미치고, 필요한지에 대해서 알아보는 포스팅을 하려고 합니다.데이터가 움직이면 도시가 달라집니다.요즘 "AI","데이터","스마트시티"라는 말, 참 많이 들리죠?하지만 사실 이 세 가지는 모두 연결돼 있습니다.그리고 그 중심엔 데이터센터가 있어요!우리가 사는 도시가 점점 더 편리해지는 이유, 그건 바로 데이터가 실시간으로 움직이기 때문이에요.그건 바로 데이터가 실시간으로 움직이기 때문이에요.예를 들어, 도로 위 차량 흐름을 분석해 교통신호를 바꾸고, 비가 오면 재난 문자 시스템이 자동으로 작동하고, 건물의 에너지를 AI가 스스로 조절하죠.이 모든 게 가능하려면, 엄청난 양의 데이터를 실시간으로 처리할 수 있는 "두뇌"가 필요한데요!!그 두뇌가 바로 데이터센터예요.부산, 데이터가 산업을 바꾸는 도시부산은 지금 그 "두뇌"를 키우고 있다고 하는데요.미음지구 및 강서구 에코델타시티 일대에 그린 데이터센터 집적단지가 만들어지고 있고,AI가 산업 속으로 더 깊게 들어가고 있어요.제조 산업은 AI분석으로 효율을 높이고, 물류 산업은 항만부터 창고까지 데이터로 연결되고, 금융 산업은 데이터 기반으로 더 빠른 결정을 내린다고 합니다.이처럼 AI+산업+데이터센터,세 가지가 연결되면서 부산은 "스마트 산업 도시"로 성장하고 있다고 하네요! 산업이 모이면, 기회가 온다지금 부산은 새로운 산업 생태계를 만들어가고 있는데요.스마트시티 실증, 해양 AI, U헬스케어까지데이터가 필요한 모든 산업이 하나의 네트워크로 묶이고 있죠.이 변화는 단순한 기술 이야기가 아닙니다!기업이 더 빠르게 성장하고,시민들이 더 편리한 도시를 경험하는 이야기에요.데이터센터가 부산을, 데이터센터를 통해 AI를 성장시킨다.AI 시대, 기술만으로는 도시가 성장하지 않습니다.그 기술을 활용할 사람과 공간, 그리고 산업의 흐름이 함께 움직여야 하죠.부산은 바로 그 "균형"을 만들어가고 있습니다.AI가 움직이는 도시, 부산이 보여줍니다.이제 부산은 단순한 항만 도시가 아닙니다.데이터와 AI가 함께 뛰는 산업의 중심 도시,스마트시티의 미래를 먼저 보여주는 도시로 바뀌고 있어요.부산의 데이터센터는AI를 위한 인프라를 넘어서,새로운 산업 기회의 시작점이 되고 있습니다.

인공지능 기타･부산그린데이터센터･데이터센터･EDC･그린데이터센터･지속가능한･부산정보산업진흥원･부산･글로벌데이터･에코델타시티･강서구

1

부산, 스마트시티와 데이터센터의 미래를 연결하다

오늘은 데이터센터+스마트시티로 부산의 미래를 연결하다는 주제로 포스팅 하려고 합니다.먼저 스마트시티에 대해서 간단하게 설명하면, 스마트시티는 정보통신기술(ICT), 인공지능(AI), 사물인터넷(Iot) 등을 활용해서교통, 환경, 에너지, 안전, 행정 등의 다방면에서 지능적으로 운영과 관리를 하는 도시를 말합니다.모든 것은 사람 중심의 도시 운영 + 기술 중심의 효율성이 결합된 형태라고 할 수 있는데요!예시로 스마트 신호등, 자율주행 등을 기술적으로 교통체증 완화나 사고 감소 등의 기대효과를 낼 수도 있고, 에너지 모니터링 등의 기술로 에너지 절감과 에너지를 효율적으로 배분하기도 합니다. AI CCTV, 긴급 알림 시스템을 통해서 범죄 예방이나 재난 대응 속도를 향상 시킬 수도 있습니다.스마트홈, IoT 가전, 원격의료으로 전반적인 생활의 질이 향상 되는 등의 다양한 기대효과를 누릴 수 있는데, 이 모든게 데이터가 없으면 불가능한 것들입니다.다른 기술들도 마찬가지겠지만, 교통 기술이나 재난 예측 시스템 등은 실시간 데이터를 활용하지 않으면 불가능한 것들이라지연되지 않고 빠르게 데이터가 전달되고 분석하는 활동이 매우 중요합니다. 그렇기에 데이터센터는 더욱더 중요한 자산이 될 것입니다.부산에서는 이미 데이터센와 스마트시티가 실증 중에 있으며, 스마트항만, 스마트빌딩, U-헬스케어 같은 기술들이 지속적으로 테스트 되고 있습니다. 현재 모든 걸 갖추고 있는 도시가 바로 부산이 되겠습니다!부산항도 무인화 바람 .. 자율주행 차 돌아다닌다.| 출처 : 아시아경제 | https://www.asiae.co.kr/article/2025110212513469541현재는 부산항에서 컨테이너를 옮기는 크레인을 원격으로 조종하거나 컨테이너를 옮기는 차량 또한 자율주행을 하는 등의 자동화, 무인화 부두로 탈바꿈 하기 위해 많은 조금씩 변화하고 있는 중입니다. 스마트항만은 부두를 시작으로 도시까지 자율주행으로 컨테이너를 옮기는 등의 데이터를 이용한 전자동화를 계획하고 있습니다.부산은 데이터센터와 스마트시티가 합쳐져 디지털 전환을 선도하는 도시로 성장하고, 이는 한국을 넘어 글로벌 무대로 확장할 준비가 된 도시입니다.부산은 이제, 우리가 꿈꾸던 미래를 직접 그리고 실행하는 도시가 될 것입니다.다음 포스팅에서는 데이터센터를 기반으로 확장되는 산업인프라에 대해서 좀 더 자세히 알아보도록 하겠습니다.

데이터 사이언스 기타･데이터센터･스마트시티･자율주행･에코델타시티･스마트빌딩･스마트항만･자율운항선박･해양AI데이터･인공지능

1

[인프런 클론 6주 완성 챌린지] 불안으로 인한 미루기 및 해결 시도

불안이 또 찾아왔다.개인적으로 데드라인에 대한 불안으로 일을 그르친 것이 한두번이 아니었다. 고질병이었던 불안으로 인해 나는 일을 미루는 습관을 가지고 있었고 간단한 일조차도 너무 크게 느껴졌다.(글을 잘 쓰려고 하지 말자. 사실은 지금도 불안하다.)나는 분명 저번에 불안한 일들에 내 자신을 노출시키면서 어느 정도 해결되었다고 생각했는데 웬걸, 이번 주에 챌린지 1주차 과제 마감 때문에 또다시 불안이 찾아왔고 3일 동안 벌벌 떨며 기본 세팅을 미루었다.그러다 어떤 글을 봤는데 나와 비슷하게 불안을 느끼는 사람의 글이었다. 본인이 불안할 때 아무 생각 없이 딱 할 수 있는 부분을 시작한다고 한다.이 글을 보고 목표를 바꿨다. 원래는 챌린지를 통해서 백엔드 프로젝트를 기획하고 기능 구현하고 배포하는 것과 관련된 문제 해결 능력을 기르려고 했는데, 다 필요없고 일단 챌린지를 따라치되 일부 디테일에서 변주를 주는 것을 목표로 하고 있다. 예를 들어 원래는 Configuration을 config server를 따로 구성하면서 삽질해보고 싶었는데, 아니 지금도 그렇게 해보고 싶은데 다 포기하고 강의에 나온 .env 파일로 해결하려고 한다. 변주를 주고 싶은 부분의 예는 db 스키마에서 pk이다. 아무리 불안핑이어도 uuid pk는 쉽지 않기 때문에, 아니 실은 bigint pk, uuid pk를 둘 다 잘 몰라서 bigint row_id (pk) + uuid entity_id (index) 조합으로 실험해보고 싶고 이 정도는 해도 될 것 같아서 이 정도의 변주만 주려고 한다.아래 글은 다른 글인데 나중에 읽으려고 추가합니다. 공감되는 부분도 많고 나중에 시도해볼 부분도 많은 것 같습니다.https://brunch.co.kr/magazine/discipline

커리어 · 자기계발 기타･학습일기･불안･미루기

1

0

인공지능과 추천 시스템 강의 노트 (7/16) - 2025. 10. 17

들어가며 연휴 이후 첫 수업인데, 토요일에 강의장에서 일정이 있어 금요일 저녁으로 이동해서 수업을 진행하였다. 꽤 오랫동안 잊고 있었는데, 금요일 오후의 여의도는 토요일 오전보다 훨씬 북적이는 동네였다.이전의 두 번의 녹화 온라인 강의가 강제로 끝까지 보게 하는 내용이라 하여 장단점이 있다 싶었고, 학기 말까지 남은 다음 2번의 원격 수업을 아예 녹화로 진행해야 할까 하는 생각을 해 보게 되었다. 준비한 내용들 7주) 강의 update추천시스템 - 5장 - 1 나눈 이야기들한시간 분량의 수업을 준비하는 내용은 양에서는 적었지만, 추천 시스템 항목에서 MovieLens 데이터의 EDA 를 조금 진지하게 하게 되었는데, 학교에 있는 Chrome + colab 등으로 입코딩과 클릭 클릭을 해야 하는 수업이었다. 학교 PC 에 뭘 설치하기도 애매하기에 여러 방법을 고려해 봤지만, 이 정도가 맞는 거 같은데, 해 본 사람들에게는 아무 것도 아닌 일일 수도, 여전히 처음 해 본 사람들한테는 진입 장벽일 수 있겠다.학생들 각자 보고 싶은 데이터는 직접 보며 분석했으면 하는 마음에 pre-requisite 으로 Python 을 놓았고, 자유 방식의 EDA를 과제로 내었는데, 한 학생은 이 벽을 넘지 못하고 혹은 넘지 않고 과제를 drop 하였다. 코딩 자체를 평가 잣대로 놓지는 않기에 용기를 내기에 나쁘지 않은 환경이라 생각하는데 이래저래 아쉬움이 있다. 이후 근처의 식당에서 간담회를 진행했는데, 조금 자유로운 분위기에서 여러 이야기들을 나누며 명함들을 수집하였다. 절반 정도의 학생들이 참석을 하였고, 미래야 모른다지만, 이것도 인연인데 싶다. p.s.학생 하나가 7개월 아기와 함께 수업에 들어오게 되었다. 뉴스로만 접하던 상황이어서 조금 신선하긴 했고, 아기네 식구들과 다른 학생들 모두에게 불편하지 않은 상황이었기를 바라는 마음으로 이야기들을 진행했다. 다행히 울지 않은 순한 아이였고, 한국에서 거의 처음으로 유모차에 사람이 앉아 있는 것을 본 기억이기도 하다.

대학 교육 기타･인공지능･추천시스템

0

미래를 여는 힘은 여전히 우리, 프로그래머들에게 있다! <우리, 프로그래머들> 펀딩 오픈!

"The only way to go fast, is to go well."(빨리 가는 유일한 방법은 제대로 가는 것이다.)- 로버트 마틴(Robert C. Martin) - 우리는 누구일까요?우리 프로그래머는 왜 존재할까요? 사회에는 디테일에 집착하는 사람, 즉 우리 같은 사람이 꼭 필요하기 때문입니다.그런 사람이 있어야만 나머지 사람들은 아이스버킷 챌린지나 앵그리버드를 하거나 치과 대기실에서 솔리테어(solitaire, 혼자하는 카드 놀이)를 하며 시간을 보내는 일에 집중할 수 있으니 말이죠. 이렇게 대부분의 사람이 디테일을 피하려고 하는 한 그 디테일 속으로 뛰어드는 우리 같은 사람도 반드시 필요합니다. 그것이 바로 우리 정체성입니다. 우리는 이 세상 디테일을 책임지는 사람입니다. 지금부터 컴퓨팅과 프로그래밍의 시대가 어떻게 시작되었는지 이야기를 들려드리려 합니다. 이는 몇몇 비범한 사람의 삶과 도전, 그들이 살았던 특별한 시대, 그들이 다루었던 놀라운 기계들에 관한 이야기입니다. 자, 이제 준비가 되었다면 안전벨트를 꽉 매기를 바랍니다.아마도 아주 길고 거친 여정이 시작될 테니까요. -본문 발췌 및 재구성-🎉🎉 펀딩 오픈 당일 목표 100% 달성! 🎉🎉<우리, 프로그래머들> : AI 시대에 잊혀 가는 ‘프로그래머 정신’을 다시 깨우다 🌊 AI라는 거대한 파도 앞에서 길을 잃은 당신에게,📘 '엉클 밥' 로버트 C. 마틴이 보내는 뜨거운 응답. 변화의 한가운데서, 우리는 다시 본질로 돌아가자.미래를 여는 힘은 여전히 우리, 프로그래머들에게 있다! 🔹엉클 밥이라는 이름을 모르는 프로그래머는 거의 없다.이 책에서 그는 과거와 미래를 잇고, 프로그래머에게 다시 희망을 말한다.— 추천사, ThePrimeagen (소프트웨어 개발자이자 유튜버, 전 넷플릭스 엔지니어) 🔎지금 교보문고에서 만나보세요! [바로가기] *특별 사은품 구성도 놓치지 마세요! (수량 한정)

교양･코딩･개발･자기계발･프로그래머･개발자･AI･클린･아키텍쳐･코드･프로그래밍

0

🐝 가장 인기 많은 eBPF 혁명 오픈소스, Cilium 2025 활용 보고서(CNCF)

이제 Cilium은 단순히 Kubernetes의 Networking Open Source를 넘어, Cloud와 AI Native 생태계의 Global 표준 기술로 완전히 자리를 잡았네요. Networking, Security, Observability 등 AI 및 ML Workload를 위한 최적의 필수 Open Source 기술입니다. 🌐✨☁ Goggle, AWS, Azure 등 대부분의 Major Cloud 기업들이 기본으로 채택하고 있으며, 최근에 공개된 Cilium Annual Report에 대한 주요 Point를 공유드립니다. ☘︎ Cilium Core ➛ eBPF» Kernel Level에서의 Networking과 보안 제공,» Sidecar없는 Service Mesh 구현과 운영의 복잡성 해결 ☘︎ 단순 CNI ⇉ Platform 진화 » Networking(CNI)이상의 기능» Tetragon을 통한 Runtime 보안» Hubble을 이용한 정밀한 관측성» Gateway API 지원 등 다용도 Tool ☘︎ AI Native Open Source» 수만 개의 Node 연결 확장성» 차세대 Datacenter의 Core Architecture Component 상세한 2025년 Annual 보고서(아래 link🔗)를 확인하셔서 2026년에는 본격적인 AI기반의 Cloud 시대를 준비하세요. 🚀https://www.cloudbro.ai/t/3570

데브옵스 · 인프라

0

🚀 Backstage Plug-in 소개 - Platforming Engineering

📢 최근 Platform Engineering에 대한 관심이 많아지고 있기에, 도움이 될만한 정보를 공유합니다. Platform Engineering(특히, IDP) 구현은 일반적으로 Backstage를 많이 고려하고 있으나🧐, Backstage의 Base 기능에 대한 불편한 점들, 특히 👀Backstage에서 생성된 Service or Resource 수정 또는 Update의 번거로움 등 여러가지 불편한 부분이 있었는데, entity-scaffolder Plug-in이 지원을 합니다. 즉, 📝 Backstage Entity Page에 Scaffolder Template을 직접 embedding하여, 기존 Data를 기반으로 손쉽게 Entity를 Update하고 Self-Service 강화할 수 있는 Plug-in 입니다. 🙌 🔥 주요 기능 & 특징⇉ 엔티티 내 템플릿 실행 (Embed Scaffolder) 더 이상 템플릿 페이지로 이동할 필요 없이, 엔티티 상세 페이지(Entity Page) 안에서 해당 리소스와 관련된 템플릿을 바로 실행할 수 있습니다.⇉ 데이터 자동 완성 (Pre-populate Values) 수정할 때마다 모든 정보를 다시 입력할 필요없이, 기존 엔티티의 메타데이터를 가져와 템플릿 입력 필드를 자동으로 채워주기 때문에(Pre-fill). 개발자는 변경이 필요한 부분만 수정하면 됩니다.⇉ 조건부 워크플로우 (Conditional Steps) 단순한 입력뿐만 아니라, 상황에 따라 달라지는 복잡한 조건부 단계들도 매끄럽게 처리하여 정교한 셀프 서비스 시나리오를 지원합니다.⇉ 진정한 셀프 서비스 (Self-Service) 리소스 사양 변경, 태그 수정, 설정 업데이트 등 빈번한 유지보수 작업을 개발자가 직접, 빠르고 정확하게 수행할 수 있도록 돕습니다. Platform Engineering 구축에 실질적인 도움이 되시기를 기대합니다. [출처]: https://github.com/TheCodingSheikh/backstage-plugins/tree/main/plugins/entity-scaffolder[참고 Link] : https://www.cloudbro.ai/t/3538

개발 도구･백스테이지･플러그인

0

🌐 2026년은 Go for Global Cloud Bros

지난 7개월간 참여해주신 ☁ Kubernetes · DevOps · Platform Engineering · FinOps · MLOps 등 Production 운영하는 Top-tier 기업의 🇰🇷 국내 +2,000명이상의 Cloud Bro 전문가(Developer, Engineer, Architect)들과 함께 ... ✴︎✴︎✴︎2026년은 🌐Global Cloud Expert(Bro)분들과 함께 다양한 Program(incl. Open Project)으로 함께 합니다. Over the past 7 months, together with 2,000+ Cloud Bro experts (Developers, Engineers, Architects) from top-tier companies in 🇰🇷 Korea who operate production environments across ☁ Kubernetes, DevOps, Platform Engineering, FinOps, and MLOps… ✴︎✴︎✴︎In 2026, we will move forward with 🌐Global Cloud Experts (Bros) through diverse programs (including Open Projects). https://www.cloudbro.ai/t/3511

0