블로그 모아보기 - 인프런

서버와 연결을 유지하는 가장 단순한 방법, 폴링(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

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

1

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

요즘 디지털 환경에서 느끼는 피로는 단순히 사용 시간이 많아서라기보다,계속해서 무언가에 반응해야 한다는 압박감에서 오는 경우가 많다.이번 주차 미션에서는 이러한 문제의식 속에서디지털 디톡스를 고려한 디자인 사례들을 ‘행복을 주는 디자인’의 관점으로 살펴보고자 했다.아래 사례들은 모두 사용자를 더 오래 붙잡기보다는,사용자가 스스로 디지털과의 거리를 조절할 수 있도록 돕는 디자인이라는 공통점을 가진다. #디지털 디톡스를 고려한 디자인 사례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･디지털디톡스･심리학･디자인･디논･독서모임･행복한디자인･챌린지

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

🚀 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

왜 내 릴스, 쇼츠는 조회수가 안나올까?

릴스 만들다가 답답해서 최근 떡상한 계정 150개 직접 분석해보고있어요 🤔혹시 알고리즘 정체기 겪는 분들 도움 되실까 해서 공유합니다!거창한 건 아니고, 매일 계정 하나씩 뜯어서 핵심만 풀고 있으니 오셔서 편하게 정보 줍줍해가세요~ 🔥👇 매일 올라오는 릴스 분석 노트https://www.instagram.com/reelstamp

마케팅･릴스･크리에이터

0

🧭 쿠버네티스 아키텍처를 한눈에 이해할 수 있는 레퍼런스 모음

복잡한 Kubenetes 구조를 문서로만 이해하기엔 한계가 있습니다. 실제 학습과 Production 설계 과정에서는 잘 설계된 Architecture Diagram 하나가 수십 줄의 설명을 대체하는 경우가 많습니다. 💡Awesome GitHub Repository는 📐 CloudSkew · Creately · Draw.io · Holori · Hyperglance · Layer5 · Lucidchart · Moqups · Terrastruct 등 다양한 Drawing Tool과 실전 Scenario로 구성된 Kubernetes Diagram을 체계적으로 Curation 되어있습니다. https://www.cloudbro.ai/t/topic/3466☀ 이런 분들께 필요합니다⇉ Kubernetes 전체 구조를 시각적으로 파악하고 싶은 입문자⇉ Cluster 구조와 Component 배치를 고민하는 DevOps Engineer · Architect⇉ 조직에 Kubernetes Architecture를 설명할 명확한 Reference가 필요한 분

클라우드브로･지식주권･클라우드･쿠버네티스･시스템설계･깃허브추천

0

💡 CloudHound + AWS 공식 Calculator로 EC2·RDS 비용 “한눈에

AWS EC2와 RDS 비용 예측이 어렵다고 느껴졌다면? 이제 걱정 NO! AWS 공식 Pricing Calculator로 기본 비용을 예측하고, *CloudHound의 실시간 비교 계산기로 EC2·RDS 인스턴스를 똑똑하게 분석할 수 있어요. 간단 입력으로 월별 비용부터 최적 인스턴스까지 스마트하게 결정하세요! AWS Pricing Calculator AWS가 제공하는 공식 비용 예측 도구로 EC2, RDS, S3 등 주요 서비스의 사용량 기반 예상 비용을 무료로 계산할 수 있어요. 리전, 인스턴스 유형, 사용량 등 세세하게 설정해 정확한 월별 비용 추정과 비교를 할 수 있답니다. CloudHound AWS Instance Calculator (무료)AWS 인스턴스 수천 가지 옵션과 다양한 요금 모델을 실시간 최신 가격 데이터로 비교할 수 있는 도구예요. EC2/RDS의 vCPU, 메모리, 저장소 등 핵심 요소를 한 화면에, TCO까지 계산해 가장 비용 효율적인 선택을 빠르게 찾을 수 있습니다.https://www.cloudbro.ai/t/cloudhound-aws-calculator-ec2-rds/3461

0

🧠 Kubernetes의 피로를 줄이는 혁신 도구 10개

1. CueLang + Monokle — 깨지지 않는 스키마 기반 구성2. Crossplane — 진정한 Kubernetes용 IaC (Crossplane - CNCF Project : 쿠버네이티브 멀티 클라우드 인프라 제어)3. Dagger — Kubernetes 네이티브 CI/CD 파이프라인 (⚙ CI/CD를 코드로 전환하다 — K8s 대안 툴 ; Dagger)4. Kpt — 추측 없는 GitOps5. OpenTofu (구 Terraform 포크) — 벤더 종속 없는 안정적 IaC (Terraform를 떠난 이유 (2025년), 그리고 우리가 선택한 대안 - OpenTofu & Crossplane)6. Argo CD + Argo Rollouts — GitOps와 스마트 배포의 단순화7. Tilt — 개발자를 위한 로컬 Kubernetes 동반자8. Lens IDE — Kubernetes의 시각적 두뇌9. Kubernetes Dashboard 3.0 — 단순함과 실용성의 균형10. Helmfile + Jsonnet — 복잡하지 않은 자동화https://www.cloudbro.ai/t/bros-insights-kubernetes-10/2799

Kubernetes･혁신도구･피로해결

0

💸 AWS EC2 비용 최적화 실전 가이드: 불필요한 지출을 구조적으로 줄이는 방법

AWS EC2를 사용하면서 비용이 지속적으로 증가하는데, 어떤 인스턴스가 낭비되고 있는지?어디서 비용 최적화가 가능한지? 명확히 파악하지 못하는 상황이 발생하는 경우가 있습니다. 원인 분석EC2 비용 증가의 주요 원인은 다음과 같이 구조적으로 반복됩니다.Idle / Underutilized 인스턴스: 사용률이 낮거나 거의 사용되지 않음 잘못된 인스턴스 사이징: 실제 워크로드 대비 과도한 스펙온디맨드 위주의 사용: Savings Plan, Reserved Instance 미활용가시성 부족: 리소스, 비용, 사용 패턴을 한눈에 보기 어려움 해결 방안 EC2 비용 절감을 위해 다음과 같은 접근이 있습니다.🔍리소스 가시성 확보 → EC2, EBS, 네트워크 비용을 시각적으로 파악✂ 불필요한 리소스 식별 및 제거 → Idle 인스턴스, 미사용 볼륨 정리⚖ Right-sizing 전략 → CPU / Memory 사용률 기반 인스턴스 재조정📉 비용 최적화 옵션 활용 → Reserved Instances, Savings Plans, Spot Instances 검토 [출처] https://www.hyperglance.com/blog/aws-ec2-cost-optimization/

데브옵스 · 인프라･AWS･비용최적화

0

취업은 타이밍! 실시간 채용 무료앱 추천

안녕하세요. 취업 준비생 여러분! 자소서 쓰느라 바쁜데, 채용 사이트 매번 새로고침 하기 힘드시죠? "아, 맞다! 그 공고 마감일 언제였지?" 하고 깜빡해서 기회를 놓친 적이 있다면, 오늘 소개해 드리는 이 앱이 필수입니다. 취업은 스피드! '공채속보'복잡한 건 딱 질색인 분들을 위해 만들었습니다. 이것저것 설정할 필요 없이, 설치만 하면 바로 실시간 채용 정보를 배달해 드립니다. 남들보다 한발 앞서는 비결 새 공고가 뜨면 '푸시 알림' 도착 내가 직접 찾으러 다니지 않아도 됩니다. 새로운 기업 공채, 대기업/공기업 소식이 업데이트되는 즉시 휴대폰으로 [알림]을 보내드립니다. 왜 '공채속보'를 써야 할까요? 1. 군더더기 없는 심플함 � 복잡한 필터 설정하느라 머리 아플 필요 없습니다. 앱을 켜는 순간, 지금 가장 핫한 채용 정보가 한눈에 들어옵니다. 2. 1초도 아까운 취준생을 위한 속도 좋은 공고는 타이밍이 생명입니다. 누구보다 빠르게 확인하고 먼저 지원하세요. 3. 평생 100% 무료 취업 준비 비용도 만만치 않으시죠? 이 앱의 모든 정보와 알림 서비스는 예비 직장인들을 위해 완전 무료로 제공됩니다. 지금 바로 알림을 켜두세요! 지금 이 순간에도 새로운 채용 정보는 계속 올라오고 있습니다. 놓치고 후회하지 마시고, 지금 바로 앱을 설치해서 알림을 받아보세요. 합격의 기운을 담아 가장 빠르게 전달해 드리겠습니다. [클릭] 실시간 공채속보 무료 다운로드 받기 (위 글자를 클릭하면 구글 플레이스토어로 이동합니다)

취업 · 이직･채용정보･공채･기업공채･실시간공채

0

[프로젝트 공유] 프레임워크에 덜 의존적인 UI 컴포넌트를 만들어봤습니다

안녕하세요.프론트엔드 개발을 하면서 React, Vue 등 여러 프레임워크를 오가다 보니항상 비슷한 고민을 하게 되었습니다.Select, Toast 같은 기본 UI 컴포넌트는프레임워크가 바뀔 때마다 다시 구현해야 할까?UI 동작과 UX는 거의 같은데,프레임워크에 묶여 있다는 이유로매번 새로 만드는 구조가 과연 효율적인지 의문이 들었습니다.그래서 개인 프로젝트로프레임워크에 덜 의존적인 UI 컴포넌트를 Web Components 기반으로 만들어보았습니다.🔧 어떤 것을 만들어봤나요?크게 두 가지 컴포넌트입니다.1⃣ Select 컴포넌트Web Component 기반 (의존성 없음)대용량 데이터 처리를 위한 가상 스크롤한글 초성 / 일본어 / 중국어 검색 지원키보드 접근성 및 스크린 리더 대응CSS Variables 기반 스타일 커스터마이징React, Vue 등에서 사용할 수 있도록 래퍼 제공2⃣ Toast 알림 컴포넌트프레임워크에 종속되지 않는 Toast UI여러 위치와 애니메이션 지원중복 메시지 자동 그룹핑SSR 환경 고려접근성(ARIA) 기본 지원🤔 Web Components를 선택한 이유Web Components를 선택한 이유는 단순합니다.브라우저 표준 기술이라 장기 유지에 유리특정 프레임워크 라이프사이클에 묶이지 않음여러 프로젝트에서 재사용 가능UI 프리미티브(Select, Toast 등)에 적합하다고 판단물론 프레임워크 전용 컴포넌트만큼의 DX는 아닐 수 있지만,장기적인 관점에서는 충분히 의미 있는 시도라고 생각했습니다.💬 커뮤니티 분들께 여쭤보고 싶습니다실무에서 Web Components를 사용해보신 경험이 있으신가요?프레임워크 변경 가능성이 있는 프로젝트에서UI 컴포넌트를 어떻게 관리하고 계신지 궁금합니다.이런 접근 방식이 현실적인 선택일지 의견을 듣고 싶습니다.아직은 실험적인 프로젝트이고,피드백을 받아가며 개선해보려는 단계입니다.편하게 의견 주시면 감사하겠습니다.🔗 참고 링크Select 컴포넌트: https://www.npmjs.com/package/seo-selectToast 컴포넌트: https://www.npmjs.com/package/seo-toast

프론트엔드･javascript･typescript･react･vue･webcomponent･npm･select･toast

0