블로그 모아보기 - 인프런

[쿠버네티스] 컨테이너 한방 정리 #3

기술의 흐름으로 이해하는 컨테이너- 이미지 참고 : 쿠버네티스 어나더 클래스 (https://inf.run/Acobj) 쿠버네티스는 이제 [컨테이너]랑 [가상화] 그리고 [데브옵스]속에 깊숙히 자리잡고 있습니다. 그래서 이 세 가지를 알아야 쿠버네티스를 더 잘 알 수 있게 되는데, 이 단어들은 정말 큰 개념이라서 그냥 용어 설명으로는 이해하기 힘들어요. 그래서 기술에 전반적인 배경을 이해하는 게 중요하다고 생각합니다.그래서 이번 강의는 [컨테이너 한방 정리]로, 쿠버네티스를 잘 이해하기 위해컨테이너를 중심으로한 여러 배경 흐름 들을 이야기 해요. 1. Linux OS 흐름컨테이너를 잘 알기 위해서는 Linux에 대해서 먼저 알 필요가 있습니다.최초에 OS로 unix가 있었고, 한참 시간이 지나고 linux가 나왔어요. 그리고 이 linux를 기반으로 현재까지도 엄청 많은 배포판들이 만들어지고 있습니다.하지만, 다행이도 우리는 이 두 가지 배포판만 알고 있어도 충분해요.debian이랑 redhat 계열인데, debian linux는 커뮤니티용이라고 해서 무료고요. redhat linux는 redhat 이라는 기업에서 만들었고, 유료에요.쿠버네티스를 설치할 때도 이렇게 이 두가지 배포판을 기준으로 설치 가이드를 제공합니다. 데비안과 레드햇 계열에 대한 자세한 얘기는 강의 중에 설명드리고, 여기선 기업용으로 쓰는 redhat에 대해 좀 얘기를 해볼께요. redhat에서 linux 배포판이 만들어지는 순서가 있어요. 최초에는 fedora linux라고 해서 새로운 기능을 개발하는 버전이 있고, 이건 무료고요. 이 기능들이 안정화되면 redhat linux로 이름을 바꿔서 릴리즈를 합니다. 기업은 이걸 설치하면 유지보수 비용을 내야되는 유료 버전이고, redhat enterprise linux 앞자만 따서 RHEL, 렐 이라고도 통상 불러요. 그래서 이걸로 기업들이 설치를 하면 유지보수 비용을 내야 되는 유료 버전 이고, 그리고 이걸 복사해서 만든 게 centOS 배포판 이예요. rhel이랑 똑같이 안정화 버전인데, 무료로 쓸 수 있습니다.기업에서는 주로 redhat 계열을 많이 쓰고, 특히 centOS의 점유율이 높은데 centOS 8은 2021년에 지원을 종료 했고, centOS 7은 2024년도에 지원이 종료가 되거든요. 이 centOS가 종료되는 배경을 좀 말씀을 드리면 시장 점유율이 ubuntu가 압도적이고. 다음은 centOS랑 debian이 2, 3위를 왔다갔다 해요. redhat은 2%지만, 이 수치가 그래도 기업 배포판 중에 1위고요. 이 1위가 된 배경에는 사람들한테 centOS를 무료로 쓰게 해주면서 자연스럽게 redhat을 선택하게 하는 그런 전략이 있었거든요. 근데 현재 redhat은 IBM에 인수가 된 상태예요. 그리고 IBM의 새로운 전략은 centOS에 점유율을 rhel로 당기려는거 같아요.왜나하면 현재 redhat 배포판을 만드는 순서가 이렇게 변경됐거든요.처음엔 마찬가지로 fedora를 통해서 기능 개발을 하고, centOS대신 centOS Stream이라고해서 이 기능들을 테스트하는 배포판이 생겼어요. 테스트 배포판(테스트베드)이라고 생각을 하면 되는데 여전히 무료지만, 이 배포판에서는 바이너리 호환성 보장 안될 수 있다는 얘기를 해요. 무슨 내용인지 몰라도 이제 쓰면 안되나 싶은 생각이 들죠?그리고 테스트 과정이 끝나면, 안정화 버전인 Redhat Linux가 됩니다. 이렇게 배포판을 만드는 프로세스가 바꿨어요. 그래서 기존에 centOS를 쓰던 기업들은 앞으로 고민을 좀 해봐야 되는 게 지금 상황이고요. 아래와 같이 4가지 방법이 있는데 아래와 같습니다.이렇게 4가지 선택지 중에 전 4번을 선택을 했고, 이 강의에 실습 환경으로 사용이 되요. 저도 어떤 linux를 선택할까 고민을 많이 했는데, 1, 2번은 기업의 상황이라 제외를 하고, 타 OS로 ubuntu를 고민을 하다가 그래도 제가 가장 오래 사용을 했고, 문제가 생겼을 때 잘 가이드를 해드릴 수 있어야 하니까 4번, 새로운 복제본을 선택을 했습니다.그리고 AlmaLinux와 RockyLinux 중에서 Rocky Linux를 선택한 이유는 아래와 같아요.구글 트렌드에서 키워드 검색량 확인 (link)CentOS 공동설립자 중 한명 만들었음 (link)클라우드 서비스에서 VM 생성을 Rocky Linux로 하는 사례들 확인Github Watch/Fork/Start 비교 (rocky link), (alma link) 2. Container 흐름자, 이제 컨테이너에 대해서 얘기를 해 볼꺼예요. 지금까지 봐듯이 linux는 꾸준히 발전을 했고, 내부적으로도 많은 코어 기술들이 개발이 됐는데 그중 하나가 격리 기술이예요.chroot라고 해서 사용자 격리를 시작으로 파일이나 네트워크를 분리하는 기술들이 만들어 졌고요. 한참 지난 후에 cgroup이라고해서 각각에 App마다 cpu나 memory를 할당을 할 수 있게 됐어요. namespace는 보통 App 하나가 하나의 프로세스를 차지하거든요. 이 프로세스를 격리 시켜주는 기술이 만들어 지면서 우리는 이제 각각의 App을 소위 말하는 [독립적인 환경]에서 실행을 시킬 수 있게 됩니다.그리고 다음으로 이 기술들을 집약해서 정리한게 LXC라고 해서 linux container에 줄임말 이예요. 이 컨테이너의 어머니이자, 최초의 컨테이너죠. 그리고 이 기술을 기반으로 만들어진 이번엔 컨테이너에 대명사죠. Docker, 요즘은 위세가 많이 죽긴 했어요. 이전까지 컨테이너 기술은 저 같은 평범한 개발자들이 쓰기엔 좀 어려웠다면 docker는 이걸 누구나 쓰기 쉬운 형태로 만들었습니다. 요즘 잘 정리된 블로그 몇 개만 봐도 대강 이해해서 내 OS에 컨테이너를 띄울 수 있죠.docker가 나오고 rkt라고 rocket이라는 컨테이너가 나와요. docker가 보안에 안 좋은 점이 좀 있는데, 이 부분을 공략을 하면서 더 안정적인 컨테이너를 강조를 했고 실제 docker보다 성능도 더 좋다고 해요. docker가 보안에 안 좋은 점은 root권한으로 설치하고 실행을 해야 되기 때문인데, 현재는 rootless 설치 모드가 생겨서 보안이 강화가 됐습니다.한편 쿠버네티스는 점점 표준으로 정착이 되고 있고, 현재는 컨테이너간의 싸움 중입니다. 초반에 docker가 보안에 약하다는 것 까지는 사실 docker 대세에 크게 문제가 없었거든요. 시간이 지나면 충분히 보완 될꺼라는 기대도 있었고 실제로 보완이 됐죠. 근데 docker 위세가 조금씩 꺽이기 시작한 이유가 뭐냐면, 쿠버네티스에서 docker가 빠진 다는 얘기가 계속 있었어서 그래요. 그 이유는 docker가 쿠버네티스와 인터페이스가 잘 안 맞아서 그렇거든요. 물론 처음엔 docker를 메인으로 쿠버네티스가 만들어졌죠. 근데 쿠버네티스가 표준화가 될 수록 docker가 걸림돌이 되고 있는 상황이예요. 이제 누가 쿠버네티스랑 호환성이 좋은지가 컨테이너를 선택하는 중요한 결정요소가 됐습니다.그 이후에 나온 대표적인 컨테이너가 containerd랑 cri-o고요. containerd는 docker에서 컨테이너를 만들어주는 기능이 분리된 거예요. docker가 설치할 땐 간단해 보여도 엄청 많은 기능들이 녹아진 엔진이거든요. 그 큰 엔진에서 containerd 프로젝트만 분리 되서 나왔고 CNCF에 기부 됩니다. 번외로, docker는 현재 mirantis라는 회사에 인수된 상태예요. docker를 정말 많이 쓰지만 기술 투자 대비해서 수익이 큰 편은 아니었던 거 같아요. 그래서 mirantis라는 회사에 인수가 됐고 이 mirantis는 openstack 프로젝트를 하고 있는 회사 거든요. 이 openstack이 뭐냐면, kubernetes 이전에, 가상화에 대세라고 하긴 좀 그렇고, 가장 큰 가능성으로 가상화 시장을 선도한게 openstack 이예요. 저도 개인적으로 한 3년 정도 openstack 관련된 일을 했었고, 그래서 다음 가상화를 설명하는 강의에서 최대한 재미있게 얘기를 해 드릴께요. 여튼 docker가 mirantis에 인수된 이후부터 이 kubernetes 인터페이스를 잘 맞추려고 하고 있기 때문에 쿠버네티스에서 docker는 빠지진 않게 됩니다. 3. Container Orchestration과 Container 흐름강의 영상에서 컨테이너 오케스트레이션(쿠버네티스)과 컨테이너(컨테이너 런타임) 간에 한 단계 더 깊은 흐름을 이야기 합니다.가장 핵심은 쿠버네티스의 kubelet 변화와 그리고 이에 따른 컨테이너 런타임들 간의 흐름이예요. 바로 CRI가 어떤 배경에서 만들어졌고, 쿠버네티스 버전이 올라가면서 CRI가 어떤 방향으로 바뀌는지, 그리고 그에 따른 컨테이너 런타임들 간의 변화를 설명 드립니다. 그리고 컨테이너에서 절대 빼놓으면 안되는 OCI가 있습니다. 컨테이너 표준인데, 컨테이너 런타임들은 이걸 잘 지키고 있기 때문에, 우리는 런타임을 바꾸더라도 기존에 만들었던 이미지를 그대로 사용할 수 있어요 블로그는 여기까지고요. 강의가 오픈 되면 링크 걸어 놓을께요.좋은 하루되세요! 해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 많은 관심 부탁 드려요!강의 링크 :https://inf.run/Acobj 좋아요 ♡는 저에게 큰 힘이 됩니다 :)

데브옵스 · 인프라･인프런･쿠버네티스･어나더클래스･지상편･일프로･kubernetes･devops･kubeops･container･컨테이너한방정리

28

6

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

4

향로님의 추석 챌린지 회고

추석 연휴 동안 완강을 목표로 매일 1강을 인증하는 향로님의 챌린지에 참여했습니다.평소에도 블로그나 SNS를 통해 향로님의 글을 보는 것을 좋아했는데, 추석기간 동안 챌린지까지 여시다니!취준생의 입장에서 너무 좋았습니다. 참여하는 동안, 인출을 조금이라도 하고 싶어 미션 인증할 때 제목이나 글에 배운 내용을 넣어 어그로를 끌려고도 했습니다 ㅎㅎ; 챌린지 동안 열린 오픈 카톡방에서 본 다른 분들의 컴퓨터 세팅 이야기, 카공 인증샷 등을 보며 더 재밌게 챌린지를 참여할 수 있었던 것 같습니다. 참여하며 놀랐던 것 중 하나는 향로님이 1,000명이 넘는 참여자 분들의 글에 답변을 달아주시고 있다는 점이였습니다. 그리고 연휴인데도 불구하고 오픈카톡방에서 다양한 분들의 질문에 답변해주시고, 중간 중간 좋은 글과 라이브까지..! 라이브에서 언뜻 들었던 내용은 모든 분에게 한 번씩 닿기 위해서 글에 답변을 단다는 말을 들었던 것 같습니다. 진심이 전달된다는 게 사실 이 때까지 잘 느껴보지 못했던 것 같은데, 인프런이라는 플랫폼과 향로님과 마케팅팀분들이 열어주신 챌린지 덕분에 어떤 활동이라도 시간을 들여 고민을 한다면, 진심을 전달하는 게 가능하다는 걸 느낀 것 같습니다. [이다의 도시 관찰 일기]라는 책에서, 버스 안에 항상 클래식 FM을 틀어두던 기사분의 이야기가 나왔습니다.각기 다른 목적지를 향해 탄 승객들이지만, 그 음악 덕분에 버스는 잠시 일상의 밖으로 벗어난 또 다른 공간이 되었다고 합니다. 인프런 추석 챌린지에 참여하며 저도 그런 느낌을 받았습니다.다들 다른 길을 걷고 있지만, 같은 클래식 안에서 한 마음으로 달리는 듯한 시간들이었습니다. 또 향로님의 글에서 운동 후 보장된 근육통이라는 표현을 보고, 어떤 것에 도전했을 때 남는 아쉬움과 상처같은 부정적인 감정도 운동 후의 근육통처럼 여긴다면좀 더 쉽게 다음에 시도할 수 있지 않을까라는 생각이 들었습니다. 연휴 동안 목표를 정해놓고 달성하는 것의 즐거움을 느낀 것 같습니다.모두 운동이나 사이드 프로젝트 등 다음 아궁이 불을 찾아 때워서, 다음 챌린지 때 뵈었으면 좋겠습니다.추석 연휴 동안 수고 많으셨습니다!

커리어 · 자기계발 기타･회고･챌린지

4

3

코틀린 상속 간 주의점

코틀린 넌 왜 나에게 이런 시련을 주는건가.. 연휴기간 동안 코틀린 상속 관련 공부를 진행하다가 재미난 이슈가 있어서 한번 공유드릴려구요!아래의 2개의 클래스가 있습니다. 보시는 바와 같이 Child class가 Parent 클래스를 상속받고 있지요.package me.sungbin.troubleshooting open class Parent( open val number: String = "100" ) { init { println("Parent Call") println(number) } }package me.sungbin.troubleshooting class Child( override val number: String, ): Parent() { init { println("Child Call") } }그리고 아래와 같이 main 함수에서 Child class 생성자를 호출합니다.package me.sungbin.troubleshooting fun main() { Child("300") } 그러면 결과는 어떻게 찍힐까요?저는 처음에 아래와 같이 생각했습니다. 부모 클래스의 생성자가 호출되면서 number값을 출력할 때 오버라이딩 되었으니 자식 클래스의 number값을 호출하지 않을까? 그래서 아래와 같이 생각했었습니다.Parent Class 300 Child Class그런데 실제 결과는 달랐습니다.Parent Class null Child Class오잉? 이상하지 않은가요? 그래서 자바코드로 디컴파일 해보고 공식문서를 찾아본 결과 정답에 대한 솔루션을 알 수 있었습니다.공식문서: 공식 문서 링크왜 그런가 싶더니 코틀린 공식 문서에서 아래와 같이 이야기 하더라구요!파생 클래스의 새 인스턴스를 생성하는 동안 기본 클래스 초기화는 첫 번째 단계로 수행됩니다(기본 클래스 생성자의 인수 평가에 의해서만 선행됨). 즉, 파생 클래스의 초기화 논리가 실행되기 전에 수행됩니다.코틀린의 공식문서의 해당 내용을 번역해보았습니다.즉, 기본 클래스 생성자가 실행될 때 파생 클래스에서 선언되거나 재정의된 속성은 아직 초기화되지 않은 상태입니다. 기본 클래스 초기화 로직에서 이러한 속성을 사용하면 (직접적으로든 다른 재정의된 멤버 구현을 통해 간접적으로든 ) 잘못된 동작이나 런타임 오류가 발생할 수 있습니다. 따라서 기본 클래스를 설계할 때는 생성자, 속성 초기화자 또는 블록에 멤버를 open사용하지 않는 것이 좋습니다.즉, 요약 하자면 아래와 같을 것입니다.자식 생성자를 호출한다 -> 그 전에 부모 생성자를 호출하려고 할 때 먼저 init block을 호출한다. number 값을 출력하려고 보니 재정의되어서 자식 클래스에 접근한다. -> 그런데 자식 클래스 생성자 전이니 해당 값은 알 수 없다 -> 따라서 null로 출력한다. 그런데 저는 여기서 또 의문이 들었습니다. 분명 선언된 것은 non-nullable 타입인데 어떻게 null이 나오는거야? 또한, 신기한 것은 타입을 String -> Int로 변경 시에는 기본 값 0이 나오더라구요! 그래서 또 한번 30분간 연구를 해보았습니다. 그 덕에 조금 답을 얻을 수 있었는데요.초기화 순서를 먼저 보면 좋을 것 같아요.Child("300") 호출 → Parent() 생성자 호출(슈퍼 생성자 호출이 먼저).Parent의 init가 실행되며 println(number) 수행.number는 open 프로퍼티라서 가상 디스패치로 Child.number getter를 타게 됩니다.하지만 이 시점에는 Child.number의 백킹 필드가 아직 할당 전이므로, 원시 타입 Int → JVM 기본값 0, 레퍼런스 타입(예: String) → JVM 기본값 null이 반환된다고 하더라구요.Kotlin의 Non-null 보장도 생성 중(super 생성자 실행 중)에는 예외적으로 깨질 수 있습니다.그래서 값이 다르게 나왔다고 하더라구요!후기해당 과정은 정말 1시간 동안 연구하면서 공식문서를 뒤져보고 gpt한테도 물어보면서 얻은 답변들이였습니다. 그래서 뭔가 재미나면서도 다른 분들께 공유를 드리면 좋을 것 같아서 해당 포스팅을 진행하게 되었습니다. 이렇게 연구하게 된것도 어찌보면 인프런에서 진행하는 '향로' 와 함께하는 추석 완강 챌린지 덕도 큰 것 같습니다. 연휴가 이제 거의 절반을 지난 것 같은데 남은 연휴기간도 화이팅입니다!

백엔드･kotlin

3

2

[군대에서 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월 전역이네요 하하..)

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

2

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

[K-DEVCON 2025] K-Devcon Hunters 일원이 되어주세요!

안녕하세요. K-DEVCON 입니다!1년 만에 돌아온 DEVCON, 이번 컨퍼런스 테마는 "K-Devcon Hunters"로 헌터들의 탐험에 여러분을 초대합니다. 새로운 지식과 기술, 그리고 연결을 찾아 나서는 15명의 연사자님과 함께 여러분도 IT 미지의 영역을 향한 여정에 합류하시길 바랍니다. 여러분도 이제, K-Devcon Hunters의 일원이 되어주세요! 📅일시: 2025년 11월 1일(토) 13:00~18:00 (5시간)📍장소: 한국 마이크로소프트 (서울 종로구 종로1길 50, 더케이트윈타워 A동 13층)🏷 티켓구매링크 : https://www.ticketa.co/events/33✅티켓 구매 후 사전이벤트도 같이 참여해주세요 -> 사전이벤트 오픈 일시 9월 27일(토) 오후 6시 👋 K-DEVCON이 궁금하다면? 홈페이지 / 링크드인 / 인스타그램 / 슬랙

커리어 · 자기계발 기타･K-DEVCON･세미나･개발･IT

1

인공지능과 추천 시스템 강의 노트 - 2025. 9. 13. (2/16)

들어가며타이트해진 출석 체크와 작년 대비 추가된 중간과제와 기말과제 조건들 덕인지 꽤 많은 학생들이 다른 선택들을 하였고, 인원은 58명으로 정해졌다. 이제 조금 기대치가 조절되고 있는 셈이니 내년에도 이 과목을 내가 하고 있을 지는 모르지만, 학과를 위해서는 강의 평가도 좋은 점수가 나와야 할텐데 하는 걱정도 적지 않게 든다.공개된 데이터를 가지고, EDA 를 자유 형식으로 하라는 중간 과제가 서로 낯설어서 질문들이 많다. Kaggle , Dacon 등에서 보이는 ‘내가 봐도 문제 없는 데이터’를 가지고 직장 상사에게 보고하는 형태의 보고서를 쓴다는 생각으로 과제를 정의하고 있다. 데이터의 형식, 문제 정의 등에 대해 피드백을 주고 받을 생각으로, 각자 도메인에서 의미있는 해석들이 있으리라 기대가 된다.구름이 잔뜩 낀, 하지만 매력적인 서울 하늘 준비한 내용들2주) 강의 updateAI 강의 - 1강추천시스템 - 1Google(Playstore)에서 과제 런칭하기 - 1 이번 주에 있었던 일들로는 굵직굵직한 OpenAI 의 한국 행보와 구글 검색의 AI 모드 전면 배치 등이 있었다. 사상 최고를 경신하고 있는 코스피 자체도 관심 있게 챙겨야 하겠다. 나눈 이야기들약간의 역사적인 이야기가 들어 있는 인공지능 이야기와 추천 시스템의 입문에 대해 다루었다. 추천 시스템이라는 단어들도 오해가 많은 영역이라, 이 강의에서는 완성된 사용자 위주의 제품의 시각에서 접근과 그걸 가능하게 하는 방법론에 대해 이야기를 많이 하게 된다. 다음 시간부터는 각 내용들에 대해 요즘 시각에서 익숙한 이야기들을 담게 되겠다.유사 쇼핑몰의 개념으로 구글 플레이스토어 이야기를, 완제품의 시각에서 구글 검색 이야기를 내부자의 관점에서 많이 하게 될 것이라 ice-breaking 으로 구글 플레이스토어 이야기를 꽤 일찍부터 시간을 많이 할애하기로 했다. 지표들에 대해서까지 대략적으로 이야기를 하였는데, 아무래도 바깥에서 이야기하기에 한계들이 있는 영역이라 여러 번 감정 이입을 해 가며 정리를 해야 하겠다. ps.인프런에 올라가 있는 유료 강의들을 원하는 학생들에게는 무료로 제공하자 싶어 본의 아니게 인프런 광고를 조금 하게 되었다. 도움이 필요한 분들께 조금이라도 도움이 되면 하는 바램이다.

대학 교육 기타･인공지능･금융･추천

1

0

[2025 정보보호 인재양성 교육사업 성과공유회 참가 신청 안내]

안녕하세요, 2025 정보보호 인재양성 교육사업 성과공유회가 오는 12월 19일 (금) 개최됩니다. 정보보호 인재양성의 최신 방향과 우수 사례를 한 자리에서 확인할 수 있는 의미있는 자리이니 많은 관심과 참석 부탁드립니다. ☆ 일시2025년 12월 19일 (금) 10:00-15:10 ☆ 장소삼정호텔 아도니스 홀 (1F)*서울시 강남구 봉은사로 150 ☆ 사전 등록 링크링크 바로가기 *사전등록자 중 현장 도착 선착순 120명 대상 호텔 중식 제공 많은 참여 부탁드립니다!감사합니다.

보안･정보보안･성과공유회

0

[인프런 클론 6주 완성 챌린지] 배우기와 익히기의 밸런스

개인적으로 이번 챌린지를 신청하는 데 많은 용기가 필요했다.하나는 타인의 문제 해결을 클론코딩하면서 내가 문제를 해결하는 문제해결력이 떨어지는 것이 아닌가 걱정했기 때문이고,다른 하나는 내 자신의 문제해결력에 하자가 있다는 것을 인정해야 했기 때문이다. (주의: 개인적인 맥락 하에서만 맞는 얘기입니다. 일반적으로 클론코딩 수업을 듣는다고 문제해결력에 하자가 있다고는 생각하지 않습니다.)이번 챌린지를 신청했을 때 했던 생각은 약간 자포자기하는 심정으로 '내 문제해결력이 떨어지는 리스크를 감수해서라도 나는 백엔드 개발을 한 바퀴를 돌려봐서 흐름을 파악해야겠다'였다. 또 '지금 못해도 배워서 잘 하면 되지'라는 말로 못하는 내 자신을 용서하는 과정도 필요했다.뚜껑을 열어보니 예상외로 챌린지에 참여하기를 정말 잘한 것 같다는 생각이 들었다. 일단 지금까지는 그렇다. 모방하고 이를 돌아보는 과정에서 내 문제 해결의 어떤 부분에서 하자가 있는지를 파악할 수 있었기 때문이다.실마리는 불안한 상태에서도 퍼포먼스를 내는 방법을 고민하면서 찾아왔다. 문득 '불안한 상태에서도 손이 자동적으로 나가도록 무지성 연습을 하면 불안할 때도 내 실행 능력의 저점은 보장되지 않을까?'라는 생각이 들었다. 그래서 nestjs 첫 프로젝트 수업을 2회, 컨트롤러는 3회 반복해서 구현했다. 반복하면서 다음 생각이 들었다.내가 불안감을 느끼면서 막혔던 이유는 동시에 문제 2-3개를 해결해야 해서 압도당했기 때문이다.예를 들면 nestjs controller 구현 + 클론 코딩 과정에서 현재 단계에 대한 이해작업이 어려워서가 아니라 코드가 손에 안 익어서 막힌다.간단한 게시글에 대한 crud 작업 연습에서 사실 "이해"가 필요한 부분은 거의 없다. 반복하면서 막혔던 이유는 전부 nest가 손에 안 익어서였다.그러면서 이런 생각이 들었다.모든 학습 과정은 배우기('학')와 익히기('습')가 동반된다. 프로그래밍의 경우 과목 특성인지 배움 없이 익히기에 치중한 학습자들이 많아서인지는 모르겠지만 이 중 정확한 이해를 통한 배우기가 특히 강조된다고 개인적으로 느꼈다.배우기와 익히기의 비중은 프로그래밍의 하위 분야에 따라 많이 다른 것 같다. 알고리즘 학습의 경우 (PS만큼 어렵지는 않은 맥락에서는) 배우기를 잘 하면 익히기는 상대적으로 수월하게 되는 것 같고, 웹 개발의 경우 배우기와 익히기 둘 다 의식적인 노력이 필요한 것 같다.나는 지금까지 내가 알고리즘은 못하더라도 "뭔가 잘 맞고" 웹 개발은 "뭔가 잘 안 맞는다"고 생각했는데, 적성의 문제가 아니라 학습 방법의 문제인 것 같다는 생각이 들었다.이제 앞으로 할 일은 막힐 때 어떤 부분으로 인해 병목이 생기는지를 파악해서 그 부분의 문제를 하나씩 해결하면 되지 않을까 싶다.

백엔드･학습일기･nest･클론코딩

0

✨ K-DEVCON에서 시스템 디자인 스터디 멤버를 모집합니다(~11/26(일)까지 모집)

✨ K-DEVCON에서 시스템 디자인 스터디 멤버를 모집합니다(~11/26(일)까지 모집) 👏K-DEVCON 에서는 25년 9월 부터 11월까지 약 2개월 동안 계획했던 8회의 시스템 디자인 스터디를 성공적으로 마무리하였습니다. 그 흐름을 이어 다음 시스템 디자인 스터디에 참여하실 분을 모집합니다. 🚀 IT 엔지니어라면 누구나 고민하는 대규모 시스템 설계, 이제 함께 공부하고 실전 감각을 키워보세요!!! 📖 교재: 『가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 (1~6장)』 📅 일정: 12월 4일(목) 시작 / 매주 목요일 저녁 19:30~21:00 (총 6주) (연휴/공휴일은 일정 조정) 📍 장소: 성수역 인근 스터디룸 🙋🏻 인원: 약 10명 내외 💵 비용: 5만원 (스터디 운영을 위해 사용 예정) ⏰ 모집 기한: 11월 26일 까지!!! ⚙ 기대 수준: 중급 개발자 (3년차 내외) 이번 스터디는 단순 독서 모임이 아닌, 실제 시스템 설계를 함께 고민하고 토론하는 실전형 스터디입니다. 관심 있는 분들의 많은 신청 바랍니다! 👉 [자세한 안내] https://k-devcon.com/164👉 [신청 링크] https://lnkd.in/gDj7iVnr

시스템 · 운영체제･시스템디자인･시스템엔지니어

0

주섬이 웹서비스를 출시하기까지

주섬이 웹서비스를 출시하기까지부제 : 홍보인 듯 회고인 듯, 회고인 듯 홍보인 듯 안녕하세요, 링크저장 앱 주섬을 운영하고 있는 팀 핑크보스입니다. 혹시 저희 서비스, 링크저장 앱 주섬을 들어보신 적이 있으신가요? 주섬은 링크를 편리하게 저장, 분류, 관리할 수 있게 도와주는 서비스입니다.주섬 프로젝트는 23년 4월, 직장인 사이드프로젝트로 시작되었고 같은 해 8월에 iOS 출시, 이후 운영과 고도화를 계속하고 있고, 올해 n월 웹서비스까지 출시하게 되었답니다! 주섬이 처음이신 분들을 위해, 주섬이 어떤 서비스인지 잠깐 소개해드릴게요! 링크, 자주 저장하시나요? 그렇다면 잘 찾아오셨습니다.레퍼런스 저장, 구매가 고민되는 상품, 놓치기 싫은 플레이리스트, 그냥 웃겨서 저장해두는 글 등, 우리는 평소에 링크를 참 많이 저장해요. 그런데 그렇게 저장해둔 링크들, 정말 다시 찾아서 열어보시나요?카톡 나만의 채팅방이나 메모장에 쌓아만 두고 계시진 않나요?분명히 나중에 보려고 저장했는데 까먹었다가 막상 다시 보려니 어디에 저장했는지 까먹어서 메모장과 나만의 채팅방을 뒤적뒤적…… 어떤 링크인지 잘 안 보여서 몇 개를 열었다 닫았다 반복하면서 🤯🤯🤯링크 하나 찾다가 짜증이 확 올라오는 경험, 모두 한 번씩은 해보셨을 거예요. 실제로 링크 저장과 관련 사용자 경험 설문을 해보니 응답자의 70% 이상이 링크를 저장해둔 사실을 잊어버리는 것이 불편하다고 응답했고, 응답자의 40% 이상이 원하는 링크를 찾기 힘들어서 불편하다고 응답했어요. 그래서 주섬은 이런 기능을 제공해요편리한 저장 : 웹이나 앱에서 링크를 복사하거나 공유패널을 이용하여 간편하게 저장링크 제목 수정 : 링크 제목은 내가 알아볼 수 있게 직접 수정폴더 커스터마이징 : 원하는 만큼 폴더를 생성하고 내 마음대로 커스텀!태그 : 부가정보를 담을 수 있는 태그 추가 및 태그 필터 기능 제공읽지 않은 링크 알림 : 알림을 켜두면 읽지않은 링크는 PUSH 알림을 줘요 🙋‍♀ 평소 링크를 많이 저장해두는 분🙋 링크를 쌓아두기만 하고 다시 열어보는 게 가장 어렵게 느껴지시는 분🙋‍♂ 내 마음대로 링크를 분류, 정리해두고 필요할 때 빠르게 찾아보고 싶은 분 이런 분들에게 딱 맞는 서비스랍니다. 현재 앱은 iOS만 지원되고 안드로이드는 개발 중이예요! 웹서비스 출시, 이제 PC에서도 쓸 수 있어요!사실 이 글은 조금 두서 없었지만 웹서비스 출시 홍보글이랍니다. 올해 11월, 드디어 주섬 웹서비스가 출시 되었거든요!박수갈채 타임 갖겠습니다. 뿌이뿌이뿌이 뿌이~~~ 🥳🎉🎉🎉🎉(주섬 웹서비스 출시에 대한 객관적인 비평 또는 피드백? 그런 거 원하지 않습니다. 무조건 박수갈채. 일방적이고 편향적인 칭찬 부탁드립니다.) 아래 URL로 접속하여 주섬 웹서비스를 사용해보세요!https://app.joosum.com/원래 주섬 사용자셨다면 기존 계정으로 로그인하여 사용할 수 있어요. 처음 사용해보신다면 소셜 로그인으로 간편하게 가입하고 웹, 앱서비스를 함께 사용해보세요! 웹서비스 출시, 왜 했을까요?주섬 iOS 출시 후 운영과 고도화를 계속하면서, 팀원들이 직접 주섬을 사용하면서 느낀 불편한 점들도 같이 공유하고 개선해왔는데요.가장 큰 고민 중 하나는 iOS 앱으로만 지원이 되니 PC에서는 지원이 되지 않는다는 것이었어요. 모바일에서 주섬으로 링크를 편하게 관리할 수 있더라도 PC에서 링크 저장 시에는 다른 방법을 써야 한다면 결국은 디바이스마다 링크 저장 경로가 달라지면서 링크를 다시 찾아보기 어려워지게 돼요. 어떤 링크를 찾아보려고 할 때 어느 정도는 기억에 의존해야 하고, 기억이 나지 않는다면 결국엔 핸드폰에서 주섬을 뒤져보고, PC에서는 PC 저장경로를 뒤져보는 행동을 반복하게 되었어요. 즉, 주섬이 원래 해결하고자 했던 문제가 다시 발생하는 거죠. 🥲 : 링크 저장한 건 많은데, 막상 다시 쓰려고 하면 어디 있는지 몰라서 또 검색하게 돼… 이러한 문제점을 해결하려면 PC와 모바일에서 통합적으로 사용할 수 있도록 앱서비스와 연동된 웹서비스 출시가 필요하다고 생각했죠. 그래서 출시 후 6개월이 지난 어느 날, 핑크보스는 주섬 웹서비스 개발 계획을 세우게 되었어요. 물론 과정은 쉽지 않았어요. 웹개발자 구인, 직장인 팀원들의 야근 이슈, 우선순위 정리….. 등 다양한 이슈로 예상보다는 진행이 늦어졌지만 그래도 드디어! 웹서비스 출시를 할 수 있게 되었답니다. 그럼, 어떤 점이 좋아졌을까요?주섬은 이번 웹서비스 출시로, 앱/웹 통합 링크저장 서비스로서 더욱 향상된 사용경험을 제공할 수 있게 되었어요.그럼 본격적으로 저희 웹서비스 자랑을 좀 해볼게요 🤗 하나, 모든 기기로 이어지는 자연스러운 흐름스마트폰에서 저장한 링크를 PC에서 바로 열어보고,PC에서 저장한 링크도 앱에서 손쉽게 확인할 수 있어요.디바이스에 구애받지 않고, 언제 어디서나 원하는 링크에 즉시 접근하세요.링크를 저장하는 순간부터, 활용하는 순간까지 끊김 없이 연결돼요. 둘, PC 환경에 최적화된 사용경험그냥 옮긴 게 아니라, 새로 설계했어요. 모바일 앱의 기능은 가져오면서 PC에 맞게 새롭게 구성한 UIUX를 적용했어요.넓은 화면을 살려 화면 이동 없이 링크 내용을 확인하고, 어떤 화면에서도 폴더 목록을 보고 정리할 수 있어요.정리와 탐색이 더 빠르고 편리해졌어요! 셋, 더욱 편리한 검색찾고 싶은 링크가 있다면 PC 버전 상단 검색창에서 링크 제목으로 검색해보세요. 어느 화면에서나 폴더에 상관없이 바로 검색하여 ‘찾는 시간’을 줄여보세요. 넷, 하나로 모아지는 저장경로, 높아진 생산성이제는 흩어지지 말고, 주섬 하나로 통합하여 링크를 더 잘 활용해보세요. 어디에서 저장하든 내가 만든 폴더와 태그로 정리하고, 필요할 때 언제든 쉽게 찾아보세요. 잘 정리해둔 나만의 링크 목록, 당신의 생산성을 높여줄 거예요. 주섬, 많이 사랑해주세요!주섬은 처음 출시한 이후, 꾸준히 운영과 고도화 작업을 지속하고 있으며 안드로이드 출시도 앞두고 있답니다. 웹서비스 출시로 더욱 다양한 기기와 환경에서 사용이 가능해지면서 더 많은 가능성이 생겼고‘링크 관리를 통한 생산성 향상’에 집중하여 더욱 나은 경험과 가치를 드리기 위해 고민하고, 노력하고 있어요. 앞으로도 이런 주섬, 많은 관심과 성원과 응원과(중요) 앱 다운로드와(중요) 사용 부탁 드리며, 궁금한 점이나, 피드백이 있으시다면 언제든지 pinkjoosum@gmail.com 으로 보내주세요! 주섬 앱 다운로드 하기(iOS)https://apps.apple.com/kr/app/주섬-joosum/id6455258212

기획 · PM· PO･출시･회고･웹서비스･사이드프로젝트･링크저장･아카이빙

0

[인프런 클론 6주 완성 챌린지] 오늘을 기억하고 싶다.

오늘은 처음으로 불안에 직면했을 때 긍정적인 피드백을 받은 날이다.처음 노트북을 꺼내들었을 때는 불안에 떨고 있었는데, 중간에 tailwind 스타일링 할 때 따라해보면서 변주를 주는 과정에서 몰입이 되었고, 시간 가는 줄 모르고 강의 끝까지 따라치게 되었다. 강의가 끝났을 때의 성취감, 효능감이 장난이 아니었다.물론 객관적으로는 한 것은 정말 아무것도 없다. 강의에서의 로그인 플로우를 따라 친 것이 전부이다. 그리고 냉정하게 돌아본다면 내가 몰입할 수 있는 일의 난이도는 tailwind 스타일링 및 강의를 그대로 따라치는 수준에 불과하다.하지만 오늘은 그런 것보다도 일주일동안 불안한 상태로 애쓴 내 자신에게 고생했다는 말을 해주고 싶다.그리고 미래에는 조금씩 더 어려운 일들에도 직면할 수 있을지도 모르니 희망을 잃지 말자는 생각이 들었다.이 순간을 기억하기 위해 조금만 쉬었다 다음 강의로 넘어가야겠다.

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

0

Snowflake BUILD KOREA 웨비나 – 개발자를 위한 AI·데이터 실전 인사이트

안녕하세요, 여러분!데이터와 AI의 흐름이 빠르게 진화하는 요즘,Snowflake Korea가 준비한 웨비나“BUILD with us in the Age of AI”에 여러분을 초대합니다. 📅 일시: 2025년 12월 9일 (화) 14:00–16:30🔗 등록하기: https://buly.kr/1xzeDO7 이번 웨비나는 단순한 기술 발표를 넘어, 개발자가 당장 실무에 활용할 수 있는 AI·데이터 인사이트를 얻을 수 있는 자리입니다. 정형·비정형 데이터를 활용한 AI 에이전트 개발부터 ML 프로젝트 운영까지 다양한 실전 노하우를 공유합니다. 🎉 다양한 이벤트도 준비되어 있습니다!웨비나 참여자분들을 위한 스페셜 이벤트와 경품도 마련되어 있어요.참여만 해도 Snowflake가 준비한 사은품, 기술 리소스, 다시보기 영상 등을 받을 수 있으니 부담 없이 들어오셔서 혜택도 챙기고 인사이트도 얻어가세요! 🎁 등록자 혜택 • 글로벌 BUIL D 주요 세션(한글 자막 포함) 8편 다시보기 제공 • Snowflake 기술 자료 및 개발자 리소스 제공 • 라이브 참여자 대상 특별 이벤트 및 기념품 AI와 데이터를 중심으로 새로운 시대를 만드는 데 관심 있는 개발자라면 놓치지 마세요. 12월 9일에 함께해요! #Developer #AI #DataCloud #Snowflake #BuildKorea

데이터베이스･Developer･DataCloud･AI･Snowflake･BuildKorea

0

[책추천] SQL 코딩 테스트를 준비한다면 | SQL 실전 트레이닝

(원본: https://blog.naver.com/italian-lesson/223972366847)나의 본업은 데이터 분석가이다. 그중 SQL은 회사에서 메인으로 쓰는 나의 언어이다. 내가 좋아하는 언어는 이탈리아어와 SQL인데, 그중 SQL은 제한적인 문법만으로 데이터를 원하는 방식으로 추출할 수 있다는 게 마음에 든다. 그런 내가 SQL과 관련된 책을 썼다. 교보문고, yes 24, 알라딘에서 구매 가능하다.https://product.kyobobook.co.kr/detail/S000217223580 저자 소개에서도 포기할 수 없었던 내 이탈리아어 블로그 🌈내가 SQL 코딩 테스트를 준비할 때 사용했던 방식을 책에 녹였기 때문에 극강의 효율로 SQL을 공부할 수 있는 책이다. 차별 포인트 #1SQL 이론이 아닌 SQL 문제 풀이로 구성된 책이다. 수학의 정석 같은 느낌보다 수학 익힘책 같은 책이다. 이론을 아무리 배워봤자 막상 문제를 풀려고 하면 못 푸는 것을 수학 공부할 때 다들 느껴보았다. 어느 정도 이론을 알았다면 바로 문제를 풀어보는 것이 더 효과적이다. 차별 포인트 #263개의 SQL 문제들을 18개의 유형으로 정리하였다. 그래서 이 중에서 내가 약한 유형을 집중적으로 파볼 수 있다.유형 1. INNER JOIN유형 2. LEFT OUTER JOIN유형 3. CROSS JOIN유형 4. FULL OUTER JOIN유형 5. GROUP BY유형 6. HAVING유형 7. MIN, MAX유형 8. SUM, COUNT유형 9. CASE WHEN유형 10. IFNULL유형 11. LIMIT유형 12. NOT IN유형 13. RANK유형 14. DENSE_RANK유형 15. ROW_NUMBER유형 16. LAG, LEAD유형 17. DATE유형 18. CONCAT 각 유형 안에서 또 문제의 유형을 나누었다. 그래서 만약 GROUP BY가 어렵다면 어떤 유형의 GROUP BY 문제가 약한지 추가적으로 파악해 볼 수 있다. (문제 유형을 확인하고 싶다면 교보문고/yes24/알라딘 링크의 '목차' 부분에서 확인 가능!)책 마지막 부분에 문제 세트 3개로 마무리된다. 문제 세트에서는 여러 유형들이 섞여 있기 때문에 복습하기에 좋다. 차별 포인트 #3이렇게 다른 방법으로도 풀 수 있다는 다른 정답 풀이도 있고, 이렇게 풀면 틀리다는 오답 풀이도 있다. 수학 문제를 풀 때도 선생님이 푸는 방식은 이해가 가는데, 왜 내가 푸는 방식은 틀린 거지? 내 방식으로 풀면 안 되나?라는 질문이 뒤따른다. 그러한 궁금증을 해소하기 위해 다른 정답 풀이와 오답 풀이에 힘을 많이 썼다. 특히 오답 풀이는 내가 처음 SQL 문제를 풀었을 때 잘못 풀었던 방식이다. 우리 모두 별반 다르지 않기 때문에 내가 그런 실수를 했다면 다른 사람들도 똑같이 실수할 것이다. 그리고 이때 왜 자신이 틀렸는지 정확히 아는 것이 중요하고 그때 실력이 확 는다.차별 포인트 #4중간중간 이해를 돕기 위해 도식화한 그림들도 많다. 모든 유형에 직접 한 땀 한 땀 파워포인트로 만든 그림들을 추가하였다. (역시 파워포인트로 뭐든지 할 수 있음)어찌 보면 나한테 쉽게 설명하려고 그린 그림이기도 하다. 특히나 처음 JOIN을 배웠을 때 데이터가 결합하는 방식이 헷갈렸다. JOIN이 나올 때마다 어떻게 데이터가 연결되는지 하나하나 다 연결해서 표시하였다. 예상 독자SQL 코딩 테스트를 위해 준비했던 방식을 책에 녹인 것이긴 하지만 무조건 코테 대비용은 아니다. 크게 보면 SQL을 구현하는 데는 어려움을 겪고 있는 초보자를 위한 책이다. 이런 초보자들은 이론적 설명 보다 문제를 통한 학습이 이해하기 쉽고 기억에도 더 잘 남는다. 그 외에도 헷갈리는 포인트, 실무에서 깨달았던 SQL 구현 꿀팁들도 녹였다. 실무에서 직면하는 문제를 해결하는 데 필요한 실전 경험을 미리 쌓아볼 수 있다.

데이터 분석･SQL･SQL실전트레이닝･SQL코딩테스트･코딩테스트

0

레거시 결제/정산 백엔드 서비스 재구축

1. 프로젝트 소개>프로젝트 목표:현재 운영 중인 레거시 결제/정산 백엔드 시스템의 구조적 문제점(낮은 유지보수성, 강한 종속성, 불안정한 확장성)을 해결하고, 클린 아키텍처를 적용하여 고도로 안정적이며 변화에 유연하게 대응할 수 있는 차세대 결제/정산 시스템으로 전환하는 것입니다.>주요 기능:핵심 결제 로직 재구현: 안정적인 결제 승인, 취소, 환불 로직 처리.정산 시스템 고도화: 일별/월별 정산 데이터 생성 및 관리, 복잡한 수수료 및 분배 로직 처리.PG사 연동 모듈 분리: 다양한 외부 결제대행업체(PG사) 및 금융기관 연동을 위한 인터페이스(Gateway)를 명확히 분리하여, PG사 변경이나 추가에 유연하게 대응.고성능 트랜잭션 처리: 대량의 결제 트래픽을 안정적으로 처리할 수 있는 성능과 트랜잭션 무결성 확보.2. 클린 아키텍처 선택 동기-기존 레거시 방식의 문제점기존 레거시 결제/정산 시스템은 다음과 같은 구조적 문제점을 내포하고 있어, 장기적인 운영 및 개발에 심각한 어려움을 초래했습니다.DB/프레임워크에 종속된 비즈니스 로직:핵심 결제 및 정산 비즈니스 규칙이 데이터베이스 접근 코드(SQL, ORM)나 특정 웹 프레임워크(예: Spring Controller, Django View)의 구현체에 강하게 결합되어 있었습니다.이로 인해 DB 스키마나 프레임워크 버전이 변경될 때마다 핵심 비즈니스 로직까지 대규모의 수정이 필요했습니다.-낮은 유지보수성과 확장성:시스템의 핵심인 결제 로직이 외부 기술과 얽혀있어, 새로운 결제 수단이나 복잡한 정산 정책이 추가될 경우 코드 전체를 건드려야 했으며, 이 과정에서 코드의 유연성과 유지보수성이 현저히 저하되었습니다.-테스트의 어려움:순수한 비즈니스 로직을 테스트하기 위해서도 반드시 데이터베이스 연결이나 웹 환경 설정이 필요하여, 단위 테스트 작성이 어렵고, 기능 변경 후 안정성을 신속하게 검증하기 어려웠습니다.-클린 아키텍처 적용 동기결제/정산 시스템은 회사의 수익과 직결되는 미션 크리티컬(Mission-Critical)한 핵심 도메인입니다. 클린 아키텍처는 이러한 핵심 도메인의 안정성과 장기적인 유지보수성을 극대화하는 최적의 솔루션입니다.-핵심 비즈니스 로직 보호 (Independent of Frameworks, DBs, UIs):클린 아키텍처는 핵심 비즈니스 규칙(도메인)을 DB, Web Framework, UI와 같은 외부 기술 요소로부터 완벽하게 분리하여 보호합니다.이는 시스템의 생명주기가 길어질수록, 프레임워크의 변화나 DB 마이그레이션과 같은 외부적인 변화에도 결제/정산 로직의 안정성을 흔들림 없이 유지할 수 있게 합니다.-높은 테스트 용이성 확보:Use Case(유스케이스, Interactor) 계층에 비즈니스 로직을 집중하고, 이를 외부 인프라(DB Repository)의 구현체에 의존하지 않도록 설계합니다.결과적으로 DB 연결 없이도 순수한 비즈니스 로직만을 독립적으로 테스트할 수 있어, 리팩토링 및 기능 확장 시 안정성을 매우 높일 수 있습니다.-SOLID 원칙 준수 및 장기적인 유지보수 극대화:클린 아키텍처는 SOLID 원칙을 자연스럽게 유도하며, 특히 SRP(단일 책임 원칙)와 OCP(개방-폐쇄 원칙)에 따라 시스템을 설계하도록 장려합니다. 이는 결제, 정산, 환불 등 각 기능별 유스케이스의 책임을 명확히 하고, 기존 코드를 수정하지 않고도 새로운 기능을 추가할 수 있는 유연하고 확장 가능한 구조를 확립합니다.

0