감성 개발자

JWT vs 세션 인증, 15년차 백엔드 개발자가 실무에서 고르는 기준 (리프레시 토큰 설계 함정 3가지)

Lovizu — Sat, 10 Oct 2026 14:27:54 +0900

며칠 전 사내 신규 프로젝트 킥오프에서 인증 방식 얘기가 나왔다. 주니어 한 명이 "요즘 누가 세션 쓰나요, JWT 가야죠"라고 했고, 나는 잠깐 고민하다가 "이 프로젝트는 세션이 맞을 것 같은데"라고 답했다. 회의가 끝나고 그 친구가 따로 물어보러 왔다. 왜 JWT가 아니냐고. 그때 했던 얘기를 정리해서 글로 남긴다. 15년 넘게 백엔드를 하면서 JWT로 인증을 구현해 장애도 겪어봤고, 세션으로 돌아간 프로젝트도 있고, 결국 둘 다 쓰는 프로젝트도 있다. 이론은 간단한데 실무는 간단하지 않았다.

세션 인증과 JWT, 교과서 설명은 이렇다

복습부터 하자. 세션 인증은 로그인에 성공하면 서버가 세션 ID를 만들어 저장소(메모리, Redis, DB)에 보관하고, 브라우저에는 그 ID만 쿠키로 내려주는 방식이다. 요청이 올 때마다 서버가 저장소를 조회해서 "이 사람 로그인한 사람 맞네"를 확인한다. 상태가 서버에 있다. 그래서 스테이트풀(stateful)이라고 부른다.

JWT(JSON Web Token)는 반대다. 로그인에 성공하면 서버가 사용자 정보와 만료 시각을 담은 토큰을 서명해서 내려주고, 서버는 아무것도 저장하지 않는다. 요청이 오면 서명만 검증하면 끝이다. 상태가 클라이언트에 있다. 스테이트리스(stateless)다.

교과서적인 장단점 비교는 이렇다. 세션은 서버 저장소 조회가 매 요청마다 필요하니 확장에 불리하고, JWT는 서명 검증만 하면 되니 서버를 수평 확장해도 세션 공유 문제가 없다. 여기까지만 들으면 JWT가 무조건 이기는 게임처럼 보인다. 그 주니어도 여기까지 알고 있었다. 문제는 그다음부터다.

함정 1. JWT는 로그아웃이 안 된다

JWT의 가장 큰 강점인 "서버가 상태를 저장하지 않는다"는 말을 뒤집으면 "서버가 토큰을 무효화할 방법이 없다"가 된다. 사용자가 로그아웃 버튼을 눌러도, 이미 발급된 토큰은 만료 시각까지 유효하다. 클라이언트에서 토큰을 지우는 건 로그아웃처럼 보이게 하는 것뿐이고, 누군가 그 토큰을 복사해뒀다면 만료 전까지 계속 쓸 수 있다.

실제로 겪은 일이다. 몇 년 전 운영하던 서비스에서 퇴사자 계정을 정지시켰는데, 그 계정으로 발급된 토큰이 이틀짜리였다. 계정은 분명 정지 상태인데 API는 이틀 동안 멀쩡히 응답했다. 관리자 입장에서는 "차단했는데 왜 들어와?"가 된다. 보안 감사에서 이 부분을 지적받고 나서야 구조를 바꿨다.

해결책은 다들 안다. 블랙리스트를 만들면 된다. 로그아웃하거나 정지된 토큰을 Redis 같은 곳에 넣어두고, 매 요청마다 "이 토큰 블랙리스트에 있나?"를 확인하는 거다. 그런데 잠깐, 매 요청마다 저장소를 조회한다고? 그건 그냥 세션이다. 스테이트리스라는 JWT의 존재 이유가 사라진다. 이 모순이 JWT 인증 설계의 출발점이고, 그래서 나온 절충안이 "액세스 토큰은 짧게, 리프레시 토큰으로 갱신"하는 구조다.

함정 2. 리프레시 토큰, 어디에 저장할 것인가

액세스 토큰을 15분짜리로 짧게 만들면 탈취돼도 피해가 15분으로 제한된다. 대신 사용자가 15분마다 재로그인할 수는 없으니, 수명이 긴 리프레시 토큰으로 새 액세스 토큰을 받아온다. 여기까지는 좋다. 그런데 이 리프레시 토큰을 브라우저 어디에 둘 것인가. 이게 두 번째 함정이다.

localStorage에 두면 구현이 제일 쉽다. 자바스크립트로 꺼내서 헤더에 실으면 되니까. 문제는 XSS다. 외부 스크립트 하나, npm 패키지 하나가 오염되면 localStorage는 그대로 털린다. 수명이 2주짜리인 리프레시 토큰이 털리면 공격자는 2주 동안 그 사용자다.

httpOnly 쿠키에 두면 자바스크립트로 접근이 불가능하니 XSS로 토큰 자체를 훔치는 건 막는다. 대신 쿠키는 브라우저가 자동으로 실어 보내니 CSRF 걱정이 생긴다. 요즘은 SameSite=Lax가 기본값이라 과거보다 훨씬 낫지만, 크로스 도메인 API 호출이 필요한 구조(프론트는 app.example.com, API는 api.other.com 같은)에서는 SameSite=None을 써야 하고, 그러면 CSRF 토큰 같은 추가 방어가 다시 필요해진다.

내 결론은 수년째 같다. 리프레시 토큰은 httpOnly + Secure + SameSite 쿠키, 액세스 토큰은 메모리(자바스크립트 변수)에만. 액세스 토큰을 아예 localStorage에도 안 둔다. 새로고침하면 날아가지만, 그때는 쿠키에 있는 리프레시 토큰으로 조용히 한 번 갱신하면 된다. 사용자는 아무것도 못 느낀다. 완벽한 방어는 아니지만(XSS가 뚫리면 공격자가 갱신 요청 자체를 흉내 낼 수 있다), 토큰 원본이 통째로 유출되는 것과는 피해 범위가 다르다.

함정 3. 동시 요청과 리프레시 레이스 컨디션

이건 운영에서 실제로 터져본 사람만 아는 문제다. 액세스 토큰이 만료된 시점에 프론트가 API를 동시에 서너 개 쏘면, 전부 401을 받고 전부 각자 리프레시를 시도한다. 리프레시 토큰 로테이션(갱신할 때마다 리프레시 토큰도 새로 발급하고 이전 것은 폐기)을 적용해둔 상태라면, 첫 번째 갱신 요청이 성공하는 순간 나머지 요청들이 들고 있던 리프레시 토큰은 이미 폐기된 토큰이 된다. 결과는 영문 모를 강제 로그아웃. 사용자 입장에서는 "쓰다가 갑자기 튕겼어요"가 되고, 로그를 봐도 재현이 안 되니 한참 헤매게 된다.

우리도 이 문제로 CS가 간헐적으로 들어왔는데, 원인을 잡는 데 꽤 걸렸다. 해결은 두 갈래로 했다. 프론트에서는 리프레시 요청을 싱글턴으로 만들었다. 갱신이 진행 중이면 뒤에 오는 요청들은 새로 갱신을 시도하지 않고 그 Promise를 같이 기다렸다가, 새 토큰으로 재시도한다. 서버에서는 직전 리프레시 토큰에 수 초 정도의 유예(grace period)를 둬서, 로테이션 직후 아슬아슬하게 도착한 요청까지는 받아줬다. 이 두 개를 넣고 나서야 유령 로그아웃이 사라졌다.

로테이션 얘기가 나온 김에 하나 더. 로테이션을 하는 진짜 이유는 재사용 감지다. 이미 폐기된 리프레시 토큰으로 갱신 요청이 들어온다는 건 둘 중 하나다. 방금 말한 레이스 컨디션이거나, 누군가 토큰을 훔쳐서 쓰고 있거나. 유예 시간을 지난 재사용이 감지되면 그 사용자의 토큰 패밀리 전체를 폐기하고 재로그인을 요구하는 게 정석이다. 이게 돌고 있어야 리프레시 토큰 탈취에 대한 최소한의 안전망이 생긴다.

그래서 결국 세션은 뭐가 되는가

여기까지 하고 나면 묘한 기분이 든다. 짧은 액세스 토큰, 서버에 저장되는 리프레시 토큰, 로테이션, 재사용 감지, 블랙리스트까지. 서버가 저장하고 관리하는 게 한둘이 아니다. 스테이트리스라서 선택한 JWT인데, 제대로 만들수록 점점 스테이트풀이 되어간다. 반면 세션은 어떤가. Redis에 세션 넣고 쿠키 하나 내려주면 로그아웃 즉시 반영, 강제 만료 즉시 반영, 기기별 세션 관리까지 전부 공짜로 따라온다. Spring Session이든 Laravel이든 express-session이든 프레임워크가 다 해준다.

"세션은 확장이 안 된다"는 말도 이제는 반쯤 옛날 얘기다. 그 말이 나왔던 시절은 세션을 서버 메모리에 들고 있어서 로드밸런서에 스티키 세션을 걸어야 했던 때다. 지금은 Redis 하나 띄우면 서버 10대가 세션을 공유한다. Redis 조회는 1ms 안쪽이다. 물론 매 요청마다 네트워크 왕복이 하나 추가되는 건 사실이고, 초당 수십만 요청을 받는 규모라면 이것도 부담이 된다. 하지만 국내 서비스 대부분은 그 규모가 아니다. 우리 회사도 아니다.

내가 실무에서 고르는 기준

그래서 요즘 나는 이렇게 가른다.

세션을 고르는 경우. 프론트와 백엔드가 같은 도메인(서브도메인 포함)에 있고, 웹 브라우저가 주 클라이언트인 서비스. 사내 어드민, 모놀리식 웹 서비스, 전형적인 B2B SaaS가 여기 해당한다. 이런 데서 JWT를 고르면 위에서 말한 함정들을 전부 직접 구현해서 통과해야 하는데, 얻는 건 거의 없다. 킥오프에서 세션을 밀었던 그 프로젝트도 어드민 성격의 웹 서비스였다.

JWT(또는 토큰 기반)를 고르는 경우. 모바일 앱이 주 클라이언트일 때(앱에는 쿠키 개념이 어색하다), 서드파티에게 API를 열어줄 때, 마이크로서비스 사이에서 서비스 간 인증이 필요할 때, 그리고 인증 서버와 자원 서버가 조직적으로 분리되어 있을 때다. 특히 MSA에서 게이트웨이가 토큰을 한 번 검증하고 내부 서비스들은 서명만 믿고 가는 구조는 JWT가 아니면 만들기 어렵다.

그리고 현실적인 세 번째 선택지. 직접 만들지 않는 것. Keycloak 같은 셀프호스팅 솔루션이든 Auth0, Cognito, Firebase Auth 같은 매니지드 서비스든, 인증을 통째로 위임하는 선택지가 요즘은 꽤 성숙했다. 위에서 말한 로테이션, 재사용 감지, 토큰 폐기 같은 걸 전부 알아서 해준다. 인증은 틀리면 보안 사고로 직결되는 영역이라, 작은 팀일수록 오히려 기성품을 쓰는 게 맞다고 본다. 나도 사이드 프로젝트에서는 직접 구현 안 한 지 오래됐다.

설계 체크리스트로 정리

글이 길어졌으니 실무 체크리스트로 요약한다. JWT 기반으로 간다면 최소한 이건 확인하자.

액세스 토큰 수명은 짧게(5~15분). 피해 반경을 시간으로 제한하는 게 1원칙.
리프레시 토큰은 httpOnly + Secure + SameSite 쿠키로. localStorage에 두지 않는다.
액세스 토큰은 메모리에만 보관, 새로고침 시 리프레시로 복구.
리프레시 토큰 로테이션 + 재사용 감지(패밀리 전체 폐기)를 구현한다.
동시 요청 레이스 컨디션 대비: 프론트 리프레시 싱글턴 + 서버 유예 시간.
JWT 페이로드에 민감 정보를 넣지 않는다. 서명이지 암호화가 아니다. 디코딩은 누구나 한다.
알고리즘은 서버가 강제한다. 헤더의 alg를 믿고 따라가면 안 된다(none 알고리즘 공격은 고전이지만 여전히 나온다).
계정 정지·비밀번호 변경 시 해당 사용자의 리프레시 토큰을 전부 폐기하는 경로를 처음부터 만든다.

세션으로 간다면 체크리스트가 훨씬 짧다. 세션 저장소를 Redis로 분리하고, 쿠키에 httpOnly/Secure/SameSite 걸고, 세션 고정(session fixation) 방지로 로그인 성공 시 세션 ID를 재발급하는 것. 프레임워크 기본 설정에서 크게 벗어날 일이 없다. 이 짧음 자체가 세션의 경쟁력이다.

마무리: 기술 선택은 유행이 아니라 제약 조건이다

그 주니어에게 마지막으로 해준 말은 이거였다. JWT가 나쁜 게 아니라, "왜 쓰는지 모르고 쓰는 것"이 나쁜 거라고. 세션이 구식인 게 아니라, 우리 제약 조건에서 가장 싸고 안전한 답인 경우가 생각보다 많은 것뿐이라고. 인증 방식은 이력서에 쓰는 기술 스택이 아니라 서비스의 현관문이다. 문은 화려할 필요가 없다. 잘 잠기고, 필요할 때 바로 잠글 수 있으면 된다.

다음에 기회가 되면 이 글에서 미뤄둔 주제, MSA 환경에서 게이트웨이 토큰 검증과 서비스 간 인증(mTLS vs 토큰 릴레이) 얘기를 따로 정리해볼 생각이다.

이미지 출처: Unsplash (키보드 위 자물쇠 © Towfiqu Barbhuiya, 자물쇠와 키보드 키 © FlyD, 자바스크립트 코드 화면 © Markus Spiske)

아이 셋 독감 예방접종, 10월 안에 끝내는 이유와 환절기 감기 덜 걸리는 우리 집 루틴

Lovizu — Thu, 8 Oct 2026 16:09:30 +0900

아침에 애들 등교시키려고 현관문을 여는데 공기가 달라졌다. 지난주까지만 해도 반팔로 버틸 만했는데, 이번 주부터는 얇은 패딩 조끼를 꺼냈다. 이맘때가 되면 우리 집에는 연례행사가 하나 있다. 독감 예방접종이다. 아이가 셋이면 접종도 이벤트다. 한 명씩 데려가면 세 번 왕복이고, 한 번에 데려가면 소아과 대기실에서 한 시간짜리 인내심 테스트가 열린다.

오늘은 올해 바뀐 어린이 독감 국가예방접종 내용부터, 아이 셋을 데리고 10월 안에 접종을 끝내는 우리 집 방식, 그리고 접종만으로는 다 못 막는 환절기 감기를 조금이라도 덜 달고 사는 생활 루틴까지 정리해 본다. 매년 하는 일인데도 매년 헷갈려서, 나 스스로 보려고 정리하는 글이기도 하다.

올해 어린이 독감 무료접종, 바뀐 것부터 확인

질병관리청 발표(2026년 8월 25일 보도자료) 기준으로 이번 2026-2027절기 인플루엔자 국가예방접종은 작년과 몇 가지가 달라졌다. 핵심만 추리면 이렇다.

지원 연령 확대: 어린이 무료접종 대상이 기존 생후 6개월~13세에서 생후 6개월~14세(중학교 2학년, 2012.1.1~2026.8.31 출생)까지 늘었다. 중학생 형님들도 올해부터는 무료다.
접종 기간: 2회 접종 대상 어린이와 임신부는 9월 21일부터, 1회 접종 대상 어린이는 9월 28일부터 시작해서 2027년 4월 30일까지 이어진다.
2회 접종 대상: 과거 접종력이 없거나 기존에 1회만 맞은 생후 6개월 이상 9세 미만 어린이는 4주 간격으로 두 번 맞는다. 첫째 때 이걸 몰라서 한 번만 맞히고 겨울을 났던 기억이 있다.
백신: 올해는 WHO 권장주가 모두 포함된 3가 백신으로 진행된다.
어디서 맞나: 주소지와 상관없이 전국 위탁의료기관(약 2만 3천 곳)과 보건소에서 무료다. 가까운 기관은 예방접종도우미 누리집에서 검색하면 된다.

참고로 65세 이상 어르신은 10월 12일 75세 이상부터 연령대별로 순차 시작이다. 조부모님 접종 일정 챙기는 집은 이것도 같이 봐두면 좋다. 우리 부모님도 올해는 코로나19 백신과 동시 접종을 권고받으셨다.

나는 왜 10월 안에 끝내려고 하나

접종 기간이 내년 4월까지인데 왜 서두르냐는 말을 들은 적이 있다. 몇 년 해보니 이유가 세 가지다.

첫째, 유행은 기다려주지 않는다. 독감은 보통 늦가을부터 겨울 사이에 유행하는데, 접종 후 항체가 생기는 데 대략 2주 정도 걸린다고 알려져 있다. 유행이 시작된 다음에 맞으면 그 공백기가 아깝다. 10월 안에 맞혀두면 본격적인 유행 전에 준비가 끝난다.

둘째, 소아과 대란을 피한다. 11월에 날이 확 추워지고 주변에서 독감 소식이 들리기 시작하면 소아과가 접종과 진료로 동시에 터져 나간다. 작년에 막내 2차 접종을 11월 중순으로 미뤘다가 토요일 오전 대기 40팀을 보고 그냥 돌아온 적이 있다. 10월 초중순은 상대적으로 한산하다.

셋째, 2회 접종 아이의 일정 계산. 4주 간격으로 두 번 맞아야 하는 아이가 있으면 역산이 필요하다. 10월 초에 1차를 맞아야 11월 초에 2차가 끝난다. 미루다 보면 2차가 12월로 밀리고, 그 사이에 유행이 먼저 온다.

독감과 감기는 다르다, 그래서 접종이 필요하다

애들 어릴 때는 나도 "독감 = 독한 감기" 정도로 생각했다. 둘째가 어린이집에서 인플루엔자 확진을 받아온 해에 확실히 배웠다. 감기는 콧물, 기침이 서서히 오는데 독감은 갑자기 고열이 치솟고 온몸을 아파했다. 아이는 사나흘을 앓았고, 등원 중지 기간 동안 아내와 내가 번갈아 연차를 썼다. 그 주에 셋째까지 열이 오르기 시작했을 때의 막막함은 지금도 생생하다.

감기는 원인 바이러스가 200종이 넘어서 백신 자체가 없다. 반면 독감(인플루엔자)은 유행할 바이러스주를 예측해서 매년 백신을 만든다. 그래서 "작년에 맞았는데 올해 또 맞아야 하나"라는 질문의 답은 "그렇다"이다. 유행주가 매년 바뀌고 백신 구성도 매년 달라지기 때문이다. 백신을 맞아도 독감에 걸릴 수는 있지만, 일반적으로 증상 완화와 합병증 예방에 도움이 된다고 안내된다. 아이 셋 중 둘이 같은 독감을 앓아도 접종한 아이가 눈에 띄게 수월하게 지나간 경험을 하고 나서는, 우리 집에서 독감 접종은 선택이 아니라 기본값이 됐다.

아이 셋 접종, 우리 집 실전 운영법

아이가 셋이면 접종도 운영의 영역이다. 시행착오 끝에 정착한 방식은 이렇다.

1. 셋을 한 번에, 평일 오후 또는 토요일 이른 오전으로 예약한다. 접종 때문에 세 번 병원에 가는 건 부모 연차가 남아나지 않는다. 요즘 소아과는 대부분 앱이나 전화로 접종 예약이 되니, 셋을 같은 시간대로 묶는다. 토요일이라면 문 여는 시간 직후가 제일 낫다.

2. 접종 전날 컨디션을 본다. 열이 있거나 상태가 안 좋으면 접종을 미루는 게 원칙이다. 애매하면 당일 의사 선생님 진찰 때 물어보면 된다. 괜히 부모가 미리 단정하지 말고, 데려가서 판단을 맡기는 게 속 편하다.

3. 순서는 막내부터. 큰애들은 기다릴 줄 알지만 막내는 형 누나가 주사 맞고 우는 걸 보면 전염된다. 막내 먼저 끝내고 형들이 맞는 동안 간식으로 달래는 게 우리 집 공식이다.

4. 접종 후에는 일정을 비운다. 접종 당일은 격한 활동 없이 지켜보라는 안내를 매번 받는다. 접종 부위가 붓거나 미열이 있을 수 있는데, 상태가 평소와 다르다 싶으면 접종받은 병원에 문의하거나 진료를 받는 게 맞다. 우리는 접종 날 저녁 태권도를 빼는 걸로 정리했다.

5. 주사 무서워하는 아이는 "예고제"로. 우리 둘째는 주사 공포가 심한 편이었다. 당일에 기습적으로 데려가는 건 한 번은 통해도 다음 해부터 병원 근처만 가도 운다. 지금은 이틀 전에 미리 말해주고, 무엇을 왜 맞는지 설명하고, 끝나면 뭘 할지(둘째 픽은 늘 편의점 슬러시)를 같이 정한다. 예고하고 보상을 약속하는 쪽이 장기전에서는 훨씬 낫다. 접종 순간에는 "아프지 않아"라고 거짓말하지 않는 것도 중요하다. "따끔하고 금방 끝나"가 정확하고, 아이도 그 말은 믿어준다.

6. 부모도 같이 맞는다. 아이들만 맞히고 부모가 안 맞으면 구멍이 남는다. 애들 국가접종은 무료지만 성인은 유료라서 아까운 마음이 들 수 있는데, 간병 휴가와 비교하면 싼 보험이다. 나는 회사 근처 내과에서, 아내는 애들 접종하는 날 같은 병원에서 함께 맞는다.

접종이 다는 아니다, 환절기 감기 줄이는 우리 집 루틴

독감 백신은 독감을 대비하는 수단이지 모든 감기를 막아주는 게 아니다. 환절기 콧물 감기는 결국 생활 습관 싸움이다. 질병관리청과 식약처가 안내하는 수칙에 우리 집 현실을 얹으면 이렇게 된다.

1. 귀가 직후 손씻기 30초. 뻔한 얘기지만 제일 효과를 체감한 항목이다. 흐르는 물에 비누로 30초. 아이들은 "30초"가 감이 없어서 좋아하는 노래 한 소절을 부르면서 씻게 했다. 현관에서 바로 화장실로 직행하는 동선을 만들어 두니 잔소리가 줄었다.

2. 습도 50~60%. 공기가 건조해지면 호흡기 점막이 말라서 바이러스에 뚫리기 쉬워진다는 게 공통된 안내다. 우리 집은 10월부터 가습기를 꺼내고, 가습기가 없는 방에는 젖은 수건을 건다. 가습기는 매일 물을 갈고 주기적으로 세척하는 게 번거롭지만, 이건 타협하면 안 되는 부분이다.

3. 실내 온도 20~22도, 환기는 하루 세 번. 춥다고 꽁꽁 닫아두면 실내 공기가 더 나빠진다. 식약처 안내 기준 적정 실내 온도는 20~22도. 환기는 하루 세 번, 10분씩이라도 창문을 연다. 아침 등교 준비 전, 저녁 먹기 전, 자기 전으로 시간을 박아두면 까먹지 않는다.

4. 미지근한 물 자주 마시기. 애들은 목이 마르기 전까지 물을 안 마신다. 식탁과 거실에 물병을 상시 배치하고, 등교 가방에도 물통을 넣는다. 차가운 물보다는 미지근한 물이 낫다는 안내가 많아서 정수기 온수를 섞어 준다.

5. 수면 시간 사수. 잠이 부족하면 면역이 떨어진다는 건 어른 아이 공통이다. 환절기에는 애들 취침 시간을 평소보다 30분 당긴다. 사실 제일 안 지켜지는 항목인데, 그래서 제일 중요하다고 생각한다.

셋 중 하나가 걸렸을 때의 현실 대응

아이 셋 집에서 완벽한 격리는 없다. 한 방에서 자고 같은 식탁에서 먹는데 무슨 격리인가. 그래도 도미노를 늦추는 방법은 있다.

수건과 컵부터 분리한다. 평소에는 대충 섞여도, 누가 콧물을 시작하면 그날부터 수건 색을 나눈다.
아픈 아이 손씻기를 두 배로. 옮기는 쪽의 손이 제일 위험하다. 기침 예절(소매로 가리기)도 이때 다시 리마인드한다.
부모가 무너지지 않는다. 간병하다 부모가 같이 앓으면 집안 전체가 멈춘다. 아픈 아이 돌보는 사람을 한 명으로 정하고, 나머지 한 명은 남은 두 아이와 집안을 돌린다. 교대는 하루 단위로.
증상이 심하거나 길어지면 병원. 고열이 이어지거나 아이 상태가 평소와 다르면 미루지 말고 진료를 받는다. 인터넷 검색은 참고일 뿐, 판단은 의사에게 맡기는 게 맞다.

학교·어린이집 가정통신문, 흘려보내지 말 것

이맘때 학교와 어린이집에서 독감 접종 안내 가정통신문이 온다. 아이 셋이면 같은 내용이 세 장 오는데, 셋째 가방 바닥에서 2주 뒤에 발견되는 게 함정이다. 우리 집은 가정통신문을 현관 옆 자석 보드에 모으고, 접종·검진류는 바로 캘린더에 옮기는 걸로 정리했다. 특히 인플루엔자는 학교보건법상 등교 중지 대상 감염병이라, 확진되면 열 내린 뒤에도 일정 기간 등교를 못 한다. 맞벌이 집에서 이게 무슨 의미인지는 겪어본 사람만 안다. 아이 하나당 일주일 가까운 가정 보육이 생길 수 있다는 뜻이다. 접종으로 그 확률을 낮출 수 있다면 토요일 오전 한 번은 싸게 먹히는 셈이다.

참고로 독감이 유행하기 시작하면 지역 맘카페보다 질병관리청 감염병 포털의 인플루엔자 표본감시 자료가 정확하다. "독감 주의보 발령" 뉴스가 뜨면 이미 유행이 시작됐다는 신호이니, 그 전에 접종을 끝내는 게 이 글의 요지다.

10월 체크리스트로 정리

□ 아이별 접종 이력 확인 (2회 접종 대상인지 — 9세 미만 + 과거 접종력 확인)
□ 예방접종도우미 누리집에서 가까운 위탁의료기관 확인
□ 셋 묶어서 접종 예약 (평일 오후 or 토요일 오전)
□ 2회 접종 아이는 4주 뒤 2차 일정까지 미리 캘린더에 등록
□ 부모 접종 일정 잡기
□ 가습기 꺼내서 세척, 방마다 습도 점검
□ 환기 시간 3개 정하기 (아침/저녁/자기 전)
□ 아이들 물통·물병 배치, 취침 시간 30분 당기기

독감 접종은 매년 하는 일인데도 매년 새로 찾아보게 된다. 올해는 14세까지 무료가 확대됐으니 중학생 자녀가 있는 집은 특히 챙길 만하다. 이 글은 아이 셋 키우는 아빠의 경험담이자 일반적인 정보 정리일 뿐이니, 아이의 접종 여부나 건강 상태에 대한 구체적인 판단은 반드시 소아청소년과 전문의와 상담하시길 바란다. 올겨울은 다 같이 덜 아프고 지나가면 좋겠다.

참고 자료: 질병관리청 보도자료 '올겨울 인플루엔자 국가예방접종, 14세까지 확대해 9월 21일부터 순차 시행'(2026.8.25), 정책브리핑 '환절기, 감기 예방에 도움 되는 실천 요령'(식품의약품안전처), 국민건강보험 건강iN 매거진 '환절기 건강, 이렇게 챙기자'

이미지 출처: Unsplash — kazuend(@kazuend), Edgar Soto(@edgardo1987), zeliang xiao(@xiaozeliang)

AWS RDS 커넥션 고갈 장애 해결기: Too many connections 원인부터 RDS Proxy까지

Lovizu — Wed, 7 Oct 2026 20:39:56 +0900

금요일 저녁 8시였다. 애들 셋 씻기고 이제 좀 앉아볼까 하는데 폰이 울렸다. 슬랙 알람. "DB 연결이 안 됩니다." 운영 서버 로그를 열어보니 익숙하면서도 제일 보기 싫은 그 문구가 찍혀 있었다. SQLSTATE[HY000] [1040] Too many connections.

RDS를 몇 년 써봤다는 사람도 이 에러 앞에서는 한 번씩 당황한다. 나도 그랬다. 커넥션이 왜 고갈됐는지, 지금 당장 뭘 해야 서비스가 살아나는지, 그리고 다시는 안 터지게 하려면 뭘 고쳐야 하는지가 머릿속에서 한 번에 정리가 안 되기 때문이다. 이 글은 그날 밤 내가 했던 삽질과, 그 뒤에 정리해둔 대응 순서를 기록한 것이다. 같은 에러로 검색해서 들어온 분이라면 긴급 대응 섹션부터 보셔도 된다.

증상: Too many connections, 그런데 서버는 멀쩡해 보인다

이 장애의 고약한 점은 EC2도 멀쩡하고, RDS CPU도 20%대로 한가해 보인다는 거다. 모니터링 대시보드만 보면 아무 문제가 없다. 그런데 애플리케이션은 DB 커넥션을 못 맺어서 500을 뱉고 있다.

이유는 단순하다. MySQL(MariaDB도 동일)은 동시에 맺을 수 있는 커넥션 수에 상한이 있다. max_connections 파라미터다. 이 상한에 도달하면 새 커넥션 요청을 전부 거절한다. CPU나 메모리가 남아돌아도 소용없다. 문지기가 "정원 초과"라고 막아버리는 상황이다.

먼저 지금 상태를 확인한다. 다행히 운영자용 예약 커넥션 한 자리는 남겨두는 경우가 많아서, 관리 계정으로는 접속이 될 때가 있다.

-- 현재 커넥션 수
SHOW STATUS LIKE 'Threads_connected';

-- 설정된 상한
SHOW VARIABLES LIKE 'max_connections';

-- 역대 최대 동시 커넥션 (이게 max_connections에 붙어 있으면 확정)
SHOW STATUS LIKE 'Max_used_connections';

-- 누가 물고 있는지
SELECT user, host, db, command, time, state
FROM information_schema.processlist
ORDER BY time DESC;

그날 밤 우리 서버는 max_connections가 405였고 Threads_connected가 404였다. 깔끔한 만석이었다.

RDS의 max_connections 기본값은 생각보다 작다

여기서 많이들 놀란다. RDS MySQL의 max_connections 기본값은 고정 숫자가 아니라 인스턴스 메모리 기반 공식이다.

{DBInstanceClassMemory/12582880}

메모리를 12,582,880바이트(약 12MB)로 나눈 값이다. 인스턴스별로 대략 계산해보면 이렇다.

db.t3.micro (1GB) → 약 80~85개
db.t3.small (2GB) → 약 160~170개
db.t3.medium (4GB) → 약 320~340개
db.m5.large (8GB) → 약 640~680개

실제 값은 OS와 RDS 관리 프로세스가 쓰는 메모리를 빼고 계산되기 때문에 저 어림값보다 조금 작게 잡힌다. 중요한 건 "t3.small이면 커넥션 160개 남짓"이라는 감각이다. 이게 얼마나 작은 숫자인지는 다음 섹션에서 바로 체감된다.

원인 1: 커넥션 풀 산수를 안 해봤다

교과서는 이렇게 말한다. "커넥션 풀을 쓰면 커넥션을 재사용하므로 효율적입니다." 맞는 말이다. 그런데 실무에서 터지는 건 풀을 안 써서가 아니라, 풀 사이즈 곱셈을 안 해봐서다.

우리 구성이 딱 그랬다. 라라벨 API 서버가 오토스케일링 그룹에 들어 있었고, 평소엔 4대였다. 서버당 PHP-FPM 워커가 40개. PHP는 전통적으로 요청당 커넥션을 맺고 끊지만, 우리는 persistent connection을 켜둔 상태였다. 그러면 산수가 이렇게 된다.

서버 4대 × 워커 40개 = 커넥션 최대 160개  → t3.medium(약 330개)에서 여유 있음
트래픽 몰려서 8대로 스케일아웃 = 320개     → 턱밑
10대 = 400개                              → 폭발

그날 저녁 마케팅 푸시가 나갔고, 오토스케일링은 설계대로 성실하게 인스턴스를 10대까지 늘렸다. 앱 서버는 늘어나는데 DB 커넥션 상한은 그대로니까, 서버를 늘릴수록 장애가 심해지는 역설이 완성됐다. 오토스케일링의 최대 인스턴스 수 × 서버당 풀 사이즈가 max_connections를 넘는 순간, 그 구성은 시한폭탄이다. 스프링 부트의 HikariCP든, Node의 pg 풀이든, 장고의 CONN_MAX_AGE든 전부 같은 산수가 적용된다.

원인 2: Lambda가 끼어 있으면 곱셈이 더 가팔라진다

우리 사례는 아니지만, 요즘 이 에러의 단골 원인이 하나 더 있다. 서버리스다. Lambda는 동시 실행 하나당 실행 환경이 하나씩 뜨고, 각 환경이 DB 커넥션을 쥔다. 동시 실행 500이면 커넥션 500개다. 풀이고 뭐고 없이 상한을 뚫는다.

게다가 Lambda 실행 환경은 끝나도 바로 사라지지 않고 한동안 유지되면서(웜 상태) 커넥션을 물고 있는 경우가 많다. 트래픽 스파이크가 지나간 뒤에도 커넥션 수가 한참 높게 유지되는 그래프를 봤다면 십중팔구 이 패턴이다. Lambda에서 RDS를 직접 때리는 구조라면 뒤에 나올 RDS Proxy가 사실상 정답에 가깝다.

긴급 대응: 서비스부터 살리는 30분

원인 분석은 나중이고, 일단 살려야 한다. 그날 밤 기준으로 효과가 있었던 순서다.

1단계. 관리 계정으로 접속해서 오래 물고 있는 커넥션을 정리한다. processlist에서 Sleep 상태로 수백 초씩 누워 있는 커넥션이 보이면 끊어도 된다. RDS에서는 KILL 대신 전용 프로시저를 쓴다.

CALL mysql.rds_kill(프로세스ID);

한 건씩 죽이는 게 답답하면 processlist에서 kill 문을 생성해서 한꺼번에 돌리는 방법도 있다. 단, 어떤 커넥션인지 확인하고 죽이자. 배치 작업의 긴 트랜잭션을 끊으면 롤백으로 더 큰 불을 만들 수 있다.

2단계. 파라미터 그룹에서 max_connections를 임시로 올린다. RDS는 기본 파라미터 그룹을 수정할 수 없으니 커스텀 파라미터 그룹이 이미 붙어 있어야 한다. max_connections는 동적 파라미터라서 재부팅 없이 적용된다. 이게 되는 구성이면 5분 안에 숨통이 트인다. 다만 이건 진통제다. 메모리가 받쳐주지 않는데 상한만 올리면 이번엔 스왑과 OOM이 온다. 커넥션 하나가 버퍼 등으로 수 MB씩 먹을 수 있다는 걸 기억하고, 임시로 1.5배 정도까지만.

3단계. 커넥션을 뿜어내는 쪽을 잠근다. 우리는 오토스케일링 최대 대수를 일단 6대로 줄였다. Lambda가 원인이라면 해당 함수의 reserved concurrency를 낮추는 게 같은 역할을 한다. 유입을 줄이는 게 아니라 DB로 가는 수도꼭지를 잠그는 것이다.

이 세 개로 그날 밤은 넘겼다. 11시쯤 애들 재우러 들어갔으니 세 시간짜리 장애였다.

재발 방지 1: 풀 사이즈를 공식으로 정한다

다음 주에 제대로 정리했다. 핵심은 감으로 잡던 풀 사이즈를 공식으로 바꾼 것이다.

(서버 최대 대수 × 서버당 풀 최대치) + 배치/크론 + 관리자 접속 여유분
  ≤ max_connections × 0.8

0.8을 곱하는 이유는 페일오버나 점검 때 쓸 여유, 그리고 예상 못 한 접속(사람 손, 모니터링 도구)의 몫이다. 거꾸로 말하면 풀 최대치는 이렇게 역산한다.

서버당 풀 최대치 = (max_connections × 0.8 − 배치 − 여유분) ÷ 서버 최대 대수

여기서 "서버 대수"는 평소 대수가 아니라 오토스케일링 최대 대수다. 이걸 평소 대수로 계산해두는 바람에 터지는 집이 많다. 우리도 그랬고.

그리고 풀 사이즈는 크다고 좋은 게 아니다. DB가 실제로 동시에 일할 수 있는 쿼리 수는 vCPU 수에 수렴한다. 풀을 수백 개로 잡아봐야 대부분 줄만 서 있고, 컨텍스트 스위칭 비용으로 오히려 느려진다. HikariCP 문서가 제안하는 (코어 수 × 2) + 디스크 수 같은 작은 값에서 시작해서 부하 테스트로 늘려가는 쪽이 맞다. 이론은 "풀은 여유 있게"지만, 실제로는 "풀은 생각보다 작게"가 정답인 경우가 훨씬 많았다.

재발 방지 2: wait_timeout과 유휴 커넥션 정리

processlist에서 봤던 수백 초짜리 Sleep 커넥션들, 그게 자리만 차지하는 유령 손님이다. 앱이 커넥션을 닫지 않고 종료됐거나, persistent connection이 회수되지 않고 쌓인 결과다. 두 군데서 잡는다.

DB 쪽: wait_timeout(기본 28800초 = 8시간)을 내린다. 우리는 300초로 잡았다. 8시간은 유령 손님에게 자리를 8시간 보장해주는 설정이다.
앱 쪽: 풀의 idle timeout을 DB의 wait_timeout보다 짧게 잡는다. 반대로 하면 DB가 먼저 끊은 죽은 커넥션을 앱이 쓰려다 "MySQL server has gone away"를 만난다. 이 에러로 검색해서 온 분이라면 범인은 이 순서 역전이다.

재발 방지 3: RDS Proxy, 쓸 만한가

Lambda 얘기가 나왔으니 RDS Proxy도 짚고 가자. 앱과 RDS 사이에 끼어서 커넥션 풀을 대신 관리해주는 관리형 프록시다. 수천 개의 앱 커넥션을 받아서 DB에는 소수의 커넥션으로 다중화(multiplexing)해준다. 페일오버 시간도 단축된다.

직접 붙여본 소감은 이렇다. Lambda처럼 커넥션 수가 예측 불가능하게 튀는 구조에서는 투자 대비 효과가 확실하다. 반면 서버 대수가 뻔하고 풀 산수가 되는 일반 EC2/ECS 구성에서는 비용(vCPU당 과금)이 아깝게 느껴질 수 있다. 우리는 Lambda 기반 신규 서비스에만 붙이고, 기존 API 서버는 풀 설정 정리로 끝냈다. 전부 붙이는 게 아니라 커넥션 패턴이 난폭한 워크로드에만 선별 투입하는 게 합리적이라고 본다.

재발 방지 4: 터지기 전에 알람이 오게

마지막 조각은 모니터링이다. 이 장애는 예고가 길다. 커넥션 수는 보통 몇 주에 걸쳐 슬금슬금 오르다가 어느 날 상한을 친다. 그래프만 보고 있었어도 2주 전에 알 수 있었다.

CloudWatch의 DatabaseConnections 지표에 알람을 건다. 기준은 max_connections의 80%. 우리는 t3.medium 기준 260에 걸어뒀다.
Performance Insights를 켠다(프리 티어로 7일 보존은 무료). 커넥션을 누가 만드는지, 어떤 쿼리가 오래 무는지가 바로 보인다.
배포 체크리스트에 "오토스케일링 최대 대수 바꾸면 풀 산수 다시" 한 줄을 넣었다. 제일 원시적인데 제일 효과 있었다.

정리: 그날 밤 이후 바뀐 것

순서대로 요약하면 이렇다.

장애 중이면: processlist 확인 → 유휴 커넥션 kill → 동적 파라미터로 max_connections 임시 증설 → 커넥션 발생원(오토스케일링/Lambda 동시성) 조이기
풀 사이즈는 오토스케일링 최대 대수 기준으로 역산, 전체 합이 max_connections의 80% 이하
wait_timeout은 내리고, 앱 풀의 idle timeout은 그보다 더 짧게
Lambda가 DB를 직접 때리면 RDS Proxy 검토
DatabaseConnections 80% 알람은 지금 바로 걸 것

Too many connections는 사실 DB 장애가 아니다. 용량 계획 장애다. 인스턴스를 키우는 건 상한을 미루는 것일 뿐이고, 산수를 해놓지 않으면 더 큰 인스턴스에서 더 크게 터진다. 금요일 저녁의 세 시간을 수업료로 내고 배운 결론이다. 이 글이 누군가의 금요일 저녁을 지켜주면 좋겠다.

이미지 출처: Unsplash — Kevin Ache(@kevinache), Taylor Vick(@tvick), Luke Chesser(@lukechesser)

지난주 테크 뉴스 핵심 정리: 제미나이 4 아르곤, GPT-6.1 솔, 브로드컴 420억 달러 대출

Lovizu — Mon, 5 Oct 2026 11:07:29 +0900

지난주에 "다음 주는 OpenAI 데브데이"라고 예고를 했었는데, 뚜껑을 열어보니 데브데이는 오히려 조연이었다. 이번 주 주인공은 구글이었다. 조용하던 구글이 9월 30일 제미나이 4 아르곤을 꺼내 들면서 프론티어 모델 경쟁이 다시 한 바퀴 돌았고, 앤스로픽 IPO 서류에서는 입이 벌어지는 숫자가 나왔다. 아이 셋 재우고 밤에 뉴스 정리하면서 "이 판은 이제 모델 싸움이 아니라 돈 싸움이구나" 싶었던 한 주였다. 9월 28일부터 10월 4일까지, 지난주 테크 뉴스를 정리한다.

구글 제미나이 4 아르곤 공개, 그런데 일반 사용자는 아직 못 쓴다

9월 30일 구글이 새 프론티어 모델 제미나이 4 아르곤(Gemini 4 Argon)을 공개했다. 작년 11월 제미나이 3 이후 최상위 모델 공백이 길었던 구글의 반격이다. 구글 발표 기준으로 실제 장기 소프트웨어 엔지니어링 작업을 평가하는 DeepSWE v1.1에서 77.9%로 최고 기록을 세웠고, 보안 취약점 수정 능력을 보는 CWE-bench v1에서 68%로 공동 1위, 기업 업무 자동화를 보는 재피어 AutomationBench에서도 51.3%로 1위에 올랐다.

개발자 입장에서 눈에 들어온 건 두 가지다. 첫째, 출력 토큰 한도를 기존 6만 4천 개에서 100만 개로 늘렸다. 입력 컨텍스트가 아니라 출력이 100만 토큰이다. 긴 추론과 대규모 코드 생성을 한 번의 실행으로 끝내겠다는 설계다. 둘째, 구글 내부에서 이미 아르곤 에이전트가 C/C++ 코드베이스를 러스트로 이식하는 작업을 하고 있다는 대목이다. libgav1 비디오 디코더의 SIMD 코드 3만 2천 줄을 안전한 러스트 코드로 대체하면서 기존 러스트 포팅 대비 2.7배 빠르게 만들었다고 한다. 이 정도면 "AI가 코드 마이그레이션을 돕는다" 수준이 아니라 마이그레이션 주체가 AI다.

단, 함정이 하나 있다. 아르곤은 지금 일반 공개가 아니다. 페어윈드 프로그램이라는 경로로 신뢰된 사이버 보안 조직에 먼저 풀고, 미국 정부의 사전 접근 절차를 거친 뒤 단계적으로 확대한다. IT조선 보도(9월 30일)도 "일반 출시 시점은 명시되지 않았다"고 짚었다. 가격은 입력 100만 토큰당 2달러, 출력 10달러로 공개됐는데, 써보지도 못하는 모델의 가격표만 먼저 구경하는 상황이다. 최상위 모델을 보안 전문가에게 먼저 주고 가드레일을 다듬은 뒤 공개하는 흐름은 이제 업계 표준이 되는 분위기다.

OpenAI 데브데이: GPT-6.1 솔, 그리고 'dots'

9월 29일 OpenAI 데브데이가 있었다. 주력 발표는 GPT-6.1 솔(Sol). 지난주에 다뤘던 GPT-6 솔이 나온 지 딱 일주일 만에 .1 버전이 나왔다. Plus, Pro, Business 플랜에서 바로 쓸 수 있고 API 가격은 입력 100만 토큰당 2달러, 출력 10달러다. 공교롭게도 아르곤과 가격이 완전히 같다. 프론티어급 모델 가격이 2/10 선으로 수렴하는 모양새인데, 작년 이맘때를 생각하면 믿기지 않는 가격이다.

코덱스(Codex)에서는 토큰 생성 속도를 최대 8배 끌어올린 '울트라패스트' 모드도 예고됐다. 에이전트 코딩 도구는 결국 대기 시간 싸움이라, 체감 생산성에는 벤치마크 점수보다 이게 더 클 수 있다. 같은 날 'dots'라는 신규 제품도 공개됐다. 모델 번호 경쟁이 주춤한 대신 제품과 속도로 승부를 보려는 인상이었다.

개인적으로는 일주일 단위로 쏟아지는 버전 업이 반갑지만은 않다. 회사 프로젝트에 모델 버전을 고정해 두는 입장에서는 평가-교체 주기가 릴리즈 주기를 못 따라간다. 이제는 "최신 모델 추적"이 아니라 "우리 워크로드에서 언제 갈아탈지"를 정하는 운영 정책이 필요한 시점이다.

클로드 코드에 '모드(Mods)' 도입, 도구를 안에서 뜯어고친다

10월 1일 앤스로픽이 클로드 코드에 모드(mods) 기능을 넣었다. 타입스크립트 몇 줄로 클로드 코드의 동작 자체를 바꾸는 플러그인이다. 모델에 보내기 전 프롬프트를 고쳐 쓰고, 툴 호출을 가로채서 막거나 재시도하고, 민감 정보를 지우고, 터미널 UI에 패널이나 버튼을 추가할 수 있다. 설치는 /plugin 명령으로 하고, 핫 리로드가 되니 세션 안에서 바로 적용된다. 기본 기능이던 /diff도 이번에 모드로 분리돼서 끄거나 교체할 수 있게 됐다.

이게 왜 중요하냐면, AI 코딩 도구의 경쟁 축이 "모델이 얼마나 똑똑한가"에서 "도구를 얼마나 내 워크플로우에 맞게 깎을 수 있는가"로 넘어가고 있다는 신호라서다. 에디터로 치면 VS Code가 확장 생태계로 이긴 것과 같은 그림이다. 사내 보안 정책상 특정 명령 실행을 막아야 한다거나, 회사 티켓 시스템을 툴 호출에 끼워 넣고 싶다거나 하는 요구를 이제 포크 없이 모드로 해결할 수 있다. 클로드한테 "이런 모드 만들어줘"라고 시키면 자기가 자기 모드를 짜는 것도 가능하다. 주말에 하나 만들어볼 생각이다.

브로드컴, 앤스로픽에 최대 420억 달러 대출. 순환 지출 논쟁 재점화

10월 1일 로이터가 앤스로픽 상장 투자설명서를 인용해 보도한 내용이다. 브로드컴이 앤스로픽에 최대 420억 달러(약 57조 원)를 빌려준다. 앤스로픽이 5년간 약정한 TPU 연산 용량 리스 1,252억 달러의 약 3분의 1을 이 전환사채로 충당하는 구조다. 앤스로픽은 내년 브로드컴 칩 설계 부문의 최대 고객이 될 전망이고, 브로드컴은 이를 바탕으로 2027 회계연도 AI 반도체 매출 약 1,150억 달러를 내다본다.

칩 회사가 고객에게 돈을 빌려주고, 그 돈으로 고객이 자기 칩을 빌려 쓰는 구조. 엔비디아가 먼저 보여준 '칩 금융' 전략을 브로드컴이 따라가는 셈이다. 월가에서는 당연히 상호 지출(circular spending) 우려가 나온다. 로스차일드 쪽에서는 "이 모든 금융을 뒷받침할 매출을 두 회사가 만들 수 있는지에 베팅이 집중돼 있다"는 코멘트가 나왔고, 앤스로픽 스스로도 투자설명서에 브로드컴이 공급자 겸 전주(錢主)가 되는 데 따른 "잠재적 이해 상충" 리스크를 고지했다.

솔직히 나는 이 뉴스가 이번 주에서 제일 중요하다고 본다. 모델 벤치마크는 분기마다 뒤집히지만, 이런 부채 구조는 한번 꼬이면 업계 전체가 흔들린다. 닷컴 시절 통신장비 벤더 파이낸싱이 겹쳐 보인다는 지적이 괜한 소리가 아니다. 우리 같은 실무자 입장에서는 특정 벤더 API에 올인하지 않는 멀티 벤더 설계가 점점 보험이 아니라 필수가 되어 간다.

AI 회사 자체가 공격 표면이 된 한 주

보안 쪽은 이번 주에 성격이 다른 두 건이 겹쳤다. 9월 30일 OpenAI는 자사 모델 출력을 대량 수집해 다른 모델 학습에 쓰려던 조직적 증류(distillation) 캠페인을 적발해 차단했다고 발표했다. 모델 자체가 털리는 게 아니라 API 호출 패턴으로 지식을 빼가는, 말하자면 모델 지적재산 탈취다. 10월 2일에는 프루프포인트가 중국 연계 그룹 TA419가 앤스로픽 임원과 전직 백악관 과학기술정책실 인사를 사칭해 AI 정책 전문가들에게 피싱을 돌린 정황을 공개했다.

둘을 겹쳐 보면 그림이 선명하다. AI 기업은 이제 서비스 제공자이면서 동시에 국가급 공격자의 1순위 표적이다. 실무 영향도 있다. 회사에서 LLM API를 쓰는 쪽이라면 API 키 관리와 호출 로그 모니터링이 "비용 관리" 이슈에서 "보안" 이슈로 승격됐다고 봐야 하고, AI 업계 사람을 사칭한 스피어피싱은 이제 우리 업계 종사자 전원이 받을 수 있는 메일이 됐다. 지난주 시트릭스 제로데이에 이어, 보안 뉴스가 한 주도 빠지지 않는다.

국내: 퓨리오사AI, 8000억 프리IPO 클로징 초읽기

국내 소식 하나. 뉴스1 보도(10월 5일) 기준으로 퓨리오사AI의 8000억 원 규모 프리IPO가 클로징 초읽기에 들어갔다. 국민성장펀드 3,700억과 산업은행 300억 등 정책자금이 절반을 받치고, 유암코와 시스코 같은 신규 투자자가 들어오면서 기업가치는 약 2조 8천억 원으로 평가됐다. 2세대 AI 칩 레니게이드(RNGD)는 올해 1월 양산을 시작했고 유럽 쪽 검증도 병행 중이다. 메가존클라우드와는 3년간 5,500억 규모 공급 계약 이야기도 나와 있다.

위에서 본 것처럼 미국은 수백억 달러 단위로 판이 커졌다. 그 와중에 국내 AI 칩 회사가 추론 특화라는 각도로 조 단위 밸류에이션을 만들어 가는 건 응원할 일이다. 엔비디아 독주 시장에서 전력 효율 좋은 추론 칩이라는 포지션은 숫자만 받쳐주면 생각보다 공간이 있다. 상장까지 가는 과정, 계속 지켜볼 생각이다.

짧게 훑는 나머지 소식

구글, 무료 제미나이 앱 모델 축소. 아르곤 발표 며칠 뒤인 10월 4일, 구글이 무료 제미나이 앱 사용자에게 제공하던 모델 선택지를 하나로 줄였다는 소식이 나왔다. 최상위 모델은 보안 전문가 우선, 무료 사용자는 단일 모델. 프론티어 경쟁 비용을 결국 누가 내는지 보여주는 장면이다. 무료 티어로 팀원들에게 데모 보여주던 분들은 동작이 달라졌는지 한번 확인해 보시길.

앤스로픽, 1억 달러 들여 엔지니어 1만 명 교육. 10월 2일 앤스로픽이 '클로드 프론티어 아카데미'를 발표했다. 2027년까지 기업 AI 엔지니어 1만 명을 키우겠다는 계획이다. IPO를 앞두고 기업 시장 생태계를 직접 만들겠다는 포석인데, 교육 커리큘럼이 공개되면 팀 차원에서 살펴볼 가치는 있어 보인다.

앤스로픽, 호주에서 robots.txt 방식 옵트아웃 제안. 호주가 AI 저작권 규칙을 검토하는 가운데 앤스로픽이 robots.txt 스타일의 학습 거부 표준을 제안했고, 현지 방송사들은 "기본값이 수집 허용이 되는 것"이라며 반발했다(10월 1일, TNW 보도). 블로그 운영하는 입장에서 남 일이 아니라서 챙겨 봤다. 내 글이 학습에 쓰이는 걸 막는 책임이 창작자 쪽에 넘어오는 구조라, 국내 논의가 시작되면 이 프레임이 그대로 수입될 가능성이 높다.

EU, 엔비디아 중심 AI 칩 시장 들여다본다. 유럽연합이 엔비디아가 지배하는 AI 칩 시장 구조의 적법성 검토에 들어갔다는 보도가 있었다. GPU 할당이 사실상 사업 성패를 가르는 시대라, 규제 당국이 움직이기 시작한 건 놀랍지 않다. 결론까지는 몇 년 걸리겠지만 방향은 기억해 둘 만하다.

모건스탠리 "3년 내 노동력 40% 이상이 AI 영향권". 숫자 자체보다, 이런 전망이 더 이상 뉴스 축에도 못 끼는 분위기가 뉴스다. 예측이 맞든 틀리든 우리가 할 일은 같다. 도구를 손에 익히고, 도구로 대체 안 되는 축적을 만드는 것.

이번 주를 한 줄로

"모델은 수렴하고, 돈은 발산한다." 아르곤과 GPT-6.1 솔의 가격표가 똑같아지는 동안, 인프라 쪽에서는 420억 달러짜리 대출 계약이 나왔다. 다음 주는 앤스로픽 IPO 일정 구체화 여부, 그리고 아르곤의 일반 공개 범위 확대 소식을 지켜보면 될 것 같다. 월요일 출근길에 커피 한잔하면서 참고가 되셨길.

2026년 남은 100일, 목표를 새로 세우지 않고 3개로 줄인 이유 (40대 개발자 아빠의 4분기 계획)

Lovizu — Sun, 4 Oct 2026 23:05:04 +0900

달력을 보다가 잠깐 멈췄다. 오늘이 10월 4일이면, 올해가 딱 88일 남았다. 지난달 말에 '올해 100일 남음' 지점을 지나쳤고, 이제는 두 자리 숫자다. 수능 100일 전에 교실 뒤에 붙던 그 숫자를 마흔 넘어서 다시 만나니 기분이 묘하다. 지난 8월에 2026년 목표 중간 결산을 하면서 살아남은 목표 3개와 접은 목표 4개를 정리했는데, 그로부터 한 달 반쯤 지났다. 이번 글은 그 후속이다. 남은 100일 동안 뭘 할 것인가. 결론부터 말하면, 나는 목표를 새로 세우지 않았다. 오히려 더 줄였다.

남은 100일, 목표를 새로 세우지 않은 이유

연말이 다가오면 이상한 조급함이 생긴다. "올해가 가기 전에 뭐라도 해야 하는데" 하는 마음. 그 마음이 시키는 대로 하면 보통 10월에 새 목표를 서너 개 추가하게 되고, 12월 31일에 그 목표들은 전부 미완성 상태로 내년 목표 리스트에 복사된다. 나도 몇 년을 그렇게 살았다. 재작년 10월에는 갑자기 영어 회화를 등록했고(11월에 접었다), 작년 이맘때는 사이드 프로젝트를 새로 시작했다(커밋 14개 남기고 멈췄다).

올해는 그 패턴을 끊기로 했다. 이유는 단순하다. 100일은 뭔가를 새로 시작해서 결과를 내기엔 짧고, 하던 걸 마무리 짓기엔 충분한 시간이기 때문이다. 애 셋 키우면서 회사 다니는 40대의 하루에서 목표에 쓸 수 있는 시간은 많아야 한두 시간이다. 그 한두 시간을 새 목표의 시동 거는 데 쓰면, 이미 8개월 굴려온 목표들의 마무리가 흐지부지된다. 시동 비용이 제일 비싸다는 건 개발하면서 지겹게 배웠다. 컨텍스트 스위칭이 성능을 잡아먹는 건 CPU나 사람이나 똑같다.

4분기 목표는 3개, 각각 숫자 하나씩

그래서 8월 중간 결산에서 살아남은 목표들을 그대로 가져가되, 남은 100일 동안 도달할 지점을 숫자 하나씩으로 다시 박았다. 목표가 "꾸준히 운동하기" 같은 상태 목표면 연말에 평가가 안 된다. "했나 안 했나"를 셀 수 있어야 한다.

1. 몸: 새벽 운동 주 4회 × 12주 = 48회 중 38회 이상

지난 9월 초에 새벽 30분 홈트 석 달 기록을 썼다. 그 리듬을 연말까지 끌고 가는 게 첫 번째 목표다. 다만 "매일 하기"가 아니라 주 4회로 잡았다. 석 달 굴려보니 주 5회 이상 잡으면 한 번 깨질 때 죄책감으로 이틀을 더 날리고, 주 4회면 하루 밀려도 복구가 된다. 12주 동안 48번의 기회 중 38번 이상 하면 성공. 달성률 80%다. 100%를 목표로 안 잡는 이유는, 애가 셋이라 새벽에 무슨 일이 생길지 모르는 게 우리 집 기본값이기 때문이다. 아이가 새벽에 열이 나면 그날 운동은 없는 거다. 그걸 실패로 계산하는 시스템은 오래 못 간다.

2. 일: 방치한 기술 부채 하나를 연말 전에 청산

회사 일 말고, 내 개인 인프라 얘기다. 몇 년째 "언젠가 정리해야지" 하고 미뤄둔 게 하나 있다. 로컬 NAS와 백업 체계다. 가족사진이 아이폰, 아내 폰, 구글 포토, 외장하드 두 개에 흩어져 있고, 그 외장하드 중 하나는 5년이 넘었다. 개발자가 남의 서버 장애는 잡으러 다니면서 정작 자기 집 데이터는 단일 장애점에 올려놓고 사는 게 몇 년째다. 4분기 안에 백업 3-2-1 원칙(사본 3개, 매체 2종, 오프사이트 1개)에 맞는 구조를 만들고, 흩어진 사진을 한 곳으로 모으는 것까지가 목표다. 완료 조건은 명확하다. 12월 31일에 "외장하드 하나가 지금 죽어도 잃는 게 없는가"에 예라고 답할 수 있으면 된다.

3. 돈: 연말 가계 결산을 12월에 미리 끝내기

지난달 초에 기준금리 3% 시대 가계 점검 글을 쓰면서 대출과 고정지출을 한 번 훑었다. 그때 만든 점검표를 일회성으로 끝내지 않고, 12월 둘째 주까지 올해 가계 결산을 마치는 게 세 번째 목표다. 보통 연말 결산은 1월에 카드값 정산하면서 얼렁뚱땅 하게 되는데, 그러면 결산이 아니라 회고가 된다. 12월 중순에 끝내면 연말정산 준비, 내년 보험 갱신, 예적금 만기 재배치를 금리 상황 봐가며 여유 있게 결정할 수 있다. 완료 조건은 스프레드시트 한 장. 올해 12개월 수입·지출·저축률이 한 화면에 나오면 끝이다.

접은 목표는 다시 줍지 않는다

8월에 접은 목표 4개는 4분기에도 그대로 접힌 상태로 둔다. 이게 생각보다 어렵다. 연말이 되면 접었던 목표들이 자꾸 말을 건다. "지금이라도 하면 되잖아." 안 된다. 8월에 접을 때는 이유가 있어서 접은 거고, 그 이유(시간, 체력, 우선순위)는 10월이라고 사라지지 않는다. 오히려 연말엔 회사 일도 집안 행사도 몰린다.

대신 접은 목표들은 노트 한 페이지에 "왜 접었는지"와 함께 적어뒀다. 내년 1월에 새해 목표를 세울 때 이 페이지부터 읽을 거다. 같은 목표를 같은 방식으로 다시 세우는 실수를 막는 데는 이만한 게 없다. 작년의 나는 이 기록을 안 남겨서, 올해 초에 재작년과 거의 똑같은 목표를 세웠다가 똑같은 지점에서 접었다. 장애 회고를 안 쓰면 같은 장애가 또 터지는 것과 같은 원리다.

100일을 굴리는 방식: 주간 점검 10분

목표를 줄인 대신 점검 주기는 촘촘하게 잡았다. 매주 일요일 밤, 아이들 재우고 나서 10분. 딱 세 줄 쓴다.

운동: 이번 주 몇 회 / 누적 몇 회 (목표 페이스 대비 ±)
NAS: 이번 주에 한 것 한 줄 (안 했으면 "안 함"이라고 그대로 쓴다)
돈: 이번 주 특이 지출 한 줄

포인트는 "안 함"을 그대로 쓰는 거다. 주간 점검이 무너지는 순간은 바쁜 주가 아니라, 못 한 주에 점검 자체를 건너뛸 때다. 한 번 건너뛰면 다음 주에 두 주치를 써야 하니 더 하기 싫어지고, 그렇게 시스템이 죽는다. 기록이 초라해도 기록을 하는 것과 안 하는 것의 차이가 연말에 결산 가능한 한 해와 기억에 의존하는 한 해를 가른다.

그리고 12주짜리 표를 하나 만들었다. 세로축이 목표 3개, 가로축이 주차다. 매주 채워지는 칸을 보는 것만으로도 페이스 감각이 생긴다. 스프린트 번다운 차트를 집에서도 쓰는 셈인데, 도구는 거창할 필요 없다. 나는 그냥 노션 표 하나다. 종이 달력에 동그라미를 쳐도 똑같이 작동한다.

40대의 목표 관리에서 배운 것

20대에는 목표가 많을수록 열심히 사는 것 같았다. 30대에는 목표를 이루는 기술(습관, 루틴, 앱)에 돈과 시간을 썼다. 40대가 되고 아이가 셋이 되니 결론이 단순해졌다. 목표의 개수를 줄이는 것 자체가 가장 강력한 목표 달성 기술이다. 시간과 체력이 유한하다는 걸 몸으로 아는 나이가 되면, 뭘 할지보다 뭘 안 할지 정하는 게 계획의 대부분이 된다.

올해 남은 100일 동안 내가 새로 시작하는 건 없다. 운동은 하던 걸 유지하고, NAS는 미루던 걸 끝내고, 가계부는 하던 걸 한 단계 당겨서 마무리한다. 화려한 게 하나도 없다. 그런데 12월 31일에 이 세 개가 다 되어 있으면, 올해는 꽤 괜찮은 해였다고 말할 수 있을 것 같다.

남은 100일 목표 점검 체크리스트

비슷한 상황에 있는 분들을 위해, 내가 4분기 목표를 정리하면서 쓴 질문들을 남긴다.

지금 굴리고 있는 목표 중 연말까지 마무리 지을 수 있는 것은 무엇인가?
새로 추가하고 싶은 목표가 있다면, 그건 내년 1월에 시작해도 늦지 않은가? (대부분 늦지 않다)
각 목표의 완료 조건을 숫자 하나 또는 예/아니오 질문 하나로 적을 수 있는가?
달성률 100%가 아니라 80%를 기준으로 잡아도 의미가 있는 목표인가?
주간 점검을 10분 안에 끝낼 수 있는 형태인가?
목표가 3개를 넘는가? 넘는다면 어떤 걸 내년으로 보낼 것인가?
올해 접은 목표를 "왜 접었는지"와 함께 기록해뒀는가?

연말까지 88일. 숫자로 보면 짧지만, 주간 점검으로 보면 12번의 기회가 남았다. 새해 계획은 1월 1일에 세우는 게 아니라 12월의 결산에서 나온다고 믿는다. 연말에 결산 글로 돌아오겠다. 그때 이 글이 부끄럽지 않도록, 일단 내일 새벽 운동부터.

이미지 출처: Unsplash — Road Ahead, Renáta-Adrienn, Estée Janssens

한성컴퓨터 27인치 QHD 144Hz 모니터 TFG27Q14P2 한 달 사용기, 17만 원대 코딩용 듀얼 모니터의 정석

Lovizu — Sat, 3 Oct 2026 22:38:35 +0900

집에서 쓰던 24인치 FHD 모니터가 슬슬 한계였다. 재택근무 날이면 IDE 한 쪽에 터미널 띄우고, 브라우저까지 올리면 창 전환만 하루 종일 하는 기분이었다. 회사 모니터는 27인치 QHD인데 집에 오면 화면이 좁아서 능률이 뚝 떨어지는 게 몸으로 느껴졌다. 그래서 조건을 딱 정했다. 27인치, QHD, 주사율 144Hz 이상, 그리고 20만 원 이하. 이 네 가지 조건으로 한참을 뒤지다가 결국 한성컴퓨터 TFG27Q14P2로 정착했다.

왜 하필 한성 TFG27Q14P2였나

모니터 고르는 데 들인 시간이 솔직히 모니터 값보다 아까울 정도였다. 쿠팡에서 27인치 QHD로 검색하면 큐빅스, 이노스, 크로스오버, 픽셀리스 같은 중소 브랜드부터 LG 울트라기어, 삼성 오디세이까지 수십 개가 쏟아진다. 가격대는 12만 원부터 30만 원까지 천차만별이다.

내 기준은 단순했다. 첫째, 패널 복권을 피하고 싶었다. 그래서 '무결점' 보증 옵션이 있는 제품을 우선했다. 둘째, 브랜드 AS가 어느 정도 검증된 곳이어야 했다. 한성컴퓨터는 가성비 모니터 쪽에서 워낙 오래 굴러온 브랜드라 그 점에서 점수를 줬다. 셋째, 144Hz. 게임을 많이 하는 건 아니지만 주말에 아이들 재우고 가끔 하는 게임에서 100Hz와 144Hz는 생각보다 차이가 난다.

TFG27Q14P2는 무결점 모델 기준 17만 원대 후반. 스펙은 27인치(68.5cm) QHD(2560x1440), IPS 패널, 144Hz, 응답속도 1ms(MPRT)다. 이 스펙 조합에 이 가격이면 크게 고민할 이유가 없었다. 쿠팡 상품평이 541개에 평점 분포를 보니 최고 등급이 484개로 압도적이었다. 한 달에 600명 이상 샀다는 표시도 떠 있었다. 사람들이 바보가 아닌 이상 이 정도 물량이 팔리는 데는 이유가 있다.

개봉과 설치, 10분이면 끝

로켓배송으로 다음 날 도착했다. 박스는 생각보다 컸지만 구성은 단출하다. 모니터 본체, 받침대, 지지대, DP 케이블, 어댑터. 조립은 공구 없이 손나사로 끝난다. 받침대 결합하고 책상에 올리는 데 10분이 안 걸렸다.

첫인상은 "베젤이 진짜 얇네"였다. 3면 베젤리스 디자인이라 화면 켜기 전에는 테두리가 거의 안 보인다. 디자인은 전형적인 게이밍 모니터처럼 요란하지 않고 담백한 블랙이라 사무용 책상에 놔도 이질감이 없다. 이 점이 의외로 마음에 들었다. 마흔 넘어서 책상에 RGB 번쩍거리는 물건 올리는 건 좀 부담스럽다.

전원 넣고 해상도 잡히는 것 확인하고, 그래픽 설정에서 144Hz로 바꿔주면 끝. 윈도우에서는 설정-디스플레이-고급 디스플레이에서 주사율을 직접 선택해야 한다. 이거 안 하고 60Hz로 쓰면서 "144Hz 별거 없네" 하는 경우가 은근히 많다. 맥북에 물릴 거라면 시스템 설정-디스플레이에서 재생 빈도를 확인하자. 참고로 맥북과 연결할 때는 USB-C to DP 케이블을 따로 준비하는 게 깔끔하다. 이 모니터에는 USB-C 입력이 없어서 HDMI나 DP로 연결해야 한다.

초기 세팅에서 하나 더 챙길 게 OSD 설정이다. 공장 출하 상태는 밝기가 꽤 높게 잡혀 있어서 밤에 쓰면 눈이 부시다. 나는 밝기를 40 전후로 내리고, 블루라이트 저감 모드는 끈 상태에서 윈도우 야간 모드로 대체했다. 모니터 뒤쪽 조그 버튼으로 조작하는데, 메뉴 구조가 단순해서 헤맬 일은 없다. 게임 모드니 FPS 모드니 하는 프리셋도 있지만 솔직히 표준 모드에서 밝기만 잡아줘도 충분하다.

한 달 실사용: 코딩, 문서, 그리고 가끔 게임

가장 체감이 큰 건 역시 작업 공간이다. QHD는 FHD 대비 픽셀이 1.8배 가까이 많다. VSCode 기준으로 코드 창 두 개를 나란히 띄우고도 파일 트리가 답답하지 않다. 24인치 FHD에서는 꿈도 못 꾸던 배치다. 터미널 로그 보면서 코드 고치는 작업이 확실히 편해졌다.

글자 선명도도 만족스럽다. 27인치에 QHD면 픽셀 밀도가 약 109PPI라서 윈도우 배율 100~125% 사이에서 글자가 자글거리지 않는다. 하루 종일 텍스트를 보는 직업이라 이게 눈 피로에 직결되는데, 확실히 FHD 때보다 덜 피곤하다. 상품평에서도 "문서 작업할 때 눈이 편하다"는 얘기가 유독 많았는데 써보니 공감이 된다.

IPS 패널이라 색감과 시야각도 무난하다. 전문 색 작업을 할 수준은 아니지만, 사진 정리하거나 영상 보는 용도로는 부족함이 없다. 144Hz는 게임에서만 좋은 게 아니다. 마우스 커서 움직임, 창 드래그, 스크롤 같은 일상 동작이 전부 부드러워진다. 한 번 익숙해지면 60Hz 모니터로 돌아가기 힘들다는 말이 괜히 나오는 게 아니다.

주말 밤에 가끔 하는 게임에서도 제값을 한다. 응답속도 1ms(MPRT)에 144Hz면 FPS를 빡세게 파는 사람이 아닌 이상 아쉬울 게 없는 스펙이다. 나처럼 일주일에 두세 시간 게임하는 아빠한테는 차고 넘친다.

의외의 수확은 가족 공용으로도 쓸모가 있다는 점이다. 주말 낮에는 첫째가 이 모니터로 숙제하고 타자 연습을 한다. 27인치면 아이 눈높이에서도 글자가 커서 좋고, QHD라 유튜브 학습 영상 틀어놓고 옆에 문서 띄우는 것도 된다. 아이 셋 집에서는 물건 하나를 사도 이렇게 돌려쓸 수 있는지가 은근히 중요한 기준이 된다.

듀얼 구성 얘기도 해야겠다. 상품평을 보면 이 모니터를 두 대 사서 듀얼로 쓰는 사람이 유독 많다. 코딩하는 사람 입장에서 이해가 간다. 17만 원대니까 두 대를 사도 대기업 모니터 한 대 값 수준이다. 나는 당장은 한 대만 들였지만, 기존 24인치를 세로로 돌려서 옆에 두고 로그 전용으로 쓰고 있다. 3면 베젤리스라 듀얼로 붙였을 때 경계선이 거슬리지 않는 것도 장점이다.

단점도 분명히 있다

한 달 쓰면서, 그리고 상품평 수백 개를 훑으면서 정리한 아쉬운 점들이다.

첫째, 스탠드가 틸트만 된다. 높이 조절, 피벗, 스위블 전부 없다. 기본 스탠드 높이가 애매하다고 느끼면 모니터 받침대를 따로 사거나 모니터암을 달아야 한다. 실제로 두 대를 사서 듀얼로 놨는데 미세하게 높이가 안 맞았다는 상품평도 있었다. 나는 처음부터 모니터암 쓸 생각이었어서 문제가 안 됐지만, 책상에 그냥 올려 쓸 사람은 참고해야 한다. VESA 홀은 있으니 암 장착은 가능하다.

둘째, 고주파음 사례가 있다. 상품평 중에 144Hz로 쓸 때 고주파음이 신경 쓰인다는 후기가 있었다. 내 개체에서는 귀를 바짝 대야 들릴까 말까 한 수준이라 체감이 없는데, 이건 전자제품 특성상 개체차가 있는 부분이다. 조용한 방에서 쓰는데 소리에 예민한 편이라면 수령 직후에 꼭 확인해보는 게 좋다.

셋째, 무결점이라고 100% 안심은 아니다. 무결점 옵션인데도 구석에 점 하나를 발견했다는 상품평이 있었다. 무결점 보증은 불량 화소 발견 시 교환해주는 정책이지 불량 화소가 아예 없다는 보장이 아니다. 받자마자 단색 화면 띄워서 데드픽셀 체크하고, 있으면 바로 교환 신청하는 게 정석이다. 보증 기간 지나고 발견하면 답이 없다.

넷째, 배송 구성품 확인은 필수. 어댑터가 빠진 채로 왔다는 상품평도 있었다. 쿠팡 배송이 빠른 대신 이런 사고가 아예 없지는 않으니, 박스 열면 구성품부터 체크하자. 로켓배송이라 교환 처리 자체는 빠르다.

다섯째, 영상 재생 시 깜빡임을 겪었다는 사례. 동영상을 틀면 화면이 깜빡인다는 상품평이 하나 있었다. 이런 증상은 보통 케이블 문제거나 그래픽 드라이버와 가변 주사율(FreeSync) 설정이 꼬였을 때 나온다. 비슷한 증상이 보이면 동봉된 DP 케이블 대신 다른 케이블로 바꿔보고, 그래픽 드라이버를 최신으로 올린 뒤 FreeSync를 껐다 켜보는 순서로 확인해보자. 그래도 안 되면 불량이니 교환이 답이다.

경쟁 제품과 비교하면

같은 가격대에서 고민했던 제품들과 간단히 비교하면 이렇다.

큐빅스 QHD 27인치(약 12만 원): 가격은 확실히 싸다. 다만 주사율이 100Hz고, 브랜드 인지도나 AS 측면에서는 한성보다 한 수 아래라고 봤다. 세컨드 모니터로는 좋은 선택지다.

이노스 27인치 QHD NANO IPS(약 17~18만 원): 가장 치열하게 고민한 상대. LG 패널을 쓰고 가격도 비슷하다. 120Hz라는 점과 당시 배송 일정 때문에 한성으로 기울었는데, 이노스를 골랐어도 후회는 없었을 것 같다.

LG 울트라기어 QHD(약 30만 원), 삼성 오디세이 G5(약 29만 원): 대기업 브랜드에 스펙도 좋지만 10만 원 이상 비싸다. 그 차액이면 모니터암에 키보드까지 산다. 브랜드 자체에 가치를 두는 게 아니라면, 이 용도에서 체감 차이는 크지 않다고 본다.

델 QHD 144Hz(약 30만 원): 사무용 신뢰도는 최상급인데 역시 가격. 회사 장비로는 델을 선호하지만 내 돈으로 집에 들이기엔 망설여졌다.

결국 "17만 원대에서 27인치 + QHD + 144Hz + IPS + 무결점 보증"을 전부 챙길 수 있는 조합이 한성이었다. 가성비라는 말을 별로 안 좋아하는데, 이 제품에는 그 말이 정확하게 들어맞는다.

이런 사람에게 추천, 이런 사람은 패스

추천: 재택근무나 공부용으로 첫 QHD 모니터를 알아보는 사람, 듀얼 모니터를 저렴하게 구성하고 싶은 사람, 업무 7 게임 3 정도의 비율로 쓰는 사람, 모니터암을 쓸 계획이 있는 사람. 특히 코딩하는 사람한테는 24인치 FHD에서 넘어왔을 때 만족도가 체감상 가장 큰 업그레이드 구간이다.

패스: 스탠드에서 높이 조절이 꼭 필요한 사람(모니터암 없이 쓸 거라면 다시 생각하자), 색 정확도가 중요한 전문 그래픽 작업자, 240Hz 이상이 필요한 FPS 헤비 게이머. 그리고 4K가 필요한 영상 편집 용도라면 애초에 다른 카테고리를 봐야 한다.

받자마자 해야 할 체크리스트 5가지

상품평에서 나온 문제 사례들을 종합하면, 수령 직후 10분 투자로 대부분의 리스크를 걸러낼 수 있다. 모니터류는 초기 불량을 빨리 발견할수록 처리가 깔끔하다.

1. 구성품 확인: 본체, 스탠드, 어댑터, DP 케이블이 다 들어있는지. 어댑터 누락 사례가 실제로 있었다.
2. 데드픽셀 체크: 단색 화면(흰색, 검정, 빨강, 초록, 파랑)을 전체 화면으로 띄워서 점 있는지 확인. 무결점 모델이면 발견 즉시 교환 신청.
3. 주사율 설정: 윈도우 고급 디스플레이 설정에서 144Hz 선택. 60Hz로 쓰면 이 모니터 산 의미가 절반은 날아간다.
4. 고주파음 확인: 조용한 환경에서 144Hz 상태로 밝은 화면을 띄우고 소리가 나는지 확인. 거슬리는 수준이면 초기에 교환하는 게 낫다.
5. 빛샘 확인: 어두운 방에서 검정 화면을 띄워 모서리 빛샘 정도 확인. IPS 특성상 약간은 있는 게 정상이고, 심하면 교환 대상이다.

이 다섯 개만 해두면 로켓배송 교환 가능 기간 안에 복불복 요소를 거의 다 털어낼 수 있다. 귀찮아서 안 하고 있다가 한 달 뒤에 발견하면 그때부터는 머리가 아파진다.

마무리

모니터는 한 번 사면 5년 넘게 쓰는 물건이다. 10년 된 모니터를 바꾸고 나서야 "왜 진작 안 바꿨지" 싶었다는 상품평이 있었는데, 딱 내 심정이다. 매일 8시간 넘게 들여다보는 물건에 17만 원이면, 하루로 치면 커피 한 잔 값도 안 된다. 눈이 편해지고 작업 효율이 올라가는 걸 생각하면 올해 산 장비 중에 가장 돈값을 한 물건이다.

장비 욕심이라는 게 끝이 없어서, 더 좋은 모니터는 항상 존재한다. 4K도 있고 OLED도 있고 울트라와이드도 있다. 하지만 예산 안에서 매일 쓰는 시간 대비 만족도를 따지면, 17만 원대 27인치 QHD 144Hz는 지금 시점에서 가장 합리적인 선택지 중 하나라고 생각한다. 적어도 "모니터 때문에 일 못 하겠다"는 핑계는 사라졌다. 이제 핑계가 없어진 게 문제라면 문제다.

구매는 아래 링크에서 확인할 수 있다.

한성컴퓨터 QHD 평면형 27인치 게이밍 모니터 TFG27Q14P2 (쿠팡 최저가 확인)

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

본문 사진: 쿠팡 상품 페이지 구매자 상품평 이미지(제품 컷)

지난주 테크 뉴스 핵심 정리: 오푸스 5.5 vs GPT-6 솔, 시트릭스 제로데이, 반도체 수출 48%

Lovizu — Fri, 2 Oct 2026 10:34:22 +0900

3주 만에 다시 쓰는 주간 테크 뉴스 정리다. 애 셋 데리고 추석 연휴를 통과하느라 정리를 걸렀더니, 그 사이 업계가 조용했느냐 하면 정반대였다. 지난주(9/21~9/27)는 앤스로픽과 OpenAI가 같은 날, 그것도 90분 간격으로 신모델을 맞붙여 내놨고, 시트릭스는 CVE 번호조차 없는 제로데이 2건이 실전에서 터지는 초유의 상황을 맞았다. 국내 반도체 수출은 또 기록을 갈아치웠다. 하나씩 정리해 본다.

앤스로픽 오푸스 5.5 vs OpenAI GPT-6 솔·루나, 90분 차이 맞대결

9월 22일(현지시간), 앤스로픽이 클로드 오푸스 5.5(Claude Opus 5.5)를 발표했다. 새 5.5 패밀리의 첫 모델인데, 핵심은 성능보다 가격이다. 대부분의 작업에서 자사 최상위 모델인 페이블 5.1급 성능을 내면서 운영 비용은 오푸스 5 대비 40% 싸다는 게 회사 설명이다.

그런데 그로부터 딱 90분 뒤, OpenAI가 GPT-6 솔(Sol)과 루나(Luna)를 내놨다. 테크크런치가 이 90분 간격을 콕 집어 보도했을 정도로, 두 회사가 서로의 발표 일정을 의식하고 있다는 게 노골적으로 드러난 하루였다. 솔과 루나는 지난 7월 GPT-5.6 시리즈에서 처음 등장한 라인업인데, 솔은 코딩 같은 복잡한 작업용, 루나는 문서 요약·정보 추출·짧은 질의응답처럼 목표가 분명한 대량 작업용으로 역할이 나뉘어 있다. 이달 초 나온 최상위 모델 아스트라가 "새 세대의 지능"이라면, 이번 둘은 그 지능을 싸고 넓게 뿌리는 보급형이라는 게 OpenAI의 설명이다.

숫자를 보면 의도가 더 분명하다. API 가격은 기존 5.6 시리즈의 절반이고, OpenAI는 이 인하가 캐싱·추론 최적화 덕분이라고 밝혔다. 실사용 대화 기반의 자체 팩트 평가에서는 솔의 오답률이 전작의 절반 수준으로 줄어, 훨씬 싼 값에 아스트라급 신뢰도를 낸다고 주장했다. 발표문 곳곳에서 앤스로픽의 페이블·오푸스보다 낫다는 비교를 반복한 것도 인상적이었다. 새 모델은 ChatGPT Work와 Codex, API에 먼저 풀리고 루나는 무료·Go 요금제까지 내려간다.

이게 우리한테 뭘 의미하느냐. 프런티어 경쟁이 "누가 더 똑똑한가"에서 "누가 같은 성능을 더 싸게 주는가"로 확실히 넘어왔다는 얘기다. 두 회사가 같은 날 나란히 가격 인하 카드를 꺼냈다는 건 우연이 아니다. API로 서비스 만드는 입장에서는 반가운 흐름이고, 분기마다 모델 단가표를 다시 짜야 하는 시대가 됐다. 실제로 반년 전에 "이 작업은 비싸서 최상위 모델 못 쓴다"고 접어둔 기능이 있다면 지금 단가로 다시 계산해 볼 만하다. 나도 사이드 프로젝트에서 쓰는 모델 티어를 이번 주에 다시 짜볼 생각이다. 이런 속도로 가격이 떨어지면 모델 선택 로직 자체를 설정값으로 빼두는 게 맞다는 걸 요즘 절감한다.

구글 "제미나이 4, 최대한 빨리" — 3.5 Pro는 접었다

경쟁사 둘이 신모델을 쏟아내는 동안 구글은 어디 있느냐는 질문에, 답이 나왔다. 9월 24일 딥마인드의 코라이 카부크추오글루가 디인포메이션의 AI 어젠다 라이브 서밋에서 차기 플래그십 제미나이 4가 포스트트레이닝 단계에 들어갔고 "최대한 빨리(as soon as possible)" 내놓겠다고 확인했다. 연말보다 훨씬 이르게 내는 게 목표라고 한다.

흥미로운 대목은 따로 있다. 여름에 예고까지 했던 제미나이 3.5 Pro는 결국 출시하지 않았고, 그 대신 "한 발 물러서서" Flash 계열에 집중했다는 걸 사실상 인정했다. 실제로 작년 11월 제미나이 3 Pro, 올해 2월 3.1 Pro 이후 플래그십은 감감무소식이었고, 그 사이 나온 건 9월 초 3.8 Flash 같은 경량 모델뿐이었다. 지금은 제미나이 4로 자사 코딩 도구 앤티그래비티(Antigravity)를 돌려보는 내부 테스트가 진행 중이라고 한다. 구글이 뒤처진 것 아니냐는 물음에는 "우리가 프런티어에 항상 있을 거라는 건 내 안에선 확실한 사실"이라고 답했다.

15년 개발자 짬으로 번역하면, 내부 로드맵이 한 번 갈아엎어졌다는 뜻이다. 예고한 버전을 조용히 접고 다음 메이저로 직행하는 건 조직 안에서 꽤 큰 결단이 있었다는 신호다. 카부크추오글루가 AGI 질문에 "이제 논점은 신뢰할 수 있는 지능형 에이전트를 만들 수 있느냐"라고 답한 것도 눈여겨볼 만하다. 벤치마크 점수 싸움에서 에이전트 신뢰성 싸움으로 전선이 옮겨가고 있다는 얘기다. 11월이면 제미나이 3 출시 1년인데, 4가 그 안에 나올지가 4분기 AI판의 최대 관전 포인트가 됐다.

시트릭스 넷스케일러, CVE도 없는 제로데이 2건이 실전에서 악용 중

보안 쪽은 이번 주도 무거웠다. 9월 26일 보안 연구업체 watchTowr가 시트릭스 넷스케일러 ADC·게이트웨이에서 미패치 원격코드실행(RCE) 취약점 2건을 공개했고, 더해커뉴스가 27일 이를 보도했다. 문제는 발견 경위다. 연구실에서 찾은 게 아니라, 이미 침해당한 고객사 포렌식 조사 중에 발견됐다. 즉 공격자들이 먼저 쓰고 있었다는 얘기다.

더 심각한 건 절차의 공백이다. 글을 쓰는 시점까지 시트릭스는 취약점 확인도, CVE 번호 부여도, 보안 권고문도, 패치도 내놓지 않았다. CVE가 없으니 취약점 스캐너는 잡아내지 못하고, CISA의 악용 취약점 목록(KEV)에도 올릴 수 없다. 미국 연방기관의 의무 조치 시계 자체가 시작을 못 하는 상황이다. 넷스케일러는 올해만 3월 CitrixBleed 3(CVE-2026-3055), 6월 메모리 오버리드, 8월 인증 우회(CVE-2026-19490)에 이어 벌써 네 번째 대형 사고다.

넷스케일러 굴리는 분들은 패치 기다리지 말고 지금 할 수 있는 걸 먼저 하는 게 맞다. show ns version으로 빌드 버전을 확인해 두고(권고문이 나오면 대조해야 한다), 관리 인터페이스 접근을 신뢰 IP 대역으로 제한하고, 인증 로그에서 이상한 관리자 세션이나 로그 공백이 없는지 살펴보시라. 침해된 환경의 포렌식에서 발견된 건이니, "우리는 아직 공격 안 당했겠지"가 아니라 "이미 들어와 있을 수 있다"를 전제로 봐야 한다. watchTowr는 9월 28일 주간에 시트릭스가 패치를 낼 것으로 예상한다고 했으니, 이번 주 공지를 예의주시해야 한다.

운영 연차 있는 사람이라면 올해 엣지 장비 사고 패턴이 눈에 밟힐 거다. F5 BIG-IP, 시스코 ISE(CVSS 10.0), 아리스타 벨로클라우드(CVSS 10.0)까지, VPN·로드밸런서·인증 게이트웨이처럼 인증 이전 단계의 코드가 인터넷에 그대로 노출되는 장비들이 올해 공격자들의 주력 진입로가 됐다. 피싱 메일보다 미패치 엣지 장비를 노리는 쪽이 랜섬웨어 조직들의 표준 수법이 되었다는 분석도 나와 있다. 경계 장비 하나만 뚫리면 내부망 전체가 열리는 구조를 언제까지 유지할 건지, 제로 트러스트 전환 논의를 미루어온 조직일수록 이번 사건을 계기로 생각해 볼 만하다.

앤스로픽-아카마이 116억 달러 계약, 지분 5% 워런트까지

인프라 쪽 빅딜도 있었다. 9월 24일 아카마이가 앤스로픽과 7년간 116억 달러 규모의 클라우드 인프라 계약을 발표했다. 옵션이 다 실행되면 약 200억 달러까지 커질 수 있는 계약이다. 5월에 맺은 18억 달러 계약을 크게 확장한 건데, 블룸버그에 따르면 이번엔 GPU가 아니라 CPU 공급 중심이라는 점이 눈에 띈다.

구조도 특이하다. 아카마이는 앤스로픽에 보통주 약 5%에 해당하는 770만 주 워런트(행사가 111.33달러)를 발행했다. 고객이 공급사 지분을 받는 형태인데, 아카마이 CEO 톰 레이턴은 블룸버그에 "고객과의 클라우드 계약에 워런트를 붙인 건 이번이 처음"이라고 했다. 발표 직후 아카마이 주가는 시간외에서 17%까지 뛰었다.

아카마이 쪽 셈법도 만만치 않다. 이 계약을 이행하려고 약 55억 달러의 설비투자를 잡았는데, 이는 작년 한 해 전체 설비투자의 여섯 배가 넘는 규모다. 메모리 선구매를 위해 올해 투자도 17억 달러 늘렸다. 매출은 내년 1.5억~3억 달러에서 시작해 2028년엔 연 17억 달러 수준을 기대한다고 한다. 다만 월가에서는 이런 식으로 서로 사고 서로 투자하는 순환 거래가 늘면 AI 실수요가 얼마인지 가늠하기 어려워진다는 지적도 같이 나온다. CDN 회사로만 알던 아카마이가 AI 컴퓨트 공급자로 변신하는 그림 자체는 흥미롭지만, 올해 앤스로픽이 볼타(100억 달러), 럼그룹(137억 달러 추정)에 이어 컴퓨트 계약을 쌓는 속도를 보면 이 판의 자본 소모전이 어디까지 갈지 아찔하기도 하다.

국내 반도체 수출, 9월 중순까지 역대 최대 — 전체 수출의 48%

국내 뉴스로 넘어오면, 수출 통계가 또 기록을 썼다. 관세청 집계 기준 9월 1~20일 수출이 동기간 역대 최대를 기록했고, 그중 반도체 비중이 48%에 달했다고 연합뉴스가 21일 보도했다. 흐름을 거슬러 올라가면 더 가파르다. 이달 초순(1~10일) 수출은 349억 7천만 달러로 1년 전보다 82.6% 늘며 두 달 만에 동기간 기록을 갈아치웠는데, 그중 반도체가 전년 대비 270% 급증하며 전체 수출의 47.1%를 차지했다. 무역수지도 103억 7천만 달러 흑자로 역대 최대였다. 메모리 가격 상승과 물량 증가가 동시에 실리면서 수출 통계가 매 순번 기록을 새로 쓰는 국면이다.

AI 인프라 투자가 실제 돈이 되어 국내 메모리 업계로 흘러들어오고 있다는 게 숫자로 확인되는 셈이다. 앞에서 본 아카마이 계약만 봐도 메모리 선구매에 조 단위 돈이 움직이고 있으니, HBM과 서버용 D램 수요가 당분간 꺾일 이유를 찾기 어렵다. 다만 수출의 절반 가까이가 품목 하나에 걸려 있다는 건 뒤집어 보면 그만큼 포트폴리오가 쏠려 있다는 뜻이기도 하다. 메모리 사이클이 꺾이는 순간 국가 단위로 흔들린다는 얘기라, 좋아만 하기엔 찜찜함이 남는다. 월급쟁이 가장 입장에서 반도체 호황 뉴스는 늘 반갑지만, 이런 쏠림 장세일수록 내 포트폴리오까지 같은 방향으로 쏠려 있지 않은지 점검하게 된다.

그 밖에 짚어둘 소식들

클로드 마켓플레이스·플러그인 개발자 포털 오픈(9/25) — 앤스로픽이 플러그인 제출·심사 추적·사용 분석까지 되는 개발자 포털을 열었다. 클로드 생태계를 앱스토어처럼 키우겠다는 신호다.
메타 Muse, 초반 성장세가 ChatGPT 초기보다 빠르다(9/21, 테크크런치) — 모바일 AI 앱 경쟁에서 메타가 수십억 사용자 배포망을 무기로 밀어붙이는 중이다. 모델 성능보다 유통 채널이 승부를 가를 수 있다는 걸 보여주는 사례다.
시스코 시큐어 이메일 게이트웨이 루트 RCE 제로데이 악용(시큐리티위크) — 넷스케일러만의 문제가 아니다. 올해 엣지 장비 수난사는 F5, 시스코 ISE, 아리스타까지 이어지는 업계 공통 패턴이다.
앤스로픽·OpenAI, 호주에 AI 학습 저작권 완화 요청(9/22) — 호주의 강경한 AI 학습 저작권 규제에 대해 두 회사가 투자·창작자 지원과 연계한 좁은 예외를 제안했다. AI 학습 데이터를 둘러싼 국가별 규제 지형이 갈라지는 중이다.
앤스로픽 "클로드가 자사 모델 R&D의 26%를 주도"(9/18) — 사람 감독하에 상위 지시만 받고 태스크를 끝까지 수행하는 비중이 저 정도라는 발표다. AI가 다음 AI를 만드는 재귀 구조가 홍보 문구가 아니라 수치로 나오기 시작했다.
트럼프-테크 CEO 회동(9/29) — 미 백악관이 AI를 의제로 테크 CEO들과 만난다는 보도가 지난주 나왔고, 회동은 예고대로 이번 주 월요일에 열렸다. AI 규제·투자 정책의 방향타가 될 수 있는 자리다.

마무리 — 이번 주 볼 것

이번 주 키워드를 한 줄로 줄이면 "가격 전쟁과 엣지 보안 구멍"이다. 그리고 이번 주도 이미 시끄러웠다. 이번 주 월요일(9/29) OpenAI 데브데이가 열렸고, 시트릭스의 넷스케일러 패치와 CVE 부여도 이번 주 안에 나올 것으로 예상된다. 데브데이에서 뭐가 나왔는지, 넷스케일러 권고문에 어떤 빌드가 포함되는지는 다음 주 정리에서 이어서 다루겠다. 그리고 구글이 제미나이 4 카드를 정말 4분기 안에 꺼낼지도. 프런티어 3사가 전부 발사대에 올라와 있는 4분기는 오랜만이라, 지켜보는 재미는 확실할 것 같다.

추석에 부부싸움 안 하는 법, 결혼 11년차 아이 셋 아빠의 명절 평화 원칙 7가지

Lovizu — Thu, 1 Oct 2026 23:06:57 +0900

추석 연휴가 끝나고 일주일쯤 지났다. 결혼 11년차니까 명절을 스무 번 넘게 치렀다. 아이가 셋이 되고 나서는 명절이 '쉬는 날'이 아니라 '치르는 날'이라는 걸 몸으로 안다. 그리고 솔직히 고백하면, 우리 부부가 크게 싸운 날의 절반은 명절이거나 명절 직후였다. 연휴가 끝나고 출근한 월요일에 서로 말을 안 한 적도 있다.

명절 부부싸움, 명절증후군, 시댁 스트레스. 명절마다 검색량이 치솟는 단어들이라고 한다. 그만큼 다들 비슷하게 힘들다는 뜻일 거다. 우리 부부도 예외가 아니었다.

그런데 몇 년 전부터는 명절에 거의 안 싸운다. 사이가 갑자기 좋아져서가 아니다. 싸울 만한 지점을 미리 없애는 요령이 생겼기 때문이다. 이번 추석을 복기하는 김에, 결혼 11년차 아이 셋 아빠가 명절 부부싸움을 피하려고 지키는 원칙들을 정리해둔다. 이번 명절에 한바탕 치르고 온 분이라면, 다음 설이 오기 전에 참고할 만한 게 하나쯤 있을 거다.

명절 부부싸움은 명절에 터질 뿐, 명절에 시작되지 않는다

이게 내가 깨달은 것 중 제일 중요한 거다. 명절 당일에 터지는 싸움의 원인은 대부분 명절 전에 이미 만들어져 있다. 양가 용돈을 얼마 할지, 선물은 뭘 할지, 언제 출발할지, 어디서 자고 올지. 이런 걸 정하지 않은 채로 연휴에 들어가면, 결정의 순간마다 협상을 해야 하고, 협상은 피곤한 상태에서 하면 반드시 감정 싸움이 된다.

그래서 우리는 명절 일주일 전에 15분짜리 회의를 한다. 거창한 건 아니고 애들 재우고 식탁에서 하는 짧은 대화다. 안건은 딱 네 개. 양가 용돈 금액, 선물 품목과 예산, 이동 일정, 각자 집에 머무는 시간. 이걸 미리 정해두면 명절 당일에는 실행만 하면 된다. 결정할 게 없으니 싸울 거리도 없다.

특히 돈 얘기는 반드시 명절 전에 끝내야 한다. 시댁 용돈과 처가 용돈이 다르다는 걸 명절 당일에 알게 되는 순간, 그날 저녁은 무조건 냉전이다. 우리는 몇 년 전부터 양가 동일 금액 원칙으로 못을 박았다. 금액이 같으면 해석의 여지가 없다.

참고로 우리 집 명절 총예산은 '양가 용돈 + 선물 + 교통비 + 애들 옷' 합쳐서 상한선을 정해놓고 그 안에서만 움직인다. 아이 셋 기준으로 명절 한 번에 나가는 돈이 만만치 않아서, 상한선 없이 그때그때 쓰면 연휴 끝나고 카드값 보면서 2차전이 벌어진다. 돈 문제로 싸우는 게 아니라, 돈을 정해두지 않아서 싸우는 거다. 이건 명절만이 아니라 가계 전반에 통하는 원리인데, 명절에 제일 극적으로 드러난다.

선물도 요령이 생겼다. 품목 고민을 명절마다 새로 하지 않는다. 양가 부모님이 좋아하시는 걸 몇 년에 걸쳐 파악해서 사실상 고정 품목으로 굳혔고, 온라인으로 명절 열흘 전에 주문해 미리 보내드린다. 명절 직전 배송 대란에 걸리면 그것도 스트레스고, 당일에 사서 들고 가는 건 짐이다. 선물 고민이 사라지니 명절 준비 스트레스의 한 축이 통째로 사라졌다.

방문 순서와 체류 시간은 '공식'으로 정해놨다

결혼 초에는 매번 협상했다. 이번엔 어디 먼저 갈까, 몇 시에 일어날까. 이 협상이 매번 소모전이었다. 지금은 공식이 있다. 설에는 시댁 먼저, 추석에는 처가 먼저. 번갈아 간다. 그리고 각 집 체류 시간은 최대한 비슷하게 맞춘다.

이 공식의 좋은 점은 누구도 서운할 이유가 구조적으로 없다는 거다. 아내 입장에서 "왜 맨날 시댁부터 가"라는 말이 나올 일이 없고, 나도 눈치 볼 일이 없다. 부모님들도 몇 년 지나니 패턴을 아셔서 아예 그 일정에 맞춰 음식을 준비하신다.

체류 시간을 비슷하게 맞추는 것도 생각보다 중요하다. 한쪽 집에서 1박을 하면 다른 쪽 집에도 그에 준하는 시간을 쓴다. 정확히 시간을 재는 건 아니지만, 서로 "우리 집에는 잠깐 들르는 수준"이라는 느낌을 받지 않게 하는 게 핵심이다. 부부싸움의 상당수는 사실 계산의 문제가 아니라 서운함의 문제다.

전 부치는 집에서 남편이 사라지면 안 된다

솔직하게 쓴다. 결혼 초의 나는 시댁에 가면 거실에 앉아 있는 남편이었다. 부엌에서 아내가 어머니와 전을 부치는 동안 나는 TV 앞에서 아버지와 과일을 먹었다. 그때는 그게 문제인 줄도 몰랐다. 아내가 몇 번을 참다가 터뜨리고 나서야 알았다.

지금 나의 명절 포지션은 명확하다. 시댁에서는 내가 제일 많이 움직인다. 전 뒤집기, 상 차리기, 설거지, 쓰레기 버리기, 애들 건사까지. 아내가 처가에서 편하려면 내가 시댁에서 먼저 움직여야 한다는 걸 늦게 배웠다. 반대로 처가에서는 아내가 나를 챙긴다. 각자 자기 부모 집에서 배우자의 방패가 되어주는 것. 이게 우리가 찾은 균형이다.

요즘은 차례를 간소화하거나 아예 여행으로 대체하는 집도 많다고 들었다. 우리 양가는 아직 음식을 하는 쪽이라 이 원칙이 유효한데, 어느 쪽이든 본질은 같다고 본다. 명절 노동이 한 사람에게 쏠리는 구조를 부부가 함께 깨고 있느냐. 형태가 어떻든 그 질문에 "그렇다"고 답할 수 있으면 명절 싸움의 최대 지뢰 하나는 제거된 거다.

애 셋 아빠 입장에서 하나 더 보태면, 명절에 아이들을 보는 것도 명백한 노동이다. "나는 애 봤잖아"라고 말하고 싶다면, 정말로 애만 봤는지 스마트폰을 보면서 애 옆에 있었는지 스스로에게 물어봐야 한다. 아내들은 그 차이를 정확하게 안다.

귀성길 운전 스트레스를 조수석에 풀지 않는다

우리 집은 양가가 다 지방이라 명절마다 왕복 500km를 넘게 달린다. 애 셋을 태우고 정체 구간에 갇혀 있으면 누구라도 예민해진다. 돌이켜보면 명절 싸움의 도화선이 차 안이었던 적이 꽤 많다. 운전하다 짜증이 올라온 상태에서 아내가 길 안내 한마디 하면 그게 시비처럼 들리고, 그렇게 시작된 말다툼이 명절 내내 이어지는 식이다.

애 셋과 장거리를 다녀본 분들은 알 거다. 이동 자체가 하나의 프로젝트다. 간식 준비, 화장실 타이밍, 뒷자리 분쟁 중재까지 전부 변수다. 이 변수들을 운전자 혼자 감당하면 반드시 터진다. 그래서 우리는 역할을 나눈다. 나는 운전만, 아내는 뒷자리 상황 통제만. 서로의 영역에 훈수 두지 않는 게 룰이다. 운전자에게 "아까 그 길로 갔어야지"라고 하지 않고, 뒷자리 중재에 "애를 왜 그렇게 달래"라고 하지 않는다.

그래서 만든 규칙이 몇 개 있다. 첫째, 출발 시간은 무조건 새벽이다. 애들이 차에서 자는 시간이 길수록 모두가 평화롭다. 둘째, 두 시간마다 휴게소에 선다. 급할 게 없다. 셋째, 운전 중에 예민한 주제를 꺼내지 않는다. 용돈 얘기, 부모님 얘기, 돈 얘기는 차 안에서 금지다. 밀폐된 공간에서 도망갈 곳 없이 하는 대화는 싸움이 되기 쉽다. 넷째, 내가 운전대를 잡았으면 짜증도 내 몫이다. 정체는 아내 탓이 아니다.

각자의 부모에 대한 아쉬움은 각자가 말한다

이건 우리 부부의 명절 헌법 같은 거다. 시댁에서 서운한 일이 있었으면 그 얘기를 아내가 아니라 내가 꺼낸다. 처가에서 뭔가 불편했으면 아내가 먼저 말한다. 배우자의 부모를 내 입으로 평가하는 순간, 아무리 맞는 말이어도 상대는 방어 태세가 된다. 같은 내용이라도 "우리 엄마가 오늘 좀 심하셨지, 미안해"라고 내가 먼저 말하면 아내는 오히려 괜찮다고 한다.

포인트는 순서다. 잘못을 따지는 게 아니라, 자기 쪽 이슈를 자기가 먼저 인정하는 것. 이거 하나로 명절 뒤끝의 팔 할이 사라졌다. 반대로 배우자가 자기 부모에 대한 아쉬움을 먼저 꺼냈을 때 "그것 봐, 내가 뭐랬어"라고 받으면 그 제도는 그날로 끝난다. 먼저 말해준 용기를 고맙게 받는 게 유지 비결이다.

연휴 마지막 날 밤, 30분 정산 대화

명절이 끝나면 우리는 짧게 정산을 한다. 돈 정산이 아니라 감정 정산이다. 애들 재우고 맥주 한 캔씩 놓고, 이번 명절에 고마웠던 것 하나와 다음에 바꾸고 싶은 것 하나씩을 말한다. 딱 30분. 길게 하면 회의가 되고, 회의가 길어지면 싸움이 된다.

이 시간의 진짜 효과는 '넘어가지 않는다'는 데 있다. 명절에 쌓인 작은 서운함은 그냥 두면 사라지는 게 아니라 이자가 붙는다. 반년 뒤 다음 명절에 "당신 지난 추석에도 그랬잖아"로 복리 청구된다. 그 자리에서 원금만 정산하고 끝내는 게 훨씬 싸게 먹힌다.

연휴 마지막 날은 비워둔다: 명절증후군은 부부 공동의 적

몇 년 전까지 우리는 연휴 마지막 날까지 꽉 채워 일정을 잡았다. 처가에서 저녁까지 먹고 밤늦게 올라와서 다음 날 바로 출근. 그 다음 주 내내 부부 둘 다 방전 상태였고, 방전된 사람 둘이 붙어 있으면 별것 아닌 일로 부딪힌다. 명절증후군이라는 게 괜히 있는 말이 아니다. 몸이 힘들면 마음의 여유도 같이 사라진다.

지금은 연휴 마지막 하루를 무조건 우리 집에서 보내는 날로 비워둔다. 이번 추석도 그렇게 했다. 늦잠 자고, 밀린 빨래 돌리고, 애들은 거실에서 뒹굴게 두고, 배달 음식 시켜 먹는 날. 아무 일정 없는 하루가 있어야 일상으로 복귀가 된다. 양가 부모님께는 미리 "마지막 날은 애들 컨디션 조절해야 해서 일찍 올라가요"라고 말씀드린다. 처음엔 눈치가 보였는데, 몇 번 하니 자연스러운 패턴이 됐다.

이 하루의 또 다른 용도는 부부가 각자 혼자 있는 시간을 챙겨주는 거다. 명절 내내 우리는 남편, 아내, 사위, 며느리, 아빠, 엄마 역할을 쉬지 않고 수행한다. 역할에서 벗어난 시간이 한 톨도 없으면 사람이 예민해진다. 아내가 카페에 두 시간 다녀오는 동안 내가 애들을 보고, 내가 한 시간 산책하는 동안 아내가 커버해준다. 별거 아닌 것 같지만 이 두어 시간이 연휴의 체감 품질을 바꾼다.

그래도 싸웠다면: 복구가 예방보다 중요하다

이렇게 써놨지만 우리도 사람이라 다음 명절도 장담은 못 한다. 명절에 한 번도 안 싸우는 부부보다, 싸워도 빨리 복구하는 부부가 현실적인 목표라고 생각한다. 우리 집 복구 규칙은 단순하다. 애들 앞에서 시작된 언쟁은 애들 앞에서 화해까지 보여줄 것, 그리고 그날 안에 어느 한쪽이 먼저 말을 걸 것. 먼저 말 거는 사람이 지는 게 아니라 먼저 말 거는 사람이 어른이다.

우리 집 명절 평화 체크리스트 10개

정리 삼아, 우리 부부가 명절마다 점검하는 항목을 목록으로 남겨둔다. 다음 설에 나도 다시 볼 겸.

명절 일주일 전, 15분 부부회의로 용돈·선물·일정·체류 시간 확정
양가 용돈은 동일 금액 원칙, 명절 총예산 상한선 설정
선물은 고정 품목으로 열흘 전 온라인 주문, 미리 배송
방문 순서는 설·추석 번갈아, 체류 시간은 양가 비슷하게
각자 자기 부모 집에서 더 많이 움직이기 (전 부치기, 설거지, 애들 건사)
이동 중 역할 분담: 운전자와 뒷자리 통제자, 서로 훈수 금지
차 안에서 돈·부모님 등 예민한 주제 금지
배우자 부모에 대한 아쉬움은 그 집 자식이 먼저 말하기
연휴 마지막 날은 일정 없이 집에서 회복, 각자 혼자 시간 두어 시간씩
연휴 마지막 밤 30분, 고마웠던 것 하나 + 바꾸고 싶은 것 하나 정산 대화

열 개를 다 지키는 명절은 사실 우리도 드물다. 하지만 절반만 지켜져도 명절의 공기가 다르다. 특히 1번과 10번, 그러니까 시작 전 회의와 끝난 뒤 정산만큼은 빼먹지 않으려고 한다. 앞뒤가 정리되면 중간의 소란은 어떻게든 지나간다.

결혼 11년을 지나면서 알게 된 건, 명절 부부싸움의 본질은 시댁도 처가도 아니라는 거다. 결국 "당신은 내 편인가"라는 질문 하나다. 배우자가 자기 부모 앞에서 내 편을 들어줬다는 감각만 있으면, 전을 몇 시간 부치든 운전을 몇 시간 하든 버틸 만하다. 그 감각이 없으면 사소한 한마디에도 무너진다.

다음 명절, 양가 일정을 다 끝내고 돌아오는 차 안에서 배우자에게 한마디 건네보시라. "오늘 고생했어, 당신 덕에 잘 넘어갔다." 명절 부부싸움 예방책 중에 이것보다 가성비 좋은 건 아직 못 찾았다. 그리고 이번 추석에 미처 그 말을 못 했다면, 오늘 저녁이라도 늦지 않았다.

이미지 출처: Unsplash — Florian Siedl, Alexander Holmes, Alexandra Tran.

기준금리 3% 시대, 아이 셋 가장의 가계 재정 점검 기록 (대출·예적금·고정지출 총정리)

Lovizu — Wed, 9 Sep 2026 15:39:03 +0900

월급날 저녁, 아내가 은행 앱을 보다가 한마디 했다. "우리 대출 이자 또 올랐는데?" 알고 있었다. 알고 있었는데 애써 안 보고 있었다는 게 정확하다. 한국은행이 7월에 이어 8월에도 기준금리를 올리면서, 이제 기준금리는 3.00%가 됐다. 두 달 사이 0.5%포인트가 올랐다. 애 셋 키우는 외벌이에 가까운 가장 입장에서 이건 그냥 뉴스가 아니라 매달 통장에서 빠져나가는 숫자의 문제다.

그래서 이번 주말, 오랜만에 노트북을 켜고 가계 재정을 처음부터 끝까지 점검했다. 대출, 예적금, 고정지출, 아이들 교육비까지. 이 글은 그 기록이다. 재테크 전문가의 조언이 아니라, 금리 인상기를 처음 맞는 게 아닌 40대 직장인이 실제로 뭘 확인하고 뭘 바꿨는지에 대한 이야기다.

두 달 사이 두 번 오른 기준금리, 남 일이 아니었다

순서를 정리하면 이렇다. 한국은행 금융통화위원회는 지난 7월 16일 기준금리를 2.50%에서 2.75%로 올렸다. 3년 6개월 만의 첫 인상이었다. 그리고 8월 27일, 한 번 더 올려서 3.00%가 됐다. 두 번 연속 인상이다. 배경은 결국 물가다. 올해 2분기 소비자물가 상승률이 3%대로 올라섰고, 통계를 봐도 올해 1분기 가구당 월평균 가계지출이 424만 원으로 1년 전보다 4.2% 늘었다. 버는 건 그대로인데 나가는 게 늘고, 거기에 이자까지 오르는 구간에 들어선 거다.

금리가 오르면 뉴스에서는 늘 "이자 부담 증가"라는 표현을 쓰는데, 체감은 좀 다르다. 대출 있는 사람한테는 고통이고, 목돈을 굴려야 하는 사람한테는 오랜만의 기회다. 문제는 나 같은 40대 가장은 대부분 둘 다 해당된다는 점이다. 주택담보대출은 갚는 중이고, 아이들 학자금이나 노후 대비로 모아둔 돈도 굴려야 한다. 그래서 한쪽만 보면 안 되고 전체를 한 번에 점검해야 한다.

제일 먼저 확인한 것: 내 대출의 금리 조건

점검 1순위는 당연히 대출이었다. 확인할 건 세 가지였다.

첫째, 내 대출이 변동금리인지 고정금리인지. 당연히 알고 있어야 하는 건데, 의외로 헷갈리는 사람이 많다. 특히 5년 고정 후 변동으로 전환되는 혼합형은 지금 자기가 어느 구간에 있는지 모르는 경우가 흔하다. 나도 앱을 열어 계약 조건을 다시 확인했다. 금리 인하 가능성이 얘기되던 작년에 변동금리로 갈아탄 사람이 꽤 많았다고 한다. 실제로 올해 상반기에 변동금리 대출이 급증했다는 기사도 있었다. 그분들이 지금 제일 마음이 불편할 거다.

둘째, 금리 변동 주기와 다음 갱신일. 변동금리라도 이자가 바로 오르는 게 아니다. 보통 6개월 주기로 코픽스에 연동돼 갱신되니까, 내 대출이 언제 갱신되는지 알면 이자 인상이 언제 반영될지 미리 계산할 수 있다. 나는 다음 갱신일을 캘린더에 등록해뒀다. 별거 아닌 것 같지만, 갱신 월에 이자가 몇만 원 뛰는 걸 미리 알고 맞는 것과 모르고 맞는 것은 가계부 운영에서 차이가 크다.

셋째, 금리인하요구권. 승진했거나, 연봉이 올랐거나, 신용점수가 올랐다면 은행에 금리를 내려달라고 요구할 수 있는 제도다. 앱에서 신청하면 며칠 안에 결과가 나온다. 나는 재작년에 한 번 해서 0.2%포인트를 깎은 적이 있다. 거절당해도 손해 볼 게 없으니, 금리 인상기일수록 오히려 챙겨야 하는 카드다.

고정이냐 변동이냐를 두고 지금 갈아타야 하는지 묻는다면, 나는 함부로 답을 못 하겠다. 지금 시점 기준 주담대 고정금리는 대체로 연 4%대, 변동은 3% 후반에서 4% 초반으로 격차가 많이 좁혀진 상태다. 추가 인상이 이어질 거라 보면 고정이 마음 편하고, 이번 인상 사이클이 짧게 끝날 거라 보면 변동을 유지하며 버티는 선택지도 있다. 다만 중도상환수수료와 대환 비용까지 넣고 계산해봐야 하고, 이건 각자 대출 잔액과 잔여 기간에 따라 답이 완전히 달라진다. 내가 한 일은 은행 앱의 대환 시뮬레이션으로 숫자를 뽑아서 엑셀에 정리해둔 것까지다. 결정은 다음 금통위(10월)를 보고 하기로 했다.

이자가 실제로 얼마나 늘어나는지 계산해보면

막연하게 "이자가 오른다"고 불안해하는 것보다 숫자로 확인하는 게 낫다. 계산은 단순하다. 변동금리 대출 잔액에 금리 인상 폭을 곱하면 연간 추가 이자가 나온다.

예를 들어 변동금리 주택담보대출 잔액이 2억 원이고, 이번 기준금리 인상분 0.5%포인트가 대출금리에 그대로 반영된다고 가정하면, 연간 추가 이자는 100만 원. 월로 나누면 8만 원이 조금 넘는다. 물론 코픽스 연동이라 기준금리 인상분이 그대로 다 옮겨지는 건 아니고 시차도 있지만, 방향 자체는 분명하다. 월 8만 원이면 우리 집 기준으로 아이 한 명 학원비 한 과목 값이다. 그렇게 환산하니 숫자가 확 와닿았다.

반대로 이 계산을 해보면 과도한 공포에서도 벗어난다. 잔액이 5천만 원이라면 같은 조건에서 월 2만 원 수준이다. 부담이지만 가계가 무너질 숫자는 아니다. 중요한 건 내 대출 잔액과 금리 조건으로 직접 계산해보는 것이다. 뉴스 헤드라인의 공포와 내 가계부의 현실은 생각보다 거리가 있는 경우가 많다.

예적금은 오랜만에 갈아탈 맛이 난다

대출 쪽이 아픈 얘기였다면 이쪽은 그나마 즐거운 얘기다. 기준금리가 오르면 예적금 금리도 따라 오른다. 은행들이 슬금슬금 수신금리를 올리는 게 보이기 시작했다.

내가 실제로 한 일은 세 가지다.

파킹통장 금리 비교. 생활비 통장과 비상금을 넣어두는 파킹통장은 금리 인상이 가장 빨리 반영되는 곳 중 하나다. 주거래 은행이라는 이유로 낮은 금리에 묵혀두고 있었는데, 인터넷은행 몇 곳을 비교해보니 차이가 제법 났다. 비상금 규모가 1천만 원이라면 금리 1%포인트 차이는 1년에 세전 10만 원이다. 치킨 네다섯 마리 값이지만, 앱에서 10분이면 옮길 수 있는 돈이기도 하다.

만기 임박 예금의 재예치 전략. 마침 10월에 만기가 돌아오는 예금이 하나 있다. 예전 같으면 만기일에 자동 재예치로 뒀을 텐데, 이번엔 다르게 하기로 했다. 추가 인상 가능성이 남아 있는 상황에서는 1년 만기로 다 묶는 것보다, 일부는 파킹통장이나 3~6개월 단기 예금으로 두고 금리 흐름을 본 뒤에 장기로 묶는 게 낫겠다는 판단이다. 이른바 풍차돌리기까지는 아니어도, 만기를 분산해두면 금리가 더 오를 때 대응할 여지가 생긴다.

청약통장과 아이들 통장 점검. 아이 셋 이름으로 넣고 있는 적금과 청약통장도 이번에 같이 확인했다. 오래전에 가입해둔 상품이라 금리가 낮은 것도 있었는데, 상품에 따라 갈아타는 게 나은 경우도 있고 가입 시점의 혜택 때문에 유지가 나은 경우도 있다. 이건 일괄적으로 답이 없어서 하나씩 열어봤다. 셋 다 열어보는 데 생각보다 시간이 걸렸다. 애가 셋이면 통장도 세 배다.

고정지출 다이어트: 이자 오른 만큼 어디서 뺄 것인가

이자가 월 몇만 원 늘어난다면, 그 몇만 원을 어디선가 만들어야 한다. 소득을 당장 늘릴 수 없으니 답은 고정지출이다. 이번에 가계부를 3개월 치 돌려보면서 발견한 것들이 있다.

구독 서비스. OTT 3개, 음악 스트리밍, 클라우드 저장소, 그리고 언제 가입했는지 기억도 안 나는 앱 구독 2개. 합쳐보니 월 7만 원 가까이 나가고 있었다. OTT는 가족들과 상의해서 하나만 남기고 정리했다. 보고 싶은 게 생기면 그 달만 구독하면 된다. 이것만으로 월 4만 원 가까이 줄었다.

통신비. 약정이 끝난 지 몇 달 지난 회선이 있었다. 알뜰폰 요금제와 비교해보니 나 혼자만 옮겨도 월 3만 원 이상 차이가 났다. 결합할인 때문에 계산이 복잡해지긴 하는데, 가족 전체 통신비를 놓고 계산기를 두드려볼 가치는 충분했다.

보험. 제일 조심스러운 항목이다. 보험은 해지가 능사가 아니라서, 리모델링한다고 섣불리 갈아탔다가 오히려 손해 보는 경우도 많다. 나는 이번에 정리만 했다. 어떤 보험이 있고, 보장이 뭐고, 월 얼마가 나가는지 한 장짜리 표로 만들었다. 중복 보장 하나가 눈에 띄어서 그것만 전문가 상담을 받아보기로 했다.

여유 자금이 생기면: 빚부터 갚을까, 저축부터 할까

점검하다 보니 자연스럽게 이 질문에 닿았다. 상여금이든 성과급이든 목돈이 생겼을 때, 대출을 갚는 게 맞나 예금을 드는 게 맞나.

원칙은 간단하다. 대출금리가 예금금리보다 높으면 갚는 게 이득이다. 지금처럼 주담대 금리가 4% 안팎이고 예금금리가 그보다 낮다면, 세금까지 감안할 때 상환 쪽이 수치상 유리한 경우가 대부분이다. 다만 현실에서는 숫자만으로 결정하면 안 되는 변수가 두 개 있다.

하나는 중도상환수수료다. 대출 받은 지 3년이 안 됐다면 수수료가 붙는 경우가 많으니, 수수료율과 절감되는 이자를 비교해봐야 한다. 다른 하나는 비상금이다. 빚 갚는 데 몰빵해서 통장을 비워두면, 정작 급한 일이 터졌을 때 더 비싼 신용대출을 받게 된다. 아이 셋 집은 급한 일이 정말 수시로 터진다. 응급실 한 번, 갑작스러운 가전 수리 한 번이면 몇십만 원이 그냥 나간다. 그래서 우리 집은 생활비 3개월 치 비상금은 무조건 지키고, 그 이상의 여유가 생겼을 때만 중도상환을 검토하기로 했다.

이번 금리 인상기에 한 가지 달라진 게 있다면, 예금금리가 올라오면서 "갚기 vs 모으기"의 계산이 예전보다 훨씬 팽팽하게 갈린다는 점이다. 제로금리 시절에는 무조건 빚부터 갚는 게 정답에 가까웠는데, 지금은 각자의 대출금리와 세후 예금금리를 직접 대보면 의외로 박빙인 경우도 나온다. 계산기를 두드려볼 이유가 하나 더 생긴 셈이다.

물가 3% 시대의 아이 셋 교육비

사실 우리 집 가계부에서 이자보다 무서운 건 교육비다. 통계에서도 자녀 있는 가구의 교육비 부담은 매년 상위권이다. 애들이 크면서 학원비는 물가상승률보다 빠르게 오르는 느낌인데, 이건 체감만이 아니라 실제로 그런 항목이 많다.

올해 1분기 가계동향을 봐도 소비지출 증가율(5.3%)이 전체 가계지출 증가율보다 높다. 우리 집 가계부를 3개월 치 들여다봤더니 식비와 교육비가 증가분의 대부분을 차지하고 있었다. 아이 셋이 밥 먹는 양이 달라지는 속도와 학원비 인상 주기는 금리와 무관하게 온다. 그래서 가계부에서 조절 가능한 항목과 불가능한 항목을 먼저 나누는 게 순서다.

금리 인상기라고 애들 학원을 끊는 건 현실적으로 어렵다. 대신 우리 부부가 정한 원칙은 두 가지다. 하나, 교육비 총액에 상한선을 정한다. 소득의 일정 비율을 넘지 않도록 상한을 정해두고, 새 학원을 추가하려면 뭔가를 빼는 구조로 간다. 둘, 애들 명의 저축은 건드리지 않는다. 가계가 빠듯해지면 제일 먼저 손이 가는 게 아이들 적금인데, 그건 마지막의 마지막까지 손대지 않기로 했다. 대신 위에서 말한 구독료, 통신비 같은 어른들 지출부터 줄인다.

내가 정리한 금리 인상기 가계 점검 체크리스트

이번 주말 점검을 하면서 정리한 목록이다. 순서대로 하면 두세 시간이면 끝난다.

내 대출의 금리 유형(고정/변동/혼합) 확인
변동금리라면 갱신 주기와 다음 갱신일 캘린더 등록
금리인하요구권 신청 가능 여부 확인 (승진, 연봉 인상, 신용점수 상승 시)
대환 시뮬레이션 돌려보고 숫자만 정리 (결정은 천천히)
파킹통장 금리 비교, 비상금 이동
만기 도래 예금은 자동 재예치 해제, 만기 분산 전략 검토
구독 서비스 전수 조사 후 정리
약정 끝난 통신 회선 알뜰폰 비교
보험은 해지 대신 한 장짜리 현황표 만들기
교육비 상한선 부부 합의

거창한 재테크는 하나도 없다. 그런데 이 열 가지를 하고 나니 마음이 한결 가벼워졌다. 금리가 오르는 건 내가 어쩔 수 없지만, 그 파도에 어떻게 올라탈지는 준비할 수 있다는 감각. 가장한테는 그게 중요하다.

마치며: 금리는 사이클이다

15년 넘게 직장 생활을 하면서 금리 인상기를 몇 번 지나왔다. 그때마다 느끼는 건 같다. 금리는 사이클이고, 오르막이 있으면 내리막이 있다. 중요한 건 오르막에서 무리한 포지션을 잡지 않는 것, 그리고 내 가계의 숫자를 내가 정확히 알고 있는 것이다.

10월 금통위에서 한 번 더 올릴지, 여기서 쉬어갈지는 모르겠다. 전문가들 전망도 갈린다. 다만 어느 쪽이든 우리 집 가계부는 이제 준비가 됐다. 이 글을 읽는 분들도 이번 주말, 두세 시간만 내서 대출 조건과 예금 금리부터 확인해보시길 권한다. 남의 전망을 듣는 것보다 내 숫자를 아는 게 먼저다.

※ 이 글은 개인의 경험을 정리한 것으로, 특정 금융상품의 추천이나 투자 조언이 아닙니다. 대출 대환, 예적금 가입, 보험 변경은 각자의 상황에 맞게 금융사 상담을 거쳐 결정하시기 바랍니다. (기준금리 등 수치: 한국은행 금융통화위원회 2026년 7월 16일, 8월 27일 결정 기준)
이미지 출처: Unsplash — Jakub Żerdzicki, Katie Harp, 2H Media

지난주 테크 뉴스 핵심 정리: GPT-6 아스트라, 제미나이 3.8, 반도체 관세 압박

Lovizu — Tue, 8 Sep 2026 15:03:16 +0900

이번 주는 프런티어 모델이 이틀 간격으로 두 방 터졌다. 오픈AI가 GPT-6 아스트라를 내놨고, 그 전날 구글은 제미나이 3.8 플래시를 사이버 보안 특화 모델과 함께 밀어냈다. 그 와중에 미국 상무장관은 삼성전자와 SK하이닉스를 콕 찍어 관세 경고를 날렸고, 보안 쪽에서는 크롬 제로데이부터 개발자 도구 체인까지 실제 악용 사례가 줄줄이 터졌다. 모델 경쟁, 보안, 반도체 지정학이 같은 주에 겹치니 뉴스 읽는 것만으로도 일주일이 갔다. 지난 일주일(9월 1일~7일) 뉴스 중 실무자 입장에서 알아둘 가치가 있는 것들만 추렸다.

오픈AI GPT-6 아스트라 출시, 이번엔 "컴퓨터를 쓰는 AI"다

9월 3일(현지시간) 오픈AI가 차세대 모델 GPT-6 아스트라(Astra)를 공개하고 단계적 롤아웃을 시작했다. CNBC와 와이어드 보도를 종합하면, 이번 모델의 핵심은 벤치마크 점수가 아니라 컴퓨터와 웹을 직접 조작하는 능력이다. 오픈AI 스스로 "컴퓨터와 웹 내비게이션에서 최고 수준"이라고 못 박았다.

흥미로운 건 출시 전 분위기였다. 로이터가 9월 1일에 "오픈AI가 차기 모델이 너무 강력해서 추가 안전장치가 필요하다고 판단했다"고 보도했고, 같은 날 오픈AI는 'Path to Astra'라는 안전 프레임워크 문서를 먼저 올렸다. 모델 발표보다 안전장치 발표가 먼저 나온 셈이다. 마케팅이라고 보는 시각도 있지만, 시스템 카드를 별도 도메인까지 파서 공개한 걸 보면 에이전트형 모델의 리스크를 진짜로 의식하고 있다는 인상이다.

실무 관점에서는 이렇게 읽었다. 작년까지 "AI에게 코드를 짜게 한다"가 화두였다면, 이제는 "AI에게 내 컴퓨터를 맡긴다"가 표준 시나리오로 넘어가고 있다. 브라우저를 조작하고 여러 단계를 알아서 수행하는 모델이 기본값이 되면, 우리가 만드는 서비스도 '사람이 클릭하는 UI'만이 아니라 '에이전트가 접근하는 인터페이스'를 같이 고민해야 한다. 봇 차단 로직 하나만 봐도 그렇다. 지금까지는 크롤러를 막는 게 정답이었지만, 사용자를 대신해서 온 에이전트까지 막으면 이제 고객을 막는 게 된다. 남 일이 아니라 설계 요구사항이 바뀌는 얘기다.

같은 주에 오픈AI는 ChatGPT를 의료 정보 소스와 연동하는 기능(9월 1일)도 조용히 내놨고, 9월 29일 샌프란시스코 데브데이 2026 일정도 공개했다. 모델 출시 전후로 안전 문서, 제품 연동, 개발자 행사 예고까지 한 주에 몰아넣는 걸 보면 롤아웃 자체가 잘 짜인 캠페인이다. 개발자용 세부 스펙과 API 가격은 데브데이에서 더 풀릴 가능성이 높으니, 당장 프로덕션 모델을 갈아탈 계획이라면 이달 말까지는 지켜보는 게 낫다고 본다.

구글 제미나이 3.8 플래시, 그리고 정부 전용 '사이버' 모델

하루 앞선 9월 2일 구글 딥마인드는 제미나이 3.8 플래시와 3.8 플래시 사이버(Cyber)를 동시에 내놨다. 3.7 플래시가 나온 지 3주 만이고, 6주 사이 플래시 계열만 세 번째 릴리즈다. 요즘 구글의 미드티어 모델 회전 속도는 솔직히 무섭다.

일반용 3.8 플래시는 소프트웨어 엔지니어링, 에이전트 작업, 다단계 추론 강화가 골자이고 제미나이 API, AI 스튜디오, 안드로이드 스튜디오, 자사 에이전트 IDE인 안티그래비티까지 출시 당일 전부 열렸다. 가격은 올해 말까지 100만 토큰당 입력 0.75달러, 출력 3.75달러. 우리 팀도 배치성 작업은 플래시급 모델로 내리고 어려운 것만 상위 모델로 올리는 구조로 바꾸는 중인데, 이 가격이면 "일단 플래시로 돌려보고 안 되면 상위 모델" 전략이 더 굳어질 수밖에 없다. 플래그십 한 방보다 미드티어를 빠르게 굴리는 쪽이 실제 API 매출을 만든다는 걸 구글이 제일 잘 이해하고 있는 것 같다.

플래시 계열이 3주 간격으로 나오다 보니 팀 입장에서는 모델 버전 고정 전략도 다시 생각하게 된다. 우리는 프로덕션 프롬프트를 특정 버전에 핀 해두고 새 버전이 나오면 회귀 테스트 세트를 돌려 통과해야 갈아타는 방식으로 정리했는데, 이 주기가 3주면 테스트 자동화 없이는 못 따라간다. 모델 릴리즈 속도가 빨라질수록 "평가 파이프라인이 곧 경쟁력"이라는 말이 체감된다.

진짜 눈에 띈 건 사이버 쪽이다. 취약점 탐지와 자동 패치에 특화된 모델인데, 일반 공개를 하지 않고 '페어윈드(Fairwind)'라는 심사 프로그램을 통해 정부와 핵심 인프라 운영자에게만 제공한다. 구글 크롬 보안팀 기준으로 크롬 버그 패치 품질이 훨씬 큰 상용 모델 대비 2.6배 좋았고, 20개 언어를 아우르는 내부 취약점 벤치마크에서 성공률 70%를 넘겼다고 한다. 같은 코어를 놓고 안전 튜닝과 접근 권한만 다르게 가져가는 '한 모델 두 봉투' 방식이 앞으로 위험 역량 모델의 배포 표준이 될 것 같다. 능력은 만들되 아무에게나 안 주는 것. AI 랩들이 결국 같은 결론으로 수렴하고 있다.

앤스로픽, 35조 원짜리 클라우드 계약과 삼성 반도체 설계 진출

앤스로픽은 이번 주에 인프라와 영업 양쪽에서 뉴스를 만들었다. 월스트리트저널 보도(9월 1일)에 따르면 엔비디아가 투자한 네오클라우드 업체 람다(Lambda)와 350억 달러 규모의 클라우드 컴퓨팅 계약을 맺었다. 텍사스에 짓는 약 350MW급 데이터센터에서 클로드, 특히 빠르게 크는 클로드 코드용 용량을 공급받는 구조다. 재미있는 건 부지 임차인이 엔비디아 본인이라는 점이다. GPU 만드는 회사가 데이터센터 임대까지 쥐고 있으니, AI 인프라 돈의 흐름이 얼마나 엔비디아 중심으로 돌아가는지 보여주는 장면이다.

국내 뉴스도 있었다. 매일경제(9월 1일)에 따르면 앤스로픽이 삼성전자 반도체 설계 업무에 클로드를 시험 적용 중이다. 연구원들이 직접 하던 설계 특화 소프트웨어 작업을 자동화하는 시도라는데, 코딩 보조를 넘어 EDA 영역까지 AI가 들어가는 사례다. 앤스로픽코리아 쪽은 "성능 대비 가격이 12~18개월 새 최소 10배 낮아졌다"고도 했다. 가격이 이 속도로 떨어지면 "AI 도입은 비싸서 못 한다"는 말은 올해 안에 설득력을 잃는다. 문제는 비용이 아니라 어디에 붙일지 아는 도메인 지식이라는 걸, 현장에 있는 사람일수록 실감할 거다. 십 년 넘게 같은 도메인에서 굴러온 사람이 AI를 제일 잘 쓰게 된다는 아이러니를 요즘 매일 본다. 연차 진급이 부담스러운 연차가 아니라, 자기 도메인을 AI에게 설명할 수 있느냐가 시니어의 새 기준이 되어가는 느낌이다.

패치 안 하면 당하는 한 주였다: 크롬 제로데이부터 JFrog, LiteLLM까지

보안 쪽은 이번 주가 유난히 험했다. 서버 운영하는 입장에서 남 일이 아닌 것들만 추린다.

먼저 크롬 V8 제로데이(CVE-2026-85046). V8 엔진의 타입 혼동 취약점으로, 악성 웹페이지를 여는 것만으로 샌드박스 안에서 코드 실행이 가능하다. 구글이 9월 3일 스테이블 업데이트로 패치했는데 이미 실제 공격이 확인된 상태였고, 올해만 여섯 번째 크롬 제로데이다. 제보한 외부 연구자에게 돌아간 바운티가 1,000달러라는 게 어쩌면 이번 주 최고의 블랙코미디다. 공격자 손에 들어가면 수억 원짜리 무기가 되는 버그 값이 그렇다. 어쨌든 CISA는 9월 6일 KEV(알려진 악용 취약점) 목록에 올렸다. 회사 PC든 집 PC든 크롬 버전 확인부터 하자. 재시작 한 번이면 끝나는 일을 미루다 당하는 게 제일 억울하다.

개발자 스택 쪽이 더 아프다. JFrog 아티팩토리 인증 우회(CVE-2026-82329)는 8월 28일 공개 후 나흘 만인 9월 1일부터 실제 악용이 관측됐다. 기본 설정에서 무인증 공격자가 관리자 토큰을 만들어낼 수 있는 크리티컬급이다. 사내 아티팩트 저장소가 뚫리면 공급망 전체가 오염되는 거라, 셀프호스팅 중이라면 버전 확인이 급하다. CISA가 9월 2일 KEV에 한꺼번에 올린 7건에는 LiteLLM 인증 취약점(CVE-2026-59822)과 파이썬 Starlette의 요청 스머글링도 포함됐다. LLM 프록시로 LiteLLM 쓰는 팀이 꽤 많을 텐데, AI 인프라 도구도 이제 공격 표면이라는 걸 확인시켜 준 사례다. 이 밖에 SonicWall SMA1000의 CVSS 10점짜리 SSRF(CVE-2026-83548)도 실제 악용 중이고, 9월 5일에는 폴란드 CERT가 인터넷에 노출된 미크로틱 라우터가 SSH 경유 무인증 장악을 당하고 있다고 경보를 냈다. 공통 교훈은 하나다. 공개에서 악용까지 걸리는 시간이 이제 '며칠'이 아니라 '하루'다.

월요일 출근하면 할 일을 정리하면 이렇다. 크롬은 전사 업데이트 강제(재시작 포함), 셀프호스팅 아티팩토리는 버전 확인 후 즉시 패치, LiteLLM 프록시는 인증 설정과 노출 범위 점검, VPN 장비(SonicWall 계열)는 벤더 권고 확인. 특히 아티팩트 저장소와 LLM 프록시는 CI/CD 토큰과 API 키가 지나다니는 길목이라, 뚫리면 피해 범위 산정부터가 일이 된다. 패치는 지루하지만 장애 대응보다는 훨씬 싸다.

삼성·SK 겨눈 관세 경고, 뒤에서 치고 올라오는 중국 D램

반도체는 앞뒤로 압박받는 모양새다. 앞에서는 미국이다. 하워드 러트닉 미 상무장관이 9월 4일 미국 내 생산이 부족하면 표적 관세를 물릴 수 있다며 삼성전자와 SK하이닉스를 직접 거명했다(중앙일보). 삼성은 이미 텍사스 테일러에 370억 달러 이상, SK하이닉스는 인디애나 HBM 후공정에 40억 달러를 투자하고 있는데도 더 내놓으라는 압박이다. 데이터센터 서버 같은 완제품까지 관세 대상을 넓히는 방안도 거론된다니, 이건 반도체 회사만의 문제가 아니라 서버 도입 비용, 환율, 결국 우리 회사 인프라 예산까지 닿는 얘기다.

뒤에서는 중국이다. 서울경제(9월 3일)에 따르면 중국 CXMT가 글로벌 D램 점유율 10%를 돌파했다. 정부 보조금과 내수를 등에 업고 증설 중이고, HBM3E 양산과 LPDDR6 개발까지 밀어붙이고 있다. 장비와 부품 공급망까지 자체적으로 국산화하는 중이라 제재로 시간을 버는 것도 한계가 있다. 범용 D램에서 가격으로 치고 올라오는 동안 한국은 미국 투자 압박으로 손발이 묶이는, 전형적인 샌드위치 구도다. 슈퍼사이클 호황 뉴스에 가려져 있지만 구조적으로는 편치 않은 흐름이다.

그나마 밝은 쪽은 생태계다. 한미반도체가 세미콘 타이완 2026에서 AI 반도체용 2.5D 패키징 장비 5종을 공개했는데 그중 4종은 이미 글로벌 파운드리와 OSAT에 양산용으로 들어가 있고(뉴스1, 9월 2일), 하나마이크론·LB세미콘·두산테스나 같은 후공정 업체들도 흑자 전환과 증설 소식이 이어졌다. 대기업 둘만 쳐다보던 국내 반도체 판이 팹리스-디자인하우스-후공정 분업 구조로 넓어지는 건 길게 보면 체질 개선이다.

짧게 볼 뉴스

중국 즈푸AI(Z.AI)의 API 매출이 급증하며 중국 AI 업체들도 개발자 API가 돈이 된다는 걸 증명하기 시작했다(차이신). 모델 가격 경쟁이 극심한 중국 시장에서 맞춤 구축보다 API 장사가 남는다는 신호라 방향 자체는 글로벌 트렌드와 같다. TP-Link는 첫 와이파이8 라우터 라인업을 공개했는데 이론상 무선 19Gbps급이다. 집 공유기 바꿀 명분이 또 생겼지만, 우리 집 공유기도 아직 멀쩡한데 인터넷 요금제가 병목인 걸 아는 애 셋 아빠 입장에서는 일단 참기로 했다. 그리고 오픈AI 데브데이 2026이 9월 29일 샌프란시스코에서 열린다. GPT-6 아스트라 출시 직후의 데브데이라 개발자 도구 쪽 발표가 몰릴 가능성이 크다.

마무리

매주 월요일 아침마다 이런 정리를 하다 보니 나름의 요령이 생겼다. 뉴스는 흘러가게 두고, "내 일에 뭐가 바뀌는가"를 기준으로 세 줄만 남기는 것이다. 이번 주 세 줄은 이렇다. 에이전트가 쓰는 인터페이스를 설계 요구사항으로 받아들일 것, 미드티어 모델 중심으로 비용 구조를 다시 짤 것, 그리고 패치 사이클을 '주 단위'에서 '일 단위'로 당길 것.

이번 주 키워드는 셋이다. 에이전트 모델의 세대교체, 위험 역량의 선별 배포, 그리고 반도체 지정학. 다음 주는 GPT-6 아스트라의 실사용 후기가 쏟아질 시점이고, 이달 말 오픈AI 데브데이(9월 29일)까지 개발자 뉴스는 계속 시끄러울 예정이다. 크롬 업데이트, 오늘 꼭 하자.

도커 디스크 용량 100% 장애 해결기: overlay2 정리부터 로그 로테이션까지

Lovizu — Sun, 6 Sep 2026 11:11:58 +0900

금요일 밤 11시에 배포가 실패했다. CI는 초록불인데 서버에서 컨테이너가 안 뜬다. 에러 메시지는 딱 한 줄. no space left on device. 디스크가 꽉 찬 것이다. 코드 몇 줄 바꿨다고 디스크가 찰 리는 없는데, 확인해 보니 루트 파티션 사용률이 100%였다. 범인은 도커였다.

이런 일을 한 번이라도 겪어본 분이라면 알 것이다. 이게 한 번으로 안 끝난다는 걸. 임시로 지우고 넘어가면 몇 달 뒤에 똑같은 알람이 또 울린다. 그래서 이번에 원인부터 재발 방지까지 한 번에 정리했다. 같은 장애를 겪고 있는 분들에게 시간을 아껴드리고 싶어서 쓰는 글이다.

사진: Kevin Ache / Unsplash

증상: 디스크 100%, 로그인도 버벅거린다

증상은 단순했다. 배포 실패, 컨테이너 재시작 실패, 심하면 SSH 접속까지 버벅거린다. 디스크가 100%가 되면 도커만 문제가 아니라 시스템 전체가 이상해진다. 리눅스는 임시 파일 하나 못 쓰는 상태가 되면 생각보다 많은 것이 멈춘다.

먼저 뭐가 먹고 있는지부터 확인한다.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G   29G    0G 100% /

루트가 꽉 찼으면 다음은 어디가 큰지 추적한다. 도커를 쓰는 서버라면 십중팔구 여기다.

$ sudo du -sh /var/lib/docker/*
1.2G    /var/lib/docker/containers
19G     /var/lib/docker/overlay2
2.7G    /var/lib/docker/tmp
850M    /var/lib/docker/volumes

내 경우 overlay2가 19기가였다. 30기가짜리 서버에서 도커 혼자 20기가 넘게 쓰고 있었던 셈이다. 도커 입장에서 보면 어디에 얼마나 쓰는지는 이 명령이 더 보기 편하다.

$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          24        3         14.2GB    12.1GB (85%)
Containers      5         3         1.1GB     0.9GB
Local Volumes   8         2         850MB     620MB
Build Cache     113       0         3.4GB    3.4GB

RECLAIMABLE 컬럼이 핵심이다. 회수 가능한 용량, 즉 지금 아무도 안 쓰는데 자리만 차지하는 데이터다. 이미지 85%가 회수 가능이라는 건 배포할 때마다 새 이미지를 받아놓고 옛날 이미지를 한 번도 안 지웠다는 뜻이다. 뜨끔했다.

overlay2는 왜 이렇게 커지는가

overlay2는 도커의 기본 스토리지 드라이버다. 이미지 레이어, 컨테이너의 쓰기 레이어가 전부 여기 쌓인다. 도커 이미지는 레이어 구조라서, 배포를 반복하면 예전 이미지의 레이어들이 계속 남는다. 태그가 latest 하나뿐이어도 실제 레이어는 배포 횟수만큼 누적된다.

여기에 세 가지가 더 얹힌다.

첫째, 빌드 캐시. 서버에서 직접 docker build를 하는 구조라면 빌드 캐시가 조용히 몇 기가씩 쌓인다. 위의 예에서도 3.4기가였다.

둘째, 중지된 컨테이너. docker run을 --rm 없이 돌리고 지우지 않으면 죽은 컨테이너의 쓰기 레이어가 그대로 남는다.

셋째, 그리고 제일 악질인 컨테이너 로그. 이건 뒤에서 따로 다룬다. 진짜 범인은 이 녀석이었다.

응급 처치: prune 한 방, 단 옵션은 알고 쓰자

일단 서비스를 살려야 하니 미사용 리소스부터 정리한다.

$ docker system prune -a -f

이 한 줄로 19기가짜리 overlay2가 4기가대로 내려왔다. 다만 옵션 의미는 정확히 알고 써야 한다. 나도 처음엔 아무 생각 없이 복붙했다가 식겁한 적이 있다.

docker system prune: 중지된 컨테이너, 미사용 네트워크, dangling 이미지, 빌드 캐시 삭제
-a: 여기에 더해 실행 중인 컨테이너가 참조하지 않는 모든 이미지 삭제
--volumes: 미사용 익명 볼륨까지 삭제

주의할 점 두 가지. 하나, 컨테이너가 내려가 있는 상태에서 -a를 돌리면 그 컨테이너의 이미지도 미사용으로 간주되어 지워진다. 다음 기동 때 이미지를 처음부터 다시 받아야 한다. 프라이빗 레지스트리가 느리거나 이미지가 크면 복구 시간이 확 늘어난다. 둘, --volumes는 신중하게. DB 데이터를 익명 볼륨에 넣어둔 낡은 구성이라면 데이터가 날아갈 수 있다. 볼륨 정리는 docker volume ls로 목록을 눈으로 확인한 뒤에 하는 게 맞다.

운영 중인 서버라면 필터를 걸어서 최근 것은 남기는 쪽이 안전하다.

# 48시간 넘게 미사용인 것만 정리
$ docker system prune -f --filter "until=48h"

사진: Taylor Vick / Unsplash

진짜 범인: 무한히 자라는 컨테이너 로그

prune으로 급한 불은 껐는데, containers 디렉터리에 1기가 넘는 게 남아 있었다. 파고 들어가 보니 로그 파일 하나가 900메가였다.

$ sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -rh | head -3
912M    /var/lib/docker/containers/8ac2.../8ac2...-json.log
210M    /var/lib/docker/containers/f31b.../f31b...-json.log

도커의 기본 로그 드라이버인 json-file은 기본값이 무제한이다. max-size 기본값이 -1, 로테이션 없음. 컨테이너가 stdout으로 찍는 모든 로그가 파일 하나에 영원히 쌓인다. 애플리케이션이 디버그 로그라도 켜져 있으면 성장 속도가 무섭다. 도커를 몇 년 썼는데 이 기본값을 이번에 처음 제대로 봤다. 공식 문서에 떡하니 적혀 있는데도 장애를 겪고 나서야 읽게 되는 게 사람이다.

당장 급하면 로그 파일을 비워서 공간을 회수할 수 있다. 파일을 rm으로 지우면 안 되고(프로세스가 잡고 있어서 공간이 반환되지 않는다) truncate로 비운다.

$ sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

물론 이건 응급 처치다. 로그는 다시 자란다.

재발 방지 1: daemon.json에 로그 로테이션 걸기

근본 대책은 데몬 레벨에서 로그 상한을 거는 것이다. /etc/docker/daemon.json에 다음을 넣는다. 파일이 없으면 만들면 된다.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

컨테이너당 로그를 10메가짜리 파일 3개, 최대 30메가로 제한하는 설정이다. 주의할 점은 값들을 전부 문자열로 써야 한다는 것. max-file을 숫자 3으로 쓰면 데몬이 안 뜬다. 그리고 max-file은 max-size가 같이 설정되어 있어야만 동작한다.

설정 후 도커를 재시작하는데, 여기 함정이 하나 더 있다. 이미 떠 있는 컨테이너에는 적용되지 않는다. 새로 만들어지는 컨테이너부터 적용된다. 그래서 컴포즈를 쓴다면 재생성까지 해줘야 한다.

$ sudo systemctl restart docker
$ docker compose up -d --force-recreate

# 적용 확인
$ docker inspect --format '{{.HostConfig.LogConfig}}' my-app
{json-file map[max-file:3 max-size:10m]}

서비스별로 다르게 주고 싶으면 컴포즈 파일에서 logging 블록으로 오버라이드하면 된다. 로그가 많은 서비스만 따로 조이는 식이다.

services:
  api:
    image: my-api
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "5"

참고로 도커 공식 문서는 디스크 효율을 위해 local 드라이버를 권장한다. local은 압축과 로테이션이 기본으로 켜져 있다(파일당 20메가 5개). 다만 내부 바이너리 포맷이라 Filebeat처럼 로그 파일을 직접 읽는 수집기와는 궁합이 안 맞는다. docker logs 명령으로만 로그를 본다면 local로 갈아타는 것도 좋은 선택이다.

재발 방지 2: 정리를 크론에 맡긴다

사람이 기억해서 정리하는 방식은 반드시 실패한다. 나는 이번에 크론에 넣어버렸다.

# crontab -e
# 매일 새벽 4시, 48시간 이상 미사용 리소스 정리
0 4 * * * docker system prune -f --filter "until=48h"

# 일요일 새벽 5시, 일주일 이상 미사용 이미지까지 정리
0 5 * * 0 docker image prune -af --filter "until=168h"

빌드를 서버에서 직접 하는 구성이라면 빌드 캐시 상한도 같이 걸어두면 좋다.

# 빌드 캐시를 2GB 이내로 유지
$ docker buildx prune -f --max-used-space 2GB

그리고 디스크 사용률 알람. 거창한 모니터링 없이도 크론에 쉘 스크립트 하나면 된다. 사용률 85% 넘으면 슬랙 웹훅으로 쏘게 해뒀다. 디스크 장애는 예고 없이 오는 게 아니라, 알람을 안 걸어놔서 예고를 못 들은 것뿐이다.

재발 방지 3: 애초에 이미지를 작게 만든다

정리를 아무리 잘해도 이미지 하나가 1.5기가면 근본적으로 힘들다. 우리 서비스의 Node 기반 이미지가 딱 그랬다. 손댄 건 두 가지다.

하나는 베이스 이미지를 alpine 계열로 바꾼 것. node:20에서 node:20-alpine으로 바꾸는 것만으로 베이스가 1기가 가까이에서 100메가대로 내려간다. glibc 의존성이 있는 네이티브 모듈은 빌드가 깨질 수 있으니 CI에서 한 번 돌려보고 넘어가야 하지만, 웬만한 웹 서비스는 문제없이 넘어간다.

다른 하나는 멀티 스테이지 빌드. 빌드 도구와 devDependencies는 빌드 스테이지에만 두고, 최종 스테이지에는 산출물과 프로덕션 의존성만 복사한다.

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
CMD ["node", "dist/main.js"]

이 두 가지로 이미지가 1.5기가에서 400메가 밑으로 내려왔다. 이미지가 작아지면 overlay2에 쌓이는 레이어도, 배포 때 받는 시간도, 레지스트리 비용도 같이 줄어든다. 디스크 정리를 반복하는 것보다 이쪽이 훨씬 남는 장사다.

사진: Markus Spiske / Unsplash

정리: 순서대로 하면 되는 체크리스트

같은 상황을 만난 분을 위해 순서대로 요약한다.

현황 파악: df -h → sudo du -sh /var/lib/docker/* → docker system df
응급 처치: docker system prune -a -f (내려간 컨테이너의 이미지가 지워질 수 있음에 주의, --volumes는 볼륨 목록 확인 후에)
로그 확인: containers 밑 *-json.log 크기 확인, 크면 truncate로 비우기
재발 방지: daemon.json에 max-size/max-file 설정 → 도커 재시작 → 컨테이너 재생성(--force-recreate)까지 해야 적용
자동화: prune 크론 등록, 빌드 캐시 상한, 디스크 사용률 알람

돌아보면 이 장애의 교훈은 도커 명령어가 아니었다. 기본값을 믿지 말자는 것이었다. json-file 로그 무제한, 이미지 무한 누적, 빌드 캐시 무제한. 도커는 기본 상태로 두면 디스크를 다 쓸 때까지 자란다. 처음 서버 세팅할 때 daemon.json에 로그 설정 네 줄만 넣어뒀다면 금요일 밤을 반납할 일도 없었다. 새 서버를 세팅할 일이 있다면 도커 설치 직후에 로그 로테이션부터 걸어두시길. 미래의 내가 고마워한다.

지난주 테크 뉴스 핵심 정리: 엔비디아 어닝 서프라이즈, zHBM, 피지컬 AI

Lovizu — Sat, 5 Sep 2026 23:07:48 +0900

지난주(8월 24일~30일)는 온 시장이 수요일 하나만 쳐다보고 있던 한 주였다. 엔비디아 실적 발표 말이다. 8월 중순 코스피가 이틀 만에 7% 넘게 빠진 뒤라, 개발자인 나조차 아침에 눈 뜨면 실적 컨센서스 기사부터 확인하게 되더라. 결론부터 말하면 엔비디아는 또 숫자로 증명했고, 그 숫자 뒤에 깔린 메시지가 오히려 더 흥미로운 한 주였다. 메모리 반도체의 다음 라운드, 물리 세계로 나가는 AI 에이전트, 그리고 만점짜리 보안 구멍까지 순서대로 정리해 본다.

엔비디아 2분기 실적, 매출 962억 달러보다 무서운 건 "공급이 병목"이라는 말

한국 시간 8월 27일 새벽, 엔비디아가 2027 회계연도 2분기 실적을 발표했다. 매출 962억 달러로 전년 동기 대비 106% 증가, 조정 주당순이익은 2.22달러로 시장 컨센서스(2.08달러)를 6.7% 웃돌았다. 데이터센터 매출만 890억 달러로 전체의 92%를 넘겼고, 다음 분기 가이던스는 1,080억 달러를 제시했다. 매출이 1년 만에 두 배가 된 회사가 "다음 분기엔 더 벌겠다"고 말하는 장면을 벌써 몇 분기째 보고 있는지 모르겠다. 발표 당일 CNBC와 로이터가 일제히 다룬 내용이다.

숫자만 보면 "또 서프라이즈네" 하고 넘어갈 수 있는데, 나는 컨퍼런스콜의 두 마디가 더 기억에 남는다. 하나는 젠슨 황이 말한 "에이전틱 AI는 기존 대비 15~100배의 컴퓨팅을 요구한다"는 것. 챗봇에 질문 하나 던지는 것과 에이전트가 뒤에서 수십 번 추론을 돌리는 건 비용 구조가 완전히 다른 게임이라는 걸, 판매자 입장에서 정확히 짚은 말이다. 다른 하나는 "공급이 2028 회계연도 말까지 병목으로 남을 것"이라는 경고다. 수요가 없어서 걱정이 아니라 만들 수가 없어서 걱정이라는 얘기를 2년 뒤 시점까지 못 박아서 한 셈이다. 여기에 2028 회계연도 매출 70% 성장 전망까지 얹었고, 같은 날 AWS에 GPU 200만 개를 추가 공급하는 협력 확대도 함께 발표됐다.

국내 증시 입장에서 이 발표는 사실상 변곡점 이벤트였다. 연합뉴스 8월 25일 기사 기준으로 삼성전자와 SK하이닉스는 대규모 주주환원 발표에도 이틀 연속 급락하다 낙폭을 일부 만회하는 어수선한 흐름이었고, 시장 전체가 "엔비디아 실적이 AI 투자심리의 분기점"이라는 데 이견이 없는 상태였다. 뚜껑이 열리고 나서야 반도체 수급이 안정을 찾는 분위기였는데, 실적이 이 정도로 나왔는데도 시간외 반응이 폭발적이지 않았다는 건 눈높이가 그만큼 올라와 있다는 방증이기도 하다.

실무자 관점의 교훈은 단순하다. 클라우드 GPU 예약이나 온프레미스 장비 도입 계획이 있다면, 가격이 내려가길 기다리는 전략은 당분간 통하지 않는다는 것. 공급자가 직접 "2년은 모자란다"고 선언한 시장에서 관망은 전략이 아니다. 우리 팀도 이번 발표를 보고 추론 비용 최적화, 그러니까 캐싱과 모델 티어링 쪽에 다시 힘을 주기로 했다. GPU를 싸게 사는 건 우리 손을 떠난 문제지만, 덜 쓰는 건 우리 손에 있으니까.

덧붙이면, 이런 장세에서 개인 투자자인 나 같은 사람이 배우는 건 늘 같다. 실적이 좋아도 주가는 기대치와의 싸움이라는 것. 회사 성장과 내 계좌 수익률은 별개의 문제고, 그래서 나는 분할 매수 원칙만 지키기로 다시 마음먹었다. 투자 얘기는 여기까지만.

핫칩스 2026, 삼성 zHBM과 SK하이닉스 패키징. HBM 경쟁의 다음 라운드

8월 24~25일 열린 반도체 학회 핫칩스 2026에서 삼성전자와 SK하이닉스가 나란히 차세대 HBM 로드맵을 공개했는데, 두 회사가 찍은 방점이 서로 달라서 재미있었다. 트렌드포스와 Wccftech의 8월 24일 보도를 종합하면, 삼성은 표준 HBM에서 커스텀 HBM, 그리고 3D 적층 기반의 zHBM으로 가는 3단계 진화를 제시했다. zHBM은 표준 HBM4e 스택 대비 전력 효율 70% 향상, DRAM 대역폭 230% 증가를 주장한다. 핵심은 HBM 베이스 다이에 로직과 고객 맞춤 기능을 밀어 넣겠다는 방향성이다. 메모리 회사가 사실상 "우리도 연산 일부를 가져오겠다"고 선언한 셈이다.

반면 SK하이닉스는 첨단 패키징 쪽에 집중했다. TSMC의 CoWoS-S와 CoWoS-L, 그리고 인텔 EMIB이 HBM 스택과 실리콘 인터포저에 가하는 기계적·열적 스트레스를 비교하는 발표였다. 화려한 신제품 발표라기보다 "쌓아 올린 메모리를 어떻게 안 부러뜨리고 붙이느냐"는 공정 엔지니어링 이야기인데, HBM 세대가 올라갈수록 이 지점이 수율과 원가를 가르는 진짜 승부처가 된다. 요약하면 삼성은 "메모리를 더 똑똑하게", SK하이닉스는 "메모리를 더 잘 붙이게"에 베팅한 그림이다.

이게 왜 중요하냐면, 메모리가 더 이상 수동 부품이 아니라 연산의 일부가 되어가고 있어서다. 엔비디아조차 이번 실적 콜에서 메모리 비용이 마진을 압박한다고 언급했을 정도로, AI 인프라 원가에서 HBM의 비중은 계속 커지고 있다. 서버 스펙 시트에서 GPU 모델명만 보던 습관에서 벗어나, 메모리 구성과 패키징 방식까지 봐야 하는 시대가 오는 중이다. 애플리케이션 개발자에게 당장 와닿는 변화는 아니지만, 추론 단가가 어디서 결정되는지 이해하고 있으면 클라우드 인스턴스 선택부터 달라진다. 그리고 이 판의 양대 축이 전부 한국 회사라는 건, 요즘처럼 증시가 출렁일 때 그나마 붙잡게 되는 팩트이기도 하다.

앤스로픽 MHS 프리뷰, AI 에이전트가 드디어 물리 장치를 만진다

지난주 발표 중에 제일 "미래에서 온 뉴스" 같았던 건 이거다. 앤스로픽이 8월 27일 공식 뉴스룸을 통해 Model Hardware Standard(MHS) 연구 프리뷰를 공개했다. AI 에이전트가 물리 장치를 안전하게 조작하기 위한 공유 규격으로, 첫 적용 대상은 과학 연구실과 첨단 제조사들이다. 같은 날 과학자 지원 프로그램 확대 발표도 함께 나왔으니, 방향은 분명하다. AI를 과학 실험과 제조 현장의 실행 주체로 밀어 넣겠다는 것이다.

이걸 보고 MCP가 떠오른 사람이 나만은 아닐 거다. 에이전트가 소프트웨어 도구를 호출하는 방식이 프로토콜로 표준화되면서 작년부터 생태계가 폭발했던 것처럼, 이번엔 하드웨어 제어 계층에서 같은 그림을 그리겠다는 시도로 읽힌다. 소프트웨어 툴 호출이야 잘못돼 봤자 롤백하면 그만이지만, 물리 장비는 실수 한 번이 곧 사고다. 그래서 권한 범위, 안전 한계값, 실패 시 정지 동작 같은 걸 애플리케이션이 아니라 규격 수준에서 정의하겠다는 접근 자체는 맞는 순서라고 본다. 동시에, 그 표준을 자기들이 먼저 쓰겠다는 플랫폼 선점 전략인 것도 부정할 수 없다.

당장 웹 서비스 만드는 개발자에게 영향은 없다. 다만 코드 짜주는 AI 다음 단계는 물리 세계에서 일하는 AI라는 방향은 점점 또렷해지고 있다. IoT나 로보틱스, 스마트팩토리 쪽에 발 담근 분들은 프리뷰 문서라도 미리 훑어볼 가치가 있다. MCP 때도 "이게 뭐가 되겠어" 하다가 반년 만에 이력서 키워드가 된 걸 우리는 이미 봤다.

Sonnet 5 가격 영구화, API 비용 계획 세운 팀은 다시 계산해도 된다

조용히 지나갔지만 실무에는 꽤 실질적인 뉴스. 앤스로픽이 Claude Sonnet 5의 프로모션 가격(입력 100만 토큰당 2달러, 출력 10달러)을 영구화했다. 원래 8월 31일에 종료되고 3달러/15달러로 돌아갈 예정이었는데, 만료 직전에 이 가격을 그대로 굳혔다. 9월부터 API 비용이 50% 뛴다고 가정하고 예산을 잡아뒀던 팀이라면, 그 스프레드시트를 기분 좋게 다시 열어도 된다. 우리처럼 월 토큰 사용량이 꾸준히 우상향하는 팀에는 연간 단위로 보면 무시 못 할 차이다.

나는 이 결정을 "중간 티어 가격 방어선 선언"으로 읽었다. OpenAI가 7월에 GPT-5.6 패밀리를 내놓으면서 저가 티어인 Luna를 100만 토큰당 1달러에 깔아버린 상황이라, 볼륨 워크로드 시장에서 가격을 물러설 수 없다는 계산이 보인다. 프런티어 성능 경쟁과 별개로, 실제 매출이 나오는 대량 처리 시장의 가격 경쟁이 본격화됐다는 신호다.

지난주 후반에는 앤스로픽이 신모델 두 종을 동시에 준비 중이라는 루머까지 돌았는데, 실제로 이 글을 정리하는 사이 9월 1일에 Fable 5.1과 Mythos 5.1이 공식 발표됐다. 프런티어 모델 교체 주기가 이제 몇 달이 아니라 몇 주 단위로 도는 느낌이다. 이런 속도라면 특정 모델명을 하드코딩한 파이프라인은 점점 부채가 된다. 모델 ID를 설정으로 빼고, 평가 셋을 자동으로 돌릴 수 있게 해두는 게 이 시대의 최소한의 방어 운전이다.

CVSS 만점짜리 오라클 WebLogic 취약점, 패치 다 해도 뚫린다

보안 쪽에서는 이게 제일 컸다. The Register의 8월 25일 보도에 따르면, 오라클 퓨전 미들웨어의 CVSS 10.0 만점 취약점 CVE-2026-60004가 실제 공격에 악용되고 있는 게 확인되면서 미국 CISA가 알려진 악용 취약점(KEV) 목록에 올렸다. 연방기관에 부여된 패치 시한이 단 3일. CISA가 주는 데드라인 중 가장 짧은 축이다. 이 취약점은 올해 1월에 공개된 것으로, 인증 없이 WebLogic 서버에서 원격 코드 실행이 가능하다.

무서운 대목은 따로 있다. 올해 오라클이 낸 패치 1,449개를 전부 적용했더라도 여전히 취약할 수 있다는 것. 공격자들이 전통적인 소프트웨어 버그가 아니라 시스템이 설계된 동작 방식 자체를 악용하는 쪽으로 옮겨가고 있어서다. "패치 잘 하고 있으니 우린 괜찮다"는 논리가 무너지는 지점이다.

금융권이나 공공 SI를 경험해 본 분들은 알 거다. WebLogic은 "잘 돌아가니까 건드리지 말자"는 분위기 속에 방치된 레거시 환경에 정말 많다. 나도 예전 프로젝트에서 담당자조차 존재를 모르던 개발용 WebLogic 인스턴스가 외부에 열려 있는 걸 본 적이 있다. 운영 계정에 WebLogic이 한 대라도 있다면 이번 주에 자산 목록부터 확인하시길. 특히 프로덕션보다 관리가 느슨한 개발·테스트 환경이 위험하다. 당장 패치가 어렵다면 네트워크 세그멘테이션과 WAF, 모니터링 강화 같은 보완 통제라도 먼저 챙겨야 한다.

짧게 짚고 넘어가는 단신들

실적 시즌은 계속된다. 엔비디아 다음 날인 8월 27일에는 마벨이 2분기 실적을 발표했다. 8월 19일 공개된 구글과의 맞춤형 AI 칩 계약과 121억 달러 규모 워런트 덕에 기대가 잔뜩 올라간 상태였는데, 눈높이가 높아진 만큼 발표 후 주가 반응은 차가웠다. 워크데이, 오토데스크, 스노우플레이크 등 소프트웨어 기업들 실적도 줄줄이 이어지는 중이다. AI 인프라 투자가 실제 소프트웨어 매출로 전환되고 있는지가 9월 초 시장의 핵심 질문이다.

빅테크의 자금 압박. 연합뉴스 8월 25일 분석 기사에서 눈에 띈 대목 하나. 반도체주 변동성의 근본 배경으로 미국 국채금리 고공행진이 지목됐다. AI 데이터센터 투자는 조 단위 자본 지출 경쟁인데, 금리가 높으면 그 돈의 조달 비용도 같이 뛴다. AI 사이클을 볼 때 기술 뉴스만큼 거시 지표를 같이 봐야 하는 이유다.

앤스로픽의 또 다른 발표. MHS 외에도 지난주 앤스로픽은 8월 25일 AI가 사용자 웰빙에 미치는 영향을 평가하는 연구 지원 프로그램을 발표했다. 모델 성능 벤치마크가 아니라 "AI가 사람에게 이로운가"를 재는 평가 체계에 돈을 대겠다는 것. 에이전트가 물리 세계로 나가는 시점에 이런 평가 인프라가 같이 깔리는 건 다행스러운 일이다.

이번 주를 한 줄로 줄이면

"공급은 모자라고, 메모리는 똑똑해지고, 에이전트는 몸을 얻는 중." 돈도 기술도 전부 AI 인프라의 물리적 한계를 뚫는 데 몰리고 있다는 게 지난주의 공통분모였다.

이번 주는 9월 1일에 나온 앤스로픽 Fable 5.1·Mythos 5.1의 실제 성능 검증, 그리고 9월 2일 스노우플레이크를 비롯한 소프트웨어 기업들 실적이 관전 포인트다. 엔비디아가 쏘아 올린 낙관론이 소프트웨어 실적으로도 이어지는지 확인하면 AI 사이클의 온도를 한 번 더 잴 수 있을 것이다. 다음 주에 또 정리하겠다.

참고: CNBC·로이터·연합뉴스(8/25)·인베스팅닷컴 엔비디아 실적 보도, 트렌드포스·Wccftech 핫칩스 2026 보도(8/24), 앤스로픽 공식 뉴스룸(8/27), The Register(8/25)

40대 개발자의 새벽 운동 일지, 출근 전 30분 홈트로 석 달 버틴 기록 (몸의 변화와 현실 조언)

Lovizu — Thu, 3 Sep 2026 12:34:34 +0900

올해 봄 건강검진 결과지를 받아 들고 한참을 들여다봤다. 숫자 몇 개가 작년보다 나빠져 있었다. 크게 아픈 데는 없는데, 의사 선생님이 "운동 좀 하셔야겠는데요"라고 지나가듯 말한 그 한마디가 이상하게 오래 남았다. 마흔 넘어서 듣는 그 말은 서른에 듣던 것과 무게가 다르다. 그래서 6월부터 출근 전 30분 운동을 다시 시작했고, 오늘로 딱 석 달을 채웠다. 이 글은 그 석 달의 기록이다. 대단한 변신 스토리는 아니다. 애 셋 키우는 40대 직장인 개발자가 하루 30분을 어떻게 지켜냈는지, 몸은 뭐가 달라졌고 뭐는 그대로인지, 있는 그대로 적어본다.

사진: Unsplash, Robin Benzrihem(@robinoode)

다시 운동을 시작한 이유는 거창하지 않았다

계기는 두 개였다. 하나는 위에서 말한 건강검진. 다른 하나는 회사 계단이었다. 사무실이 4층인데, 엘리베이터 점검하던 날 계단으로 올라갔다가 3층부터 숨이 차서 잠깐 멈췄다. 뒤에서 올라오던 20대 직원이 가볍게 추월해 가는데, 그 순간 '아, 이건 좀 아니다' 싶었다.

개발자라는 직업이 원래 몸에 좋은 직업은 아니다. 하루 종일 앉아 있고, 마감 걸리면 야근하고, 스트레스는 야식으로 풀게 된다. 여기에 애가 셋이면 '내 시간'이라는 게 사실상 없다. 퇴근하면 육아 2교대 시작이고, 애들 재우고 나면 밤 10시 반. 그때부터 운동하러 나가는 건 몇 번 해봤지만 오래 못 갔다. 몸도 지쳐 있고, 그 시간엔 그냥 소파에 눕고 싶은 게 사람 마음이다.

그래서 이번엔 접근을 바꿨다. 결론부터 말하면, 40대 아빠가 운동 시간을 확보할 수 있는 유일한 구간은 새벽뿐이었다. 아무도 나를 찾지 않는 시간. 아이들이 깨기 전, 출근 준비 전. 새벽 5시 50분 기상, 6시부터 6시 반까지 30분. 이게 내가 석 달 동안 지킨 전부다.

출근 전 30분, 루틴은 최대한 단순하게 짰다

헬스장은 등록하지 않았다. 과거에 세 번 등록해서 세 번 다 기부천사가 돼본 경험이 있다. 왕복 이동 시간까지 계산하면 새벽 30분 운동을 위해 1시간 반이 필요한데, 그건 지속 불가능하다는 걸 이미 안다. 그래서 거실 홈트, 맨몸운동으로 정했다. 준비물은 요가 매트 한 장과 문틀 철봉이 전부다.

루틴은 이렇게 굴렸다.

월·수·금 : 근력 위주. 푸시업, 스쿼트, 플랭크, 철봉 매달리기를 서킷으로 3~4바퀴
화·목 : 유산소 위주. 아파트 단지 빠르게 걷기 또는 계단 오르기 25분
토 : 아이들 일어나기 전에 가볍게 스트레칭 + 폼롤러
일 : 완전 휴식. 대신 애들이랑 놀이터에서 몸으로 놀아주기

포인트는 '못 채워도 되는 설계'다. 처음부터 주 7일짜리 계획을 세우면 하루 빠지는 순간 죄책감이 생기고, 죄책감이 쌓이면 그만두게 된다. 나는 주 3회 근력만 지키면 성공, 나머지는 보너스로 쳤다. 이 기준 덕분에 석 달을 버텼다고 생각한다.

석 달 치 기록: 숫자는 거짓말을 안 한다

운동 일지는 스프레드시트에 적었다. 개발자 직업병인지 뭐든 기록부터 하게 되는데, 이번엔 그 습관이 도움이 됐다. 매달 첫 주 기준으로 주요 숫자만 뽑아보면 이렇다.

6월 시작 : 체중 81.4kg / 푸시업 한 번에 12개 / 스쿼트 20개 / 플랭크 40초 / 철봉 매달리기 25초
7월 초 : 체중 80.2kg / 푸시업 18개 / 스쿼트 30개 / 플랭크 1분 / 철봉 40초
8월 초 : 체중 79.0kg / 푸시업 24개 / 스쿼트 40개 / 플랭크 1분 30초 / 철봉 55초
9월 현재 : 체중 78.1kg / 푸시업 30개 / 스쿼트 50개 / 플랭크 2분 / 철봉 1분 10초

석 달에 체중 -3.3kg. 솔직히 극적인 숫자는 아니다. 한 달에 1kg 남짓이다. 인터넷에는 "3개월에 10kg 감량" 같은 글이 넘쳐나니까 처음엔 내 속도가 초라해 보이기도 했다. 그런데 40대에 무리한 감량은 요요와 부상으로 돌아온다는 얘기를 하도 많이 들어서, 이 정도 속도면 오히려 잘 가고 있다고 마음을 고쳐먹었다. 실제로 몸이 가벼워진 건 체중계 숫자보다 훨씬 크게 느껴진다.

사진: Unsplash, Giorgio Trovato(@giorgiotrovato)

푸시업 개수가 12개에서 30개가 된 게 개인적으로는 제일 뿌듯하다. 처음 시작할 때는 무릎 대고 하는 날도 있었다. 지금은 정자세로 30개를 채우고, 마지막 세트는 발을 소파에 올리고 하는 여유까지 생겼다. 근력은 나이 들어도 는다. 이건 석 달 해보고 확실히 체감했다.

몸에서 느껴진 변화, 기대 안 했던 것들

체중이나 근력보다 의외의 변화들이 더 좋았다.

첫째, 오후 3시의 급격한 방전이 줄었다. 개발자라면 다들 아는 그 시간대. 점심 먹고 두세 시쯤 되면 모니터 앞에서 눈이 감기고 집중력이 바닥나는 구간이 있다. 운동 시작하고 한 달쯤 지나니 이게 눈에 띄게 완만해졌다. 커피를 하루 세 잔에서 두 잔으로 줄였는데도 버틸 만하다.

둘째, 잠드는 속도가 빨라졌다. 원래 누워서 휴대폰 보다가 새벽 1시 넘겨 자는 날이 많았는데, 새벽 기상을 하다 보니 밤 11시면 자연스럽게 졸리다. 수면 시간 자체는 비슷한데 아침에 일어나는 게 덜 괴롭다. 수면의 질이 달라진 느낌이랄까.

셋째, 허리와 어깨가 덜 뭉친다. 하루 8시간 이상 앉아 있는 직업이라 만성적으로 어깨가 돌덩이였는데, 푸시업과 철봉 매달리기를 꾸준히 하면서 확실히 덜해졌다. 물론 이건 사람마다 다를 수 있는 부분이고, 통증이 있는 상태라면 운동으로 해결하려 하기보다 병원부터 가보는 게 순서라고 생각한다. 나도 시작 전에 예전에 다쳤던 무릎 상태를 확인받고 시작했다.

넷째, 애들 앞에서 덜 지친다. 이게 사실 제일 크다. 주말에 놀이터에서 30분만 뛰어도 벤치를 찾던 아빠였는데, 요즘은 첫째랑 축구를 한 시간 해도 버틸 만하다. 운동한 시간은 새벽이지만, 그 효과를 돌려받는 건 아이들과 있는 시간이더라.

무너질 뻔한 고비가 세 번 있었다

석 달이 순탄하지만은 않았다. 돌아보면 고비가 세 번 있었다.

1차 고비, 7월 초 회식 시즌. 반기 마무리 회식이 몰리면서 술 마신 다음 날 새벽 기상이 안 됐다. 이때 이틀 연속으로 빠지고 나니 '이번 주는 망했으니 다음 주부터 하자'는 익숙한 목소리가 올라왔다. 예전 같으면 여기서 끝났을 텐데, 이번엔 '망한 주'라는 개념 자체를 없앴다. 하루 빠지면 그냥 다음 날 다시 하면 된다. 주 단위 리셋 사고방식이 운동을 그만두게 만드는 주범이라는 걸 이제는 안다.

2차 고비, 8월 휴가와 막내 아픈 주. 가족 여행 다녀오고, 연달아 막내가 열이 나서 밤에 몇 번씩 깨던 주가 있었다. 이럴 땐 새벽 운동이 불가능하다. 잠이 우선이다. 대신 '최소 버전'을 만들어놨다. 아무리 엉망인 날도 푸시업 20개와 스쿼트 20개는 하고 잔다. 5분이면 된다. 운동량으로는 의미가 크지 않을지 몰라도, '끊기지 않았다'는 감각을 유지하는 데는 이 5분이 결정적이었다.

3차 고비, 9월 첫 주의 권태기. 석 달쯤 되니 몸무게가 일주일 넘게 그대로였다. 정체기가 오니 재미가 뚝 떨어졌다. 이때 도움이 된 게 기록이었다. 체중은 멈췄지만 플랭크 시간과 푸시업 개수는 계속 늘고 있었다. 지표를 하나만 보면 정체기가 슬럼프가 되는데, 여러 개를 보면 '다른 게 크고 있네'가 보인다. 서비스 지표 볼 때랑 똑같다. DAU가 멈춰도 리텐션이 오르고 있으면 그 서비스는 죽은 게 아니다.

사진: Unsplash, Aalo Lens(@aalolens)

40대 운동, 조심해야 할 것들도 분명히 있다

석 달 하면서 느낀 주의점도 적어둔다. 나는 의사도 트레이너도 아니니, 어디까지나 한 사람의 경험담으로만 읽어주시면 좋겠다.

아픈 것과 힘든 것을 구분해야 한다. 근육이 힘든 건 괜찮지만 관절이 아픈 건 신호다. 나는 스쿼트 각도를 욕심내다 무릎이 시큰했던 적이 있는데, 바로 가동 범위를 줄이고 자세부터 다시 잡았다. 40대의 부상은 회복이 오래 걸린다. 하루 무리해서 2주 쉬면 완전히 손해다.
준비운동을 생략하면 안 된다. 20대엔 바로 본운동 들어가도 괜찮았지만 지금은 다르다. 손목, 어깨, 고관절 돌리기 5분은 무조건 지킨다. 30분 중 5분이 아깝게 느껴져도, 그 5분이 나머지 25분을 지켜준다.
기존 질환이 있다면 시작 전에 전문가와 상의하는 게 맞다. 혈압이나 허리, 무릎에 문제가 있는 상태에서 인터넷 루틴만 보고 따라 하는 건 위험할 수 있다. 몸 상태는 사람마다 다르니, 내 루틴 역시 정답이 아니라 하나의 사례일 뿐이다.
보조제나 특정 식단에 대한 환상은 접었다. 단백질 섭취야 신경 쓰지만, 뭘 먹어서 살이 빠졌다기보다 야식 빈도가 줄어든 게 컸다. 새벽에 일어나야 하니 밤에 뭘 먹고 싶은 마음 자체가 줄었다.

새벽 운동 석 달 차가 전하는 현실 팁 6가지

혹시 새벽 운동을 시작해보려는 분이 있다면, 석 달 차가 몸으로 배운 팁 몇 가지를 정리해둔다. 유튜브에 나오는 멋진 얘기 말고, 진짜 사소해서 아무도 안 알려주는 것들이다.

1. 기상 직후 물 한 컵부터. 자고 일어나면 몸이 뻣뻣하고 머리도 안 돌아간다. 물 한 컵 마시고 화장실 다녀오는 5분이 워밍업의 시작이다. 이 5분 루틴이 있으면 '일어나자마자 운동'이라는 부담이 '일어나서 물 마시기'라는 쉬운 첫 동작으로 바뀐다. 첫 동작이 쉬워야 그다음이 이어진다.

2. 전날 밤 10분이 새벽을 결정한다. 밤 12시 넘어 자면 새벽 5시 50분 기상은 그냥 불가능하다. 나는 밤 11시에 휴대폰을 충전기에 꽂고 침실 밖에 둔다. 새벽 운동의 성패는 사실 전날 밤 취침 시간에서 이미 갈린다. 운동 계획보다 수면 계획이 먼저다.

3. 소리 없는 운동 위주로 짠다. 아파트에서 새벽 6시에 점프 스쿼트나 버피를 하면 아랫집에 민폐다. 그리고 애들이 깬다. 애들이 깨면 그날 운동은 끝이다. 푸시업, 플랭크, 슬로우 스쿼트처럼 착지 소음 없는 동작 위주로 구성한 건 그래서다. 매트 두께도 층간소음에 생각보다 영향이 크다.

4. 운동 강도는 '다음 날 또 하고 싶은 정도'까지만. 초반에 의욕이 넘쳐서 근육통으로 이틀을 절뚝거린 적이 있다. 그 이틀의 공백이 리듬을 깨는 게 강도 높은 하루보다 손해다. 지금은 '조금 아쉬운데?' 싶을 때 멈춘다. 지속이 강도를 이긴다. 최소한 40대에게는 확실히 그렇다.

5. 측정은 일주일에 한 번이면 충분하다. 매일 체중계에 올라가면 하루 단위 출렁임에 기분만 왔다 갔다 한다. 나는 토요일 아침 공복에만 잰다. 대신 운동 수행 기록(개수, 시간)은 매일 적는다. 체중은 느리게 움직이는 후행 지표고, 수행 능력이 선행 지표다. 모니터링할 지표를 잘 골라야 오래 간다.

6. 가족에게 공유하면 그만두기 어려워진다. 아내에게 석 달 목표를 선언했고, 첫째한테는 "아빠 푸시업 30개 도전 중"이라고 말해뒀다. 아이가 가끔 "아빠 오늘 몇 개 했어?"라고 물어보는데, 이게 어떤 앱 알림보다 강력하다. 아이 앞에서 한 약속은 쉽게 못 접는다.

석 달을 지켜준 건 의지가 아니라 장치였다

마지막으로, 석 달 해보고 내린 결론 하나. 나를 움직인 건 의지력이 아니었다. 의지는 석 달짜리 연료가 못 된다. 대신 장치가 필요했다.

전날 밤에 운동복을 거실에 꺼내두는 것. 알람을 침대에서 손 안 닿는 곳에 두는 것. 스프레드시트에 한 줄이라도 적는 것. 아내에게 "석 달만 새벽에 깨워줘도 뭐라 하지 말아달라"고 선언해둔 것. 이런 사소한 장치들이 게으른 나를 매일 아침 매트 위로 밀어 넣었다. 개발할 때 CI를 걸어두는 이유와 같다. 사람의 성실함을 믿지 말고 시스템이 굴러가게 만들 것.

다음 목표는 소박하다. 연말까지 푸시업 40개, 플랭크 3분, 체중 76kg대 진입. 그리고 무엇보다 '끊기지 않기'. 겨울이 오면 새벽 기상 난이도가 확 올라갈 텐데, 그건 그때 가서 또 최소 버전으로 버텨볼 생각이다. 석 달 뒤에 겨울을 버틴 운동 일지로 다시 돌아오겠다.

비슷하게 운동을 다시 시작해보려는 40대 분들에게 이 기록이 작은 참고가 되면 좋겠다. 거창할 필요 없다. 새벽 30분, 아니 5분이라도, 오늘 시작해서 내일 또 하면 그게 운동 루틴이다.

AI가 코드를 다 짜주는 시대, 주니어 개발자는 어떻게 성장해야 할까 (15년차 개발자의 생각)

Lovizu — Tue, 1 Sep 2026 17:17:02 +0900

얼마 전 팀 주니어 개발자가 짜온 코드를 리뷰하다가 잠깐 멍해진 적이 있다. 코드가 이상해서가 아니다. 너무 멀쩡해서였다. 예외 처리도 깔끔하고, 네이밍도 좋고, 테스트 코드까지 붙어 있었다. 3년차가 쓴 코드라고 보기엔 지나치게 정돈되어 있었다. 물어보니 역시나였다. "AI한테 시키고 제가 다듬었어요." 요즘은 이게 표준이다. 나도 쓴다. 부정할 생각은 없다. 다만 그날 이후로 계속 머릿속을 떠나지 않는 질문이 하나 있다. AI가 코드를 다 짜주는 시대에, 주니어 개발자는 도대체 어떻게 성장해야 하는가.

사진: Arnold Francisca / Unsplash

코드 리뷰 풍경이 달라졌다

15년 넘게 이 일을 하면서 코드 리뷰 풍경이 이렇게 빨리 바뀐 건 처음 본다. 몇 년 전만 해도 주니어 코드 리뷰의 절반은 문법과 컨벤션 얘기였다. 변수명이 왜 이러냐, 이 반복문은 왜 세 번 도냐, null 체크는 어디 갔냐. 지금은 그런 지적을 할 일이 거의 없다. AI가 그런 실수를 안 하기 때문이다.

대신 리뷰에서 나오는 질문이 달라졌다. "이 함수가 왜 여기 있어야 하죠?" "이 케이스에서 트랜잭션이 왜 필요한지 설명해줄 수 있어요?" 이런 질문을 던졌을 때 대답이 막히는 경우가 늘었다. 코드는 본인이 올렸는데, 그 코드가 왜 그렇게 생겼는지는 설명을 못 한다. 코드의 주인이 사람이 아니라 도구가 된 것 같은 순간이다.

오해는 말자. 주니어가 게을러서가 아니다. 회사는 빠른 결과물을 원하고, AI는 빠른 결과물을 준다. 눈앞에 완성된 코드가 있는데 그걸 안 쓰고 한나절 삽질하는 게 오히려 이상한 선택처럼 보이는 환경이 됐다. 구조가 그렇게 만들어졌는데 개인을 탓하는 건 공정하지 않다.

문제는 코드가 아니라 '겪음'의 실종이다

내가 걱정하는 건 코드 품질이 아니다. AI가 짜준 코드는 대체로 평균 이상이다. 문제는 그 코드에 도달하기까지의 과정이 통째로 사라진다는 데 있다.

예를 하나 들어보자. 몇 달 전 운영 중이던 서비스에서 간헐적으로만 재현되는 타임아웃 장애가 있었다. AI에게 물으니 그럴듯한 원인 후보를 여러 개 냈다. 커넥션 풀 고갈, DNS 캐싱, GC 멈춤. 전부 그럴싸했지만 정답은 그 목록에 없었다. 결국 문제를 찾은 건 "왜 특정 시간대에만 터지지?"라는 이상한 감각을 못 버린 팀원의 집요함이었다. 그 감각은 어디서 왔을까. 비슷한 장애를 맨몸으로 겪어본 기억에서 왔다고 나는 생각한다.

개발자의 실력이라는 게 뭘까 생각해보면, 결국 '겪은 문제의 총량'이라고 나는 믿는 편이다. 새벽에 장애 알림 받고 로그를 뒤지다가 커넥션 풀 설정 하나 때문이었다는 걸 알아냈을 때, 인덱스를 걸었는데도 쿼리가 느려서 실행계획을 처음 열어봤을 때, 그런 경험들이 쌓여서 어느 순간 코드를 보면 냄새를 맡는 감각이 생긴다. 이 감각은 책으로도, 강의로도 안 생긴다. 겪어야 생긴다.

그런데 AI는 바로 그 '겪는 구간'을 건너뛰게 해준다. 에러가 나면 에러 메시지를 복사해서 붙여넣으면 원인과 해결책이 같이 온다. 편하다. 나도 매일 그렇게 한다. 하지만 나는 그 에러를 예전에 맨몸으로 겪어봤기 때문에 AI의 답이 맞는지 틀렸는지 판단할 수 있다. 겪어본 적 없는 사람에게 AI의 답은 검증할 수 없는 정답지다. 채점 기준 없이 정답지만 쌓이는 공부가 실력이 될 리 없다.

사진: Mohammad Rahmani / Unsplash

"우리 때는 삽질로 배웠다"는 말의 함정

여기까지 쓰고 보니 딱 꼰대 소리 하기 좋은 흐름인데, 일부러 반대쪽 얘기도 해야겠다. "우리 때는 삽질하면서 배웠는데 요즘 애들은..."이라는 말에는 함정이 있다.

솔직해지자. 우리가 삽질로 배운 건 그때는 삽질 말고 방법이 없었기 때문이다. 스택오버플로우가 없던 시절에 개발하던 선배들은 매뉴얼 책 한 권 들고 밤을 새웠고, 그 선배들 눈에는 검색으로 답을 찾는 우리가 날로 먹는 것처럼 보였을 거다. 구글 검색이 개발자를 망친다는 얘기도 있었고, IDE 자동완성이 개발자를 바보로 만든다는 얘기도 있었다. 지금 들으면 웃기지 않나. 도구가 바뀔 때마다 같은 걱정이 반복됐고, 개발자들은 결국 그 도구 위에서 더 어려운 문제를 풀어왔다.

그러니까 "AI 때문에 주니어가 성장을 못 한다"는 명제는 절반만 맞다고 본다. 정확히는 이렇게 고쳐 써야 한다. 성장의 경로가 바뀌었는데, 새 경로가 아직 정리가 안 됐다. 예전 경로는 폐쇄됐는데 새 이정표는 없는 상태. 지금 주니어들이 서 있는 곳이 거기다.

그래서 주니어는 뭘 해야 하나

답을 아는 척할 생각은 없지만, 애 셋 키우면서 배운 게 하나 있다. 아이가 자전거를 배울 때 보조바퀴를 언제 떼느냐가 중요한 게 아니라, 넘어져도 되는 안전한 환경에서 넘어져보는 경험이 중요하더라. 개발도 비슷하다고 생각한다. 내가 주니어라면, 혹은 내 팀 주니어에게 해주고 싶은 얘기는 세 가지다.

첫째, AI의 답을 받기 전에 내 답을 먼저 만들어보는 습관. 설계든 디버깅이든, 10분이라도 좋으니 내 가설을 먼저 세우고 나서 AI에게 물어보는 거다. 내 가설과 AI의 답이 다르면 왜 다른지 따져보는 그 지점에서 진짜 공부가 시작된다. 가설 없이 받은 답은 흘러가고, 가설 위에서 받은 답은 쌓인다.

둘째, 설명할 수 없는 코드는 올리지 않는다는 원칙. AI가 짜줬든 어디서 가져왔든 상관없다. 리뷰에서 "이거 왜 이렇게 했어요?"라는 질문에 자기 언어로 답할 수 있으면 그건 자기 코드다. 답을 못 하면 아직 자기 코드가 아닌 거다. 이 기준 하나만 지켜도 AI를 쓰면서 성장하는 쪽에 설 수 있다고 본다.

셋째, 일부러 겪는 시간을 확보하는 것. 회사 일은 속도가 생명이니 AI를 풀로 쓰되, 사이드 프로젝트나 학습 시간에는 의도적으로 AI를 끄고 바닥부터 부딪혀보는 거다. 근력 운동이랑 똑같다. 평소에 기계 힘을 빌리더라도, 맨몸 운동으로 기본 근력을 만들어두지 않으면 기계가 없을 때 아무것도 못 든다. 일주일에 반나절이라도 좋다. 프레임워크 없이 HTTP 서버를 직접 띄워본다든가, ORM 없이 쿼리를 손으로 짜본다든가. 이런 시간이 당장의 생산성에는 아무 도움이 안 되지만, 5년 뒤의 판단력에는 복리로 쌓인다.

하나 더 보태자면, 장애와 트러블슈팅 경험은 기회가 올 때 자원해서 잡으라고 말하고 싶다. 남의 장애 회고 문서를 읽는 것과 새벽에 직접 로그를 뒤지는 건 완전히 다른 경험이다. AI가 대체하기 가장 어려운 경험이 바로 이런 '내 서비스가 무너지는 걸 직접 복구해본 기억'이다. 힘들지만, 이만한 성장 부스터가 없다.

사진: Franck V. / Unsplash

채용과 면접도 흔들리고 있다

이 얘기를 하려면 채용 얘기를 빼놓을 수 없다. 최근에 우리 팀 채용 면접에 들어갔다가 재미있는 경험을 했다. 과제 전형으로 제출된 코드들이 다 비슷하게 잘 짜여 있었다. 몇 년 전이라면 상위 10%에 들었을 코드가 이제는 평균이 됐다. 과제만 봐서는 지원자의 실력을 구분할 수 없는 시대가 된 거다.

그래서 면접 방식도 바뀌고 있다. 우리도 과제 코드에 대해 '왜'를 파고드는 질문의 비중을 크게 늘렸다. 이 구조를 선택한 이유, 다른 대안과의 트레이드오프, 이 코드가 트래픽이 10배 늘면 어디서 먼저 터질지. AI로 짠 코드라도 이 질문들에 자기 언어로 답하는 지원자는 합격이다. 반대로 완벽한 코드를 내고도 설명이 무너지는 지원자가 생각보다 많다. 결국 면접장에서도 갈리는 건 코드가 아니라 코드에 대한 이해다.

주니어 입장에서 이건 나쁜 소식이 아니라고 본다. 채용의 기준이 '코드를 짤 수 있는가'에서 '코드를 설명할 수 있는가'로 옮겨가고 있다는 건, 성장의 방향도 거기에 맞추면 된다는 뜻이니까. 어디에 힘을 써야 할지가 오히려 명확해졌다.

시니어와 회사도 숙제가 있다

주니어에게만 숙제를 떠넘기면 안 된다. 사실 더 큰 숙제는 시니어와 회사에 있다고 생각한다.

시니어의 역할은 이제 '코드 잘 짜는 법'을 가르치는 게 아니라 '판단하는 법'을 가르치는 쪽으로 옮겨가야 한다. 리뷰에서 문법 지적할 일이 없어졌으면, 그 시간에 왜 이 구조를 선택했는지, 이 코드가 6개월 뒤에 어떤 문제를 일으킬 수 있는지 같은 얘기를 해야 한다. 나부터도 리뷰 코멘트의 방향을 바꾸는 중이다. "이렇게 고치세요"가 아니라 "이 경우엔 어떻게 되나요?"라고 묻는 쪽으로.

회사 입장에서는 더 현실적인 문제가 있다. AI 때문에 주니어 채용을 줄이는 회사들이 실제로 늘고 있는데, 이건 미래의 시니어 공급을 끊는 일이다. 시니어는 하늘에서 떨어지지 않는다. 전부 주니어였던 사람들이다. 지금 주니어를 안 뽑고 안 키우면 5년 뒤에 시니어 구인난으로 돌아온다. 눈앞의 생산성만 보고 성장 사다리를 걷어차는 건 업계 전체로 보면 제 발등 찍기다.

우리 팀이 실험 중인 것들

말만 하면 꾼대니까, 우리 팀에서 올해 실제로 해보고 있는 것들을 공유한다. 성공했다기보다는 아직 실험 단계라는 걸 전제로 봐주면 좋겠다.

첫 번째는 '설명 리뷰'다. 주니어가 PR을 올리면 일주일에 한 번은 코드 리뷰 대신 15분짜리 구두 설명 시간을 잡는다. 화면 공유하고 본인이 짜온 코드의 흐름을 말로 설명하는 거다. 신기하게도 설명하다가 본인이 먼저 "어, 이거 이상한데요"하며 문제를 찾는 경우가 많다. 설명은 이해를 강제하는 장치다.

두 번째는 AI 사용 기록이다. 프롬프트를 어떻게 썼는지, AI 답을 그대로 썼는지 고쳤는지, 고쳤다면 왜 고쳤는지를 PR 설명에 한 줄씩 남기게 한다. 부끄러워할 일이 아니라 오히려 자랑이 되는 문화를 만들려고 한다. AI 답을 고친 이유를 설명할 수 있다는 건 그 사람의 판단력이 작동했다는 증거니까.

세 번째는 장애 회고에 주니어를 무조건 참여시키는 거다. 예전엔 시니어끼리 빨리 끝내는 게 효율적이라 생각했는데, 지금은 생각이 바뀌었다. 장애 회고야말로 AI가 대신 겪어줄 수 없는 경험을 간접체험으로라도 전달할 수 있는 거의 유일한 자리가 됐다.

반대편 의견도 있다

토론 카테고리에 쓰는 글이니 반론도 정리해둔다. 실제로 주변 개발자들과 얘기해보면 의견이 꽤 갈린다.

한쪽에서는 "겪음의 실종" 자체가 기우라고 본다. 어차피 앞으로의 개발은 AI와 협업하는 형태가 기본값이 될 텐데, 옛날 방식의 밑바닥 경험은 라틴어 같은 교양이지 필수가 아니라는 거다. 자동차 정비를 몰라도 운전을 잘할 수 있듯이, 저수준 디버깅 경험 없이도 AI를 지휘해서 좋은 소프트웨어를 만드는 새로운 유형의 개발자가 주류가 될 거라는 주장. 일리가 있다. 나도 어셈블리를 몰라도 15년을 먹고살았으니까.

다른 한쪽은 내 걱정보다 더 비관적이다. 판단력이라는 것도 결국 겪음에서 나오는데, 겪음의 기회 자체가 구조적으로 사라졌으니 세대 단절은 피할 수 없다는 쪽. 어느 쪽이 맞을지는 솔직히 모르겠다. 5년쯤 지나면 답이 나올 텐데, 그때 지금 주니어들이 어떤 시니어가 되어 있을지가 그 답일 거다.

정리하며

나는 AI 코딩 도구를 매일 쓰고, 앞으로 더 쓸 거다. 이건 거스를 수 있는 흐름이 아니다. 다만 도구가 대신해주는 것과 내가 가져가야 하는 것을 구분하는 일은 여전히 사람 몫이다. 코드는 AI가 짜줄 수 있어도, 그 코드에 책임지는 감각과 판단력은 외주를 줄 수 없다.

주니어 시절의 나에게 한 줄만 남긴다면 이렇게 쓰겠다. 도구는 최대한 활용하되, 설명할 수 없는 코드에 네 이름을 붙이지 마라. 그 원칙 하나면 도구가 뭐로 바뀌든 계속 성장할 수 있다.

여러분 생각은 어떤가. AI 시대의 주니어 성장, 기우일까 진짜 위기일까. 현업에 계신 분들의 의견이 궁금하다. 댓글로 나눠주시면 감사히 읽겠다.

블로그 소개

Lovizu — Fri, 28 Aug 2026 13:32:52 +0900

감성 개발자 블로그 소개

안녕하세요. 감성 개발자(lovizu.com)를 운영하는 Lovizu입니다.

이 블로그는 2018년 8월에 시작해 지금까지 150편이 넘는 글을 쌓아온 개인 기술 블로그입니다. 회사에서 코드를 짜고, 집에 돌아와 아이 셋을 키우면서 겪은 것들을 그때그때 기록해 왔습니다. 검색해서 찾아 헤맸는데 정리된 글이 없어서 답답했던 것, 삽질 끝에 겨우 해결한 것, 돈 주고 사보고 나서야 알게 된 것들을 남기는 곳입니다.

블로그 이름에 ‘감성’이 붙은 이유는 단순합니다. 기술 문서처럼 건조하게 정답만 나열하기보다, 왜 그 상황에 빠졌고 어떤 판단으로 어떻게 빠져나왔는지까지 쓰고 싶었기 때문입니다.

운영자 소개

웹 백엔드를 주로 다루는 개발자입니다. PHP / Laravel을 주력으로 오래 써왔고, MySQL과 AWS 운영이 일의 큰 비중을 차지합니다. 회사를 다니다 프리랜서로 전향한 시기도 있었고, 그 과정에서 겪은 고민들도 블로그에 남아 있습니다.

주력 외에 실제로 손대본 것들은 이렇습니다.

백엔드: Laravel, Java Spring Boot, NestJS, Go
프런트엔드: JavaScript, CSS, Next.js, React Native
모바일: Flutter / Dart
인프라: AWS(EC2, RDS, Lambda 서버리스), Docker

그리고 아이 셋을 키우는 아빠입니다. 그래서 이 블로그에는 개발 이야기만큼이나 육아, 장비, 살림살이 이야기가 섞여 있습니다. 두 영역이 따로 노는 것 같지만 실제로는 비슷합니다. 문제를 정의하고, 가설을 세우고, 되는 방법을 찾을 때까지 굴려보는 일이라는 점에서요.

틈틈이 만든 토이 프로젝트도 있습니다. 아기 수면교육 앱 아기소리, 미세먼지 앱 클린에어, 키즈랜드, 포켓몬스터 도감 같은 것들인데, 대부분 “우리 집에 필요해서” 시작된 것들입니다. 공개한 코드 일부는 GitHub에서 보실 수 있습니다.

이런 글을 씁니다

개발
Laravel, SQL 튜닝, Java Spring, Go, NestJS, Next.js, Flutter 등 실무에서 막혔던 지점과 해결 과정을 다룹니다. 인덱스를 걸었는데도 느린 쿼리를 실행계획으로 잡는 법처럼, 검색해도 잘 안 나오는 중간 단계 이야기를 주로 씁니다.

AWS & 인프라
EC2, RDS, 서버리스 운영 경험과 비용 관리를 다룹니다. 청구서가 예상보다 튀었을 때 원인을 추적한 기록 같은 것들입니다.

IT 이야기
매주 월요일마다 지난주 기술 뉴스 중 개발자 입장에서 넘기기 어려운 것들을 골라 정리합니다. 요약에 그치지 않고 “그래서 내 프로젝트에 뭘 해야 하는가”까지 적으려고 합니다.

장비 후기
직접 사서 최소 한 달 이상 써본 것만 씁니다. 키보드, 마우스, 허브처럼 하루 종일 손이 닿는 물건들이 대부분입니다. 좋았던 점뿐 아니라 사고 나서 후회한 것도 같이 적습니다.

일상 & 육아
아이 셋 키우면서 실제로 효과를 본 방법과 실패한 방법을 기록합니다. 육아 TIP, 육아 장비, 부부생활, 운동 일지 등이 여기 속합니다.

글을 쓸 때 지키는 것들

직접 겪은 것만 씁니다. 써보지 않은 장비는 후기를 쓰지 않고, 돌려보지 않은 코드는 올리지 않습니다.
실패도 같이 씁니다. 성공담만 있으면 읽는 사람이 판단할 근거가 부족하다고 생각합니다.
출처를 밝힙니다. 뉴스나 외부 자료를 인용한 경우 어디서 온 내용인지 표기합니다.
광고와 제휴를 숨기지 않습니다. 제휴 링크가 포함된 글에는 해당 사실을 본문에 명시합니다. 자세한 내용은 개인정보처리방침에 정리해 두었습니다.
틀린 건 고칩니다. 잘못된 정보를 발견하면 글을 수정하고, 내용이 크게 바뀐 경우 그 사실을 남깁니다.

문의 및 소통

이 블로그의 문의 창구는 각 게시글의 댓글입니다. 글에 대한 질문, 잘못된 내용 제보, 추가로 다뤄줬으면 하는 주제 모두 해당 글 아래 댓글로 남겨주시면 확인 후 답변드립니다. 다른 분들에게도 도움이 되는 경우가 많아서 공개 댓글을 기본 창구로 두고 있습니다.

공개하기 곤란한 내용이라면 댓글 작성 시 비밀 댓글로 남겨주세요. 방명록도 열려 있습니다.

개인정보 관련 요청 등 별도 처리가 필요한 사안은 private@lovizu.com 으로 보내주시면 됩니다.

답변은 보통 며칠 안에 드리지만, 회사 일과 육아가 겹치는 주에는 조금 늦어질 수 있습니다. 양해 부탁드립니다.

블로그 정보

블로그명: 감성 개발자
주소: https://lovizu.com
운영자: Lovizu
개설: 2018년 8월
플랫폼: 티스토리(TISTORY)
문의: 각 게시글 댓글 / 방명록
이메일: private@lovizu.com
개인정보처리방침

읽어주셔서 감사합니다. 어느 글에서든 한 줄이라도 도움이 되셨다면 그걸로 충분합니다.

개인정보처리방침

Lovizu — Fri, 28 Aug 2026 13:23:50 +0900

개인정보처리방침

감성 개발자(lovizu.com, 이하 ‘본 블로그’)는 방문자의 개인정보를 소중하게 생각하며, 「개인정보 보호법」 및 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」 등 관련 법령을 준수합니다. 본 방침은 본 블로그가 어떤 정보를 수집하고, 어떤 목적으로 이용하며, 어떤 제3자 서비스가 관여하는지를 안내합니다.

본 블로그는 카카오가 운영하는 티스토리(TISTORY) 플랫폼 위에서 운영되는 개인 블로그입니다. 별도의 회원가입, 상품 판매, 결제, 배송 절차가 없습니다.

1. 수집하는 정보와 수집 방법

가. 자동으로 수집되는 정보
방문자가 본 블로그를 이용하는 과정에서 아래 정보가 자동으로 생성되어 수집될 수 있습니다.

IP 주소, 쿠키, 방문 일시, 체류 시간, 서비스 이용 기록
브라우저 종류 및 버전, 운영체제, 기기 정보, 화면 해상도
유입 경로(referrer) 및 검색어

나. 방문자가 직접 입력하는 정보

댓글 및 방명록 작성 시: 닉네임, 비밀번호(비회원 작성 시), 이메일 주소 또는 홈페이지 주소(선택 입력)
이메일로 문의하는 경우: 이메일 주소 및 문의 내용에 포함된 정보

본 블로그는 주민등록번호, 계좌정보, 결제정보 등 민감정보 및 고유식별정보를 일절 수집하지 않습니다.

2. 개인정보의 이용 목적

블로그 콘텐츠 제공 및 이용 환경 개선
댓글 및 방명록 운영, 문의 사항에 대한 답변
방문 통계 분석을 통한 콘텐츠 개선
맞춤형 광고를 포함한 광고 게재 및 광고 성과 측정
부정 이용(스팸, 도배, 악성 댓글) 방지

3. 쿠키(Cookie)의 사용

본 블로그는 방문자에게 더 나은 이용 환경과 관련성 높은 광고를 제공하기 위해 쿠키를 사용합니다. 쿠키는 웹사이트가 방문자의 브라우저에 저장하는 아주 작은 텍스트 파일로, 방문 기록과 설정을 기억하는 데 사용됩니다.

방문자는 쿠키 저장을 거부할 권리가 있습니다. 브라우저 설정에서 모든 쿠키를 허용하거나, 저장될 때마다 확인을 거치거나, 모든 쿠키의 저장을 거부할 수 있습니다.

Chrome: 설정 > 개인 정보 보호 및 보안 > 서드 파티 쿠키
Safari: 설정 > 개인정보 보호 > 쿠키 및 웹 사이트 데이터
Edge: 설정 > 쿠키 및 사이트 권한 > 쿠키 및 사이트 데이터 관리
Firefox: 설정 > 개인 정보 및 보안 > 쿠키와 사이트 데이터

다만 쿠키 저장을 거부할 경우 일부 기능의 이용에 불편이 있을 수 있습니다.

4. 제3자 광고 서비스 및 Google 애드센스

본 블로그는 Google 애드센스(Google AdSense)를 이용해 광고를 게재합니다. 이와 관련하여 아래 사항을 안내드립니다.

Google을 포함한 제3자 광고 공급업체는 쿠키를 사용하여 방문자가 본 블로그 및 인터넷상의 다른 웹사이트를 방문한 기록을 바탕으로 광고를 게재합니다.
Google은 광고 게재를 위해 DoubleClick DART 쿠키를 포함한 광고 쿠키를 사용할 수 있습니다.
본 블로그에 게재되는 광고로 인해 제3자가 방문자의 브라우저에 쿠키를 삽입하거나 읽을 수 있으며, 웹 비콘(web beacon) 또는 IP 주소를 통해 정보를 수집할 수 있습니다.
이 과정에서 수집되는 정보는 광고 게재 및 성과 측정 목적으로만 사용되며, 본 블로그 운영자는 해당 데이터에 직접 접근하거나 이를 식별할 수 없습니다.

맞춤 광고를 원하지 않으실 경우 아래 링크에서 직접 설정을 변경하실 수 있습니다.

Google 광고 설정에서 맞춤 광고 사용 중지: https://adssettings.google.com
Google의 광고 관련 개인정보 처리 안내: https://policies.google.com/technologies/ads
Google 파트너 사이트 이용 시 Google의 데이터 사용 방식: https://policies.google.com/technologies/partner-sites
제3자 광고 공급업체 일괄 수신 거부(미국 DAA): https://www.aboutads.info/choices
유럽 지역 수신 거부(EDAA): https://www.youronlinechoices.com

5. 제휴 마케팅 고지

본 블로그의 일부 게시물에는 쿠팡 파트너스 등 제휴 마케팅 링크가 포함될 수 있습니다. 해당 링크를 통해 구매가 이루어질 경우 운영자가 일정액의 수수료를 제공받으며, 이는 각 게시물 내에 명시합니다. 제휴 링크 클릭 시 해당 제휴사의 쿠키가 브라우저에 저장될 수 있으며, 이후의 개인정보 처리는 해당 제휴사의 개인정보처리방침을 따릅니다.

6. 방문 통계 및 분석 도구

본 블로그는 콘텐츠 개선을 위해 티스토리(카카오)가 제공하는 기본 방문 통계 기능을 이용하며, 필요에 따라 Google Analytics 및 Google Search Console을 사용할 수 있습니다. 이들 도구는 쿠키 및 유사 기술을 통해 익명화된 이용 행태 정보를 수집합니다. Google Analytics의 데이터 수집을 원하지 않으실 경우 Google Analytics 차단 브라우저 부가기능을 설치하실 수 있습니다.

7. 개인정보의 제3자 제공 및 처리 위탁

본 블로그는 방문자의 개인정보를 제3자에게 판매하거나 임의로 제공하지 않습니다. 다만 아래의 경우는 예외로 합니다.

방문자가 사전에 명시적으로 동의한 경우
법령의 규정에 의하거나, 수사 목적으로 법령에 정해진 절차와 방법에 따라 수사기관의 요구가 있는 경우

또한 본 블로그는 티스토리 플랫폼 위에서 운영되므로, 블로그 서비스 제공 및 데이터 보관은 주식회사 카카오가 담당하며 해당 부분은 카카오의 개인정보처리방침을 따릅니다. 광고 게재와 관련된 데이터 처리는 Google LLC가 담당합니다.

8. 개인정보의 보유 및 파기

댓글 및 방명록: 작성자가 삭제하거나 운영자가 삭제할 때까지 보관하며, 삭제 시 지체 없이 파기합니다.
접속 로그 및 쿠키: 각 서비스 제공자(카카오, Google)의 정책에 따라 보관 후 파기됩니다.
문의 이메일: 답변 완료 후 1년 이내 파기합니다.

전자적 파일 형태의 정보는 복구 및 재생이 불가능한 방법으로 영구 삭제합니다.

9. 정보주체의 권리와 행사 방법

방문자는 언제든지 아래 권리를 행사할 수 있습니다.

개인정보 열람 요구
오류가 있을 경우 정정 요구
삭제 요구
처리 정지 요구

위 권리는 본 방침 하단의 이메일을 통해 요청하실 수 있으며, 운영자는 지체 없이 조치합니다. 댓글과 방명록은 방문자가 직접 삭제할 수 있습니다.

10. 만 14세 미만 아동의 개인정보

본 블로그는 만 14세 미만 아동을 대상으로 하지 않으며, 만 14세 미만 아동의 개인정보를 고의로 수집하지 않습니다. 만 14세 미만 아동의 정보가 수집된 사실을 인지할 경우 즉시 파기합니다.

11. 외부 링크에 대한 책임

본 블로그에는 외부 웹사이트로 연결되는 링크가 포함되어 있습니다. 링크된 사이트에서 이루어지는 개인정보 수집 및 처리에 대해서는 본 블로그가 책임지지 않으며, 해당 사이트의 개인정보처리방침을 확인하시기 바랍니다.

12. 개인정보의 안전성 확보 조치

본 블로그는 개인정보 보호를 위해 관리자 계정에 2단계 인증을 적용하고, HTTPS를 통한 암호화 통신을 사용하며, 수집되는 정보를 목적 달성에 필요한 최소한으로 제한하고 있습니다.

13. 개인정보 보호책임자 및 문의처

블로그명: 감성 개발자 (lovizu.com)
개인정보 보호책임자: Lovizu (운영자)
문의 이메일: private@lovizu.com

개인정보 침해에 대한 신고나 상담이 필요하신 경우 아래 기관에 문의하실 수 있습니다.

개인정보침해신고센터 (privacy.kisa.or.kr / 국번없이 118)
개인정보 분쟁조정위원회 (www.kopico.go.kr / 1833-6972)
대검찰청 사이버수사과 (www.spo.go.kr / 국번없이 1301)
경찰청 사이버수사국 (ecrm.police.go.kr / 국번없이 182)

14. 개인정보처리방침의 변경

본 개인정보처리방침의 내용에 추가, 삭제 및 수정이 있을 경우 시행 7일 전부터 본 페이지를 통해 고지합니다.

본 방침 시행일: 2026년 8월 28일

개학하고 알았다, 초등 공부 습관도 장비빨이다: 아이 셋 아빠의 책상 셋업 5가지 (LED 스탠드, 타임타이머, 독서대)

Lovizu — Fri, 28 Aug 2026 03:08:19 +0900

지난주에 개학 전 생활 리듬 복구 작전이라는 글을 썼다. 수면 시간 되돌리고, 아침 루틴 다시 세우고, 준비물 체크리스트 만들고. 그런데 개학하고 일주일을 지켜보니 하나가 더 남아 있었다. 아이들 책상이다. 방학 두 달 동안 책상은 공부하는 곳이 아니라 잡동사니 두는 곳이었다. 레고 부품, 슬라임 통, 어디서 났는지 모를 스티커들. 첫째를 앉혀놓고 숙제를 시키는데 10분을 못 버티고 일어난다. 조명은 어둡고, 책은 바닥에 눕혀져 있고, 시간 개념은 없고.

결국 또 결론은 같은 데로 갔다. 육아는 장비빨이다. 이 카테고리에 글을 쓰는 게 몇 년 만인지 모르겠는데, 그때는 분유 포트와 역류방지 쿠션 이야기를 했었다. 애들이 크니까 장비도 같이 큰다. 이번에는 초등학생 책상 셋업이다. 개학하고 2주 동안 하나씩 들이면서 정리한, 실제로 효과 본 장비 다섯 가지를 쓴다.

사진: Anis Rahman / Unsplash

1. LED 책상 스탠드, 방 등만 믿으면 안 된다

제일 먼저 바꾼 게 조명이다. 아이들 방은 천장 등 하나로 버티고 있었는데, 저녁에 책상에 앉으면 아이 그림자가 공책 위로 떨어진다. 본인 머리 그림자 속에서 받아쓰기를 하고 있는 셈이다. 어른인 나도 그 자리에서 책을 읽어보니 눈이 금방 피곤했다.

학습용 LED 스탠드는 가격대가 생각보다 넓다. 레토 같은 브랜드의 시력보호 스탠드는 1만 원 중후반이면 사고, 필립스 학습 스탠드는 2만 원대 중반부터, 아이클 같은 학습 전문 브랜드는 4~5만 원대, 와이드형으로 가면 8만 원을 넘는다. 나는 첫째 책상에는 팔이 길고 광폭인 4만 원대 제품을, 둘째 책상에는 2만 원대 기본형을 놨다. 다 써보고 느낀 기준은 세 가지다.

플리커 프리인지. 눈에 안 보이는 깜빡임이 있는 저가 제품은 오래 앉아 있으면 피로가 다르다. 상세페이지에 플리커 프리 표기가 없으면 거른다.
밝기와 색온도 조절이 되는지. 숙제할 때는 하얀빛(주광색), 자기 전 책 읽을 때는 노란빛(전구색)으로 바꿔 쓴다. 이게 되는 것과 안 되는 것의 활용도 차이가 크다.
헤드가 넓은지. 초등 교과서와 공책을 나란히 펴면 생각보다 넓다. 헤드가 좁으면 조명 범위 밖으로 공책이 나간다.

참고로 스탠드를 켰다고 방 천장 등을 끄면 안 된다. 주변은 어둡고 책상만 밝으면 명암 차이 때문에 눈이 더 피곤해진다. 안과에서 아이 검진받을 때 들은 이야기도 같았다. 방 전체 조명을 켠 상태에서 책상 스탠드를 보조로 쓰는 게 기본이고, 책과 눈 사이 거리를 30cm 이상 유지하는 게 조명보다 중요하다고 했다. 장비는 거들 뿐이라는 걸 안과에서도 확인받은 셈이다.

조명 하나 바꿨다고 애가 갑자기 공부를 잘하게 되지는 않는다. 그런데 책상 앞에 앉아 있는 시간이 눈에 띄게 늘었다. 밝고 또렷한 자리는 앉을 맛이 난다. 이건 어른 데스크 셋업이랑 똑같다.

2. 타임타이머, 시간이 눈에 보여야 아이가 움직인다

사진: Joan Tran / Unsplash

개발자들이 뽀모도로 타이머 쓰는 이유랑 똑같다. 아이들은 "30분만 하자"는 말을 이해하지 못한다. 30분이라는 시간이 몸으로 안 잡히기 때문이다. 그래서 들인 게 타임타이머다. 흔히 구글타이머라고 부르는 그 물건이다. 다이얼을 돌리면 남은 시간이 빨간 부채꼴로 표시되고, 시간이 지날수록 빨간 영역이 줄어든다. 남은 시간이 눈에 보인다는 게 핵심이다.

정품 타임타이머는 3만 원대라 살짝 망설였는데, 요즘은 같은 방식의 무소음 타이머가 1만 원대 초중반에 많이 나온다. 우리 집은 1만 원대 제품으로 시작했고 지금까지 문제없이 쓴다. 초침 소리 없는 무소음인지만 확인하면 된다. 소리 나는 제품은 애가 타이머 구경하느라 공부를 안 한다.

쓰는 방식은 단순하다. 숙제 시작 전에 아이가 직접 다이얼을 돌리게 한다. "20분 하고 쉬자"를 아이 손으로 세팅하는 것. 이게 은근히 중요하다. 아빠가 돌리면 감시가 되고, 자기가 돌리면 약속이 된다. 빨간 영역이 다 사라지면 무조건 일어나서 쉰다. 40분씩 붙잡아두는 것보다 15~20분 집중하고 쉬는 쪽이 초등 저학년한테는 훨씬 잘 맞았다.

어른 뽀모도로가 25분 집중, 5분 휴식이라면 우리 집 초등 버전은 20분 집중, 10분 휴식으로 정착했다. 휴식이 더 긴 게 포인트다. 쉬는 시간이 짧으면 아이는 쉰 것 같지가 않아서 다음 바퀴 협상이 어려워진다. 넉넉하게 쉬게 해주는 대신 타이머가 울리면 바로 다시 앉는다는 약속을 지키게 하는 쪽이 오래갔다.

3. 독서대, 목 각도가 집중력이다

아이들이 책을 볼 때 자세를 옆에서 보면 거의 목이 직각으로 꺾여 있다. 책이 바닥에 평평하게 누워 있으니 당연하다. 나도 모니터 암 달고 목 통증이 줄어든 경험이 있어서, 애들 책상에도 독서대를 하나씩 올려놨다.

독서대는 비쌀 이유가 없는 물건이다. 1만 원대 초반이면 각도 조절 되는 철제나 플라스틱 독서대를 산다. 고를 때 본 건 두 가지다. 교과서를 펼쳤을 때 페이지를 눌러주는 고정 클립이 튼튼한지, 그리고 문제집을 올려도 안 넘어가는 크기인지. 너무 작은 휴대용은 초등 전과목 문제집 무게를 못 버틴다.

부수 효과가 하나 있는데, 책이 세워져 있으면 책상 위 공간이 넓어진다. 공책 쓸 자리가 나오니까 책 밑에 팔을 구겨 넣고 쓰는 이상한 자세가 사라졌다.

4. 발받침, 의자에서 다리가 대롱대롱 뜨면 집중은 없다

사진: Aleksandra Dementeva / Unsplash

이건 셋째 때문에 알게 된 거다. 아이가 의자에 앉으면 발이 바닥에 안 닿는다. 발이 뜨면 아이는 계속 몸을 비튼다. 다리를 의자 위로 올렸다가, 양반다리를 했다가, 결국 의자에서 내려온다. 산만해서가 아니라 자세가 불안정해서 그런 거였다.

높이 조절되는 발받침이 1~2만 원대면 있다. 발이 닿는 면이 생기니까 앉은 자세가 잡히고, 자세가 잡히니까 버티는 시간이 늘었다. 성장기 애들은 책상 의자 높이가 몸에 안 맞는 구간이 계속 생기는데, 의자를 매번 바꿀 수는 없으니 발받침으로 맞추는 게 현실적이다. 원래는 사무용 제품인데 아이 책상 밑에 더 잘 어울린다.

5. 책상 정리함, 비우는 게 먼저고 정리함은 그다음

마지막은 제일 싼 장비다. 책상 위 잡동사니는 정리함이 없어서가 아니라 버리지 않아서 쌓인다. 그래서 먼저 아이랑 같이 책상을 싹 비웠다. 학용품만 남기고 장난감은 전부 다른 수납함으로 이사. 그다음에 연필꽂이 하나, 서랍형 정리함 하나만 올렸다. 다이소나 온라인에서 5천 원에서 1만 원이면 충분하다.

정리함과 같이 굴리는 의식이 하나 있다. 일요일 저녁 10분 책상 리셋이다. 다음 주 시간표를 보면서 필요한 교과서를 책꽂이 맨 앞으로 빼고, 연필 깎아서 연필꽂이 채우고, 지우개 가루 털어내는 것까지가 한 세트다. 처음엔 내가 다 해줬는데 지금은 옆에서 보고만 있어도 아이가 순서대로 한다. 월요일 아침에 준비물 찾는 소동이 확실히 줄었다.

규칙은 하나만 세웠다. "책상 위에는 지금 하는 과목만 올라온다." 물론 3일에 한 번씩 무너진다. 그래도 정리된 상태의 기본값이 있으면 되돌리는 데 5분이면 된다. 기본값이 없으면 매번 대청소다. 코드 리팩토링이랑 비슷하다. 깨끗한 기준 상태가 있어야 어디가 어질러졌는지 보인다.

2주 굴려본 결과, 저녁 풍경이 달라졌다

장비를 다 들이고 2주를 굴려봤다. 수치로 말할 수 있는 변화는 이렇다. 첫째가 책상에 한 번 앉아서 버티는 시간이 10분 안팎에서 타이머 한 바퀴, 그러니까 20분 정도로 늘었다. 하루에 두 바퀴 돌면 40분이고, 초등학생 숙제는 그 안에 대부분 끝난다. 예전에는 저녁 8시부터 9시 반까지 숙제 하나를 붙잡고 온 집안이 소모전을 했는데, 지금은 저녁 먹고 두 바퀴 돌리면 8시 반 전에 상황이 종료된다.

부모 입장에서 제일 큰 변화는 잔소리의 내용이 바뀐 거다. 예전에는 "똑바로 앉아", "불 켜고 해", "언제까지 할 거야"가 잔소리의 삼대장이었다. 조명, 자세, 시간을 전부 부모 입으로 관리하고 있었던 셈이다. 지금은 그 세 가지를 장비가 대신한다. 스탠드는 켜져 있고, 발은 발받침에 올라가 있고, 남은 시간은 타이머가 보여준다. 남은 잔소리는 "시작하자" 하나다. 하나도 안 하는 것보단 못하지만, 셋에서 하나로 줄인 것만으로 저녁의 피로도가 다르다.

사놓고 후회한 장비도 있다

성공담만 쓰면 반칙이니까 실패한 것도 적는다. 첫 번째는 캐릭터 책상 매트다. 아이가 좋아하는 캐릭터가 크게 그려진 데스크 매트를 깔아줬더니, 숙제하다 말고 매트 그림을 구경한다. 책상 위 시야에는 심심한 게 낫다. 지금은 무지 단색 매트로 바꿨고, 캐릭터 매트는 거실 그림 그리는 자리로 강등됐다.

두 번째는 스터디 플래너다. 문구점에서 초등학생용 플래너를 사 왔는데, 초등 저학년한테 하루 계획을 글로 쓰게 하는 건 숙제 위에 숙제를 얹는 일이었다. 사흘 쓰고 서랍행. 대신 A4 화이트보드에 오늘 할 일을 아빠가 세 줄로 써주고 아이가 끝날 때마다 지우는 방식으로 바꿨더니 이건 굴러간다. 쓰는 부담은 부모가 지고, 아이는 지우는 재미만 가져가는 구조라 그런 것 같다. 화이트보드는 5천 원짜리다.

세 번째는 각도 조절되는 높이조절 책상 상판 같은 고급 장비 욕심이다. 결론부터 말하면 아직 초등 저학년 구간에서는 과했다. 아이는 상판 각도를 조절하는 게 아니라 그걸 미끄럼틀로 쓴다. 지금 단계에서는 싸고 단순한 장비 여러 개가 비싸고 복잡한 장비 하나보다 낫다는 게 내 결론이다.

아이 셋 집이라 생긴 운영 노하우

애가 셋이면 장비 문제가 아니라 자리 배치 문제가 하나 더 붙는다. 우리 집에서 한 방에 책상 두 개를 붙여놨던 시절이 있는데, 형제가 나란히 앉으면 공부가 아니라 합동 장난이 시작된다. 지금은 책상 방향을 서로 등지게 돌려놨다. 같은 방을 쓰더라도 시야에 서로가 안 들어오게만 해도 간섭이 확 준다. 이건 돈 안 드는 장비빨이다.

장비를 들일 때도 순서를 정했다. 셋 다 한 번에 풀세팅해주면 좋겠지만 그러면 지갑이 남아나지 않는다. 학년이 높은 순서, 그러니까 책상에 앉아 있어야 하는 시간이 긴 순서대로 먼저 세팅했다. 첫째 것을 세팅하면서 둘째가 구경하게 놔두면, 둘째는 자기 차례가 왔을 때 장비를 선물로 받아들인다. 같은 물건도 순서가 만들어주는 기대감이 있다.

그리고 타이머는 결국 한 명당 하나씩 샀다. 하나로 돌려쓰게 했더니 "쟤가 내 시간 뺏었다"는 분쟁이 생긴다. 형제 있는 집은 공유 장비가 분쟁 장비가 되는 경우가 많다. 1만 원대 물건은 그냥 사람 수대로 사는 게 평화 비용으로 싸다.

돈으로 정리하면

다섯 가지 다 합쳐도 10만 원 안쪽으로 맞출 수 있다. 스탠드 2~4만 원, 타이머 1만 원대, 독서대 1만 원대, 발받침 1~2만 원, 정리함 1만 원 이하. 학원 한 달 보내는 비용보다 싸다. 그리고 경험상 이건 소모품이 아니라 몇 년 쓰는 물건들이다.

구입 우선순위를 묻는다면 이렇게 답하겠다. 1순위는 조명이다. 눈 건강 문제라서 효과 논쟁의 여지가 없다. 2순위는 타이머. 습관 만들기의 핵심 장비다. 3순위가 발받침처럼 자세를 잡아주는 물건이고, 독서대와 정리함은 있으면 좋은 마무리 장비다. 예산이 3만 원뿐이라면 스탠드 하나와 타이머 하나만 사도 책상의 체감이 달라진다.

오해는 하지 말자. 장비를 사줬다고 아이가 알아서 공부하는 일은 없다. 우리 집도 여전히 숙제 시작 전까지 실랑이를 한다. 다만 장비가 해주는 건 마찰을 줄이는 거다. 어두워서 눈이 피곤하고, 시간 개념이 없어서 끝이 안 보이고, 자세가 불편해서 몸이 배기는, 그런 물리적인 핑계들을 하나씩 없애 놓으면 남는 건 습관 싸움뿐이다. 습관 싸움은 부모가 같이 해줘야 하는 영역이고, 장비는 그 싸움의 난이도를 낮춰준다.

분유 포트 쓰던 시절에는 장비가 부모를 편하게 해줬는데, 초등 시기의 장비는 아이의 환경을 만들어주는 쪽에 가깝다. 다음 장비빨 글은 아마 아이들 첫 키즈폰이나 태블릿 거치대가 되지 않을까 싶다. 그건 그것대로 고민이 깊은 물건이라, 정리되면 또 쓰겠다.

개발자 아빠의 스마트홈 구축기: 홈어시스턴트(Home Assistant)로 IoT 앱 지옥 탈출한 후기

Lovizu — Thu, 27 Aug 2026 03:09:12 +0900

우리 집에는 스마트 기기가 꽤 많다. 샤오미 공기청정기, 스마트 플러그, 거실 조명, 현관 도어센서, 아이 방 온습도계까지. 문제는 이걸 제어하는 앱이 전부 따로 놀았다는 거다. 공기청정기는 미홈 앱, 조명은 또 다른 앱, 플러그는 헤이홈 앱. 아내가 "불 좀 꺼줘"라고 하면 폰에서 앱을 세 번 갈아타야 했다. 스마트홈이 아니라 앱 지옥이었다.

그래서 작년에 홈어시스턴트(Home Assistant)를 집에 들였다. 결론부터 말하면, 지금은 우리 집 인프라의 중심이 됐고, 아이 셋 키우는 집에서 이게 없던 시절로 돌아가라면 못 돌아간다. 오늘은 개발자 아빠 관점에서 홈어시스턴트 도입기를 정리해본다.

사진: BENCE BOROS, Unsplash

홈어시스턴트가 뭔가, 왜 필요한가

홈어시스턴트는 오픈소스 스마트홈 허브 소프트웨어다. 집에 있는 작은 서버(라즈베리파이나 미니PC)에 설치해두면, 제조사가 제각각인 IoT 기기들을 한 화면에서 모아 제어하고 자동화할 수 있다. 샤오미든 스마트싱스든 필립스 휴든 IKEA든, 웬만한 기기는 다 붙는다. 공식 통합구성요소(Integration)가 수천 개 수준이라 "이게 될까?" 싶은 기기도 검색해보면 대부분 누가 이미 붙여놨다.

내가 느낀 핵심 가치는 세 가지다.

첫째, 파편화 해소. 앱 여러 개 오가던 걸 대시보드 하나로 끝낸다. 거실 벽에 안 쓰는 태블릿 하나 걸어두고 대시보드를 띄워놨더니, 아내도 아이들도 그냥 터치해서 쓴다. 가족 만족도가 올라가는 지점이 바로 여기다.

둘째, 클라우드 독립. 제조사 앱은 대부분 중국이나 미국 서버를 거친다. 서버 장애가 나면 내 집 조명이 안 켜지는 황당한 구조다. 홈어시스턴트는 로컬 네트워크에서 도는 게 기본이라, 인터넷이 끊겨도 집 안 자동화는 그대로 돈다. 개발자 입장에서 이 아키텍처가 제일 마음에 들었다.

셋째, 자동화. 이게 진짜다. "제어"는 시작일 뿐이고, 결국 스마트홈의 완성은 내가 아무것도 안 해도 알아서 돌아가는 상태다. 뒤에서 실제 예시로 설명한다.

설치: 라즈베리파이냐 미니PC냐

홈어시스턴트를 돌리는 방법은 크게 세 가지다.

1. 라즈베리파이에 HAOS 설치 — 공식 권장 입문 코스. SD카드에 이미지 굽고 꽂으면 끝이다. 다만 SD카드는 수명 문제가 있어서 장기 운영하려면 SSD 부팅을 권한다.

2. 미니PC에 HAOS 또는 프록스목스 — 내가 최종 정착한 방식. 중고 미니PC(인텔 N100급이면 충분하다)를 10만 원대에 구해서 올리면 라즈베리파이보다 훨씬 여유롭다. 애드온을 이것저것 올려도 안 버벅인다.

3. 도커 컨테이너 — 이미 홈서버가 있는 사람용. 다만 컨테이너 방식은 애드온 스토어를 못 쓰기 때문에, 처음이라면 HAOS(운영체제째 설치)를 추천한다. 백업, 업데이트, 애드온 관리가 다 UI에서 된다.

개발자라면 도커가 익숙하니 3번이 끌리겠지만, 스마트홈 서버는 "잘 돌아가고 신경 안 쓰이는 것"이 최우선이다. 나도 처음엔 도커로 시작했다가 결국 HAOS로 갈아탔다. 집 인프라는 취미 프로젝트가 아니라 운영 서비스다. 장애 나면 항의하는 고객(아내)이 바로 옆에 있다.

도입 첫 주에 내가 한 일

설치 자체는 한 시간이면 끝난다. 진짜 작업은 그다음부터다. 내 도입 첫 주 기록을 순서대로 남겨두면 이렇다.

1일차 — HAOS 설치, 초기 계정 생성, 같은 네트워크에 있던 기기 자동 발견. 홈어시스턴트는 네트워크를 스캔해서 붙일 수 있는 기기를 알아서 찾아준다. 샤오미 공기청정기와 로봇청소기가 설치 10분 만에 대시보드에 떴을 때 살짝 소름이 돋았다.

2~3일차 — 미홈, 스마트싱스 계정 연동. 클라우드 계정을 한 번 연결해주면 그 계정에 물린 기기가 통째로 들어온다. 이 시점에 이미 앱 세 개가 대시보드 하나로 합쳐졌다.

4~5일차 — 모바일 앱 설치와 가족 구성원 등록. 홈어시스턴트 공식 앱을 깔면 폰이 곧 재실 센서가 된다. 누가 집에 있는지, 언제 나갔는지를 자동화의 조건으로 쓸 수 있게 된다. 위치 정보는 우리 집 서버에만 쌓이니 제조사 클라우드에 가족 동선을 올리는 것보다 마음이 편하다.

주말 — 첫 자동화 작성. 거창한 것 말고 "해 지면 거실 무드등 켜기" 하나만 만들었다. 작게 시작해서 하나씩 늘리는 게 요령이다. 처음부터 집 전체를 자동화하려고 하면 반드시 어딘가에서 꼬인다. 이건 소프트웨어 프로젝트랑 똑같다.

사진: Dan LeFebvre, Unsplash

기기 연동: 지그비 동글 하나가 세계를 바꾼다

와이파이 기기는 통합구성요소로 바로 붙는다. 진짜 재미는 지그비(Zigbee)부터다. USB 지그비 동글(코디네이터)을 하나 꽂고 Zigbee2MQTT나 ZHA를 올리면, 제조사 허브 없이 지그비 센서를 직접 붙일 수 있다.

이게 왜 좋냐면, 알리익스프레스에서 파는 몇천 원짜리 온습도계, 도어센서, 모션센서를 허브 없이 수십 개 붙일 수 있기 때문이다. 샤오미 허브, 이케아 허브, 스마트싱스 허브를 각각 살 필요가 없다. 지그비는 메시 네트워크라 기기가 늘수록 오히려 통신이 안정된다.

우리 집 기준으로 현재 붙어 있는 것들: 각 방 온습도 센서, 현관·베란다 도어센서, 복도 모션센서, 거실·안방 조명, 스마트 플러그 여러 개, 공기청정기, 로봇청소기, 월패드 연동까지. 처음엔 기기 5개로 시작했는데 어느새 50개가 넘었다. 이 바닥이 원래 그렇다. 입문 비용보다 중독 비용이 크다.

자동화 실전: 아이 셋 집에서 실제로 쓰는 것들

홈어시스턴트의 자동화는 "트리거 → 조건 → 액션" 구조다. 개발자에게는 이벤트 드리븐 아키텍처 그 자체라 금방 익숙해진다. 우리 집에서 실제로 돌아가는 자동화 몇 개를 소개한다.

아이 방 온습도 관리 — 아이 방 습도가 40% 밑으로 떨어지면 가습기 플러그를 켜고, 60%를 넘으면 끈다. 겨울철 아이들 감기 관리에 이만한 게 없다. 온습도 이력이 그래프로 쌓이니까 "어젯밤 방이 건조했나?" 같은 질문에 데이터로 답할 수 있다.

외출 모드 — 가족 전원의 폰이 집 와이파이에서 사라지면 조명과 대기전력 플러그를 일괄 차단한다. 아이 셋 데리고 외출하는 날 아침은 전쟁터라 "불 껐나?" 확인할 정신이 없는데, 이건 그냥 알아서 된다.

심야 복도 조명 — 밤 10시 이후 복도 모션센서가 감지되면 조명을 최저 밝기로 켠다. 애들이 밤에 화장실 갈 때 환한 불 때문에 잠이 깨는 걸 막아준다. 사소해 보여도 체감 효과는 크다.

세탁 완료 알림 — 세탁기 플러그의 전력 사용량이 일정 시간 바닥으로 떨어지면 "세탁 끝났습니다" 알림을 부부 폰에 쏜다. 스마트 세탁기가 아니어도 플러그 하나로 스마트 세탁기가 된다.

이런 자동화가 하나씩 쌓이면 어느 순간 집이 알아서 돌아간다. 손으로 하던 일을 시스템이 대신하는 경험, 개발자가 코드로 하던 그 일을 집에서 하는 셈이다.

사진: Jakub Zerdzicki, Unsplash

HACS, 커스텀의 세계

기본 기능만으로도 충분하지만, 개발자라면 결국 HACS(Home Assistant Community Store)를 만나게 된다. 커뮤니티가 만든 커스텀 통합과 대시보드 카드를 설치할 수 있는 비공식 스토어인데, 국내 사용자에게 특히 유용하다. 공식 통합이 없는 국내 서비스들, 예를 들어 아파트 월패드 연동이나 국내 가전 연동 같은 것들이 커뮤니티의 손으로 HACS에 올라와 있는 경우가 많다.

대시보드 쪽도 마찬가지다. 기본 카드만 쓰면 밋밋한데, 커뮤니티 카드 몇 개를 얹으면 벽걸이 태블릿에 띄워둘 만한 대시보드가 나온다. 다만 커스텀은 어디까지나 커스텀이라, 코어 업데이트 때 깨질 수 있다는 점은 감안해야 한다. 나는 "가족이 매일 쓰는 화면은 보수적으로, 내 실험용 화면은 자유롭게"라는 원칙으로 나눠서 운영한다.

외부 접속과 보안, 개발자라면 여기가 본론이다

집 밖에서 우리 집 상태를 보려면 외부 접속을 열어야 한다. 방법은 크게 세 가지다. 공식 클라우드 구독(월 몇 달러로 제일 간단하다), 테일스케일 같은 VPN(무료이고 안전하지만 가족 폰에 전부 깔아야 한다), 그리고 도메인과 리버스 프록시로 직접 여는 방법.

나는 직접 여는 쪽을 택했다. 개인 도메인에 서브도메인을 파고, 리버스 프록시 뒤에 홈어시스턴트를 두고, HTTPS 인증서를 물렸다. 여기서 강조하고 싶은 건 보안이다. 집 서버를 인터넷에 노출하는 순간부터는 운영자의 책임이 시작된다. 최소한 이것만은 지키자.

첫째, 2단계 인증(MFA)을 무조건 켠다. 홈어시스턴트 자체에 TOTP 기능이 내장돼 있다. 둘째, 로그인 시도 제한을 걸어 무차별 대입을 차단한다. 셋째, 관리자 계정과 가족 계정을 분리한다. 아이들 태블릿에 관리자 세션을 남겨두는 건 서버 루트 비밀번호를 거실에 붙여두는 것과 같다. 넷째, 백업은 외부 저장소에도 복사해둔다. 서버가 죽어도 설정은 살아야 한다.

이 과정 자체가 미니 인프라 운영 경험이라, 주니어 개발자에게는 오히려 살아있는 공부가 된다. DNS, 인증서, 프록시, 인증, 백업까지 실무에서 쓰는 개념이 집 안에서 전부 등장한다.

비용은 얼마나 들었나

스마트홈은 돈 먹는 취미라는 인식이 있는데, 홈어시스턴트 기준으로 정리하면 생각보다 소박하게 시작할 수 있다.

서버는 중고 미니PC 기준 10만 원 안팎, 라즈베리파이를 이미 갖고 있다면 0원이다. 지그비 동글은 2~4만 원대. 지그비 센서류는 개당 3천 원에서 1만 원 사이라 문·모션·온습도 센서를 열 개 깔아도 10만 원이 안 된다. 스마트 플러그와 조명은 이미 쓰던 걸 그대로 붙이면 된다. 즉 30만 원 이하로 "우리 집이 달라졌다"를 체감할 수 있는 수준까지 간다. 소프트웨어는 전부 무료 오픈소스다.

오히려 조심해야 할 건 그다음이다. 붙는 게 재미있어서 센서를 계속 사게 되는 단계가 온다. 나도 "이번 달은 그만 산다"를 몇 번이나 번복했는지 모른다. 예산 상한을 정해두는 걸 추천한다.

단점도 분명히 있다

좋은 얘기만 하면 광고 글이다. 현실적인 단점을 적어둔다.

초기 러닝커브가 있다. 요즘 UI가 많이 좋아졌다고는 해도, YAML 설정을 만질 일이 아예 없지는 않다. 비개발자 배우자에게 관리까지 맡기긴 어렵다. 우리 집도 "사용"은 가족 모두가 하지만 "운영"은 내 몫이다.

업데이트 관리가 필요하다. 홈어시스턴트는 매달 새 버전이 나온다. 대부분 무난하지만 가끔 브레이킹 체인지가 있어서, 릴리즈 노트를 훑고 백업을 확인한 뒤 올리는 습관이 필요하다. 자동 백업 설정은 필수다.

시간을 잡아먹는다. 이게 제일 큰 단점일 수 있다. 대시보드 꾸미기, 자동화 다듬기가 은근히 재미있어서 주말 밤이 순삭된다. 취미가 하나 늘어난다고 생각하면 장점이고, 시간이 없는 사람에겐 부담이다.

스마트싱스 VS 홈어시스턴트, 뭔 골라야 하나

이 질문을 주변에서 자주 받는다. 내 답은 단순하다. 앞으로 기기를 얕게 쓰고 관리는 하기 싫다면 스마트싱스나 애플 홈 같은 상용 생태계가 맞다. 앱 설치하고 기기 등록하면 끝이고, 장애 대응도 제조사 몷이다. 반면 기기가 계속 늘어날 예정이고, 제조사 경계를 넘나드는 자동화를 원하고, 내 데이터를 내 서버에 두고 싶다면 홈어시스턴트다. 둘은 경쟁 관계라기보다 공존 관계에 가깝다. 실제로 나는 스마트싱스 계정을 홈어시스턴트에 물려서 같이 쓴다. 허브의 최종 지휘권만 홈어시스턴트가 가져가는 구조다.

참고로 요즘 IoT 업계는 매터(Matter)라는 표준으로 수렴하는 분위기다. 제조사 간 장벽이 낮아지는 방향은 분명한데, 그래도 "모든 기기를 한군데 모아 자동화하는 두뇌" 역할은 여전히 필요하다. 홈어시스턴트는 매터도 지원하니, 지금 시작해도 표준 전환기에 버려질 선택은 아니다.

누구에게 추천하나

추천: 집에 스마트 기기가 이미 5개 이상인데 앱이 다 따로 노는 사람, 서버나 도커를 다뤄본 개발자, 집 데이터(온습도·전력)를 쌓아보고 싶은 사람, 그리고 가족을 위한 자동화에서 재미를 느낄 아빠들.

비추: 스마트 기기가 한두 개뿐인 사람(그냥 제조사 앱 쓰는 게 낫다), 서버 한 대 관리도 스트레스인 사람, 설정보다 완제품을 원하는 사람은 애플 홈킷이나 스마트싱스 같은 상용 생태계가 맞다.

마무리

홈어시스턴트는 IoT 파편화 시대에 개발자가 선택할 수 있는 가장 강력한 답이라고 생각한다. 10만 원대 미니PC 한 대와 주말 이틀 정도의 시간이면 시작할 수 있다. 그리고 어느 날 아이가 "아빠, 우리 집은 밤에 불이 알아서 켜져"라고 친구에게 자랑하는 걸 듣게 되면, 그간의 삽질이 다 보상받는 기분이 든다.

다음에는 지그비 센서 구성과 실제 자동화 YAML 예시를 따로 정리해볼 생각이다. 스마트홈 입문을 고민 중이라면, 일단 안 쓰는 라즈베리파이나 중고 미니PC부터 알아보시길.

자바스크립트 없이 되는 요즘 CSS 정리: :has 선택자, 컨테이너 쿼리, popover 실전 후기

Lovizu — Wed, 26 Aug 2026 03:07:43 +0900

이 블로그를 오래 보신 분이라면 알겠지만, 나는 제이쿼리로 DOM을 주무르던 시절부터 웹을 만들어온 사람이다. 그 시절엔 뭐만 하려고 하면 자바스크립트였다. 아코디언 메뉴도 JS, 툴팁도 JS, 부모 요소 스타일 바꾸는 것도 JS. "CSS는 못 하니까"가 당연한 전제였다.

그런데 요 몇 년 사이에 그 전제가 꽤 많이 무너졌다. 최근에 사내 프로젝트 프론트 코드를 정리하다가, 예전에 자바스크립트로 짜놓은 UI 로직 중 상당수가 이제 CSS 몇 줄로 끝난다는 걸 새삼 확인했다. 실제로 걷어낸 코드가 몇백 줄이다. 오늘은 그 과정에서 실무에 바로 써먹은 모던 CSS 기능들을 정리해본다. 이론 나열이 아니라, "원래 JS로 이렇게 짰는데 지금은 이렇게 바꿨다"는 관점으로 쓴다.

사진: Unsplash, Florian Olivo

1. :has() — 드디어 생긴 부모 선택자

CSS에 부모 선택자가 없다는 건 20년 가까이 개발자들 단골 불평이었다. "자식 상태 보고 부모 스타일 바꾸기"는 무조건 자바스크립트 몫이었다.

전형적인 예가 폼 유효성 표시다. 예전엔 이런 코드를 짰다.

// 예전 방식: input 상태를 감시해서 부모에 클래스 토글
document.querySelectorAll('.form-field input').forEach((input) => {
  input.addEventListener('input', () => {
    input.closest('.form-field')
      .classList.toggle('has-error', !input.checkValidity());
  });
});

지금은 CSS만으로 된다.

/* 지금 방식: 유효하지 않은 input을 품은 필드에 스타일 */
.form-field:has(input:invalid:not(:placeholder-shown)) {
  border-color: #e5484d;
}
.form-field:has(input:valid) .check-icon {
  opacity: 1;
}

이벤트 리스너도, 클래스 토글도 없다. 상태는 브라우저가 이미 알고 있고, CSS가 그걸 직접 읽는다. 나는 체크박스 선택 시 카드 전체를 강조하는 UI, 이미지가 없는 게시글 카드의 레이아웃 변경, 이 두 군데에서 JS를 걷어냈다. :has()는 2023년 말부터 모든 주요 브라우저에서 지원되니, 사내 서비스처럼 브라우저를 어느 정도 통제할 수 있는 환경이면 그냥 쓰면 된다.

주의할 점 하나. :has()는 강력한 만큼 셀렉터 매칭 비용이 있다. body:has(...)처럼 최상위에 넓게 거는 건 피하고, 가능한 한 좁은 범위에 거는 게 좋다. 실제로 리스트 항목 수천 개짜리 화면에서 무심코 넓게 걸었다가 스크롤이 미묘하게 버벅여서 범위를 좁힌 적이 있다.

2. 컨테이너 쿼리 — 반응형의 기준이 화면에서 부모로

미디어 쿼리의 근본적인 한계는 기준이 항상 뷰포트라는 거다. 같은 카드 컴포넌트가 사이드바에 들어가면 좁게, 본문에 들어가면 넓게 나와야 하는데, 뷰포트 기준으로는 이걸 못 푼다. 그래서 예전엔 ResizeObserver로 부모 너비를 재서 클래스를 붙이는 코드를 짰다.

/* 지금 방식: 부모를 컨테이너로 선언 */
.card-wrapper {
  container-type: inline-size;
}

/* 컨테이너 너비 기준으로 분기 */
@container (max-width: 400px) {
  .card {
    flex-direction: column;
  }
  .card .thumbnail {
    width: 100%;
  }
}

컴포넌트가 "내가 놓인 자리의 너비"에 스스로 반응한다. 디자인 시스템 만드는 입장에서는 이게 진짜 크다. 카드 컴포넌트를 어디에 갖다 놓든 알아서 맞춰지니까, "이 컴포넌트는 사이드바용 variant를 따로 주세요" 같은 대화가 사라진다. 우리 팀에서는 관리자 대시보드 위젯에 먼저 적용했는데, 위젯 크기를 사용자가 드래그로 바꾸는 화면이라 효과가 특히 좋았다. ResizeObserver 코드 한 덩어리가 통째로 사라졌다.

사진: Unsplash, Gabriel Heinzer

3. popover 속성 — 드롭다운/툴팁의 골칫거리 해결

드롭다운 메뉴 만들 때 제일 귀찮은 게 뭐냐고 물으면 나는 "바깥 클릭하면 닫기"라고 답한다. document에 클릭 리스너 걸고, 메뉴 내부 클릭이면 무시하고, ESC 키 처리하고, 스크롤 컨테이너 안에서 z-index 씨름하고. 다들 한 번씩 짜봤을 거다.

HTML의 popover 속성은 이걸 브라우저 기본 동작으로 만들어버렸다.

<button popovertarget="user-menu">메뉴</button>

<div id="user-menu" popover>
  <a href="/settings">설정</a>
  <a href="/logout">로그아웃</a>
</div>

자바스크립트 0줄. 바깥 클릭 시 닫힘, ESC로 닫힘, 최상위 레이어(top layer)에 그려져서 z-index 문제 없음, 이게 전부 기본 제공이다. 정확히는 CSS가 아니라 HTML 기능이지만, "JS 로직을 플랫폼 기본 기능으로 대체한다"는 맥락에서 같이 묶었다. 열림/닫힘 애니메이션도 @starting-style과 transition-behavior: allow-discrete를 쓰면 CSS로 처리된다. 접근성 관점에서도 직접 짠 드롭다운보다 기본 동작이 낫다.

4. 스크롤 관련: scroll-snap과 sticky

모바일에서 좌우로 넘기는 캐러셀, 예전엔 라이브러리부터 찾았다. Swiper 같은 걸 npm install 하는 순간 번들에 수십 KB가 얹힌다. 단순한 캐러셀이면 지금은 이걸로 충분하다.

.carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
}
.carousel > * {
  flex: 0 0 80%;
  scroll-snap-align: center;
}

손가락으로 넘기면 착착 걸린다. 자동 재생이나 무한 루프가 필요하면 그때 라이브러리를 고민하면 되고, 상품 이미지 넘겨보기 수준이면 이 여섯 줄이 끝이다.

position: sticky는 이제 새로울 것도 없지만, 아직도 스크롤 이벤트로 헤더 고정을 구현한 레거시 코드를 종종 만난다. 스크롤 리스너는 성능 문제의 단골 원인이니, 보이는 족족 sticky로 바꾸는 걸 추천한다.

5. 자잘하지만 체감 큰 것들

CSS 중첩(Nesting) — Sass 없이도 이제 브라우저가 중첩 문법을 이해한다. 빌드 도구 없이 순수 CSS만 쓰는 작은 프로젝트에서 특히 반갑다. 다만 팀 프로젝트에서는 이미 Sass/PostCSS 파이프라인이 있는 경우가 많아서, 나는 신규 사이드 프로젝트부터 적용 중이다.

.card {
  padding: 16px;

  &:hover {
    background: #f5f5f5;
  }

  .title {
    font-weight: 600;
  }
}

text-wrap: balance — 제목이 두 줄로 떨어질 때 윗줄만 길고 아랫줄에 한 단어만 덜렁 남는 것, 그동안 JS 라이브러리로 잡던 문제다. 이제 한 줄이면 된다. 제목 요소에 걸어두면 줄 길이를 균형 있게 맞춰준다.

accent-color — 체크박스, 라디오, 프로그레스바 색상 때문에 커스텀 컴포넌트를 만들던 시절이 있었다. 브랜드 색만 맞추면 되는 상황이라면 accent-color: #6c47ff; 한 줄로 끝난다. 접근성 잘 잡힌 네이티브 컨트롤을 그대로 쓸 수 있다는 게 핵심이다.

aspect-ratio와 gap — 썸네일 비율 유지하려고 padding-top으로 비율 잡던 트릭, 기억하는 분 많을 것이다. 이제 aspect-ratio: 16 / 9; 한 줄이면 끝이다. flexbox에서도 gap이 동작한 지 오래라, margin과 음수 margin으로 아이템 간격을 잡던 코드는 보이는 대로 정리해도 된다.

dialog 요소 — 모달도 popover와 같은 맥락이다. <dialog>와 showModal()을 쓰면 포커스 트랩, 배경 딤 처리(::backdrop), ESC 닫기가 기본으로 따라온다. 모달 라이브러리 하나를 의존성에서 뺄 수 있다.

사진: Unsplash, Ferenc Almasi

삽질 기록 하나 — :has()와 우선순위 함정

좋은 이야기만 쓰면 광고 같으니, 실제로 밟았던 함정도 하나 남긴다. :has()를 도입하고 며칠 뒤, 멀쩡하던 카드의 hover 스타일이 갑자기 먹히지 않는 문제가 생겼다. 범인은 우선순위였다. :has()는 괄호 안에 들어간 셀렉터 중 가장 높은 우선순위를 자기 우선순위로 가져간다. .card:has(input:checked)는 클래스 하나짜리 셀렉터가 아니라는 얘기다. 뒤에 선언한 .card:hover가 이길 거라고 생각했는데 졌다.

해결은 둘 중 하나다. 우선순위를 맞춰주거나, 아예 :where()로 감싸서 우선순위를 0으로 만들어버리는 것.

/* :where()로 감싸면 우선순위가 오르지 않는다 */
.card:where(:has(input:checked)) {
  outline: 2px solid #6c47ff;
}

이 사건 이후로 팀 컨벤션에 "상태성 :has()는 :where()로 감싸서 쓴다"를 추가했다. 모던 CSS는 기능만 늘어난 게 아니라 우선순위 계산법도 같이 복잡해졌다. 이럴 때 개발자 도구의 Computed 탭에서 어떤 규칙이 이겼는지 확인하는 습관이 시간을 크게 아껴준다.

도입할 때 실무 기준

새 기능 소개 글은 많은데, 정작 "우리 서비스에 써도 되나"에 대한 이야기는 잘 없다. 내 기준은 이렇다.

첫째, Baseline 확인이 먼저다. MDN이나 caniuse에서 "Baseline: Widely available" 표시가 있으면 사실상 고민 없이 쓴다. 위에 쓴 것 중 :has(), 컨테이너 쿼리, scroll-snap, nesting, accent-color, dialog는 이미 이 단계다. popover와 @starting-style은 지원된 지 상대적으로 얼마 안 됐으니, 서비스 사용자층의 브라우저 통계를 한 번 보고 결정하는 게 안전하다.

둘째, 망가져도 되는 곳부터 적용한다. text-wrap: balance 같은 건 미지원 브라우저에서 그냥 원래대로 보일 뿐이라 리스크가 없다. 반면 컨테이너 쿼리는 레이아웃 자체가 달라지니, @supports로 감싸거나 구형 브라우저용 기본 레이아웃을 깔아두고 시작해야 한다.

/* 미지원 브라우저용 기본값을 먼저, 신기능은 @supports로 */
@supports (container-type: inline-size) {
  .card-wrapper {
    container-type: inline-size;
  }
}

셋째, 기존 코드를 일부러 갈아엎지는 않는다. 잘 돌아가는 JS 드롭다운을 popover로 바꾸는 작업 자체는 공수다. 나는 새 화면을 만들 때, 혹은 어차피 그 컴포넌트를 손대야 할 때만 교체한다. 리팩터링은 흐름에 얹어야지, 그 자체가 목적이 되면 끝이 없다.

마무리 — CSS를 다시 배워야 하는 시점

10년 전에 CSS를 배운 사람과 지금 CSS를 배우는 사람은 사실상 다른 언어를 배우는 거라고 느낀다. 나 같은 연차의 개발자일수록 "그건 CSS로 안 되니까 JS로"라는 반사신경이 몸에 배어 있는데, 그 반사신경이 이제 꽤 자주 틀린다. 프론트엔드 코드 리뷰를 하다 보면 연차 있는 사람일수록 오히려 옛날 방식으로 짜는 게 보인다. 나부터도 그랬다.

아이 셋 키우는 아빠 입장에서 비유하자면, 예전엔 분유 타주는 것도 기저귀 갈아주는 것도 전부 수동이었는데, 어느 순간 자동으로 해주는 도구들이 나온 상황과 비슷하다. 도구가 있는데도 손으로 하던 습관대로 하고 있다면, 그건 성실함이 아니라 그냥 정보 업데이트가 안 된 것이다.

자바스크립트가 줄어들면 좋은 점은 명확하다. 번들이 가벼워지고, 이벤트 리스너 관리 같은 버그 포인트가 사라지고, 브라우저 기본 동작이라 접근성도 대체로 낫다. 이번 주말에 본인 프로젝트에서 아코디언, 드롭다운, 캐러셀 코드를 한 번 열어보시길. 생각보다 많은 줄이 지워질 수 있다.

다음에 기회가 되면 @starting-style로 진입/퇴장 애니메이션을 CSS만으로 처리하는 방법, 그리고 View Transitions API로 페이지 전환 효과 만드는 이야기도 정리해보겠다.

로지텍 리프트 버티컬 마우스 한 달 사용기, 손목 시큰거리는 40대 개발자의 선택 (Lift 후기)

Lovizu — Tue, 25 Aug 2026 03:10:59 +0900

작년부터 오른쪽 손목이 심상치 않았다. 하루에 열 시간 가까이 키보드와 마우스를 잡는 직업이라 어느 정도 각오는 하고 살았는데, 마우스를 쥔 채로 스크롤을 오래 내리고 나면 손목 바깥쪽이 시큰거리는 날이 잦아졌다. 파스를 붙이고 손목 보호대를 차 봐도 그때뿐이었다. 얼마 전 키보드를 독거미 F87로 바꾸면서 입력 장비를 한 번 정리한 김에, 이번에는 마우스 차례라고 생각했다. 그래서 고른 게 로지텍 리프트(Lift) 버티컬 마우스다. 한 달 정도 회사와 집에서 번갈아 써 본 솔직한 후기를 남긴다.

왜 버티컬 마우스였나

일반 마우스를 쥐면 손바닥이 바닥을 보게 된다. 이때 팔뚝의 두 뼈가 교차하면서 손목이 살짝 비틀린 상태가 되는데, 이 자세로 하루 종일 클릭과 스크롤을 반복하는 게 손목에는 꽤 부담이라고 한다. 버티컬 마우스는 손을 악수하듯 세워서 잡게 만들어서 이 비틀림을 줄여 준다. 이론은 그렇다. 문제는 이론이 아니라 실제로 편한가였다.

후보는 세 개였다. 로지텍 MX Vertical, 로지텍 리프트, 그리고 2만 원대 보급형 버티컬 마우스들. MX Vertical은 크고 비쌌다. 보급형은 리뷰를 읽다 보니 스크롤 휠 품질과 센서 감도에 대한 불만이 반복해서 보였다. 리프트는 그 중간이다. 정가 88,390원인데 쿠팡에서 68,780원에 로켓배송으로 팔고 있었고, 상품평이 8,700개를 넘겼는데 한 달간 4,000명 이상이 샀다고 떠 있었다. 이 정도 표본이면 복불복은 아니겠다 싶어 그래파이트 색으로 주문했다.

첫인상: 생각보다 작고, 생각보다 조용하다

박스를 열고 처음 든 생각은 "작네"였다. 사진으로 볼 때는 MX Vertical처럼 우람한 물건을 상상했는데, 실물은 손안에 쏙 들어오는 크기다. 공식 스펙 자체가 손 길이 17.5cm 이하의 작은 손부터 중간 크기 손에 맞춘 제품이다. 내 손이 대략 18cm 근처인데, 딱 마지노선이라는 느낌이다. 손을 얹으면 남는 공간 없이 꽉 찬다. 이 부분은 뒤에 단점에서 다시 이야기한다.

각도는 57도. 완전히 수직도 아니고 일반 마우스처럼 눕지도 않은, 악수하다 만 것 같은 각도다. 처음 잡으면 어색한데, 손목이 비틀리지 않는다는 게 무슨 말인지 잡는 순간 바로 이해가 된다.

그리고 클릭이 조용하다. 무소음 스위치라서 딸깍 소리 대신 톡톡 하는 낮은 소리가 난다. 새벽에 아이들 재워 놓고 거실에서 작업할 일이 많은 아빠 입장에서 이건 생각보다 큰 장점이었다. 독거미 키보드도 조용한 축으로 골랐는데, 마우스까지 조용해지니 새벽 작업 세트가 완성됐다.

박스 구성과 연결

구성은 단출하다. 마우스 본체, 로지 볼트 USB-A 수신기, 그리고 AA 건전지 한 개가 이미 본체에 들어 있다. 별도 충전 케이블이 없으니 박스 열고 바닥 전원 스위치만 켜면 끝이다. 수신기는 본체 안 건전지 옆 수납 공간에 들어가게 되어 있어서 들고 다닐 때 잃어버릴 걱정이 없다. 이런 디테일은 로지텍이 확실히 잘한다.

연결은 두 가지다. 블루투스로 직접 붙이거나, 동봉된 로지 볼트 수신기를 꽂아 쓰거나. 나는 회사 맥북에는 블루투스, 집 데스크탑에는 수신기로 붙였다. 블루투스 연결은 맥OS와 윈도우 모두 페어링 한 번에 잡혔고, 한 달 동안 끊김이나 커서 튐은 한 번도 없었다. 참고로 수신기가 예전 유니파잉이 아니라 로지 볼트 규격이라, 집에 굴러다니는 구형 유니파잉 수신기와는 호환이 안 된다. 이건 알고 있어야 한다.

스펙 정리

각도 57도 버티컬 설계, 작은 손~중간 손(17.5cm 이하) 대상
센서 최대 4000DPI, 무소음 클릭 스위치
연결: 블루투스 + 로지 볼트(Logi Bolt) USB 수신기, 최대 3대 기기 Easy-Switch 전환
전원: AA 건전지 1개, 최대 24개월 사용
스크롤: SmartWheel, 천천히 돌리면 정밀 스크롤, 빠르게 돌리면 고속 스크롤
모델명 MR0094, 2021년 12월 출시

건전지 방식은 호불호가 있는데 나는 오히려 마음에 든다. 충전식은 결국 배터리가 부풀거나 수명이 줄어드는 순간이 오는데, AA 하나로 2년을 버틴다면 그냥 다이소에서 건전지 사서 갈아 끼우는 쪽이 속 편하다.

일주일 적응기: 솔직히 처음엔 후회했다

여기는 솔직하게 쓴다. 첫 이틀은 후회했다. 커서를 미세하게 움직이는 작업, 그러니까 IDE에서 텍스트 드래그로 정확히 괄호까지 선택한다거나, 디자인 시안에서 픽셀 단위로 뭘 맞춘다거나 하는 동작이 마음처럼 안 됐다. 손을 세워서 잡으면 마우스를 움직이는 근육 자체가 달라지는데, 20년 넘게 눕혀 잡던 손이 하루아침에 바뀔 리가 없다.

리뷰들을 다시 읽어 보니 다들 비슷한 이야기를 하고 있었다. 며칠 적응 기간이 필요하다는 후기가 압도적으로 많았고, 실제로 나도 3일째부터 어색함이 급격히 줄더니 일주일 지나니까 예전 속도가 그대로 나왔다. 지금은 오히려 반대다. 가끔 예전 마우스를 잡으면 손목을 비틀어 눕히는 그 자세가 어색하고 불편하게 느껴진다. 건초염으로 고생하다 이 마우스로 갈아탄 뒤 4년째 쓰고 재구매했다는 후기도 있던데, 왜 그런지 알 것 같다.

한 달 실사용: 손목은 정말 편해졌나

결론부터 말하면, 시큰거리는 빈도가 눈에 띄게 줄었다. 마우스 하나 바꿨다고 손목이 완치되는 마법 같은 건 당연히 없다. 다만 하루가 끝났을 때 손목 바깥쪽에 남던 묵직한 피로감이 확실히 덜하다. 손등이 하늘을 보는 자세와 엄지가 하늘을 보는 자세의 차이가 열 시간 누적되면 이 정도 차이를 만드는구나 싶다.

기능 면에서 기대 안 했다가 잘 쓰는 건 두 가지다. 하나는 Easy-Switch다. 회사 맥북, 집 데스크탑, 아이패드까지 3대를 등록해 두고 바닥의 버튼으로 전환하는데, 마우스 하나를 가방에 넣고 다니면서 어디서든 그대로 쓴다. 다른 하나는 SmartWheel 스크롤이다. 코드 리뷰할 때는 한 줄씩 정밀하게, 긴 로그 파일 볼 때는 휠을 세게 굴려서 고속으로 내려가는데, 이 전환이 자연스러워서 손에 익으면 되돌아가기 어렵다.

엄지 쪽에는 앞으로/뒤로 버튼이 있고, 로지텍 Options+ 앱에서 기능을 바꿀 수 있다. 나는 뒤로 가기와 복사/붙여넣기를 걸어 두고 쓰는데, 브라우저에서 문서 찾아다닐 때 확실히 손이 덜 간다.

단점: 이건 알고 사야 한다

첫째, 손 큰 사람에게는 작다. 이게 가장 중요한 단점이다. 리뷰 중에 손 가로 18cm 기준으로 딱 마지노선이라는 정성스러운 후기가 있었는데 동의한다. 손이 그보다 크면 손날이 바닥에 쓸려서 오히려 불편할 수 있다. 손이 큰 편이라면 리프트가 아니라 형님뻘인 MX Vertical을 봐야 한다. 반대로 손이 작은 편이거나 여성이라면 리프트 쪽이 정답이다.

둘째, 적응 기간은 진짜 있다. 위에 쓴 대로 며칠은 커서가 마음대로 안 움직인다. 그 기간에 중요한 발표 시연이나 마감이 걸려 있다면 도입 시점을 조절하는 게 좋다.

셋째, 게임용은 아니다. 4000DPI 센서가 나쁘다는 게 아니라, 빠른 플리크가 필요한 FPS류를 이 그립으로 하는 건 무리다. 적응돼서 웬만한 게임은 한다는 후기도 있긴 한데, 게임 비중이 크면 게이밍 마우스를 따로 두는 걸 추천한다.

넷째, 밝은 색상은 변색 이슈가 있다. 페일 그레이를 쓰다가 손바닥 닿는 고무 부분이 변색돼서 그래파이트로 재구매했다는 후기가 여럿 보였다. 손에 땀이 많은 편이라면 무조건 어두운 색이다. 나도 그래서 그래파이트를 골랐다.

다섯째, Easy-Switch 버튼이 바닥에 있다. 기기를 전환하려면 마우스를 들어서 뒤집어야 한다. 자주 전환하는 사람에게는 은근히 번거롭다. MX 시리즈처럼 옆면에 있었으면 좋았을 텐데.

경쟁 제품과 비교

MX Vertical(약 12~13만 원대): 각도가 더 가파르고(78도) 크기가 커서 큰 손에 맞다. 충전식이고 가격이 리프트의 두 배 가까이 된다. 손이 크고 예산이 넉넉하면 이쪽.

보급형 버티컬(로이체 RX-800V 등 2만 원대): 버티컬이라는 게 나한테 맞는 자세인지 시험해 보는 용도로는 나쁘지 않다. 다만 스크롤 품질, 무소음, 멀티페어링, 마감에서 차이가 난다. 하루 한두 시간 쓰는 사람이면 보급형으로 충분하고, 하루 여덟 시간 이상 잡고 사는 직업이면 리프트값은 한다고 본다.

일반 무선 마우스(G304 등): 집에 굴러다니는 G304와 나란히 놓고 보면 리프트가 확실히 키가 크다. 대신 차지하는 면적은 비슷해서 좁은 책상에서도 부담이 없다. 손목 문제가 없다면 굳이 버티컬로 넘어올 이유는 없다. 이건 어디까지나 손목이 보내는 신호를 받은 사람들의 장비다.

아이 셋 아빠의 사소한 관찰

예상 못 한 부수입도 있다. 생김새가 특이해서인지 아이들이 아빠 마우스를 장난감으로 안 본다. 이전 마우스는 손에 잡히는 대로 가져다가 자동차처럼 굴리고 놀던 둘째가, 이건 산처럼 생겼다며 손도 안 대니 마우스 수명이 늘어난 셈이다. 농담이 아니라 세워서 잡는 그립 특성상 아이 손에는 잘 안 잡힐 크기이기도 하다.

그리고 마우스를 바꾸면서 생긴 습관이 하나 있다. 손목이 편해지니 오히려 손목 상태에 관심이 생겨서, 이제는 뽀모도로 한 사이클 끝날 때마다 손목 스트레칭을 같이 한다. 장비는 결국 습관을 바꾸는 계기일 때 가장 값어치를 한다고 생각한다.

자주 묻는 것들

맥에서 잘 되나? 잘 된다. 일반판(MR0094)을 맥북에 블루투스로 붙여 쓰는데 문제없다. 참고로 'Lift for Mac'이라는 맥 전용판이 따로 있긴 한데, 하드웨어는 사실상 같고 수신기 동봉 여부와 색상 구성 정도가 다르다. 맥과 윈도우를 같이 쓴다면 그냥 일반판을 사는 게 낫다.

왼손잡이용은? 있다. 리프트는 왼손 전용 모델이 따로 나온다. 버티컬 마우스는 구조상 좌우 대칭이 불가능해서 왼손잡이는 반드시 왼손용을 골라야 한다.

소프트웨어는 필수인가? 필수는 아니다. 꽂으면 그냥 마우스로 잘 동작한다. 다만 로지텍 Options+를 깔면 엄지 버튼과 휠 버튼에 원하는 기능을 지정할 수 있고, DPI 즉 커서 속도도 세밀하게 조절할 수 있다. 버티컬 적응 초기에 커서 속도를 평소보다 한 단계 낮추면 정밀 조작 스트레스가 확 준다. 이건 적응기를 버티는 실전 팁이다.

건전지 교체는 번거롭지 않나? 최대 24개월이라는 공식 수치를 그대로 믿지는 않더라도, 후기들을 보면 1년 이상은 무난히 가는 분위기다. 상판이 자석으로 붙어 있어서 손톱으로 열고 AA 하나 갈아 끼우면 끝이다. 2년에 한 번 있을 일을 단점이라고 부르기는 어렵다.

총평

마우스에 7만 원은 솔직히 선뜻 나가는 돈은 아니다. 나도 장바구니에 넣고 일주일을 묵혔다. 그런데 생각해 보면 개발자가 하루에 가장 오래 손을 대고 있는 물건이 키보드와 마우스다. 의자에는 수십만 원을 쓰면서 손목이 매일 아프다고 파스값을 쓰는 건 순서가 틀렸다. 한 달 써 본 지금은 초기 적응 스트레스까지 포함해도 잘 산 물건이라고 정리하게 된다. 손목이 신호를 보내기 시작한 또래 개발자라면, 더 나빠지기 전에 자세부터 바꿔 보는 걸 권한다.

덧붙이면, 이런 장비는 결국 자세 교정 도구다. 마우스를 바꾸고 나서 나는 모니터 높이와 팔걸이 높이도 한 번씩 다시 잡았다. 손목만 세운다고 끝이 아니라, 팔꿈치 각도와 어깨까지 이어지는 라인이 편해야 오래 간다. 장비 하나 바꾼 김에 책상 전체를 점검해 보는 걸 추천한다. 돈 드는 일도 아니다.

구매는 아래 링크에서 확인할 수 있다. 오늘 기준 68,780원, 로켓배송에 무료 반품이라 그립이 안 맞으면 돌려보내기도 부담이 없다. 상품평 8,700개를 먼저 훑어보고 자기 손 크기와 맞는지 가늠해 보는 것도 좋다.

로지텍 리프트 버티컬 마우스 최저가 확인하기 (쿠팡)

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

지난주 테크 뉴스 핵심 정리: 앤스로픽 역전, 윈도우 제로데이, 소버린 AI

Lovizu — Mon, 24 Aug 2026 12:52:47 +0900

월요일 아침이면 늘 하던 대로, 지난주(8월 17일~23일) IT 뉴스 중에서 개발자 입장에서 그냥 넘기기 어려운 것들만 추려봤다. 이번 주는 한 문장으로 요약하면 이렇다. "AI 판의 서열이 바뀌었고, 그 와중에 보안은 계속 뚫리고 있다." 앤스로픽이 OpenAI 매출을 처음으로 넘어섰다는 소식이 단연 컸고, 국내에서는 KT의 소버린 AI 어플라이언스 출시와 반도체 주가의 롤러코스터가 눈에 띄었다. 하나씩 정리해 본다.

앤스로픽 분기 매출, OpenAI 첫 추월

이번 주 가장 큰 뉴스다. 월스트리트저널(WSJ)이 8월 19일 보도한 내용에 따르면, 2분기(4~6월) 매출에서 앤스로픽이 116억 달러를 기록하며 OpenAI(67억 달러)를 처음으로 앞질렀다. 단순히 앞선 정도가 아니다. 앤스로픽은 전분기 대비 매출이 두 배 이상 뛰면서 소폭이지만 영업이익 흑자까지 냈고, OpenAI는 매출이 18% 늘어나는 동안 영업손실이 93억 달러에서 123억 달러로 오히려 더 커졌다. 매출은 10억 달러 늘었는데 적자는 30억 달러 늘어난 셈이다.

왜 이렇게 갈렸는지에 대한 분석도 흥미롭다. 앤스로픽 성장의 중심에는 개발자들이 쓰는 Claude Code가 있다는 평가가 많다. 코딩이라는 확실한 유즈케이스에서 돈을 내는 고객을 잡았고, 컴퓨팅 자원을 효율적으로 쓰는 쪽으로 개선을 해왔다는 것이다. 반면 OpenAI는 7월에 GPT-5.6을 내놓은 뒤 기업 고객 매출이 한 달 새 32% 늘며 다시 반등 중이라고 해명했지만, 투자자들 눈높이에는 못 미쳤다는 반응이 나왔다.

숫자를 조금 더 들여다보면 체감이 된다. 앤스로픽의 연환산 매출은 1년 새 7배가 뛰어 650억 달러 수준에 도달했다는 보도가 나왔고, 이르면 올가을 상장 가능성과 함께 시가총액 2조 달러 목표가 거론되고 있다. 올해 4월에는 구글이 최대 400억 달러, 아마존이 최대 250억 달러 투자를 약속하기도 했다. 반면 OpenAI는 최근 1년 사이 최고매출책임자(CRO) 교체를 포함해 주요 경영진이 연이어 바뀌었고, 브록먼이 제품과 사업 조직을 직접 챙기며 성장 재가속에 나선 상황이다.

개발자 입장에서 이 뉴스가 중요한 이유는 간단하다. 두 회사 모두 IPO를 준비 중이고, 앞으로 몇 년간 가격 정책과 모델 라인업이 "상장사 실적" 논리로 움직일 가능성이 커졌다는 점이다. 상장사가 되면 분기마다 마진을 증명해야 하고, 그 압박은 결국 API 단가, 무료 티어 축소, 모델 지원 종료 주기 같은 형태로 사용자에게 내려온다. 지금 회사 프로젝트에서 특정 벤더 API에 깊게 묶여 있다면, 가격 인상이나 모델 정책 변경에 대비한 추상화 레이어 하나쯤은 미리 만들어 두는 게 좋겠다는 생각을 다시 하게 됐다. 나부터도 사이드 프로젝트에서 LLM 호출부를 어댑터 패턴으로 분리해 둔 게 올해 들어 몇 번이나 도움이 됐다. 모델 교체가 설정 파일 한 줄 수정으로 끝나느냐, 스프린트 하나를 통째로 태우느냐의 차이는 이런 뉴스가 터졌을 때 극명하게 갈린다.

OpenAI, 프런티어 모델 훈련 일부를 스스로 멈췄다

매출 뉴스에 묻힐 뻔했지만 개인적으로는 이쪽이 더 의미심장했다. 샘 알트먼이 X(트위터)에 "새로운 수준의 능력에 걸맞은 정렬(alignment)·보안·모니터링 기준을 충족하기 위해 일부 프런티어 강화학습(RL) 훈련을 일시 중단했다"고 직접 밝혔다. 모델 발전 속도가 "극도로 빠르다"는 말과 함께였다.

맥락이 있다. 최근 내부 테스트에서 OpenAI의 에이전트가 다른 회사 시스템을 해킹하는 상황이 벌어졌고, 그 이후 OpenAI는 안전 규정 자체를 다시 쓰고 있는 것으로 알려졌다. 공동창업자 그렉 브록먼도 "우리 모델의 사이버 능력을 과소평가했다"고 인정했다. 상업 경쟁이 이렇게 치열한 시점에, 그것도 실적 발표로 두들겨 맞는 와중에 훈련을 멈춘다는 건 회사 입장에서 쉬운 결정이 아니다. 그만큼 내부에서 본 게 심상치 않았다는 뜻으로 읽힌다.

실무 관점의 시사점은 이거다. 에이전트에게 브라우저, 터미널, 사내 API 접근 권한을 주는 게 이제 일상이 됐는데, 권한 범위를 좁게 잡고 감사 로그를 남기는 설계가 선택이 아니라 필수가 되고 있다. 구체적으로는 세 가지만 챙겨도 리스크가 크게 줄어든다. 첫째, 에이전트용 서비스 계정을 사람 계정과 분리하고 토큰 수명을 짧게 가져갈 것. 둘째, 에이전트가 호출할 수 있는 API를 화이트리스트로 제한할 것. 셋째, 에이전트의 행동 로그를 사람의 행동 로그와 구분해서 남겨둘 것. 사고가 났을 때 "누가 그랬는지"보다 "어느 에이전트가 어떤 권한으로 그랬는지"를 추적할 수 있어야 수습이 된다. 우리 팀도 최근 에이전트용 계정을 재정비했는데, 이번 뉴스를 보니 몇 주 번거로울 가치가 충분한 작업이었다 싶다.

라자루스의 윈도우 커널 제로데이, 패치는 하셨는지

보안 쪽에서는 북한발 소식이 한 주 내내 시끄러웠다. 북한 연계 해킹그룹 라자루스가 윈도우 커널 제로데이 취약점(CVE-2026-68820)을 악용해 '푸드모듈'이라는 고도화된 루트킷을 유포한 사실이 알려졌고, 미국 CISA는 연방기관에 8월 25일까지 패치를 완료하라는 긴급 지침을 내렸다. 커널 레벨 루트킷은 한번 박히면 백신으로 탐지하기가 극도로 어렵다는 점에서 급이 다른 위협이다.

여기에 더해 국내 보안기업 지니언스는 또 다른 북한 해킹조직 김수키가 생성형 AI 도구를 정찰부터 악성코드 제작까지 공격 체계 전반에 활용하고 있다는 분석을 내놨다. 피싱 메일 문구가 어색해서 걸러지던 시대는 끝났다고 봐야 한다.

왜 이게 남의 나라 연방기관 얘기로 끝나지 않느냐면, 라자루스의 주력 타깃이 전통적으로 국내 기업, 금융권, 암호화폐 거래소였기 때문이다. 미국 연방기관에 25일 시한을 박을 정도의 취약점이면 국내 기업 서버는 이미 스캐닝 대상에 올라가 있다고 보는 게 합리적이다. 회사에서 윈도우 서버나 개발 PC를 관리하는 입장이라면 이번 주 정기 패치 배포 일정을 앞당길 이유가 충분하다. 나는 집 PC와 아이들 노트북까지 윈도우 업데이트를 주말에 다 돌려놨다. 애 셋 키우는 집은 공용 노트북이 사실상 공격 표면이다. 어른 계정과 아이 계정 분리, 자동 업데이트 활성화. 기본이지만 이번 같은 뉴스가 나올 때마다 한 번씩 점검하게 된다.

KT, 국산 NPU와 LLM을 한 상자에 담은 소버린 AI 어플라이언스

국내 소식 중에서는 KT가 8월 19일 출시한 'KT NPU LLM 스테이션'이 흥미로웠다. 국내 AI 반도체 기업 리벨리온의 추론 특화 NPU 'ATOM-MAX'에 KT 자체 LLM '믿음 K 2.5 Pro', 운영 API 플랫폼까지 한 서버에 담은 일체형 제품이다. 설치 당일부터 AI 기능을 바로 쓸 수 있다는 게 핵심 셀링 포인트다.

"소버린 AI"라는 단어가 마케팅 용어처럼 들릴 수도 있지만, 실무에서는 꽤 현실적인 수요가 있다. 금융, 공공, 의료처럼 데이터를 외부 클라우드에 못 올리는 조직이 여전히 많고, 이들에게 "GPU 수급 걱정 없이, 폐쇄망에서, 국산 스택으로" 돌아가는 완제품은 도입 품의를 통과시키기가 훨씬 쉽다. 엔비디아 GPU 없이 추론 전용 NPU로 어느 정도 성능이 나오는지가 관건인데, 동급 GPU 대비 전력 효율이 높다는 공인 시험 결과를 내세우고 있으니 실제 벤치마크 후기가 나오면 챙겨볼 생각이다. 온프레미스 LLM 구축 견적을 받아본 적이 있는 입장에서, 이런 어플라이언스형 제품이 가격만 맞으면 판을 바꿀 수 있다고 본다. GPU 서버 견적은 보통 카드 수급 불확실성 때문에 납기가 몇 달씩 밀리는데, 완제품이면 그 불확실성이 사라지기 때문이다. KT는 여기에 에이전트 기능 탑재와 엣지 데이터센터 확대까지 예고했는데, 통신사가 통신 인프라를 지렛대 삼아 기업용 AI 시장으로 들어오는 그림은 해외의 소버린 클라우드 흐름과도 겹쳐 보인다.

반도체 롤러코스터: 중동 쇼크와 SK하이닉스의 40조 승부수

8월 19일 국내 증시에서는 삼성전자와 SK하이닉스가 장 초반 나란히 급락했다. 중동발 리스크가 반도체 밸류체인을 덮치면서 삼성전자는 장중 6% 넘게 빠졌다. 그런데 같은 날 SK하이닉스는 40조 원 규모의 자사주 취득·소각 주주환원 계획을 발표했다. 7월 ADR 상장 이후 투자설명서 교부 기간과 겹쳐 발표 시점이 늦어졌다는 뒷이야기도 나왔다.

수급 쪽 데이터도 재미있다. 8월 들어 외국인은 삼성전자를 약 9,900억 원 순매수하면서 SK하이닉스는 1조 원 넘게 순매도했다. 상반기처럼 "AI 반도체면 다 같이 간다"는 장세가 끝나고 종목별로 옥석을 가리기 시작했다는 얘기다. 주식 얘기를 길게 할 자리는 아니지만, 개발자 입장에서 이 흐름은 메모리 가격과 클라우드 인프라 비용으로 되돌아온다. HBM과 서버 D램 수급이 출렁이면 결국 클라우드 인스턴스 가격과 회사 장비 구매 예산에 영향이 온다. 올해 상반기 내내 메모리 가격이 강세였던 걸 생각하면, 개인적으로는 집에서 쓰는 NAS용 메모리랑 SSD도 필요한 게 있으면 가격 알람 걸어두고 조정장에 사둔다는 원칙을 유지 중이다. 사내 GPU 서버 증설 계획이 있다면 분기 단위로 가격 추이를 지켜볼 필요가 있다.

구글 클라우드, 2029년까지 양자내성암호 전환

마지막은 짧지만 방향성이 중요한 뉴스. 구글 클라우드가 2029년까지 양자내성암호(PQC) 체계로 전환하겠다는 계획을 밝혔다. "지금 암호화된 트래픽을 수집해 두었다가 양자컴퓨터가 나오면 해독한다"는 이른바 'Harvest Now, Decrypt Later' 공격에 대비하겠다는 것이다.

2029년이면 멀게 느껴지지만, 암호 체계 마이그레이션은 늘 예상보다 오래 걸린다. TLS 인증서, JWT 서명, 데이터베이스 암호화 키, 내부 서비스 간 mTLS, 오래된 레거시 시스템의 하드코딩된 알고리즘까지, 애플리케이션 곳곳에 암호화가 박혀 있기 때문이다. 클라우드 벤더가 인프라 레벨에서 알아서 바꿔주는 부분도 있겠지만, 애플리케이션 레벨에서 직접 고른 암호화 로직은 결국 개발팀 몫이다. 당장 할 일은 없더라도, 우리 시스템 어디에 어떤 암호 알고리즘이 쓰이는지 목록화해 두는 것(crypto inventory)이 PQC 전환의 첫걸음이라는 점은 기억해 둘 만하다. 10년 전 SHA-1 인증서 퇴출 때 고생했던 기억이 있는 분들은 무슨 말인지 바로 아실 거다.

짧게 보는 단신 세 가지

길게 다룰 정도는 아니지만 흘려 보기는 아까운 소식들도 묶어둔다.

하나. 로이터에 따르면 미국 은행들이 앤스로픽의 보안 분석 도구 '미토스(Mythos)'가 짚어낸 IT 시스템 취약점을 고치느라 비상이 걸렸다. AI가 취약점을 찾아주는 속도를 사람의 수정 속도가 못 따라가는 상황이 이미 현실이 됐다는 얘기다. 공격자도 같은 도구를 쓴다면, 패치 속도가 결국 보안의 승부처가 된다.

둘. 미국 정부가 민간 기업에 해외 사이버 범죄조직에 대한 이른바 '역해킹'을 허용하는 방향을 공식화하고 있다는 보도가 나왔다. 방어만 하던 민간 영역이 공격까지 품게 되면 교전 규칙 자체가 바뀌는 거라 논쟁이 적지 않을 것 같다.

셋. 카스퍼스키는 AI 에이전트용 악성코드·백도어 탐지 기능을 발표했다. 에이전트 자체가 공격 통로가 되는 시대에 맞춰 보안 제품군도 '사람을 지키는 보안'에서 '에이전트를 지키는 보안'으로 재편되기 시작했다는 신호로 읽혔다.

이번 주를 한 줄로

"돈은 코딩 AI로 몰리고, 리스크는 에이전트와 커널에서 터진다." 앤스로픽의 역전은 결국 개발자라는 확실한 고객층을 잡은 결과였고, OpenAI의 훈련 중단은 에이전트 시대의 보안이 더 이상 이론적 걱정이 아니라는 신호였다. 다음 주는 엔비디아 2분기 실적 발표가 예정되어 있어서 AI 인프라 투자 사이클이 유지되는지 확인할 수 있는 한 주가 될 것 같다. 앤스로픽의 가을 IPO 관련 공시가 나오는지, 그리고 CISA 패치 시한(8월 25일) 이후 라자루스 관련 추가 보도가 이어지는지도 같이 체크해볼 생각이다. 월요일 출근길, 이 정도만 알고 가도 커피 타임 대화는 충분하다.

이 글은 WSJ, 로이터, The Next Web, 연합뉴스, 뉴스핌, 뉴스1, 보안뉴스 등 지난주 보도를 바탕으로 직접 정리했다.

개학 일주일 전, 아이 셋 아빠의 생활 리듬 복구 작전 (수면·아침 루틴·준비물 체크리스트)

Lovizu — Sat, 22 Aug 2026 03:06:45 +0900

8월 말이 되면 우리 집 공기가 달라진다. 달력을 보던 첫째가 "아빠, 개학 며칠 남았어?"라고 묻는 순간부터다. 방학 내내 밤 11시에 자고 아침 9시에 일어나던 아이들이, 일주일 뒤에는 7시에 일어나서 밥 먹고 가방 메고 나가야 한다. 이게 자동으로 될 리가 없다. 아이 셋을 키우면서 개학을 여러 번 치러보니, 개학 전 일주일을 어떻게 보내느냐가 개학 후 한 달을 결정한다는 걸 몸으로 배웠다.

오늘은 우리 집에서 실제로 굴리고 있는 개학 전 생활 리듬 복구 방법을 정리해본다. 거창한 교육 이론이 아니라, 애 셋 등교시켜본 아빠의 실전 기록이다.

사진: Unsplash, Eyestetix Studio

무너진 건 아이가 아니라 온 집안의 리듬이다

방학이 끝나갈 때쯤 아이들 생활을 보면 한숨부터 나온다. 기상 시간은 두 시간쯤 밀려 있고, 아침밥은 브런치가 된 지 오래고, 미디어 시간은 슬금슬금 늘어서 하루 두세 시간이 기본이 되어 있다. 그런데 곰곰이 생각해보면 이건 아이들 잘못이 아니다. 어른인 나부터 방학 모드였다. 아이가 늦게 자니 나도 늦게까지 같이 있었고, 아침에 급할 일이 없으니 온 집안이 느슨해졌다.

그래서 우리 집 개학 준비의 첫 번째 원칙은 이거다. 아이만 고치려 들지 말고, 집 전체의 시간표를 되돌린다. 아이한테만 "일찍 자!"라고 소리쳐봤자 거실에 TV가 켜져 있으면 소용없다. 부모가 먼저 방학 모드를 끝내야 아이도 따라온다. 당연한 얘기 같지만, 이걸 인정하기까지 몇 번의 개학을 망쳐봤다.

수면 리듬: 하루 30분씩, 일주일 계획으로 당긴다

제일 중요한 게 수면이다. 그리고 제일 안 되는 것도 수면이다. 개학 전날 "내일부터 학교니까 일찍 자"라고 하면 백 퍼센트 실패한다. 아이 몸은 이미 밤 11시에 맞춰져 있는데 갑자기 9시에 눕힌다고 잠이 올 리가 없다. 침대에서 한 시간 뒤척이다가 짜증만 늘고, 다음 날 아침은 전쟁이 된다.

우리 집은 개학 일주일 전부터 취침 시간을 하루 20~30분씩 앞당기는 방식을 쓴다. 예를 들어 지금 11시에 잔다면 이런 식이다.

D-7~D-6: 10시 30분 취침
D-5~D-4: 10시 취침
D-3~D-2: 9시 30분 취침
D-1: 9시 취침, 개학 당일 아침 리허설

포인트는 취침 시간보다 기상 시간을 먼저 당기는 것이다. 아침에 일찍 깨워서 낮에 활동량을 늘리면 밤에 일찍 자는 건 자연스럽게 따라온다. 반대로 아침에 늦게 자게 두고 밤에만 일찍 재우려고 하면 애도 어른도 괴롭다. 그리고 자기 전 한 시간은 태블릿과 TV를 끈다. 화면 보다가 바로 누우면 잠드는 데 확실히 오래 걸린다. 이건 아이 셋 모두에게서 확인한, 우리 집 기준으로는 예외가 없는 법칙이다.

둘째처럼 잠 앞당기기가 유독 안 되는 아이도 있다. 그럴 땐 낮잠을 줄이고 오후에 놀이터에서 한 시간쯤 뛰게 한다. 몸이 피곤하면 눕자마자 잔다. 결국 수면 문제의 절반은 활동량 문제였다.

사진: Unsplash, Suhas Hanjar

아침 루틴 리허설: 개학 전에 등교 연습을 한 번 해본다

개학 첫날 아침이 힘든 이유는 오랜만이라서다. 일어나서, 밥 먹고, 세수하고, 옷 입고, 가방 메고 나가는 그 흐름을 두 달 가까이 안 해봤으니 몸이 잊어버린 거다. 그래서 우리 집은 개학 2~3일 전에 등교 리허설을 한다. 말이 거창하지, 그냥 학교 가는 날과 똑같은 시간에 깨워서 똑같은 순서로 움직여보는 거다.

해보면 재밌는 게, 꼭 어딘가에서 병목이 생긴다. 첫째는 일어나서 밥상까지 오는 데 20분이 걸리고, 둘째는 옷 고르다가 15분을 쓴다. 개학 당일에 이걸 처음 겪으면 아침부터 소리 지르게 되는데, 리허설에서 미리 발견하면 대책을 세울 수 있다. 우리 집 해법은 이렇다.

옷은 전날 밤에 고른다. 아이가 직접 고르게 하되, 시점을 아침에서 저녁으로 옮기는 것만으로 아침 15분이 산다.
가방은 전날 밤에 싼다. 시간표 보고 챙기는 습관은 저학년 때 잡아두면 두고두고 편하다. 처음엔 부모가 같이 확인하고, 익숙해지면 아이한테 넘긴다.
아침 메뉴는 단순하게 고정한다. 개학 첫 주 아침은 새 메뉴 실험하는 시간이 아니다. 아이들이 무조건 먹는 메뉴 두세 개를 돌린다.
아침에 하는 결정을 최소화한다. 개발자 일을 하면서 배운 건데, 아침의 의사결정은 비싸다. 결정할 게 없는 아침이 빠른 아침이다.

리허설을 한 번 해두면 아이들도 "아, 이제 이 흐름으로 돌아가는구나" 하고 마음의 준비를 한다. 그 효과가 생각보다 크다.

준비물 점검: 주말 반나절이면 끝난다

준비물은 미루면 개학 전날 밤에 문방구를 뒤지게 되고, 미리 하면 주말 반나절 일거리다. 우리 집은 개학 전 마지막 주말에 아이들과 같이 책상을 정리하면서 한 번에 끝낸다. 순서는 이렇다.

필통 열어보기: 방학 지난 필통은 거의 유적지다. 연필 깎아서 채우고, 지우개 있는지 확인하고, 다 쓴 건 버린다.
실내화 신어보기: 방학 두 달이면 애들 발이 큰다. 작아진 실내화는 미리 사둔다. 개학 전날 밤에 실내화 사러 뛰는 것만큼 허무한 일이 없다.
이름표 확인: 새로 산 학용품에는 이름 스티커를 붙인다. 이거 안 붙이면 한 달 안에 절반이 사라진다. 애 셋이면 물건 분실이 곱하기 3이라, 우리 집은 이름 스티커를 대량으로 뽑아두고 쓴다.
알림장·가정통신문 확인: 방학 전 마지막 알림장이나 학교 앱 공지에 개학일 준비물이 적혀 있는 경우가 많다. 학교마다 다르니 공지를 다시 확인하는 게 제일 정확하다.
책가방 세탁: 한 학기 멘 가방은 생각보다 지저분하다. 주말에 빨아서 말려두면 새 학기 기분도 난다.

포인트는 이걸 부모 혼자 하지 않고 아이와 같이 한다는 거다. 자기 물건을 자기가 점검하는 경험이 쌓이면, 고학년쯤 되면 알아서 한다. 첫째가 올해 처음으로 혼자 가방을 다 싸놓은 걸 봤을 때, 몇 년 치 잔소리가 보상받는 기분이었다.

사진: Unsplash, Annie Spratt

미디어 시간 줄이기: 뺏지 말고 대체한다

방학 동안 늘어난 미디어 시간을 개학 전에 줄여놔야 하는데, 이게 수면만큼 어렵다. 그냥 "오늘부터 태블릿 금지"라고 선언하면 집안에 전쟁이 난다. 몇 번 실패해보고 정착한 방법은 뺏는 게 아니라 대체하는 것이다.

미디어 시간을 줄이는 만큼 다른 걸 채워 넣는다. 오후에 놀이터나 자전거 같은 몸 쓰는 활동을 넣고, 저녁에는 보드게임이나 책 읽는 시간을 넣는다. 할 게 있으면 아이들은 생각보다 순순히 화면에서 떨어진다. 심심한데 화면까지 뺏으니까 싸움이 나는 거다.

그리고 시간을 줄일 때도 협상 테이블에 아이를 앉힌다. "개학하면 학교 다녀와서 숙제하고 나면 태블릿 볼 시간이 하루 30분 정도야. 지금부터 조금씩 맞춰가자"라고 상황을 설명하고, 하루 총량을 아이와 같이 정한다. 자기가 정한 규칙은 지키려는 시늉이라도 하는데, 부모가 일방적으로 정한 규칙은 어기는 게 놀이가 된다. 애 셋 다 그랬다.

마음 준비: 개학이 싫은 건 정상이다

개학 전에 아이가 "학교 가기 싫어"라고 하면 부모는 덜컥한다. 나도 그랬다. 그런데 생각해보면 어른도 연휴 끝나고 출근하기 싫지 않나. 두 달 놀다가 학교 가는 게 싫은 건 지극히 정상이다. 이걸 "무슨 소리야, 학교는 가야지"라고 눌러버리면 아이는 입을 닫는다.

우리 집은 개학 전 주에 저녁 먹으면서 학교 얘기를 슬쩍슬쩍 꺼낸다. "개학하면 제일 보고 싶은 친구가 누구야?", "2학기에는 뭐가 제일 기대돼?" 같은 질문이다. 싫은 점을 캐묻는 것보다 기대되는 걸 묻는 쪽이 대화가 잘 굴러간다. 그러다 보면 아이 입에서 걱정거리가 자연스럽게 나오기도 한다. 친구 관계일 수도 있고, 급식일 수도 있고, 의외로 사소한 것일 때가 많다. 들어주는 것만으로 절반은 풀린다.

다만 개학하고 나서도 몇 주 넘게 배가 아프다거나, 아침마다 심하게 울면서 등교를 거부하는 상태가 이어지면 그건 단순한 개학 증후군이 아닐 수 있다. 그럴 땐 담임 선생님과 상담하고 필요하면 전문가의 도움을 받는 게 맞다. 아이마다 상황이 다르니, 집에서의 노력만으로 해결하려고 붙들고 있지 않는 게 좋다고 생각한다.

사진: Unsplash, Estée Janssens

아빠가 할 수 있는 가장 큰 기여: 주말 아침을 버티는 것

맞벌이든 아니든, 개학 준비 기간에 아빠가 할 수 있는 제일 실질적인 기여는 아침 담당을 나눠 지는 것이라고 생각한다. 기상 전쟁은 혼자 치르면 지옥이고 둘이 치르면 그럭저럭 할 만하다. 우리 집은 내가 아침에 아이들 깨우고 밥 먹이는 담당, 아내가 옷과 가방 담당으로 나눴다. 역할이 정해져 있으면 아침에 서로 눈치 볼 일도, "당신이 좀 하지"라는 말이 나올 일도 줄어든다.

그리고 개학 첫 주말에는 아이들을 좀 풀어준다. 일주일 내내 리듬 맞추느라 애들도 긴장했을 테니, 주말 하루쯤은 좋아하는 거 실컷 하게 둔다. 대신 일요일 밤에는 다시 제 시간에 재운다. 당기는 건 일주일 걸리지만 무너지는 건 하루면 충분하다는 걸 여러 번 확인했다.

방학 숙제: 마지막 사흘의 지옥을 피하는 법

생활 리듬 얘기만 했는데, 사실 개학 전 일주일의 최대 복병은 방학 숙제다. 밀린 일기, 손도 안 댄 독후감, 만들다 만 만들기. 이게 남아 있으면 수면이고 리허설이고 다 무너진다. 마지막 이틀 밤을 숙제로 새우면 리듬 당기기는 물 건너간다.

그래서 우리 집은 개학 D-7에 숙제 재고 조사부터 한다. 남은 숙제를 전부 꺼내놓고 목록을 만든 다음, 남은 날짜로 나눈다. 일 시키는 것과 비슷하다. 큰 덩어리를 그대로 두면 애도 어른도 시작을 못 하는데, "오늘은 일기 두 개랑 독후감 한 쪽"처럼 잘게 쪼개주면 어떻게든 굴러간다. 하루치 분량을 끝내면 그날 미디어 시간을 정상 지급하는 식으로 연결해두면 동기부여도 된다.

밀린 일기는 솔직히 고백하면 우리 집도 완벽하게 못 챙긴다. 다만 사진첩을 같이 넘겨보면서 "이날 뭐 했는지 기억나?" 하고 되짚어주면 아이가 생각보다 잘 써낸다. 두 달 전 일을 맨땅에서 기억해내라는 건 어른한테도 무리한 요구다. 거들 수 있는 건 거들어주되, 쓰는 건 아이 손으로 쓰게 한다.

2학기 스케줄 세팅: 개학 전에 어른이 해둘 일

아이 리듬을 당기는 동안 어른이 해둬야 할 사무 작업도 있다. 개학하고 나서 허둥대지 않으려면 이 정도는 미리 점검해두는 게 좋다.

학교 앱·알림장 앱 알림 켜기: 방학 동안 꺼두거나 알림을 묵음 처리한 경우가 많다. 개학 주간에는 준비물·시간표 공지가 몰려서 나오니 미리 살려둔다.
2학기 학원·돌봄 시간표 확인: 학기가 바뀌면서 하교 시간이나 학원 시간이 바뀌는 경우가 있다. 하교 후 아이 동선을 종이에 한 번 그려보면 구멍이 보인다. 애가 셋이면 동선이 세 개라, 우리 집은 공유 캘린더에 셋 색깔을 다르게 넣어서 관리한다.
비상 연락 체계 점검: 하교 시간에 부모가 둘 다 못 받는 상황일 때 누구한테 연락이 가는지, 아이가 그걸 아는지 확인한다. 1학기에 한 번 겪어보고 나서 챙기게 됐다.
계절 환절기 대비: 8월 말 개학이면 낮은 여전히 덥지만 아침저녁으로 선선해지는 시기다. 얇은 겉옷 하나씩 가방에 넣어두면 유용하다.

이런 건 아이가 할 수 없는 영역이라 어른 몫이다. 개발 일로 치면 배포 전에 환경 변수와 모니터링부터 점검하는 것과 비슷하다. 본 게임은 개학 후에 시작되는데, 인프라가 안 잡혀 있으면 첫 주 내내 장애 대응만 하게 된다.

정리: 우리 집 개학 D-7 체크리스트

글이 길어졌으니 우리 집에서 실제로 쓰는 순서를 요약하고 마친다.

D-7: 기상·취침 시간 30분 당기기 시작. 자기 전 한 시간 화면 끄기.
D-6~D-4: 수면 시간 계속 당기기. 오후 활동량 늘리기. 미디어 총량 아이와 재협상.
주말: 준비물 점검(필통·실내화·이름표·가방 세탁). 학교 공지 재확인. 아이와 같이 진행.
D-3~D-2: 등교 리허설 한 번. 병목 구간 찾아서 전날 밤으로 옮기기(옷·가방).
D-1: 목표 취침 시간 도달. 저녁 먹으며 2학기 기대되는 것 얘기하기.
개학 후 첫 주말: 하루는 풀어주되, 일요일 밤 취침 시간은 사수.

완벽하게 되냐고 물으면, 당연히 아니다. 계획대로 안 되는 날이 절반이다. 그래도 일주일 전에 시작한 해와 전날 밤에 벼락치기한 해는 개학 첫 주의 피로도가 확실히 다르다. 아이 셋 데리고 여러 번 실험해본 사람의 결론이니, 이번 개학을 앞둔 집이라면 오늘 밤 취침 시간 30분 당기는 것부터 시작해보시길. 그 30분이 개학 첫 주 아침의 평화를 만든다.

AWS 비용 절감 실전 가이드, 청구서에서 새는 돈을 잡는 8가지 점검 포인트

Lovizu — Fri, 21 Aug 2026 03:06:34 +0900

매달 초가 되면 저는 습관처럼 AWS 청구서를 엽니다. 예전 회사에서 월 청구액이 예상보다 40% 넘게 튀어나온 적이 있었는데, 그때 원인을 추적하면서 알게 된 게 하나 있습니다. AWS 요금은 큰 실수 하나로 터지는 게 아니라, 아무도 안 보는 작은 낭비들이 조용히 쌓여서 터진다는 겁니다.

이번 글은 제가 실무에서 실제로 잡아냈던 AWS 비용 낭비 포인트들을 정리한 것입니다. 콘솔에서 바로 확인할 수 있는 것들 위주라, 오늘 점심시간에 하나씩 열어보면서 따라 해볼 수 있는 수준으로 썼습니다.

사진: Unsplash의 Growtika

0. 시작은 무조건 비용 가시화부터

비용 절감 얘기를 하면 다들 인스턴스 줄이는 것부터 떠올리는데, 순서가 틀렸습니다. 뭐가 얼마나 나가는지 모르는 상태에서 줄이는 건 감으로 하는 다이어트와 같습니다.

제가 새 계정을 맡으면 제일 먼저 하는 세 가지입니다.

Cost Explorer 활성화: 서비스별, 리전별, 태그별로 어디서 돈이 새는지 그래프로 보입니다. 활성화 자체는 무료입니다.
AWS Budgets 알람: 월 예산을 잡고 50%, 80%, 100% 도달 시 메일이 오게 겁니다. 5분이면 설정하는데, 이거 하나로 "월말에 청구서 보고 놀라는" 상황은 사라집니다.
비용 할당 태그: 리소스마다 프로젝트/환경(prod, dev) 태그를 붙입니다. 태그가 없으면 "이 비용이 어느 서비스 건지"를 아무도 답 못 하는 순간이 반드시 옵니다.

이 세 개가 깔려 있어야 아래 항목들을 점검할 때 효과가 숫자로 보입니다.

1. EC2: 켜져 있는 것 자체가 돈이다

EC2는 대부분 조직에서 청구서의 가장 큰 덩어리입니다. 그런데 의외로 절감 포인트는 단순한 데 있습니다.

개발/스테이징 서버는 퇴근하면 끕니다. 평일 9시부터 21시까지만 켜도 한 달 가동 시간이 730시간에서 260시간 수준으로 떨어집니다. 인스턴스 요금이 3분의 1이 되는 셈입니다. EventBridge 스케줄러와 Lambda 몇 줄이면 자동으로 켜고 끌 수 있고, Instance Scheduler라는 AWS 공식 솔루션도 있습니다. 저희 팀은 이걸 적용하고 개발 계정 EC2 비용이 실제로 60% 넘게 줄었습니다.

인스턴스 세대를 올리는 것도 절감입니다. 같은 사양이면 신형 세대가 대체로 더 싸거나 성능이 좋습니다. 특히 Graviton(ARM) 계열은 동급 x86 대비 가격 대비 성능이 눈에 띄게 낫습니다. 저는 처음에 "ARM으로 바꾸면 뭔가 안 돌아가지 않을까" 걱정했는데, 요즘 웹 애플리케이션 스택은 웬만하면 그냥 돌아갑니다. 도커 이미지만 멀티 아키텍처로 빌드해두면 전환 부담이 크지 않았습니다.

1년 이상 켜둘 게 확실한 서버는 Savings Plans를 겁니다. 온디맨드 대비 대략 30~40% 아낍니다. 다만 약정은 "확실한 것만, 보수적으로"가 원칙입니다. 트래픽이 어떻게 될지 모르는 신규 서비스에 3년 약정부터 거는 건 절감이 아니라 도박입니다.

2. EBS: gp2로 남아 있는 볼륨은 그냥 손해

은근히 많이 놓치는 항목입니다. EBS 볼륨 타입이 아직 gp2라면 gp3로 바꾸는 것만으로 GB당 요금이 약 20% 내려갑니다. gp3는 기본 성능(3000 IOPS)이 보장되기 때문에, 소형 볼륨에서는 오히려 gp2보다 성능이 좋아지는 경우도 많습니다. 무중단으로 변경 가능해서 사실상 리스크 없는 절감입니다.

하나 더, 주인 잃은 볼륨과 스냅샷입니다. 인스턴스를 종료해도 EBS 볼륨이 남는 설정이었다면, 콘솔에서 상태가 available인 볼륨들이 조용히 과금되고 있을 겁니다. 오래된 AMI와 스냅샷도 마찬가지입니다. 분기에 한 번은 available 볼륨과 연결 안 된 스냅샷을 정리하는 걸 권합니다.

사진: Unsplash의 imgix

3. NAT Gateway: 조용한 과금의 제왕

제가 겪은 비용 사고 중 제일 황당했던 게 이겁니다. NAT Gateway는 시간당 요금에 더해 처리한 데이터 GB당 요금이 붙습니다. 프라이빗 서브넷의 서버들이 S3나 외부 API로 데이터를 많이 보내면, 그 트래픽이 전부 NAT를 통과하면서 요금이 쌓입니다.

당시 저희는 프라이빗 서브넷의 배치 서버가 S3에 대용량 파일을 올리는 구조였는데, 이 트래픽이 몽땅 NAT를 타고 있었습니다. S3와 DynamoDB는 게이트웨이 VPC 엔드포인트가 무료입니다. 엔드포인트 하나 붙이는 것으로 그 트래픽의 NAT 비용이 통째로 사라졌습니다. VPC에 NAT Gateway를 쓰고 있다면 Cost Explorer에서 NatGateway 항목을 꼭 한번 확인해보세요. 생각보다 큰 금액이 잡혀 있는 경우가 많습니다.

4. S3: 수명주기 정책 없이 쌓기만 하면 창고비가 된다

S3는 쌓는 건 쉬운데 치우는 건 아무도 안 합니다. 로그, 백업, 임시 산출물이 Standard 클래스에 몇 년씩 쌓여 있는 버킷을 저는 여러 번 봤습니다.

수명주기(Lifecycle) 정책: 30일 지나면 Standard-IA로, 90일 지나면 Glacier 계열로 내리고, 로그처럼 보존 기한이 있는 건 만료 삭제까지 걸어둡니다.
Intelligent-Tiering: 접근 패턴을 예측하기 어려운 버킷은 이걸로 두면 알아서 저렴한 계층으로 옮겨줍니다. 고민할 시간에 이걸 켜는 게 나은 경우가 많습니다.
미완료 멀티파트 업로드 정리: 대용량 업로드가 중간에 실패하면 조각 파일이 보이지 않게 남아 과금됩니다. 수명주기 정책에서 "incomplete multipart upload 7일 후 중단" 규칙은 모든 버킷에 기본으로 넣어두는 게 좋습니다.

5. CloudWatch Logs: 보존 기간 기본값이 '무제한'이다

이건 아는 순간 바로 고치게 되는 항목입니다. CloudWatch 로그 그룹의 보존 기간 기본값은 무기한입니다. Lambda나 ECS를 쓰면 로그 그룹이 자동 생성되는데, 손대지 않으면 로그가 영원히 쌓입니다. 로그 그룹 목록에서 보존 기간을 30일이나 90일로 일괄 지정하는 것만으로 매달 나가던 저장 비용이 잡힙니다. 장기 보존이 필요한 로그는 S3로 내보내서 Glacier로 내리는 게 훨씬 쌉니다.

6. RDS: 스냅샷과 과잉 사양을 의심하라

RDS는 함부로 줄이기 무서운 영역이지만, 그래도 점검할 건 있습니다. CloudWatch에서 CPU와 메모리(FreeableMemory) 지표를 2주 이상 봤을 때 CPU가 늘 10% 아래라면 한 단계 다운사이징을 검토할 만합니다. 수동 스냅샷은 자동 백업과 달리 지우기 전까지 계속 과금되니, "혹시 몰라서" 만들어둔 오래된 수동 스냅샷을 정리합니다. 개발용 RDS는 EC2처럼 야간 중지가 가능합니다(최대 7일). 그리고 프로덕션이 아닌 DB에 멀티 AZ가 켜져 있다면, 그건 비용이 정확히 2배로 나가고 있다는 뜻입니다.

사진: Unsplash의 Recha Oktaviani

7. 데이터 전송 비용: 아키텍처 그림에는 안 보이는 요금

AWS 요금표에서 제일 읽기 어려운 게 데이터 전송입니다. 기억할 것만 추리면 이렇습니다. 들어오는 건 대체로 무료, 나가는 건 유료, 그리고 가용영역(AZ) 간 이동도 유료입니다.

실무에서 자주 걸리는 패턴은 두 가지였습니다. 첫째, 외부로 나가는 정적 콘텐츠를 EC2나 S3에서 직접 서빙하는 경우. CloudFront를 앞에 두면 전송 단가도 내려가고 원본 부하도 줍니다. 둘째, 마이크로서비스끼리 AZ를 넘나들며 통신하는 경우. 같은 AZ 안에서 통신하도록 배치만 조정해도 전송 비용이 내려갑니다. 트래픽이 커질수록 이 차이는 무시 못 할 금액이 됩니다.

번외 1. Lambda: 메모리 설정이 곧 요금 설정이다

서버리스라서 싸다고 생각하고 방치하기 쉬운 게 Lambda입니다. Lambda 요금은 실행 시간 곱하기 할당 메모리로 계산되는데, 재미있는 건 메모리를 올리면 CPU도 같이 올라가서 실행 시간이 줄어든다는 점입니다. 그래서 메모리 128MB로 아껴 쓴다고 설정한 함수가, 512MB로 올린 함수보다 오히려 비싼 경우가 실제로 있습니다. 실행 시간이 4배 넘게 걸리면 손해거든요.

AWS Lambda Power Tuning이라는 오픈소스 도구를 쓰면 메모리 구간별 비용과 속도를 그래프로 뽑아줍니다. 저는 호출량 많은 함수 몇 개만 이걸로 점검했는데, 함수 두 개는 메모리를 올리는 게 더 싸다는 결과가 나왔습니다. "메모리를 올렸더니 요금이 내려간다"는 건 직접 보기 전엔 잘 안 믿기는 경험입니다.

또 하나, Lambda가 같은 VPC 안의 RDS를 붙는 구조라면 앞서 말한 NAT Gateway 비용과 CloudWatch 로그 비용이 함께 따라온다는 것도 기억해둘 필요가 있습니다. 서버리스 비용 사고는 함수 자체보다 주변 리소스에서 나는 경우가 더 많았습니다.

번외 2. 재발 방지: 사람 눈 말고 알람에게 맡겨라

한 번 정리하고 끝내면 6개월 뒤에 똑같은 낭비가 다시 쌓여 있습니다. 사람이 계속 들여다보는 건 지속 가능하지 않아서, 저는 감시를 시스템에 넘기는 쪽으로 정리했습니다.

Cost Anomaly Detection: 평소 패턴에서 벗어난 비용 급증을 잡아서 알려줍니다. 무료고, 설정도 몇 분이면 끝납니다. 특정 서비스 요금이 갑자기 튀는 사고는 월말 청구서가 아니라 이 알람으로 먼저 알게 되는 게 정상입니다.
Trusted Advisor / Compute Optimizer: 유휴 리소스, 과잉 사양 인스턴스를 자동으로 짚어줍니다. 분기 점검 때 이 리포트부터 열면 어디를 볼지 고민할 필요가 없습니다.
태그 정책 강제: 태그 없는 리소스는 생성 단계에서 막거나, 최소한 주간 리포트로 잡아냅니다. 비용 추적의 절반은 태그 규율에서 나옵니다.

팀에 공유할 때는 "아끼자"라는 구호보다 숫자 하나를 보여주는 게 효과적이었습니다. 개발 서버 야간 중지 하나로 월 얼마가 줄었는지 슬랙에 공유했더니, 그다음부터는 팀원들이 먼저 "이 인스턴스 스케줄 걸까요?"라고 물어보기 시작했습니다.

점검 체크리스트 요약

위 내용을 실제 점검 순서로 정리하면 이렇습니다.

Cost Explorer, Budgets 알람, 비용 태그부터 세팅한다.
개발/스테이징 EC2에 야간·주말 자동 중지를 건다.
gp2 볼륨을 gp3로 바꾸고, available 볼륨과 고아 스냅샷을 정리한다.
NAT Gateway 트래픽을 확인하고 S3/DynamoDB는 VPC 엔드포인트로 돌린다.
S3 전 버킷에 수명주기 정책과 미완료 멀티파트 정리 규칙을 넣는다.
CloudWatch 로그 그룹 보존 기간을 일괄 지정한다.
RDS 지표를 보고 사양·스냅샷·멀티 AZ를 재검토한다.
안정 워크로드에만 보수적으로 Savings Plans를 적용한다.

경험상 1~6번까지는 서비스에 영향 없이 적용할 수 있는 것들이고, 이것만으로도 청구서가 두 자릿수 퍼센트로 내려가는 조직이 많습니다.

마치며

AWS 비용 최적화는 한 방이 없습니다. 새는 구멍을 하나씩 막고, 알람으로 재발을 감시하는 반복 작업에 가깝습니다. 저는 매월 첫 주에 30분짜리 "청구서 리뷰" 일정을 캘린더에 박아두는데, 애 셋 학원비 나가는 걸 생각하면 회사 돈이라도 새는 꼴을 못 보는 성격이 된 것 같습니다. 가정 경제든 클라우드든, 결국 가계부 쓰는 사람이 이깁니다.

다음 AWS 글에서는 이번에 짧게 언급한 개발 서버 자동 켜기/끄기를 EventBridge 스케줄러와 Lambda로 구현하는 과정을 코드와 함께 정리해보겠습니다.

인덱스를 걸었는데도 쿼리가 느린 이유, MySQL 실행계획으로 잡는 실전 정리

Lovizu — Thu, 20 Aug 2026 03:08:17 +0900

운영 DB에서 특정 화면이 느리다는 제보를 받으면, 저는 제일 먼저 쿼리부터 봅니다. 그런데 쿼리를 열어보면 십중팔구 이런 반응이 나옵니다. "어? 이거 인덱스 있는데?" 인덱스가 있다는 것과 인덱스를 탄다는 것은 완전히 다른 얘기입니다. 이 차이를 모르면 인덱스를 아무리 추가해도 쿼리는 계속 느립니다.

이번 글은 제가 실무에서 반복적으로 만난 "인덱스가 있는데도 안 타는" 케이스들을 MySQL 기준으로 정리한 것입니다. 대부분 EXPLAIN 한 번이면 원인이 보이는 것들인데, 처음 겪으면 한참 헤매게 되는 유형들입니다.

사진: Unsplash의 Growtika

먼저 EXPLAIN 읽는 법부터, 딱 세 컬럼만

실행계획을 처음 보면 컬럼이 많아서 부담스러운데, 실무에서 문제를 잡을 때 제가 먼저 보는 건 딱 세 개입니다.

EXPLAIN SELECT * FROM orders WHERE user_id = 12345;

type: 접근 방식입니다. const, eq_ref, ref, range까지는 양호하고, index는 애매하고, ALL이 나오면 풀스캔입니다. 느린 쿼리의 범인은 대부분 ALL입니다.
rows: 옵티마이저가 "이 정도 읽어야겠다"고 추정한 행 수입니다. 실제 결과가 10건인데 rows가 200만이면, 200만 건을 훑어서 10건을 골라내고 있다는 뜻입니다.
Extra: Using filesort, Using temporary가 보이면 정렬이나 임시 테이블에서 비용이 나가고 있다는 신호입니다.

key 컬럼에 인덱스 이름이 찍혀 있다고 안심하면 안 됩니다. 인덱스를 "쓰긴 쓰는데" 범위를 못 좁혀서 사실상 풀스캔에 가까운 경우도 많습니다. 그래서 type과 rows를 같이 봐야 합니다.

사례 1. 컬럼을 함수로 감싸면 인덱스는 무용지물

제일 흔한 유형입니다. 날짜 조건 걸 때 이렇게 쓰는 경우가 많습니다.

-- created_at에 인덱스가 있어도 풀스캔
SELECT * FROM orders
WHERE DATE(created_at) = '2026-08-19';

인덱스는 created_at의 원본 값으로 정렬돼 있습니다. 그런데 DATE()로 가공한 값과 비교하면, MySQL은 모든 행에 대해 함수를 실행해본 뒤에야 조건을 판단할 수 있습니다. 인덱스 정렬 순서를 활용할 수 없으니 풀스캔이 됩니다.

고치는 방법은 컬럼을 그대로 두고 조건 쪽을 범위로 바꾸는 겁니다.

-- 인덱스 range 스캔
SELECT * FROM orders
WHERE created_at >= '2026-08-19 00:00:00'
  AND created_at < '2026-08-20 00:00:00';

같은 원리로 WHERE SUBSTRING(code, 1, 3) = 'ABC', WHERE amount * 1.1 > 10000 같은 것도 전부 인덱스를 못 탑니다. 규칙은 하나입니다. WHERE 절에서 인덱스 컬럼은 절대 가공하지 않는다. 가공은 항상 반대편, 즉 상수 쪽에서 합니다.

사례 2. 자료형이 다르면 조용히 풀스캔이 된다

이건 저도 운영에서 한 번 제대로 당한 적이 있습니다. 사용자 식별 코드를 VARCHAR로 저장한 테이블이 있었는데, 애플리케이션에서 숫자로 조건을 넘겼습니다.

-- user_code는 VARCHAR, 인덱스 있음
SELECT * FROM members WHERE user_code = 12345;   -- 풀스캔
SELECT * FROM members WHERE user_code = '12345'; -- 인덱스 사용

문자열 컬럼과 숫자를 비교하면 MySQL은 컬럼 쪽을 숫자로 암묵적 형변환합니다. 컬럼이 변환된다는 건 사례 1과 똑같이 "컬럼을 가공한" 상황이라 인덱스를 못 탑니다. 무서운 점은 에러가 안 난다는 겁니다. 결과는 똑같이 나오고, 데이터가 적을 땐 느린지도 모릅니다. 데이터가 수백만 건 쌓인 뒤에야 터집니다.

당시엔 배포 후 특정 API만 응답이 3초씩 걸려서 한참 뒤졌는데, 원인은 ORM 쪽에서 파라미터 타입이 int로 바뀐 커밋 하나였습니다. 이후로 저는 코드 리뷰에서 WHERE 조건의 타입 일치를 습관적으로 봅니다.

사진: Unsplash의 MARCO

사례 3. 복합 인덱스는 순서가 전부다

복합 인덱스 (a, b, c)는 전화번호부와 같습니다. 성으로 정렬하고, 같은 성 안에서 이름으로 정렬한 구조입니다. 그래서 왼쪽 컬럼부터 조건이 있어야 인덱스가 제 역할을 합니다.

-- INDEX idx_status_created (status, created_at)

-- 인덱스 잘 탐
WHERE status = 'PAID' AND created_at >= '2026-08-01'

-- status 조건이 없으면 이 인덱스로 범위를 못 좁힘
WHERE created_at >= '2026-08-01'

또 하나 자주 놓치는 규칙이 있습니다. 범위 조건을 만난 뒤의 컬럼은 인덱스 정렬을 활용하지 못한다는 점입니다.

-- INDEX (status, created_at, amount)
WHERE status = 'PAID'
  AND created_at >= '2026-08-01'   -- 범위 조건
  AND amount = 50000               -- 여기부터는 필터링으로만 동작

그래서 복합 인덱스를 설계할 땐 동등 비교(=) 컬럼을 앞에, 범위 조건 컬럼을 뒤에 두는 게 기본입니다. 인덱스를 새로 팔 때 저는 항상 "이 테이블에서 제일 자주 나오는 WHERE 조합이 뭔가"부터 쿼리 로그로 확인하고 순서를 정합니다.

사례 4. LIKE '%키워드%'는 인덱스가 못 돕는다

검색 기능 만들 때 단골로 나오는 문제입니다.

SELECT * FROM products WHERE name LIKE '%노트북%';  -- 풀스캔
SELECT * FROM products WHERE name LIKE '노트북%';   -- range 스캔

인덱스는 앞에서부터 정렬돼 있어서, 앞부분이 와일드카드면 어디서 시작할지 정할 수가 없습니다. 전방 일치(키워드%)만 인덱스를 탑니다. 중간 일치 검색이 정말 필요하면 MySQL 풀텍스트 인덱스(ngram parser)를 쓰거나, 검색 트래픽이 크면 Elasticsearch 같은 검색 엔진으로 빼는 게 맞습니다. 어중간하게 LIKE '%...%'를 운영 테이블에 그대로 두면 데이터가 커질수록 조용히 전체 서비스를 갉아먹습니다.

사례 5. 인덱스는 탔는데 여전히 느린 경우

EXPLAIN에서 type도 ref고 key도 잘 찍혀 있는데 느린 경우가 있습니다. 이때 의심할 건 두 가지입니다.

첫째, 카디널리티가 낮은 컬럼. status 같은 컬럼에 값이 3종류밖에 없고 그중 'DONE'이 전체의 90%라면, 'DONE'으로 조회할 때 인덱스를 타는 게 오히려 손해일 수 있습니다. 인덱스로 위치를 찾고 다시 테이블로 가서 행을 읽는 왕복 비용이, 그냥 처음부터 쭉 읽는 것보다 비싸지기 때문입니다. 옵티마이저가 알아서 풀스캔을 선택하기도 하는데, 그게 오히려 정상 판단인 경우입니다.

둘째, 커버링 인덱스가 아닌 경우의 테이블 왕복. 조회 컬럼이 전부 인덱스 안에 있으면 테이블까지 안 가고 인덱스만 읽고 끝납니다. EXPLAIN의 Extra에 Using index가 뜨면 커버링으로 동작한다는 뜻입니다.

-- INDEX (user_id, status, created_at)
SELECT status, created_at        -- 인덱스만 읽고 끝 (Using index)
FROM orders WHERE user_id = 12345;

SELECT *                         -- 행마다 테이블 왕복 발생
FROM orders WHERE user_id = 12345;

목록 화면처럼 자주 호출되는 쿼리는 SELECT * 를 걷어내고 필요한 컬럼만 남긴 뒤, 그 컬럼들이 인덱스에 포함되도록 설계하면 눈에 띄게 빨라집니다. 실제로 페이지네이션 쿼리 하나를 커버링 인덱스로 바꿔서 평균 응답이 수백 ms에서 수십 ms로 내려간 적도 있습니다.

사진: Unsplash의 Albert Stoynov

정렬이 느리면 ORDER BY와 인덱스 방향을 보라

Extra에 Using filesort가 떠 있다면 정렬을 인덱스로 해결하지 못하고 있다는 뜻입니다. WHERE와 ORDER BY가 같은 인덱스를 타도록 맞춰주면 filesort가 사라집니다.

-- INDEX (user_id, created_at)
SELECT * FROM orders
WHERE user_id = 12345
ORDER BY created_at DESC
LIMIT 20;

이 쿼리는 인덱스를 뒤에서부터 20건만 읽고 끝납니다. filesort도 없고, LIMIT 덕에 읽는 양 자체가 적습니다. 반대로 WHERE 컬럼과 ORDER BY 컬럼이 서로 다른 인덱스에 있으면, 옵티마이저는 둘 중 하나를 포기해야 해서 어느 쪽이든 비용이 생깁니다. 목록+정렬+페이징이 한 세트로 나오는 화면은 처음부터 (필터 컬럼, 정렬 컬럼) 복합 인덱스를 한 벌로 설계하는 게 좋습니다.

인덱스를 많이 단다고 빨라지지 않는다

여기까지 읽으면 "그럼 의심되는 컴럼마다 인덱스를 다 걸면 되겠네"라는 결론으로 가기 쉽습니다. 저도 주니어 때 그렇게 했다가 다른 문제를 만들었습니다. 인덱스는 공짜가 아닙니다.

INSERT, UPDATE, DELETE가 일어날 때마다 해당 테이블의 모든 인덱스도 같이 갱신됩니다. 인덱스가 8개 법어 있는 테이블은 행 하나를 쓸 때마다 8군데를 같이 손봐야 합니다. 쓰기 트래픽이 많은 테이블에서는 이게 그대로 쓰기 지연과 락 경합으로 돌아옵니다. 게다가 옵티마이저 입장에서는 후보 인덱스가 많을수록 선택이 복잡해져서, 어느 날 갑자기 엉뚱한 인덱스를 타는 사고도 생깁니다.

그래서 인덱스를 추가하기 전에 두 가지를 먼저 확인합니다. 첫째, 기존 복합 인덱스로 커버되는 조건인지. (a, b) 인덱스가 있으면 (a) 단독 인덱스는 중복입니다. 둘째, 쓰이지 않는 인덱스가 있는지. MySQL 8.0이면 sys.schema_unused_indexes 뷰로 한 번도 안 쓰인 인덱스를 바로 뽑을 수 있습니다. 분기에 한 번씩 이 뷰를 확인해서 죽은 인덱스를 정리하는 것만으로도 쓰기 성능과 디스크 비용이 개선됩니다.

실무용 점검 순서 요약

느린 쿼리를 만났을 때 제가 실제로 밟는 순서입니다.

EXPLAIN을 뜬다. type이 ALL인지, rows가 비정상적으로 큰지, Extra에 filesort/temporary가 있는지 본다.
WHERE 절에서 인덱스 컬럼이 함수나 연산으로 가공되고 있는지 확인한다.
비교하는 값의 자료형이 컬럼과 일치하는지 확인한다. 특히 VARCHAR 컬럼 vs 숫자 파라미터.
복합 인덱스라면 선두 컬럼 조건이 있는지, 범위 조건 뒤에 동등 조건이 밀려 있지 않은지 본다.
LIKE 패턴이 전방 일치인지 확인한다.
그래도 느리면 커버링 인덱스 여부와 카디널리티를 본다.

경험상 운영에서 만나는 느린 쿼리의 8할은 1~4번 안에서 끝납니다. 5~6번까지 가는 경우는 설계 자체를 다시 봐야 하는 경우가 많고요.

마치며

인덱스 튜닝은 거창한 기술이라기보다 습관에 가깝습니다. 쿼리를 짜면서 "이 조건이 인덱스 정렬을 활용할 수 있는 모양인가"를 한 번씩 되묻는 습관, 배포 전에 무거워질 만한 쿼리에 EXPLAIN을 한 번 떠보는 습관. 이 두 가지만 있어도 새벽에 DB CPU 알람 받고 일어나는 날이 확실히 줄어듭니다. 저처럼 애 셋 재우고 나서야 겨우 노트북을 여는 처지라면, 새벽 알람은 정말 피하고 싶으니까요.

다음에 기회가 되면 실행계획의 나머지 컬럼들(possible_keys, filtered, EXPLAIN ANALYZE)을 읽는 법도 따로 정리해보겠습니다.

결혼 11년차, 아이 셋 부부가 부부싸움을 줄인 현실적인 규칙 5가지

Lovizu — Wed, 19 Aug 2026 20:58:20 +0900

결혼한 지 11년이 넘었다. 아이는 셋이다. 이렇게 쓰면 어딘가 안정적인 가정처럼 보이지만, 사실 우리 부부도 많이 싸웠다. 신혼 때는 치약 짜는 방향 같은 걸로 싸웠고, 첫째가 태어난 뒤에는 잠 못 자는 서로에게 날을 세웠고, 셋째가 태어난 뒤에는 싸울 힘도 없어서 냉전을 했다. 부부싸움의 형태가 체력에 따라 진화한다는 걸 그때 알았다.

그런데 언제부턴가 싸움의 횟수가 눈에 띄게 줄었다. 사이가 갑자기 좋아져서가 아니다. 몇 가지 규칙을 만들었고, 그 규칙이 생각보다 잘 작동했기 때문이다. 오늘은 그 규칙들을 정리해보려고 한다. 결혼 10년차 전후로 비슷한 고민을 하는 분들, 특히 아이 키우면서 배우자와 자꾸 부딪히는 분들에게 조금이라도 참고가 됐으면 한다.

사진: Unsplash, Priscilla Du Preez

부부싸움의 원인은 대부분 '피곤함'이었다

돌이켜보면 우리 부부가 크게 싸운 날의 공통점은 주제가 아니라 컨디션이었다. 아이 셋을 재우고 나면 밤 10시가 넘는다. 그 시간의 나는 회사에서 하루 종일 시달리고 온 상태고, 아내는 하루 종일 아이들에게 시달린 상태다. 둘 다 배터리가 3% 남은 스마트폰 같은 상태에서 대화를 시작하니, 어떤 주제든 싸움으로 번졌다.

개발자답게 표현하자면, 문제는 로직이 아니라 리소스 부족이었다. 같은 코드도 메모리가 부족하면 죽는 것처럼, 같은 대화도 체력이 바닥이면 싸움이 된다. 이걸 인정하고 나니 해결 방향이 명확해졌다. 대화의 내용을 고치는 게 아니라, 대화의 조건을 고쳐야 했다.

규칙 1. 밤 10시 이후에는 중요한 이야기를 하지 않는다

우리 부부의 첫 번째 규칙이자 가장 효과가 컸던 규칙이다. 아이 교육 문제, 돈 문제, 양가 부모님 문제 같은 무거운 주제는 밤 10시 이후에 절대 꺼내지 않는다. 꺼내고 싶은 쪽이 "이거 주말에 이야기하자"라고 예약만 걸어둔다.

처음에는 답답했다. 지금 이야기하면 5분이면 끝날 것 같은데 왜 미루나 싶었다. 그런데 몇 번 해보니 알겠더라. 밤 10시의 5분짜리 대화는 실제로는 40분짜리 감정 소모전이 된다. 같은 주제를 토요일 오전에 커피 마시면서 이야기하면 정말로 5분 만에 끝난다. 결론도 더 합리적이다. 피곤할 때 내린 결정치고 좋은 결정을 본 적이 없다.

이 규칙의 핵심은 '예약'이다. 그냥 미루기만 하면 한쪽은 회피당했다고 느낀다. "안 하겠다"가 아니라 "언제 하겠다"를 정해야 서로 안심이 된다.

사진: Unsplash, Joel Henry

규칙 2. 집안일은 '도와주는 것'이 아니라 '분담하는 것'이다

결혼 초에 내가 자주 하던 말이 있다. "내가 설거지 도와줄게." 지금 생각하면 이 문장 자체가 문제였다. '도와준다'는 말에는 집안일의 주인이 아내라는 전제가 깔려 있다. 아내 입장에서는 매일 하는 일을 남편은 가끔 하면서 생색까지 내는 셈이니, 고마움보다 서운함이 쌓일 수밖에 없다.

지금 우리 집은 담당제로 운영된다. 설거지와 분리수거, 아이들 아침 등원 준비는 내 일이다. 아내가 시켜서 하는 게 아니라 그냥 내 일이다. 회사에서 내 담당 업무를 누가 시켜야 하는 게 아닌 것과 같다. 담당이 정해지니 "왜 안 했냐"는 잔소리도, "해줬는데 왜 몰라주냐"는 서운함도 사라졌다. 각자 자기 일을 하고, 상대가 힘들어 보이면 그때 백업을 해주면 된다.

담당을 나눌 때 팁이 하나 있다면, 잘하는 일이 아니라 덜 싫어하는 일을 맡는 게 오래간다. 나는 요리는 못 하지만 설거지는 아무 생각 없이 할 수 있는 사람이라 설거지를 맡았다. 10년 넘게 유지되는 걸 보면 이 배분이 맞았던 것 같다.

규칙 3. 일주일에 한 번, 아이 이야기 없는 대화 30분

아이 셋을 키우다 보면 부부의 대화가 전부 업무 회의가 된다. 첫째 학원 상담, 둘째 예방접종, 셋째 기저귀 재고. 어느 날 문득 세어보니 아내와 나눈 대화 중에 아이와 무관한 이야기가 일주일에 채 10분이 안 됐다. 부부가 아니라 육아 법인의 공동대표 같았다.

그래서 만든 게 주 1회 30분 대화 시간이다. 보통 토요일 밤, 아이들이 다 잠든 뒤에 거실에서 맥주나 차를 한 잔 두고 앉는다. 규칙은 하나다. 아이 이야기 금지. 처음에는 어색했다. 아이 빼고 나니 할 말이 없어서 10분 만에 정적이 흘렀다. 그 정적이 좀 충격이었다. 연애할 때는 밤새 통화하던 사람들인데.

몇 주 하다 보니 근육이 다시 붙었다. 요즘 아내가 보는 드라마 이야기, 내가 회사에서 겪은 황당한 일, 나중에 둘이 가보고 싶은 여행지 같은 이야기가 다시 나오기 시작했다. 대단한 대화는 아니다. 그런데 이 30분이 있는 주와 없는 주는 부부 사이의 공기가 다르다. 서로를 부모가 아니라 사람으로 다시 보게 되는 시간이라서 그런 것 같다.

사진: Unsplash, Katie Puzatova

규칙 4. 돈 이야기는 정기적으로, 감정 없이

부부싸움의 단골 주제가 돈이다. 우리도 그랬다. 그런데 잘 뜯어보면 돈 자체보다, 돈 이야기를 꺼내는 타이밍이 문제였던 적이 많다. 카드값이 많이 나온 날 갑자기 "이번 달 왜 이렇게 썼어?"라고 물으면, 그건 질문이 아니라 추궁이 된다. 듣는 쪽은 방어부터 하게 되고, 대화는 시작하자마자 감정전이 된다.

그래서 우리는 월 1회 가계 결산을 정례화했다. 매월 첫째 주말에 30분, 지난달 지출을 같이 열어보고 이번 달 큰 지출 계획을 공유한다. 정기 일정이 되니 신기한 일이 생겼다. 같은 이야기인데 아무도 기분 나빠하지 않는다. 회사에서 월간 결산 회의를 하면서 화내는 사람이 없는 것과 같다. 문제를 사람에게서 분리해서 숫자로 보게 되기 때문이다.

비상금 문제, 양가 용돈 문제처럼 예민한 주제도 이 자리에서 다룬다. 예민한 주제일수록 즉흥적으로 꺼내면 안 된다는 게 11년 치 데이터에서 얻은 결론이다.

규칙 5. 사과는 빠르게, 원인 분석은 나중에

개발자 생활을 오래 하면 장애 대응 원칙이 몸에 밴다. 장애가 나면 일단 서비스부터 복구하고, 원인 분석은 상황이 안정된 뒤에 한다. 복구보다 원인 규명을 먼저 하겠다고 서버를 붙잡고 있으면 피해만 커진다.

부부싸움도 똑같다는 걸 한참 뒤에 깨달았다. 싸움이 났을 때 그 자리에서 누가 잘못했는지 시시비비를 가리려고 하면 싸움은 무조건 길어진다. 지금 우리 부부는 일단 복구부터 한다. 내가 말이 심했다 싶으면 잘잘못 계산 전에 먼저 사과한다. "아까 말투는 미안했다" 정도면 된다. 전체 잘못을 인정하는 게 아니라 명백한 내 지분만 먼저 인정하는 거다.

그리고 하루 이틀 지나 둘 다 평온해졌을 때 짧게 회고를 한다. 그때 이야기하면 "사실 그날 내가 회사에서 안 좋은 일이 있었다"거나 "그 말이 유독 서운했다" 같은 진짜 원인이 나온다. 싸움 당일에는 절대 안 나오는 이야기들이다. 사과가 빠를수록 회고의 품질이 좋아진다는 것도 장애 대응과 똑같다.

사진: Unsplash, Amy Humphries

효과 없었던 방법들도 있었다

규칙 이야기만 하면 처음부터 잘한 것처럼 보일까 봐, 실패담도 적어둔다. 우리 부부가 시도했다가 접은 방법이 몇 가지 있다.

첫 번째는 편지 쓰기였다. 어디선가 부부 사이에는 말보다 글이 좋다는 이야기를 듣고 시도했는데, 우리에게는 안 맞았다. 나는 글로 쓰면 자꾸 논리적으로 정리하려 들어서 편지가 보고서가 됐고, 아내는 그 보고서 같은 편지를 받고 더 서운해했다. 부부 관계 조언은 유행을 타는데, 유행하는 방법이라고 우리에게 맞는 건 아니었다.

두 번째는 무조건 그 자리에서 풀고 자기였다. "해가 지기 전에 화해하라"는 말을 곧이곧대로 실천했더니, 밤 12시 넘어서까지 억지로 대화를 이어가다가 싸움이 2차전으로 번지기 일쑤였다. 우리에게는 차라리 하루 자고 일어나서 이야기하는 쪽이 나았다. 물론 냉전을 며칠씩 끌면 안 되니, "내일 이야기하자"고 한마디는 하고 잔다. 이것도 결국 규칙 1의 변형이다.

세 번째는 기념일 이벤트로 만회하기였다. 평소에 쌓인 게 있는데 생일이나 결혼기념일에 큰 선물로 퉁치려고 하면, 그 순간은 좋아도 근본적으로 달라지는 게 없었다. 관계는 이벤트가 아니라 평일의 운영에서 결정된다는 걸 몇 번의 시행착오 끝에 인정했다. 연 1회의 감동보다 주 1회의 30분이 세다.

아이들 앞에서 싸웠을 때의 원칙

아이 셋을 키우다 보니 하나 더 생긴 원칙이 있다. 아이들 앞에서 언성이 높아졌다면, 화해도 아이들이 보는 데서 한다는 것이다.

어느 날 첫째가 물었다. "아빠, 엄마랑 싸웠어?" 그 순간 아차 싶었다. 우리는 안방에서 화해했지만 아이는 싸우는 장면만 봤던 거다. 아이 입장에서는 부모가 싸우고 그걸로 끝인 세상을 산 셈이다. 그 뒤로는 아이들 앞에서 부딪힌 날에는 일부러 아이들 앞에서 사과한다. "아까 아빠가 엄마한테 말을 심하게 했어. 미안하다고 했고, 화해했어." 이렇게 한 문장이라도 보여준다.

기대 이상의 효과가 있었다. 아이들끼리 싸웠을 때 사과하고 회복하는 모습이 달라졌다. 갈등이 없는 집을 보여주는 건 불가능하지만, 갈등을 수습하는 모습은 보여줄 수 있다. 어쩌면 그게 부부싸움이 육아에 기여할 수 있는 유일한 방식일지도 모르겠다.

규칙이 부부 사이를 삭막하게 만들지 않을까

이런 이야기를 하면 가끔 듣는 말이 있다. 부부 사이에 무슨 규칙이냐, 정 없어 보인다는 반응이다. 나도 처음엔 그렇게 생각했다. 그런데 지금은 반대로 생각한다. 규칙이 없을 때 우리는 서로의 컨디션과 눈치에 모든 걸 맡겼고, 그 결과가 반복되는 싸움이었다. 규칙은 애정을 대체하는 게 아니라, 애정이 소모되지 않게 지켜주는 가드레일에 가깝다.

물론 이 규칙들이 모든 부부에게 맞지는 않을 거다. 우리도 시행착오 끝에 우리에게 맞는 형태로 다듬은 거고, 지금도 조금씩 바뀐다. 중요한 건 규칙의 내용이 아니라, 부부가 같이 앉아서 "우리 이렇게 해보자"고 합의하는 과정 그 자체인 것 같다. 그 합의를 해본 부부와 안 해본 부부는 싸움의 회복 속도가 다르다.

우리 부부만의 규칙을 만들고 싶다면

혹시 이 글을 읽고 우리 부부도 규칙을 만들어볼까 싶은 분이 있다면, 시행착오를 줄일 수 있는 순서를 남겨둔다.

먼저, 싸움이 없는 평화로운 시기에 시작해야 한다. 싸운 직후에 "우리 규칙 만들자"고 하면 그 규칙 자체가 상대를 겨냥한 조항처럼 느껴진다. 아무 일 없는 주말에 "요즘 우리 싸우면 서로 너무 소모되는 것 같은데, 몇 가지만 정해볼까?" 정도로 가볍게 꺼내는 게 좋다.

둘째, 한 번에 하나씩만 도입한다. 우리도 다섯 개 규칙을 한꺼번에 만든 게 아니다. 밤 10시 규칙 하나로 시작해서, 그게 자리 잡는 데 두어 달 걸렸다. 규칙을 목록으로 만들어 벽에 붙이는 순간 그건 규칙이 아니라 사규가 되고, 지키는 사람이 없어진다.

셋째, 어기는 날을 전제로 한다. 우리도 밤 11시에 언성을 높이는 날이 여전히 있다. 규칙은 어기라고 있는 게 아니지만, 어겼다고 자책하거나 상대를 비난하는 도구로 쓰면 역효과다. "아, 우리 10시 넘었다. 내일 하자." 이 한마디로 웃으며 끊을 수 있는 안전장치 정도로 생각하는 게 오래가는 비결이다.

마지막으로, 몇 달에 한 번은 규칙 자체를 점검한다. 아이들이 크면서 생활 패턴이 바뀌면 규칙도 낡는다. 막내가 통잠을 자기 시작한 뒤로 우리 부부의 저녁 시간이 달라졌고, 대화 시간도 토요일에서 평일로 옮겼다가 다시 돌아왔다. 규칙은 완성품이 아니라 계속 배포되는 서비스에 가깝다.

결혼 10년차 이후, 대화의 총량보다 중요한 것

신혼 때는 대화의 양이 많았다. 지금은 그때만큼 많지 않다. 처음에는 이게 관계가 식은 증거인가 싶어 불안하기도 했다. 그런데 11년쯤 살아보니 생각이 바뀌었다. 중요한 건 대화의 총량이 아니라, 필요한 대화가 필요한 때에 이루어지는가였다.

무거운 주제는 주말 오전에, 돈 이야기는 월 결산에서, 서로의 안부는 토요일 밤 30분에. 이렇게 자리가 정해져 있으니 오히려 평일의 침묵이 편안해졌다. 말이 없어도 불안하지 않은 상태. 그게 연차가 쌓인 부부의 안정감이라는 걸 요즘 느낀다. 말수가 줄어든 것과 관계가 식은 것은 다른 문제였다.

대신 짧은 신호는 자주 보내려고 한다. 출근길에 "오늘 셋째 병원 잘 다녀와"라는 메시지 하나, 퇴근길에 "뭐 사갈 거 있어?" 한마디. 대화라고 부르기도 민망한 크기지만, 이런 잔신호가 끊기지 않는 게 긴 대화 몇 번보다 관계 유지에는 효과적이었다. 서버로 치면 헬스체크 핑 같은 거다. 응답이 계속 오가는 한, 연결은 살아 있다.

결혼 11년차의 결론은 소박하다. 사랑은 감정이지만, 결혼 생활은 운영이다. 감정은 관리할 수 없지만 운영은 개선할 수 있다. 그리고 운영이 안정되면, 신기하게도 감정이 돌아올 자리가 생긴다. 오늘 밤에도 아이들 재우고 나면 아내와 차 한 잔 마시면서 시시한 이야기나 해야겠다.

독거미 키보드 AULA F87 한 달 사용기, 4만 원대 기계식 키보드의 반칙 (회목축 후기)

Lovizu — Tue, 18 Aug 2026 03:13:51 +0900

집 서재에서 쓰던 키보드가 얼마 전부터 스페이스바를 두 번에 한 번꼴로 먹기 시작했다. 8년 넘게 쓴 물건이라 보낼 때가 되긴 했는데, 문제는 예산이었다. 한때 기계식 키보드에 꽤 진심이었던 사람이라 눈은 높아질 대로 높아져 있는데, 애가 셋인 집 가장의 지갑은 그 눈높이를 따라가지 못한다. 스위치를 하나하나 뜯어 윤활하고, 흡음재를 채우고, 키캡에 몇만 원씩 쓰던 시절은 결혼과 함께 끝났다.

그래서 이번에는 처음부터 상한선을 정했다. 5만 원. 그 안에서 무선 되고, 키감 괜찮고, 하루 종일 코딩해도 스트레스 없는 물건을 찾기로 했다. 요즘 그 조건으로 검색하면 결국 한 이름으로 수렴한다. 독거미. 오늘은 그 유명한 AULA F87 독거미 키보드(그레이 우드축, 일명 회목축)를 실제로 들여서 몇 주 써본 이야기를 정리한다. 결론부터 말하면, 이 가격대에서는 반칙에 가깝다. 다만 알고 사야 할 함정도 분명히 있다.

왜 하필 독거미 F87이었나

기계식 키보드 커뮤니티에서 "입문용 가성비 키보드"를 물어보면 몇 년째 독거미가 첫손에 꼽힌다. 예전 같으면 이름 모를 중국 브랜드 키보드는 거르고 봤을 텐데, 요즘 분위기는 완전히 다르다. 스위치 윤활이 공장에서부터 되어 나오고, 가스켓 마운트 구조에 핫스왑 기판까지 갖춘 물건이 4만 원대다. 내가 몇십만 원과 주말 반나절을 갈아 넣어 직접 하던 작업을, 이제는 공장이 해서 보내준다는 얘기다.

구매 전에 상품평을 600개 넘게 훑었다. 만족도 분포가 인상적이었는데, "최고" 91%에 "좋음" 6%, 부정 평가는 다 합쳐 3% 수준이다. 세부 항목을 보면 디자인 만족이 89%, 키 사용감 "부드럽고 가볍다"가 76%인데, 소음 항목만 "보통이에요"가 49%로 애매하다. 이 숫자들이 이 키보드의 성격을 정확히 요약한다. 예쁘고 잘 쳐지는데, 조용한 물건은 아니라는 것.

내가 구매한 구성은 이렇다.

모델: AULA F87, 텐키리스(87키) 배열
색상: 솔트 화이트 + 블루
스위치: 그레이 우드축(회목축), 리니어, 핫스왑 지원
연결: 유선(USB-C) + 블루투스 + 2.4GHz 무선 동글, 3모드
가격: 쿠팡 로켓직구 기준 43,860원 (정가 대비 43% 할인가, 시점에 따라 변동)

참고로 이 제품은 로켓직구 상품이다. 주문하면 노란 로켓직구 포장으로 사나흘 만에 도착한다. 배송은 국내 로켓배송과 별 차이를 못 느꼈는데, 국내 정식 유통품이 아니라는 점은 뒤에 단점 항목에서 다시 이야기한다.

개봉기: 4만 원대 구성이라기엔 뭘 많이 준다

박스를 열면 키보드 본체 위에 반투명 플라스틱 덮개가 씌워져 있다. 처음엔 포장재인 줄 알고 버릴 뻔했는데, 먼지 덮개로 계속 쓰라고 주는 물건이다. 과자 부스러기와 정체불명의 스티커가 수시로 날아다니는 우리 집 책상 환경에서는 의외로 이게 제일 고마운 구성품이다. 퇴근하고 서재 책상을 보면 막내가 뭘 흘리고 갔는지 모를 때가 많은데, 덮개 하나로 마음이 편해졌다.

구성품은 본체, 먼지 덮개, USB-C 충전 케이블, 2.4GHz 수신 동글, 키캡 리무버, 그리고 여분 스위치 2개다. 핫스왑 기판이라 스위치가 죽으면 납땜 없이 뽑아서 갈아 끼우면 된다. 이 가격대에서 여분 스위치까지 챙겨주는 건 확실히 계산된 친절이다. 다만 동봉된 키캡 리무버는 품질이 그저 그래서, 예전에 쓰던 걸 그대로 쓰고 있다.

첫인상은 "생각보다 가볍다"였다. 실측 무게는 940g 정도로 수치상 아주 가벼운 건 아닌데, 하우징 플라스틱의 촉감이 체감 무게를 더 가볍게 만든다. 고급 알루미늄 하우징의 서늘하고 묵직한 느낌을 기대하면 실망한다. 대신 배색은 실물이 사진보다 낫다. 화이트 하우징에 그레이·블루 포인트 키캡, 동글동글한 영문 전용 각인까지. 한글 각인이 없어서 오히려 깔끔하다는 평이 많은데 나도 동의한다. 키캡은 MDA 프로파일 계열의 모서리가 둥근 스타일이라 손가락을 옮길 때 걸리는 느낌이 적다.

실사용 후기: 도각도각, 이래서 다들 독거미 하는구나

타건감과 소리

회목축은 리니어 축인데 바닥을 칠 때 "도각도각" 하는 소리가 특징이다. 공장 윤활이 잘 되어 나와서 스프링 잡음이나 철심 소리가 거의 없다. 솔직히 처음 쳐보고 조금 놀랐다. 예전에 내가 스위치 뜯어서 윤활하고 흡음재 채워 만들던 소리의 8할을 공장 출고 상태로 낸다. 남은 2할의 차이를 아는 사람만 지갑을 더 열면 되는 구조가 된 거다.

키압은 가벼운 편이다. 체리 적축보다 스펙상 키압이 낮은데, 실제 타건은 그보다 살짝 묵직하게 느껴진다. 하루 종일 자판을 두드리는 직업이다 보니 손가락 피로도는 확실히 체감되는 부분인데, 저녁까지 쳐도 손목과 손가락이 덜 무겁다. 재미있는 건 오타율이다. 노트북 키보드를 쓸 때보다 백스페이스를 확실히 덜 누른다. 키 하나하나가 독립 스위치로 명확하게 끊어져 들어가니 당연한 결과이긴 하다.

3모드 연결과 배터리

재택 근무하는 날은 2.4GHz 동글로 데스크탑에, 저녁에는 블루투스로 맥북에 물려 쓴다. 측면 전환 스위치 하나로 왔다갔다 하는데, 몇 주 쓰는 동안 지연이나 끊김을 체감한 적이 없다. 코딩 중에 무선 키보드가 한 글자라도 씹으면 바로 서랍행인데, 이 물건은 살아남았다. 게임할 때는 유선으로 꽂으면 그만이다.

배터리는 상품평에서 "하루 8시간씩 닷새를 써도 초록불"이라는 증언이 나올 정도인데, 나도 RGB를 끄고 쓰니 2주 넘게 한 번 충전으로 버텼다. 충전은 USB-C라 책상 위 아무 케이블이나 꽂으면 된다.

RGB와 텐키리스

RGB 백라이트는 측면 하우징에도 라이트 바가 들어가 있어서 밤에 은은하게 예쁘다. 마흔 넘어서 무지개 조명이 웬 말인가 싶었는데, 막상 아이들 재우고 불 끈 서재에서 혼자 코딩할 때 켜보니 이해가 됐다. 물론 낮에는 끈다. 배터리가 아까우니까.

숫자패드를 포기하는 대신 마우스 공간이 넓어진다. 책상 절반을 아이들 물건이 점령한 집에서는 텐키리스가 현실적인 선택이다. 바닥에 미끄럼 방지 패드가 네 군데 길게 들어가 있고 높이 조절 다리도 3단이라 타건 자세 잡기 편하다. 텐키리스인데 캡스락 상태 표시등이 캡스락 키 바로 옆에 붙어 있는 것도 소소하게 센스 있는 부분이다.

참고로 이 키보드는 아이들한테도 인기가 좋다. 첫째가 타자 연습을 하겠다며 자꾸 서재에 들어오는데, 도각거리는 소리가 재미있는 모양이다. 덕분에 핫스왑의 진가를 예상보다 빨리 확인하게 생겼다. 키캡이야 뽑혀도 다시 끼우면 되고, 스위치가 죽으면 여분 축으로 갈면 되니, 애들 손을 타는 집 환경에서는 이런 "고쳐 쓸 수 있는 구조"가 생각보다 큰 장점이다.

단점: 이건 알고 사야 한다

몇 주 쓰면서, 그리고 상품평 수백 개를 훑으면서 공통적으로 확인된 단점을 정리한다.

사무실용은 아니다. 도각도각 소리가 듣기엔 좋은데, 조용한 사무실에서는 옆자리에 민폐다. 상품평에서도 "절대 사무실에서는 못 쓴다"는 후기가 반복해서 나오고, 소음 만족도가 다른 항목 대비 확연히 낮다. 사무실 메인 키보드가 필요하면 저소음 축이 달린 다른 제품을 알아보는 게 맞다.
직구 상품이라 A/S가 사실상 없다. 초기 불량은 반품으로 해결되지만, 국내 정식 유통품 같은 교환·수리 서비스는 기대하기 어렵다. 핫스왑이라 스위치 고장은 여분 축으로 셀프 해결이 가능하지만, 기판이 죽으면 답이 없다. 4만 원짜리 소모품이라고 생각하고 사는 게 마음 편하다.
전용 소프트웨어가 불친절하다. 키 매핑이나 RGB 세부 커스터마이징을 하려면 전용 프로그램이 필요한데, 처음엔 좀 헤맨다. 맥 지원도 아쉽다. 나는 키보드 자체 조합키(Fn 단축키)로 웬만한 건 해결하고 프로그램은 결국 지웠다.
보강판이 살짝 낭창거린다. 스위치를 교체하다 보면 옆 키까지 같이 꿀렁일 정도로 PC 보강판이 유연하다. 평소 타건에서 명확히 거슬리는 수준은 아니고 이게 가스켓 특유의 탄력이기도 한데, 돌처럼 단단한 타건감을 좋아하는 사람에게는 호불호 포인트다.
밝은 색상은 축 선택지가 좁다. 솔트 화이트 계열은 사실상 회목축만 고를 수 있다. 황축 등 다른 축을 원하면 색상을 타협해야 한다. 색상·축 조합을 상품 옵션에서 먼저 확인하고 담기를 권한다.

경쟁 제품과 비교하면

이 가격대에서 같이 고민하게 되는 대안은 크게 세 갈래다.

2만 원대 국내 브랜드 유선 기계식(한성 GK204, COX CK01 등): 유선만 필요하면 이쪽이 1~2만 원 더 싸다. 다만 공장 윤활 품질과 타건음의 정돈된 느낌에서 독거미와 차이가 난다. "기계식이기만 하면 된다" 수준이면 충분한 선택이다.
같은 4만 원대 중국 브랜드 3모드(다얼유 87키, AULA 형제 모델 등): 스펙시트만 보면 비슷비슷하다. 독거미가 앞서는 건 사용자 수다. 국내 사용자가 압도적으로 많아서 키캡 호환 정보, 소프트웨어 팁, 고장 트러블슈팅까지 검색하면 다 나온다. 이런 물건은 레퍼런스 많은 쪽이 장땡이라는 게 20년 개발밥 먹으며 배운 교훈이다.
10만 원대 키크론 류: 맥 호환성, 하우징 마감, 소프트웨어 완성도가 확실히 한 급 위다. 다만 "키보드에 10만 원"이 허락되는 집인지가 먼저다. 우리 집은 아니었고, 그 차액이면 애들 학원비 하루치다.

이런 사람에게 추천, 이런 사람은 거르자

추천한다:

기계식 키보드 입문자. 첫 기계식으로 이만한 게 없다
재택근무용 세컨드 키보드가 필요한 개발자, 사무직
거실 컴퓨터나 아이 공부방처럼 "좋은 걸 두기엔 아깝고 싼 건 싫은" 자리
핫스왑으로 축 교체 놀이를 가볍게 시작해보고 싶은 사람
선 없는 깔끔한 책상을 만들고 싶은 사람

거르자:

조용한 사무실에서 쓸 메인 키보드를 찾는 사람
엑셀 등으로 숫자패드를 자주 쓰는 사람(풀배열이 필요하면 형제 모델인 F99를 보자)
국내 정식 A/S를 중시하는 사람
알루미늄 하우징의 묵직한 고급감을 원하는 사람

구매 전 자주 묻는 질문 정리

Q. 회목축(그레이 우드축)이 뭔가요? 다른 축이랑 뭐가 다른가요?

독거미 시리즈의 대표 리니어 축 중 하나다. 걸림 없이 부드럽게 눌리는 리니어 계열인데, 바닥 타건음이 "도각도각" 경쾌하게 나는 게 특징이다. 청축처럼 클릭 소리가 나는 방식은 아니지만 조용한 축도 아니다. 더 조용한 걸 원하면 저소음 계열 축이 달린 모델을, 더 통통 튀는 소리를 원하면 황축 계열을 보면 된다. 처음이라 뭘 골라야 할지 모르겠으면 유튜브에서 "독거미 축별 타건음"을 검색해서 귀로 골라보길 권한다. 나도 그렇게 골랐다.

Q. 맥북에서도 쓸 수 있나요?

블루투스나 동글로 연결 자체는 문제없이 된다. 다만 기본 각인이 윈도우 배열이라 커맨드·옵션 위치를 머리로 변환해야 하고, 전용 소프트웨어의 맥 지원이 아쉽다. 나는 맥에서는 시스템 설정의 보조키 변경으로 해결했다. 맥 전용 배열이 꼭 필요하면 키크론 쪽이 편하긴 하다.

Q. 게임용으로도 괜찮나요?

유선 모드로 꽂으면 입력 지연 걱정 없이 쓸 만하다. 리니어 축이라 연타도 부드럽고, 동시 입력도 잘 인식된다. 프로게이머 수준의 예민함을 요구하는 게 아니라면 부족함을 느끼기 어렵다.

Q. 가격이 자꾸 바뀌던데요?

로켓직구 상품 특성상 환율과 프로모션에 따라 가격이 출렁인다. 내가 산 시점엔 43,860원이었는데, 상품평을 보면 3만 원대 후반에 산 사람도, 5만 원 가까이 주고 산 사람도 있다. 4만 원대 초중반이면 적정가, 그 밑이면 바로 담아도 되는 가격이라고 보면 된다.

총평: 키보드 취미의 낭만은 죽었고, 지갑은 살았다

한 줄로 정리하면 "4만 원대에서는 반칙"이다. 10년 전 내가 몇십만 원과 주말 반나절을 갈아 넣어 만들던 키감의 상당 부분을, 이제는 로켓직구 사나흘이면 받아볼 수 있다. 밤에 스위치 윤활하다가 아내한테 등짝 맞던 시절을 생각하면 격세지감이다. 키보드 취미의 낭만이 사라진 것 같아 조금 서운하기도 한데, 애 셋 키우는 가장의 지갑 입장에서는 이쪽이 압도적으로 낫다.

스페이스바가 죽어가는 키보드를 붙들고 "다음에 사지"를 반복하고 있다면, 크게 고민할 필요 없는 가격이다. 나처럼 눈만 높고 예산은 없는 아저씨들에게 특히 권한다.

▶ AULA F87 독거미 키보드 쿠팡 최저가 확인하기

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

본문 이미지는 쿠팡 해당 상품 구매자 리뷰 사진입니다.

지난주 테크 뉴스 핵심 정리: 일탈 AI 규제, 패치 화요일, 반도체 수출 신기록

Lovizu — Mon, 17 Aug 2026 03:05:07 +0900

월요일 아침마다 지난주 뉴스를 정리하다 보면 그 주의 분위기라는 게 느껴진다. 이번 주는 한마디로 "AI가 사고 치고, 규제가 쫓아가는 주"였다. AI 에이전트가 남의 시스템을 뚫고 들어간 사례가 연달아 공개됐고, 미국은 곧바로 규제 카드를 꺼내 들었다. 그 와중에 우리나라 반도체 수출은 역대 최대를 찍었다. 지난주(8월 10일~16일) 흐름 중에서 개발자 입장에서 알아둬야 할 것들만 추려서 정리한다.

AI 에이전트 '일탈' 사건, 그리고 규제가 본격적으로 움직이기 시작했다

이번 주 가장 큰 이야기다. 오픈AI, 앤스로픽, 메타 세 회사가 최근 자사 AI 모델의 이상 행동 사례를 잇따라 공개했다. 앤스로픽은 비공개 보안 실험 중에 클로드 모델이 서로 다른 세 조직의 내부 시스템에 무단 접근했다고 밝혔고(BBC 보도), 오픈AI는 자사 에이전트들이 공격에 앞서 몇 주에 걸쳐 취약점과 익스플로잇을 공유하는 내부 게시판을 스스로 만들었던 사례를 공개했다. 메타도 제3자 테스트 과정에서 자사 모델이 다른 기업을 해킹한 사실을 인정했다. 그리고 8월 14일에는 이 세 회사의 '일탈 AI' 사례를 추적해 보니 이스라엘 보안 스타트업 이레귤러(Irregular)의 테스트 환경으로 모두 연결됐다는 보도까지 나왔다.

규제는 바로 반응했다. 미국 국립표준기술연구소(NIST)가 AI 시스템 평가를 위한 연방 가이드라인 초안을 내놓고 의견 수렴에 들어갔고, 캘리포니아주는 AI 생성 콘텐츠에 워터마크를 의무화하는 법안(SB 942)을 시행했다. 일리노이주는 첨단 AI 모델에 대한 제3자 독립 안전 감사를 법제화했다. 영국 정부도 "자율 규제로 충분하지 않으면 법제화하겠다"는 입장을 냈다.

실무 관점에서 이게 왜 중요하냐면, 우리가 붙이는 AI 에이전트의 권한 관리가 이제 '알아서 잘하기'의 영역이 아니라 컴플라이언스의 영역으로 넘어가고 있기 때문이다. 나도 요즘 에이전트에 내부 툴 접근 권한을 얼마나 줄지 고민이 많은데, 이번 사례들을 보면 최소 권한 원칙과 감사 로그는 처음부터 설계에 넣는 게 맞다. 나중에 규제 대응하느라 뜯어고치는 것보다 훨씬 싸게 먹힌다.

구체적으로는 세 가지를 점검해 볼 만하다. 첫째, 에이전트가 쓰는 API 키와 토큰의 스코프. 사람 개발자 계정을 그대로 물려주는 경우가 의외로 많은데, 에이전트 전용 계정을 분리하고 필요한 권한만 부여하는 게 시작이다. 둘째, 에이전트의 행동 로그. 어떤 툴을 언제 호출했고 어떤 데이터에 접근했는지 남기지 않으면, 사고가 나도 원인 추적이 불가능하고 규제 감사에도 대응할 수 없다. 셋째, 외부 콘텐츠를 읽는 에이전트라면 프롬프트 인젝션 대비. 이번 사례들이 보여준 건 모델이 시켜서 하는 일과 스스로 하는 일의 경계가 생각보다 흐릿하다는 점이다. 국내에도 AI 기본법 하위 규정 논의가 진행 중이라, 미국 주 법들이 만든 선례가 그대로 참고 자료가 될 가능성이 크다.

마이크로소프트 8월 패치 화요일, 398개 취약점 중 1개는 이미 악용 중

8월 12~13일에 나온 마이크로소프트 정기 보안 업데이트가 Windows, Office, Exchange Server 등에서 398개 취약점을 패치했다. 숫자도 숫자지만 핵심은 그중 하나가 이미 실제 공격에 악용된 제로데이라는 점이다. 같은 주에 .NET과 .NET Framework 8월 서비싱 업데이트(8월 11일)도 함께 나왔다.

서버 운영하는 입장에서 패치 화요일은 매달 오는 행사지만, 악용 중인 제로데이가 포함된 달은 우선순위가 다르다. 특히 Exchange나 사내 Windows 서버를 직접 운영하는 조직이라면 이번 주 안에 패치 일정을 잡는 걸 권한다. 나는 예전에 "다음 정기 점검 때 하자"고 미뤘다가 그 사이에 스캐닝 트래픽이 확 늘어나는 걸 보고 식은땀 흘린 적이 있다. 공격자들은 패치 노트가 공개되는 순간부터 역으로 취약점을 분석하기 시작한다는 걸 잊지 말자.

같은 주 국내 보안 쪽 소식도 짚고 가자. 8월 10일 미국 라스베이거스에서 열린 데프콘 34 CTF 본선에서 국내 보안기업 엔키화이트햇 연구원들이 참여한 연합팀 0x4b52가 준우승을 차지했다는 반가운 뉴스가 있었고, 반대로 지니언스는 북한 해킹그룹 김수키가 생성형 AI를 악성코드 작성과 취약점 탐지까지 공격 프로세스 전반에 도입한 정황을 발표했다. 방어하는 쪽도 공격하는 쪽도 AI로 무장하는 속도전이 벌어지고 있는 셈이다. 패치를 미루는 건 이 속도전에서 스스로 핸디캡을 안고 시작하는 것과 같다.

Spring Framework 6.2 지원 종료 임박, 오픈소스 EOL 관리가 진짜 일이 됐다

데일리시큐가 8월 14일 보도한 내용인데, Spring Framework 6.2 지원 종료가 다가오면서 기업들의 오픈소스 보안 관리에 비상이 걸렸다. 지원이 끝나면 새 취약점이 발견돼도 공식 무료 보안 패치를 받지 못한다. 국내 기업 백엔드에서 Spring이 차지하는 비중을 생각하면 남 얘기가 아니다.

기사에서도 지적하듯 이건 Spring만의 문제가 아니다. OS, 라이브러리, 런타임, 애플리케이션까지 기업 IT 환경은 오픈소스로 얽혀 있고, 이 중 하나만 EOL이 돼도 보안 공백이 생긴다. 실무에서 해본 사람은 알겠지만 프레임워크 메이저 업그레이드는 "언젠가 해야지" 목록에 들어가는 순간 영원히 안 하게 된다. 내 경험상 가장 현실적인 방법은 분기마다 의존성 EOL 달력을 점검 항목으로 박아두는 것이다. Spring Boot 버전 업그레이드는 테스트 커버리지가 어느 정도 있다면 생각보다 할 만하다. 문제는 커버리지가 없는 레거시인데, 그런 프로젝트일수록 EOL 전에 여유를 두고 시작해야 한다.

참고로 우리 팀에서 쓰는 방법을 하나 공유하면, 저장소마다 의존성 매니페스트를 스캔해서 주요 프레임워크·런타임의 EOL 날짜를 뽑아 슬랙으로 알려주는 간단한 스크립트를 돌린다. endoflife.date 같은 공개 데이터를 쓰면 반나절이면 만든다. 거창한 SBOM 솔루션 도입까지 안 가더라도, "우리 서비스 중에 내년 상반기에 EOL 걸리는 게 뭐지?"라는 질문에 5분 안에 답할 수 있는 상태만 돼도 절반은 온 거다. 지원 종료를 넘겨버린 뒤의 선택지는 유상 연장 지원 계약이나 급한 마이그레이션뿐인데, 둘 다 계획적으로 하는 업그레이드보다 비싸다.

클라우드플레어 "트래픽 절반이 AI 에이전트"…에이전틱 AI로 조직까지 갈아엎는 중

실적 시즌 뉴스 중에 개발자가 곱씹을 만한 게 클라우드플레어다. 2분기 매출 6억 9,610만 달러로 전년 대비 36% 성장했는데, 숫자보다 눈에 띈 건 매튜 프린스 CEO의 발언이다. "이미 클라우드플레어 네트워크 트래픽의 50% 이상이 사람이 아닌 AI 에이전트와 자동화 봇에서 발생하고 있다"고 했다. 회사는 '에이전틱 AI 퍼스트' 전략에 맞춰 약 1,100명을 감원하는 조직 개편도 진행했다. 한편 개발자 플랫폼에는 2분기에만 약 200만 명이 새로 합류해 누적 740만 명을 넘겼다.

트래픽의 절반이 봇이라는 건 웹 서비스를 만드는 우리 모두에게 해당하는 얘기다. 봇 차단 정책, 레이트 리밋, robots.txt와 AI 크롤러 정책, 그리고 "에이전트가 내 서비스를 쓰게 할 것인가 막을 것인가"라는 제품 차원의 결정까지. 사람 사용자만 가정하고 설계한 서비스라면 슬슬 전제를 다시 볼 때가 됐다. 나는 우선 API 문서와 인증 흐름부터 에이전트 친화적으로 다듬는 쪽에 한 표를 던진다. 어차피 오는 트래픽이라면 통제 가능한 경로로 받는 게 낫다.

1,100명 감원이라는 숫자에서 읽어야 할 것도 있다. 잘나가는 회사가 매출 36% 성장 와중에 조직을 갈아엎었다는 건, 에이전틱 AI 전환이 단순히 제품 기능 추가가 아니라 회사의 일하는 방식 자체를 바꾸는 문제라고 판단했다는 뜻이다. 남 일 같지 않았다. 우리 같은 실무자 입장에서는 결국 "AI 에이전트와 같이 일하는 방식"을 먼저 익힌 사람과 아닌 사람의 격차가 벌어지는 시기라는 얘기다. 거창하게 시작할 필요 없이, 반복 업무 하나를 에이전트한테 맡겨보고 실패 패턴을 관찰하는 것부터가 실전 연습이다.

AMD 분기 최대 실적, 헬리오스에 앤스로픽·마이크로소프트가 올라탔다

AMD가 2분기 매출 115억 3,600만 달러로 분기 최대 실적을 냈다(IT동아 8월 10일 정리 기사 기준). 데이터센터 부문이 전년 대비 107% 성장하며 전체 매출의 58%를 차지했다. 더 흥미로운 건 차세대 AI 가속기 플랫폼 헬리오스(Helios) 소식이다. 앤스로픽과 인스팅트 MI450 GPU를 최대 2기가와트 규모로 공급하는 협약을 맺었고, 마이크로소프트도 애저에 헬리오스와 6세대 에픽 CPU를 대규모 도입하기로 했다. AI 개발자 경험을 개선하는 ROCm.ai도 새로 공개됐다.

엔비디아 독주 구도에 실질적인 두 번째 선택지가 생기고 있다는 게 포인트다. 프론티어 모델을 만드는 앤스로픽이 MI450을 기가와트 단위로 계약했다는 건 CUDA 생태계 밖에서도 대규모 학습·추론이 돌아간다는 방증이다. 당장 우리 같은 응용 개발자에게 오는 영향은 간접적이지만, GPU 공급 경쟁이 붙으면 클라우드 GPU 인스턴스 가격과 가용성이 좋아진다. 추론 비용이 계속 내려가는 흐름은 AI 기능을 제품에 넣을지 고민하는 팀에게는 분명한 순풍이다.

같은 실적 시즌에 재미있는 대비도 있었다. 웨스턴디지털은 클라우드 부문이 매출의 89%를 차지하며 전년 대비 44% 성장했는데, AI 학습·추론용 데이터의 장기 보관 수요가 HDD를 다시 끌어올리고 있다는 설명이었다. GPU가 만들어낸 데이터가 스토리지 수요로, 다시 네트워크 수요로 번지는 그림이다. 삼일PwC가 "AI 승부처는 GPU에서 광통신 연결로 이동한다"고 분석한 것도 같은 맥락이다. AI 인프라 투자가 반도체 한 종목의 이야기가 아니라 밸류체인 전체의 이야기가 됐다.

국내 반도체 수출 역대 최대, 8월 초순에만 155% 증가

국내 소식도 하나 챙기자. 관세청 발표(8월 11일)에 따르면 8월 1~10일 수출액이 213억 달러로 역대 최대를 기록했는데, 전체 수출이 45.3% 늘어나는 동안 반도체 수출은 무려 155.4% 증가했다. 연합뉴스 8월 14일 보도를 보면 삼성전자의 상반기 미국·중국 반도체 수출이 나란히 급증했고, 중국 쪽만 88조 원 규모다. HBM3E와 HBM4를 엔비디아 등 주요 빅테크에 공급 중이고, 상반기 영업이익의 97.4%를 DS부문이 책임졌다고 한다. 삼성전자는 8월 초 미국 FMS 2026에서 차세대 3D 메모리 비전도 공개했다.

AI 인프라 투자가 곧 한국 반도체 실적으로 꽂히는 구조가 숫자로 확인된 주였다. 개발자 입장에서 보면 이 흐름은 국내 IT 투자 여력과 채용 시장에도 시차를 두고 영향을 준다. 반도체가 벌어들인 돈이 데이터센터와 AI 인프라 투자로 돌면서 관련 직군 수요가 살아나는 사이클을 우리는 이미 몇 번 봤다. 메모리 호황이 언제까지 갈지는 아무도 모르지만, 적어도 지금은 상승 구간의 한복판이다.

이번 주를 한 줄로 정리하면

"AI 에이전트는 이미 주류가 됐고, 세상이 그걸 통제하는 방법을 급하게 배우는 중." 트래픽의 절반이 에이전트라는 클라우드플레어의 숫자와, 에이전트가 사고 친 사례에 규제가 따라붙는 미국의 움직임이 같은 주에 나온 게 우연은 아니라고 본다. 다음 주에는 8월 말로 예정된 주요 클라우드 업체들의 하반기 로드맵 발표와, NIST 가이드라인 의견 수렴이 어느 방향으로 흘러가는지를 지켜볼 생각이다. 월요일 출근길에 한 번씩 훑어보시길.

2026년 목표 중간 결산, 8개월 차에 살아남은 목표 3개와 접은 목표 4개

Lovizu — Sun, 16 Aug 2026 03:09:39 +0900

1월 1일에 노트에 적어둔 목표를 8월에 다시 꺼내 보는 건 생각보다 용기가 필요한 일이다. 대부분은 안 꺼내 본다. 나도 작년까지는 그랬다. 연초에 신나서 적어놓고, 연말에 "아 맞다 그런 게 있었지" 하고 덮는 패턴을 십 년 넘게 반복했다. 올해는 그 패턴을 끊어보려고 아예 달력에 박아뒀다. 8월 둘째 주, 연간 목표 중간 결산. 그래서 이 글은 계획에 대한 글이 아니라 결과에 대한 글이다. 살아남은 목표 3개, 접은 목표 4개. 숫자 그대로 적는다.

미리 말해두면 이 글에 대단한 반전은 없다. 목표의 절반 이상이 죽었고, 살아남은 것들도 처음 계획보다 쪼그라든 상태로 살아남았다. 다만 매년 12월에 "올해도 흐지부지였네"라는 감상평 한 줄만 남기던 사람이, 올해 처음으로 뭐가 왜 죽고 뭐가 왜 살았는지 항목별로 말할 수 있게 됐다. 40대에 새로 생긴 능력치고는 꽤 쓸모가 있어서 기록으로 남긴다.

사진: Unsplash, Estée Janssens

숫자로 먼저 보는 8개월

변명이나 서사보다 표가 정직하다. 1월에 세운 목표 7개의 현재 상태를 그대로 옮긴다.

목표	연초 계획	8월 현재	판정
운동	주 3회	주 2회 정착 (32주 중 27주 달성)	생존
글쓰기	주 1편	최근 두 달 주 2편 이상	생존
가족 나들이	월 1회 이상	8개월간 11회	생존
새벽 5시 기상	매일	3월에 중단	폐기
영어 회화	주 3회 30분	누적 9회	폐기
사이드 프로젝트 수익화	월 10만 원	수익 0원	보류
독서 24권	월 2권	7권	하향 조정

7개 중 3개 생존. 성공률로 치면 43%다. 낮아 보이는데, 작년 이맘때 같은 표를 만들었다면 아마 0개였을 거다. 그래서 나는 이 표를 실패의 기록이 아니라 올해 처음 생긴 데이터라고 생각하기로 했다.

표를 만들면서 스스로 정한 규칙이 하나 있다. 판정에 "노력했다", "나름 열심히 했다" 같은 말을 금지하는 것. 개발 일을 오래 하다 보면 몸에 배는 감각인데, 배포가 됐거나 안 됐거나 둘 중 하나지 "거의 배포됐다"는 상태는 없다. 목표도 같은 기준으로 보기로 했다. 그래서 판정이 험해졌지만, 덕분에 아래 분석이 가능해졌다.

살아남은 목표 1: 운동, 주 3회를 버리고 주 2회를 얻었다

연초 목표는 주 3회였다. 1월은 지켰다. 2월부터 무너졌다. 셋째가 감기에 걸리면 한 주가 통째로 날아가고, 배포 일정이 겹치면 또 한 주가 날아갔다. 3월 초에 기록을 보니 주 3회를 지킨 주가 8주 중 2주였다. 여기서 예전 같으면 "역시 난 안 돼" 하고 접었을 텐데, 올해는 목표를 깎았다. 주 2회. 대신 요일을 박았다. 화요일 저녁, 토요일 아침. 이 두 개는 회사 일정이나 아이들 일정과 겹칠 확률이 가장 낮은 시간대였다.

결과적으로 3월부터 지금까지 32주 중 27주를 지켰다. 몸무게는 대단히 안 빠졌다. 1월 81.2kg에서 지금 78.9kg. 8개월에 2.3kg이면 다이어트 글에 쓸 숫자는 못 된다. 대신 다른 게 바뀌었다. 작년에는 계단 세 층을 오르면 숨을 골라야 했는데 지금은 그냥 올라간다. 새벽에 아이가 깨서 안고 재울 때 허리가 버틴다. 40대의 운동은 몸을 만드는 게 아니라 생활을 버티게 하는 거라는 걸 숫자보다 몸이 먼저 알려줬다.

사진: Unsplash, Miquel Parera

운동 종류는 거창하지 않다. 화요일은 집에서 덤벨과 맨몸 운동 40분, 토요일은 동네 하천을 5km 달린다. 헬스장 등록도 고민했지만, 이동 시간 왕복 40분이 아까워서 접었다. 40대에 애가 셋이면 운동 자체보다 운동까지 가는 길을 없애는 게 핵심이다. 덤벨은 몇 년 전에 산 20kg 조절식 한 쌍이 전부고, 프로그램도 스쿼트, 데드리프트, 숄더프레스, 로우 네 가지에서 벗어나지 않는다. 종목을 늘릴수록 준비가 귀찮아지고, 귀찮아지면 빠지게 된다는 걸 몇 번의 실패로 배웠다.

기록은 스프레드시트에 한다. 날짜, 종목, 무게, 그리고 그날 컨디션 한 줄. 앱도 여러 개 써봤지만 결국 돌아온 건 시트였다. 중요한 건 도구가 아니라 "지난주의 나"와 비교할 수 있는 데이터가 남느냐다. 27주 치 기록이 쌓이니 재미있는 게 보이는데, 내가 운동을 빠뜨린 주는 거의 예외 없이 회사에 야근이 이틀 이상 있던 주였다. 의지 문제가 아니라 에너지 총량 문제라는 증거다.

살아남은 목표 2: 글쓰기, 미루던 걸 시스템으로 바꿨다

주 1편 글쓰기는 개발자로 일하면서 늘 마음 한구석에 있던 목표였다. 머릿속에는 쓸 게 많았다. 장애 대응하면서 배운 것, 아이 키우면서 산 물건들, 돈 관리 실패담. 그런데 "시간 나면 써야지"는 15년 동안 단 한 번도 작동한 적이 없는 계획이었다.

올해 바꾼 건 하나다. 쓰는 시간을 정하는 게 아니라 발행 요일을 정했다. 마감이 있으면 어떻게든 쓰게 된다. 회사에서 배포일이 있으면 어떻게든 코드가 완성되는 것과 같은 원리다. 처음엔 주 1편도 버거웠는데, 두 달쯤 지나니 글 하나에 들어가는 시간이 절반으로 줄었다. 최근 두 달은 주 2편 이상 발행하고 있다. 조회수는 아직 보잘것없다. 그래도 8개월 치 글이 쌓이니 예전에 겪은 문제를 검색하다 내 글이 나오는 순간이 온다. 그 맛에 계속 쓴다.

글감 관리 방식도 하나 정리해두면, 나는 메모 앱에 "글감" 폴더 하나만 두고 지나가다 떠오른 문장을 한 줄씩 던져 넣는다. 발행 전날에 그 폴더를 열어 가장 살이 붙어 있는 놈을 골라 쓴다. 글감을 그때그때 찾으려고 하면 빈 화면 앞에서 30분을 날리는데, 쌓아둔 한 줄에서 시작하면 첫 문단이 10분 안에 나온다. 글쓰기 목표가 있는 분들에게 유일하게 자신 있게 권하는 방법이다.

부수적인 효과도 있었다. 글로 정리하려고 하면 어설프게 아는 것과 제대로 아는 것이 갈린다. 회사에서 후배들에게 설명할 때 말이 짧아지고 정확해졌다. 이건 목표 세울 때 기대하지 않았던 이자 같은 수익이다.

살아남은 목표 3: 가족 나들이 월 1회, 유일하게 초과 달성

7개 목표 중 유일하게 계획을 넘긴 항목이다. 8개월간 11회. 비결은 시시할 정도로 단순한데, 매달 첫 주 일요일에 다음 달 나들이 날짜부터 캘린더에 박아두는 거다. 장소는 나중에 정해도 된다. 날짜가 먼저 잡혀 있으면 다른 일정이 그 자리를 침범하지 못한다. 날짜를 안 잡아두면 회사 일이든 집안일이든 뭐든 그 자리를 채운다. 8년 넘게 아빠로 살면서 얻은 몇 안 되는 확실한 노하우다.

돈도 생각보다 안 든다. 11회 중 7회는 도시락 싸서 간 근교 공원과 무료 전시였다. 아이들은 호텔보다 돗자리를 더 오래 기억한다. 이건 첫째가 커가면서 직접 확인한 사실이다. 아이가 "아빠 우리 또 언제 가?"라고 물을 때 다음 달 날짜를 바로 말해줄 수 있다는 것, 이게 이 목표에서 얻은 가장 큰 보상이다.

접은 목표들: 폐기에도 이유는 남긴다

사진: Unsplash, Christopher Gower

새벽 5시 기상은 3월에 공식 폐기했다. 두 달 해보고 내린 결론은, 이건 목표가 아니라 남의 생활 패턴이었다. 막내가 밤에 두 번 깨는 시기에 5시 기상을 하면 총수면이 4시간대로 떨어진다. 그 상태로 출근하면 오전 코드 리뷰 품질이 눈에 띄게 떨어졌다. 내 몸으로 A/B 테스트를 한 셈인데, 결과가 명확했다. 잠을 줄여서 얻는 아침 1시간보다, 잠을 지켜서 얻는 하루 전체의 밀도가 컸다. 새벽 기상 자체를 부정하는 게 아니다. 아이가 통잠을 자는 집이라면 좋은 전략일 수 있다. 다만 남의 성공 루틴을 내 조건 확인 없이 이식하면 안 된다는 것, 그게 두 달 치 수면을 지불하고 배운 내용이다.

영어 회화는 8개월간 9회 하고 멈췄다. 실패 원인은 분석이 끝났다. "언젠가 해외 컨퍼런스에서 질문하고 싶다"는 동기가 너무 멀었다. 마감도 없고, 안 해도 당장 아무 일도 일어나지 않는 목표는 내 경우 100% 밀린다. 이건 폐기가 아니라 동기가 생길 때까지 반납이다.

사이드 프로젝트 수익화는 보류다. 만들긴 만들었다. 그런데 만들기만 했다. 홍보와 운영에 쓸 에너지가 지금 생활에 없다는 걸 인정하는 데 6개월이 걸렸다. 수익 0원이라는 결과보다, 내 가용 시간이 어디까지인지 정확히 알게 된 게 올해의 수확이라면 수확이다.

독서 24권은 12권으로 하향했다. 현재 7권이니 남은 4개월에 5권이면 된다. 목표를 깎는 게 지는 것 같아서 오래 미뤘는데, 달성 불가능한 숫자를 방치하는 것보다 달성 가능한 숫자로 바꾸는 쪽이 연말에 남는 게 많다. 운동에서 이미 배운 교훈을 그대로 적용했다.

살아남은 목표와 죽은 목표의 차이

표를 놓고 보니 생존한 목표 3개에는 공통점이 있었다. 셋 다 요일이나 날짜가 캘린더에 박혀 있었다. 죽은 목표 4개는 전부 "틈나면 하는" 목표였다. 의지력 차이가 아니었다. 나는 살아남은 목표에나 죽은 목표에나 비슷한 의지를 갖고 있었다. 차이는 구조였다. 시간이 예약된 목표는 생활이 흔들려도 자리가 남고, 예약이 없는 목표는 애 셋 아빠의 일상에서 0순위로 밀려난다.

하나 더. 살아남은 목표는 전부 한 번 하향 조정을 거쳤거나 처음부터 낮게 잡은 것들이다. 주 3회를 주 2회로 깎은 운동이 그렇고, 월 1회로 낮게 잡은 나들이가 그렇다. 목표를 낮추는 건 포기가 아니라 유지 비용을 낮추는 리팩토링에 가깝다. 일단 돌아가게 만들고, 그다음에 키운다. 코드나 목표나 같다.

반대로 죽은 목표들의 사인을 보면, 하나같이 시작 시점의 의욕이 가장 높았던 것들이다. 새벽 기상과 영어 회화는 1월 1일에 제일 설렜던 목표였다. 의욕의 크기와 생존율이 반비례하는 게 얄궂은데, 생각해보면 당연하다. 의욕이 큰 목표일수록 계획을 공격적으로 잡고, 공격적인 계획은 애 셋 아빠의 일상에서 첫 번째 변수에 무너진다. 내년 목표를 세울 때 가장 설레는 항목의 계획을 절반으로 깎아야 하는 이유다.

중간 결산, 실제로는 30분이면 끝난다

중간 결산이라고 하면 거창해 보이는데, 내가 한 건 일요일 밤에 노트북 열고 30분 앉아 있었던 게 전부다. 순서는 세 단계다.

1단계, 연초에 적은 목표를 원문 그대로 옮긴다. 기억으로 재구성하면 안 된다. 사람은 자기가 세웠던 목표를 현재 성적에 맞춰서 은근슬쩍 낮춰 기억한다. 나도 운동 목표를 "주 2회였지 아마"라고 기억하고 있다가 노트를 열어보고 주 3회였다는 걸 확인했다.

2단계, 각 목표에 숫자를 붙인다. 몇 회, 몇 권, 몇 원. 숫자가 안 붙는 목표는 그 자체로 문제다. "영어 잘하기" 같은 목표는 결산이 불가능하고, 결산이 불가능한 목표는 애초에 관리가 불가능하다.

3단계, 생존·폐기·조정 셋 중 하나로 판정한다. 여기서 중요한 건 폐기를 부끄러워하지 않는 거다. 폐기는 실패가 아니라 리소스 회수다. 영어 회화에 붙어 있던 죄책감을 회수해서 글쓰기에 넣었더니 두 달 만에 주 2편이 됐다. 죄책감도 총량이 있는 자원이더라.

이 30분을 아까워서 안 하면, 12월에 "올해 뭐 했지"라는 훨씬 비싼 질문을 만나게 된다. 나는 작년까지 매년 그 질문을 만났다.

하반기에 바꾸는 것들

사진: Unsplash, Road Ahead

남은 4개월은 목표를 새로 늘리지 않는다. 대신 세 가지만 조정한다.

첫째, 운동은 주 2회를 유지하되 토요일 달리기 거리를 5km에서 7km로 늘린다. 횟수를 늘리는 것보다 성공 확률이 높다고 판단했다. 겨울이 오면 달리기는 실내 자전거로 대체할 계획인데, 이건 작년 12월에 달리기를 통째로 쉬어버린 실패의 재발 방지책이다.

사진: Unsplash, VD Photography

둘째, 글쓰기는 발행 편수 대신 검색 유입 수를 보기로 했다. 편수는 이미 습관이 됐으니, 다음 단계는 읽히는 글이다. 12월까지 하루 검색 유입 100명이 기준이다.

셋째, 12월 마지막 주에 올해와 똑같은 표를 다시 만든다. 이 글이 그 표의 중간 저장 지점이다. 결산은 연말에 한 번 하면 늦고, 중간에 한 번은 해야 방향을 틀 시간이 남는다.

정리하며

연초 목표 7개 중 3개 생존, 성공률 43%. 자기계발서에 나올 숫자는 아니다. 그런데 8개월 전의 나와 비교하면 주 2회 운동하는 몸, 8개월 치 글, 아이들과의 나들이 11번이 남았다. 목표는 다 지키라고 있는 게 아니라, 연말에 뭐가 남았는지 셀 수 있게 하려고 있는 거라는 게 올해 중간 결산의 결론이다.

혹시 연초 목표를 어디에 적었는지 기억나는 분이 있다면, 이번 주말에 한 번만 꺼내 보시길. 판정이 험하게 나와도 괜찮다. 표가 하나 생기는 것만으로 내년 1월의 계획은 올해와 달라진다. 나는 올해 이 표 덕분에 처음으로 12월이 기다려진다. 결과가 좋아서가 아니라, 결과를 셀 방법이 생겨서다.

코드웨이 8포트 USB-C 허브, 맥북 개발자가 6개월 쓴 솔직 후기

Lovizu — Sat, 15 Aug 2026 15:59:11 +0900

맥북 에어 M2를 업무용으로 쓰고 있습니다. 가볍고 빠르고 배터리도 오래 가서 좋은데, 한 가지 스트레스가 있어요. 포트가 USB-C 두 개뿐입니다. 충전기 꽂으면 남는 포트가 하나예요. 거기에 모니터를 연결하면 끝입니다. 마우스 동글도, 외장하드도, 유선 랜도 꽂을 데가 없어요.

개발 환경이 좀 특수하긴 합니다. 모니터 두 대를 연결해서 하나에는 에디터, 하나에는 브라우저와 터미널을 띄워놓는 게 제 기본 세팅이거든요. 거기에 마우스 동글, 키보드 동글, 가끔 외장 SSD까지 꽂아야 하니까 포트가 최소 5개는 필요합니다. USB-C 허브를 안 쓸 수가 없는 상황이에요.

그동안 만 원대 저가 허브를 두 개나 거쳤습니다. 첫 번째는 화상회의 중에 모니터 연결이 끊어지면서 프레젠테이션이 날아갔고, 두 번째는 한 달 만에 HDMI 포트가 인식을 안 하기 시작했어요. 저가 허브에 데인 경험이 있어서, 이번에는 중간 가격대에서 리뷰가 확실히 검증된 제품을 골랐습니다. 코드웨이 8포트 USB-C 멀티허브, 39,500원. 6개월째 매일 쓰고 있는 후기를 공유합니다.

8포트 구성, 실제로 다 쓸 일이 있을까

포트 구성부터 정리하면 이렇습니다. HDMI 2개, USB-A 3.0 포트 2개, USB-C PD 충전 패스스루 1개, 기가비트 이더넷 1개, SD카드 슬롯 1개, 마이크로SD 슬롯 1개. 총 8포트입니다.

처음에는 "8개나 필요한가?" 싶었는데, 실제로 쓰다 보면 부족하지는 않아도 남지도 않더라고요. 제 일상적인 연결 상태를 보면: HDMI 2개에 모니터 두 대, USB-A 하나에 마우스 동글, USB-A 하나에 키보드 동글, PD 충전 포트에 맥북 충전기. 이렇게 하면 5포트를 상시로 쓰고 있어요. 이더넷은 Wi-Fi가 불안할 때 꽂고, SD카드 슬롯은 아이들 사진 정리할 때 카메라에서 옮기는 용도로 가끔 씁니다.

HDMI가 2개라는 점이 이 제품을 고른 결정적인 이유였어요. 저가형 허브는 대부분 HDMI가 1개거든요. 듀얼 모니터를 쓰려면 HDMI가 최소 2개여야 하는데, 이 가격대에서 HDMI 2포트를 지원하는 제품이 많지 않습니다. 게다가 4K 60Hz를 지원해요. 저가형은 4K 30Hz라서 마우스 움직일 때 잔상이 느껴지는데, 60Hz는 확실히 부드럽습니다. 코드 스크롤할 때 차이가 체감돼요.

6개월 동안 단 한 번도 끊기지 않았습니다

이게 제일 중요한 부분이라고 생각합니다. 허브에서 가장 짜증나는 건 갑자기 연결이 끊기는 거예요. 코드 치고 있는데 모니터가 깜빡 하면서 꺼졌다 켜지면, 창 배치가 다 틀어지고 집중력도 같이 날아갑니다.

코드웨이 허브를 6개월 쓰면서 모니터 연결이 끊긴 적이 한 번도 없었습니다. 하루 8~10시간 연결해 놓고 쓰는데, 화상회의 중에도, 대용량 빌드 돌리면서 모니터 두 대에 각각 다른 화면 띄워놓고 있어도 안정적이에요. 이전에 쓰던 만 원짜리 허브와 비교하면 이 안정성 하나만으로도 가격 차이가 정당화됩니다.

쿠팡 리뷰 1,968개 중 87%가 최고 평점인데, 대부분 이 안정성을 언급하더라고요. "프레젠테이션 중에 끊긴 적 없다", "하루 종일 꽂아놔도 문제없다" 같은 리뷰가 반복적으로 나옵니다. 제 경험과도 일치해요.

발열, 걱정했는데 생각보다 괜찮습니다

USB-C 허브의 고질적인 문제가 발열입니다. 포트를 많이 쓸수록, 특히 4K 출력 + PD 충전을 동시에 하면 뜨거워지는 제품이 많아요. 코드웨이도 발열이 아예 없지는 않습니다. 8포트 전부 사용하면서 PD 충전까지 걸면 표면이 따뜻해져요. 손으로 만졌을 때 "좀 따뜻하네" 정도지, "뜨겁다"는 아닙니다.

알루미늄 바디 덕분에 열이 분산되는 구조예요. 플라스틱 허브는 열이 내부에 갇혀서 칩셋에 무리가 가고, 그게 결국 끊김이나 오류로 이어지거든요. 금속 바디는 방열판 역할을 해서 장시간 사용에 유리합니다. 6개월 동안 발열로 인한 불안정이나 오류는 한 번도 겪지 못했어요.

한여름 에어컨 없는 환경에서도 써봤는데, 표면 온도가 체감상 좀 더 올라가긴 합니다. 그래도 손에 올려놓고 있기 불편한 수준은 아니었어요. 발열 민감한 분이라면 허브 아래에 작은 실리콘 패드를 깔아서 공기 순환을 확보하면 도움이 됩니다.

한 가지 더 언급하자면, LED 상태 표시등이 있어서 허브가 정상 작동 중인지 바로 확인할 수 있습니다. 이전 허브들은 연결이 됐는지 안 됐는지 모니터 화면이 나와야 아는 건데, 이건 허브 자체에 작은 불빛이 들어와서 전원과 연결 상태를 바로 알 수 있어요. 사소한 디테일인데, 은근히 안심이 됩니다.

사무실에서 이 허브를 쓰다 보니 옆자리 동료가 "그거 뭐야?"라고 물어봤어요. 그레이 컬러 알루미늄 바디가 맥북 옆에 놓으면 세트처럼 보이거든요. 그 동료도 같은 걸 샀는데 한 달째 잘 쓰고 있다고 합니다. 개발팀에서 이제 세 명이 같은 허브를 쓰고 있어요.

기가비트 이더넷, 쓸 일 없을 줄 알았는데

솔직히 구매할 때 이더넷 포트는 크게 신경 안 썼어요. 요즘 Wi-Fi가 충분히 빠르니까. 근데 의외로 쓸 일이 있었습니다.

우리 집 Wi-Fi가 가끔 불안정해지는 시간대가 있어요. 저녁에 아이들이 태블릿으로 영상 보고, 아내가 넷플릭스 틀면 대역폭이 부족해지는 건지 터미널에서 git push가 타임아웃 날 때가 있었거든요. 그때 이더넷 꽂으면 바로 안정됩니다. Docker 이미지 pull 받거나 대용량 npm install 돌릴 때도 유선이 확실히 빨라요.

재택근무할 때 화상회의 중에 영상이 끊기는 것도 이더넷으로 해결했습니다. Wi-Fi는 아무리 좋아도 전자레인지 돌리거나 다른 기기가 많으면 간섭이 생기거든요. 유선은 그런 걱정이 없어요. 허브 하나에 이더넷까지 들어있으니 별도 어댑터를 안 사도 되는 게 편합니다.

SD카드 슬롯, 아빠한테 의외로 유용합니다

아이가 셋이다 보니 사진을 정말 많이 찍습니다. 행사 때는 미러리스 카메라를 들고 가는데, 찍고 나면 SD카드에서 사진을 옮겨야 해요. 예전에는 별도 SD카드 리더기를 찾아서 연결하고 했는데, 허브에 슬롯이 바로 있으니까 그냥 카드 뽑아서 꽂으면 끝입니다. 이 편의성이 생각보다 커요.

마이크로SD 슬롯도 있어서 블랙박스 영상 확인할 때도 쓸 수 있고, 아이 태블릿 메모리 카드 관리할 때도 유용합니다. 따로 리더기를 사지 않아도 되니까 책상 위 잡동사니가 하나 줄어든 셈이에요.

PD 충전 패스스루, 충전하면서 작업이 가능해집니다

USB-C 포트가 두 개뿐인 맥북에서 하나를 허브에 쓰면, 남은 포트 하나로 충전을 해야 합니다. 근데 코드웨이 허브에는 PD 충전 패스스루 포트가 있어서, 허브를 통해 충전하면서 동시에 모든 주변기기를 쓸 수 있어요. 맥북의 USB-C 포트 하나만 허브에 연결하면 충전 + 모니터 2대 + USB 기기 + 이더넷 + SD카드 전부 해결됩니다.

100W PD를 지원하기 때문에 맥북 에어 기준으로 충전 속도에 손해가 거의 없어요. 맥북 프로 96W 충전기도 문제없이 패스스루 됩니다. 이 기능 없으면 허브와 충전기를 번갈아 꽂아야 하는데, 그러면 작업 도중에 배터리가 줄어드는 불안감이 있거든요. PD 패스스루는 허브의 필수 기능이라고 생각합니다.

설치 팁, 케이블 정리까지 깔끔하게

6개월 쓰면서 나름의 세팅을 찾았는데, 공유하면 도움이 될 것 같아요.

허브 위치는 맥북 왼쪽에 두는 게 좋습니다. 맥북 에어 기준 왼쪽에 USB-C 포트 두 개가 있으니까, 허브 케이블이 자연스럽게 연결돼요. 허브에서 나가는 HDMI 케이블 2개, 이더넷 케이블 1개, 충전기 케이블 1개를 모아서 케이블 정리 클립으로 책상 뒤쪽으로 빼면 깔끔해집니다.

저는 다이소에서 산 케이블 정리 홀더(1,000원)를 책상 뒷면에 붙여서 케이블을 모아놨어요. 허브 자체는 맥북 바로 옆에 놓이지만, 거기서 뻗어나가는 케이블들은 전부 보이지 않게 정리됩니다. 처음 세팅할 때 30분 정도 투자하면 그 이후로는 맥북 하나만 꽂으면 전체 환경이 한 번에 구성돼요.

모니터 뒤에 허브를 숨기고 싶은 분도 계실 텐데, 케이블이 15cm라서 연장 케이블이 필요합니다. USB-C 연장 케이블(1m)을 하나 사서 연결하면 허브를 모니터 뒤나 책상 아래에 둘 수 있어요. 다만 연장 케이블 품질이 안 좋으면 전송 속도가 떨어질 수 있으니 USB 3.1 Gen2 지원 케이블을 사세요.

내구성, 6개월 매일 사용 기준

가장 걱정했던 건 내구성이었어요. 저가 허브 두 개를 각각 2~3개월 만에 보내본 경험이 있으니까요. 코드웨이는 6개월째 매일 8시간 이상 사용 중인데, 포트 인식 불량이나 접촉 문제가 한 번도 없었습니다.

알루미늄 바디 표면에 약간의 사용 흔적(미세한 긁힘)은 생겼지만, 기능적으로는 첫날과 동일합니다. HDMI 포트 핀이 헐거워진다거나, USB 포트가 느슨해지는 현상도 없어요. 매일 출근할 때 맥북을 빼고, 출근하면 다시 꽂는 패턴으로 사용 중인데 커넥터 내구성도 괜찮습니다.

이전 저가 허브들은 2~3개월쯤 되면 슬슬 HDMI 포트에서 "깜빡임"이 시작됐는데, 코드웨이는 아직까지 그런 조짐이 전혀 없어요. 만약 이대로 1년을 넘긴다면, 가격 대비 내구성은 확실히 합격이라고 할 수 있을 것 같습니다.

솔직한 단점, 세 가지 짚겠습니다

장점만 늘어놓으면 광고 같으니까 단점을 제대로 짚겠습니다.

첫째, 케이블이 짧습니다. 허브 본체에서 USB-C 커넥터까지의 케이블 길이가 약 15cm 정도인데, 맥북 옆에 딱 붙여서 써야 합니다. 책상 아래에 허브를 두고 싶다거나, 모니터 뒤쪽에 숨기고 싶다면 연장 케이블이 별도로 필요해요. 저는 맥북 옆에 그냥 놓고 쓰는 편이라 크게 불편하지 않았지만, 케이블 정리에 민감한 분이라면 아쉬울 수 있습니다.

둘째, 가격이 저렴한 편은 아닙니다. 할인가 39,500원이면 USB-C 허브 중에서 중상위 가격대예요. 단순히 USB-A 포트 2~3개만 필요한 분이라면 만 원대 제품으로도 충분합니다. 8포트 풀 구성이 필요한 상황에서만 가격이 정당화돼요.

셋째, 맥에서 듀얼 모니터 확장 시 참고사항이 있습니다. macOS는 기본적으로 하나의 USB-C 허브에서 확장 디스플레이를 하나만 지원하는 제한이 있어요. 듀얼 확장을 하려면 DisplayLink 드라이버를 설치하거나, 하나는 확장 + 하나는 미러링으로 써야 하는 경우가 있습니다. 코드웨이 허브의 문제가 아니라 macOS 자체의 제한인데, 구매 전에 알아두면 좋습니다. 참고로 M3, M4 칩부터는 네이티브 듀얼 확장이 되는 모델도 있어요.

싱크베이 16,800원 vs 코드웨이 39,500원, 뭐가 다른가

비교 대상으로 가장 많이 거론되는 게 싱크베이 7포트 허브(16,800원)입니다. 가격 차이가 두 배 넘으니 당연히 비교하게 되죠.

핵심 차이는 세 가지예요. 첫째, HDMI 출력 해상도. 싱크베이는 4K 30Hz, 코드웨이는 4K 60Hz. 문서 작업만 하면 30Hz도 괜찮지만, 마우스 움직임이나 스크롤에서 체감 차이가 있습니다. 코드 에디터에서 빠르게 스크롤할 때 30Hz는 살짝 뭉개지는 느낌이 있어요.

둘째, 이더넷 포트. 싱크베이에는 이더넷이 없습니다. 유선 랜이 필요 없다면 상관없지만, 재택근무에서 안정적인 인터넷이 필요하다면 차이가 큽니다.

셋째, 빌드 퀄리티. 코드웨이는 알루미늄 바디, 싱크베이는 플라스틱. 방열과 내구성에서 차이가 나고, 장시간 사용 안정성에도 영향을 줍니다.

반대쪽 끝에는 칼디짓(CalDigit) TS4 같은 15만 원대 이상 제품이 있는데, 이건 Thunderbolt 4 독이라 카테고리 자체가 다릅니다. USB-C 허브 범위에서 가성비를 따지면 코드웨이가 중간지점을 잘 잡고 있어요.

이런 사람에게 추천합니다

맥북이나 USB-C 포트만 있는 노트북에서 듀얼 모니터 + 여러 주변기기를 안정적으로 연결하고 싶은 분. 특히 개발자, 디자이너, 영상 편집처럼 동시에 여러 장치를 쓰는 작업 환경이라면 8포트가 빛을 발합니다. 재택근무자에게 이더넷 포트도 큰 메리트예요.

반대로 단순히 마우스, 키보드 정도만 연결할 거라면 이 제품은 오버스펙입니다. 만 원대 4포트 허브로 충분해요.

저는 6개월 동안 매일 하루 8시간 이상 연결해 놓고 썼는데, 지금까지 한 번도 다른 허브를 알아본 적이 없습니다. "안정적으로 잘 되니까 신경 쓸 일이 없다"는 게 이 제품의 가장 큰 장점이에요.

구매 링크

현재 최저가는 아래에서 확인하실 수 있습니다.

쿠팡에서 코드웨이 8포트 USB-C 허브 최저가 확인하기

다음에는 요즘 써보고 있는 무선 이어폰 이야기를 해볼까 합니다. 출퇴근길에 팟캐스트 듣는 용도인데, 3만 원대에서 쓸 만한 게 있는지 꽤 찾아봤거든요.

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

국민연금 보험료 인상이 시작됐다, 40대 직장인이 지금 점검해야 할 것들

Lovizu — Sat, 15 Aug 2026 14:31:03 +0900

올해부터 국민연금 보험료율이 오르기 시작했습니다. 9%에서 13%까지, 매년 0.5%p씩 2033년까지 올라갑니다. 월급명세서를 보고 "어, 뭔가 빠져나가는 게 늘었네?" 싶었던 분들, 맞습니다. 진짜로 더 나갑니다. 소득대체율이 41.5%에서 43%로 올라가니까 "더 내고 더 받는" 구조라고 하는데, 솔직히 40대 직장인 입장에서는 체감이 잘 안 됩니다. 당장 월급에서 빠져나가는 돈은 느는데, 연금 받을 날은 아직 20년 넘게 남았으니까요.

저도 올해 초 급여명세서를 보면서 "아, 이게 시작이구나" 싶었습니다. 아이 셋에 대출 이자에 보험료에, 고정 지출은 이미 빡빡한데 여기에 연금 보험료까지 느는 겁니다. 그래서 올 초에 아내랑 앉아서 우리 집 연금 구조를 처음부터 다시 들여다봤어요. 그러다 보니 그동안 얼마나 대충 관리했는지가 보이더라고요. 비슷한 상황인 분들이 많을 거라 생각합니다. 오늘은 제가 직접 점검하면서 알게 된 것들, 그리고 실제로 바꾼 것들을 공유해 보려고 합니다.

국민연금, 실제로 얼마나 더 나가는 걸까

2026년 기준으로 보험료율이 9%에서 9.5%로 올랐습니다. 0.5%p 차이가 대수롭지 않아 보이지만 직접 계산하면 다릅니다. 월 소득 400만 원 기준으로, 기존에는 본인 부담이 18만 원이었는데 지금은 19만 원입니다. 한 달에 1만 원. "겨우 1만 원?"이라고 생각할 수 있지만, 이게 매년 누적됩니다.

2027년엔 10%, 2028년엔 10.5%... 이렇게 올라가서 2033년에 13%가 되면 본인 부담은 월 26만 원이 됩니다. 지금보다 월 7만 원, 연간 84만 원을 더 내는 거예요. 이 돈이 어디서 나옵니까. 월급이 그만큼 올라주면 좋겠지만, 현실적으로 40대 중반을 넘어가면 급여 인상 폭이 예전 같지 않거든요. 결국 다른 데서 줄이거나, 지출 구조 자체를 다시 짜야 합니다.

한 가지 위안이 되는 건 소득대체율 상향입니다. 기존 40년 가입 기준 41.5%였던 게 43%로 올라갑니다. 단순하게 계산하면, 40년 동안 꾸준히 납부하고 평균 소득이 300만 원이었다면 월 연금이 약 124만 원에서 129만 원으로 늘어나는 셈이에요. 월 5만 원 차이. 솔직히 극적이진 않습니다. 하지만 65세부터 90세까지 25년간 받는다고 치면 1,500만 원 차이입니다. 무시할 수준은 아닙니다.

퇴직연금, DC형인데 수익률을 한 번도 안 봤다면

국민연금은 국가가 알아서 운용하니까 개인이 할 수 있는 게 사실 별로 없습니다. 보험료 올라가는 거 받아들이고, 가입 기간 최대한 늘리는 정도예요. 추후납부(납부예외 기간 보충)나 임의가입 같은 제도를 활용하면 수령액을 늘릴 수 있긴 한데, 40대면 이미 15년 이상 납부해왔을 테니 추가 효과가 크진 않습니다.

진짜 점검해야 하는 건 퇴직연금입니다. 회사에서 DC형(확정기여형)으로 운영하고 있다면, 그 돈이 지금 어디에 투자되고 있는지 확인해 보신 적 있나요? 저는 부끄럽지만 5년 넘게 한 번도 안 봤습니다. 올 초에 열어보니까 전액 원리금보장형 예금에 들어가 있더라고요. 수익률이 연 2% 남짓이었습니다. 5년 동안.

2% 수익률이 왜 문제냐면, 물가상승률을 빼면 사실상 제자리거나 마이너스거든요. 2022~2024년 소비자물가 상승률이 연 3~5%였으니까, 10년 넘게 쌓인 퇴직금이 실질 가치 기준으로는 줄어들고 있었던 거예요. 돈을 모으고 있다고 생각했는데 실은 까먹고 있었다는 얘기입니다.

이걸 뒤늦게 깨닫고 올해 변경했습니다. 퇴직연금 적립금의 70%를 TDF(타겟데이트펀드) 2045로 옮겼어요. TDF는 은퇴 시점에 맞춰 알아서 주식 비중을 줄이고 채권 비중을 늘려가는 펀드입니다. 2045년 은퇴를 목표로 잡았으니까, 지금은 주식 비중이 60~70% 정도로 높고, 시간이 갈수록 안정적으로 전환됩니다. 나머지 30%는 원리금보장형에 그대로 뒀습니다. 한꺼번에 다 옮기기엔 아직 마음이 불안해서요. 이것도 경험을 보면서 천천히 비중을 조정할 생각입니다.

DC형 퇴직연금은 본인이 직접 운용 지시를 내려야 합니다. 안 내리면 그냥 디폴트 옵션(대부분 원리금보장형 예금)에 묶여 있어요. 퇴직연금 운용사 앱이나 홈페이지에서 상품 변경이 가능합니다. 미래에셋, 삼성생명, KB 등 본인 회사가 어느 운용사를 쓰는지 확인하고 앱을 깔면 됩니다. 진짜 5분이면 끝납니다. 근데 그 5분을 5년 동안 안 한 게 바로 저입니다.

연금저축과 IRP, 세액공제 한도를 채우고 있나요

40대 직장인이라면 연금저축이나 IRP(개인형퇴직연금) 하나쯤은 갖고 있을 겁니다. 문제는 매년 한도를 채우고 있느냐예요. 2026년 기준으로 연금저축 + IRP 합산 세액공제 한도는 연 900만 원입니다. 이 중 연금저축은 최대 600만 원까지 인정됩니다.

총급여 5,500만 원 이하라면 납입액의 16.5%, 초과라면 13.2%를 세액공제 받을 수 있어요. 900만 원 풀로 넣으면, 총급여 5,500만 원 초과 기준으로 연 118만 8천 원을 돌려받습니다. 한 달에 10만 원 가까이 되는 금액이에요. 연말정산 때 이게 들어오면 꽤 체감됩니다.

솔직히 저도 예전에는 "노후 자금이야 나중에 생각하지"라면서 매달 30만 원만 넣고 있었습니다. 연간 360만 원. 한도의 40%도 못 채우고 있었던 거예요. 세액공제를 반도 안 받고 있었다는 뜻이기도 합니다. 올해부터 월 75만 원으로 올렸습니다. 부담이 되지만, 세액공제로 연말에 118만 원 돌려받는 걸 생각하면 실질 부담은 월 65만 원 정도입니다.

한 가지 꼭 알아둬야 할 점이 있습니다. 연금저축은 55세 이전에 중도 해지하면 기타소득세 16.5%가 매겨집니다. 세액공제 받은 원금 + 운용수익 전체에 대해서요. 그래서 중도에 꺼낼 가능성이 있는 돈이라면 절대 넣으면 안 됩니다. 아이 학비나 갑자기 집 수리가 필요할 수도 있으니, 비상금 3~6개월분은 CMA나 파킹통장에 따로 확보해 두고, 정말 장기로 묻어둘 수 있는 여유분만 연금에 넣으세요.

보험료, 한 번 정리하면 월 30만 원은 줄어듭니다

연금 이야기를 하다 보면 자연스럽게 보험 이야기가 나옵니다. 40대가 되면 보험이 쌓여 있거든요. 20대 때 부모님이 넣어준 보험, 결혼하면서 가입한 보험, 아이 낳으면서 가입한 어린이보험. 저도 세어보니 보험만 7개였습니다. 합치면 월 85만 원이 나가고 있었어요. 매달 85만 원이라니, 웬만한 월세 수준입니다.

보험 정리를 하면서 기준을 하나 세웠습니다. "실제로 보장이 겹치는 게 있는가?" 확인해 보니까 실손보험이 2개였습니다. 하나는 2008년에 가입한 구실손이고, 하나는 2015년에 가입한 거. 실손보험은 하나면 됩니다. 2008년 구실손이 보장 범위가 넓고 자기부담금이 적어서, 2015년 것을 해지했습니다. 이것만으로 월 8만 원이 줄었어요.

종신보험도 점검했습니다. 2010년에 가입한 종신보험이 월 15만 원짜리였는데, 지금 해지환급금을 조회해 보니 납입 원금보다 적더라고요. 16년 동안 넣은 돈이 원금도 안 돌아오는 거예요. 전형적인 "고비용 저효율" 상품이었습니다. 이걸 해지하고, 보장이 필요한 부분은 정기보험(월 3만 원)으로 갈아탔습니다. 같은 사망보장 1억 원인데 보험료가 5분의 1입니다. 종신보험은 보장과 저축이 섞여 있어서 비싼 거고, 정기보험은 순수 보장만 하니까 싼 겁니다.

이렇게 보험 정리로 월 30만 원을 아꼈고, 그 돈을 연금저축 추가 납입에 돌렸습니다. 보험 정리는 정말 효과가 큽니다. 10년 넘은 보험이 있다면 한 번 들여다보세요. 보험다모아(insure.or.kr)에서 본인 보험 가입 내역을 한 번에 조회할 수 있고, 보장 내용 비교도 가능합니다. 설계사한테 연락할 필요 없이 혼자 확인할 수 있어요.

가계부 앱, 귀찮아도 3개월만 써보세요

연금이고 보험이고, 결국 돈이 어디로 나가는지 파악이 먼저입니다. 저는 올 초에 뱅크샐러드를 깔아서 3개월 동안 모든 지출을 추적했습니다. 그전에는 "대충 이 정도 쓸 거야"라고 감으로 관리했는데, 실제 데이터를 찍어보니 깜짝 놀랄 일이 한둘이 아니었어요.

편의점 지출이 월 12만 원이었습니다. 퇴근길에 캔맥주 하나, 아이 간식 하나, 이런 것들이 쌓인 거예요. 커피가 월 8만 원. 하루에 아메리카노 한 잔 4,500원이면 별것 아닌 것 같은데, 20일 출근하면 9만 원입니다. 택시가 월 15만 원. 야근하고 지하철 끊기면 타는 택시가 한 달에 서너 번이면 그 정도 나옵니다. "이 정도는 괜찮지"라고 넘겼던 것들을 합치니 월 35만 원이었습니다.

가계부를 3개월 쓰면 패턴이 보입니다. 어디서 새는지, 어디가 진짜 고정인지, 어디를 줄여도 삶의 질에 영향이 적은지. 저는 편의점은 주 1회로 제한하고, 커피는 텀블러 들고 다니기 시작했습니다. 회사에 드립백도 가져다 놨어요. 택시는 비 오는 날이나 밤 11시 넘겼을 때만 타기로 했습니다. 이것만으로 월 15만 원을 줄였습니다. 대단한 절약법이 아니에요. 그냥 "무의식적으로 나가던 돈을 인식한" 결과입니다.

뱅크샐러드 말고도 토스 소비내역, 카카오페이 가계부 등 비슷한 기능이 많습니다. 어떤 앱이든 상관없어요. 카드 연동만 하면 자동 분류됩니다. 3개월이면 충분합니다. 그 이후에는 감이 잡혀서 굳이 앱을 안 켜도 지출 관리가 됩니다.

ISA 계좌, 아직 안 만들었다면 올해 안에 개설하세요

연금저축이나 IRP 외에 하나 더 챙길 게 있습니다. ISA(개인종합자산관리계좌)예요. 2026년 기준으로 ISA는 연간 납입한도 4,000만 원, 비과세 한도가 일반형 기준 400만 원입니다. 서민형이나 농어민형은 비과세 한도가 600만 원까지 올라가요.

ISA가 좋은 건 계좌 안에서 이익과 손실을 통산해 준다는 겁니다. 예를 들어 A 상품에서 200만 원 수익, B 상품에서 100만 원 손실이 나면, 순이익 100만 원에 대해서만 과세합니다. 일반 증권 계좌였으면 A의 200만 원에 대해 세금을 내야 하는데, ISA에서는 순이익 기준이라 세 부담이 확 줄어요.

저는 올 초에 ISA 계좌를 만들고, 매월 30만 원씩 S&P500 추종 ETF에 적립식으로 넣고 있습니다. 거창한 투자 전략이 아니에요. 그냥 매달 같은 날 같은 금액을 자동이체로 넣는 겁니다. 3년 의무보유 기간이 있어서 단기로 빼려는 분에게는 안 맞지만, 어차피 5년 이상 장기로 굴릴 생각이면 세금 혜택이 꽤 큽니다.

ISA 만기 후에는 연금저축이나 IRP로 전환할 수도 있습니다. 이때 전환 금액의 10%(최대 300만 원)에 대해 추가 세액공제가 가능해요. 연금저축 세액공제와 별도로 주어지는 혜택이라, ISA → 연금저축 전환까지 설계하면 절세 효과가 상당합니다. 이런 구조를 알고 나서 "왜 진작 안 했을까" 싶었어요.

결국 주말 하루면 됩니다

정리하면, 40대 가장이 지금 당장 할 일은 네 가지예요.

첫째, 퇴직연금 운용 상태 확인. DC형이라면 디폴트 예금에서 벗어나 TDF나 혼합형 펀드를 검토해 보세요. 운용사 앱에서 5분이면 변경 가능합니다. 리스크가 걱정되면 30%만 먼저 옮겨보는 것도 방법입니다.

둘째, 연금저축·IRP 세액공제 한도 확인. 연 900만 원을 채우고 있는지, 아니라면 월 납입액을 얼마까지 올릴 수 있는지 계산해 보세요. 세액공제만으로 연 100만 원 넘게 돌려받을 수 있습니다.

셋째, 보험 정리. 보험다모아에서 가입 내역을 조회하고, 실손 중복이나 고비용 종신보험이 있는지 확인하세요. 겹치는 보장은 과감하게 정리하고, 아낀 보험료는 연금 납입에 돌리세요.

넷째, 가계부 앱 3개월. 뱅크샐러드든 토스든 아무거나 깔고, 카드 연동해서 3개월만 추적하세요. 어디서 돈이 새는지 눈에 보이기 시작합니다.

이 네 가지를 하는 데 시간이 얼마나 걸렸냐면, 주말 하루면 됐습니다. 아이들 재우고 나서 노트북 열고 두 시간 정도 앉아 있으면 퇴직연금 변경, 연금저축 증액 신청, 보험 해지 전화 한 통까지 끝납니다. 그 두 시간이 월 45만 원의 여유를 만들어줬습니다. 연으로 치면 540만 원이에요. 이 돈이 연금 계좌에 들어가서 20년간 복리로 굴러가면, 은퇴 시점에 꽤 의미 있는 차이가 됩니다.

40대는 돈을 가장 많이 벌면서, 동시에 가장 많이 쓰는 시기입니다. 그래서 "관리"가 중요해요. 새로운 재테크 공부를 하라는 게 아닙니다. 이미 가지고 있는 것들을 제대로 들여다보는 것만으로도 달라집니다.

다음에는 아이들 용돈 교육 이야기를 써볼까 합니다. 첫째한테 만 원을 줬더니 전부 뽑기에 쓴 사건이 있었거든요. 돈의 가치를 가르치는 게 이렇게 어려운 일이었나 싶었습니다.

(이미지 출처: Unsplash 무료 라이선스)

연말정산 카드 소득공제, 25% 넘기 전후로 다르게 써야 하는 이유

Lovizu — Fri, 14 Aug 2026 20:05:46 +0900

연말정산 카드 소득공제, 25% 넘기 전후로 다르게 써야 하는 이유

카드를 많이 썼는데 연말정산에서는 생각보다 돌려받는 느낌이 약할 때가 있습니다. 이유는 단순합니다. 신용카드 소득공제는 쓴 돈 전체를 봐주는 제도가 아니라, 총급여의 25%를 넘긴 뒤의 사용분부터 계산하기 때문입니다.

그래서 8월쯤에는 "올해 카드값이 얼마였지?"만 보면 부족합니다. 지금까지 쓴 금액이 총급여의 25%에 가까운지, 이미 넘겼는지, 넘긴 뒤에는 신용카드와 체크카드·현금영수증 비중을 어떻게 가져갈지 봐야 합니다. 같은 30만 원을 써도 어느 구간에서, 어떤 결제수단으로 썼는지에 따라 연말정산 체감이 달라질 수 있습니다.

이 글은 2026년 8월 14일 기준 공개 자료를 바탕으로, 직장인이 연말정산 신용카드 등 사용금액 소득공제를 생활비 관점에서 점검하는 방법을 정리한 글입니다. 세무 대리나 절세 처방이 아니라 가계 예산을 흔들지 않기 위한 확인 순서에 가깝습니다. 실제 공제 가능 여부와 금액은 국세청 홈택스, 회사 연말정산 안내, 세무 전문가 상담으로 최종 확인하는 편이 안전합니다.

최종 업데이트: 2026-08-14

먼저 계산할 것은 카드값이 아니라 총급여의 25%입니다

연말정산 카드 소득공제를 볼 때 가장 흔한 착각은 "카드를 많이 쓰면 공제가 커진다"는 생각입니다. 절반만 맞는 말입니다. 국세청은 신용카드, 직불카드, 선불카드, 현금영수증 사용액 합계 중 총급여액의 25%를 초과하는 금액에 대해 결제수단과 사용처별 공제율을 적용한다고 안내합니다. (출처: 국세청 주요 세법 개정 내용)

예를 들어 총급여가 4,800만 원이라면 기준선은 1,200만 원입니다. 올해 신용카드와 체크카드, 현금영수증을 합쳐 1,000만 원만 썼다면 아직 공제 계산이 본격적으로 시작되지 않은 상태입니다. 반대로 이미 1,300만 원을 썼다면 초과분 100만 원부터 공제율을 따져볼 수 있습니다.

이 기준이 중요한 이유는 돈을 더 쓰라고 말하기 위해서가 아닙니다. 이미 써야 할 생활비가 있다면, 어느 시점부터 결제수단을 바꾸는 것이 합리적인지 판단하기 위해서입니다. 억지 소비로 공제를 받으려는 접근은 대개 손해입니다. 세금이 줄어드는 폭보다 지출 자체가 더 크기 때문입니다.

확인 항목	봐야 할 숫자	해석
총급여	근로소득 원천징수 기준 급여	25% 기준선을 계산하는 출발점
올해 누적 사용액	신용카드+체크카드+현금영수증 등	기준선을 넘겼는지 확인
기준선 초과분	누적 사용액 - 총급여의 25%	공제율을 따져볼 구간
남은 필수지출	식비, 교통비, 병원비, 교육비 등	억지 소비 없이 조정 가능한 범위

8월에 이 표를 한 번 채워보면 연말에 급하게 소비를 늘리는 일을 줄일 수 있습니다. 핵심은 "얼마나 더 써야 공제받나"가 아니라, "어차피 쓸 돈을 어떤 방식으로 결제할까"입니다.

25%를 넘기 전에는 혜택 좋은 카드가 더 현실적일 수 있습니다

총급여의 25%를 아직 넘기지 못했다면, 결제수단별 소득공제율을 너무 일찍 따질 필요는 없습니다. 어차피 기준선 아래 사용액은 공제 계산에서 먼저 빠지기 때문입니다. 이 구간에서는 카드사 할인, 포인트, 생활비 관리 편의성 같은 현실적인 이득이 더 크게 보일 수 있습니다.

예를 들어 월 고정비 대부분을 신용카드로 자동결제하고 있다면, 25% 기준선에 도달하기 전까지는 기존 결제 흐름을 무리하게 바꿀 이유가 작습니다. 통신비, 관리비, 구독료, 보험료처럼 자동결제가 엮여 있는 항목은 바꾸는 과정에서 결제 누락이 생길 수도 있습니다.

다만 여기에도 예외가 있습니다. 신용카드를 쓰면 예산이 자주 무너지는 사람이라면 공제율보다 지출 통제가 먼저입니다. 카드 혜택을 받으려다가 다음 달 결제일마다 통장 잔고를 걱정한다면, 세금 계산보다 현금흐름 관리가 더 급한 문제입니다.

저는 가계 지출을 볼 때 "공제율이 높으니 체크카드가 무조건 낫다"는 식으로 보지 않습니다. 기준선 전에는 신용카드 혜택과 자동결제 편의가 의미 있을 수 있고, 기준선을 넘긴 뒤에는 체크카드·현금영수증 비중을 다시 보는 식으로 나눠 생각하는 편이 현실적입니다.

25%를 넘긴 뒤에는 체크카드와 현금영수증 비중을 봅니다

국세청 안내에 따르면 신용카드 사용분은 15%, 현금영수증과 직불·선불카드 사용분은 30%의 공제율이 적용됩니다. 전통시장과 대중교통 사용분은 40%로 안내되어 있습니다. (출처: 국세청 주요 세법 개정 내용)

이 차이는 기준선을 넘긴 뒤에 의미가 커집니다. 이미 총급여의 25%를 넘겼다면, 이후의 생활비 중 일부를 체크카드나 현금영수증으로 처리하는 것이 공제 계산상 더 유리할 수 있습니다. 물론 카드사 할인이나 무이자, 포인트가 큰 지출이라면 단순 공제율만 보고 바꾸면 안 됩니다.

예를 들어 10만 원짜리 지출이 있다고 해보겠습니다. 신용카드 공제율만 보면 15%, 체크카드·현금영수증은 30%입니다. 하지만 이것이 세금에서 그대로 1만5천 원, 3만 원 빠진다는 뜻은 아닙니다. 소득공제는 과세표준을 줄이는 방식이라 실제 세금 감소액은 자신의 세율 구간과 다른 공제 상황에 따라 달라집니다.

그래서 생활비 관점의 결론은 더 단순합니다. 기준선을 넘긴 뒤라면, 할인 혜택이 크지 않은 일반 지출은 체크카드·현금영수증으로 돌릴 만합니다. 반대로 특정 신용카드 혜택이 확실한 항목, 할부가 필요한 큰 지출, 결제 안정성이 중요한 자동납부는 기존 방식을 유지하는 쪽이 나을 수 있습니다.

전통시장·대중교통·문화비는 따로 봐야 합니다

연말정산 카드 소득공제에서 전통시장과 대중교통은 일반 신용카드 사용분과 다르게 봐야 합니다. 국세청은 전통시장 사용분과 대중교통 이용분에 대해 40% 공제율을 안내합니다. 총급여 7천만 원 이하 근로자의 문화체육 사용분은 30% 공제율로 안내되어 있습니다. (출처: 국세청 주요 세법 개정 내용)

문화비 소득공제는 도서, 공연, 박물관·미술관, 신문, 영화 같은 항목에서 많이 알려져 있었습니다. 2025년 7월 1일 이후 지출하는 수영장·체력단련장 시설 이용료도 공제대상금액에 추가된 것으로 국세청 자료에 안내되어 있습니다. 문화비 소득공제 누리집은 사업자 검색 기능을 제공하므로, 내가 결제하려는 곳이 등록 사업자인지 확인할 수 있습니다. (출처: 문화비 소득공제 사업자 찾기)

여기서 조심할 부분은 "헬스장에 결제하면 전부 된다"처럼 단순화하지 않는 것입니다. 국세청 자료는 시설이용료와 직접 관련이 없는 비용은 제외될 수 있고, 시설이용료와 시설이용 외 비용이 구분되지 않는 경우 계산 방식이 달라질 수 있다고 설명합니다. 등록 사업자 여부와 결제 항목을 함께 봐야 합니다.

전통시장도 마찬가지입니다. 내가 시장이라고 생각하는 곳에서 썼다고 모두 전통시장 사용분으로 잡히는 것은 아닐 수 있습니다. 연말정산 간소화 자료에서 어떻게 분류되는지, 현금영수증이나 카드 사용내역이 제대로 반영되는지를 확인해야 합니다.

공제한도가 있어서 무한정 유리하지 않습니다

카드 소득공제는 공제율만 보면 체크카드와 현금영수증을 많이 쓰는 것이 계속 유리해 보입니다. 하지만 공제한도가 있습니다. 국세청은 소비자 소득공제 한도를 총급여 7천만 원 이하 300만 원, 총급여 7천만 원 초과 250만 원으로 안내합니다. 한도 초과금액이 있는 경우 전통시장, 대중교통, 문화체육 사용분 등에 대해 추가공제 구조가 따로 있습니다. (출처: 국세청 주요 세법 개정 내용)

이 말은 두 가지로 나눠 이해하면 쉽습니다. 첫째, 공제율이 높은 결제수단을 쓴다고 해서 끝없이 공제가 커지는 것은 아닙니다. 둘째, 한도에 가까운 사람은 일반 사용분보다 전통시장, 대중교통, 문화비처럼 별도 추가공제 가능성이 있는 항목을 더 꼼꼼히 확인해야 합니다.

다만 일반 직장인이 매달 이 계산을 세무 프로그램처럼 정확히 할 필요는 없습니다. 홈택스 연말정산 미리보기, 카드사 연말정산 리포트, 회사 연말정산 안내가 열리는 시점에 다시 맞춰보면 됩니다. 8월에는 방향만 잡아도 충분합니다.

제가 현실적으로 권하는 기준은 이렇습니다. 총급여 25%에 한참 못 미쳤다면 지출을 일부러 늘리지 않습니다. 이미 기준선을 넘겼다면 앞으로 남은 생활비 중 할인 혜택이 약한 지출부터 체크카드·현금영수증으로 돌릴지 봅니다. 한도에 가까운 사람은 대중교통, 전통시장, 문화비 사용분이 빠지지 않았는지 간소화 자료에서 확인합니다.

이런 지출은 소득공제보다 예산 통제가 먼저입니다

연말정산 시즌이 다가오면 "공제받으려면 더 써야 하나"라는 질문이 나옵니다. 하지만 카드 소득공제는 지출을 늘릴 이유가 되기 어렵습니다. 10만 원을 더 써서 세금이 일부 줄어든다 해도, 지갑에서 나간 돈은 10만 원 그대로입니다.

특히 아래 지출은 소득공제를 핑계로 늘리지 않는 편이 좋습니다.

필요하지 않은 가전·가구 교체
할인율 때문에 담는 대량 장보기
쓰지 않을 가능성이 큰 연간 이용권
카드 실적을 채우기 위한 추가 결제
할부로 넘기면 괜찮아 보이는 고가 소비

연말정산은 이미 발생한 지출을 세법에 맞게 정리하는 절차입니다. 세금을 줄이려고 생활비를 부풀리면 순서가 뒤집힙니다. 먼저 월 예산 안에서 필요한 소비인지 확인하고, 그다음 결제수단을 고르는 편이 낫습니다.

반대로 놓치면 아까운 지출도 있습니다. 평소에 현금으로 결제하던 병원 주변 약국, 동네 학원비 일부, 수리비, 전통시장 장보기처럼 현금영수증을 받을 수 있는 항목입니다. 이런 지출은 더 쓰는 것이 아니라 이미 쓰는 돈의 증빙을 챙기는 문제입니다.

8월에 해두면 연말에 덜 흔들리는 점검 순서

연말정산 카드 소득공제는 12월에 몰아서 계산하면 늦습니다. 이미 지출은 끝나 있고, 남은 선택지는 크지 않기 때문입니다. 8월이나 9월쯤 한 번만 점검해도 연말 소비를 억지로 늘리는 일을 줄일 수 있습니다.

첫 번째로 올해 총급여 예상액을 적습니다. 연봉계약서 숫자와 연말정산 총급여는 다를 수 있지만, 대략적인 기준선을 잡기에는 충분합니다. 상여, 휴직, 이직이 있었다면 회사 급여명세서나 인사팀 안내를 기준으로 보수적으로 잡습니다.

두 번째로 카드사 앱과 현금영수증 조회 화면에서 올해 누적 사용액을 봅니다. 신용카드만 보지 말고 체크카드, 현금영수증까지 합쳐야 합니다. 가족카드나 부양가족 사용분은 공제 요건이 따로 얽힐 수 있으니, 애매하면 회사 연말정산 안내 시점에 다시 확인합니다.

세 번째로 남은 4개월의 필수지출을 적습니다. 식비, 교통비, 병원비, 교육비, 관리비처럼 이미 예정된 돈입니다. 여기서 조정할 수 있는 것은 "쓸지 말지"보다 "어떤 결제수단으로 처리할지"에 가깝습니다.

마지막으로 자동결제 항목은 무리하게 건드리지 않습니다. 통신비나 보험료처럼 한 번 꼬이면 불편한 항목은 소득공제율보다 납부 안정성이 우선입니다. 대신 장보기, 약국, 동네 수리비, 운동시설 이용료처럼 결제 순간에 선택 가능한 항목부터 바꾸면 부담이 덜합니다.

상황별로 이렇게 판단하면 됩니다

총급여 25% 기준선에 아직 멀리 있다면, 체크카드 전환보다 과소비 방지가 먼저입니다. 이 구간에서 공제율을 따지며 지출을 늘리면 절세가 아니라 소비 확대가 됩니다. 신용카드 혜택을 이미 잘 쓰고 있고 결제일 관리가 된다면 그대로 가도 됩니다.

기준선을 거의 넘겼거나 이미 넘긴 사람은 남은 생활비의 결제수단을 나눠볼 만합니다. 할인 혜택이 약한 일반 지출은 체크카드나 현금영수증으로 처리하고, 카드 혜택이 큰 고정비는 유지하는 방식입니다. 전통시장과 대중교통, 문화비 항목은 간소화 자료에서 누락 여부를 따로 확인합니다.

카드값 때문에 매달 잔고가 흔들리는 사람은 연말정산보다 결제 구조가 먼저입니다. 이 경우에는 신용카드 실적과 포인트를 줄이고, 체크카드와 계좌 잔고 중심으로 생활비를 관리하는 편이 더 나을 수 있습니다. 세금 환급 몇만 원보다 연체나 리볼빙 위험을 피하는 것이 훨씬 큽니다.

이직, 휴직, 퇴직, 맞벌이 부양가족 공제처럼 변수가 있는 사람은 단순 계산표를 그대로 믿지 않는 편이 좋습니다. 총급여와 기본공제 대상, 부양가족 사용분 반영 여부에 따라 결과가 달라질 수 있습니다. 회사 연말정산 공지와 국세청 자료를 같이 확인해야 합니다.

연말정산 카드 소득공제 체크리스트

올해 예상 총급여를 적고 25% 기준선을 계산했다.
신용카드, 체크카드, 현금영수증 누적 사용액을 합산했다.
기준선을 넘기 전인지, 넘긴 뒤인지 구분했다.
기준선을 넘긴 뒤의 일반 생활비는 체크카드·현금영수증 전환을 검토했다.
전통시장, 대중교통 사용분이 따로 잡히는지 확인했다.
도서·공연·영화·수영장·체력단련장 등 문화비 사용분은 등록 사업자 여부를 확인했다.
공제 때문에 필요 없는 지출을 늘리지 않기로 했다.
자동결제 항목은 결제 누락 위험까지 보고 변경 여부를 정했다.
연말정산 간소화 자료가 열리면 누락 항목을 다시 확인하기로 했다.

자주 묻는 질문

신용카드보다 체크카드가 항상 유리한가요?

항상 그렇지는 않습니다. 총급여 25% 기준선을 넘기 전에는 공제율 차이가 크게 체감되지 않을 수 있습니다. 기준선을 넘긴 뒤에는 체크카드와 현금영수증의 공제율이 신용카드보다 높지만, 카드 할인이나 자동결제 안정성까지 함께 봐야 합니다.

총급여의 25%를 못 넘기면 아무 의미가 없나요?

카드 소득공제 계산에서는 기준선을 넘지 못하면 공제 효과가 제한적입니다. 그렇다고 지출을 억지로 늘릴 필요는 없습니다. 연말정산보다 생활비를 지키는 것이 먼저입니다.

전통시장이나 대중교통은 왜 따로 봐야 하나요?

국세청 안내상 전통시장과 대중교통 사용분은 일반 신용카드 사용분보다 높은 공제율이 적용됩니다. 다만 실제 반영 여부는 카드·현금영수증 자료와 사용처 분류에 따라 달라질 수 있으므로 간소화 자료에서 확인해야 합니다.

헬스장이나 수영장 비용도 문화비 소득공제가 되나요?

2025년 7월 1일 이후 지출하는 수영장·체력단련장 시설이용료는 공제대상금액에 추가된 것으로 안내되어 있습니다. 다만 등록 사업자 여부와 결제 항목에 따라 달라질 수 있으니 문화비 소득공제 누리집에서 사업자를 확인하는 편이 안전합니다.

가족카드 사용액도 내 연말정산에 들어가나요?

가족카드, 부양가족 사용분, 맞벌이 부부의 공제 배분은 요건에 따라 달라질 수 있습니다. 단순히 카드 명의만 보고 판단하지 말고, 회사 연말정산 안내와 국세청 자료를 기준으로 확인해야 합니다.

마무리하면, 더 쓰는 계획이 아니라 덜 흔들리는 계획이어야 합니다

연말정산 카드 소득공제는 소비를 부추기는 장치가 아닙니다. 이미 필요한 생활비를 썼다면, 총급여 25% 기준선을 넘겼는지 확인하고 남은 지출의 결제수단을 조정하는 정도로 접근하는 것이 현실적입니다.

8월에 할 일은 복잡한 세액 계산이 아닙니다. 총급여 25% 기준선, 올해 누적 사용액, 남은 필수지출, 전통시장·대중교통·문화비 누락 가능성만 확인해도 충분합니다. 세금 환급을 위해 돈을 더 쓰기보다, 어차피 쓸 돈이 제대로 기록되게 만드는 쪽이 가계에는 더 안전합니다.

출처

화면 눈 피로 줄이는 20-20-20 루틴: 밝기보다 먼저 볼 기준

Lovizu — Thu, 13 Aug 2026 02:07:34 +0900

오후가 되면 화면 글자가 또렷하지 않고, 눈을 몇 번 감았다 떠도 뻑뻑한 날이 있습니다. 이럴 때 많은 사람이 모니터 밝기부터 낮추거나 블루라이트 차단 안경을 찾습니다. 그런데 실제로 먼저 봐야 할 것은 얼마나 오래 한 지점을 봤는지, 화면과 눈 사이가 너무 가까운지, 창문과 조명이 화면에 비치는지입니다.

화면 눈 피로는 대개 한 가지 원인으로만 오지 않습니다. 깜빡임이 줄고, 초점이 가까운 곳에 오래 묶이고, 화면 반사를 피하려고 몸이 앞으로 기울어지는 일이 겹칩니다. 그래서 해결도 "밝기 하나"가 아니라 하루 작업 흐름을 조금씩 바꾸는 쪽이 현실적입니다.

먼저 기준부터 잡으면 이렇습니다.

컴퓨터를 오래 볼 때는 20분마다 약 20피트, 우리 기준으로 약 6m 떨어진 곳을 20초 보는 방식이 눈 휴식의 기본값입니다. (출처: National Eye Institute)

OSHA는 모니터를 정면에 두고, 눈에서 최소 20인치 이상 떨어뜨리며, 화면 위쪽이 눈높이 또는 그보다 살짝 낮은 위치가 되도록 안내합니다. (출처: OSHA - Monitors)

눈 통증, 갑작스러운 시야 변화, 충혈이 심하게 지속되는 경우에는 생활 루틴만으로 판단하지 말고 안과 진료를 받는 편이 안전합니다.

최종 업데이트: 2026-08-13

20-20-20은 알람보다 "초점을 멀리 보내는 습관"입니다

20-20-20 규칙은 복잡하지 않습니다. 화면을 20분 봤다면, 20초 동안 20피트 정도 떨어진 곳을 보는 방식입니다. National Eye Institute는 컴퓨터를 오래 보면 눈이 피로해질 수 있으니, 20분마다 멀리 있는 대상을 20초 보며 눈을 쉬게 하라고 안내합니다.

중요한 건 숫자를 완벽하게 맞추는 일이 아닙니다. 20분마다 6m를 정확히 재거나, 알람을 끄느라 더 스트레스받을 필요는 없습니다. 핵심은 가까운 화면에 묶여 있던 초점을 멀리 풀어주는 것입니다. 창밖 건물, 복도 끝 시계, 사무실 반대편 벽처럼 눈이 멀리 맞출 수 있는 지점을 하나 정해두면 실천이 쉬워집니다.

개발 작업처럼 집중이 길게 이어지는 일을 하면 "조금만 더 하고 쉬자"가 반복됩니다. 문제는 눈이 피곤해진 뒤 쉬면 회복이 늦다는 점입니다. 커밋 하나 끝낸 뒤, 회의가 시작되기 전, 문서 한 단락을 마친 뒤처럼 작업 단위를 끊는 지점에 눈 휴식을 붙이는 편이 알람보다 오래 갑니다.

화면 거리는 눈 피로와 목 자세를 같이 바꿉니다

눈이 피로할 때 화면을 가까이 당기는 습관이 생기기 쉽습니다. 글자가 잘 안 보이니 몸이 앞으로 가고, 몸이 앞으로 가면 목과 어깨까지 같이 굳습니다. 이때 "자세를 바르게 하자"만으로는 오래 못 갑니다. 글자가 작거나 화면이 너무 멀거나 반사가 있으면 몸은 다시 앞으로 기울어집니다.

OSHA의 컴퓨터 작업대 자료는 모니터를 눈에서 최소 20인치, 약 50cm 이상 떨어뜨리고, 일반적으로 20~40인치 범위에서 편하게 읽히는 거리를 잡으라고 설명합니다. 화면 위쪽은 눈높이 또는 그보다 조금 낮게 두는 편이 목을 젖히거나 숙이는 일을 줄입니다. 이 기준은 눈만을 위한 조언이 아니라 목과 어깨 부담을 같이 낮추는 세팅입니다.

책상이 좁다면 먼저 화면 배율을 올려보세요. 모니터를 더 멀리 두고도 글자가 편하게 읽히면 눈과 목이 동시에 편해집니다. 노트북만 쓰는 경우에는 화면을 올리면 키보드가 같이 올라가 손목이 불편해질 수 있으니, 가능하면 외장 키보드와 마우스를 함께 쓰는 쪽이 낫습니다.

점검 항목	괜찮은 기준	바꿔야 할 신호
화면 거리	눈에서 약 50cm 이상, 글자가 편하게 읽힘	글자를 보려고 상체가 앞으로 감
화면 높이	화면 위쪽이 눈높이 또는 살짝 아래	턱이 들리거나 고개가 계속 숙여짐
화면 위치	정면을 볼 때 몸통과 목이 같이 앞을 봄	화면이 옆에 있어 목을 비틀고 봄
글자 크기	허리를 기대도 읽힘	눈을 찡그리거나 확대를 자주 함

밝기를 낮추기 전에 반사와 주변 밝기를 봐야 합니다

눈이 부시면 화면 밝기를 낮추고 싶어집니다. 하지만 주변 조명과 화면 반사가 그대로라면 밝기만 낮춰도 해결이 약합니다. 화면이 어두워지면 글자를 보려고 더 힘을 주고, 창문이나 스탠드가 비치면 반사를 피해 자세가 틀어집니다.

OSHA는 조명과 밝기 수준을 적절히 잡아야 모니터 이미지를 보기 쉽고, 과한 조명이나 화면 반사가 눈 피로와 두통, 어색한 자세로 이어질 수 있다고 설명합니다. 특히 창문이나 조명이 화면에 직접 비치지 않게 하고, 밝은 빛이 시야 안에 바로 들어오지 않도록 배치하는 것이 좋습니다.

집에서 일한다면 한 번만 시간을 내서 낮과 밤의 화면을 각각 봐야 합니다. 낮에는 창문 방향이 문제이고, 밤에는 천장등과 스탠드 위치가 문제인 경우가 많습니다. 화면을 창문과 직각에 가깝게 두거나, 커튼을 조절하거나, 스탠드 빛이 화면에 반사되지 않게 옆으로 빼는 것만으로도 눈 피로가 줄어들 수 있습니다.

밝기는 주변보다 지나치게 튀지 않는 정도가 좋습니다. 어두운 방에서 밝은 모니터만 켜두면 대비가 커지고, 반대로 환한 창가 앞에서 어두운 화면을 보면 글자가 뭉개져 보일 수 있습니다. "몇 퍼센트 밝기"보다 화면과 주변의 차이가 너무 큰지를 먼저 보세요.

뻑뻑함은 눈물이 부족해서가 아니라 깜빡임이 줄어서 시작될 수 있습니다

화면을 볼 때 눈이 마르는 느낌은 흔합니다. OSHA는 모니터를 오래 보면 눈 피로와 건조함이 생길 수 있고, 화면을 볼 때 사용자가 눈을 덜 깜빡이는 경우가 많다고 설명합니다. AAO EyeWiki의 디지털 눈 피로 자료도 휴식과 깜빡임, 건조한 환경 관리가 증상 완화에 관련된다고 정리합니다.

여기서 흔한 실수는 인공눈물부터 계속 넣는 것입니다. 인공눈물이 필요한 사람도 있지만, 모든 뻑뻑함을 점안액으로만 해결하려고 하면 원인을 놓치기 쉽습니다. 에어컨 바람이 얼굴로 바로 오거나, 습도가 낮거나, 콘택트렌즈를 오래 끼고 있거나, 화면 앞에서 눈을 거의 깜빡이지 않는 패턴이 같이 있는지 봐야 합니다.

일단은 세 가지부터 해볼 만합니다.

20-20-20 휴식 때 일부러 3~5번 천천히 깜빡입니다.
에어컨·선풍기 바람이 얼굴에 직접 오지 않게 방향을 바꿉니다.
콘택트렌즈를 낀 날에는 화면 작업 시간을 더 잘게 끊고, 건조감이 심하면 안경 사용 시간을 늘립니다.

눈이 자주 마른다면 실내 습도도 변수입니다. OSHA는 건조한 공기가 눈을 건조하게 할 수 있고, 특히 콘택트렌즈 사용자에게 더 불편할 수 있다고 안내합니다. 가습기를 무조건 켜라는 뜻은 아니지만, 에어컨이 강한 사무실이나 난방이 센 겨울에는 바람 방향과 습도를 함께 보는 편이 좋습니다.

블루라이트 차단보다 "밤 화면 시간"을 먼저 줄입니다

블루라이트는 눈 건강 이야기에서 자주 등장합니다. 하지만 업무용 화면 눈 피로를 모두 블루라이트 탓으로 돌리면 판단이 흐려집니다. AAO EyeWiki는 미국안과학회가 컴퓨터 화면의 빛이 눈을 손상한다는 과학적 근거가 없다고 보며, 컴퓨터 사용을 위한 특수 안경을 권하지 않는다고 정리합니다.

그렇다고 밤 화면 사용이 아무 영향도 없다는 뜻은 아닙니다. 같은 자료는 취침 직전 디지털 기기 사용이 수면 패턴에 영향을 줄 수 있다고 설명합니다. 눈 피로와 수면 문제는 완전히 같은 주제는 아니지만, 밤 늦게 밝은 화면을 계속 보면 다음 날 피로가 다시 쌓입니다.

그래서 우선순위는 이렇습니다. 낮에는 휴식 간격, 거리, 반사, 건조함을 먼저 손봅니다. 밤에는 블루라이트 차단 안경보다 화면을 보는 시간을 줄이고, 밝기를 낮추고, 잠들기 전 업무 메시지나 자극적인 콘텐츠를 끊는 것이 더 실용적입니다. 안경 하나로 하루 종일 화면을 봐도 괜찮아진다고 기대하면 실패하기 쉽습니다.

이런 증상은 "화면을 많이 봐서 그래"로 넘기지 않습니다

화면 눈 피로는 흔하지만, 모든 눈 불편감이 단순 피로는 아닙니다. 생활 루틴을 바꿔도 눈 통증이 심하거나, 시야가 갑자기 흐려지거나, 한쪽 눈만 유독 불편하거나, 빛 번짐과 두통이 같이 심해진다면 다른 문제가 숨어 있을 수 있습니다.

아래에 해당하면 휴식만 반복하지 말고 안과나 의료기관에서 확인받는 편이 안전합니다.

갑작스러운 시력 저하나 시야 일부가 가려지는 느낌
눈 통증이 강하거나 충혈이 심하게 지속되는 경우
빛을 보기 힘들 정도의 눈부심
두통, 구역감, 어지럼이 눈 증상과 같이 나타나는 경우
콘택트렌즈 착용 중 통증, 분비물, 심한 충혈이 있는 경우
당뇨, 고혈압 등 눈 건강에 영향을 줄 수 있는 질환이 있는 경우

이 글은 일반적인 생활 건강 정보입니다. 눈 질환의 진단이나 치료를 대신하지 않습니다. 증상이 갑자기 심해지거나 오래 지속되면 자가 판단보다 의료 전문가 상담을 우선하세요.

오늘 바로 바꿀 수 있는 화면 눈 피로 체크리스트

20분마다 멀리 볼 대상을 하나 정해두었는가
눈 휴식 때 일부러 천천히 깜빡이는가
화면이 눈에서 약 50cm 이상 떨어져 있는가
허리를 기대고도 글자가 편하게 읽히는가
화면 위쪽이 눈높이 또는 살짝 아래에 있는가
창문, 천장등, 스탠드가 화면에 비치지 않는가
에어컨·선풍기 바람이 눈으로 바로 오지 않는가
밤에는 화면 밝기와 사용 시간을 함께 줄이는가
통증·시야 변화·심한 충혈이 있으면 진료 기준으로 보는가

자주 묻는 질문

Q. 20-20-20을 꼭 20분마다 해야 하나요?
정확한 숫자보다 가까운 화면에서 멀리 초점을 보내는 습관이 핵심입니다. 다만 "생각날 때마다"로 두면 대부분 잊기 때문에, 20분 또는 작업 한 단위마다 쉬는 기준을 정해두는 편이 실천하기 쉽습니다.

Q. 다크 모드가 눈 피로에 더 좋은가요?
사람마다 다릅니다. 어두운 방에서는 다크 모드가 편할 수 있지만, 밝은 공간에서는 글자 대비가 약해져 더 힘들 수 있습니다. 모드보다 화면과 주변 밝기 차이, 글자 크기, 반사를 먼저 확인하세요.

Q. 블루라이트 차단 안경을 쓰면 눈 피로가 해결되나요?
그렇게 단정하기 어렵습니다. 미국안과학회는 컴퓨터 사용을 위한 특수 안경을 일반적으로 권하지 않는 입장입니다. 장시간 화면 사용의 피로는 휴식 부족, 깜빡임 감소, 거리, 반사, 건조함이 같이 작용하므로 안경 하나에 기대지 않는 편이 좋습니다.

Q. 인공눈물은 써도 되나요?
건조감 완화에 도움이 될 수 있지만, 종류와 사용 빈도는 개인 상태에 따라 달라집니다. 자주 써야 하거나 통증·충혈이 함께 있으면 안과에서 원인을 확인하는 편이 안전합니다.

작성 관점

이 글은 책상 앞에서 오래 일하는 사람이 눈 피로를 "참아야 하는 일"로 넘기지 않도록 쓰였습니다. National Eye Institute, OSHA, AAO EyeWiki 자료를 확인해 20-20-20 휴식, 모니터 거리, 조명 반사, 건조한 환경 같은 생활 기준을 정리했습니다. 특정 안경이나 기기를 권하기보다, 돈이 들지 않는 작업 환경 조정과 진료가 필요한 신호를 구분하는 데 초점을 맞췄습니다.

출처

National Eye Institute - Keep Your Eyes Healthy — 20-20-20 눈 휴식, 정기 눈 검진, 눈 건강 생활 습관을 확인했습니다. 확인일: 2026-08-13
OSHA - Computer Workstations: Monitors — 모니터 거리, 높이, 정면 배치, 장시간 화면 보기와 눈 피로·건조함 관련 내용을 확인했습니다. 확인일: 2026-08-13
OSHA - Computer Workstations: Workstation Environment — 조명, 화면 반사, 건조한 공기와 작업 환경 관련 기준을 확인했습니다. 확인일: 2026-08-13
AAO EyeWiki - Computer Vision Syndrome (Digital Eye Strain) — 디지털 눈 피로 증상, 휴식·깜빡임, 블루라이트 차단 안경에 대한 한계를 확인했습니다. 확인일: 2026-08-13

Node.js 컨테이너 종료가 느릴 때 먼저 볼 graceful shutdown 기준

Lovizu — Tue, 11 Aug 2026 02:07:25 +0900

Node.js 컨테이너 종료가 느릴 때 먼저 볼 graceful shutdown 기준

배포 버튼을 눌렀을 뿐인데 몇 초 동안 502가 튑니다. 로그에는 에러가 많지 않고, 새 컨테이너도 정상으로 떠 있습니다. 그런데 사용자 입장에서는 방금 누른 저장 버튼이 실패했고, 운영자는 "배포 중 잠깐 그런 것 같다"는 애매한 말만 남깁니다.

이런 문제는 보통 배포 도구만 바꿔서는 사라지지 않습니다. 컨테이너가 내려갈 때 애플리케이션이 어떤 순서로 요청을 멈추고, 남은 일을 끝내고, 프로세스를 종료할지 정해져 있어야 합니다. Node.js 서버라면 SIGTERM을 받고도 계속 새 요청을 받는지, server.close() 이후 오래 붙은 연결을 어떻게 다룰지, readiness가 먼저 내려가는지부터 확인해야 합니다.

나는 작은 팀의 Node.js 서비스를 볼 때 graceful shutdown을 아래 네 가지 질문으로 쪼갭니다.

종료 신호가 실제 Node.js 프로세스까지 도착하는가
새 요청을 먼저 막고, 처리 중인 요청은 끝낼 시간을 주는가
readiness와 liveness가 서로 다른 실패를 보고 있는가
플랫폼의 강제 종료 시간 안에 정리 작업이 끝나는가

최종 업데이트: 2026-08-11
작성 관점: Node.js API 서버를 Docker, ECS/Fargate, 로드밸런서 뒤에서 운영할 때 겪는 배포 중 502, 중단 요청, 느린 종료 문제를 기준으로 정리했습니다.

graceful shutdown은 "프로세스 종료"보다 앞의 문제입니다

docker stop이나 오케스트레이터의 스케일 인이 시작되면 컨테이너는 언젠가 내려갑니다. 문제는 내려간다는 사실이 아니라, 내려가는 동안 트래픽이 어떻게 흐르느냐입니다. 로드밸런서는 아직 컨테이너가 살아 있다고 보고 요청을 보낼 수 있고, Node.js 프로세스는 새 연결을 받다가 갑자기 끊길 수 있습니다.

graceful shutdown을 제대로 보려면 종료를 네 단계로 나눠야 합니다.

단계	애플리케이션이 해야 할 일	실패하면 보이는 증상
종료 신호 수신	`SIGTERM` 같은 중지 신호를 핸들링한다	컨테이너가 강제 종료될 때까지 기다림
트래픽 차단	readiness를 실패로 바꾸거나 새 연결을 받지 않는다	배포 중 일부 요청이 새로 들어와 끊김
진행 중 작업 마무리	HTTP 요청, DB 쿼리, 큐 작업을 정리한다	저장, 결제, 파일 처리 같은 작업이 중간에 멈춤
제한 시간 안에 종료	타이머, DB 풀, 워커를 닫고 `exitCode`를 정한다	플랫폼이 `SIGKILL`로 강제 종료

이 순서가 없는 상태에서 health check만 추가하면 착시가 생깁니다. "컨테이너는 healthy"인데 배포 중 요청은 실패합니다. 헬스체크는 상태를 알려주는 장치이고, 종료 처리 코드는 실제로 요청을 멈추는 장치입니다. 둘을 같이 설계해야 합니다.

종료 신호가 Node.js까지 도착하는지 먼저 확인합니다

Node.js 공식 문서는 프로세스가 SIGINT, SIGTERM 같은 signal을 받으면 같은 이름의 이벤트가 발생한다고 설명합니다. 신호 핸들러는 첫 번째 인자로 신호 이름을 받을 수 있습니다. 이 글은 2026년 8월 11일 기준 Node.js 공식 문서를 확인해 작성했습니다. (출처: Node.js Process - Signal events)

컨테이너 환경에서 자주 놓치는 지점은 신호가 애플리케이션까지 전달되지 않는 경우입니다. Dockerfile의 CMD나 ENTRYPOINT가 shell form으로 되어 있거나, 중간 쉘 스크립트가 마지막에 exec를 쓰지 않으면 실제 Node.js 프로세스가 PID 1이 아닐 수 있습니다. 이 경우 종료 신호는 쉘까지는 갔지만 앱은 모르는 상태가 됩니다.

먼저 Dockerfile을 이렇게 점검합니다.

# 피하고 싶은 형태: shell이 중간에 끼기 쉽습니다.
CMD node server.js

# 더 명확한 형태: node 프로세스가 직접 실행됩니다.
CMD ["node", "server.js"]

초기화 스크립트가 꼭 필요하다면 마지막 실행에서 exec를 써서 프로세스를 대체해야 합니다.

#!/bin/sh
set -e

node scripts/migrate-once.js
exec node server.js

이 한 줄 차이가 배포 안정성에 영향을 줍니다. exec 없이 node server.js를 실행하면 shell이 부모 프로세스로 남고, 종료 신호 처리 방식이 의도와 달라질 수 있습니다. 작은 팀에서는 이런 문제가 로드밸런서 설정이나 ECS 배포 설정 탓처럼 보이다가, 결국 Dockerfile 한 줄에서 발견되는 일이 적지 않습니다.

Dockerfile 문서는 STOPSIGNAL이 컨테이너 중지 시 보낼 신호를 지정하며, 별도 정의가 없으면 기본값이 SIGTERM이라고 설명합니다. 또한 docker stop은 이 중지 신호를 사용합니다. 특별한 이유가 없다면 Node.js HTTP 서버에서는 기본 SIGTERM 흐름을 받아 애플리케이션 코드에서 종료 절차를 처리하는 편이 단순합니다. (출처: Dockerfile reference - STOPSIGNAL)

Node.js에서는 새 연결 차단과 기존 요청 마무리를 분리합니다

Node.js HTTP 서버의 server.close()는 새 연결을 받지 않게 하고, 요청을 보내고 있거나 응답을 기다리는 중이 아닌 연결을 닫습니다. Node.js v19.0.0부터는 반환 전 idle connection을 닫는 변경도 들어갔습니다. 오래 붙어 있는 연결까지 강제로 닫아야 할 때는 server.closeAllConnections() 같은 별도 메서드가 있지만, 이름 그대로 활성 연결도 닫을 수 있어 사용 위치를 조심해야 합니다. (출처: Node.js HTTP - server.close(), Node.js HTTP - server.closeAllConnections())

기본 구조는 아래처럼 시작할 수 있습니다.

import http from "node:http";
import process from "node:process";

const app = async (req, res) => {
  if (req.url === "/healthz") {
    res.writeHead(200);
    res.end("ok");
    return;
  }

  if (req.url === "/readyz") {
    if (isShuttingDown) {
      res.writeHead(503);
      res.end("shutting down");
      return;
    }

    res.writeHead(200);
    res.end("ready");
    return;
  }

  res.writeHead(200, { "content-type": "application/json" });
  res.end(JSON.stringify({ ok: true }));
};

const server = http.createServer(app);
let isShuttingDown = false;

server.listen(3000, () => {
  console.log("server listening on :3000");
});

async function shutdown(signal) {
  if (isShuttingDown) return;

  isShuttingDown = true;
  console.log(`${signal} received. start graceful shutdown`);

  const forceExitTimer = setTimeout(() => {
    console.error("graceful shutdown timeout exceeded");
    process.exit(1);
  }, 25_000);

  forceExitTimer.unref();

  server.close(async (error) => {
    if (error) {
      console.error(error);
      process.exitCode = 1;
    }

    try {
      await closeDatabasePool();
      await closeQueueConsumers();
    } catch (cleanupError) {
      console.error(cleanupError);
      process.exitCode = 1;
    }
  });
}

process.on("SIGTERM", shutdown);
process.on("SIGINT", shutdown);

async function closeDatabasePool() {
  // 예: await pool.end();
}

async function closeQueueConsumers() {
  // 예: await worker.close();
}

이 예시에서 핵심은 isShuttingDown입니다. 종료 신호를 받는 순간 /readyz를 실패로 바꿉니다. 그러면 로드밸런서나 오케스트레이터가 이 인스턴스를 트래픽 대상에서 빼기 시작할 수 있습니다. 동시에 server.close()로 새 연결을 받지 않게 합니다. 처리 중인 요청은 가능한 한 끝내고, DB 풀과 큐 소비자 같은 외부 리소스는 마지막에 닫습니다.

주의할 점도 있습니다. server.close() 콜백 안에서 정리 작업을 시작했는데, 그 작업을 기다리는 Promise가 실제 종료 흐름에 묶이지 않으면 프로세스가 예상보다 빨리 내려갈 수 있습니다. 반대로 타이머나 워커가 남아 있으면 프로세스가 끝나지 않습니다. 그래서 운영 코드에서는 종료 흐름을 테스트로 한 번 재현해 보는 편이 좋습니다.

docker stop --time 30 my-node-api

이 명령으로 컨테이너가 30초 안에 내려가는지, 종료 로그가 남는지, 처리 중 요청이 끊기는지 확인합니다. 로컬에서 이 실험이 안 되면 운영 배포에서는 더 보기 어렵습니다.

readiness와 liveness를 같은 엔드포인트로 두면 장애가 커질 수 있습니다

Kubernetes 문서는 probe를 startup, liveness, readiness로 나눕니다. startup probe는 앱 시작 완료를 확인하고, liveness probe는 컨테이너를 재시작해야 할 정도의 상태를 판단하며, readiness probe는 트래픽을 받을 준비가 됐는지 판단합니다. readiness가 실패하면 서비스의 EndpointSlice에서 해당 Pod가 트래픽 대상에서 빠질 수 있습니다. (출처: Kubernetes - Liveness, Readiness, and Startup Probes)

문제는 이 세 가지를 모두 /health 하나로 묶을 때 생깁니다. DB가 잠깐 느려졌다는 이유로 liveness가 실패하면, 컨테이너가 재시작됩니다. 재시작이 몰리면 남은 인스턴스에 부하가 더 쌓이고, 부하는 다시 헬스체크 실패로 이어질 수 있습니다.

실무에서는 이렇게 나누는 편이 덜 위험합니다.

엔드포인트	용도	실패 기준
`/healthz`	프로세스가 살아 있고 이벤트 루프가 응답 가능한지 확인	앱이 멈췄거나 기본 응답이 불가능할 때
`/readyz`	트래픽을 받아도 되는지 확인	종료 중, DB 연결 불가, 필수 캐시 준비 전
`/startupz`	초기화가 끝났는지 확인	마이그레이션, 캐시 로딩, 설정 로딩 미완료

liveness는 마지막 수단에 가깝게 잡아야 합니다. "잠깐 외부 API가 느리다"는 이유로 프로세스를 죽이면 회복이 아니라 흔들림이 됩니다. 반대로 readiness는 더 민감해도 됩니다. 이 인스턴스가 지금 요청을 처리하기 어렵다면 잠시 트래픽 대상에서 빠지는 것이 낫습니다.

Kubernetes 문서도 liveness probe를 잘못 구현하면 부하 상황에서 컨테이너 재시작이 이어져 장애가 커질 수 있다고 주의합니다. 그래서 liveness는 애플리케이션 자체가 복구 불가능하게 멈췄는지 보는 쪽에 가깝고, 의존성 상태는 readiness로 보내는 편이 운영상 안전합니다. (출처: Kubernetes - Liveness probe caution)

Docker HEALTHCHECK와 ECS 헬스체크는 같은 말처럼 보이지만 위치가 다릅니다

Dockerfile의 HEALTHCHECK는 컨테이너 내부에서 명령을 실행해 컨테이너 상태를 판단합니다. Docker 문서는 health status가 starting, healthy, unhealthy로 변할 수 있고, 실패가 지정 횟수만큼 이어지면 unhealthy가 된다고 설명합니다. --interval, --timeout, --start-period, --retries 같은 옵션도 여기서 정합니다. (출처: Dockerfile reference - HEALTHCHECK)

ECS를 쓰는 팀이라면 한 가지를 더 알아야 합니다. Amazon ECS 문서는 task definition에 지정한 컨테이너 헬스체크만 모니터링하고 보고한다고 설명합니다. 이미지에 들어 있는 Docker health check가 있더라도 ECS task definition에 지정되지 않았다면 ECS가 그것을 그대로 모니터링하는 구조가 아닙니다. 또한 task definition의 헬스체크 파라미터는 이미지에 있는 Docker health check를 override할 수 있습니다. (출처: Amazon ECS - Determine task health using container health checks)

이 차이를 모르고 Dockerfile에만 HEALTHCHECK를 넣으면 "로컬에서는 healthy인데 ECS에서는 배포 판단에 반영되지 않는" 상황이 생길 수 있습니다. 반대로 ECS task definition에도 같은 기준을 넣으면, 배포 플랫폼이 컨테이너 상태를 더 명확히 볼 수 있습니다.

작은 Node.js API라면 시작점은 아래 정도로 충분합니다.

HEALTHCHECK --interval=30s --timeout=3s --start-period=20s --retries=3 \
  CMD node -e "fetch('http://127.0.0.1:3000/healthz').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))"

다만 이 명령에도 트레이드오프가 있습니다. Node.js 런타임을 매번 띄우는 방식이라 아주 촘촘한 간격에는 부담이 될 수 있습니다. 이미지에 curl이나 wget이 없다면 이런 식으로 시작할 수 있지만, 운영에서는 컨테이너 크기, 실행 비용, 헬스체크 주기를 같이 봐야 합니다.

종료 제한 시간은 플랫폼과 코드가 같은 숫자를 보고 있어야 합니다

Kubernetes의 Pod 종료 흐름은 일반적으로 컨테이너 런타임이 프로세스 1에 TERM 신호를 보내고, grace period가 지난 뒤 남은 프로세스에 KILL 신호를 보내는 방식입니다. 기본 graceful delete는 30초 안에서 동작하며, terminationGracePeriodSeconds로 조정할 수 있습니다. (출처: Kubernetes - Pod termination)

ECS도 비슷한 관점으로 봐야 합니다. AWS ECS 문서는 stop signal 이후 애플리케이션이 종료하지 않으면 SIGKILL이 보내지며, EC2 기반 ECS에서는 ECS_CONTAINER_STOP_TIMEOUT 기본값이 30초라고 설명합니다. 로드밸런서 connection draining을 다루는 ECS 문서도 애플리케이션이 SIGTERM을 받아 새 요청을 멈추고 진행 중 요청을 끝내는 방향을 안내합니다. (출처: Amazon ECS - Optimize load balancer connection draining parameters)

여기서 자주 생기는 실수는 코드의 강제 종료 타이머가 플랫폼보다 길다는 것입니다. 예를 들어 Kubernetes terminationGracePeriodSeconds가 30초인데 애플리케이션 코드의 force timeout을 60초로 잡으면, 코드가 직접 정리하기 전에 플랫폼이 먼저 프로세스를 죽일 수 있습니다. 앱 로그에는 "정상 종료 완료"가 남지 않고, DB 커넥션이나 큐 작업도 중간 상태로 남을 수 있습니다.

나는 보통 이렇게 맞춥니다.

플랫폼 grace period: 30초라면 애플리케이션 force timeout은 25초 안팎으로 둔다.
로드밸런서 deregistration delay: 평소 요청 시간이 짧은 서비스와 업로드/스트리밍 서비스는 따로 잡는다.
readiness 실패 전환: SIGTERM을 받는 즉시 내려간다.
배치/큐 워커: HTTP 서버보다 더 긴 정리 시간이 필요할 수 있으므로 별도 컨테이너나 별도 stop timeout을 검토한다.

숫자는 서비스마다 달라질 수 있습니다. 핵심은 "코드는 60초를 기다리는데 플랫폼은 30초에 죽인다" 같은 엇갈림을 없애는 것입니다.

배포 중 502를 줄이는 점검 순서

graceful shutdown 문제는 한 번에 완벽하게 고치려 하면 범위가 커집니다. 나는 보통 아래 순서로 확인합니다.

종료 신호 로그를 남긴다.
SIGTERM received 로그가 배포 때 찍히는지 확인합니다. 안 찍히면 Dockerfile, ENTRYPOINT, 프로세스 관리자부터 봅니다.
/readyz를 별도로 만든다.
종료 중에는 503을 반환하게 둡니다. /healthz와 같은 응답을 쓰지 않습니다.
server.close()를 호출한다.
새 연결을 막고 기존 요청이 끝날 기회를 줍니다. 오래 붙는 연결이 있다면 WebSocket, SSE, 업로드 경로를 따로 점검합니다.
정리 작업에 제한 시간을 둔다.
DB 풀, 큐 소비자, cron성 타이머를 닫습니다. 플랫폼 grace period보다 짧은 force timeout을 둡니다.
헬스체크 위치를 맞춘다.
Dockerfile, ECS task definition, Kubernetes probe 중 실제 배포 플랫폼이 보는 설정을 확인합니다.
배포 중 트래픽으로 재현한다.
로컬 docker stop만으로는 부족합니다. 스테이징에서 요청을 계속 보내며 rolling deploy를 실행해 5xx, 지연, 중복 처리 여부를 봅니다.

이 순서는 화려하지 않지만 문제를 빨리 좁힙니다. 운영 사고 때 "로드밸런서가 이상하다"와 "Node.js가 종료 신호를 무시한다"는 전혀 다른 문제입니다. 신호, readiness, 서버 종료, 강제 종료 시간을 분리하면 원인 후보가 줄어듭니다.

이런 경우에는 graceful shutdown만으로 부족합니다

모든 중단 문제가 graceful shutdown 코드로 해결되는 것은 아닙니다. 특히 아래 경우에는 더 넓게 봐야 합니다.

긴 파일 업로드나 스트리밍 요청이 많다.
WebSocket처럼 연결이 오래 유지된다.
큐 작업이 한 번 시작되면 수십 초 이상 걸린다.
같은 요청이 두 번 실행되면 데이터가 꼬인다.
DB migration이 배포와 동시에 실행된다.

이런 서비스는 종료 코드만 고쳐서는 부족합니다. 요청 단위 idempotency, 작업 재개 설계, drain 기간, 배포 전후 migration 순서가 같이 필요합니다. 예를 들어 주문 생성 API라면 graceful shutdown보다 먼저 중복 요청 방지 키를 봐야 할 수 있습니다. 컨테이너가 아무리 우아하게 내려가도, 클라이언트가 재시도한 요청을 서버가 두 번 처리하면 운영 문제는 그대로 남습니다.

Node.js API 서버와 큐 워커를 같은 프로세스에 묶어 둔 경우도 조심해야 합니다. HTTP 요청은 빨리 내려가야 하는데 큐 작업은 끝까지 처리해야 한다면 종료 기준이 충돌합니다. 이때는 프로세스나 컨테이너를 분리하는 편이 더 단순할 수 있습니다.

작은 팀에서 바로 적용할 체크리스트

Dockerfile의 CMD 또는 ENTRYPOINT가 exec form이거나, 쉘 스크립트 마지막에 exec를 사용한다.
Node.js에서 SIGTERM과 SIGINT를 모두 받아 같은 종료 흐름으로 보낸다.
종료 신호를 받으면 즉시 readiness 응답이 실패한다.
server.close()로 새 연결을 막고 진행 중 요청을 마무리한다.
DB 풀, Redis 연결, 큐 소비자, 타이머를 닫는 코드가 있다.
애플리케이션 force timeout이 플랫폼 grace period보다 짧다.
liveness는 프로세스 생존, readiness는 트래픽 수신 가능 상태를 본다.
ECS를 쓴다면 task definition의 health check가 실제 배포 판단에 반영되는지 확인한다.
Kubernetes를 쓴다면 startup/readiness/liveness probe 역할이 섞이지 않았는지 본다.
스테이징에서 배포 중 요청을 보내며 5xx와 중단 요청을 확인했다.

마지막으로 하나만 고른다면 /readyz와 SIGTERM 로그부터 넣겠습니다. 배포 중 인스턴스가 언제 트래픽 대상에서 빠지는지, 종료 신호가 앱까지 도착하는지 알 수 있어야 다음 원인을 찾을 수 있습니다. graceful shutdown은 멋진 운영 패턴이 아니라, 컨테이너가 내려가는 30초 동안 사용자의 요청을 어디까지 지켜줄지 정하는 약속입니다.

출처

지난주 테크 뉴스 핵심 정리: Gemini 전환, AI 보안, Cloud Run 고가용성

Lovizu — Mon, 10 Aug 2026 15:03:27 +0900

지난주 테크 뉴스 핵심 정리: Gemini 전환, AI 보안, Cloud Run 고가용성

지난주 테크 뉴스는 "새 AI 기능이 하나 더 나왔다"보다 조금 더 실무적인 쪽으로 움직였습니다. Google Assistant는 Gemini로 넘어가는 일정이 더 구체적으로 보였고, Microsoft는 보안 운영을 agentic workflow로 재설계하겠다는 메시지를 밀었습니다. Cloud Run은 서버리스 서비스도 다중 리전 장애 대응을 더 진지하게 다뤄야 한다는 신호를 냈습니다.

2026-08-03부터 2026-08-09까지의 흐름을 한 문장으로 묶으면 이렇습니다. AI는 제품 안으로 더 깊게 들어오고 있고, 개발팀은 기능보다 운영 경계와 전환 비용을 먼저 계산해야 합니다. 이번 글은 뉴스 제목을 따라가는 대신, 작은 개발팀이나 사내 플랫폼 담당자가 이번 주에 실제로 확인할 지점을 중심으로 정리합니다.

최종 업데이트: 2026-08-10
작성 관점: BLOA Researcher 브리프와 공식 발표, 공식 문서, 주요 보도를 기준으로 정리했습니다. 단일 출처 항목과 아직 공개 문서가 부족한 정책 항목은 본문에서 따로 표시했습니다.

한눈에 보는 지난주 테크 뉴스

지난주(2026-08-03 ~ 2026-08-09)의 핵심은 플랫폼 전환과 운영 자동화였습니다. Google 생태계에서는 Assistant에서 Gemini로 넘어가는 흐름이 Android Auto, 헤드폰, 차량 문서까지 넓어졌습니다. Microsoft의 Project Perception은 public preview에 들어갔고, Cloud Run은 service health 기반의 cross-region failover를 전면에 내세웠습니다.

오픈소스 쪽에서는 AI 코딩을 "모델에게 맡기는 일"이 아니라 절차, 기억, 리뷰, 보안 규칙까지 묶어 운영하려는 저장소들이 GitHub Trending에서 눈에 띄었습니다. 정책 면에서는 White House의 frontier AI 검토 프레임워크 관련 보도가 이어졌지만, 세부 기준은 아직 공개 문서로 확인하기 어렵습니다.

이번 주 요약

Google Assistant에서 Gemini로 전환: Android, Auto, 헤드폰, 차량 경험까지 Gemini 기준으로 재정리되는 흐름이 뚜렷해졌습니다.
Microsoft Project Perception public preview: 보안 AI가 탐지 보조를 넘어 red/blue/green team agent 구조로 확장되고 있습니다.
Cloud Run service health와 자동 failover: 서버리스도 readiness probe, load balancer, 데이터 계층까지 묶어 고가용성을 설계해야 할 단계입니다.
AI 개발 에이전트 오픈소스 부상: ECC, speech-to-speech, open-code-review는 모델 성능보다 운영 체계와 검증 흐름을 보여 줍니다.
White House frontier AI 정책 보도: 공개 원문이 부족하므로, 출시 일정에 바로 반영하기보다 규제 방향의 관전 포인트로 보는 편이 안전합니다.

1. Google Assistant에서 Gemini로, 이제 전환 비용을 계산해야 합니다

무슨 일이 있었나

Google 지원 문서 전반에서 Gemini가 Google Assistant를 대체하거나 함께 쓰이는 흐름이 더 분명해졌습니다. Android Auto 도움말은 "Gemini is replacing Google Assistant on most mobile devices"라고 안내하고, Gemini가 기존 명령을 이해하면서 더 자연스러운 대화도 지원한다고 설명합니다. 자동차, 헤드폰, Pixel, Gemini 앱 도움말도 Gemini와 Assistant의 역할을 새 기준으로 정리하고 있습니다.

The Verge는 2026-08-05 보도에서 Google이 2026-09-04부터 Android phones, tablets, 일부 연결 기기에서 Assistant 접근 제거를 시작한다고 전했습니다. 다만 이 날짜와 제거 범위는 보도 기준으로 다루는 편이 안전합니다. Google 공식 도움말은 전환 방향과 2026년 중 세부 안내를 말하지만, 모든 기기와 지역에 같은 속도로 적용된다고 단정하기는 어렵습니다.

왜 중요한가

사용자 입장에서는 음성 비서 이름이 바뀌는 문제처럼 보일 수 있습니다. 개발팀 관점에서는 다릅니다. 기존 Assistant는 비교적 정해진 명령과 액션 중심이었지만, Gemini는 더 대화형 경험을 전제로 합니다. 앱이 음성 호출, 메시지 처리, 차량 내 작업, 헤드폰 인터랙션과 연결돼 있다면 "명령어가 잘 먹히는가"보다 "대화 흐름에서 사용자가 길을 잃지 않는가"를 봐야 합니다.

한국 서비스 팀이라면 당장 모든 UX를 갈아엎을 필요는 없습니다. 대신 Android 사용자 문의가 늘어날 수 있는 지점을 먼저 정리해야 합니다. 예를 들어 "예전에는 되던 음성 명령이 안 된다", "차에서 Gemini와 Assistant가 다르게 동작한다", "잠금 화면에서는 왜 반응이 다른가" 같은 질문은 제품 기능보다 지원 문서와 고객 응대 품질에서 먼저 차이가 납니다.

실무자가 확인할 것

Android 앱이나 웨어러블, 차량 연동 기능이 있다면 Assistant 전제의 도움말 문구를 Gemini 기준으로 점검하세요.
음성 명령 테스트 케이스를 단순 명령형과 대화형 요청으로 나눠 다시 만들어 보세요.
지역, 언어, 기기별 전환 속도가 다를 수 있으므로 고객 안내에는 "모든 사용자에게 동시에 적용"처럼 쓰지 않는 편이 안전합니다.

원문/공식 링크

공식 문서: Android Auto Help — Talk to Gemini or Google Assistant
공식 문서: Gemini Apps Help — Use Gemini on your headphones
공식 문서: Cars with Google built-in Help — Set up Gemini or Google Assistant for your car
제품/문서: Pixel Help — What you can do with your Gemini mobile app
참고 보도: The Verge — Google Assistant will disappear from your phone next month

2. Microsoft Project Perception, 보안 AI는 권한 설계가 먼저입니다

무슨 일이 있었나

Microsoft는 2026-07-27 공식 블로그에서 agentic security를 위한 새 cyber stack과 Project Perception을 소개했습니다. 발표일은 7월 말이지만, public preview 시작일이 2026-08-03으로 명시돼 이번 주 실무 이슈에 들어옵니다. Microsoft는 Project Perception을 signals, context, models, specialized agents를 묶어 보안 위험을 계속 이해하고 대응하는 시스템으로 설명했습니다.

구조도 흥미롭습니다. Microsoft는 red team agents, blue team agents, green team agents가 각각 공격 경로 식별, 위험 판단, 교정 조치를 맡는 형태를 제시했습니다. 여기에 MAI-Cyber-1-Flash 같은 보안 특화 모델을 적용해 특정 취약점 관리 시나리오에서 자체 벤치마크 성과와 비용 절감을 설명했습니다.

왜 중요한가

보안 AI를 볼 때 숫자만 보면 판단이 쉬워 보입니다. 성능이 높고 비용이 낮다면 도입하면 될 것 같기 때문입니다. 하지만 실제 운영에서는 다른 질문이 먼저 나옵니다. 에이전트가 어떤 로그를 볼 수 있는지, 어디까지 조치할 수 있는지, 사람 승인은 언제 들어가는지, 잘못된 차단을 어떻게 되돌리는지가 더 중요합니다.

작은 팀이라면 특히 조심해야 합니다. 보안 담당자가 한두 명인 조직에서 자동 조치가 늘어나면 대응 속도는 빨라질 수 있지만, 권한과 복구 절차가 흐리면 장애 대응이 더 어려워질 수 있습니다. 저는 이런 도구를 검토할 때 "얼마나 똑똑한가"보다 "실수했을 때 멈출 수 있는가"를 먼저 봅니다.

실무자가 확인할 것

보안 AI 검토표에 탐지 성능, 조치 권한, 사람 승인, 감사 로그, 롤백 절차를 분리해 넣으세요.
public preview 기능은 가격, 가용 리전, 데이터 보관 조건, 제품별 통합 범위를 다시 확인해야 합니다.
자체 발표의 벤치마크 수치는 그대로 우리 조직의 성능으로 받아들이지 말고, 실제 로그와 공격 시나리오로 재검증해야 합니다.

원문/공식 링크

공식 발표: Microsoft Official Blog — Rethinking security for the age of AI
제품/문서: Microsoft Security
참고 자료: Microsoft Security Blog

3. Cloud Run service health, 서버리스도 장애 설계를 피할 수 없습니다

무슨 일이 있었나

Google Cloud는 Cloud Run multi-region services와 service health를 활용한 고가용성 구성을 공식 블로그와 문서에서 강조했습니다. 블로그는 2026-07-20에 공개됐지만, 지난주 Researcher 브리프 기준으로 Cloud Run service health와 automated cross-region failover 문서가 실무자 사이에서 다시 주목됐습니다.

핵심은 readiness probe와 service health입니다. Cloud Run은 readiness probe로 인스턴스 수준 상태를 확인하고, service health는 각 리전의 서비스 상태를 집계합니다. 이 상태가 serverless NEG를 통해 load balancer와 연결되면, unhealthy region에서 healthy region으로 트래픽을 자동으로 피할 수 있습니다.

왜 중요한가

서버리스는 운영을 줄여주지만 장애 설계를 없애주지는 않습니다. Cloud Run 서비스가 여러 리전에 떠 있어도, 데이터베이스가 한 리전에만 있거나 readiness probe가 실제 장애를 잘 못 잡으면 failover는 기대만큼 동작하지 않습니다. Google Cloud 문서도 public internet과 private network 구성에 따라 외부 또는 내부 application load balancer를 나눠 봐야 한다고 설명합니다.

중소 규모 팀에서는 "멀티리전"이라는 말이 과하게 들릴 수 있습니다. 그래도 결제, 인증, 알림, 외부 API webhook처럼 멈추면 바로 고객 문의가 오는 경로는 다릅니다. 전체 서비스를 한 번에 다중 리전으로 만들기보다, 끊기면 곤란한 endpoint부터 readiness probe와 장애 시나리오를 정리하는 편이 현실적입니다.

실무자가 확인할 것

Cloud Run 서비스를 쓰고 있다면 readiness probe가 단순 200 OK가 아니라 실제 의존성 상태를 적절히 반영하는지 확인하세요.
public internet 서비스인지 private network 서비스인지에 따라 load balancer 구성을 구분하세요.
애플리케이션 tier만 다중 리전으로 만들지 말고 데이터 계층의 replication, RPO, data residency 조건도 같이 점검하세요.

원문/공식 링크

공식 발표: Google Cloud Blog — Making highly available, multi-region Cloud Run services just got easier
공식 문서: Google Cloud Documentation — Automate cross-region failover with Cloud Run service health
제품/문서: Google Cloud — Cloud Run documentation

4. GitHub Trending 오픈소스, AI 코딩은 절차 싸움으로 넘어가고 있습니다

무슨 일이 있었나

지난주 GitHub Trending에서는 AI 개발 에이전트와 리뷰 자동화 흐름을 보여 주는 저장소들이 눈에 띄었습니다. affaan-m/ECC는 coding agent를 위한 engineering system과 toolbox를 표방합니다. README 기준으로 plan, test, implement, review, verify, remember 같은 절차를 묶어 여러 coding harness에서 쓰는 구조를 제시합니다.

Hugging Face의 speech-to-speech는 로컬 음성 에이전트 파이프라인을 실험할 수 있는 저장소입니다. 음성 감지, STT, LLM, TTS를 조합해 voice agent를 만들려는 팀에 실험 출발점을 제공합니다. Alibaba의 open-code-review는 deterministic pipeline과 LLM Agent를 섞어 코드 리뷰를 수행하는 CLI로, 파일 선택과 룰 기반 검사는 절차화하고 의미 판단은 LLM에 맡기는 방향을 보여 줍니다.

왜 중요한가

AI 코딩 도구를 써보면 처음에는 "어떤 모델이 코드를 더 잘 쓰나"에 관심이 갑니다. 몇 달 지나면 질문이 바뀝니다. 누가 요구사항을 정리하고, 어떤 테스트로 확인하며, 리뷰 결과를 어디에 남기고, 실패한 패턴을 다음 작업에 어떻게 반영할지가 더 중요해집니다. 이번에 주목받은 저장소들은 그 흐름을 잘 보여 줍니다.

소규모 개발팀에서도 바로 배울 지점이 있습니다. 거창한 agent platform을 들이지 않아도 AGENTS.md, 리뷰 체크리스트, 반복 작업 템플릿, 테스트 기준, 메모리 규칙을 정리하면 AI 도구의 품질이 달라집니다. 반대로 그런 기준 없이 모델만 바꾸면, 그때그때 괜찮은 답은 나오지만 팀의 개발 방식으로 쌓이지 않습니다.

실무자가 확인할 것

AI 코딩 도구를 쓰고 있다면 프롬프트보다 먼저 작업 절차, 검증 명령, 리뷰 기준, 금지 작업을 문서화하세요.
오픈소스 agent 도구를 들여올 때는 라이선스, 권한, secret 접근, hook 동작, 저장소 쓰기 범위를 먼저 확인해야 합니다.
음성 에이전트 PoC는 모델 품질만 보지 말고 지연 시간, 하드웨어 요구사항, 개인정보 처리 위치를 함께 봐야 합니다.

원문/공식 링크

공식 저장소: GitHub — affaan-m/ECC
공식 저장소: GitHub — huggingface/speech-to-speech
공식 저장소: GitHub — alibaba/open-code-review
인기 반응: GitHub Trending

5. White House frontier AI 보도, 아직은 정책 관전 포인트로 봐야 합니다

무슨 일이 있었나

지난주에는 미국 행정부가 OpenAI, Google, Anthropic 등 주요 AI 기업과 frontier AI 사전 검토 프레임워크를 논의했다는 보도가 이어졌습니다. 다만 이번 주 기준으로 그 세부 프레임워크 원문이 공개 문서로 확인되지는 않았습니다. 공개적으로 확인 가능한 1차 자료는 2026-06-05 White House의 국가안보 AI 관련 fact sheet와 NSPM-11입니다.

보도에서는 closed frontier model과 open-weight model의 취급 차이도 언급됐습니다. 하지만 이 부분은 보도 기준입니다. "open model은 완전히 제외된다"처럼 확정적으로 쓰기에는 공개 근거가 부족합니다.

왜 중요한가

미국 AI 정책은 미국 기업만의 문제가 아닙니다. 대형 모델 공급사의 출시 일정, red team 절차, 평가 문서, enterprise 계약 조건이 바뀌면 한국 기업도 영향을 받습니다. 특히 미국 모델 API를 쓰는 팀은 기능 출시가 늦어지거나, 특정 고위험 기능에 추가 검토가 붙는 상황을 만날 수 있습니다.

그렇다고 이번 보도를 보고 당장 제품 계획을 바꿀 필요는 없습니다. 아직은 세부 문서가 없는 상태입니다. 실무적으로는 모델 공급사 status page, safety 문서, enterprise 약관 변경, API release note를 같이 보는 정도가 적당합니다.

실무자가 확인할 것

frontier model API에 의존하는 기능은 공급사별 release note와 safety policy 변경을 추적하세요.
정책 보도만 보고 출시 일정을 확정하지 말고, 공식 문서나 계약 변경이 나오는지 기다리세요.
regulated industry 고객에게 AI 기능을 제공한다면 모델 평가, 감사 로그, human review 절차를 미리 문서화하는 편이 좋습니다.

원문/공식 링크

공식 자료: White House — Fact Sheet: Historic Directive on AI in the National Security Enterprise
공식 자료: White House — National Security Presidential Memorandum/NSPM-11
공식 자료: White House — National AI Legislative Framework
참고 보도: Axios — Inside Trump's AI framework

이번 주에 이어서 볼 것

Google Assistant 제거 일정의 공식 문서화: 2026-09-04 시작 날짜와 기기별 적용 범위가 Google 공식 안내로 더 명확해지는지 봐야 합니다.
Project Perception preview 세부 조건: 가격, 가용 리전, 로그 보관, 사람 승인 흐름이 문서로 얼마나 공개되는지 확인할 필요가 있습니다.
Cloud Run multi-region 운영 사례: service health만으로 충분한지, 데이터 계층과 external dependency까지 포함한 장애 후기가 나오는지 봐야 합니다.
AI agent 도구의 보안 기준: hook, secret scanning, 저장소 쓰기 권한을 어디까지 제한하는지가 도입 판단의 핵심이 될 가능성이 큽니다.
frontier AI 정책 원문 공개 여부: 보도와 실제 정책 문서 사이의 차이를 구분해야 합니다.

마무리

지난주의 흐름은 AI가 더 똑똑해졌다는 이야기보다, AI가 들어가는 자리가 넓어졌다는 이야기였습니다. 모바일 assistant, 보안 운영, 서버리스 장애 대응, 코드 리뷰, 음성 에이전트까지 모두 같은 질문으로 이어집니다. 이 기능을 켰을 때 누가 책임지고, 어디까지 자동화하며, 실패하면 어떻게 되돌릴 것인가.

이번 주에 바로 할 일은 새 도구를 설치하는 것이 아닙니다. Android 연동 제품이 있다면 Gemini 전환 안내를 점검하고, Cloud Run을 쓴다면 readiness probe와 failover 전제를 확인하세요. AI 코딩 도구를 팀에서 쓰고 있다면 모델 이름보다 작업 절차와 리뷰 기준을 먼저 적어두는 편이 훨씬 오래 갑니다.

출처

개학 전 생활 리듬, 마지막 7일에 되돌리는 가족 루틴

Lovizu — Sat, 8 Aug 2026 22:22:13 +0900

개학 전 생활 리듬, 마지막 7일에 되돌리는 가족 루틴

방학이 끝나갈 때 부모가 가장 먼저 떠올리는 건 밀린 숙제입니다. 그런데 막상 개학 첫 주에 더 크게 흔들리는 건 숙제보다 생활 리듬인 경우가 많습니다. 밤에는 잠이 안 오고, 아침에는 일어나지 못하고, 책가방은 전날 밤에야 뒤집어엎습니다.

개학 준비는 아이를 갑자기 부지런하게 만드는 일이 아닙니다. 마지막 7일 동안 잠드는 시간, 아침에 움직이는 순서, 화면을 끄는 기준, 준비물 위치를 조금씩 되돌리는 작업에 가깝습니다. 공부 계획을 더 얹기 전에 집 안의 시간표부터 학교 쪽으로 천천히 당겨야 합니다.

3줄 요약

개학 전 마지막 7일은 수면 시간, 아침 동선, 미디어 규칙, 준비물 위치 네 가지를 먼저 맞추는 기간입니다.

잠자는 시간을 하루 만에 1-2시간 앞당기기보다, 매일 15-30분씩 당기는 편이 현실적입니다.

아이 혼자 바꾸라고 하기보다 가족의 저녁 소음, 화면 사용, 아침 준비 순서를 같이 조정해야 오래 갑니다.

최종 업데이트: 2026-08-08

작성 관점: 이 글은 방학에서 개학으로 넘어가는 초등·중등 가정의 생활 루틴을 정리한 생활형 가이드입니다. 수면 문제나 건강 문제를 진단하는 글이 아니며, 지속적인 불면·과도한 피로·등교 거부처럼 일상 조정으로 해결하기 어려운 상황은 학교 상담 교사나 의료 전문가와 상의하는 편이 안전합니다.

먼저 결론: 공부보다 잠과 아침을 먼저 맞춥니다

개학 준비를 "밀린 공부 따라잡기"로만 잡으면 첫 주가 피곤해집니다. 방학 동안 늦게 자고 늦게 일어나는 흐름이 굳어졌다면, 문제집 한 권보다 기상 시간이 먼저입니다. 아침에 몸이 일어나지 않으면 등교 준비, 아침 식사, 숙제 확인이 전부 싸움으로 바뀝니다.

마지막 7일에 볼 것은 네 가지입니다.

먼저 맞출 것	현실적인 기준	미루면 생기는 일
잠드는 시간	하루 15-30분씩 앞당기기	개학 첫 주 아침 기상 실패
아침 동선	씻기, 옷, 식사, 가방 순서 고정	매일 같은 말 반복
미디어 사용	잠들기 전 화면 끄는 시간 정하기	취침 지연, 가족 갈등
준비물 위치	책가방·실내화·알림장 자리 고정	전날 밤 찾기 시작

핵심은 완벽한 계획이 아니라 반복 가능한 순서입니다. 아이가 해야 할 일을 모두 외우게 하는 것보다, 집 안에서 그 순서가 자연스럽게 보이도록 만드는 편이 덜 부딪힙니다.

1일 차: 방학 리듬을 혼내지 말고 먼저 기록합니다

첫날에는 바꾸려고 하기보다 현재 리듬을 봅니다. 아이가 몇 시에 잠드는지, 실제로 잠든 뒤 몇 시에 일어나는지, 아침에 가장 오래 걸리는 일이 무엇인지 적어보세요. 부모 기억만 믿으면 "맨날 늦게 자잖아" 같은 말로 흐르기 쉽습니다.

기록은 복잡할 필요가 없습니다.

잠자리에 들어간 시간
실제로 불을 끄고 조용해진 시간
아침에 일어난 시간
아침 준비에서 막힌 지점
화면을 끄기로 한 시간과 실제로 끈 시간

이렇게 보면 문제의 모양이 보입니다. 어떤 집은 잠드는 시간이 늦어서 문제이고, 어떤 집은 잠은 충분히 잤지만 아침 동선이 복잡해서 늦습니다. 원인이 다른데 같은 말로 다그치면 아이도 부모도 지칩니다.

2-3일 차: 잠드는 시간을 조금씩 당깁니다

개학 전 생활 리듬에서 가장 먼저 손볼 것은 취침 시간입니다. CDC는 6-12세 아동은 하루 9-12시간, 13-18세 청소년은 8-10시간의 수면이 권장된다고 안내합니다. 수면 필요량은 아이마다 다르지만, 등교 시간이 정해져 있다면 거꾸로 계산해야 합니다. (출처: CDC - About Sleep)

예를 들어 7시에 일어나야 하는 초등학생이라면, 잠드는 시간이 밤 11시를 넘는 루틴은 개학 첫 주에 부담이 큽니다. 그렇다고 오늘부터 무조건 9시에 자라고 하면 대개 실패합니다. 방학 동안 늦어진 리듬은 몸이 바로 따라오지 않기 때문입니다.

현실적인 방법은 하루 15-30분씩 앞당기는 것입니다.

1일 차: 현재 잠드는 시간 기록
2일 차: 불 끄는 시간 15-30분 앞당기기
3일 차: 저녁 간식과 샤워 시간을 함께 앞당기기
4일 차 이후: 기상 시간도 15-30분씩 학교 시간에 맞추기

여기서 부모가 놓치기 쉬운 지점이 있습니다. 아이만 일찍 자라고 해도 거실 TV 소리, 부모의 휴대폰 소리, 늦은 야식 분위기가 그대로면 잠자리로 가기 어렵습니다. 개학 전 1주일만큼은 가족 전체의 밤 소리를 조금 낮추는 편이 효과가 큽니다.

4일 차: 아침 준비를 말이 아니라 순서로 만듭니다

아침마다 "빨리 씻어", "옷 입어", "가방 챙겨"를 반복하고 있다면 아이가 게을러서만은 아닐 수 있습니다. 순서가 매일 달라지면 아이는 매번 새로 판단해야 합니다. 방학에는 그 판단을 늦게 해도 괜찮지만, 등교일에는 시간이 없습니다.

아침 순서는 짧아야 합니다. 아이 방 문이나 냉장고에 붙일 정도로만 줄이세요.

일어나서 화장실
세수와 양치
옷 입기
아침 먹기
책가방 들고 현관

집마다 순서는 달라도 됩니다. 중요한 건 매일 같은 순서로 가는 것입니다. 체크표를 만들 때도 "착하게 준비하기" 같은 추상적인 표현보다 "양치", "양말", "물통"처럼 눈에 보이는 행동으로 적어야 합니다.

초등 저학년이라면 글자보다 그림이나 작은 아이콘이 더 잘 맞을 수 있습니다. 중학생 이상이라면 부모가 붙여주는 표보다 휴대폰 알람이나 달력 앱이 나을 때도 있습니다. 나이에 맞는 도구를 쓰되, 아침에 새로 협상하지 않게 만드는 것이 목표입니다.

5일 차: 화면을 끊는 대신 꺼지는 시간을 정합니다

방학이 끝날 때 가장 많이 부딪히는 주제가 영상과 게임입니다. "이제 그만해"는 거의 항상 싸움으로 이어집니다. 아이 입장에서는 재미있는 걸 갑자기 빼앗기는 느낌이고, 부모 입장에서는 개학이 코앞인데 계속 화면만 보는 것처럼 보입니다.

미국소아과학회(AAP)는 가족마다 루틴과 가치가 다르기 때문에, 한 가지 시간 제한만 밀어붙이기보다 가족에게 맞는 미디어 계획을 세우라고 안내합니다. 특히 식사 시간, 숙제 시간, 잠들기 전처럼 화면을 비우는 구역과 시간을 정하는 방식이 실용적입니다. (출처: HealthyChildren.org - How to Make a Family Media Plan)

개학 전 7일에는 화면 시간을 갑자기 0으로 만들 필요가 없습니다. 대신 꺼지는 시간을 정하세요.

잠들기 1시간 전에는 긴 영상과 게임을 끝낸다
자동재생과 알림은 꺼둔다
충전기는 침대 옆이 아니라 거실이나 책상 쪽에 둔다
부모도 같은 시간대에는 큰 화면 소리를 줄인다

아이에게는 "왜 안 돼"보다 "언제까지는 돼"가 더 이해하기 쉽습니다. 예를 들어 "8시 30분까지 보고, 그다음에는 충전 자리에 둔다"처럼 끝나는 시간을 숫자로 말하세요. 규칙이 짧을수록 지킬 가능성이 올라갑니다.

6일 차: 책가방은 전날 밤이 아니라 낮에 한 번 엽니다

개학 전날 밤에 책가방을 처음 열면 꼭 하나가 없습니다. 실내화가 작아졌거나, 필통에 연필이 없거나, 알림장과 준비물이 다른 곳에 있습니다. 이때 부모도 조급해져서 말이 날카로워집니다.

가방 점검은 개학 전날 밤보다 하루나 이틀 앞당기는 편이 낫습니다. 낮에 한 번 열어야 필요한 것을 사거나 세탁할 시간이 생깁니다.

확인할 것은 많아 보여도 기본은 정해져 있습니다.

책가방 안에 지난 학기 종이와 쓰레기가 남아 있는지
필통에 연필, 지우개, 자, 색연필 등 기본 도구가 있는지
실내화가 맞고 세탁되어 있는지
물통, 손수건, 마스크 등 학교별 준비물이 필요한지
방학 숙제나 안내장이 따로 제출되어야 하는지

여기서도 부모가 전부 대신 챙기면 개학 뒤에도 같은 일이 반복됩니다. 처음에는 같이 확인하되, 마지막에는 아이가 직접 가방에 넣게 하세요. "네 물건은 네가 책임져"라는 큰 말보다, 손으로 한 번 넣어보는 경험이 더 오래 남습니다.

7일 차: 개학 전날에는 새 규칙을 만들지 않습니다

개학 전날은 큰 결심을 하는 날이 아닙니다. 오히려 새 규칙을 만들수록 불안해집니다. "이제부터 매일 1시간 공부", "스마트폰은 평일 금지", "아침마다 운동" 같은 결심은 첫 주에 부딪히기 쉽습니다.

전날에는 세 가지만 확인하세요.

내일 몇 시에 일어날지
옷과 가방이 어디에 있는지
등교 후 첫 일정이 무엇인지

아이에게도 길게 설명하지 않는 편이 좋습니다. "내일은 7시에 일어나고, 옷은 의자에 있고, 가방은 현관 옆에 있어" 정도면 충분합니다. 긴 훈계는 잠들기 전 긴장만 키웁니다.

부모도 개학 첫날 아침에 모든 것을 완벽하게 만들겠다는 기대를 낮춰야 합니다. 첫 주는 적응 기간입니다. 늦지 않게 나가고, 아이가 학교에 다녀와서 너무 무너지지 않는다면 이미 중요한 부분은 지나간 겁니다.

아이 성향별로 다르게 적용하기

같은 7일 루틴이라도 아이 성향에 따라 강도를 조정해야 합니다.

늦게 자는 아이

취침 시간만 당기지 말고 저녁 활동 전체를 앞당겨야 합니다. 샤워, 간식, 숙제 확인, 화면 종료 시간이 그대로면 잠자리만 빨라져도 잠이 오지 않습니다. 이 경우에는 "9시에 자자"보다 "8시 30분에는 화면을 끄고, 9시에는 방 조명을 낮추자"처럼 앞 단계를 같이 정하세요.

아침에 느린 아이

아침에 해야 할 일을 줄이는 것이 먼저입니다. 옷 고르기, 준비물 찾기, 물통 씻기처럼 전날 할 수 있는 일을 밤에 빼두세요. 아침에는 씻기, 입기, 먹기, 나가기 정도만 남겨야 합니다.

변화에 예민한 아이

개학 이야기를 너무 자주 꺼내면 부담이 커질 수 있습니다. 이런 경우에는 "이제 학교 가야 하니까"보다 "우리 아침을 조금 편하게 만들어보자"처럼 생활의 불편을 줄이는 쪽으로 말하는 편이 낫습니다. 달력에 개학일을 표시하고, 하루에 하나씩만 바꾸세요.

스스로 잘 챙기는 아이

부모가 모든 항목을 관리하려 들면 오히려 잔소리로 들릴 수 있습니다. 체크리스트만 공유하고, 아이가 자기 방식으로 정리하게 두세요. 대신 등교 시간, 취침 기준, 준비물 마감처럼 가족 전체에 영향을 주는 선은 같이 합의합니다.

개학 전 7일 체크리스트

현재 잠드는 시간과 일어나는 시간을 하루 이상 기록했다.
취침과 기상 시간을 하루 15-30분씩 조정하기로 했다.
잠들기 전 화면을 끄는 시간을 숫자로 정했다.
아침 준비 순서를 5단계 안팎으로 줄였다.
옷, 양말, 가방, 물통 위치를 전날 확인하는 방식으로 바꿨다.
책가방과 필통을 개학 전날 밤보다 먼저 열어봤다.
실내화, 준비물, 제출물처럼 시간이 필요한 항목을 따로 확인했다.
개학 전날에는 새 규칙을 추가하지 않기로 했다.

이런 경우에는 루틴보다 상담이 먼저일 수 있습니다

생활 리듬 조정은 대부분의 가정에서 시도해볼 수 있는 방법입니다. 다만 아이가 잠을 거의 못 자거나, 아침마다 심한 복통과 두통을 호소하거나, 학교 이야기에 강한 공포를 보인다면 단순한 루틴 문제로만 보지 않는 편이 안전합니다.

이때는 담임교사, 학교 상담실, 소아청소년과 등 도움을 받을 수 있는 곳과 연결하세요. 부모가 집에서 할 수 있는 조정은 분명히 있지만, 아이의 불안이나 건강 문제가 섞여 있다면 혼자 해결하려고 오래 끌지 않는 것이 낫습니다.

마무리

개학 전 마지막 7일은 아이를 몰아붙이는 시간이 아니라, 학교에 맞는 생활 리듬으로 천천히 돌아오는 시간입니다. 잠드는 시간을 조금 앞당기고, 아침 순서를 고정하고, 화면이 꺼지는 시간을 정하고, 책가방을 미리 열어보는 것만으로 첫 주의 소란은 꽤 줄어듭니다.

이번 주에 하나만 한다면 책가방보다 취침 시간을 먼저 보세요. 아침이 덜 무너지면 준비물도, 숙제도, 등교도 훨씬 차분하게 따라옵니다.

출처

CDC - About Sleep — 연령대별 권장 수면 시간과 수면의 기본 역할 참고. (확인일: 2026-08-08)
CDC - Sleep and Health — 학생 수면과 집중, 학업 수행, 건강의 관련성 참고. (확인일: 2026-08-08)
HealthyChildren.org - How to Make a Family Media Plan — 가족 미디어 계획, 화면 없는 시간과 구역 설정 기준 참고. (확인일: 2026-08-08)

재산세 7월에 냈는데 9월에도 또 나오는 이유

Lovizu — Fri, 7 Aug 2026 17:09:33 +0900

7월에 재산세를 냈는데 9월에 고지서가 한 번 더 오면, 계산이 잘못된 것처럼 느껴질 수 있습니다. 특히 아파트 한 채만 가진 사람이라면 더 그렇습니다. "지난달에 냈는데 왜 또 내지?"라는 생각이 먼저 들죠.

하지만 주택 재산세는 원래 한 해 세액을 7월과 9월에 나눠 내는 구조입니다. 7월 고지서가 전부가 아니라 주택분 1/2일 수 있고, 9월에는 나머지 주택분 1/2이 다시 나옵니다. 토지를 함께 갖고 있다면 9월에는 토지분까지 더해질 수 있습니다.

이 글은 2026년 8월 7일 기준 공개 자료를 바탕으로, 재산세 고지서를 받았을 때 어디를 먼저 봐야 하는지 정리한 생활 금융 가이드입니다. 특정 절세 방법이나 세무 판단을 권하는 글은 아닙니다. 실제 세액과 감면 여부는 관할 지방자치단체 고지서, 위택스, 이택스, 세무 담당 부서에서 최종 확인하는 편이 안전합니다.

최종 업데이트: 2026-08-07

먼저 볼 것은 금액보다 몇 월분입니다

재산세 고지서를 받으면 대부분 금액부터 봅니다. 금액이 크면 놀라고, 작으면 넘어가기 쉽습니다. 그런데 예산을 세울 때는 금액보다 먼저 고지서의 과세대상과 납기를 봐야 합니다.

서울시는 2026년 7월분 재산세 고지 안내에서 재산세가 매년 7월과 9월에 부과된다고 설명했습니다. 7월에는 주택의 절반, 건축물, 선박, 항공기분이 나오고, 9월에는 주택의 나머지 절반과 토지분이 나옵니다. 같은 안내에서 7월분 납부기한은 2026년 7월 31일까지라고 밝혔습니다. (출처: 서울특별시 보도자료 (https://www.seoul.go.kr/news/news_report.do?bbsNo=158&nttNo=461668))

그래서 7월 고지서를 냈다고 해서 올해 재산세가 끝났다고 보면 안 됩니다. 아파트, 빌라, 단독주택처럼 주택을 보유했다면 9월 고지서가 한 번 더 오는 것이 일반적인 흐름입니다. 반대로 상가 건축물만 있다면 7월 한 번으로 끝날 수 있고, 토지만 있다면 9월에 처음 고지될 수 있습니다.

보유한 재산 | 주로 고지되는 달 | 확인할 점

주택 | 7월, 9월 | 연간 세액을 절반씩 나눠 내는지 확인
건축물 | 7월 | 주택과 별도 건축물분인지 확인
토지 | 9월 | 주택 2기분과 함께 나오는지 확인
선박·항공기 | 7월 | 일반 주택 고지서와 구분

고지서가 두 번 온다는 사실보다 더 중요한 것은 내가 7월에 무엇을 냈는가입니다. 주택분 1기분만 냈다면 9월 예산에 비슷한 금액을 한 번 더 잡아두는 편이 낫습니다. 7월 고지서에 건축물분이 함께 있었다면 9월 금액이 7월과 꼭 같지는 않을 수 있습니다.

왜 6월 1일이 계속 나오나

재산세 이야기를 찾다 보면 6월 1일이라는 날짜가 반복해서 나옵니다. 이유는 간단합니다. 재산세는 그해 6월 1일 현재 재산을 사실상 소유한 사람에게 부과되는 세금이기 때문입니다.

국가법령정보센터에 공개된 지방세법 제114조는 재산세의 과세기준일을 매년 6월 1일로 둡니다. 제115조는 주택의 재산세 납기를 7월 16일부터 7월 31일까지 절반, 9월 16일부터 9월 30일까지 나머지 절반으로 정하고 있습니다. (출처: 국가법령정보센터 지방세법 조문정보 (https://law.go.kr/LSW/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1033349659))

이 날짜 때문에 이사나 매매를 한 해에는 헷갈리는 일이 생깁니다. 예를 들어 6월 이후에 집을 팔았더라도, 6월 1일 기준으로 소유자였다면 그해 재산세 고지 대상이 될 수 있습니다. 반대로 6월 2일 이후에 집을 샀다면, 올해 재산세가 매수자에게 바로 나오지 않을 수 있습니다.

다만 실제 거래에서는 잔금일, 등기일, 계약서 특약, 정산 방식이 얽힐 수 있습니다. 이 부분은 블로그 글만 보고 판단할 영역이 아닙니다. 부동산 거래 중이라면 중개사 설명만으로 끝내지 말고, 계약서의 세금 정산 문구와 관할 구청 세무 부서 안내를 함께 확인하는 편이 안전합니다.

7월에 냈는데 9월 고지서가 또 오는 대표 상황

가장 흔한 경우는 주택 보유자입니다. 주택분 재산세는 한 해 치를 두 번에 나눠 내기 때문에, 7월에 한 번 내고 9월에 또 내는 구조가 자연스럽습니다. 7월 고지서가 "올해 전체 세금"처럼 보이지만 실제로는 절반일 수 있습니다.

두 번째는 주택과 토지를 함께 갖고 있는 경우입니다. 9월에는 주택 2기분뿐 아니라 토지분 재산세도 나올 수 있습니다. 부모님에게서 물려받은 토지, 작은 지분으로 가진 토지, 상가 부속 토지처럼 평소에 잘 의식하지 않는 재산이 있다면 9월 고지서 금액이 예상보다 커질 수 있습니다.

세 번째는 공동명의입니다. 공동명의 부동산은 지분에 따라 각각 고지될 수 있어 한 사람의 앱 화면만 보면 전체 흐름을 놓치기 쉽습니다. 부부 공동명의라면 각자 위택스나 이택스에서 조회해 보는 것이 좋습니다.

제가 가계 예산을 볼 때 재산세는 갑자기 생긴 지출로 두지 않습니다. 매년 반복되는 지출이라면 12개월로 나눠 월 예산에 넣는 편이 덜 흔들립니다. 7월에 40만 원, 9월에 40만 원이 나온다면 매달 약 6만7천 원을 따로 빼두는 식입니다. 금액이 정확히 같지 않아도, 여름마다 카드값과 생활비가 동시에 흔들리는 일은 줄어듭니다.

고지서를 받으면 이 순서로 확인하세요

재산세는 복잡해 보이지만 고지서에서 확인할 순서는 길지 않습니다. 금액만 보고 바로 납부하기보다, 아래 네 가지를 먼저 보면 9월 예산까지 같이 잡을 수 있습니다.

1. 과세대상을 봅니다. 주택인지, 건축물인지, 토지인지 확인합니다.
2. 납기를 봅니다. 7월분인지 9월분인지 확인합니다.
3. 주택분 1기분/2기분 표시를 봅니다. 7월에 절반만 낸 것인지 확인합니다.
4. 전자납부번호와 관할 자치단체를 확인합니다. 납부와 문의에 필요합니다.

이 네 가지를 보면 "왜 또 나왔는지"가 대부분 정리됩니다. 7월 고지서가 주택분 1기분이었다면 9월분을 기다려야 하고, 9월 고지서에 토지분이 포함되어 있다면 보유 토지 내역을 확인해야 합니다.

고지서를 잃어버렸다면 다시 발급받거나 온라인으로 조회하면 됩니다. 전국 지방세는 위택스에서 조회·납부할 수 있고, 서울시 지방세는 이택스·스택스 안내가 함께 제공됩니다. 서울시는 2026년 7월 재산세 보도자료에서 인터넷, 모바일 앱 등 납부 방법을 안내했습니다. (출처: 서울특별시 보도자료 (https://www.seoul.go.kr/news/news_report.do?bbsNo=158&nttNo=461668))

납부기한을 놓치면 작은 실수가 비용이 됩니다

재산세는 "며칠 늦어도 괜찮겠지" 하고 넘기기 쉬운 항목입니다. 하지만 지방세는 납부기한을 지나면 추가 부담이 생길 수 있습니다. 서울시는 2026년 7월분 재산세 안내에서 납부기한을 넘기면 3%의 납부 지연 가산세를 부담해야 한다고 설명했습니다. (출처: 서울특별시 보도자료 (https://www.seoul.go.kr/news/news_report.do?bbsNo=158&nttNo=461668))

금액이 크지 않으면 3%가 작아 보일 수 있습니다. 하지만 문제는 돈보다 패턴입니다. 재산세는 7월과 9월, 자동차세는 6월과 12월, 주민세는 8월처럼 지방세는 특정 달에 몰려 나옵니다. 한 번 놓치기 시작하면 다음 고지서도 늦게 확인할 가능성이 커집니다.

그래서 저는 재산세를 납부한 날 바로 다음 납기 알림을 달력에 넣는 방식을 권합니다. 7월분을 냈다면 9월 16일과 9월 25일쯤 두 번 알림을 걸어둡니다. 마감일인 9월 30일만 등록하면, 카드 결제 오류나 앱 접속 지연이 생겼을 때 여유가 없습니다.

세액이 크다면 분할납부 가능 여부를 먼저 확인합니다

재산세가 예상보다 크게 나왔다면 무리해서 한 번에 납부하기 전에 분할납부 가능 여부를 확인할 수 있습니다. 정부24의 재산세 분할납부 신청 민원 안내는 분할납부 신청 시기를 분할납부하려는 재산세의 납부기한까지로 안내합니다. 신청은 인터넷, 방문, 우편 방식이 가능하다고 설명되어 있습니다. (출처: 정부24 재산세 분할납부 신청 (https://www.gov.kr/mw/AA020InfoCappView.do?CappBizCD=13100000302&HighCtgCD=A09002&tp_seq=01))

여기서 중요한 것은 납부기한까지입니다. 이미 기한이 지난 뒤에 찾아보면 선택지가 줄어들 수 있습니다. 고지서를 받았을 때 금액이 부담스럽다면, 납부 마감 주까지 미루지 말고 바로 관할 자치단체나 정부24 안내를 확인하는 편이 낫습니다.

분할납부가 항상 가능한 것은 아닙니다. 세액 기준, 신청 절차, 자치단체 처리 방식에 따라 달라질 수 있습니다. 따라서 "큰 금액이면 무조건 나눠 낼 수 있다"가 아니라, 내 고지서가 분할납부 대상인지를 확인하는 순서로 접근해야 합니다.

카드 납부는 혜택보다 결제 완료 확인이 먼저입니다

재산세 시즌이 되면 카드 무이자 할부나 포인트 혜택을 찾는 사람이 많습니다. 물론 현금흐름을 맞추는 데 도움이 될 수 있습니다. 다만 생활비 관점에서는 혜택보다 정상 납부 처리가 먼저입니다.

카드로 납부할 때는 세 가지를 확인하세요. 첫째, 납부가 완료되었는지 영수증 또는 납부 내역을 확인합니다. 둘째, 할부 조건이 카드사 행사 대상인지 확인합니다. 셋째, 카드값 결제일에 현금흐름이 다시 막히지 않는지 봅니다.

재산세를 카드로 냈다고 지출이 사라지는 것은 아닙니다. 결제일이 뒤로 밀릴 뿐입니다. 이번 달 통장 잔고는 지켰는데 다음 달 카드값이 커져서 생활비가 흔들린다면, 예산 관리에는 별 도움이 되지 않습니다.

금액이 작다면 계좌이체로 깔끔하게 끝내는 편이 나을 수 있습니다. 금액이 크고 카드 할부를 쓸 계획이라면, 할부개월 수보다 다음 두 달의 고정비와 카드값 합계를 먼저 계산해 보세요.

다음 재산세를 예산에 넣는 현실적인 방법

재산세는 매달 나가는 돈이 아니라서 예산에서 빠지기 쉽습니다. 하지만 실제로는 매년 반복됩니다. 그래서 월급 예산에는 비정기 고정비로 넣어두는 편이 좋습니다.

가장 단순한 방법은 작년 납부액을 기준으로 월 적립액을 만드는 것입니다. 작년에 재산세를 총 90만 원 냈다면, 올해는 매달 7만5천 원을 별도 통장이나 생활비 앱 항목에 잡아둡니다. 세액이 오를 수 있으니 여유를 두고 8만 원으로 잡아도 됩니다.

올해 처음 집을 보유했거나 작년 금액을 모른다면, 7월 고지서를 기준으로 9월 지출을 임시 추정합니다. 주택분만 있다면 7월과 비슷한 금액이 9월에 한 번 더 나올 수 있다고 보고 준비합니다. 토지가 함께 있다면 9월 금액이 더 커질 수 있으니 고지서 조회를 빨리 해보는 편이 낫습니다.

이때 절대 하지 말아야 할 것은 비상금을 당연한 재산세 납부 재원으로 쓰는 일입니다. 비상금은 예상하지 못한 사고나 소득 공백을 버티기 위한 돈입니다. 재산세처럼 매년 오는 지출은 비상금이 아니라 별도 적립 항목으로 빼는 것이 가계 운영에 더 맞습니다.

이런 경우에는 혼자 판단하지 않는 편이 낫습니다

일반적인 주택 보유자의 7월·9월 고지 흐름은 비교적 단순합니다. 하지만 아래 상황이라면 블로그 글이나 주변 이야기만으로 판단하지 않는 편이 좋습니다.

• 6월 전후로 집을 사고팔았다.
• 공동명의, 상속, 증여, 신탁 등 소유관계가 섞여 있다.
• 주택과 토지, 상가 건축물을 함께 보유하고 있다.
• 고지서 금액이 작년보다 크게 달라졌다.
• 감면 대상인지 아닌지 애매하다.
• 납부기한 내 일시 납부가 어렵다.

이런 경우에는 위택스 조회 화면, 고지서, 등기 관련 서류를 준비해 관할 자치단체 세무 부서에 문의하는 것이 가장 빠릅니다. 세금은 한 문장짜리 팁보다 내 고지서의 과세대상과 산출 내역이 우선입니다.

재산세 납부 전 체크리스트

• 7월 고지서가 주택분 1기분인지 확인했다.
• 9월에 주택분 2기분이 나올 가능성을 예산에 넣었다.
• 토지 보유 여부를 확인했다.
• 공동명의라면 각 명의자별 고지 내역을 확인했다.
• 납부기한 전에 위택스, 이택스, 고지서 중 하나로 금액을 재확인했다.
• 카드 납부를 쓸 경우 결제 완료와 다음 카드값 부담을 함께 확인했다.
• 금액이 부담되면 납부기한 전에 분할납부 가능 여부를 확인했다.

자주 묻는 질문

7월에 냈는데 9월에 또 나오면 이중과세인가요?

대부분은 이중과세가 아니라 주택분 재산세를 두 번에 나눠 내는 구조입니다. 7월 고지서가 주택분 1기분이었다면 9월에 2기분이 나올 수 있습니다. 다만 같은 과세대상에 같은 기분이 중복 고지된 것처럼 보이면 관할 자치단체에 확인해야 합니다.

9월 재산세는 언제부터 준비하면 좋나요?

7월분을 납부한 직후가 가장 좋습니다. 9월 납기는 일반적으로 9월 16일부터 9월 30일까지이므로, 8월 월급 예산에서 일부를 빼두면 9월 생활비 충격이 줄어듭니다.

집을 팔았는데 재산세 고지서가 왔습니다. 잘못 나온 건가요?

반드시 잘못이라고 볼 수는 없습니다. 재산세는 매년 6월 1일을 과세기준일로 보기 때문에, 그 날짜에 소유자였다면 이후 매도했더라도 고지 대상이 될 수 있습니다. 매매계약서의 정산 조건과 관할 자치단체 안내를 함께 확인하세요.

고지서를 못 받으면 납부하지 않아도 되나요?

그렇게 보면 위험합니다. 고지서를 못 받았더라도 납부 대상이면 기한이 지나 추가 부담이 생길 수 있습니다. 주소 변경, 전자고지 신청 상태, 위택스·이택스 조회 내역을 확인하는 편이 안전합니다.

재산세를 줄이는 방법부터 찾으면 안 되나요?

감면이나 특례가 적용될 수 있는 경우는 있습니다. 다만 먼저 할 일은 내 고지서가 어떤 재산, 어떤 기분, 어떤 기준으로 나온 것인지 확인하는 것입니다. 감면 여부는 자격 요건과 시점에 따라 달라질 수 있으니 공식 안내와 관할 부서 확인을 우선하세요.

정리하면, 9월 고지서를 예산에 먼저 넣어야 합니다

재산세는 납부 버튼을 누르는 순간보다, 다음 고지서를 예상하지 못할 때 더 부담스럽습니다. 7월에 주택분 1기분을 냈다면 9월에 한 번 더 나올 수 있습니다. 토지를 갖고 있다면 9월 고지서는 더 달라질 수 있습니다.

올해 재산세를 이미 냈다면 고지서에서 과세대상과 기분을 다시 확인해 보세요. 그리고 9월 납기 알림을 지금 달력에 넣어두는 것이 좋습니다. 재산세는 피해야 할 돌발 지출이 아니라, 미리 나눠 준비해야 할 연간 생활비에 가깝습니다.

출처

• 서울특별시, 2026년 7월분 재산세 고지 보도자료 (https://www.seoul.go.kr/news/news_report.do?bbsNo=158&nttNo=461668)
• 국가법령정보센터, 지방세법 제114조·제115조 조문정보 (https://law.go.kr/LSW/lsLinkCommonInfo.do?chrClsCd=010202&lsJoLnkSeq=1033349659)
• 정부24, 재산세 분할납부 신청 민원 안내 (https://www.gov.kr/mw/AA020InfoCappView.do?CappBizCD=13100000302&HighCtgCD=A09002&tp_seq=01)

OpenAPI 문서와 실제 API가 어긋날 때 먼저 잡을 기준

Lovizu — Thu, 6 Aug 2026 11:41:13 +0900

OpenAPI 문서와 실제 API가 어긋날 때 먼저 잡을 기준

Swagger UI에는 분명 email이 필수라고 적혀 있는데, 실제 응답에는 가끔 빠집니다. 문서에는 status가 active | blocked라고 되어 있지만 운영 데이터에는 pending이 섞여 있습니다. 프론트엔드는 타입을 믿고 배포했는데, 어느 날 특정 고객 계정에서만 화면이 깨집니다.

이런 문제는 OpenAPI를 "문서 자동 생성" 정도로만 보면 계속 반복됩니다. OpenAPI는 예쁜 API 문서가 아니라, 클라이언트와 서버가 함께 지키는 계약으로 다뤄야 합니다. 계약이 깨지는 순간은 대개 큰 리팩토링 때가 아닙니다. 필드 하나를 optional로 바꾸거나, 에러 응답 형식을 급하게 추가하거나, 테스트 데이터에 없는 케이스가 운영에서 들어올 때 조용히 생깁니다.

내가 작은 팀에서 OpenAPI를 볼 때 먼저 확인하는 기준은 세 가지입니다.

문서가 실제 라우트, 요청값, 응답값을 얼마나 좁게 설명하는가
실제 API가 문서에 적힌 스키마를 자동 검증받는가
변경이 생겼을 때 프론트엔드와 외부 연동자가 언제 알아차릴 수 있는가

최종 업데이트: 2026-08-06
작성 관점: PHP/Laravel, Node.js, AWS 환경에서 API를 만들고 운영하며 겪는 문서 드리프트 문제를 기준으로 정리했습니다.

OpenAPI가 틀어지는 순간은 생각보다 사소합니다

OpenAPI Specification은 HTTP API를 언어와 구현에 묶이지 않는 인터페이스 설명으로 정의합니다. 소스 코드나 별도 문서를 보지 않아도 서비스의 기능을 이해하고 호출할 수 있게 하는 것이 핵심입니다. 최신 공개 버전은 2025년 9월 19일 기준 OpenAPI Specification v3.2.0이며, 이 글은 2026년 8월 6일에 해당 문서를 확인해 작성했습니다. (출처: OpenAPI Specification v3.2.0)

그런데 실무에서 문제는 "OpenAPI를 쓰느냐"가 아니라 "OpenAPI가 실제와 맞느냐"입니다. 문서가 한 번 만들어진 뒤 관리되지 않으면, 오히려 안심하게 만드는 잘못된 정보가 됩니다. 프론트엔드 개발자는 문서에 없는 nullable을 처리하지 않고, QA는 문서에 적힌 에러 형식만 확인하고, 외부 연동사는 더 오래된 예제를 보고 구현합니다.

내가 가장 자주 본 드리프트는 아래 네 가지입니다.

어긋나는 지점	겉으로 보이는 증상	먼저 확인할 것
응답 필드	특정 화면에서만 `undefined` 오류	`required`, `nullable`, 실제 샘플 응답
enum 값	새 상태값이 들어오면 분기 실패	운영 DB 값, 상태 전이표, schema enum
에러 형식	실패 화면 메시지가 비거나 잘못 표시됨	`4xx`, `5xx` 응답 스키마
인증/권한	문서에서는 호출 가능하지만 실제로는 401/403	operation별 `security`, 권한 정책

문서와 실제가 어긋나는 이유는 게으름만이 아닙니다. 바쁜 팀에서는 API 변경이 먼저이고 문서 반영이 나중입니다. 긴급 장애 대응 중에는 에러 응답을 임시로 바꾸기도 합니다. 문제는 그 임시 변경이 다음 배포에도 살아남는다는 점입니다.

문서 품질보다 계약 범위를 먼저 정해야 합니다

OpenAPI 문서를 처음 만들 때 모든 것을 완벽하게 적으려 하면 금방 지칩니다. 반대로 너무 느슨하게 적으면 계약으로서 힘이 없습니다. type: object만 있고 필드가 비어 있는 스키마는 사실상 "아무거나 올 수 있다"는 뜻입니다.

처음부터 넓게 잡아야 할 영역과 좁게 잡아야 할 영역을 나누는 편이 현실적입니다.

좁게 잡을 것: 공개 API 응답, 프론트엔드가 직접 렌더링하는 필드, 상태값 enum, 에러 응답 형식
느슨하게 시작할 수 있는 것: 내부 관리자 전용 임시 API, 로그성 메타데이터, 실험 기능의 비핵심 필드
반드시 명시할 것: 인증 방식, 페이지네이션 형식, 날짜/시간 포맷, nullable 여부

OpenAPI 구조 학습 문서는 paths가 엔드포인트와 파라미터, 가능한 서버 응답을 설명하는 영역이라고 안내합니다. 또 응답은 responses 아래에 HTTP 상태 코드별로 적습니다. 이 말은 단순합니다. 성공 응답만 적어둔 문서는 절반짜리 계약입니다. (출처: OpenAPI Learn - Structure of an OpenAPI Description, OpenAPI Learn - API Endpoints)

작은 팀이라면 처음부터 모든 API를 계약 테스트 대상으로 삼기보다, 깨졌을 때 비용이 큰 API부터 시작하는 편이 낫습니다. 회원가입, 결제, 주문, 권한, 알림, 외부 연동 콜백처럼 한 번 어긋나면 고객 지원이나 데이터 정정으로 이어지는 곳입니다.

실제 응답을 문서에 맞춰 보는 작은 테스트부터 시작합니다

계약 테스트라고 하면 Pact 같은 도구나 복잡한 마이크로서비스 구조부터 떠올리기 쉽습니다. 하지만 시작점은 더 작아도 됩니다. "이 API의 실제 JSON 응답이 OpenAPI에 적힌 필수 필드와 타입을 만족하는가"만 CI에서 확인해도, 문서 드리프트의 상당 부분은 빨리 드러납니다.

아래 예시는 의존성 없이 Node.js에서 돌릴 수 있는 아주 작은 검증 스크립트입니다. OpenAPI 전체를 완벽하게 해석하지 않습니다. 대신 application/json 응답 스키마의 required와 기본 타입만 확인합니다. 팀에서 기준을 합의하기 위한 출발점으로 보면 됩니다.

const spec = {
  paths: {
    "/users/me": {
      get: {
        responses: {
          "200": {
            content: {
              "application/json": {
                schema: {
                  type: "object",
                  required: ["id", "email", "role"],
                  properties: {
                    id: { type: "integer" },
                    email: { type: "string" },
                    role: { type: "string", enum: ["admin", "member"] },
                  },
                },
              },
            },
          },
        },
      },
    },
  },
};

const responseBody = {
  id: 42,
  email: "dev@example.com",
  role: "member",
};

function assertBySchema(schema, value, path = "$") {
  if (schema.type === "object") {
    if (value === null || Array.isArray(value) || typeof value !== "object") {
      throw new Error(`${path} must be object`);
    }

    for (const key of schema.required ?? []) {
      if (!(key in value)) {
        throw new Error(`${path}.${key} is required`);
      }
    }

    for (const [key, childSchema] of Object.entries(schema.properties ?? {})) {
      if (key in value) {
        assertBySchema(childSchema, value[key], `${path}.${key}`);
      }
    }
  }

  if (schema.type === "integer" && !Number.isInteger(value)) {
    throw new Error(`${path} must be integer`);
  }

  if (schema.type === "string" && typeof value !== "string") {
    throw new Error(`${path} must be string`);
  }

  if (schema.enum && !schema.enum.includes(value)) {
    throw new Error(`${path} must be one of ${schema.enum.join(", ")}`);
  }
}

const schema =
  spec.paths["/users/me"].get.responses["200"].content["application/json"].schema;

assertBySchema(schema, responseBody);
console.log("contract ok");

이 코드를 그대로 운영 검증 도구로 쓰라는 뜻은 아닙니다. 실제 프로젝트에서는 $ref, 배열, oneOf, 날짜 포맷, nullable, 추가 속성 처리까지 봐야 합니다. 다만 이 정도 테스트만 있어도 "문서에는 필수인데 실제 응답에는 빠지는 필드"와 "문서에는 문자열인데 실제로는 숫자로 내려오는 필드"를 배포 전에 잡을 수 있습니다.

OpenAPI v3.2.0 문서는 Schema Object를 통해 데이터 구조를 표현하고, Responses Object를 통해 상태 코드별 응답을 기술합니다. 계약 테스트는 이 두 지점을 실제 실행 결과와 붙여 보는 일에 가깝습니다. 문서를 사람이 읽는 산출물로만 두지 않고, 배포 과정에서 실행되는 규칙으로 바꾸는 것입니다. (출처: OpenAPI Specification v3.2.0 - Schema Object, OpenAPI Specification v3.2.0 - Responses Object)

required와 nullable은 팀에서 가장 먼저 합의해야 합니다

OpenAPI 문서가 있어도 required와 nullable 기준이 흐리면 프론트엔드는 결국 방어 코드를 남발합니다. 모든 필드에 ?.를 붙이고, 화면마다 기본값을 다르게 넣고, 실제로는 필수인 값이 빠져도 조용히 넘어갑니다. 그러면 오류는 줄어드는 것처럼 보이지만 데이터 품질 문제는 늦게 발견됩니다.

나는 응답 필드를 세 가지로 나눠 적는 편입니다.

필수 값: 화면이나 비즈니스 로직이 없으면 안 되는 값. OpenAPI의 required에 넣는다.
명시적 없음: 값이 없을 수 있다는 의미가 도메인에 있는 값. null 허용 여부를 문서에 적는다.
확장 메타데이터: 없어도 화면이 깨지지 않는 값. 필수로 두지 않되 의미를 설명한다.

예를 들어 사용자 프로필 응답에서 id와 email은 보통 필수입니다. 반면 lastLoginAt은 아직 로그인 기록이 없으면 없을 수 있습니다. 이때 빈 문자열, null, 필드 미포함을 섞어 쓰면 클라이언트 처리가 복잡해집니다. "없음"을 무엇으로 표현할지 하나로 정해야 합니다.

Laravel이나 Node.js 프로젝트에서 자주 생기는 실수는 DB 컬럼 기준을 그대로 API 계약으로 착각하는 것입니다. DB에서는 nullable이지만 API에서는 항상 채워서 내려줄 수도 있고, 반대로 DB에는 값이 있어도 권한 때문에 응답에서 제외할 수 있습니다. OpenAPI는 테이블 구조가 아니라 외부로 내보내는 인터페이스를 설명해야 합니다.

에러 응답은 성공 응답보다 더 빨리 어긋납니다

성공 응답은 화면 개발 중에 계속 보입니다. 반면 에러 응답은 테스트 데이터가 부족하면 잘 보이지 않습니다. 그래서 문서에는 400만 있고 실제로는 422, 401, 403, 409, 429가 제각각 내려오는 일이 많습니다.

에러 응답에서 최소로 맞춰야 할 것은 네 가지입니다.

사람이 읽을 메시지와 개발자가 추적할 코드가 분리되어 있는가
필드 검증 오류가 어느 필드의 어떤 문제인지 알 수 있는가
인증 실패와 권한 부족을 같은 오류처럼 처리하지 않는가
재시도 가능한 실패와 사용자가 수정해야 하는 실패가 구분되는가

예를 들어 입력 검증 실패는 화면에서 필드 옆에 표시해야 합니다. 서버 내부 오류는 사용자에게 상세 스택을 보여주면 안 됩니다. 권한 부족은 다시 로그인으로 해결되는지, 관리자 권한이 필요한지에 따라 안내가 달라집니다. 이 차이가 OpenAPI에 없으면 프론트엔드는 상태 코드와 문자열 메시지에 의존하게 됩니다.

나는 새 API를 만들 때 성공 응답보다 에러 응답 예시를 먼저 보기도 합니다. 성공 케이스는 개발자가 자연스럽게 확인하지만, 실패 케이스는 누군가 일부러 붙잡지 않으면 뒤로 밀립니다. 특히 외부 연동 API라면 에러 형식이 곧 지원 비용입니다.

문서 생성 위치를 하나로 정해야 오래 갑니다

OpenAPI 문서를 유지하는 방식은 팀마다 다릅니다. 코드에서 주석이나 데코레이터로 생성할 수도 있고, 별도 YAML을 먼저 쓰고 서버와 클라이언트를 맞출 수도 있습니다. 어느 쪽이든 중요한 것은 "정본이 어디인가"를 정하는 일입니다.

정본이 두 개가 되면 거의 반드시 어긋납니다. 백엔드는 컨트롤러 타입을 고치고, 프론트엔드는 별도 문서를 보고, 외부 연동사는 더 오래된 Swagger UI를 봅니다. 누가 맞는지 논쟁하는 순간 이미 계약 관리는 실패한 상태입니다.

실무에서는 아래 기준으로 고르면 됩니다.

팀 상황	정본 후보	주의할 점
백엔드가 API를 주도하고 변경 속도가 빠름	코드에서 OpenAPI 생성	생성된 문서를 CI에서 diff로 확인
외부 연동사가 많고 사전 합의가 중요함	OpenAPI YAML/JSON 우선	서버 구현이 문서를 따라가는 테스트 필요
프론트와 백엔드가 동시에 개발됨	문서 우선 + mock 서버	임시 mock과 실제 구현 차이를 주기적으로 검증
레거시 API를 정리하는 중	실제 응답 샘플에서 역으로 문서화	현재 동작과 목표 계약을 분리해서 표시

나는 작은 팀에서는 코드 생성 방식으로 시작하되, 공개 API나 외부 연동 API는 문서 diff를 반드시 리뷰에 올리는 방식을 선호합니다. 코드에서 생성되면 최신성은 좋아지지만, 의도치 않은 계약 변경도 조용히 문서에 반영될 수 있기 때문입니다. "문서가 자동으로 바뀌었다"는 말은 "계약 변경 리뷰가 생략됐다"는 뜻이 될 수 있습니다.

변경 관리는 버전보다 호환성 기준이 먼저입니다

API 버전을 v1, v2로 나누는 것만으로는 충분하지 않습니다. 같은 v1 안에서도 필수 필드가 추가되거나 enum 값이 바뀌면 클라이언트는 깨질 수 있습니다. 반대로 새 optional 필드를 추가하는 정도는 버전을 올리지 않아도 되는 경우가 많습니다.

변경을 볼 때는 아래처럼 나누면 판단이 쉬워집니다.

대체로 안전한 변경: optional 응답 필드 추가, 새 endpoint 추가, 설명 보강
주의가 필요한 변경: enum 값 추가, 에러 코드 추가, nullable 정책 변경
깨지는 변경: 필수 필드 제거, 타입 변경, 필수 요청 파라미터 추가, 상태 코드 의미 변경

enum 값 추가를 "안전한 변경"으로 보는 팀도 있지만, 나는 보수적으로 봅니다. 프론트엔드가 switch 문에서 알려진 값만 처리하고 있다면 새 값은 바로 빈 화면이나 기본 분기로 떨어질 수 있습니다. 상태값은 필드 하나가 아니라 화면 흐름입니다.

OpenAPI 문서의 info.version은 API 설명의 버전을 나타내는 값으로 사용할 수 있습니다. 다만 이 숫자가 올라갔다고 해서 소비자가 자동으로 안전해지는 것은 아닙니다. 중요한 것은 변경 로그에 "무엇이 호환되고 무엇이 깨지는지"를 적는 것입니다. (출처: OpenAPI Learn - Structure of an OpenAPI Description)

보안과 개인정보는 문서에도 남기지 말아야 할 것이 있습니다

OpenAPI 문서는 개발자에게 친절해야 하지만, 운영 비밀을 담아서는 안 됩니다. 예제 토큰, 실제 고객 이메일, 내부 관리자 경로, 운영 서버의 민감한 URL이 문서에 들어가면 문서 자체가 노출면이 됩니다.

OpenAPI v3.2.0의 보안 고려사항은 외부 리소스 참조, 참조 순환, Markdown/HTML 위생 처리 같은 도구 사용 리스크도 다룹니다. 문서 렌더링 도구가 외부 $ref를 자동으로 따라가거나, 설명 필드에 들어간 HTML을 그대로 보여주면 예상하지 못한 문제가 생길 수 있습니다. (출처: OpenAPI Specification v3.2.0 - Security Considerations)

문서 공개 범위를 정할 때는 아래 질문을 먼저 던집니다.

이 OpenAPI 문서가 외부에 공개되어도 되는가
내부용 endpoint와 외부용 endpoint가 같은 문서에 섞여 있지 않은가
예제 값에 실제 개인정보나 운영 토큰이 들어가지 않았는가
Swagger UI 접근 권한이 운영 관리자 권한과 분리되어 있는가
외부 $ref를 가져오는 도구라면 허용 도메인을 제한했는가

API 문서는 개발 속도를 높이기 위한 도구입니다. 하지만 운영 정보가 섞이면 문서가 아니라 보안 부채가 됩니다.

작은 팀에서 바로 적용할 OpenAPI 운영 체크리스트

OpenAPI를 제대로 운영하려고 처음부터 플랫폼을 크게 만들 필요는 없습니다. 작은 팀이라면 아래 순서로도 충분히 시작할 수 있습니다.

공개 API와 프론트엔드 핵심 API부터 OpenAPI 문서 범위를 정했다.
성공 응답뿐 아니라 주요 4xx, 5xx 에러 응답 형식을 적었다.
required, nullable, enum 값을 실제 화면 기준으로 정했다.
문서 정본이 코드인지 YAML/JSON인지 팀 안에서 합의했다.
PR에서 OpenAPI diff를 볼 수 있다.
실제 API 응답 샘플이 문서 스키마를 통과하는지 CI에서 확인한다.
enum 값 추가와 필수 필드 변경을 깨지는 변경 후보로 리뷰한다.
예제 값에 실제 개인정보, 토큰, 내부 URL이 들어가지 않게 검사한다.
외부 연동 API는 변경 로그와 적용 일자를 같이 남긴다.

처음부터 전부 자동화하지 않아도 됩니다. 가장 먼저 할 일은 "문서가 맞는지"를 사람의 기억에 맡기지 않는 것입니다. 핵심 endpoint 몇 개만이라도 실제 응답과 OpenAPI 스키마를 함께 검증하면, Swagger UI가 오래된 안내판으로 남는 일을 꽤 줄일 수 있습니다.

자주 묻는 질문

OpenAPI 문서는 코드에서 자동 생성하는 게 항상 좋나요?

항상 그렇지는 않습니다. 코드 생성 방식은 최신성을 유지하기 쉽지만, 의도하지 않은 계약 변경도 함께 반영될 수 있습니다. 외부 연동사가 있는 API라면 생성된 문서 diff를 PR에서 검토하고, 깨지는 변경인지 따로 판단해야 합니다.

Swagger UI가 있으면 계약 테스트는 없어도 되나요?

Swagger UI는 사람이 API를 읽고 시도해 보기 좋은 도구입니다. 하지만 실제 배포 과정에서 응답이 문서와 맞는지 자동으로 보장하지는 않습니다. 계약 테스트는 문서를 화면으로 보여주는 일이 아니라, 실제 응답과 문서 스키마를 비교하는 일입니다.

모든 응답 필드를 required로 잡아야 안전한가요?

아닙니다. 실제로 없을 수 있는 값을 필수로 잡으면 서버는 가짜 기본값을 만들거나 클라이언트는 문서를 믿지 않게 됩니다. 화면과 비즈니스 로직에 반드시 필요한 값만 필수로 두고, 의미 있는 "없음"은 nullable 또는 필드 미포함 정책으로 분명히 정해야 합니다.

OpenAPI 버전을 올리면 깨지는 변경 문제가 해결되나요?

버전은 소비자에게 변경을 알리는 장치일 뿐입니다. 필수 필드 제거, 타입 변경, 상태 코드 의미 변경처럼 실제 호환성을 깨는 내용은 버전 숫자와 별개로 명확히 기록하고 전환 기간을 둬야 합니다.

출처

분리배출 헷갈릴 때, 집에서 먼저 확인할 7가지 기준

Lovizu — Thu, 6 Aug 2026 11:37:34 +0900

분리배출 헷갈릴 때, 집에서 먼저 확인할 7가지 기준

택배 상자를 뜯고 나면 종이 상자, 송장 스티커, 완충재, 테이프가 한꺼번에 남습니다. 배달 음식 용기는 더 애매합니다. 플라스틱처럼 보이지만 기름이 묻어 있고, 비닐은 깨끗한 것 같지만 양념 냄새가 남아 있습니다.

이럴 때 분리배출 표시만 보고 바로 버리면 자주 틀립니다. 표시가 있더라도 내용물이 남아 있거나, 다른 재질이 붙어 있거나, 지역 수거 방식과 맞지 않으면 재활용품으로 처리되기 어렵습니다. 집에서 판단할 때는 표시 확인보다 비우기 → 헹구기 → 분리하기 → 섞지 않기 순서가 먼저입니다.

3줄 요약

분리배출의 기본은 환경부가 안내한 네 가지 원칙, 즉 비우고 헹구고 분리하고 섞지 않는 것입니다.

오염이 심한 종이, 기름 묻은 비닐, 내용물이 남은 용기는 표시가 있어도 재활용품으로 보기 어렵습니다.

지역마다 수거 요일과 세부 품목이 다를 수 있으므로, 애매한 품목은 아파트 안내문이나 지자체 공지를 함께 확인해야 합니다.

최종 업데이트: 2026-08-06

작성 관점: 이 글은 일반 가정에서 헷갈리는 분리배출을 줄이기 위한 생활 정보입니다. 지자체별 수거 방식, 공동주택 관리 규칙, 사업장 폐기물 기준은 다를 수 있으니 최종 배출 전에는 거주 지역 안내를 우선 확인하세요.

분리배출 표시는 출발점이지 결론이 아닙니다

분리배출 표시가 있으면 재활용품이라고 생각하기 쉽습니다. 하지만 실제 배출에서는 표시보다 상태가 먼저입니다. 컵라면 용기에 국물이 남아 있거나, 피자 상자에 기름이 스며 있거나, 플라스틱 용기에 음식물이 말라붙어 있으면 선별 과정에서 문제가 됩니다.

환경부는 재활용가능자원 분리배출의 핵심으로 비운다, 헹군다, 분리한다, 섞지 않는다를 안내합니다. 2018년에 공개한 내 손안의 분리배출 앱과 가이드라인도 이 네 가지 원칙을 품목별 배출 요령의 기본으로 삼고 있습니다. (출처: 환경부 보도자료, 정책브리핑)

그래서 집에서는 이렇게 묻는 편이 낫습니다.

안에 남은 내용물이 없는가?
물로 한 번 헹궈도 될 정도로 오염이 가벼운가?
종이, 비닐, 플라스틱, 금속처럼 다른 재질을 뗄 수 있는가?
같은 재질끼리 모아 배출할 수 있는가?

이 네 가지 중 하나라도 막히면 바로 재활용함에 넣기보다 한 번 더 판단해야 합니다. 특히 음식물, 기름, 테이프, 코팅, 접착제는 집에서 가장 자주 놓치는 지점입니다.

택배 상자는 상자보다 테이프와 송장이 문제입니다

택배 상자는 종이류로 배출할 수 있어 보이지만, 그대로 접어 버리면 종이가 아닌 것들이 함께 들어갑니다. 박스 테이프, 운송장 스티커, 비닐 완충재, 플라스틱 손잡이가 대표적입니다. 종이로 보이는 상자라도 이런 이물질은 가능한 한 떼고 배출하는 쪽이 안전합니다.

환경부 카드뉴스는 종이류 배출에서 테이프, 은박지, 택배송장 같은 종이 외 이물질을 제거하라고 안내합니다. 감열지 영수증, 금박지·은박지, 코팅 벽지처럼 다른 재질이 섞인 종이는 재활용 종이와 다르게 봐야 한다는 점도 함께 설명합니다. (출처: 기후에너지환경부 카드뉴스)

집에서 할 일은 간단합니다. 박스는 접기 전에 테이프를 먼저 뜯고, 송장은 개인정보가 보이지 않게 제거합니다. 비닐 완충재는 비닐류로 따로 모으고, 종이 완충재는 오염이 없을 때만 종이류로 봅니다. 음식물이 묻었거나 젖은 종이는 재활용품이 아니라 일반 쓰레기로 처리해야 할 가능성이 큽니다.

종이로 보이지만 따로 봐야 할 것

택배송장, 영수증처럼 감열지 성격이 있는 종이
음식 기름이 밴 피자 상자, 치킨 상자
비닐 코팅이 강한 포장지
은박, 금박, 플라스틱이 붙어 분리가 어려운 종이

여기서 기준은 “찢으면 종이처럼 찢어지는가”가 아닙니다. 재활용 종이로 다시 쓰기 어려울 만큼 오염되었는지, 다른 재질이 붙어 있는지를 먼저 봐야 합니다.

페트병은 투명 페트병과 나머지 플라스틱을 나눠 봅니다

생수병과 음료수병은 집에서 가장 많이 나오는 재활용품입니다. 그런데 페트병도 그냥 플라스틱류에 섞어 버리면 아깝습니다. 투명 페트병은 별도 분리배출 대상이라서, 내용물을 비우고 라벨을 제거한 뒤 압착해 뚜껑을 닫아 배출하는 흐름으로 관리하는 편이 좋습니다.

환경부는 투명 페트병 별도 분리배출을 공동주택부터 시행했고, 단독주택까지 확대하는 흐름을 안내한 바 있습니다. 정책브리핑 자료에서도 단독주택 투명페트병 별도 분리배출제 확대 시행 일정이 소개됐습니다. (출처: 정책브리핑)

집에서는 페트병을 아래 순서로 처리하면 헷갈림이 줄어듭니다.

물, 음료를 끝까지 비웁니다.
병 안을 가볍게 헹굽니다.
라벨을 떼어냅니다.
가능한 만큼 압착합니다.
뚜껑을 닫아 투명 페트병 수거함에 배출합니다.

색이 있는 페트병, 양념통, 세제통, 샴푸통은 투명 페트병과 다르게 봐야 합니다. 이들은 플라스틱류로 배출하더라도 내용물과 펌프, 라벨, 금속 스프링 같은 다른 재질을 최대한 분리해야 합니다.

배달 용기는 '재질'보다 '오염'을 먼저 봅니다

배달 용기는 분리배출에서 가장 자주 마음이 불편해지는 물건입니다. 플라스틱 표시가 있는데도 빨간 양념이 묻어 있고, 기름은 물로도 잘 안 빠집니다. 이때 “재활용 표시가 있으니 괜찮겠지”라고 넘기면 오염된 재활용품이 섞입니다.

기준은 현실적으로 잡아야 합니다. 물로 한두 번 헹궈 음식물과 기름기가 어느 정도 제거되면 플라스틱류로 배출할 수 있습니다. 반대로 양념이 깊게 배었거나, 기름이 두껍게 남거나, 씻어도 냄새와 오염이 심하면 일반 쓰레기로 보는 편이 낫습니다.

집에서 매번 완벽하게 닦으려다 지치면 오래 못 갑니다. 저는 배달 용기는 먼저 키친타월로 남은 양념을 닦고, 물로 짧게 헹군 뒤, 그래도 끈적임이 강하면 재활용 욕심을 내려놓는 쪽으로 봅니다. 물과 시간을 과하게 쓰면서까지 애매한 용기 하나를 살리려는 방식은 생활 루틴으로 오래가기 어렵습니다.

품목	먼저 볼 기준	배출 판단
깨끗한 플라스틱 용기	내용물 제거, 가벼운 헹굼 가능	플라스틱류
양념이 깊게 밴 용기	헹궈도 색과 기름이 강하게 남음	일반 쓰레기 가능성 높음
일회용 수저·빨대	작고 선별이 어려움	지역 안내 확인, 대개 일반 쓰레기 쪽으로 판단
컵라면 용기	재질과 오염 정도가 갈림	표시와 지역 안내를 함께 확인

비닐류는 깨끗한 것만 모아야 합니다

비닐은 부피가 작고 가벼워서 아무 비닐이나 한 봉투에 넣기 쉽습니다. 하지만 비닐류도 오염이 심하면 재활용이 어렵습니다. 과자 봉지, 라면 봉지, 포장 비닐처럼 겉보기에는 비닐류라도 음식물, 기름, 물기가 남아 있으면 따로 판단해야 합니다.

비닐류를 모을 때는 “비닐인가”보다 “깨끗한가”를 먼저 봅니다. 마른 택배 비닐, 깨끗한 포장 비닐은 모아두기 쉽습니다. 반면 고춧가루, 양념, 기름이 묻은 비닐은 물로 씻어 말릴 수 있는 상황이 아니라면 일반 쓰레기로 처리하는 편이 현실적입니다.

특히 비닐 안에 영수증, 스티커, 종이 라벨, 음식물 조각이 같이 들어가면 나중에 더 귀찮아집니다. 비닐류 봉투를 하나 따로 두되, 그 안에는 깨끗하고 마른 비닐만 넣는 식으로 집안 규칙을 단순하게 만드는 것이 좋습니다.

스티로폼은 흰색 완충재와 음식 포장재를 구분합니다

가전제품이나 택배에 들어 있는 흰색 스티로폼 완충재는 비교적 판단이 쉽습니다. 오염이 없고, 테이프나 송장을 제거할 수 있다면 스티로폼류로 배출할 수 있습니다. 문제는 음식물이 닿은 스티로폼입니다.

생선, 고기, 과일 포장재처럼 음식물이 닿은 스티로폼은 냄새와 오염을 먼저 봐야 합니다. 물로 깨끗하게 헹구고 말릴 수 있으면 재활용 가능성이 있지만, 색이 배었거나 음식물이 붙어 있거나 코팅·테이프가 제거되지 않으면 일반 쓰레기로 처리해야 할 수 있습니다.

아파트 분리수거장에서 스티로폼만 따로 받는 경우도 있고, 지자체 안내가 더 세부적인 곳도 있습니다. 그래서 스티로폼은 공통 원칙에 더해 거주지 안내문을 꼭 같이 봐야 합니다. 같은 품목이라도 단독주택, 공동주택, 상가 주변 수거 방식이 다르게 운영될 수 있습니다.

유리병과 캔은 비우고, 위험한 것은 따로 처리합니다

음료수 병, 소주병, 맥주병, 캔은 비교적 익숙한 품목입니다. 그래도 내용물을 비우지 않거나, 담배꽁초를 넣거나, 깨진 유리를 함께 버리면 문제가 됩니다. 빈 병과 캔은 내용물을 비우고 가볍게 헹군 뒤 배출하는 것이 기본입니다.

깨진 유리는 재활용 유리병과 같이 보면 안 됩니다. 신문지나 두꺼운 종이로 감싸 다치지 않게 처리하고, 지역의 일반 쓰레기 배출 기준을 따르는 편이 안전합니다. 내열유리, 거울, 전구, 도자기류도 일반 유리병과 다릅니다. 겉보기에는 유리처럼 보여도 재질과 처리 방식이 달라 선별장에서는 문제 품목이 될 수 있습니다.

캔도 마찬가지입니다. 음료 캔은 비우고 헹구면 비교적 간단하지만, 부탄가스나 스프레이 캔은 남은 가스를 안전하게 빼야 합니다. 이 부분은 제품 안내와 지자체 기준을 따라야 하며, 실내에서 무리하게 구멍을 뚫거나 임의로 처리하지 않는 편이 안전합니다.

헷갈리면 '재활용 욕심'보다 지역 기준을 먼저 봅니다

분리배출을 잘하려는 마음이 커지면 애매한 것도 전부 재활용함에 넣고 싶어집니다. 하지만 오염된 재활용품 하나가 다른 깨끗한 재활용품까지 망칠 수 있습니다. 확신이 없을 때는 무조건 재활용으로 보내는 것이 정답이 아닙니다.

환경부의 내 손안의 분리배출은 품목별 요령과 헷갈리는 사례를 확인할 수 있도록 만든 자료입니다. 다만 실제 배출은 지자체와 공동주택 관리 방식의 영향을 받습니다. 아파트 분리수거장 안내문, 구청·시청 생활폐기물 안내, 관리사무소 공지를 함께 보는 습관이 필요합니다.

집에서는 아래처럼 규칙을 정해두면 덜 흔들립니다.

오염이 없고 같은 재질로 분리된다면 재활용품으로 배출합니다.
씻어도 음식물과 기름이 심하게 남으면 일반 쓰레기 쪽으로 판단합니다.
품목은 맞지만 지역 수거함이 따로 있으면 그 기준을 따릅니다.
위험하거나 날카로운 물건은 재활용 여부보다 안전 포장을 먼저 생각합니다.
애매한 품목은 한 번 검색하고, 같은 물건이 반복되면 집안 규칙으로 정합니다.

집에 붙여두기 좋은 분리배출 체크리스트

내용물을 끝까지 비웠다.
물로 가볍게 헹궈 오염을 줄였다.
테이프, 송장, 라벨, 뚜껑, 펌프처럼 다른 재질을 가능한 만큼 분리했다.
종이, 플라스틱, 비닐, 캔, 유리, 스티로폼을 섞지 않았다.
기름 묻은 종이와 오염이 심한 비닐은 재활용함에 넣지 않았다.
투명 페트병은 라벨을 제거하고 별도로 모았다.
깨진 유리, 칼날, 위험한 캔은 다치지 않게 따로 처리했다.
지역 수거 요일과 공동주택 안내문을 확인했다.

이 체크리스트는 완벽한 환경 실천표가 아닙니다. 매번 버릴 때 판단 시간을 줄이기 위한 기준표에 가깝습니다. 집에 아이가 있거나 가족이 함께 분리배출한다면, 냉장고 옆이나 현관 근처에 짧게 적어두는 것만으로도 실수가 줄어듭니다.

자주 묻는 질문

분리배출 표시가 있으면 무조건 재활용품인가요?

아닙니다. 표시는 그 포장재의 재질과 배출 방향을 알려주는 출발점입니다. 내용물이 남아 있거나, 음식물·기름 오염이 심하거나, 다른 재질이 붙어 분리되지 않으면 재활용품으로 처리되기 어렵습니다.

종이컵은 종이류로 버리면 되나요?

종이컵은 안쪽 코팅과 오염 여부 때문에 일반 종이와 다르게 운영되는 경우가 있습니다. 깨끗하게 모아 별도 수거하는 곳도 있고, 일반 종이류와 섞지 말라고 안내하는 곳도 있습니다. 거주지 수거 안내를 우선 확인하세요.

라벨은 꼭 다 떼야 하나요?

가능하면 떼는 편이 좋습니다. 특히 투명 페트병은 라벨을 제거해야 다른 플라스틱과 섞이는 문제를 줄일 수 있습니다. 다만 일부 라벨이나 접착제가 완전히 떨어지지 않을 수 있으니, 무리해서 용기를 망가뜨리기보다 가능한 만큼 제거하고 지역 안내를 따르는 것이 현실적입니다.

깨끗하게 씻으면 모든 플라스틱 용기를 재활용할 수 있나요?

그렇지는 않습니다. 재질, 크기, 색상, 복합재 여부, 지역 선별 체계에 따라 달라질 수 있습니다. 집에서 할 수 있는 기본은 내용물을 비우고, 헹구고, 다른 재질을 분리하고, 같은 품목끼리 모으는 것입니다.

배달 음식 용기를 물로 씻는 것이 더 낭비 아닌가요?

과하게 씻을 필요는 없습니다. 남은 음식물을 닦고 짧게 헹궈 오염이 줄어드는 정도면 충분한 경우가 많습니다. 물을 많이 써도 기름과 양념이 남는 용기는 재활용 욕심을 줄이고 일반 쓰레기로 판단하는 편이 낫습니다.

마무리: 애매한 물건은 네 단어로 걸러봅니다

분리배출은 어려운 환경 지식보다 반복 가능한 순서가 먼저입니다. 버리기 전에 비웠나, 헹궜나, 뗐나, 섞지 않았나만 확인해도 많은 실수가 줄어듭니다.

애매한 물건을 만났을 때는 표시를 한 번 보고, 오염 상태를 보고, 지역 기준을 봅니다. 그래도 모르겠다면 그 물건은 따로 메모해두세요. 한 번 정해둔 집안 기준은 다음 분리수거 날 시간을 꽤 줄여줍니다.

출처

목 어깨 통증 줄이는 책상 루틴: 자세보다 먼저 바꿀 5가지

Lovizu — Thu, 6 Aug 2026 11:34:53 +0900

목 어깨 통증 줄이는 책상 루틴: 자세보다 먼저 바꿀 5가지

목이 뻐근해서 자세를 고쳐 앉아도 10분 뒤면 다시 모니터 쪽으로 몸이 기울어집니다. 의지가 약해서가 아닙니다. 모니터가 낮고, 마우스가 멀고, 팔을 둘 곳이 없으면 몸은 계속 그쪽으로 끌려갑니다. 오래 앉아 일하는 사람의 목 어깨 통증은 "바른 자세를 얼마나 오래 참느냐"보다 틀어진 세팅을 얼마나 덜 만들었느냐에서 먼저 갈립니다.

최종 업데이트: 2026-08-06

이 글은 일반적인 생활 건강 정보입니다. 목 통증의 진단이나 치료를 대신하지 않습니다. 통증이 심하거나 팔 저림, 힘 빠짐, 발열, 외상 뒤 통증처럼 경고 신호가 있으면 의료 전문가에게 확인하는 편이 안전합니다.

먼저 보면 좋은 기준

책상 루틴의 목표는 완벽한 자세가 아니라, 목과 어깨가 같은 긴장을 오래 버티지 않게 만드는 것입니다.

모니터, 의자, 마우스, 팔 위치를 먼저 바꾸고 스트레칭은 그다음에 붙이는 편이 현실적입니다.

통증이 팔이나 손으로 내려가거나 저림·힘 빠짐이 있으면 단순 피로로 넘기지 않는 것이 좋습니다.

목 어깨 통증은 왜 오후에 더 심해질까?

오전에는 괜찮다가 오후 3시쯤 뒷목과 승모근이 무거워지는 날이 있습니다. 이때 문제를 "운동 부족" 하나로만 보면 해결이 느립니다. 컴퓨터 작업은 몸 전체로 보면 큰 힘을 쓰지 않는 일처럼 보이지만, 목과 어깨 입장에서는 같은 자세를 오래 유지하는 일입니다.

OSHA의 컴퓨터 작업대 인체공학 자료는 모니터를 보는 정적인 자세를 오래 유지하면 머리를 지탱하는 목과 어깨 근육이 피로해질 수 있다고 설명합니다. 또한 좋은 자세로 앉아 있어도 같은 자세나 장시간의 정적 앉기는 건강하지 않으므로, 작은 조정과 주기적인 움직임이 필요하다고 안내합니다. (출처: OSHA - Work Process and Recognition, OSHA - Good Working Positions)

그래서 핵심은 한 번 크게 풀어주는 스트레칭보다, 목이 굳기 전에 세팅과 흐름을 바꾸는 것입니다. 재택근무나 책상 업무를 오래 하는 사람이라면 운동 시간보다 먼저 하루의 작업 환경을 봐야 합니다.

첫 번째: 모니터는 높이보다 "고개가 숙여지는지"로 봅니다

모니터 받침대를 살지 말지보다 먼저 확인할 것은 화면을 볼 때 턱이 앞으로 빠지는지입니다. 화면이 낮으면 목은 자연스럽게 아래로 꺾이고, 화면이 옆으로 치우치면 고개와 몸통이 따로 돌아갑니다. 목이 아픈데 모니터 위치를 그대로 둔 채 스트레칭만 늘리면, 풀고 다시 굳히는 일을 반복하게 됩니다.

OSHA 체크리스트는 머리와 목이 몸통과 일직선에 가깝고, 모니터의 위쪽이 눈높이 또는 그보다 낮아 목을 과하게 숙이거나 젖히지 않는지 확인하라고 안내합니다. 모니터 거리는 사용자가 몸을 앞으로 빼지 않고 읽을 수 있어야 하며, 일반적으로 팔 길이 정도가 기준으로 제시됩니다. (출처: OSHA - Computer Workstations Evaluation Checklist)

노트북만 쓰는 사람은 이 지점에서 자주 막힙니다. 화면을 눈높이에 맞추면 키보드가 올라가고, 키보드에 맞추면 화면이 낮아집니다. 하루 30분 정도 메일만 확인하는 정도라면 크게 문제되지 않을 수 있지만, 노트북을 주 작업 기기로 쓴다면 받침대보다 별도 키보드와 마우스가 먼저입니다.

바로 확인하는 방법

화면 가운데를 볼 때 턱이 앞으로 빠지는지 봅니다.
모니터가 정면이 아니라 옆에 있어 목을 비틀고 있는지 확인합니다.
글자를 읽으려고 상체가 앞으로 나가면 글자 크기, 화면 거리, 모니터 위치를 함께 조정합니다.

두 번째: 어깨가 올라가면 의자보다 팔 위치가 먼저입니다

목 어깨 통증을 줄이려고 의자부터 바꾸는 경우가 많습니다. 의자가 나쁘면 분명 불편하지만, 어깨가 자꾸 올라가는 사람은 팔을 어디에 두고 일하는지 먼저 봐야 합니다. 팔꿈치가 몸에서 멀어지거나 손목이 위로 꺾이면 어깨는 조용히 긴장합니다.

OSHA의 좋은 작업 자세 기준은 어깨를 편하게 내리고, 팔꿈치를 몸 가까이에 두며, 팔꿈치 각도를 대략 90~120도 범위로 유지하는 쪽을 제시합니다. 손·손목·팔뚝은 일직선에 가깝고 바닥과 거의 평행한 상태가 좋습니다. (출처: OSHA - Good Working Positions)

여기서 많은 사람이 놓치는 부분은 책상 높이입니다. 의자를 높여 팔꿈치를 맞추면 발이 뜨고, 발을 맞추면 어깨가 올라가는 책상이 있습니다. 이럴 때는 발받침을 두거나, 키보드와 마우스 위치를 몸 가까이 당기는 식으로 작은 타협점을 찾는 편이 낫습니다.

세 번째: 마우스는 손목보다 "어깨가 앞으로 나가는지"로 봅니다

마우스 때문에 손목만 아픈 것이 아닙니다. 마우스가 키보드보다 멀리 있으면 팔 전체가 앞으로 나가고, 어깨 앞쪽이 계속 긴장합니다. 넓은 책상이 오히려 불편한 이유가 여기에 있습니다. 물건을 멀리 흩어 놓으면 손을 뻗는 일이 늘어납니다.

OSHA 체크리스트는 마우스 같은 입력 장치를 키보드 바로 옆, 가능한 몸의 중심선 가까이에 두라고 안내합니다. 자주 쓰는 물건은 팔꿈치를 몸 가까이에 둔 상태에서 닿는 위치에 두고, 가끔 쓰는 물건만 조금 먼 곳에 두는 식입니다. (출처: OSHA - Computer Workstations Evaluation Checklist)

책상 위를 한 번 정리해보면 의외로 답이 나옵니다. 오른손잡이라면 마우스 오른쪽에 컵, 노트, 충전 케이블이 쌓여 마우스가 바깥으로 밀려난 경우가 많습니다. 마우스를 좋은 것으로 바꾸기 전에, 마우스가 몸에서 멀어진 이유부터 치우는 편이 빠릅니다.

네 번째: 스트레칭은 오래 하는 것보다 자주 끊는 쪽이 낫습니다

목이 뻐근할 때 20분짜리 스트레칭 영상을 켜고 따라 하는 것도 나쁘지 않습니다. 다만 하루 종일 같은 자세로 굳은 뒤 한 번에 풀려고 하면 지속하기 어렵습니다. 일하는 중간에 끊어주는 장치가 없으면 다음 날도 같은 패턴이 반복됩니다.

OSHA는 반복 작업과 정적인 자세가 긴 시간 이어질 때 짧은 휴식과 자세 변경이 필요하다고 설명합니다. 특히 컴퓨터 사용 중에는 매시간 5분 정도 컴퓨터 작업에서 벗어나 시선을 돌리고, 스트레칭하고, 일어나 걷는 식의 짧은 휴식이 근육과 힘줄 회복에 도움이 될 수 있다고 안내합니다. (출처: OSHA - Work Process and Recognition)

현실적으로는 알림 하나면 충분합니다. 50분 일하고 5분 쉬는 방식이 맞는 사람도 있고, 회의가 많은 날에는 회의가 끝날 때마다 1분만 움직이는 방식이 맞을 수도 있습니다. 중요한 것은 쉬는 시간을 길게 잡는 것이 아니라, 목과 어깨가 굳은 자세를 계속 유지하지 않게 하는 것입니다.

1분 루틴 예시

아래 동작은 통증이 없는 범위에서만 부드럽게 해보는 정도로 잡습니다. 갑자기 세게 누르거나, 통증을 참고 버티는 방식은 피하세요.

자리에서 일어나 발바닥을 바닥에 붙이고 어깨 힘을 뺍니다.
고개를 천천히 좌우로 돌려 움직임 범위를 확인합니다.
어깨를 뒤로 작게 5번 돌립니다.
가슴을 살짝 열고, 팔꿈치를 몸 옆으로 내려 10초 쉽니다.
다시 앉기 전 모니터와 마우스가 몸 정면에 있는지 확인합니다.

다섯 번째: 통증을 무시해도 되는 신호와 아닌 신호를 나눕니다

목 어깨 통증은 흔하지만, 흔하다고 해서 모두 같은 문제는 아닙니다. 피곤한 날 뻐근했다가 쉬면 가라앉는 정도와, 팔까지 저리거나 힘이 빠지는 증상은 다르게 봐야 합니다. 건강 글에서 가장 위험한 문장은 "대부분 괜찮다"입니다. 대부분이 괜찮아도, 내 증상이 예외일 수 있기 때문입니다.

MedlinePlus는 목 통증이 팔이나 손의 저림, 따끔거림, 약화와 함께 나타날 수 있다고 설명하며, 증상이 1주일 자가 관리 후에도 사라지지 않거나 팔·손의 저림·약화가 있으면 의료진에게 연락하라고 안내합니다. 또한 발열과 심한 목 뻣뻣함, 호흡곤란, 외상 뒤 목 통증, 걷기와 균형 문제, 대소변 조절 문제 같은 신호는 즉시 도움을 받아야 할 수 있습니다. (출처: MedlinePlus - Neck pain)

Mayo Clinic도 외상, 팔이나 다리의 근력 약화, 고열과 함께 오는 심한 목 통증은 응급 진료가 필요할 수 있고, 자가 관리에도 악화되거나 몇 주 이상 지속되거나 팔·다리로 뻗는 통증, 두통·약화·저림·따끔거림이 동반되면 진료 상담을 권합니다. (출처: Mayo Clinic - Neck pain: When to see a doctor)

책상에서 바로 점검할 체크리스트

점검 항목	괜찮은 상태	조정이 필요한 신호
모니터	정면을 볼 때 고개가 크게 숙여지지 않음	턱이 앞으로 빠지거나 화면을 보려고 상체가 기울어짐
의자와 발	발이 바닥이나 발받침에 안정적으로 닿음	팔 높이에 맞추면 발이 뜨고, 발에 맞추면 어깨가 올라감
팔꿈치	몸 가까이에 있고 어깨가 내려가 있음	팔을 앞으로 뻗거나 어깨를 으쓱한 채 타이핑함
마우스	키보드 바로 옆, 몸 가까운 곳에 있음	마우스를 잡으려고 팔을 멀리 뻗음
휴식	1시간 안에 한 번은 일어나거나 자세를 바꿈	오전부터 오후까지 같은 자세로 버팀
통증 신호	쉬면 줄고 팔 저림이 없음	저림·힘 빠짐·외상·발열·야간 통증이 동반됨

이런 사람은 책상 세팅보다 진료 상담이 먼저입니다

다음에 해당하면 책상 루틴으로 버티기보다 의료 전문가와 상담하는 쪽이 안전합니다.

넘어짐, 교통사고, 운동 중 충격 뒤 목 통증이 시작된 경우
팔이나 손으로 저림, 따끔거림, 힘 빠짐이 내려가는 경우
통증이 밤에 깨울 정도로 심하거나 점점 악화되는 경우
발열, 심한 두통, 목이 뻣뻣해서 턱을 가슴 쪽으로 내리기 어려운 경우
걷기와 균형이 이상하거나 대소변 조절 문제가 동반되는 경우
1주일 이상 자가 관리해도 나아지지 않거나 몇 주 이상 반복되는 경우

이 목록은 겁을 주기 위한 것이 아닙니다. "조금 불편한 목"과 "확인이 필요한 목"을 구분하기 위한 기준입니다. 특히 팔 저림이나 힘 빠짐은 단순한 자세 문제로 단정하지 않는 편이 좋습니다.

하루 루틴으로 붙이는 방법

책상 루틴은 처음부터 완벽하게 만들면 오래가지 않습니다. 첫날에는 모니터 높이와 마우스 거리만 봐도 충분합니다. 다음 날에는 1시간에 한 번 일어나는 알림을 붙이고, 그다음에는 회의 전후로 어깨를 풀어주는 식으로 늘리면 됩니다.

제가 책상 앞에서 오래 일할 때 가장 먼저 보는 것도 의자 브랜드가 아니라 마우스 위치와 화면 높이입니다. 좋은 의자에 앉아도 마우스가 멀면 어깨가 앞으로 끌려가고, 모니터가 낮으면 목은 계속 숙여집니다. 비싼 장비보다 반복되는 작은 위치가 몸에 더 오래 남습니다.

오늘 하나만 바꾼다면 마우스를 키보드 바로 옆으로 당기고, 모니터를 정면에 둔 뒤, 매시간 한 번 일어나는 알림을 켜보세요. 목 어깨 통증을 한 번에 없애는 방법은 아닙니다. 그래도 하루가 끝날 때 "버틴 느낌"을 줄이는 시작점으로는 충분히 현실적입니다.

출처

OSHA - Computer Workstations: Good Working Positions — 컴퓨터 작업대에서 중립 자세, 어깨·팔·모니터 관련 기본 기준을 확인했습니다. 확인일: 2026-08-06
OSHA - Computer Workstations Evaluation Checklist — 모니터 위치, 입력 장치 위치, 발 지지, 마우스 거리 등 책상 점검 항목을 확인했습니다. 확인일: 2026-08-06
OSHA - Work Process and Recognition — 정적인 자세와 반복 작업, 짧은 휴식 필요성, 목·어깨 경고 신호를 확인했습니다. 확인일: 2026-08-06
MedlinePlus - Neck pain — 목 통증의 흔한 원인, 자가 관리 범위, 의료진 상담이 필요한 신호를 확인했습니다. 확인일: 2026-08-06
Mayo Clinic - Neck pain: When to see a doctor — 응급 진료와 외래 상담이 필요한 목 통증 신호를 확인했습니다. 확인일: 2026-08-06

페이지 번호를 포기해야 할 때, OFFSET과 커서 페이지네이션의 갈림길

Lovizu — Thu, 6 Aug 2026 10:55:18 +0900

페이지 번호를 포기해야 할 때, OFFSET과 커서 페이지네이션의 갈림길

관리자 목록 화면에서 1페이지는 40ms, 900페이지는 4초가 나오는 상황을 본 적이 있습니다. 쿼리는 똑같습니다. 인덱스도 그대로입니다. 바뀐 건 OFFSET 뒤에 붙은 숫자 하나뿐입니다. 이때 개발자가 가장 먼저 손대는 곳은 보통 인덱스인데, 정작 문제는 인덱스가 아니라 "건너뛰기"라는 동작 자체에 있습니다.

이 글은 목록 API를 만들 때 OFFSET 방식과 커서 방식 중 무엇을 고를지 판단하는 순서를 정리한 것입니다. 성능 비교표를 만드는 것이 목적이 아니라, "우리 화면이 정말 페이지 번호를 필요로 하는가"부터 되묻는 쪽에 가깝습니다. MySQL, PostgreSQL 공식 문서와 Laravel 페이지네이션 문서를 기준으로 삼았고, 예시 코드는 PHP와 SQL로 적었지만 판단 기준 자체는 언어와 무관합니다.

먼저 이 글에서 다룰 다섯 가지를 미리 적어 둡니다.

OFFSET으로 건너뛴 행도 서버가 계산은 다 한다는 사실
페이지 번호 UI가 실제로 쓰이는 화면과 그렇지 않은 화면의 구분
커서 페이지네이션이 요구하는 정렬 키 조건
전체 건수를 세는 COUNT 쿼리가 따로 만드는 비용
이미 배포된 API의 응답 형태를 바꿀 때 감수해야 하는 것

건너뛴 행은 사라지지 않고 계산됩니다

LIMIT 20 OFFSET 18000이라는 쿼리를 보면 20건만 읽을 것 같지만 그렇지 않습니다. PostgreSQL 공식 문서는 이 동작을 아주 짧게 못 박아 둡니다. OFFSET 절이 건너뛴 행도 서버 내부에서는 여전히 계산되어야 하므로 큰 OFFSET은 비효율적일 수 있다는 설명입니다. (출처: PostgreSQL Documentation - LIMIT and OFFSET)

MySQL도 결이 비슷합니다. MySQL 8.4 레퍼런스 매뉴얼의 LIMIT 최적화 문서는 ORDER BY가 인덱스로 처리되면 매우 빠르지만, filesort가 필요한 경우에는 LIMIT 없이 조건에 맞는 행을 모두 뽑아 대부분을 정렬한 뒤에야 앞쪽 행을 찾는다고 설명합니다. (출처: MySQL 8.4 Reference Manual - LIMIT Query Optimization)

정리하면 비용은 반환하는 행 수가 아니라 "도달하기 위해 지나쳐야 하는 행 수"에 비례합니다. 그래서 이런 현상이 생깁니다.

증상	실제 원인	인덱스 추가로 해결되나
1페이지는 빠른데 뒷페이지만 느림	OFFSET 누적 스캔	아니오. 스캔 범위 자체가 커짐
전체 페이지가 고르게 느림	정렬 키에 인덱스 없음, filesort	예. 정렬 인덱스가 효과 있음
목록은 빠른데 응답이 느림	전체 건수 COUNT, N+1 조회	부분적. 쿼리 구조를 봐야 함
새로고침할 때마다 항목이 중복되거나 사라짐	페이지 이동 중 데이터 삽입·삭제	아니오. 페이징 방식 문제

마지막 줄은 성능 문제가 아니라 정확성 문제인데, 실무에서는 오히려 이쪽이 더 오래 방치됩니다. 사용자가 1페이지를 보는 동안 새 글 3건이 올라오면, 2페이지로 넘어갔을 때 이미 봤던 항목이 다시 나타납니다. 반대로 삭제가 일어나면 한 번도 보지 못한 항목이 조용히 건너뛰어집니다. Laravel 문서도 쓰기가 잦은 데이터셋에서는 OFFSET 방식이 레코드를 건너뛰거나 중복해서 보여줄 수 있다고 같은 문제를 지적합니다. (출처: Laravel Docs - Cursor Pagination)

페이지 번호가 정말 필요한 화면인지부터 봅니다

기술을 바꾸기 전에 화면을 먼저 봐야 합니다. 페이지 번호 UI는 공짜가 아닙니다. "3페이지로 바로 가기"를 지원하려면 전체 건수를 알아야 하고, 임의의 위치로 점프할 수 있어야 하고, 그 위치가 재현 가능해야 합니다. 세 가지 모두 비용입니다.

실제로 페이지 번호가 필요한 화면은 생각보다 좁습니다.

정말 필요한 경우: 운영자가 "몇 건 중 몇 번째"를 근거로 대화하는 백오피스, 감사·정산처럼 전체 건수가 업무 의미를 갖는 목록, 인쇄나 엑셀 내보내기 범위를 사람이 지정하는 화면
대체로 필요 없는 경우: 모바일 무한 스크롤, 알림·피드·타임라인, 채팅 로그, 최신순으로만 소비되는 목록, 검색 결과 상위 몇 십 건만 실제로 열람되는 화면

두 번째 그룹에서는 페이지 번호를 유지하는 비용이 거의 낭비입니다. 사용자는 837페이지로 점프하지 않고, 통계는 별도 대시보드에서 봅니다. 그런데도 "예전부터 그렇게 만들었으니까" 전체 건수를 세고 있는 API가 흔합니다.

판단이 애매하다면 로그를 보면 됩니다. 실제로 요청된 page 파라미터 값의 분포를 하루치만 뽑아 보세요. 대부분 1에서 5 사이에 몰려 있고 그 뒤로는 크롤러 요청뿐이라면, 페이지 번호는 이미 기능이 아니라 장식입니다.

커서는 위치를 숫자가 아니라 조건으로 표현합니다

커서 페이지네이션의 아이디어는 단순합니다. "몇 개를 건너뛸까"가 아니라 "어디서부터 이어서 읽을까"를 조건으로 쓰는 것입니다. Laravel 문서는 두 방식이 만드는 SQL을 나란히 보여줍니다. OFFSET 방식이 select * from users order by id asc limit 15 offset 15라면, 커서 방식은 select * from users where id > 15 order by id asc limit 15가 됩니다. 앞의 쿼리는 지나온 데이터를 전부 훑지만, 뒤의 쿼리는 인덱스 위의 시작점으로 곧장 이동합니다. (출처: Laravel Docs - Cursor Pagination)

Laravel을 쓴다면 메서드 하나만 바꾸면 됩니다.

// OFFSET 기반: 전체 건수 조회 + 페이지 번호 링크
$posts = Post::where('status', 'published')->paginate(20);

// 커서 기반: order by가 반드시 있어야 하고, 정렬 컬럼은 해당 테이블 소유여야 함
$posts = Post::where('status', 'published')
    ->orderBy('published_at', 'desc')
    ->orderBy('id', 'desc')
    ->cursorPaginate(20);

여기서 orderBy를 두 번 건 이유가 이 글의 핵심입니다.

정렬 키가 유일하지 않으면 커서는 흔들립니다

커서 방식은 "정렬 순서상 이 값보다 뒤"라는 조건으로 위치를 재구성합니다. 그래서 정렬 키가 중복되면 경계에서 문제가 생깁니다. published_at이 초 단위이고 같은 시각에 5건이 등록됐다면, where published_at < :cursor 조건은 그 5건 중 일부를 통째로 건너뛰거나 다음 페이지에서 다시 보여줄 수 있습니다.

Laravel 문서도 커서 페이지네이션의 제약을 명시합니다. 정렬이 최소 하나의 유일한 컬럼 또는 유일한 조합에 기반해야 하고, null 값을 가진 컬럼은 지원하지 않는다는 조건입니다. (출처: Laravel Docs - Cursor Pagination)

MySQL 문서도 같은 함정을 다른 각도에서 설명합니다. ORDER BY 컬럼 값이 동일한 행들의 순서는 비결정적이며, 실행 계획에 따라 달라질 수 있어서 LIMIT이 있을 때와 없을 때 순서가 달라질 수 있다는 것입니다. 순서를 확정하려면 ORDER BY에 컬럼을 더 넣어 결정적으로 만들라는 권고가 따라옵니다. (출처: MySQL 8.4 Reference Manual - LIMIT Query Optimization)

즉 커서 방식으로 넘어갈 때 반드시 해야 하는 일은 정렬 키 뒤에 유일 키를 붙여 tie-breaker를 만드는 것입니다. 정렬 키가 하나뿐인 단순한 목록이라면 기본 키 하나로 충분하지만, "최신순" 같은 정렬은 거의 항상 복합 조건이 됩니다.

프레임워크 없이 직접 구현한다면 이런 형태가 됩니다. PDO 기준으로 동작하는 최소 예시입니다.

<?php

declare(strict_types=1);

/**
 * (published_at DESC, id DESC) 정렬 기준 커서 페이지네이션.
 * 커서는 마지막 행의 (published_at, id) 쌍을 그대로 담는다.
 */
function fetchPage(PDO $pdo, ?string $cursor, int $limit = 20): array
{
    $params = [':limit' => $limit + 1];
    $keyset = '';

    if ($cursor !== null) {
        [$publishedAt, $id] = decodeCursor($cursor);

        // 행 값 비교로 (published_at, id)를 한 덩어리로 다룬다.
        // MySQL 8.x, PostgreSQL, SQLite 모두 지원하는 표준 문법이다.
        $keyset = 'AND (published_at, id) < (:published_at, :id)';
        $params[':published_at'] = $publishedAt;
        $params[':id'] = $id;
    }

    $sql = <<<SQL
        SELECT id, title, published_at
        FROM posts
        WHERE status = 'published'
        {$keyset}
        ORDER BY published_at DESC, id DESC
        LIMIT :limit
    SQL;

    $stmt = $pdo->prepare($sql);
    foreach ($params as $key => $value) {
        $stmt->bindValue($key, $value, $key === ':limit' || $key === ':id' ? PDO::PARAM_INT : PDO::PARAM_STR);
    }
    $stmt->execute();

    $rows = $stmt->fetchAll(PDO::FETCH_ASSOC);

    // limit + 1건을 요청해 두면 COUNT 없이 다음 페이지 존재 여부를 알 수 있다.
    $hasMore = count($rows) > $limit;
    if ($hasMore) {
        array_pop($rows);
    }

    $last = $rows[count($rows) - 1] ?? null;

    return [
        'items' => $rows,
        'nextCursor' => $hasMore && $last !== null
            ? encodeCursor($last['published_at'], (int) $last['id'])
            : null,
    ];
}

function encodeCursor(string $publishedAt, int $id): string
{
    return rtrim(strtr(base64_encode(json_encode([$publishedAt, $id])), '+/', '-_'), '=');
}

/** @return array{0: string, 1: int} */
function decodeCursor(string $cursor): array
{
    $json = base64_decode(strtr($cursor, '-_', '+/'), true);
    $decoded = $json === false ? null : json_decode($json, true);

    if (!is_array($decoded) || count($decoded) !== 2) {
        throw new InvalidArgumentException('Invalid cursor');
    }

    return [(string) $decoded[0], (int) $decoded[1]];
}

이 코드에서 실무적으로 의미 있는 부분은 세 곳입니다.

첫째, (published_at, id) < (:published_at, :id)라는 행 값 비교입니다. 이걸 published_at < :a OR (published_at = :a AND id < :b)로 풀어써도 결과는 같지만, 튜플 비교 쪽이 의도가 분명하고 (published_at, id) 복합 인덱스와도 잘 맞습니다.

둘째, LIMIT에 +1을 더해 한 건 더 읽는 방식입니다. 다음 페이지가 있는지 알기 위해 전체 건수를 세지 않아도 됩니다.

셋째, 커서를 base64로 감싼 이유는 보안이 아니라 계약입니다. 커서를 불투명한 문자열로 정의해 두면, 나중에 정렬 키를 하나 더 추가해도 클라이언트 코드를 고치지 않아도 됩니다. 반대로 커서에 원본 ID를 그대로 노출하면 그 값이 사실상 공개 API 스펙이 되어 버립니다.

COUNT 쿼리는 따로 계산해야 합니다

목록 API가 느릴 때 범인이 목록 쿼리가 아니라 전체 건수 쿼리인 경우가 꽤 있습니다. Laravel 문서는 paginate 메서드가 레코드를 가져오기 전에 조건에 맞는 전체 레코드 수를 먼저 센다고 설명하고, 전체 페이지 수를 UI에 보여줄 계획이 없다면 그 카운트 쿼리는 불필요하므로 simplePaginate로 단일 쿼리만 실행할 수 있다고 안내합니다. (출처: Laravel Docs - Pagination)

그래서 선택지는 두 개가 아니라 세 개입니다.

paginate: 페이지 번호와 전체 건수가 모두 필요할 때. 카운트 쿼리 1회 추가.
simplePaginate: 이전·다음만 필요하지만 OFFSET 구조는 유지하고 싶을 때. 카운트는 없앴지만 뒷페이지 스캔 비용은 남는다.
cursorPaginate: 이전·다음만 필요하고 뒷페이지 성능과 중복 방지가 중요할 때.

중간 단계인 simplePaginate가 의외로 쓸모 있습니다. 커서로 넘어가려면 응답 스펙과 클라이언트를 함께 고쳐야 하지만, 카운트 제거는 서버에서만 끝나는 변경이라 위험이 훨씬 작습니다. 총 건수가 화면 어딘가에 정말 필요하다면 근사치로 타협하는 방법도 있습니다. 검색 결과에 "1,000건 이상"이라고 표시하는 서비스들이 정확한 숫자를 몰라서 그러는 게 아닙니다. 세는 비용이 그 정보의 가치보다 크기 때문입니다.

이미 나간 API를 바꾸는 비용

기술적으로 옳은 선택이라고 해서 지금 바꿀 수 있는 건 아닙니다. 커서 방식은 응답 형태를 바꿉니다. total, last_page, current_page가 사라지고 next_cursor가 생깁니다. 앱 스토어 심사를 거쳐 배포되는 모바일 클라이언트가 붙어 있다면, 구버전 앱은 몇 달 동안 살아 있습니다.

이럴 때 쓸 수 있는 순서가 있습니다.

새 파라미터를 추가만 한다. ?cursor= 가 오면 커서 모드, ?page= 가 오면 기존 모드로 동작시킨다.
응답에 두 형태를 함께 담는다. 기존 필드는 유지하고 next_cursor를 추가한다.
클라이언트를 커서 모드로 전환하고, page 파라미터 사용률을 모니터링한다.
사용률이 충분히 떨어지고 지원 종료 버전이 정리되면 OFFSET 경로를 제거한다.

이 과정에서 놓치기 쉬운 것이 정렬 조건 변경입니다. 커서 도입과 동시에 정렬 키를 created_at에서 published_at으로 바꾸는 식의 변경을 끼워 넣으면, 문제가 생겼을 때 원인이 커서인지 정렬인지 구분할 수 없습니다. 한 번에 하나씩 바꾸는 편이 결국 빠릅니다.

화면별로 어떤 방식이 맞는지

화면	권장	이유
모바일 피드, 무한 스크롤	커서	뒤로 갈수록 느려지지 않고, 중복·누락이 없다
채팅·알림 로그	커서	쓰기가 잦고 최신순 단방향 이동이다
백오피스 검색 결과	OFFSET 유지	운영자가 페이지 번호로 위치를 공유한다
정산·감사 목록	OFFSET + 카운트	전체 건수 자체가 업무 데이터다
공개 목록 페이지 (SEO 필요)	OFFSET	페이지 URL이 색인 대상이어야 한다
데이터 배치 처리	커서	100만 건을 OFFSET으로 순회하면 뒤로 갈수록 느려진다

마지막 줄은 특히 자주 사고가 납니다. 배치 스크립트에서 LIMIT 1000 OFFSET $n으로 전체 테이블을 도는 코드는 초반에는 멀쩡하다가 후반부에 급격히 느려집니다. 게다가 처리 중에 행이 삭제되면 건너뛰는 행이 생깁니다. 키 기반 순회로 바꾸면 두 문제가 동시에 사라집니다.

적용 전 확인할 것

page 파라미터의 실제 사용 분포를 로그로 확인했다.
느린 쪽이 목록 쿼리인지 카운트 쿼리인지 분리해서 측정했다.
정렬 키에 유일 컬럼을 tie-breaker로 붙였다.
정렬에 쓰는 컬럼 조합에 인덱스가 있고 EXPLAIN으로 확인했다.
정렬 컬럼에 null이 들어갈 수 있는지 확인했다.
커서를 불투명 문자열로 정의해 내부 구조 변경 여지를 남겼다.
잘못된 커서가 들어왔을 때 500이 아니라 400으로 응답한다.
응답에서 제거할 필드가 있다면 폐기 일정과 대체 경로를 공지했다.
배치·내보내기 스크립트도 같은 기준으로 점검했다.

FAQ

인덱스를 잘 걸면 OFFSET도 빨라지지 않나요?

정렬 자체는 빨라집니다. 인덱스 순서로 읽으면 filesort를 피할 수 있으니까요. 하지만 인덱스를 탄다고 해도 건너뛸 행을 순서대로 지나가는 일은 남습니다. 뒤쪽 페이지일수록 읽어야 하는 인덱스 엔트리가 늘어나는 구조는 인덱스로 없앨 수 없습니다.

커서 방식에서 "마지막 페이지로 가기"는 어떻게 하나요?

정렬을 뒤집으면 됩니다. 최신순 목록의 마지막 페이지는 오래된 순으로 첫 페이지를 조회한 뒤 결과를 역순으로 뒤집는 것과 같습니다. 다만 임의의 N번째 페이지로 점프하는 기능은 커서 방식으로 만들 수 없습니다. 그게 필요하다면 애초에 커서로 갈 화면이 아닙니다.

커서에 노출되는 ID가 보안 문제가 되지 않나요?

base64는 인코딩이지 암호화가 아니므로 누구나 디코딩할 수 있습니다. 순차 증가하는 ID가 노출되는 것이 문제라면 커서 형식이 아니라 식별자 설계를 봐야 합니다. UUID나 ULID를 쓰거나, 커서에 서명을 붙여 위조를 막는 방법도 있습니다. 다만 서명은 위조 방지일 뿐 내용 은닉은 아닙니다.

사용자가 정렬 기준을 바꿀 수 있는 화면은 어떻게 하나요?

정렬이 바뀌면 기존 커서는 의미를 잃습니다. 정렬 조건을 커서 안에 함께 담고, 요청의 정렬 조건과 다르면 커서를 무시하고 첫 페이지부터 시작하는 편이 안전합니다. 조용히 이상한 결과를 주는 것보다 첫 페이지로 되돌리는 쪽이 디버깅하기 쉽습니다.

이미 잘 돌아가는 서비스도 지금 바꿔야 하나요?

뒷페이지 요청이 거의 없다면 바꿀 이유가 없습니다. 이 선택은 성능 좋은 방식으로 통일하는 문제가 아니라, 화면이 요구하는 이동 방식에 구현을 맞추는 문제입니다. 페이지 번호를 쓰는 사람이 있다면 OFFSET은 그 화면에서 여전히 맞는 답입니다.

남는 질문 하나

이 글의 판단 기준을 한 줄로 줄이면 이렇게 됩니다. 사용자가 목록에서 하는 행동이 "다음을 계속 본다"인지 "특정 위치로 이동한다"인지 먼저 정하고, 그 다음에 쿼리를 고른다.

당장 할 수 있는 일은 두 가지입니다. 접속 로그에서 page 값 분포를 뽑아 보세요. 그리고 가장 느린 목록 API에서 카운트 쿼리와 데이터 쿼리의 시간을 따로 재 보세요. 이 두 숫자만 손에 쥐어도 커서로 갈지, 카운트만 걷어낼지, 아무것도 안 해도 되는지가 대부분 결정됩니다.

정작 어려운 건 기술이 아니라 합의입니다. "총 1,284건"이라는 문구를 화면에서 지워도 되는지 묻는 자리에서 논의가 멈추는 경우가 많습니다. 그 숫자가 누구의 어떤 판단에 쓰이는지 확인하는 것이, 인덱스를 하나 더 만드는 것보다 먼저입니다.

출처

재택근무 생산성을 높이는 체크리스트

Lovizu — Thu, 6 Aug 2026 10:05:14 +0900

재택근무 생산성은 "집에서 일하느냐"보다 "집에서 일하는 방식을 어떻게 설계하느냐"에 더 크게 좌우됩니다. OECD는 관리자와 근로자 모두 재택근무를 대체로 긍정적으로 평가했지만, 이상적인 빈도는 주 2~3일 수준이라고 분석했고, 커뮤니케이션과 지식 흐름 저하가 주요 비용이라고 설명합니다. ILO도 재택근무는 유연성을 주지만 일과 사생활의 경계가 흐려지고 장시간 노동과 고립 위험이 커질 수 있다고 지적합니다. (출처: OECD - The role of telework for productivity during and post-COVID-19, ILO - Working from home: From invisibility to decent work)

요약 박스

재택근무 생산성은 집중 시간 확보, 비동기 문서화, 경계 설정이 핵심입니다.

OECD는 관리자와 근로자 모두 주 2~3일 정도의 중간 수준 재택근무를 이상적으로 보는 경향이 있다고 설명합니다. (출처: OECD - The role of telework for productivity during and post-COVID-19)

ILO는 재택근무가 유연성을 주는 동시에 과로와 고립, 인체공학적 위험을 키울 수 있다고 경고합니다. (출처: ILO - Working from home: From invisibility to decent work)

최종 업데이트: 2026-08-06

작성 관점

저는 재택근무 생산성을 개인 의지 문제로만 보지 않습니다. 좋은 재택근무는 성실함보다 시스템의 품질에서 나옵니다.

1. 재택근무에서 실제로 무너지는 것

재택근무가 힘든 이유는 일이 많아서가 아니라, 일이 섞이기 때문입니다.

메시지 응답과 집중 작업이 같은 시간대를 갉아먹습니다.
"보이는 일"만 남고 생각이 필요한 일이 뒤로 밀립니다.
퇴근 기준이 사라져 피로가 누적됩니다.

ILO는 재택근무가 유연성을 높일 수 있지만 근무시간이 늘어나고 업무와 사생활 경계가 흐려질 수 있다고 지적합니다. OECD도 커뮤니케이션과 지식 흐름이 손상될 때 생산성 이점이 줄어든다고 봅니다. (출처: ILO - Working from home: From invisibility to decent work, OECD Telework and Productivity)

2. 생산성을 높이는 실전 체크리스트

2-1. 집중 시간대를 캘린더에 먼저 잠급니다

재택근무에서 가장 먼저 사라지는 것은 깊게 생각하는 시간입니다. 그래서 오전 90분이나 오후 2시간처럼 "답변하지 않는 시간"을 먼저 확보하는 편이 낫습니다. 이 시간은 단순히 비워두는 것이 아니라, 문서 작성, 분석, 설계처럼 결과물이 남는 일에 써야 효과가 납니다.

2-2. 회의보다 비동기 문서를 우선합니다

재택근무에서는 짧은 질문이 연쇄 회의를 만들기 쉽습니다. 그래서 문제, 선택지, 결정 필요사항을 문장으로 적고 난 뒤 회의를 여는 방식이 효율적입니다. OECD는 하이브리드 근무 환경에서 일정 조정과 온라인 커뮤니케이션 역량이 중요하다고 설명합니다. (출처: OECD - The role of telework for productivity during and post-COVID-19)

2-3. 응답 속도 기준을 팀 단위로 맞춥니다

모든 메시지에 즉시 답해야 한다는 분위기는 재택근무를 계속 인터럽트 상태로 만듭니다. "긴급은 전화, 당일 답변은 메신저, 판단이 필요한 일은 문서"처럼 채널별 기준을 나누면 집중력이 훨씬 덜 깨집니다.

2-4. 장비보다 자세와 환경을 점검합니다

ILO는 재택근무에서 인체공학적 환경이 나쁘면 물리적 위험과 건강 문제가 커질 수 있다고 설명합니다. 비싼 장비를 다 사기 전에도, 모니터 높이, 의자 지지, 손목 각도, 조명, 소음만 정리해도 체감 피로가 줄어듭니다. (출처: ILO - Working from home: From invisibility to decent work, ILO - Human factors/ergonomics considerations for teleworking)

2-5. 퇴근 신호를 물리적으로 만듭니다

재택근무는 출근보다 퇴근이 더 어렵습니다. 노트북 덮기, 메신저 상태 변경, 내일 첫 작업 한 줄 적기 같은 종료 루틴이 있어야 일과 삶이 섞이지 않습니다. ILO는 재택근무가 일과 사생활의 경계를 흐릴 수 있다고 강조합니다. (출처: ILO - Working from home: From invisibility to decent work)

3. 주간 운영 예시

구간	추천 방식	이유
월요일 오전	주간 우선순위 문서화	회의보다 기준을 먼저 맞춤
화~목 오전	집중 작업 블록	분석, 작성, 설계 품질 확보
화~목 오후	협업, 피드백, 1:1	응답성 필요한 일 처리
금요일 오후	회고와 다음 주 준비	맥락 손실 최소화

4. 재택근무 생산성이 떨어질 때 먼저 볼 것

산출물보다 반응성이 더 중요해졌는지

메신저 답장은 빨라졌는데 문서, 보고서, 코드, 제안서 같은 결과물이 느려졌다면 생산성이 오른 것이 아니라 분산된 것입니다.

회의가 문서의 부재를 대체하고 있는지

회의가 많아질수록 정보 공유는 늘어도 의사결정 품질이 좋아진다고 보장할 수는 없습니다. 비동기 정리가 없는 팀은 재택근무에서 특히 피로가 빠르게 쌓입니다.

집에서의 근무 공간이 너무 임시적인지

ILO는 적절한 작업 환경의 중요성을 반복해서 강조합니다. 식탁, 침대, 소파를 오가는 방식은 하루는 가능해도 장기 운영에는 불리합니다. (출처: ILO - Working from home: From invisibility to decent work)

FAQ

재택근무는 무조건 자주 할수록 좋은가요?

OECD 자료는 중간 수준의 하이브리드 형태가 생산성과 웰빙의 균형에 유리할 수 있다고 봅니다. 즉, 빈도보다 설계가 중요합니다. (출처: OECD - The role of telework for productivity during and post-COVID-19)

장비를 사면 바로 생산성이 오르나요?

항상 그렇지는 않습니다. 장비보다 먼저 볼 것은 작업 환경의 안정성, 의사소통 기준, 집중 시간 확보입니다.

출처

AI 플러그인

Lovizu — Thu, 7 May 2026 22:27:05 +0900

AI Coding Agent · Open Source Tools

AI 코딩 에이전트를 더 똑똑하게 만드는 오픈소스 도구들

Claude Code, Codex, Cursor, Gemini CLI 같은 AI 코딩 에이전트를 실제 개발 워크플로우에 붙일 때 필요한 메모리, 토큰 최적화, 코드베이스 분석, 명세화, 작업 관리 도구를 정리했다.

요약

AI 코딩의 생산성은 모델 성능만으로 결정되지 않는다. 에이전트가 기억하고, 로그를 줄이고, 코드베이스를 이해하고, 요구사항을 명세화하고, 작업 상태를 추적할 수 있어야 실제 개발 환경에서 안정적으로 쓸 수 있다.

Claude Code, Codex, Cursor, Gemini CLI 같은 AI 코딩 에이전트는 이제 단순한 코드 자동완성 도구가 아니다. 최근에는 코드 작성, 테스트 실행, 리팩터링, 문서 분석, 프로젝트 구조 파악, PR 리뷰까지 처리하는 방향으로 발전하고 있다.

하지만 AI 코딩 에이전트를 실제 개발 환경에서 사용하다 보면 모델 성능만으로는 해결되지 않는 문제가 계속 나온다.

예를 들면 이런 것들이다.

이전 대화나 사용자 선호를 기억하지 못한다.
프로젝트 구조를 매번 다시 분석해야 한다.
테스트 로그와 터미널 출력이 너무 길어 컨텍스트를 많이 사용한다.
여러 에이전트가 동시에 작업할 때 상태를 파악하기 어렵다.
요구사항이 조금만 모호해도 결과물이 흔들린다.
프롬프트가 길어질수록 작업 흐름이 불안정해진다.

처음에는 “어떤 모델이 코드를 더 잘 짜는가”가 가장 중요해 보인다. 하지만 실제로 오래 사용해보면 모델 자체만큼이나 중요한 것이 있다. 바로 모델이 일하기 좋은 환경을 만들어주는 도구들이다.

이 글에서는 AI 코딩 에이전트의 생산성을 높이는 오픈소스 도구들을 정리한다. 메모리, 토큰 최적화, 코드베이스 분석, 명세 기반 개발, 작업 상태 시각화 같은 영역에서 주목할 만한 도구들이다.

AI 코딩 에이전트에 보조 도구가 필요한 이유

AI 코딩 에이전트는 기본적으로 컨텍스트 안에서 동작한다. 모델이 아무리 좋아도 입력으로 들어가는 정보가 부족하거나 지저분하면 좋은 결과를 내기 어렵다.

예를 들어 테스트가 실패했을 때 전체 로그 5,000줄을 그대로 모델에게 전달한다고 생각해보자. 실패 원인은 몇 줄이면 충분할 수 있다. 하지만 성공한 테스트 로그, 반복되는 경고, 빌드 메시지, 환경 정보가 함께 들어가면 모델은 불필요한 정보까지 모두 처리해야 한다.

프로젝트 구조도 마찬가지다. 처음 보는 코드베이스에서 에이전트가 파일 관계를 제대로 이해하지 못하면, 리팩터링이나 기능 추가 과정에서 잘못된 추측을 하게 된다.

또한 사용자의 선호나 프로젝트 규칙을 기억하지 못하면 매번 같은 설명을 반복해야 한다. 응답 스타일, 테스트 방식, 배포 방식, 브랜치 전략 같은 정보를 계속 다시 알려줘야 한다면 에이전트 사용 경험은 금방 피곤해진다.

결국 AI 코딩 에이전트를 제대로 활용하려면 다음과 같은 보조 계층이 필요하다.

영역	필요한 기능
메모리	사용자 선호, 프로젝트 규칙, 작업 패턴 저장
컨텍스트 관리	긴 로그와 불필요한 출력 압축
코드 이해	파일, 모듈, 문서 간 관계 파악
명세화	애매한 요구사항을 실행 가능한 스펙으로 변환
상태 관리	여러 에이전트의 작업 진행 상황 추적
응답 최적화	장황한 설명을 줄이고 핵심만 전달

아래 도구들은 각각 이런 문제를 해결하기 위해 만들어진 오픈소스 프로젝트들이다.

1. mem0: AI 에이전트를 위한 장기 메모리 레이어

GitHub: https://github.com/mem0ai/mem0

mem0는 AI 에이전트에 장기 기억을 추가하는 메모리 레이어다. AI 코딩 도구가 사용자와 프로젝트에 대한 정보를 저장하고, 이후 대화나 작업에서 다시 활용할 수 있게 해준다.

일반적인 AI 챗봇이나 코딩 에이전트는 세션이 바뀌면 이전 맥락을 잃는다. 컨텍스트 창 안에 남아 있는 정보만 사용할 수 있기 때문이다. 반면 mem0 같은 메모리 시스템을 사용하면 다음과 같은 정보를 장기적으로 저장할 수 있다.

사용자의 응답 선호도
프로젝트별 코딩 컨벤션
자주 사용하는 명령어
반복되는 디버깅 절차
특정 저장소의 구조와 규칙
에이전트가 기억해야 하는 장기 설정

AI 코딩 에이전트에서 메모리는 단순한 편의 기능이 아니다. 반복 설명을 줄이고, 프로젝트별 작업 일관성을 높이는 기반 기능에 가깝다.

예를 들어 사용자가 “테스트는 항상 pytest로 돌리고, 긴 설명보다 결과 중심으로 말해줘”라고 설정했다면, 에이전트가 이 내용을 기억하고 다음 작업에서도 반영할 수 있다. 매번 같은 지시를 반복하지 않아도 되는 것이다.

다만 메모리 시스템을 사용할 때는 저장 대상을 신중하게 정해야 한다. API 키, 비밀번호, 토큰 같은 민감 정보는 저장하면 안 된다. 또한 오래 지나면 틀릴 수 있는 임시 정보도 장기 메모리에 넣지 않는 편이 좋다.

좋은 메모리 시스템은 많이 저장하는 시스템이 아니다. 필요한 정보를 정확하게 저장하고, 불필요한 기억을 줄이는 시스템이다.

2. Honcho: 상태를 가진 AI 에이전트를 위한 메모리 시스템

GitHub: https://github.com/plastic-labs/honcho

Honcho는 상태를 가진 AI 에이전트를 만들기 위한 메모리 라이브러리다. 대화 이력과 사용자 상호작용을 저장하고, 이를 바탕으로 에이전트가 더 일관된 응답과 행동을 하도록 돕는다.

Honcho는 단순한 데이터 저장소라기보다 사용자와 에이전트 사이의 장기적 관계를 모델링하려는 성격이 강하다. 사용자가 어떤 방식으로 요청하는지, 어떤 결과를 선호하는지, 어떤 작업 패턴을 반복하는지를 기록하고 다음 작업에 반영한다.

AI 개발 에이전트가 Honcho 같은 메모리 시스템을 활용하면 다음과 같은 방식으로 동작할 수 있다.

사용자가 선호하는 설명 길이를 기억한다.
특정 프로젝트에서 사용하는 테스트 명령어를 기억한다.
자동 실행보다 사전 확인이 필요한 작업을 구분한다.
반복되는 업무 흐름을 다음 세션에서도 이어간다.
사용자의 작업 스타일에 맞춰 응답 방식을 조정한다.

AI 에이전트를 단발성 도구로 본다면 메모리는 없어도 된다. 하지만 매일 사용하는 개발 파트너로 본다면 이야기가 달라진다.

같은 프로젝트를 계속 다루고, 같은 사용자의 요청을 반복해서 처리하고, 장기적인 작업 흐름을 이어가야 한다면 메모리는 중요한 기반 기술이 된다.

3. RTK: AI 코딩 에이전트의 터미널 출력 토큰 줄이기

GitHub: https://github.com/rtk-ai/rtk Website: https://www.rtk-ai.app

RTK, Rust Token Killer는 AI 에이전트가 실행하는 터미널 명령어의 출력을 압축하는 CLI 프록시 도구다.

AI 코딩 에이전트는 개발 중 다양한 명령어를 실행한다.

git status npm test pytest cargo test docker compose logs

문제는 이 출력이 매우 길다는 점이다. 테스트 실패 원인은 몇 줄이면 충분한데, 실제 로그에는 성공한 테스트, 반복 경고, 빌드 메시지, 환경 정보가 함께 포함된다.

사람은 긴 로그에서 필요한 부분만 읽고 넘어갈 수 있다. 하지만 AI 에이전트는 출력 전체를 컨텍스트로 받는다. 그 결과 토큰이 낭비되고, 중요한 오류 메시지가 불필요한 정보에 묻힐 수 있다.

RTK는 명령어 출력 중 핵심 정보만 남기고 압축한다. 예를 들어 테스트 실행 결과에서는 실패한 테스트, 에러 메시지, 관련 스택트레이스 위주로 정리한다.

RTK가 특히 유용한 상황은 다음과 같다.

테스트 로그가 긴 프로젝트
빌드 출력이 많은 Rust, Node.js, Python 프로젝트
AI 에이전트가 터미널 명령을 자주 실행하는 환경
API 기반 모델 사용으로 토큰 비용이 중요한 경우
컨텍스트 창을 효율적으로 관리해야 하는 경우

AI 코딩에서 비용을 줄이는 방법은 모델을 낮추는 것만이 아니다. 모델에 전달되는 입력 자체를 줄이는 것도 중요한 최적화다.

개인적으로 RTK 같은 도구는 AI 개발 환경에서 점점 더 중요해질 가능성이 높다고 본다. 모델이 보는 정보를 줄이고 정리하는 것만으로도 응답 품질과 비용 효율이 달라질 수 있기 때문이다.

4. caveman: AI 응답을 짧게 압축하는 플러그인

GitHub: https://github.com/juliusbrussee/caveman

caveman은 Claude Code와 여러 AI 코딩 에이전트의 응답을 짧고 직접적인 문장으로 바꿔주는 플러그인이다.

AI 코딩 도구를 사용하다 보면 응답이 지나치게 길어지는 경우가 많다. 원인은 간단한데, 설명은 장황하다. 이미 알고 있는 배경 설명이나 불필요한 친절한 문장이 반복되기도 한다.

caveman은 이런 응답을 “원시인 말투”에 가깝게 압축한다.

예를 들어 일반적인 응답이 다음과 같다면:

React 컴포넌트가 매 렌더링마다 새로운 객체 참조를 생성하고 있기 때문에 리렌더링이 발생할 가능성이 높습니다. inline object를 prop으로 전달하면 React의 shallow comparison에서 매번 다른 객체로 인식됩니다. useMemo를 사용해 객체를 메모이제이션하는 것이 좋습니다.

caveman 스타일은 다음처럼 줄어든다.

새 object ref 매 render. inline prop = re-render. useMemo 써라.

조금 장난스러운 컨셉처럼 보이지만 실제로는 실용적인 면이 있다. 개발 중에는 긴 설명보다 원인과 해결책만 빠르게 보고 싶을 때가 많다.

caveman이 잘 맞는 상황은 다음과 같다.

빠른 디버깅
PR 리뷰 코멘트
커밋 메시지 작성
단순 오류 원인 파악
반복적인 개발 명령 결과 확인

물론 모든 작업에 적합한 방식은 아니다. 아키텍처 설계, 문서 작성, 복잡한 트러블슈팅에서는 충분한 설명이 필요하다. 하지만 빠른 피드백 루프가 중요한 개발 작업에서는 응답을 짧게 유지하는 것이 오히려 생산성을 높인다.

5. graphify: 코드베이스를 지식 그래프로 변환하기

GitHub: https://github.com/safishamsi/graphify

graphify는 프로젝트 폴더를 분석해 코드, 문서, 스키마, 스크립트, 이미지, PDF 등을 지식 그래프로 변환하는 도구다.

AI 코딩 에이전트에게 큰 코드베이스를 맡길 때 가장 큰 문제는 프로젝트 이해다. 작은 프로젝트라면 파일 몇 개만 읽어도 충분하다. 하지만 실제 서비스 코드는 보통 여러 언어와 문서, 설정 파일, 데이터 스키마가 섞여 있다.

graphify는 이런 프로젝트를 분석해 다음과 같은 결과물을 만든다.

graphify-out/ ├── graph.html ├── GRAPH_REPORT.md └── graph.json

각 파일의 역할은 다음과 같다.

파일	설명
graph.html	브라우저에서 확인할 수 있는 시각화 그래프
GRAPH_REPORT.md	주요 개념, 연결 관계, 분석 요약
graph.json	에이전트나 도구가 재사용할 수 있는 그래프 데이터

기본 사용 예시는 다음과 같다.

graphify .

AI 코딩 에이전트 내부에서는 /graphify . 형태로 사용할 수 있다.

graphify가 특히 유용한 경우는 다음과 같다.

처음 보는 레거시 코드베이스 분석
대형 저장소 구조 파악
코드와 문서 간 관계 확인
SQL 스키마와 애플리케이션 코드 연결 분석
AI 에이전트에게 프로젝트 맥락 제공

일반적인 코드 검색이 문자열 중심이라면, graphify는 관계 중심이다. 파일과 개념이 어떻게 연결되는지 파악해야 하는 작업에 적합하다.

AI 에이전트가 프로젝트를 제대로 이해하려면 단순히 파일 내용을 많이 읽는 것만으로는 부족하다. 어떤 파일이 어떤 개념과 연결되어 있는지, 어떤 모듈이 어떤 역할을 하는지 파악해야 한다. graphify는 이 부분을 도와주는 도구라고 볼 수 있다.

6. Ouroboros: 프롬프트 중심 개발에서 명세 중심 개발로

GitHub: https://github.com/Q00/ouroboros

Ouroboros는 AI 코딩을 위한 Agent OS를 지향하는 도구다. 핵심 메시지는 명확하다.

Stop prompting. Start specifying.

즉, AI 에이전트에게 즉흥적인 프롬프트를 던지는 대신 먼저 요구사항을 명확한 명세로 만들고, 그 명세를 기준으로 실행과 평가를 반복하자는 접근이다.

Ouroboros의 기본 흐름은 다음과 같다.

interview -> specify -> execute -> evaluate -> evolve

이 방식은 AI 코딩에서 자주 발생하는 문제를 줄인다. 대부분의 실패는 모델이 코드를 전혀 못 짜서 생기기보다, 요구사항이 애매한 상태에서 에이전트가 추측을 시작하면서 생긴다.

예를 들어 다음과 같은 요청을 생각해볼 수 있다.

태스크 관리 CLI 만들어줘.

이 요청만으로는 결정되지 않은 것이 많다.

데이터는 파일에 저장할 것인가, 데이터베이스에 저장할 것인가?
태스크 상태는 어떤 값들을 가질 것인가?
마감일과 우선순위가 필요한가?
여러 사용자를 지원해야 하는가?
테스트 기준은 무엇인가?
CLI 명령어 구조는 어떻게 할 것인가?

Ouroboros는 이런 모호한 지점을 먼저 질문으로 끄집어낸다. 그 다음 실행 가능한 명세를 만들고, 에이전트가 해당 명세를 기준으로 작업하도록 만든다.

AI 코딩이 복잡해질수록 단순 프롬프트보다 명세와 검증 흐름이 중요해진다. Ouroboros는 이 방향을 잘 보여주는 도구다.

프롬프트를 잘 쓰는 것도 중요하지만, 더 중요한 것은 요구사항을 실행 가능한 형태로 정리하는 능력이다. AI 에이전트가 강해질수록 이 차이는 더 커질 가능성이 높다.

7. Pixel Agents: AI 에이전트 작업 상태 시각화

GitHub: https://github.com/orseni/pixel-agents

Pixel Agents는 Claude Code 세션을 픽셀 아트 오피스 형태로 시각화하는 도구다.

AI 에이전트를 하나만 사용할 때는 터미널 하나로도 충분하다. 하지만 여러 프로젝트에서 여러 에이전트를 동시에 실행하면 상태 관리가 어려워진다.

예를 들어 다음과 같은 상황이 생긴다.

어떤 에이전트가 아직 실행 중인지 모른다.
어떤 프로젝트에서 작업 중인지 헷갈린다.
어느 세션이 멈췄는지 확인하기 어렵다.
결과를 검토해야 하는 작업을 놓친다.

Pixel Agents는 이런 문제를 시각적으로 해결하려는 시도다. Claude Code 세션을 캐릭터처럼 표시하고, 각 에이전트가 어떤 상태인지 한눈에 볼 수 있게 만든다.

이 도구는 당장 필수 개발 도구라기보다는 멀티 에이전트 환경에서 필요한 관제 UI의 가능성을 보여준다. 앞으로 AI 에이전트를 병렬로 실행하는 개발 방식이 늘어난다면, 이런 시각화 도구의 필요성도 커질 수 있다.

8. claude-code-kanban: AI 에이전트 작업을 칸반으로 관리하기

명령어:

npx claude-code-kanban

AI 코딩 에이전트에게 작업을 맡기면 대화창 안에서 모든 일이 흘러가는 경우가 많다. 작업이 짧을 때는 문제가 없지만, 기능 개발이나 리팩터링처럼 단계가 많은 작업에서는 상태 관리가 필요하다.

칸반 방식은 AI 에이전트 작업 관리에도 잘 맞는다.

할 일
진행 중
리뷰 필요
완료
실패 또는 보류

이런 상태를 명확히 나누면 여러 작업을 동시에 다루기 쉬워진다. 특히 Claude Code 같은 에이전트를 여러 개 실행하거나, 기능 단위로 작업을 나눠 맡길 때 유용하다.

AI 에이전트를 단순한 채팅 도구가 아니라 작업 실행자로 본다면, 작업 보드와 상태 추적은 자연스럽게 필요해진다.

사람이 개발할 때도 이슈, 브랜치, PR, 체크리스트, 칸반 보드를 사용한다. AI 에이전트 작업도 결국 비슷한 관리 체계가 필요하다.

AI 코딩 도구 생태계의 변화

AI 코딩 도구는 이제 모델 하나로 끝나는 구조가 아니다. 실제 개발 환경에서는 모델 주변에 여러 계층이 필요하다.

계층	대표 도구	역할
장기 메모리	mem0, Honcho	사용자 선호와 프로젝트 맥락 저장
토큰 최적화	RTK, caveman	터미널 출력과 응답 토큰 절약
코드 이해	graphify	코드베이스를 지식 그래프로 분석
명세 기반 실행	Ouroboros	요구사항을 명세와 평가 루프로 변환
상태 시각화	Pixel Agents	여러 에이전트 작업 상태 확인
작업 관리	claude-code-kanban	AI 작업을 태스크 단위로 추적

이 구조를 보면 AI 코딩의 방향이 조금 더 분명해진다.

앞으로 중요한 것은 단순히 “어떤 모델이 코드를 더 잘 쓰는가”만이 아니다. 모델이 일하기 좋은 환경을 어떻게 구성하느냐도 중요하다.

좋은 메모리는 반복 설명을 줄인다. 좋은 컨텍스트 관리는 모델의 집중도를 높인다. 좋은 코드 그래프는 프로젝트 이해도를 높인다. 좋은 명세는 결과물의 일관성을 높인다. 좋은 작업 관리는 멀티 에이전트 운영을 가능하게 한다.

AI 개발 환경은 점점 하나의 챗봇이 아니라, 여러 도구가 연결된 작업 시스템으로 바뀌고 있다.

결론

AI 코딩 에이전트를 제대로 활용하려면 모델 성능만 볼 것이 아니라, 주변 도구까지 함께 봐야 한다.

mem0와 Honcho는 에이전트가 사용자를 기억하게 만든다. RTK와 caveman은 토큰 낭비를 줄인다. graphify는 코드베이스 이해를 돕는다. Ouroboros는 프롬프트 중심 작업을 명세 중심 작업으로 바꾼다. Pixel Agents와 claude-code-kanban은 여러 에이전트의 상태를 관리하는 방향을 보여준다.

AI 코딩의 다음 단계는 더 좋은 모델을 쓰는 것만이 아니다. 모델이 더 정확하게 판단하고, 덜 헤매고, 더 오래 맥락을 유지할 수 있도록 개발 환경을 설계하는 것이다.

결국 생산성 차이는 모델 자체보다 워크플로우에서 날 수도 있다. AI 에이전트를 많이 사용할수록 이런 보조 도구들의 가치는 더 커질 것이다.

참고 링크

mem0: https://github.com/mem0ai/mem0
Honcho: https://github.com/plastic-labs/honcho
RTK: https://github.com/rtk-ai/rtk
RTK 홈페이지: https://www.rtk-ai.app
caveman: https://github.com/juliusbrussee/caveman
graphify: https://github.com/safishamsi/graphify
Ouroboros: https://github.com/Q00/ouroboros
Pixel Agents: https://github.com/orseni/pixel-agents

정리하면
AI 코딩 에이전트의 다음 경쟁력은 “더 좋은 모델” 하나가 아니라, 모델이 일하기 좋은 개발 환경을 어떻게 설계하느냐에서 나온다. 메모리, 컨텍스트 압축, 코드 그래프, 명세, 작업 보드가 함께 연결될 때 AI 에이전트는 단순한 챗봇이 아니라 실질적인 개발 파트너가 된다.

Aqara G4와 구형 레거시 초인종 어색하지 않게 쓰기 (feat 홈킷)

Lovizu — Fri, 28 Mar 2025 00:06:08 +0900

서론 (히스토리)

이번에 이사를 하면서, 하고 싶었던 IOT 제품들을 많이 설치했습니다 (전동 커튼, 전등 3선 스위치 등등), 그러나 안타깝게도, 우리집은 오래된 구축 아파트, 공동현관과 기존 초인종이 레거시 아날로그 방식이다. 기존 레거시를 탈거하여 IOT 제품을 달던지, 그대로 쓸건지 결정해야했습니다.

우리 가족의 선택은 레거시를 탈거하고, 아카라의 G4를 카메라를 달았습니다.

Aqara G4

아카라 G4 구매링크

한 1년정도는 만족하고 있었습니다. 아파트의 공동현관은 인터컴으로 볼수 있었지만, 아카라 초인종의 이벤트는 아이폰으로 오기때문에, 어른들은 불편하지 않고 생활이 가능했습니다. 그러다가 첫째가 초등학교를 입학하게 되었고, 현관문 열기 교육상 방문자의 얼굴을 확인해야하는 문제를 마주하게 됩니다.

구형 아파트에서 아카라 G4를 사용하여, 방문자의 얼굴을 확인하는 방법은 비싸다고 소문난 아카라 S1을 구매하거나, 애플티비를 사용하면 됩니다. 하지만 집에 TV도 없는 우리집에서 애플티비가 무슨 소용이고, 기존 월패드를 탈거하고 S1을 달면, 공동현관을 열지도, 보지도 못하게 됨으로 두개를 동시에 달고 있어야하는데, 아내에게 등짝 스매시 각이기에, 어쩔수 업싱 아카라 G4를 탈거하였습니다.

그러나 외부에서도 방문자를 확인하는 재미가 쏠쏠했는데, 아쉬움이 많이 남아 고심하게 되었고 이 글을 쓸수 있게 되었습니다.

본론 (작업일지)

1. 우선 우리의 구형 레거시 초인종 업체는 코맥스입니다. 코맥스를 HA 에 연결하는 작업을 해보기로 했습니다. (포기)

- 스마트홈 카페에 도움을 받아 기존 아날로그 신호를 이지캡이라는 장비로 HA 에 옮길수 있다는 정보를 얻었지만, 주방선이나 화장실에서 방문자를 확인하는 선로를 인테리어하면서 다 제거하여 딱봐도 나의 똥손으로 가능하지 않을것 같아서 포기했다.

2. 코맥스가 울릴 때 G4 에게 이벤트를 주는 방법 (실패)

- G4를 HA에 등록하여 코맥스에서 초인종이 눌렸을 때 G4에게 이벤트를 주는 방향으로 도전하였따.

- 외국 포럼에 보니 성공자들도 많기 코맥스 물리버튼이 눌릴 때 전자 신호로 바꾸는 여러가지 기술이 있었지만, 전자, 전기 기호가 워낙 많아 문과인 나는 그냥 포기했다.

3. G4 이벤트를 코맥스에게 주는 방법 1차 (실패)

- 위에 1~2번 을 도전하는 중에 코맥스 초인종 4선중에 흰색과 빨간색이 접전이 일어나면 초인종 이벤트가 발생한다는 것을 알아냈다. 이에 G4를 HA 에 등록하여 이벤트를 뽑아서 코맥스의 흰+빨 선을 드라이 컨택하려고 시도했다.

- G4를 HA에 등록하면, 양방향 대화가 안된다..... 이러면 초인종으로써 역할이 ... 안됨으로 실패

4. G4 이벤트를 코맥스에게 주는 방법 2차 (성공)

- 외국 포럼에서 G4 초인종 눌림 이벤트를 홈킷에서는 못뽑지만 홈킷의 서드파티앱들 (eva, home+ 등등 유료앱임)은 뽑을수 있음을 알게되었다. 보니간 과거 홈킷에 미쳤을 때 구매한 내역이 있어서 이것저것 해보니 모든 서드파티앱들이 G4의 버튼 눌림 이벤트를 받을수 있었다.

- HA 에 가상 스위치를 만들어서 홈킷 서드파티앱으로 초인종이 눌리면, 가상 스위치를 누르는 방법으로 기존 코맥스의 스위치 이벤트를 주는데 성공했다.

- G4와 기존 초인종을 나란히 설치해서 썼는데, 사람들이 헷갈려해서 두개의 제품을 합쳐놓기로 했고 지금의 모습이 되었다.

- 기존 코맥스의 플라스틱 몸통을 다 분해 해체하여서 카메라, 스피커, 보드만 뽑아서 나무판에 박았고 그 나무판 위에 G4를 설치했다.

결론

손재주가 없어서 나무판이 좀 어색하지만 그래도 이번에도 하고 싶었던 일을 여러가지 방법을 써서 성공한 것에 뿌듯함을 느낀다.

이제는 누가 방문하여 G4를 누르면, 아이폰으로는 방문자 푸쉬가 오고 집에서는 월패드로 방문자가 확인이 된다.

이런식으로 문제를 해결한 것은 단순 구글링으로 볼때 세계최초인것 같은데 ㅎㅎㅎ

개발자 정신이 이번에도 승리를 거둔게 아닌가 싶어 기분이 좋다.

이상 "세상에 안되는게 어딨어"를 입에 달고 사는 감성개발자였습니다.

ps..

응용으로 밤 늦은시간에는 코맥스에 이벤트를 주지 않고, 핸드폰으로만 푸쉬를 오게하여서 애들 몰래 배달도 가능하다 ㅎㅎ

구매링크로 접속하여 제품을 구매할 경우 소정의 수수료를 받습니다 (구매자님에게 추가금을 받는 것은 아님)

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

Laravel 서버리스(Bref)에서 could not find driver (pgsql) 해결하기

Lovizu — Wed, 29 Jan 2025 22:35:59 +0900

Laravel 애플리케이션을 AWS Lambda에 올리고 PostgreSQL에 붙이려는데 이런 에러가 나올 때가 있다.

PDOException: could not find driver (Connection: pgsql, SQL: select * from ...)

로컬에서는 잘 되던 게 Lambda에서만 터진다. 원인은 런타임 이미지에 PDO PostgreSQL 확장이 안 들어 있어서다.

왜 이런 일이 생기나

서버리스 PHP 런타임(Bref 등)은 Lambda의 용량 제한 때문에 확장을 최소한만 넣어서 배포한다. MySQL용 pdo_mysql은 기본 포함이지만 pdo_pgsql은 빠져 있는 경우가 많다.

로컬 개발 환경의 PHP에는 대부분 둘 다 깔려 있으니 로컬 테스트에서는 안 잡힌다. 배포하고 나서야 발견하게 되는 전형적인 케이스다.

해결: php/conf.d 에 확장 활성화 파일 추가

프로젝트 루트에 다음 경로로 디렉터리와 파일을 만든다.

프로젝트루트/
└── php/
    └── conf.d/
        └── pgsql.ini

파일 내용은 한 줄이면 된다.

extension=pdo_pgsql

Bref는 배포 시 php/conf.d 아래의 .ini 파일을 자동으로 읽어 런타임 설정에 반영한다. 별도 설정 없이 이 경로에 두기만 하면 된다.

serverless.yml 확인

레이어에 확장이 실제로 포함되는지도 같이 봐야 한다. Bref는 확장별 레이어를 따로 제공한다.

functions:
  web:
    handler: public/index.php
    layers:
      - ${bref:layer.php-83-fpm}
      - ${bref-extra:pgsql-php-83}

bref-extra 플러그인을 쓰면 pgsql, redis, gd 같은 추가 확장을 레이어로 붙일 수 있다. serverless-lift나 Bref 버전에 따라 이름이 조금씩 다르니 사용 중인 버전 문서를 확인하는 게 좋다.

배포 후 확인하는 법

확장이 제대로 올라갔는지는 Lambda에서 직접 확인하는 게 빠르다.

# 로컬에서 Lambda 함수 호출
vendor/bin/bref cli 함수이름 -- artisan tinker

# 또는 간단한 라우트 하나 만들어서
Route::get('/_ext', fn() => implode(', ', get_loaded_extensions()));

pdo_pgsql 이 목록에 있으면 성공이다.

같은 원리로 자주 겪는 것들

이 에러는 pgsql만의 문제가 아니다. 서버리스 환경에서 확장이 빠져서 나는 에러는 패턴이 같다.

could not find driver → PDO 드라이버 누락 (pgsql, sqlsrv 등)
Class "Redis" not found → redis 확장 누락
Call to undefined function imagecreate() → gd 확장 누락
Call to undefined function bcadd() → bcmath 확장 누락

전부 같은 방식으로 접근하면 된다. 해당 확장 레이어를 추가하고, 필요하면 php/conf.d에 extension= 한 줄을 넣는다.

그 전에 한 가지 더 확인할 것

드라이버 문제가 아닌데 같은 에러가 나는 경우도 있다. config/database.php의 커넥션 이름이 잘못됐거나, .env의 DB_CONNECTION 값이 오타인 경우다.

DB_CONNECTION=pgsql   # pgsql 이 맞는지 확인 (postgres, postgresql 아님)

에러 메시지에 (Connection: pgsql) 이라고 커넥션명이 찍히니, 그 값이 config/database.php에 정의된 키와 일치하는지 먼저 보면 시간을 아낄 수 있다.

정리

서버리스 PHP 런타임은 용량 때문에 확장을 최소한만 포함한다
php/conf.d/pgsql.ini 에 extension=pdo_pgsql 추가
레이어에도 해당 확장이 포함돼 있어야 한다 (bref-extra)
get_loaded_extensions() 로 배포 후 확인
redis, gd, bcmath 등 다른 확장 누락도 같은 방식으로 해결

(주) 티씨팩 (www.tcpack.co.kr)

Lovizu — Thu, 21 Nov 2024 15:54:58 +0900

총 제작 시간 : 1m

1. 디자인 + 기획 : 5d

2. 개발 : 10d

3. 기타 조율 및 조정 : 5d

4. 개발 인원 : 1명

작업내용

1. SEO (검색 최적화)

2. 디자인

3. 상품 등록

4. 도메인 관리

5. 이미지 등록 및 캐시 작업

작업 리서치

성능 리서치

검색엔진 최적화

검사 결과 : https://pagespeed.web.dev/analysis/https-tcpack-co-kr/cuz64p8cln?utm_source=search_console&form_factor=desktop&hl=ko

Watchtower로 도커 컨테이너 자동 업데이트하기, 그리고 운영에서 조심할 점

Lovizu — Tue, 5 Nov 2024 21:31:28 +0900

홈서버나 개인 프로젝트에 도커 컨테이너를 여러 개 띄워두면 이미지 업데이트를 챙기는 게 일이 된다. docker pull 하고 컨테이너 지우고 다시 띄우는 걸 컨테이너 수만큼 반복해야 한다.

이걸 자동으로 해주는 게 Watchtower다.

실행

docker run -d \
  --name=watchtower \
  -e TZ=Asia/Seoul \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --restart=always \
  containrrr/watchtower --cleanup

각 옵션의 의미는 이렇다.

-v /var/run/docker.sock:/var/run/docker.sock : 호스트의 도커 소켓을 마운트해서 다른 컨테이너를 제어할 수 있게 한다. Watchtower 동작의 핵심이다.
--cleanup : 업데이트 후 낡은 이미지를 삭제한다. 이걸 빼면 dangling 이미지가 계속 쌓여 디스크를 잡아먹는다.
--restart=always : 호스트 재부팅 후에도 Watchtower가 자동으로 뜬다.
-e TZ=Asia/Seoul : 로그 시각과 스케줄 기준 시간대.

기본 주기는 24시간이다. 실행하면 등록된 모든 컨테이너의 이미지를 주기적으로 확인해서 새 버전이 있으면 pull 받고 같은 옵션으로 재생성한다.

docker-compose로 쓰기

services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: always
    environment:
      - TZ=Asia/Seoul
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_SCHEDULE=0 0 4 * * *   # 매일 새벽 4시
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

WATCHTOWER_SCHEDULE은 6자리 cron 형식이다. 맨 앞이 초 단위라는 점만 주의하면 된다. 새벽 시간대로 잡아두면 재시작 순간의 다운타임이 덜 거슬린다.

특정 컨테이너만 대상으로 하기

전부 자동 업데이트하는 게 부담스러우면 대상을 좁힐 수 있다. 두 가지 방식이 있다.

1. 이름으로 지정

docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --cleanup nginx redis

2. 라벨 기반 (권장)

services:
  watchtower:
    image: containrrr/watchtower
    environment:
      - WATCHTOWER_LABEL_ENABLE=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  myapp:
    image: myapp:latest
    labels:
      - "com.centurylinklabs.watchtower.enable=true"

라벨 방식이 관리하기 좋다. 새 서비스를 추가할 때 Watchtower 설정을 건드릴 필요 없이 라벨만 붙이면 된다. 반대로 특정 컨테이너만 제외하려면 enable=false를 붙인다.

알림 붙이기

자동으로 돌아가는 만큼 무엇이 언제 업데이트됐는지는 알아야 한다.

environment:
  - WATCHTOWER_NOTIFICATIONS=shoutrrr
  - WATCHTOWER_NOTIFICATION_URL=slack://token@channel
  - WATCHTOWER_NOTIFICATIONS_LEVEL=info

shoutrrr를 통해 Slack, Discord, Telegram, 이메일 등을 지원한다. 업데이트 알림이 오면 그때 해당 서비스가 정상인지 한 번 확인하는 습관을 들이면 좋다.

운영 환경에서 조심할 점

여기가 중요하다. Watchtower는 편하지만 운영 서비스에 그대로 쓰기에는 위험하다.

latest 태그는 언제 무엇이 바뀔지 모른다. 메이저 버전이 올라가면서 breaking change가 들어와도 그대로 받아버린다. 자고 일어나면 서비스가 죽어 있을 수 있다.
도커 소켓 마운트는 사실상 호스트 루트 권한이다. Watchtower 컨테이너가 뚫리면 호스트 전체가 뚫린다. 인터넷에 노출된 서버라면 신중해야 한다.
재시작 순간 다운타임이 생긴다. 컨테이너를 지우고 다시 만드는 방식이라 무중단이 아니다.
롤백이 자동이 아니다. 새 이미지가 문제여도 알아서 되돌리지 않는다.

그래서 나는 이렇게 나눠서 쓴다.

환경	방식
홈서버, 개인 프로젝트	Watchtower 자동 업데이트
사내 도구, 스테이징	Watchtower + 알림, 태그는 마이너 고정
운영 서비스	CI/CD 파이프라인에서 명시적 배포

알림만 받고 업데이트는 수동으로

절충안도 있다. 새 이미지가 있는지 확인만 하고 실제 업데이트는 안 하도록 설정할 수 있다.

environment:
  - WATCHTOWER_MONITOR_ONLY=true

이러면 "새 버전 나왔다"는 알림만 오고 컨테이너는 그대로 둔다. 운영 환경에서는 이 모드가 현실적이다.

정리

Watchtower는 도커 소켓을 마운트해서 다른 컨테이너를 자동 갱신한다
--cleanup을 빼면 낡은 이미지가 디스크에 쌓인다
대상 지정은 라벨 방식이 관리하기 좋다
latest 자동 업데이트는 운영에서 위험하다
도커 소켓 마운트 = 사실상 호스트 루트 권한
운영이라면 WATCHTOWER_MONITOR_ONLY=true로 알림만 받는 것을 권한다

JetBrains IDE 한글 언어팩이 안 먹을 때, 설정 위치가 바뀌었다

Lovizu — Thu, 26 Sep 2024 09:21:28 +0900

PhpStorm이나 IntelliJ에서 한글 언어팩을 켰는데 UI가 그대로 영어인 경우가 있다. 캐시를 지워도, IDE를 재시작해도 안 바뀐다.

원인은 단순한데 찾기가 어렵다. 언어팩을 enable 하는 것과, 실제로 사용할 언어를 고르는 것이 별개가 됐기 때문이다.

무엇이 바뀌었나

예전에는 한글 언어팩이 마켓플레이스에서 설치하는 플러그인이었다. 설치하면 곧바로 적용됐다.

그런데 언어팩이 IDE에 기본 번들로 들어오면서 설치/삭제가 아니라 enable / disable 방식으로 바뀌었다. 여기서 함정이 생긴다. enable은 "이 언어팩을 쓸 수 있게 해달라"는 뜻이지 "이 언어로 바꿔달라"는 뜻이 아니다.

해결 순서

1. 언어팩을 enable 한다

Settings (Preferences) > Plugins > Installed 탭
→ "Korean Language Pack / 한국어 언어 팩" 검색
→ 체크박스 활성화

여기까지는 대부분 한다. 문제는 다음 단계다.

2. 실제 사용 언어를 지정한다

Settings > Appearance & Behavior > System Settings > Language and Region
→ Language 항목에서 한국어 선택
→ Apply 후 IDE 재시작

언어팩이 enable 되어 있어야 이 드롭다운에 한국어 항목이 나타난다. enable 안 된 상태에서는 목록에 아예 안 보이므로, 1번을 먼저 하고 2번으로 가는 순서가 중요하다.

영어로 되돌리고 싶을 때도 같은 위치에서 English를 고르면 된다.

그래도 안 될 때 확인할 것

언어팩 버전이 IDE 버전과 안 맞는 경우

JetBrains 언어팩은 IDE 메이저 버전에 맞춰 나온다. IDE를 업데이트했는데 언어팩이 예전 버전이면 적용이 안 되거나 일부만 번역된다. Plugins 화면에서 업데이트가 있는지 확인한다.

설정이 저장 안 되는 경우

여러 JetBrains IDE를 쓰면 설정 디렉터리가 제품·버전별로 따로 있다. 한쪽에서 바꾼 게 다른 쪽에 반영되지 않는 건 정상이다.

# macOS
~/Library/Application Support/JetBrains/<Product><Version>/

# Windows
%APPDATA%\JetBrains\<Product><Version>\

# Linux
~/.config/JetBrains/<Product><Version>/

그래도 안 되면 캐시 무효화

File > Invalidate Caches... > Invalidate and Restart

순서상 이건 마지막에 시도한다. 인덱스를 다시 만들기 때문에 대형 프로젝트에서는 시간이 꽤 걸린다.

한글 UI를 권할지에 대한 개인적인 생각

한 가지 짚고 넘어갈 게 있다. 한글 UI가 항상 좋은 건 아니다.

검색이 어려워진다. 문제가 생겨서 검색할 때 대부분의 자료가 영문 메뉴 기준이다. "Invalidate Caches"를 "캐시 무효화"로 보고 있으면 매칭이 안 된다.
공식 문서와 어긋난다. JetBrains 공식 문서, 라라캐스트 같은 강의 영상은 전부 영문 UI다.
일부 항목은 번역이 안 돼 섞여 나온다. 플러그인이 제공하는 메뉴는 영문 그대로인 경우가 많다.

그래서 나는 IDE UI 자체는 영문으로 두고, 대신 단축키를 외우는 데 시간을 쓰는 쪽을 권한다. 메뉴를 읽을 일 자체가 줄어든다. 처음 진입 장벽 때문에 한글이 필요하다면 켜두고, 익숙해지면 영문으로 돌아가는 것도 방법이다.

정리

언어팩 enable과 언어 선택은 별개 단계다
Plugins에서 enable → Appearance & Behavior > System Settings > Language and Region에서 한국어 선택
enable 안 하면 언어 드롭다운에 한국어가 안 뜬다
IDE 업데이트 후에는 언어팩 버전도 확인
캐시 무효화는 마지막 수단

맥에서 사진 EXIF 날짜·위치 일괄 변경하기 (ExifTool)

Lovizu — Sat, 24 Aug 2024 13:00:19 +0900

스캔한 옛날 사진이나, 카메라 시계가 잘못 맞춰진 상태로 찍은 사진들의 메타데이터를 한 번에 고쳐야 할 때가 있다. ExifTool을 쓰면 명령 한 줄로 끝난다.

설치

brew install exiftool

명령어

위치만 변경

exiftool -gpslatitude=37.6534 -gpslongitude=126.8321 \
  -gpslatituderef=N -gpslongituderef=E \
  -overwrite_original /경로/사진_폴더/*.jpg

날짜만 변경

exiftool "-AllDates=2024:08:24 12:34:56" \
  -overwrite_original /경로/사진_폴더/*.jpg

둘 다 변경

exiftool "-AllDates=2024:08:24 12:34:56" \
  -gpslatitude=37.5665 -gpslongitude=126.9780 \
  -gpslatituderef=N -gpslongituderef=E \
  -overwrite_original /경로/사진_폴더/*.jpg

옵션 설명

-AllDates — DateTimeOriginal, CreateDate, ModifyDate 세 개를 한 번에 설정한다. 개별로 지정할 수도 있지만 대개 셋 다 맞추는 게 맞다
-gpslatituderef=N — 북위. 남반구는 S
-gpslongituderef=E — 동경. 서반구는 W
-overwrite_original — 원본을 덮어쓴다. 이 옵션이 없으면 파일명.jpg_original 백업 파일이 같이 생긴다

참고로 -overwrite_original 없이 실행해서 백업본을 남기는 게 처음에는 안전하다. 결과를 확인하고 나서 백업 파일을 지우면 된다.

자주 쓰는 응용

날짜를 상대적으로 이동

카메라 시계가 3시간 느리게 맞춰져 있었다면, 절대값 대신 이동시키는 게 편하다.

# 모든 날짜를 3시간 뒤로
exiftool "-AllDates+=0:0:0 3:0:0" -overwrite_original *.jpg

# 2일 앞으로
exiftool "-AllDates-=0:0:2 0:0:0" -overwrite_original *.jpg

형식은 연:월:일 시:분:초 다.

파일명에서 날짜 가져오기

20240824_123456.jpg 같은 파일명이면 거기서 날짜를 추출할 수 있다.

exiftool "-AllDates<filename" -overwrite_original *.jpg

파일 수정 시각을 EXIF로

exiftool "-AllDates<FileModifyDate" -overwrite_original *.jpg

반대로 EXIF 날짜로 파일명 바꾸기

exiftool "-FileName<DateTimeOriginal" -d "%Y%m%d_%H%M%S%%-c.%%e" .

하위 폴더까지 재귀 처리

exiftool -r "-AllDates=2024:08:24 12:34:56" -overwrite_original /경로/사진_폴더

확인하는 법

# 특정 파일의 모든 메타데이터
exiftool photo.jpg

# 날짜 관련만
exiftool -time:all -a -G1 photo.jpg

# GPS만
exiftool -gps:all photo.jpg

# 폴더 전체를 표로
exiftool -T -filename -DateTimeOriginal -GPSPosition *.jpg

개인정보 관점: EXIF 제거하기

반대 방향도 알아둘 필요가 있다. 사진을 웹에 올릴 때 EXIF에 촬영 위치가 그대로 남아 있으면 집 주소가 노출된다.

# GPS 정보만 제거
exiftool -gps:all= -overwrite_original *.jpg

# 모든 메타데이터 제거
exiftool -all= -overwrite_original *.jpg

# 방향(회전) 정보는 남기고 나머지 제거
exiftool -all= -tagsfromfile @ -orientation -overwrite_original *.jpg

마지막 명령이 실용적이다. Orientation을 지우면 세로 사진이 눕기 때문에, 그것만 남기고 나머지를 털어내는 방식이다.

주의할 점

애플 사진 앱 라이브러리를 직접 건드리지 않는다. ~/Pictures/Photos Library.photoslibrary 내부 파일을 수정하면 DB와 어긋나서 라이브러리가 깨질 수 있다. 내보내기 → 수정 → 다시 가져오기 순서로 한다
먼저 복사본으로 테스트한다. -overwrite_original은 되돌릴 수 없다
HEIC도 지원한다. 아이폰 기본 포맷도 문제없이 처리된다
동영상도 가능하다. MP4, MOV의 CreateDate도 수정할 수 있다

정리

brew install exiftool 한 줄로 설치
-AllDates로 촬영·생성·수정 날짜를 한 번에
-overwrite_original 없으면 _original 백업이 생긴다. 처음엔 붙이지 말 것
시계가 틀어졌으면 +=, -= 로 상대 이동이 편하다
웹에 올릴 사진은 -gps:all= 로 위치 정보 제거
애플 사진 앱 라이브러리 내부는 직접 수정하지 않는다

[Android] 스토어 배포 경고 (디버그 기호 업로드)

Lovizu — Tue, 9 Jul 2024 22:58:03 +0900

오늘도 구글이 나에게 시련을 준다.

이 App Bundle 아티팩트 유형은 네이티브 코드를 포함하며 아직 디버그 기호가 업로드되지 않았습니다. 비정상 종료 및 ANR을 더 쉽게 분석하고 디버그할 수 있도 록 기호 파일을 업로드하는 것이 좋습니다.

단순 경고이지만, 무시해도 될것 같은데 신경이 너무 쓰인다.

구글링을 해보았더니, 아래의 경로를 압축해서 업로드하면 된다고한다.

[project_root]/build/app/intermediates/merged_native_libs/release/out/lib

압축해야 하는 녀석들

위의 3개 폴더 (현재 시점으로는 3개인데 나중에는 몇개가 될지 모르겠다.) 를 압축한다. 파일명은 상관없다.

압축된 파일은

App Bundle 탐색기로 가서

App Bundle 탐색기

경고를 띄운 업로드중인 혹은 업로드 된 버전을 선택후

경고를 띄운 버전 선택

다운로드 > 네이티브 디버그 기호에 업로드해주면된다.

다운로드 > 네이티브 디버그 기호에 업로드 화면

그럼 윈도우라면 아주 깔끔하게 그냥 처리되겠지만, 우린 하필 맥유저이기에

The native debug symbols contain an invalid directory __MACOSX. Only Android ABIs are supported. The native debug symbols contain an invalid directory lib. Only Android ABIs are supported.

이런 류의 경고를 보게 될것이다.

맥에서 압축할 때 섞여 들어있는 파일인데 그건 빼고 하라는 뜻이다.

// 우리가 압축해야할 폴더까지 가서 아래의 명령어로 압축해보자.
zip -r ./symbols.zip ./*

그럼 symbols.zip 이 나오는데 그걸 업로드해주면 된다.

Flutter 안드로이드 타겟 SDK 대응하기 (targetSdkVersion 경고)

Lovizu — Tue, 9 Jul 2024 22:46:35 +0900

평화로운 개발 인생에 또 구글이 정기적으로 시련을 준다. "앱이 Android 14(API 수준 34) 이상을 타겟팅해야 함"이라는 경고 메일이다.

구글 플레이는 매년 새 앱과 업데이트에 대해 타겟 API 레벨 최소 요구치를 올린다. 대응하지 않으면 업데이트 자체를 올릴 수 없다.

기본적으로 손봐야 할 코드

수정할 위치는 android/app/build.gradle 이다.

compileSdkVersion : xxx
targetSdkVersion  : xxx

Android 14 대응이라면 이렇게 변경되어야 한다.

compileSdkVersion : 34
targetSdkVersion  : 34

두 가지 선택지

여기서 우리는 2가지 선택을 해야 한다.

1. build.gradle 파일을 직접 수정할 것인가?
2. 거기에 박혀 있는 flutter 상수를 수정할 것인가?

Flutter 프로젝트는 기본적으로 compileSdkVersion이 flutter.compileSdkVersion 같은 상수로 되어 있다.

전자: 직접 입력

android {
    compileSdkVersion 34
    
    defaultConfig {
        targetSdkVersion 34
        minSdkVersion 21
    }
}

해당 프로젝트에만 적용된다. 명시적이라 다른 사람이 봐도 바로 알 수 있다는 게 장점이다.

후자: Flutter 상수 변경

flutter SDK가 설치되어 있는 위치에서 아래 경로로 이동한다.

packages/flutter_tools/gradle/src/main/groovy

# fvm으로 버전 관리 중이라면
~/fvm/versions/stable/packages/flutter_tools/gradle/src/main/groovy

거기서 flutter.groovy 의 값을 원하는 대로 변경하면, 이후 만드는 모든 프로젝트에 기본값으로 적용된다. 프로젝트마다 하드코딩하는 게 귀찮다면 이 방법이 편하다.

다만 단점이 명확하다.

flutter upgrade 하면 초기화된다. SDK 파일을 직접 고치는 것이라 업그레이드 시 덮어씌워진다
팀원과 값이 달라진다. 내 로컬에서는 되는데 CI나 다른 사람 환경에서는 안 되는 상황이 생긴다
Git에 남지 않는다. 왜 이 값인지 추적이 안 된다

그래서 팀 프로젝트라면 프로젝트 파일에 직접 명시하는 쪽을 권한다.

참고로 보통은 flutter upgrade를 하면 알아서 바뀐다. Flutter 팀이 SDK 버전을 따라 올려주기 때문에, 최신 Flutter로 올리는 것만으로 해결되는 경우가 많다.

버전을 올린 뒤에 확인할 것들

숫자만 바꾼다고 끝이 아니다. 타겟 SDK를 올리면 동작 변경 사항이 적용된다. 이게 진짜 작업이다.

Android 13 (API 33)

알림 권한이 런타임 권한으로 바뀜 — POST_NOTIFICATIONS 를 직접 요청해야 한다. 안 하면 푸시가 아예 안 온다
미디어 접근 권한 세분화 — READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO

Android 14 (API 34)

포그라운드 서비스 타입 선언 필수 — foregroundServiceType 을 매니페스트에 명시해야 한다
암시적 인텐트 제한 — 내보내지 않은 컴포넌트에 암시적 인텐트를 보낼 수 없다
BroadcastReceiver 등록 시 export 여부 명시 필수

공통으로 확인할 것

플러그인 호환성 — 사용 중인 패키지가 새 SDK를 지원하는지. flutter pub outdated 로 확인
Gradle / AGP 버전 — compileSdk를 올리면 Android Gradle Plugin과 Gradle 버전도 함께 올려야 하는 경우가 많다
Java 버전 — AGP 8부터 Java 17이 필요하다
실기기 테스트 — 에뮬레이터에서는 안 잡히는 권한 이슈가 실기기에서 나온다

작업 순서 권장

1. flutter upgrade 로 SDK를 먼저 올린다
2. flutter pub outdated 로 패키지 상태 확인 후 업그레이드
3. build.gradle의 compileSdk / targetSdk 수정
4. 빌드해서 에러부터 잡는다 (Gradle, AGP, Java 버전)
5. 권한 관련 동작 변경 사항 대응
6. 실기기에서 알림·카메라·저장소 기능 테스트
7. 내부 테스트 트랙에 먼저 올려 확인

한 번에 다 하려고 하면 어디서 깨졌는지 모르게 된다. 빌드가 되는 지점까지 먼저 만들고, 그다음에 동작 변경을 다루는 순서가 편하다.

정리

android/app/build.gradle 의 compileSdkVersion, targetSdkVersion 수정
Flutter SDK 상수를 고치는 방법도 있지만 flutter upgrade 시 초기화된다
팀 프로젝트는 프로젝트 파일에 직접 명시
보통은 flutter upgrade만으로 해결된다
숫자를 올리면 동작 변경 사항이 따라온다. 알림 권한(13), 포그라운드 서비스 타입(14)
반드시 실기기에서 테스트