본문 바로가기

분류 전체보기

(136)
[Spring Boot] Spring Batch Chunk 지향 처리: 1,000만 건 메모리 최적화의 꽃 앞선 33단계에서 우리는 Spring Batch의 기본 뼈대인 Job과 Step을 배웠습니다. 하지만 실무에서 주어지는 '1,000만 명의 VIP 등급 업데이트' 같은 거대한 과제를 단일 Tasklet으로 처리하려 든다면, List users = userRepository.findAll()을 호출하는 순간 1,000만 개의 자바 객체가 메모리(RAM)에 올라가며 1초 만에 OOM(OutOfMemory) 에러와 함께 서버가 폭발하게 됩니다. 그렇다고 1건씩 DB에서 읽어와서 1건씩 UPDATE 쿼리를 날린다면? 1,000만 번의 네트워크 I/O(통신 비용)가 발생하여 배치가 끝나는 데 일주일이 넘게 걸릴 것입니다. 메모리를 터뜨리지 않으면서도 미친 듯이 빠른 속도를 내는, 이 두 마리 토끼를 잡기 위해 고..
[Spring Boot] Spring Batch 입문: 1,000만 건의 데이터를 씹어 삼키다 웹 서비스 백엔드 개발자들은 주로 사용자가 스마트폰에서 버튼을 누르면 0.1초 만에 응답(JSON)을 주는 '실시간(Real-time)' 처리에 익숙합니다. 그런데 실무에서는 이런 요구사항이 비일비재하게 떨어집니다. "매월 1일 자정마다, 전체 회원 1,000만 명의 지난 한 달 치 결제 내역을 싹 다 조회해서 합산한 뒤, 50만 원 이상 쓴 사람들의 등급을 VIP로 업데이트하고 쿠폰을 발급해 주세요." 이 작업을 일반적인 스프링 웹 컨트롤러 안에서 for문 1,000만 번을 돌려서 처리하면 어떻게 될까요? 99.9% 확률로 메모리 초과(OOM)로 서버가 죽거나, 중간에 DB 커넥션이 끊겨서 '500만 명까지만 처리되고 멈추는' 끔찍한 대참사가 벌어집니다. 500만 명을 다시 어떻게 롤백할까요? 상상만 ..
[Spring Boot] STOMP와 RabbitMQ: 엔터프라이즈급 실시간 채팅의 완성 이전 31단계에서 우리는 순수 WebSocket을 사용해 양방향 통신을 뚫어보았지만, "단톡방 구분이 안 된다", "메시지 포맷이 중구난방이다", "서버가 여러 대면 통신이 끊긴다"는 치명적인 세 가지 장벽에 부딪혔습니다. 실무 카카오톡이나 디스코드 같은 대규모 실시간 서비스는 이 문제를 어떻게 해결할까요? 바로 웹소켓이라는 텅 빈 고속도로 위에, STOMP(Simple Text Oriented Messaging Protocol)라는 엄격한 교통 규칙(신호등과 차선)을 세우고, 여러 서버 간의 메시지 배달을 책임지는 RabbitMQ(메시지 브로커)라는 거대한 우체국을 도입하는 것입니다.이번 [Spring Boot 실무 완벽 가이드] 시리즈에서는 "실무 실시간 서비스 아키텍처의 절대 표준!" STOMP 프..
[Spring Boot] WebSocket 실시간 채팅: 양방향 통신의 서막 우리가 매일 사용하는 카카오톡이나 주식 거래 앱의 호가창은 어떻게 실시간으로 데이터가 번쩍번쩍 업데이트될까요? 초보 개발자들은 프론트엔드에서 setInterval() 함수를 써서 1초마다 백엔드에 "새로운 채팅 온 거 있어?"라고 묻는 폴링(Polling) 방식을 떠올립니다. 하지만 1,000명의 유저가 1초마다 빈 요청(HTTP)을 보내면 서버는 채팅을 하기도 전에 트래픽 폭탄을 맞고 터져버릴 것입니다. 웹의 근간인 HTTP는 본래 '단방향(클라이언트가 물어보면 서버가 대답하고 끊음)' 통신이기 때문입니다.이 HTTP의 태생적 한계를 부수고, "클라이언트와 서버가 한 번 손을 잡으면(Handshake) 연결을 끊지 않고, 서버가 원할 때 언제든 클라이언트에게 데이터를 쏴줄 수 있는 고속도로"를 뚫어주는..
[CSS] 실무에서 자주 쓰이는 Flexbox UI 패턴 5가지 완벽 정복 Flexbox의 문법(Container와 Item 속성)을 완벽히 암기했다 하더라도, 막상 피그마(Figma) 디자인 시안을 던져주고 코드로 구현하라고 하면 눈앞이 하얘지는 초보 퍼블리셔들이 많습니다. "어? 여기엔 space-between을 써야 하나? flex-grow를 줘야 하나?" 문법과 실전은 완전히 다른 영역이기 때문입니다. 현대 웹사이트의 컴포넌트들을 분석해 보면, 수천 가지의 화려한 UI도 결국 Flexbox를 이용한 5~6가지의 전형적인 레이아웃 패턴의 반복에 불과하다는 것을 깨닫게 됩니다. 이번 13단계 포스팅에서는 글로벌 대기업 웹사이트부터 개인 블로그까지 빠짐없이 등장하는 실무 최다 빈출 Flexbox UI 패턴 5가지의 구현 원리와 코드를 상세히 알아보겠습니다. 이 패턴들만 외워두..
[CSS] Grid 이전 포스팅에서 우리는 레이아웃의 구원자 Flexbox에 대해 깊이 열광했습니다. Flexbox는 가로 한 줄(Row) 또는 세로 한 줄(Column)의 요소를 우아하게 정렬하는 데 있어 타의 추종을 불허하는 신적인 존재입니다. 하지만 완벽해 보이는 Flexbox에게도 뼈아픈 한계가 하나 존재합니다. 바로 '1차원(1-Dimensional) 선형 시스템'이라는 족쇄입니다. 갤러리 이미지들이나 복잡한 대시보드 화면처럼 가로와 세로가 동시에 정교하게 딱딱 맞아떨어지는 '바둑판(2차원 면)' 형태의 격자 레이아웃을 짜려고 하면, Flexbox는 갑자기 바보가 됩니다. 가로 한 줄을 맞추고 flex-wrap으로 아래로 떨구면, 떨어진 아랫줄 요소들의 너비가 윗줄 요소들과 미묘하게 틀어지며 오와 열이 박살 나기 ..
[CSS] Flexbox (2편: Item)(Grow, Shrink) 우리가 직전 10단계 포스팅에서 다루었던 것은 오직 '부모(Flex Container)'의 입장이었습니다. 부모가 display: flex를 선언하고, 자식들을 왼쪽으로 밀어붙일지(justify-content), 세로로 중앙에 줄을 세울지(align-items)라는 전체적인 '정렬과 방향'의 규칙을 통제하는 법을 배웠습니다. 하지만 실무 레이아웃은 그렇게 호락호락하지 않습니다. "왼쪽의 메뉴바는 무조건 250px로 크기를 고정하고, 오른쪽 본문 영역은 사용자의 모니터가 커지면 커지는 대로 남은 빈 공간을 쫙쫙 다 빨아들여서 넓어지게 해주세요!" 같은 디테일하고 이기적인 요구사항들이 쏟아집니다. 이때 필요한 것이 바로 '자식(Flex Item) 요소'들에게 개별적으로 부여하는 고무줄 속성들입니다. Flex..
[CSS] Flexbox 컨테이너 속성 Float와 Position으로 고통받던 프론트엔드 개발자들에게 한 줄기 빛처럼 강림한 기술, 바로 Flexbox(Flexible Box Layout)입니다. Flexbox는 그 이름처럼 상자들의 크기를 뷰포트나 내용물에 맞게 아주 '유연하게' 늘이거나 줄이며 배치할 수 있도록 설계된 현대적인 1차원(가로 혹은 세로) 레이아웃 모델입니다. display: flex; 단 한 줄을 선언하는 순간, 부모 요소는 전지전능한 지휘자(Container)가 되어 자식 요소들(Items)의 방향, 정렬, 간격을 마음대로 주무를 수 있게 됩니다. 가운데 정렬을 하기 위해 margin: auto를 주며 씨름하던 과거는 잊으십시오. 이번 포스팅에서는 Flexbox의 양대 산맥 중 부모 요소에 적용하는 '컨테이너(Contai..
[CSS] Flexbox (1편: Container) 과거 웹 개발자들은 화면에 박스 3개를 나란히 가로로 배치하기 위해 피눈물을 흘렸습니다. float: left를 썼다가 부모의 높이가 찌그러지는 버그(Height Collapse)를 막기 위해 clearfix라는 흑마법 코드를 덧붙여야 했고, 수직 중앙 정렬(Vertical Center)을 맞추기 위해 line-height와 margin 값을 픽셀 단위로 찍어 맞추는 노가다를 반복했습니다. 브라우저 창 크기가 변하는 스마트폰 시대가 도래하자, 이 구시대적 해킹 레이아웃은 여지없이 와르르 무너져 내렸습니다. 전 세계 개발자들의 절규를 들은 W3C는 마침내 2009년 초안을 거쳐, 오로지 '레이아웃 배치'만을 목적으로 창조된 완벽하고 우아한 구세주를 세상에 내놓았습니다. 그것이 바로 CSS Flexible ..
[CSS] Variables (사용자 지정 속성) 과거 웹 개발자들은 웹사이트 전체의 메인 컬러(예: 브랜드 컬러인 파란색 #1da1f2)를 적용하기 위해 수백 개의 CSS 클래스에 color: #1da1f2;를 복사해서 붙여넣었습니다.어느 날 기획자가 "브랜드 컬러를 약간 보라색 톤으로 바꿔주세요"라고 요청하면, 개발자는 프로젝트 전체를 뒤져가며 수백 개의 코드를 일일이 찾아 바꾸는(Find & Replace) 지옥 같은 막노동을 해야만 했습니다. 프로그래밍의 제1 원칙인 DRY(Don't Repeat Yourself, 중복 금지)가 완전히 박살 난 상태였죠. 이를 해결하기 위해 Sass(SCSS)나 Less 같은 CSS 전처리기(Preprocessor)들이 등장하여 변수 기능을 제공했지만, 이것들은 컴파일 단계에서 값이 고정되어 버리기 때문에 런타임..
[CSS] Float와 Clearfix 우리가 매일 사용하는 화려하고 반응성이 뛰어난 웹사이트들의 이면에는 10년이 넘는 프론트엔드 개발자들의 피 튀기는 사투가 숨어있습니다. 현대에는 display: flex나 display: grid 코드 단 한 줄이면 박스 수십 개를 아주 우아하고 아름답게 가로로 나란히 배치할 수 있습니다. 하지만 불과 몇 년 전까지만 해도, CSS에는 '요소들을 가로로 배치하기 위한 전용 레이아웃 속성'이라는 것 자체가 아예 존재하지 않았습니다. 개발자들은 멘붕에 빠졌습니다. "웹사이트의 좌측에는 메뉴바(GNB)를 놓고, 우측에는 본문을 2단으로 나란히 배치하고 싶은데 어떻게 해야 하지?" 결국 그들은 CSS의 본래 목적을 완전히 벗어난, 특정 속성의 버그성 동작을 악용하는 '해킹(Hack)' 기법을 십수 년간 표준처럼..
[CSS] Positioning 우리가 직전 06단계에서 배웠던 Block과 Inline의 법칙은 브라우저의 아주 정직한 '일반 흐름(Normal Flow)'을 따릅니다. 위에서부터 아래로, 왼쪽에서 오른쪽으로 차곡차곡 박스를 쌓아가는 방식이죠. 하지만 현대의 웹 디자인은 결코 정직하지 않습니다. 스크롤을 한참 내려도 상단에 끈질기게 달라붙어 있는 네비게이션 헤더(Header), 프로필 사진의 오른쪽 구석에 살짝 걸쳐서 깜빡이는 빨간색 알림(Badge) 동그라미, 그리고 화면 정중앙에 떡하니 나타나서 뒤의 내용들을 다 가려버리는 모달(Modal) 팝업창까지! 이 모든 화려한 UI들은 기존 요소들을 밀어내지 않고, 마치 포토샵의 '레이어(Layer)'처럼 공중에 붕 떠서 자신만의 3차원 Z축 공간을 확보합니다. 문서의 일반적인 흐름(중력..
[CSS] Display 우리가 HTML 문서에 박스 3개를 연달아 코딩하고 결과를 확인해 보면, 신기하게도 세 박스가 나란히 옆으로 붙지 않고 층층이 위아래로 쌓여 있는 모습을 보게 됩니다. 반대로 태그나 태그를 여러 개 쓰면, 이번에는 위아래로 쌓이지 않고 글씨처럼 좌우로 길게 나열됩니다. 대체 브라우저 안에서는 무슨 보이지 않는 룰(Rule)이 존재하길래 어떤 녀석은 줄 바꿈을 일으키고 어떤 녀석은 가로로 붙어 버리는 걸까요? 이 모든 마법 같은 배치를 결정짓는 절대적인 단 하나의 CSS 속성, 그것이 바로 'Display' 속성입니다. display 속성을 완벽하게 장악하지 못하면, 버튼에 패딩(Padding)을 주었는데 위아래로 겹쳐버린다거나, 폭(Width)을 지정했는데 아무런 반응이 없는 등 수많은 기괴한 버그..
[CSS] 타이포그래피(Typography) 인터넷에 존재하는 정보의 90% 이상은 '텍스트'로 이루어져 있습니다. 화려한 비디오와 이미지들이 시선을 끌 수는 있지만, 결국 사용자가 그 웹사이트에 머무르며 정보를 습득하고 구매 버튼을 누르게 만드는 최종적인 설득의 매개체는 잘 정돈된 글씨(Typography)입니다. 종이 출판물 시대부터 이어져 온 타이포그래피의 엄격한 규칙들은 웹으로 넘어오면서 모니터 픽셀과 브라우저 렌더링이라는 새로운 변수를 만나 더욱 고도화되었습니다. 주니어 프론트엔드 개발자들이 흔히 font-size나 대충 키우고 font-weight를 굵게 만드는 것으로 글꼴 디자인을 끝냈다고 착각하지만, 진짜 전문가들은 줄 간격(Line Height)의 미세한 황금비율을 계산하고, 외부 웹 폰트가 로딩될 때 발생하는 끔찍한 '깜빡임 현상..
[CSS] Color & Background 웹사이트에 처음 접속한 사용자가 이 사이트가 트렌디한지, 신뢰할 만한지, 아니면 10년 전에 만들어진 낡은 사이트인지 판별하는 데 걸리는 시간은 0.05초(50 밀리초)에 불과하다고 합니다. 텍스트를 읽기도 전에 우리의 뇌는 화면의 '색상(Color)'과 '배경(Background)'이 뿜어내는 분위기를 본능적으로 스캔하여 결론을 내려버립니다. 프론트엔드 개발자가 레이아웃과 단위를 아무리 기가 막히게 짜놓아도, 버튼 색상이 촌스러운 순수 빨간색(red)이거나 배경 이미지가 찌그러져 있다면 그 프로젝트는 처참하게 실패한 것입니다. 웹에서의 색상은 단순한 미적 장식이 아닙니다. 클릭을 유도하는 심리적 넛지(Nudge)이자, 다크 모드를 전환하는 아키텍처의 핵심 데이터입니다. 이번 04단계 포스팅에서는 컴퓨터..
[CSS] 단위(Units) 완벽 가이드 웹 디자인을 시작할 때 우리가 가장 먼저 집어 드는 무기는 픽셀(px)입니다. width: 300px;, font-size: 16px; 등 직관적이고 절대적인 수치를 제공하는 px은 포토샵이나 일러스트레이터 같은 고전적인 그래픽 툴에 익숙한 디자이너와 개발자들에게 엄청난 안도감을 줍니다. 하지만 모던 웹 개발의 세계로 깊숙이 들어가는 순간, 이 '절대적인 고정 단위'는 반응형 웹(Responsive Web)과 웹 접근성(Accessibility)을 파괴하는 거대한 족쇄로 돌변합니다. 사용자가 손바닥만 한 아이폰으로 접속하든, 거대한 32인치 4K 모니터로 접속하든 똑같이 300px의 크기를 고집하는 요소는 필연적으로 화면 밖으로 잘리거나 현미경으로 봐야 할 만큼 작아지는 촌극을 빚어냅니다. 현대 프론트엔..
[CSS] Box Model - 브라우저가 세상을 바라보는 네모난 시선 웹 개발에 입문하여 CSS로 글씨 색깔도 바꿔보고 배경색도 칠해보다 보면, 문득 "이제 버튼들을 옆으로 나란히 배치해 볼까?" 또는 "이 사진과 텍스트 사이의 간격을 좀 띄워볼까?" 하는 시도를 하게 됩니다. 그리고 이때부터 끔찍한 절망이 시작됩니다. 분명히 간격을 10px 주었는데 옆으로 튕겨 나가고, 테두리를 그렸더니 레이아웃 전체가 아래로 와르르 무너져 내리는 기이한 현상들을 마주하게 됩니다. 구글에 검색해 가며 margin, padding 값을 이것저것 아무렇게나 때려 맞추다 보면 어찌어찌 화면은 예뻐지지만, 코드는 누더기가 되어버립니다. 왜 이런 일이 발생할까요? 그것은 바로 웹 브라우저가 HTML 요소들을 화면에 그릴 때 사용하는 절대적인 수학 공식, 'CSS 박스 모델(Box Model)'의..
[CSS] CSS의 탄생 배경과 HTML과의 완벽한 분리 웹 개발에 입문하는 거의 모든 사람들이 가장 먼저 접하는 기술은 HTML과 CSS입니다. 코딩 부트캠프나 온라인 강의에서는 보통 "HTML은 웹페이지의 뼈대를 만들고, CSS는 그 뼈대를 예쁘게 꾸미는 역할을 합니다"라고 간단명료하게 설명하고 넘어갑니다. 하지만, 깊이 있는 프론트엔드 개발자가 되기 위해서는 단순히 이 문장을 외우는 것을 넘어, "대체 왜 처음부터 HTML 자체에 디자인 기능을 빵빵하게 넣지 않고 굳이 CSS라는 완전히 다른 언어를 발명하여 분리해야만 했는가?"에 대한 역사적이고 구조적인 근본 이유를 이해해야 합니다. 이 분리의 철학을 이해하지 못하면, 실무에서 수천 줄의 코드가 얽히고설키는 유지보수 지옥을 마주하게 됩니다.오늘 포스팅에서는 초창기 웹의 혼란스러웠던 역사부터 CSS가 가져..
[Spring Boot] GraalVM Native Image: 자바의 한계를 찢고 0.05초 만에 부팅하라 현대 클라우드 생태계는 요금이 저렴하고 유연한 AWS Lambda 같은 서버리스(Serverless)나 쿠버네티스(K8s) 오토스케일링 환경으로 빠르게 넘어가고 있습니다. 이런 환경에서는 트래픽이 몰릴 때 서버(컨테이너)가 1초 만에 수십 대씩 팟! 팟! 하고 순식간에 떠야 합니다. 그런데 여기서 자바(Java) 진영에 치명적인 위기가 찾아옵니다. 자바는 .jar를 실행하면 무겁고 거대한 JVM(자바 가상머신)을 먼저 띄운 뒤, 그 위에서 바이트코드를 통역(JIT)하며 스프링의 수많은 빈(Bean)들을 메모리에 올리느라 서버 부팅에만 최소 5초~15초가 걸립니다. Go나 Node.js가 0.1초 만에 켜지는 것에 비하면 너무나 뚱뚱하고 둔한 것이죠. "이제 클라우드 시대에 자바는 끝났다"는 조롱이 쏟아지..
[Spring Boot] Spring WebFlux: 한계 돌파, 비동기 논블로킹(Non-Blocking)의 기적 JMeter로 1만 명의 부하 테스트를 때리다 보면, 평범한 Spring MVC(톰캣 기반) 서버가 어느 순간 맥없이 무너지는 것을 보게 됩니다. 이유가 뭘까요? 기존 방식은 '1 요청 = 1 쓰레드(Thread)'라는 치명적인 룰을 가집니다. 유저가 API를 호출하면 쓰레드 하나가 배정되고, 그 쓰레드는 데이터베이스에서 쿼리 결과를 가져오는 2초 동안 '대기(Blocking)' 상태에 빠집니다. 아무 일도 안 하면서 쓰레드를 꽉 쥐고 있는 거죠. 이렇게 200명의 유저가 동시에 접속해 쓰레드 200개가 전부 DB 응답을 기다리며 멈춰버리면, 201번째 유저부터는 하얀 화면만 보며 에러를 뱉게 됩니다(Thread Pool 고갈). "아니, DB 기다리는 동안 쓰레드가 놀지 말고, 돌아가서 다른 유저 요청..
[Spring Boot] JMeter 부하 테스트: 트래픽 폭탄을 쏘고 병목을 부숴라 여러분이 만든 수강신청 시스템이 내일 아침 9시에 오픈합니다. 개발자 본인이 로컬 환경에서 포스트맨(Postman)으로 /api/enroll API를 한 번 클릭했을 때는 응답 속도가 0.1초(100ms)로 완벽했습니다. 하지만 다음 날 아침 9시, 1만 명의 학생이 동시에 접속(새로고침 연타)을 시작하자마자 서버는 "Connection Timeout"을 뱉으며 장렬히 전사했습니다. 1만 개의 트래픽이 쏟아질 때 DB 커넥션 풀(HikariCP)이 버티는지, CPU가 몇 퍼센트까지 치솟는지, 톰캣(Tomcat)의 기본 쓰레드 200개가 부족하진 않은지 미리 검증하지 않은 대가입니다. 오픈 당일 사직서를 쓰고 싶지 않다면, "실제 유저 1만 명이 접속하는 것과 똑같은 환경을 시뮬레이션해서 가짜 트래픽 폭탄..
[Spring Boot] 힙 덤프(Heap Dump) 분석: 메모리 누수(OOM)의 범인을 체포하라 자바(Java)의 가장 큰 장점 중 하나는 개발자가 메모리(RAM) 관리에 신경 쓰지 않아도 된다는 것입니다. 객체를 다 쓰고 나면 가비지 컬렉터(Garbage Collector, GC)라는 청소부가 돌아다니며 쓰레기를 싹 치워주기 때문이죠. 그런데 여러분이 만든 쇼핑몰 서버가 일주일만 지나면 서서히 메모리가 차오르더니 java.lang.OutOfMemoryError (OOM)을 뱉으며 장렬히 전사하는 현상이 발생했습니다. 청소부(GC)가 왜 쓰레기를 치우지 못했을까요? 개발자가 코드 어딘가에서 List나 Map 같은 저장소에 객체를 계속 쌓아두기만 하고 빼지 않으면(참조를 유지하면), GC는 "어? 이 객체는 아직 쓰고 있는 중요한 데이터인가 보네? 치우지 말아야지!" 하고 냅두게 됩니다. 이것이 바로..
[Spring Boot] Docker 컨테이너화: "내 로컬에선 되는데 서버에선 안돼요"를 끝내다 여러분이 윈도우(Windows) 노트북에서 Java 17을 설치하고 스프링 부트(Spring Boot) 서버를 완벽하게 개발했습니다. "완벽해! 이제 배포하자!"라며 리눅스(Linux) 운영 서버에 .jar 파일을 올리고 실행했는데, 갑자기 "Unsupported Class Version Error"가 뜨며 서버가 뻗어버립니다. 알고 보니 리눅스 서버에는 Java 11이 깔려있었던 것입니다. 부랴부랴 Java 17로 업데이트했더니 이번엔 파일 경로(Path) 문제로 이미지가 엑스박스가 뜹니다. 개발자의 로컬 환경, 테스트 서버 환경, 라이브 운영 서버 환경이 조금씩 달라서 생기는 이 지긋지긋한 '환경 불일치 문제'는 지난 수십 년간 수많은 개발자의 밤을 지새우게 만들었습니다. 이 고통을 완벽하게 끝내기 ..
[Spring Boot] 무중단 배포 전략: Nginx와 블루/그린(Blue/Green) 아키텍처 새벽 3시, 개발자가 버그를 고치고 새로운 스프링 부트(Spring Boot) 버전(V2)을 배포(Deploy)하기 위해 서버에 접속합니다. 기존에 돌고 있던 V1 서버 프로세스를 kill 명령어로 죽이고, 새로운 V2 .jar 파일을 java -jar 명령어로 기동 시킵니다. 스프링의 거대한 프레임워크가 톰캣(Tomcat)을 띄우고 메모리에 빈(Bean)들을 올리는 데 약 10~15초가 소요됩니다. 문제는 이 15초 동안 사이트에 들어온 사용자들은 끔찍한 "502 Bad Gateway" 또는 "연결할 수 없음" 에러 페이지를 마주하게 된다는 것입니다. (다운타임 발생) 과거에는 고객들이 잠든 새벽에 서버를 내리고 작업(점검 시간)하는 것이 당연했지만, 24시간 글로벌로 돌아가는 현대의 서비스(넷플릭스,..

티스토리툴바