부지런한 게으름뱅이

6월 2일 장후 브리핑: 코스피 8,801.49, +0.15% 보합

부지런한 게으름뱅이 — Tue, 2 Jun 2026 16:20:27 +0900

6월 2일 장후 브리핑: 코스피 8,801.49, +0.15% 보합

장후 커버

6월 2일 장후 코스피는 8,801.49로 전일보다 +0.15% 올랐어요. 코스닥은 1,026.03으로 -2.29% 내려 대형주와 중소형주의 온도 차가 컸어요. 1

장중 코스피가 8,933선까지 올라선 뒤 힘이 줄었고, 코스닥은 5거래일 연속 약세를 이어갔어요. 4

오늘의 시장 한눈에 보기

코스피 1일 라인차트

오늘의 시장 요약카드

오늘 시장은 삼성전자가 +3.30% 오르며 코스피 하단을 받쳤지만, 코스닥 약세와 외국인 매도가 동시에 나온 장이었어요. 2 외국인은 6.6조원 넘게 순매도했고, 개인은 6.3조원 넘게 받아냈어요. 기관 순매수는 2,409억원으로 방향은 매수였지만 외국인 매도 규모를 상쇄하기에는 작았어요. 업종은 통신업과 은행이 강했고, 철강금속·건설업·보험·증권은 약했어요.

업종별 동향

업종별 등락률

오늘 강세 업종

통신업: +6.36%
은행: +2.05%
전기전자: +0.43%

오늘 약세 업종

의약품: -1.54%
화학: -2.29%
운수장비: -2.86%
증권: -3.25%
보험: -3.48%

특징주 분석

등락률 순위

종목 재무 분석

케이엠제약

케이엠제약 특징주 차트

종가는 2,635원(+29.80%)이고 거래량은 44만주였어요. 최근 3개월 범위는 336~3,105원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요.

PER은 -16.1배, PBR은 2.25배예요. EPS는 -164원, BPS는 1,170원이고 52주 위치는 상단에서 17% 지점이에요. 밸류에이션은 적자로 분류돼요.

보도에서 확인되는 축은 장중 급등 재료와 수급 쏠림과 당일 주가 변동 배경예요. 종목 자체 이슈만 보기보다 지수 수급까지 같이 봐야 하는 구간이에요. 6 7

알에프텍

알에프텍 특징주 차트

종가는 7,850원(+11.51%)이고 거래량은 12만주였어요. 최근 3개월 범위는 1,500~8,900원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요.

PER은 -1.8배, PBR은 0.26배예요. EPS는 -4,285원, BPS는 30,607원이고 52주 위치는 상단에서 14% 지점이에요. 밸류에이션은 적자로 분류돼요.

보도에서 확인되는 축은 반도체 대형주의 시가총액 역전 부담과 고평가 경고와 장중 급등 재료와 수급 쏠림예요. 종목 자체 이슈만 보기보다 지수 수급까지 같이 봐야 하는 구간이에요. 8 9

포니링크

포니링크 특징주 차트

종가는 3,025원(+10.20%)이고 거래량은 19만주였어요. 최근 3개월 범위는 591~3,800원이고, 최근 3개월 범위의 상단부에서 거래가 끝났어요.

PER은 4.9배, PBR은 0.35배예요. EPS는 620원, BPS는 8,572원이고 52주 위치는 상단에서 24% 지점이에요. 밸류에이션은 저평가로 분류돼요.

보도에서 확인되는 축은 장중 급등 재료와 수급 쏠림과 는 자율주행 서비스 플랫폼 사업의 성과 도출이 늦어지며 주가가 밀리고 있으며, 라닉스는 V2X 통신예요. 종목 자체 이슈만 보기보다 지수 수급까지 같이 봐야 하는 구간이에요. 10 11

카티스

카티스 특징주 차트

종가는 2,690원(-10.48%)이고 거래량은 19만주였어요. 최근 3개월 범위는 591~4,350원이고, 최근 3개월 범위의 중간권에서 마감했어요.

PER은 -28.3배, PBR은 4.19배예요. EPS는 -95원, BPS는 642원이고 52주 위치는 상단에서 44% 지점이에요. 밸류에이션은 적자로 분류돼요.

카티스는 반도체 대형주의 시가총액 역전 부담과 고평가 경고와 당일 주가 변동 배경이 함께 영향을 줬어요. 개별 재료와 시장 수급이 동시에 얹힌 흐름이라 단기 변동성이 커질 수 있어요. 8 12

상승 TOP

케이엠제약 +29.80%
알에프텍 +11.51%
포니링크 +10.20%

하락 TOP

카티스 -10.48%
엔케이 -9.03%
씨엔플러스 -6.82%

코스피 시총 5대 종목 시황

코스피 시총 상위 5개 종목은 지수 체감에 직접 영향을 주는 축이에요. 지수 방향만 보지 말고 대형주별 차트, 거래량, 당일 뉴스가 같은 방향인지 같이 확인해야 해요.

삼성전자

삼성전자 대형주 차트

시총 1위, 시가총액 2107조 5,834억원 규모예요. 종가는 360,500원(+3.30%)이고 거래량은 4310만주였어요. 최근 3개월 범위는 167,000~370,000원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요. 시총 상위주는 지수 체감에 미치는 영향이 커서, 종목 자체 재료와 외국인·기관 수급 방향을 함께 봐야 해요.

삼성전자는 반도체 대형주의 시가총액 역전 부담과 고평가 경고를 중심으로 해석돼요. 단기 반응이 컸던 만큼 차트에서는 거래량 유지 여부가 중요해요. 13 14

SK하이닉스

SK하이닉스 대형주 차트

시총 2위, 시가총액 1681조 9,776억원 규모예요. 종가는 2,360,000원(-0.13%)이고 거래량은 554만주였어요. 최근 3개월 범위는 806,000~2,407,000원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요. 시총 상위주는 지수 체감에 미치는 영향이 커서, 종목 자체 재료와 외국인·기관 수급 방향을 함께 봐야 해요.

당일 보도에서 읽히는 포인트는 반도체 대형주의 시가총액 역전 부담과 고평가 경고예요. 종가 위치와 거래량을 함께 보면 재료의 힘을 더 현실적으로 볼 수 있어요. 14 13

SK스퀘어

SK스퀘어 대형주 차트

시총 4위, 시가총액 177조 6,160억원 규모예요. 종가는 1,346,000원(+7.17%)이고 거래량은 103만주였어요. 최근 3개월 범위는 460,000~1,375,000원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요. 시총 상위주는 지수 체감에 미치는 영향이 커서, 종목 자체 재료와 외국인·기관 수급 방향을 함께 봐야 해요.

이 종목은 장중 급등 재료와 수급 쏠림이 핵심 변수였어요. 주가가 재료를 먼저 반영했는지, 추가 수급이 붙는지가 관건이에요. 15 16

현대차

현대차 대형주 차트

시총 5위, 시가총액 149조 2,684억원 규모예요. 종가는 729,000원(-2.80%)이고 거래량은 232만주였어요. 최근 3개월 범위는 445,000~783,000원이고, 최근 3개월 흐름으로 보면 고점권에 가까운 자리예요. 시총 상위주는 지수 체감에 미치는 영향이 커서, 종목 자체 재료와 외국인·기관 수급 방향을 함께 봐야 해요.

현대차 관련 보도는 장중 급등 재료와 수급 쏠림에 초점이 맞춰졌어요. 이 재료가 실제 매수세로 이어지는지는 다음 거래일 거래량까지 확인해야 해요. 15 17

삼성전기

삼성전기 대형주 차트

시총 6위, 시가총액 135조 4,197억원 규모예요. 종가는 1,813,000원(-9.58%)이고 거래량은 195만주였어요. 최근 3개월 범위는 350,500~2,192,000원이고, 최근 3개월 범위의 상단부에서 거래가 끝났어요. 시총 상위주는 지수 체감에 미치는 영향이 커서, 종목 자체 재료와 외국인·기관 수급 방향을 함께 봐야 해요.

보도에서 확인되는 축은 반도체 대형주의 시가총액 역전 부담과 고평가 경고와 AI 투자 기대감예요. 종목 자체 이슈만 보기보다 지수 수급까지 같이 봐야 하는 구간이에요. 18 19

수급 동향

수급 동향 카드

외국인: 6.6조 5,941억원 순매도
기관: 2,409억원 순매수
개인: 6.3조 3,489억원 순매수

리스크 요인

첫 번째 리스크는 장중 고점 이후 힘이 빠진 흐름이에요. 코스피가 8,933선까지 오른 뒤 마감가가 8,801.49로 내려오면서 단기 차익 매물이 확인됐어요. 4 두 번째 리스크는 코스닥의 연속 약세예요. 대형 반도체가 버텨도 중소형주 체감이 약하면 시장 폭은 좁아질 수 있어요. 세 번째 리스크는 외국인 매도예요. 외국인 순매도가 이어지면 지수는 버텨도 종목별 변동성은 커질 수 있어요.

내일 주요 경제지표 일정 (미국)

날짜	경제지표
06-01	FOMC 금리결정
06-01	건설지출 (Construction Spending)

내일 전망

내일은 코스피 8,800선 안착 여부와 코스닥 반등 여부를 같이 확인해야 해요. 삼성전자처럼 지수 기여도가 큰 종목의 거래량이 유지되면 코스피는 다시 고점 테스트를 시도할 수 있어요. 2 다만 외국인 매도가 이어지고 코스닥이 다시 밀리면 체감 장세는 약해질 수 있어요. 장 초반에는 통신·은행 강세가 이어지는지, 철강·건설 약세가 멈추는지부터 보는 게 좋아요.

참고 자료

코스피, 등락 끝에 8,800대 상승 마감…또 사상 최고치 — SBS
특징주, 삼전, 3%대 상승으로 코스피 지켰다…하이닉스 약보합(종합) — 연합뉴스
"코스피 9000 눈앞" 지방선거 표심도 흔들까? Y녹취록 — YTN
코스피 8933 찍고 하락 전환…코스닥 5거래일째 하락 — SBS Biz
오중기 "국힘 경북 독점 깨야", 이철우 "민주 의회독재 봐라" — 뉴스
놓치면 후회? '이재용보다 못한' K-방산 대장주 한화에어로스페이스의 ... — 뉴스
만년 저평가 탈피 시동…풍전약품, 베일 벗은 신사업 모멘텀에 러브콜 ... — 핀포인트뉴스
주요공시, 삼성중공업, 네오셈, SK아이이테크놀로지, 에코아이, JK리버... — 뉴스
특징주, 알에프텍, 시너지아이비투자 지분 전량 정리에 급등 — 토큰포스트
나무기술, AI 인프라 확장 올라탔다... 클라우드·GPU 타고 '빅 랠리' — 핀포인트뉴스
국산 반도체의 자존심 세웠네... 넥스트칩, 차량용 팹리스 시장 장악 주... — 핀포인트뉴스
쏠리드·센서뷰 주가 신바람… 5G·위성통신 투자 기대감 폭발 — 핀포인트뉴스
日키옥시아 시총 42조엔 돌파..'적층 대신 속도' 승부수 통했나 — 뉴스
자막뉴스, "삼성전자 성과급 어떻게 생각해?"…'깜짝' 엔비디아 성과급... — SBS
마감시황, 코스피, 13.11포인트 오른 8801.49 마감 — 뉴스
코스피 지수 8801.49 마감…하루 만에 9만원 폭등한 '이곳' 어디? — 뉴스
젠슨황은 반도체 넘어 로봇 보는 중 : 현대차그룹 정의선-LG그룹 구광모... — 뉴스
코스피, 오르락내리락 끝에 8800선 사상 최고가 마감 — 한국경제
삼성자산운용, KODEX AI반도체TOP2플러스 순자산 4조원 돌파 — 뉴스

본 글은 정보 제공 목적이며, 투자 권유가 아닙니다. 모든 투자의 책임은 투자자 본인에게 있습니다.

Surface Laptop Ultra가 노리는 건 맥북 프로보다 로컬 AI예요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 13:19:07 +0900

Surface Laptop Ultra가 노리는 건 맥북 프로보다 로컬 AI예요

AI 뉴스 썸네일

마이크로소프트가 엔비디아와 손잡고 Surface 계열의 최상위 노트북을 준비하고 있다는 보도가 나왔어요. 이름은 Surface Laptop Ultra예요. 겉으로는 맥북 프로 경쟁 제품처럼 보이지만, 진짜 포인트는 윈도우 노트북에서 대형 AI 모델을 로컬로 돌리려는 시도예요. 2

핵심 요약

구분	핵심	왜 읽을 만한가요
제품	Surface Laptop Ultra는 엔비디아 RTX Spark 기반 고성능 Surface 노트북으로 소개됐어요	윈도우 진영이 맥북 프로와 AI 워크스테이션 시장을 동시에 겨냥해요
하드웨어	20코어 NVIDIA Grace CPU, Blackwell RTX GPU, 최대 128GB 통합 메모리 구성이 거론돼요	로컬 AI 추론, 영상 편집, 3D 작업을 노트북 안으로 끌어오려는 방향이 보여요
플랫폼	Windows 11 on Arm 최적화와 x86 앱 호환, 로컬 에이전트 샌드박스가 함께 언급돼요	성능만이 아니라 앱 생태계와 보안 격리까지 같이 풀어야 하는 문제예요

1. Surface Laptop Ultra, 맥북 프로 경쟁보다 더 큰 질문을 던져요

Windows Latest는 마이크로소프트가 Computex 2026에서 Surface Laptop Ultra를 공개했다고 보도했어요. 이 제품은 Surface 라인업의 최상위 모델로, Windows on Arm과 엔비디아 RTX Spark 플랫폼을 결합한 노트북으로 설명돼요. 애플 맥북 프로를 직접 겨냥한다는 표현이 붙었지만, 단순한 고성능 노트북 경쟁으로만 보면 핵심을 놓치기 쉬워요. 마이크로소프트가 묻는 말은 “윈도우 노트북도 로컬 AI 작업의 기본 장비가 될 수 있나”에 가까워요. 2

보도에 따르면 Surface Laptop Ultra는 20코어 NVIDIA Grace CPU와 Blackwell RTX GPU를 쓰고, 최대 128GB 통합 메모리를 제공해요. 1페타플롭 수준의 AI 연산 성능과 1,200억 파라미터 모델의 로컬 실행도 언급돼요. 숫자만 보면 꽤 공격적이에요. 다만 실제 제품이 어느 가격대에 나오고, 배터리와 발열을 어느 정도로 잡을지가 더 중요해요.

2. 윈도우 온 Arm은 이제 성능보다 생태계 싸움이에요

윈도우 노트북이 Arm 기반으로 옮겨 갈 때 가장 자주 부딪힌 문제는 앱 호환성과 성능 편차였어요. 이번 보도에서 흥미로운 부분도 하드웨어 사양만이 아니에요. Windows 11 on Arm이 20코어 스케줄링, 전력·열 관리, GPU 메모리 접근, 공유 메모리 페이지 관리에 맞춰 조정됐다는 대목이 같이 나와요. 1

게임과 크리에이터 앱 지원도 따로 강조됐어요. Epic, BattlEye, Riot Games, KRAFTON, Adobe 같은 이름이 나오는 이유예요. 고성능 칩을 넣어도 안티치트나 영상 편집 앱이 제대로 돌지 않으면 전문가용 노트북이라는 말이 힘을 잃어요. 이 제품이 실제로 의미를 가지려면 벤치마크 점수보다 “매일 쓰는 앱이 문제없이 돌아가나”가 먼저 확인돼야 해요.

3. 로컬 AI PC 경쟁은 메모리와 개발 환경으로 갈라질 수 있어요

최대 128GB 통합 메모리와 CUDA 지원은 개발자에게 꽤 큰 신호예요. 클라우드 GPU 없이도 일정 규모의 모델을 손안에서 다뤄 볼 수 있다면, 프로토타입과 실험 방식이 달라질 수 있어요. 특히 로컬 에이전트, 코드 작업, 영상·이미지 생성, 3D 렌더링처럼 GPU와 메모리를 같이 먹는 작업에서 차이가 나요.

그렇다고 모든 AI 작업이 노트북으로 옮겨 온다는 뜻은 아니에요. 대형 모델 학습이나 팀 단위 배포는 여전히 클라우드가 유리해요. 대신 개인 개발자나 크리에이터가 “작은 모델을 빠르게 돌려 보고 바로 수정하는” 구간은 로컬 장비가 더 편할 수 있어요. Surface Laptop Ultra가 흥미로운 이유도 여기에 있어요. 윈도우 PC가 다시 개발 장비의 중심으로 들어오려면, AI 시대의 로컬 작업 경험을 설득해야 해요.

왜 중요한가요

애플은 맥북 프로에서 성능, 배터리, 통합 메모리, 조용한 하드웨어 경험을 하나의 제품 경험으로 묶어 왔어요. 마이크로소프트와 엔비디아가 이 흐름에 대응하려면 GPU 성능만 높여서는 부족해요. 윈도우 앱 호환성, Arm 네이티브 전환, 로컬 AI 개발 환경, 크리에이터 앱 최적화가 같이 맞아야 해요. 2

이번 보도는 AI PC 경쟁이 “NPU가 몇 TOPS인가”에서 끝나지 않는다는 점을 보여줘요. 앞으로의 고급 노트북은 CPU, GPU, 메모리, 운영체제, 개발 도구가 한 몸처럼 움직여야 해요. Surface Laptop Ultra가 실제 제품으로 나왔을 때 볼 부분도 명확해요. 가격, 배터리, 발열, 앱 호환성, 로컬 AI 성능이 맥북 프로와 비교할 수 있는 수준인지 확인해야 해요. 1

참고 자료

Microsoft, NVIDIA 기반 Surface Laptop Ultra로 MacBook Pro 경쟁 제품을 만듦 — GeekNews
Microsoft builds its ultimate MacBook Pro rival with the NVIDIA powered Surface Laptop Ultra — Windows Latest

AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

부지런한 게으름뱅이 — Tue, 2 Jun 2026 13:07:49 +0900

AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

AI 뉴스 썸네일

AI가 코드를 더 빨리 만들면 운영팀의 일도 같이 바뀌어요. Google SRE는 이제 AI를 단순한 보조 도구가 아니라, 장애 감지와 조사, 일부 완화까지 맡는 운영 계층으로 보고 있어요.

핵심 요약

구분	핵심	왜 볼만한가요
운영 자동화	Google은 SRE 업무에 AI를 넣되, 자율성 레벨을 L0부터 L4까지 나눠요	장애 대응에서 “얼마나 맡길 수 있나”를 단계로 보는 기준이 생겨요
안전 설계	투명성, 실시간 리스크 평가, 점진적 권한 부여를 기본 축으로 둬요	프로덕션에서 AI가 실수할 때 피해가 커지는 문제를 정면으로 다뤄요
평가 방식	최근 인시던트와 사람의 대응 기록을 평가 데이터로 써요	데모가 아니라 실제 운영 품질을 매일 재검증하는 흐름을 보여줘요
개발 조직 변화	코드 리뷰는 줄 단위 검토보다 설계, 의도, 정책 검토 쪽으로 옮겨가요	AI 코딩 확산 뒤 운영과 리뷰 체계가 어떻게 바뀔지 가늠할 수 있어요

1. AI가 장애 대응까지 맡을 때, Google SRE가 세운 안전선

Google은 왜 SRE를 다시 설계하나요

Google SRE 글의 출발점은 꽤 현실적이에요. AI 코딩 도구가 코드 작성과 배포 속도를 끌어올리면, 사람이 모든 변경을 줄 단위로 따라가며 검토하는 방식은 금방 한계에 닿아요. 원문은 조직이 최대 4배 생산성 향상을 목표로 삼는 상황을 전제로 두고, SRE가 기존 운영 방식만 붙잡기 어렵다고 설명해요. 2

핵심은 “AI로 기존 업무를 더 빠르게 처리하자”가 아니에요. Google은 장애 감지, 알림 보강, 원인 추정, 완화 실행, 평가 데이터 생성까지 운영 흐름 전체에 AI를 넣는 쪽을 보고 있어요. 다만 프로덕션에서 잘못된 판단은 곧바로 장애로 이어질 수 있어서, AI가 할 수 있는 일과 하면 안 되는 일을 먼저 나누는 구조가 중요해져요. 1

자율성은 한 번에 열지 않고 단계로 나눠요

Google은 SRE AI의 자율성을 L0부터 L4까지 나눠요. L0는 사람이 모든 판단과 실행을 맡고, L1은 AI가 조사와 가설 제안을 도와요. L2는 실행 계획을 세울 수 있지만 사람의 승인이 필요하고, L3는 정해진 범위 안에서 직접 실행까지 할 수 있어요. L4는 진단, 완화, 복구 확인까지 여러 단계를 스스로 이어가는 상태예요. 2

이 구분이 중요한 이유는 “AI에게 맡긴다”는 말이 너무 넓기 때문이에요. 로그 요약을 맡기는 것과 트래픽을 실제로 빼는 것은 위험이 달라요. Google은 권한을 한 번에 열지 않고, 낮은 자율성에서 검증한 뒤 높은 단계로 올리는 방식을 택해요.

안전 삼각축은 운영 AI의 기본 조건이에요

원문에서 가장 눈에 띄는 부분은 Safety Trifecta예요. 첫 번째는 투명성이에요. AI가 어떤 신호를 봤고, 어떤 가설을 세웠고, 왜 특정 조치를 골랐는지 기록해야 해요. 두 번째는 실시간 리스크 평가예요. 같은 조치라도 배포가 진행 중인지, 에러 버짓이 어떤지, 활성 인시던트가 있는지에 따라 위험도가 달라져요. 세 번째는 점진적 권한 부여예요. 처음부터 전권을 주지 않고, 신뢰가 쌓인 범위에서만 권한을 넓혀요. 2

이 접근은 AI 운영 자동화에서 자주 빠지는 지점을 짚어요. 모델 성능보다 먼저 봐야 할 것은 실행 경로예요. AI가 좋은 답을 내도, 그 답이 실제 프로덕션 상태를 바꾸는 순간에는 최소 권한, 전용 레이트 리밋, 중단 장치, dry-run 같은 안전장치가 필요해요.

AI Operator와 Actus는 역할을 나눠요

Google은 AI Operator를 프로덕션 알림의 1차 대응 에이전트로 설명해요. 이 시스템은 알림을 받으면 여러 조사를 병렬로 수행하고, 과거 유사 사례와 운영 지식을 바탕으로 원인을 좁혀요. 막히면 사람에게 넘기고, 사람이 볼 수 있도록 조사 과정을 남겨요. 2

실행 쪽은 Actus 같은 제어 계층이 맡아요. AI가 직접 스크립트를 실행하는 방식이 아니라, 실행 계획을 안전 검사에 통과시킨 뒤 표준화된 경로로 조치해요. 위험이 커지면 L3에서 L2로 내려가 사람 승인을 요구하고, 비상 상황에서는 진행 중인 자동 조치를 멈출 수 있는 “레드 버튼”도 둬요. 이 분리는 운영 AI 설계에서 꽤 중요한 패턴이에요. 추론하는 시스템과 실제 상태를 바꾸는 시스템을 나눠야 통제가 쉬워져요.

평가 데이터는 사람의 운영 기억에서 나와요

Google은 AI가 높은 자율성을 얻으려면 평가 데이터가 먼저 필요하다고 봐요. 인시던트 채팅, 노트, CLI 기록처럼 흩어진 운영 흔적을 시간순 사건으로 재구성하고, 이를 Bronze, Silver, Gold 품질 계층으로 나눠요. 사람이 검증한 Gold 데이터는 AI가 실제로 올바른 완화 조치를 골랐는지 판단하는 기준으로 쓰여요. 2

흥미로운 점은 평가가 일회성 벤치마크에 머물지 않는다는 거예요. 최근 실제 인시던트로 매일 평가를 돌리고, 정성적인 추론은 LLM 평가자가 보되 최종 완화 결과는 결정론적으로 채점해요. 예를 들어 정확한 바이너리나 버전이 맞아야 정답으로 인정하는 식이에요. 운영 AI를 제품처럼 계속 배포하려면 이런 반복 평가가 필수에 가까워져요.

개발 속도가 빨라지면 리뷰 방식도 달라져요

원문은 SRE의 변화가 장애 대응에만 머물지 않는다고 봐요. AI가 코드를 계획하고, 작성하고, 리뷰하고, 제출하는 흐름이 커지면 변경량은 4배에서 10배까지 늘 수 있어요. 이때 사람이 모든 코드를 줄 단위로 검토하면 리뷰 피로가 커지고, 승인이 형식화될 위험도 생겨요. 2

그래서 Google은 사람의 감독이 더 앞단으로 옮겨가야 한다고 말해요. 코드를 한 줄씩 보는 대신 설계, 의도, 정책, 테스트 기준을 먼저 검토하는 쪽이에요. 코드를 만드는 AI와 테스트나 리뷰를 맡는 AI를 분리해 같은 편향이 반복되지 않게 하는 원칙도 제시해요. 단순 롤백이 어려워지는 문제도 다뤄요. 짧은 시간에 여러 변경이 들어오면 롤백 하나가 그사이 들어온 보안 패치까지 되돌릴 수 있어서, 동적 설정과 기능 플래그, 빠른 수정 배포가 더 중요해져요.

왜 중요한가요

이 글은 “AI가 SRE를 대체한다”는 식의 단순한 이야기가 아니에요. 오히려 사람의 역할이 어디로 옮겨가는지 보여줘요. 사람이 직접 모든 알림을 조사하고 모든 완화 명령을 치는 방식에서, AI가 안전하게 움직일 수 있는 경계와 평가 기준을 설계하는 쪽으로 이동해요. 1

서비스 운영팀이 바로 L3, L4 자동화를 도입하기는 어려워요. 그래도 L1 수준의 알림 보강, 원인 가설 제안, 인시던트 기록 정리부터는 현실적인 출발점이 될 수 있어요. 중요한 건 AI 기능 자체보다 운영 권한, 감사 기록, 평가 데이터, 중단 장치를 함께 설계하는 거예요.

참고 자료

SRE에서의 AI: Google은 어떻게 신뢰성 있는 운영의 미래를 설계하는가 — GeekNews
AI in SRE: How Google is Engineering the Future of Reliable Operations — Google SRE

NVIDIA RTX Spark, 로컬 AI PC 경쟁을 Windows로 끌고 와요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 12:58:25 +0900

NVIDIA RTX Spark, 로컬 AI PC 경쟁을 Windows로 끌고 와요

AI 뉴스 썸네일

NVIDIA가 RTX Spark를 공개했어요. Blackwell RTX GPU와 Arm 기반 Grace CPU를 한 칩에 묶어, 얇은 Windows 노트북과 소형 데스크톱에서 AI 개발·창작·게임을 함께 돌리겠다는 구상이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
제품	RTX Spark Superchip은 최대 6,144개 Blackwell RTX GPU 코어와 최대 20코어 Grace CPU를 결합해요.	NVIDIA가 소비자용 PC 칩 시장에 직접 들어오는 신호예요.
AI 개발	최대 128GB 통합 메모리와 CUDA 스택을 앞세워 로컬 파인튜닝·추론을 겨냥해요.	작은 모델 실험을 클라우드 대신 개인 PC에서 처리하려는 흐름과 맞닿아 있어요.
생태계	ASUS, Dell, HP, Lenovo, Microsoft, MSI 등이 노트북·데스크톱 제품을 준비해요.	한두 대의 실험 기기가 아니라 Windows PC 라인업으로 밀어붙이는 모양새예요.
변수	Arm 기반 Windows 호환성과 실제 배터리·발열·가격은 아직 확인해야 해요.	스펙보다 중요한 건 기존 앱과 게임이 얼마나 자연스럽게 돌아가느냐예요.

1. RTX Spark는 어떤 칩인가요

RTX Spark는 NVIDIA가 AI와 RTX 그래픽을 한 칩으로 묶은 소비자용 PC 플랫폼이에요. 공식 제품 페이지 기준으로 최대 1페타플롭 FP4 AI 성능, 최대 128GB 통합 메모리, 최대 6,144개 RTX GPU 코어를 내세워요. 2

핵심은 CUDA예요. 기존 NVIDIA 개발 환경을 그대로 쓰면서 같은 기기에서 모델 개발, 프로토타이핑, 파인튜닝, 추론을 이어갈 수 있다는 점을 강조해요. 개발자 입장에서는 "노트북에서 CUDA가 된다"보다 "작은 AI 실험을 굳이 원격 GPU로 보내지 않아도 된다"는 쪽이 더 직접적인 변화예요.

다만 120억 파라미터 LLM을 로컬에서 돌린다는 설명은 조건을 같이 봐야 해요. 모델 크기, 양자화 방식, 컨텍스트 길이, 앱 최적화에 따라 체감 속도가 크게 달라질 수 있어요. 발표 스펙만으로 MacBook Pro, Strix Halo, 기존 RTX 노트북과의 우열을 단정하기는 어려워요.

2. NVIDIA가 노리는 건 AI 개발자용 개인 PC예요

NVIDIA는 RTX Spark를 크리에이터, 개발자, 게이머가 함께 쓰는 PC로 설명해요. 영상 편집, 3D 렌더링, DLSS 게임 성능도 말하지만, 가장 선명한 메시지는 로컬 AI예요. 백그라운드에서 AI 에이전트가 작업을 돕고, 사용자는 목표를 주면 PC가 일부 작업을 처리하는 그림을 제시해요. 2

이 설명이 흥미로운 이유는 NVIDIA가 데이터센터 바깥에서도 AI 워크로드를 잡으려 한다는 점이에요. 지금까지 AI 개발자는 클라우드 GPU, 로컬 RTX 데스크톱, Apple Silicon Mac, AMD Strix Halo 같은 선택지 사이에서 타협했어요. RTX Spark는 그 경쟁판에 Windows 노트북이라는 형태로 들어와요.

가격은 아직 비어 있어요. Yahoo Finance 보도는 128GB 통합 메모리 구성이 일반 노트북보다 훨씬 크고, 첫 제품군이 프리미엄 라인에 가까울 수 있다고 봤어요. 3

3. Windows on Arm 호환성이 첫 번째 관문이에요

RTX Spark는 Arm 기반 Grace CPU를 써요. 그래서 성능표보다 먼저 봐야 할 건 Windows on Arm 생태계예요. 창작 앱과 개발 도구가 네이티브로 잘 돌아가면 의미가 커져요. 반대로 x86 앱 호환, 드라이버, 게임 안티치트에서 삐걱거리면 좋은 GPU를 얹어도 일상용 PC로는 애매해질 수 있어요.

NVIDIA는 Adobe, Blackmagic Design, Blender, ComfyUI 같은 창작·AI 도구와 주요 게임 개발사를 끌어들이는 방향을 말해요. MacRumors는 RTX Spark를 Apple Silicon과 맞붙는 소비자 PC 칩으로 해석했어요. 특히 128GB 통합 메모리와 120억 파라미터 모델 로컬 실행을 NVIDIA가 강하게 밀고 있다고 짚었어요. 4

그래도 비교는 조심해야 해요. Apple은 하드웨어와 운영체제 전환을 한 방향으로 밀었고, Windows는 기존 호환성의 무게가 훨씬 커요. RTX Spark가 성공하려면 "NVIDIA 칩이 들어간 신기한 노트북"을 넘어, Windows 앱과 게임이 Arm 환경에서도 충분히 자연스럽다는 증거가 필요해요.

4. 로컬 AI PC 경쟁이 더 복잡해져요

RTX Spark가 바로 대중형 노트북을 바꾸지는 않을 수 있어요. 하지만 개발자와 크리에이터용 고성능 PC 시장에는 분명한 질문을 던져요. 로컬에서 모델을 돌리고 싶은 사람에게 필요한 건 GPU 성능만이 아니에요. 메모리 용량, 메모리 대역폭, 전력 효율, 드라이버, 프레임워크 호환성, 가격이 같이 맞아야 해요.

NVIDIA의 강점은 CUDA예요. 이미 많은 AI 도구와 연구 코드가 CUDA를 기본값처럼 다뤄요. 그 흐름을 노트북과 소형 데스크톱으로 가져오면, 개인 개발자는 클라우드 비용과 대기 시간에서 조금 더 자유로워질 수 있어요.

반대로 소비자용 PC라는 말은 기준을 높여요. 개발자용 박스라면 다소 불편해도 참을 수 있어요. 노트북이라면 배터리, 발열, 소음, 앱 호환, 게임 안정성이 모두 평가 대상이에요. RTX Spark의 진짜 평가는 제품이 나온 뒤 벤치마크와 실사용 후기가 쌓여야 가능해요.

왜 중요한가요

AI PC라는 말은 오래전부터 있었지만, 대부분은 NPU 성능이나 화상회의 기능처럼 가벼운 기능에 머물렀어요. RTX Spark는 방향이 조금 달라요. NVIDIA는 로컬 LLM, CUDA 개발, 창작 워크로드, 게임을 한 장치 안에 묶으려 해요. 2

이 흐름이 맞아떨어지면 개인용 AI 개발 환경이 더 다양해질 수 있어요. 클라우드 GPU를 빌리기 전, 손안의 노트북에서 모델을 줄이고 실험하고 검증하는 식이에요. 실패해도 볼 지점은 남아요. NVIDIA가 소비자용 PC에서 Intel, AMD, Apple과 직접 부딪히기 시작했다는 사실만으로도 PC 시장의 다음 경쟁축을 보여줘요.

참고 자료

NVIDIA, RTX Spark 공개 — GeekNews
NVIDIA RTX Spark — Slim Laptops & Small Desktops — NVIDIA
Nvidia debuts RTX Spark processor for Windows laptops, taking aim at Intel, AMD — Yahoo Finance
Nvidia Challenges Apple Silicon With New RTX Spark PC Chip — MacRumors

GPU 없이 Gemma를 돌린 낡은 Xeon 실험

부지런한 게으름뱅이 — Tue, 2 Jun 2026 12:41:37 +0900

GPU 없이 Gemma를 돌린 낡은 Xeon 실험

AI 뉴스 썸네일

최신 AI 모델은 꼭 최신 GPU에서만 돌아간다는 인식이 강해요. 그런데 2016년형 Xeon 서버와 128GB DDR3 메모리만으로 Gemma 4 26B-A4B를 읽기 속도에 가깝게 돌린 실험이 나왔어요. 핵심은 CPU 성능보다 메모리 대역폭, 추론 엔진, 캐시 배치였어요.

핵심 요약

구분	핵심	왜 볼 만한가요
로컬 LLM	GPU 없는 Xeon E5-2620 v4 서버에서 Gemma 4 26B-A4B를 실행했어요	로컬 AI의 병목이 연산보다 메모리 이동에 더 가깝다는 점을 보여줘요
추론 최적화	`ik_llama.cpp` 플래그로 MTP 추측 디코딩, MoE 라우팅, 런타임 재배치를 조합했어요	같은 모델도 실행 엔진을 어떻게 다루느냐에 따라 체감 속도가 크게 달라져요
메모리 구조	전체 요구 메모리는 82,355MiB 수준이고, 262K 컨텍스트에서는 KV 캐시가 가중치보다 커요	긴 문맥 로컬 실행에서는 모델 크기만 보면 판단을 놓치기 쉬워요
제품 관점	`ollama` 같은 쉬운 도구만으로는 세부 조율 항목이 부족할 수 있어요	개발자는 편의성과 제어권 사이에서 선택해야 해요

1. 오래된 Xeon도 Gemma를 읽기 속도로 돌렸어요

원문 작성자는 Intel Xeon E5-2620 v4, 8코어 16스레드, 128GB DDR3 RAM, GPU 없는 서버에서 Gemma 4 26B-A4B를 실행했어요. 이 장비는 AVX-512, AVX-VNNI, BF16 같은 최신 명령어를 지원하지 않아요. 그래도 `ik_llama.cpp`의 실행 옵션을 세밀하게 조합해 읽으면서 따라갈 만한 속도까지 끌어올렸다고 설명해요. 원문은 이 결과를 단순한 하드웨어 자랑보다 추론 병목을 이해하는 사례로 다뤄요.

이 실험에서 중요한 지점은 CPU가 "느리다"라는 말만으로 끝나지 않는다는 점이에요. LLM이 토큰을 하나씩 만들 때는 거대한 가중치를 계속 RAM에서 캐시와 코어로 옮겨야 해요. 연산 장치가 계산을 못 해서 멈추기보다, 다음 가중치가 메모리 버스를 타고 오기를 기다리는 시간이 커져요. 그래서 DDR3처럼 느린 메모리에서는 모델 실행의 승부가 메모리 배치와 캐시 친화성으로 옮겨가요.

원문은 `ollama` 같은 편한 도구가 이 상황에 맞지 않을 수 있다고 봐요. 모델 지원 여부도 문제지만, 더 큰 문제는 세부 설정을 충분히 열어주지 않는다는 점이에요. 오래된 서버에서 대형 오픈 모델을 억지로 돌릴 때는 `--spec-type mtp`, `--cpu-moe`, `--merge-up-gate-experts`, `--run-time-repack`, `--flash-attn on` 같은 옵션을 직접 이해해야 해요. 이건 로컬 LLM이 "설치하면 끝"인 소비자 제품과 "조율해야 쓸 수 있는 시스템" 사이에 있다는 뜻이에요.

MoE 모델의 성격도 중요해요. Gemma 4 26B-A4B는 전체 파라미터는 약 25.2B지만, 토큰마다 활성화되는 파라미터는 약 3.8B 수준으로 설명돼요. 이 구조는 메모리를 덜 쓰게 해 주는 면이 있지만, 전문가 라우팅이 캐시를 자주 비우면 CPU에서는 오히려 느려질 수 있어요. `--cpu-moe`와 `--merge-up-gate-experts` 같은 옵션은 이 문제를 줄이려는 장치예요.

왜 중요한가요

로컬 AI를 보는 기준이 조금 바뀌고 있어요. 지금까지는 "GPU가 있느냐"가 첫 질문이었다면, 이 사례는 "메모리 대역폭을 얼마나 잘 쓰느냐"와 "추론 엔진을 얼마나 직접 제어할 수 있느냐"도 함께 보게 해요. 오래된 장비가 최신 GPU를 이긴다는 얘기는 아니에요. 대신 모델 크기, 양자화, KV 캐시, 추측 디코딩, MoE 라우팅을 맞추면 버려진 서버도 특정 작업에서는 쓸모가 생길 수 있다는 쪽에 가까워요. GeekNews 요약도 이 점을 메모리 병목과 세부 실행 항목 중심으로 정리해요.

개발자에게는 꽤 현실적인 힌트가 있어요. 로컬 모델을 업무 보조나 자동화에 붙일 때 최고 성능보다 지속 비용, 프라이버시, 장비 재활용이 더 중요할 수 있어요. 대화형 챗봇처럼 빠른 반응이 필요한 작업에는 부족해도, 백그라운드 요약이나 코드 초안 보조처럼 기다릴 수 있는 작업에는 충분할 수 있어요. 다만 전력, 소음, 유지보수 시간까지 계산해야 해요.

AI 서비스 운영자에게도 이 흐름은 가볍지 않아요. 공개 가중치 모델이 좋아지고 로컬 실행 노하우가 쌓이면, 모든 추론을 클라우드 API에 맡기는 구조가 유일한 답은 아니게 돼요. 기업 내부 문서, 개인 데이터, 장기 자동화 작업은 로컬이나 사내 장비에서 돌리는 쪽이 더 자연스러울 수 있어요. 편한 상용 API와 직접 관리하는 로컬 모델은 서로 대체재라기보다 용도별 선택지가 될 가능성이 커요.

이번 글에서 제일 흥미로운 부분은 낡은 CPU가 아니라 병목을 끝까지 파고드는 방식이에요. 모델 실행은 이제 모델 파일 하나를 내려받는 문제가 아니에요. 어떤 양자화를 고를지, KV 캐시가 얼마나 커질지, CPU 캐시에 맞게 가중치를 어떻게 놓을지, 추측 디코딩이 실제로 이득을 주는지까지 봐야 해요. 로컬 AI가 넓어질수록 이런 낮은 수준의 이해가 다시 중요해지고 있어요.

참고 자료

10년 된 Xeon이면 충분하다 — GeekNews
A 10 year old Xeon is all you need — point.free

인스타그램 계정 복구 AI가 username 하나에 무너졌어요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 12:32:51 +0900

인스타그램 계정 복구 AI가 username 하나에 무너졌어요

AI 뉴스 썸네일

인스타그램 계정 복구 절차에서 계정 이름만으로 비밀번호 재설정까지 이어질 수 있었다는 사례가 공개됐어요. 글쓴이는 공격자가 피해자 근처 지역의 VPN이나 프록시로 접속한 뒤, Meta의 고객지원 AI에 “계정이 해킹됐다”고 말하는 흐름을 설명해요. 글쓴이는 Meta가 이미 이 문제를 막은 것으로 설명하지만, AI가 계정 복구처럼 권한이 큰 업무를 맡을 때 어떤 검증 절차가 필요한지 보여주는 사례예요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
취약점	username과 지역 위장만으로 계정 복구 요청이 시작됐어요	계정 복구 흐름이 공격 표면이 될 수 있다는 점을 보여줘요
AI 지원	공격자 이메일로 인증 코드가 가는 흐름이 있었다고 설명돼요	고객지원 AI가 어떤 결정을 내려도 되는지 경계를 다시 봐야 해요
2FA 우회	복구 절차가 소유자 초기화처럼 처리되면 기존 2FA가 무력해질 수 있어요	“2FA가 있으니 안전하다”는 전제가 깨지는 지점이에요
대응	글쓴이는 Meta가 이미 막은 것으로 설명해요	패치 이후에도 비슷한 지원 자동화 설계는 계속 점검해야 해요

1. 공격 시작점은 계정 이름 하나였어요

원문은 공격자가 인스타그램 username만 알아도 시도를 시작할 수 있었다고 설명해요. 공개 프로필이나 About 정보에서 대략적인 지역을 파악한 뒤, 피해자 도시 근처의 VPN이나 프록시로 접속하는 방식이에요. 이렇게 하면 보안 알고리즘이 평소와 다른 지역의 요청으로 보기 어려워질 수 있어요. 2

그다음 공격자는 고객지원 AI에 계정이 해킹됐다고 말하고, 자신이 통제하는 이메일로 인증 코드를 보내 달라고 요청해요. 원문에서 가장 큰 문제로 지목한 부분은 여기예요. 해당 이메일이 실제 계정 소유자가 과거에 썼던 주소인지, 계정과 어떤 관계가 있는지 충분히 확인하지 않은 채 다음 단계로 넘어갔다는 설명이에요.

2. 인증 코드를 받은 쪽이 곧 소유자처럼 처리됐어요

글쓴이는 이 흐름을 “제로 인증 비밀번호 재설정”에 가깝게 봐요. AI가 공격자 이메일로 코드를 보내고, 공격자가 그 코드를 다시 입력하면 검증이 끝난 것처럼 처리돼요. 이후 플랫폼이 새 비밀번호 재설정 링크를 넘기면서 계정 소유권이 공격자 쪽으로 넘어갈 수 있었다는 이야기예요. 2

이 대목이 단순한 챗봇 실수보다 위험한 이유는 권한 때문이에요. 고객지원 채팅은 보기에는 대화창이지만, 뒤에서는 계정 이메일 변경과 비밀번호 재설정 같은 높은 권한의 작업으로 이어져요. AI가 “상담원처럼 답하는 도구”를 넘어 “계정 상태를 바꾸는 도구”가 되면, 대화 품질보다 권한 검증이 먼저예요.

3. 2FA가 있어도 복구 절차가 더 위에 있으면 막기 어려워요

원문에 따르면 이 복구 흐름은 계정의 진짜 소유자가 전체 초기화를 요청한 것으로 처리됐어요. 그래서 기존 2FA가 우회되고, 세션 해지와 비밀번호 변경이 진행될 수 있었다고 설명해요. 글쓴이는 기존 소유자에게 이메일, 문자, 푸시 알림이 가지 않았다는 점도 문제로 짚어요. 2

많은 사용자는 2FA를 켜면 계정 탈취 위험이 크게 줄었다고 생각해요. 맞는 말이에요. 다만 2FA보다 상위 권한을 가진 복구 절차가 따로 있고, 그 절차가 허술하면 이야기가 달라져요. 공격자는 로그인 화면을 뚫는 대신 “내가 원래 주인인데 잠겼다”는 복구 절차를 노릴 수 있어요.

4. 영상 셀피도 만능 방어선은 아니었어요

인스타그램이 신원 확인용 영상 셀피를 요구할 수도 있지만, 원문은 이 검사도 안정적인 방어선으로 보기 어렵다고 말해요. 공개 피드의 사진을 AI로 움직이게 만든 영상만으로도 통과됐다는 보고가 많았다는 설명이에요. 2

여기서 문제는 AI 생성물이 직접 악용되는 방식이에요. 공개 사진은 원래 프로필 홍보나 기록을 위한 자료였어요. 이제는 계정 복구용 신원 확인을 속이는 입력값이 될 수 있어요. 영상 셀피가 필요한 서비스라면 “움직이는 얼굴” 자체보다, 촬영 시점과 기기, 계정 이력, 위험 신호를 함께 봐야 해요.

5. 짧은 핸들은 실제 돈이 걸린 표적이에요

원문은 Telegram 블랙마켓에서 계정 탈취 서비스가 빠른 처리 시간과 높은 가격으로 거래됐다고 설명해요. 특히 짧은 핸들은 수십만 달러에서 수백만 달러 가치가 붙을 수 있어요. `hey` 같은 짧은 계정이나 `obamawhitehouse`, `ocmssf` 같은 유명 계정이 사례로 언급돼요. 2

이건 단순한 장난이나 개인 계정 사고로 보기 어려워요. 인기 있는 username은 디지털 자산처럼 거래돼요. 유명 기관 계정은 선전이나 사칭에 쓰일 수 있어요. 계정 복구 자동화가 허술하면 피해는 개인 프로필을 넘어 브랜드, 기관, 공공 커뮤니케이션까지 번질 수 있어요.

6. 이미 막혔다고 해도 설계 질문은 남아요

글쓴이는 Meta가 이 방법을 이미 패치했다고 말해요. Telegram 그룹도 조용해졌다고 해요. 다만 이 방식이 몇 주에서 몇 달 동안 활성 상태였을 수 있다는 설명도 붙어 있어요. 1 2

패치 자체보다 더 오래 남는 질문은 고객지원 자동화의 경계예요. AI가 상담을 돕는 것과 계정 복구 결정을 내리는 것은 다른 문제예요. 이메일 변경, 2FA 초기화, 비밀번호 재설정 같은 작업은 공격자가 가장 먼저 노리는 지점이에요. 이런 작업에는 단일 채팅 판단이 아니라 여러 독립 신호와 지연, 알림, 인간 검토가 필요해요.

왜 중요한가요

AI 고객지원은 비용을 줄이고 응답 속도를 높일 수 있어요. 하지만 계정 복구처럼 실패 비용이 큰 업무에서는 “빠른 해결”이 곧 위험이 될 수 있어요. 사용자가 계정에 접근하지 못하는 상황을 도와야 하지만, 공격자가 그 상황을 흉내 낼 수도 있기 때문이에요.

서비스 운영자는 복구 절차를 로그인 절차만큼 엄격하게 봐야 해요. 기존 이메일과 전화번호, 장기 사용 기기, 최근 로그인 지역, 2FA 상태, 고위험 username 여부를 따로따로 확인해야 해요. 기존 연락처가 바뀌는 순간에는 원래 연락처로 지연 알림을 보내고, 일정 시간 안에 취소할 수 있는 장치도 필요해요.

사용자 입장에서는 짧은 username이나 유명 계정일수록 공격 표적이 될 수 있다는 점을 기억해야 해요. 2FA를 켜고, 계정의 이메일과 전화번호를 최신 상태로 유지하고, 복구 알림을 놓치지 않는 습관이 필요해요. 계정이 갑자기 로그아웃되거나 복구 수단이 바뀐 흔적이 있으면 바로 플랫폼 지원 채널과 공개 공지 채널을 함께 확인해 주세요. 1

참고 자료

최신 Instagram “익스플로잇”은 내가 본 것 중 가장 어이없다 — GeekNews
The Newest Instagram "Exploit" is the Goofiest I've Seen — Sid's Blog
Hacker News discussion — Hacker News

cron 대신 systemd 타이머를 볼 만한 이유

부지런한 게으름뱅이 — Tue, 2 Jun 2026 11:56:24 +0900

cron 대신 systemd 타이머를 볼 만한 이유

IT & AI 뉴스 썸네일

서버에서 정해진 시간에 작업을 돌릴 때 가장 먼저 떠오르는 도구는 여전히 `cron`이에요. 그런데 리눅스 서버가 systemd를 쓰고 있다면, 같은 일을 `.timer`와 `.service` 조합으로 더 추적하기 쉽게 만들 수 있어요.

핵심 요약

구분	핵심	왜 볼 만한가요
서버 운영	systemd 타이머는 일정에 맞춰 서비스 유닛을 실행해요	실행 이력과 출력이 journal에 남아 장애 추적이 쉬워져요
스케줄 표현	`OnCalendar`, `OnBootSec`, `OnUnitActiveSec`로 시간을 표현해요	“매일 0시”뿐 아니라 “부팅 1시간 뒤부터 매시간” 같은 흐름을 쓰기 좋아요
운영 안정성	`Persistent`, `WakeSystem`, 랜덤 지연 옵션을 제공해요	놓친 실행을 보완하거나 동시에 몰리는 실행을 줄일 수 있어요

1. cron 대신 systemd 타이머를 볼 만한 이유

`cron`은 단순하고 오래 검증된 도구예요. 문제는 작업이 실패했을 때부터 시작돼요. `$PATH`가 예상과 다르게 잡히고, 출력이 메일이나 사라진 로그로 흘러가고, 마지막 실행 결과를 찾기 어려운 경우가 많아요. 원문 글은 이 지점을 systemd 타이머가 줄여줄 수 있다고 설명해요. 1

systemd 타이머는 실행할 작업을 `.service` 유닛으로 두고, 언제 실행할지를 `.timer` 유닛에 적어요. 예를 들어 `backup.service`가 실제 백업 명령을 담고, `backup.timer`가 그 서비스를 언제 깨울지 정하는 식이에요. 이렇게 나누면 “무엇을 실행하나요”와 “언제 실행하나요”가 분리돼요. 2

systemd 타이머도 `daily`나 특정 시각 같은 벽시계 기준 일정을 쓸 수 있어요. `systemd-analyze calendar`로 시간 표현이 실제로 언제 실행되는지 확인할 수도 있어요. `cron` 표현식을 외워서 읽는 대신, 명령어로 다음 실행 시각을 확인하는 쪽에 가까워요. 2

더 흥미로운 부분은 이벤트 기준 실행이에요. `OnBootSec=1h`는 부팅 뒤 1시간 후 실행을 뜻하고, `OnUnitActiveSec=1h`는 서비스가 마지막으로 실행된 뒤 1시간 후 다시 실행을 뜻해요. 임시 파일 정리처럼 “매일 같은 시각”보다 “시스템이 켜진 뒤 일정 시간이 지나면”이 더 자연스러운 작업에 잘 맞아요.

운영자가 체감하는 차이는 로그예요. systemd 서비스로 실행하면 표준 출력과 오류가 journal에 남아요. `systemctl status`로 최근 상태를 보고, `systemctl list-timers`로 다음 실행 시각과 마지막 실행 시각을 한 번에 볼 수 있어요. 작업이 돌았는지, 실패했는지, 다음 일정이 언제인지 확인하는 과정이 짧아져요.

물론 모든 상황에서 systemd 타이머가 `cron`보다 낫다는 뜻은 아니에요. `crontab -e` 한 줄로 끝나는 단순 작업도 많아요. 사용자 단위 타이머는 설정 파일이 늘어나는 부담도 있어요. 그래도 이미 systemd 위에서 서버를 운영하고 있다면, 주기 작업을 서비스 유닛으로 다루는 방식은 충분히 검토할 만해요.

왜 중요한가요

정기 작업은 작을 때는 별문제가 없어 보여요. 하지만 배포, 백업, 정리 작업, 상태 체크처럼 반복되는 일이 늘면 “실패했을 때 어디서 보나요”가 중요해져요. systemd 타이머는 스케줄러를 따로 쓰는 대신, 이미 운영 중인 서비스 관리 체계 안에서 정기 작업을 다룰 수 있게 해요.

노트북이나 개발 서버처럼 항상 켜져 있지 않은 장비에서는 정해진 시각을 놓치는 일이 생겨요. `Persistent=true`를 쓰면 타이머가 비활성 상태였던 동안 놓친 실행을 다시 온라인이 된 뒤 보완할 수 있어요. 꼭 절전 상태에서 깨워야 하는 작업이라면 `WakeSystem`도 선택지가 돼요. 1

여러 서버가 같은 시각에 업데이트 확인을 시작하는 문제도 있어요. 원문은 `RandomizedOffsetSec`와 `FixedRandomDelay` 같은 옵션을 소개해요. 모든 장비가 자정 정각에 같은 API를 치지 않도록 실행 시각을 안정적으로 흩뿌리는 방식이에요. 작은 옵션처럼 보여도, 운영 규모가 커지면 꽤 실용적인 차이가 나요.

개발자가 바로 가져갈 만한 포인트도 분명해요. 첫째, “정기 실행”을 단순한 명령 한 줄이 아니라 서비스로 다룰 수 있어요. 실패 처리, 재시작, 조건부 실행, 로그 확인을 systemd 안에서 이어 붙일 수 있어요. 둘째, `systemd-analyze calendar`로 시간 표현을 실행 전에 확인할 수 있어요. 셋째, `systemctl list-timers`로 지금 머신에서 어떤 예약 작업이 살아 있는지 한눈에 볼 수 있어요.

참고 자료

당신은 systemd 타이머를 충분히 좋아하지 않는군요 — GeekNews
You Don't Love systemd Timers Enough — Tyblog

제품 전략 회의에서 진짜로 물어야 할 질문은 따로 있어요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 11:40:08 +0900

제품 전략 회의에서 진짜로 물어야 할 질문은 따로 있어요

AI 뉴스 썸네일

제품 전략 회의에서 “넓게 갈까요, 깊게 갈까요?”라는 질문은 꽤 그럴듯해 보여요. 문제는 이 질문이 팀을 구체적인 고객 문제로 데려가지 못할 때가 많다는 점이에요.

Shreyas Doshi가 올린 글은 AI 스타트업을 운영하는 창업자의 고민에서 출발해요. 경쟁사가 같은 시장에 들어오자, 팀은 제품 범위를 넓힐지 이미 가진 기능을 더 깊게 만들지 묻기 시작했어요. Doshi는 이 질문 자체를 버리라고 조언해요. 진짜 전략은 추상적인 구도보다 “어떤 고객이 어떤 기능 때문에 사고 남는가”에 더 가까이 있기 때문이에요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
제품 전략	“넓게 vs 깊게” 같은 구도는 회의를 쉽게 길게 만들어요	팀이 똑똑해 보이는 말보다 고객과 기능을 바로 봐야 해요
AI 스타트업	거대 경쟁사가 들어오면 제품 범위 논쟁이 빨리 커져요	불안할수록 추상적인 전략 용어에 숨기 쉬워요
고객 이해	진짜 질문은 “어떤 기능이 어떤 고객을 붙잡는가”예요	제품 로드맵이 고객 문제와 연결되는지 점검할 수 있어요
실행 기준	차별화를 빠르게 만들 수 있으면 넓이와 깊이는 결과로 따라와요	방향 논쟁보다 구체적인 베팅을 먼저 보게 해요

1. “넓게 갈지, 깊게 갈지”는 편한 질문이에요

제품팀이 성장 방향을 이야기할 때 “넓게 갈까, 깊게 갈까”는 자주 나오는 질문이에요. 기능을 더 많이 붙일지, 특정 영역을 더 강하게 만들지 고르는 것처럼 보여요. 특히 AI 스타트업처럼 큰 회사가 빠르게 따라오는 시장에서는 더 자연스러운 질문이에요. 1

하지만 이 질문은 회의실을 안전한 추상어로 끌고 가요. 플랫폼이냐 포인트 솔루션이냐, 수평이냐 수직이냐, CAC를 낮출 거냐 LTV를 높일 거냐 같은 말이 이어져요. 다 맞는 말처럼 들리지만, 고객이 왜 돈을 내는지에는 아직 닿지 못해요.

그래서 이 글이 흥미로운 지점은 “전략 프레임워크를 잘 골라야 한다”가 아니에요. 오히려 프레임워크가 너무 빨리 등장하면 팀이 어려운 질문을 피할 수 있다는 경고에 가까워요.

2. 경쟁사가 들어오면 질문이 더 추상적으로 변해요

원문 속 창업자는 AI 스타트업을 운영하고 있었고, 두 곳의 큰 기존 사업자가 같은 영역에 들어온 상황이었다고 해요. 이런 순간에는 팀이 흔들리기 쉬워요. 제품을 더 크게 보이게 만들지, 작은 영역을 더 날카롭게 만들지 논쟁이 생겨요. 1

큰 경쟁자는 팀의 언어까지 바꿔요. 갑자기 로드맵보다 포지셔닝이 커지고, 고객 인터뷰보다 시장 지도가 앞에 놓여요. 그 자체가 나쁜 건 아니에요. 다만 그 말들이 “이번 분기에 어떤 기능을 만들면 어떤 고객이 실제로 남을까”라는 질문을 밀어내면 문제가 생겨요.

AI 제품 시장에서는 이 함정이 더 쉽게 보여요. 모델 성능, 에이전트, 워크플로, 플랫폼 같은 단어가 워낙 빠르게 돌기 때문이에요. 단어는 빨리 바뀌지만 고객의 구매 이유는 훨씬 느리게 움직여요.

3. 진짜 질문은 한 단계 아래에 있어요

Doshi가 제안하는 방향은 단순해요. “넓게 갈지, 깊게 갈지”를 묻기 전에, 특정 고객이 겪는 특정 불편을 먼저 봐야 해요. 그 고객이 어떤 기능을 보면 돈을 낼지, 어떤 경험 때문에 계속 쓸지 묻는 쪽이 더 직접적이에요. 2

이 질문은 회의에서 덜 멋있게 들릴 수 있어요. 대신 답하기 훨씬 어려워요. 고객을 제대로 알아야 하고, 경쟁 제품과 다른 지점을 만들어야 하고, 그 차이를 빠르게 구현할 수 있어야 해요.

답이 명확하면 넓이와 깊이는 굳이 따로 싸울 문제가 아니에요. 필요한 곳에서는 넓어지고, 고객이 구매하는 지점에서는 깊어져요. 제품의 모양은 추상적인 선택지에서 나오기보다 고객 통찰과 실행 속도에서 나와요.

4. 제품 팀이 바로 써먹을 수 있는 체크는 세 가지예요

첫째, 지금 말하는 고객이 실제 고객인지 봐야 해요. “중소기업”, “개발자”, “마케터”처럼 넓은 이름만 남아 있으면 아직 멀어요. 어제 통화한 고객의 업무, 예산, 불만, 대체 수단까지 떠올릴 수 있어야 해요.

둘째, 기능이 구매 이유와 연결되는지 봐야 해요. 보기 좋은 기능과 결제하게 만드는 기능은 달라요. 데모에서 박수받는 기능이 실제 도입 뒤에는 거의 쓰이지 않을 수도 있어요.

셋째, 팀이 그 차이를 빠르게 만들 수 있는지 봐야 해요. 전략이 맞아도 구현이 느리면 시장에서 배울 시간이 줄어요. 작은 기능이라도 고객 반응을 빨리 확인할 수 있으면 다음 결정이 훨씬 선명해져요.

왜 중요한가요

제품 전략 회의의 품질은 말의 크기보다 질문의 위치에 달려 있어요. 질문이 너무 위에 있으면 누구나 그럴듯하게 말할 수 있어요. 질문이 고객과 기능까지 내려가면 팀이 실제로 아는 것과 모르는 것이 드러나요. 1

기획자와 창업자에게 이 글은 좋은 경고가 돼요. 경쟁사가 들어오거나 시장이 흔들릴수록 팀은 멋진 구도로 도망가고 싶어져요. 그때 필요한 건 더 큰 전략 용어가 아니라 더 작은 고객 장면이에요. 누가, 어떤 문제 때문에, 어떤 기능을 보고, 왜 계속 쓰는지 말할 수 있어야 해요.

AI 제품을 만드는 팀도 마찬가지예요. “에이전트 플랫폼이 될까, 특정 워크플로 도구가 될까”보다 먼저 볼 질문이 있어요. 지금 고객이 반복해서 겪는 병목이 무엇인지, 그 병목을 줄이는 기능을 팀이 빠르게 만들 수 있는지가 더 중요해요. 2

참고 자료

본질의 핵심에 도달하라 — GeekNews
Shreyas Doshi X 게시물 — X

Rust로 다시 쓴 Zstandard, 압축 라이브러리도 메모리 안전성을 묻기 시작했어요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 11:28:34 +0900

Rust로 다시 쓴 Zstandard, 압축 라이브러리도 메모리 안전성을 묻기 시작했어요

AI 뉴스 썸네일

압축 라이브러리는 대부분 눈에 띄지 않아요. 그래도 웹 트래픽, 패키지 배포, 로그 저장, 빌드 도구 안쪽에서 매일 쓰여요.

Trifecta Tech Foundation이 Zstandard의 Rust 기반 구현인 `libzstd-rs-sys` 첫 프리릴리스를 공개했어요. 핵심은 단순한 언어 교체가 아니에요. 오래 쓰인 C 기반 압축 라이브러리도 이제 이식성, 검증, 메모리 안전성을 다시 따져 보는 흐름에 들어왔다는 점이에요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
오픈소스 인프라	Zstandard를 Rust로 구현한 `libzstd-rs-sys` 첫 프리릴리스가 나왔어요	웹·빌드·패키징에서 쓰이는 압축 계층이 Rust 쪽으로 넓어지는 사례예요
개발 경험	기존 Rust `zstd` 크레이트는 C 코드를 함께 빌드해야 해요	Windows나 WebAssembly처럼 C 툴체인 설정이 번거로운 환경에서 차이가 커요
성능과 안전성	기본 압축 해제는 C보다 몇 퍼센트 느리지만, 실험 플래그를 켜면 C 성능에 맞출 수 있어요	약 3% 성능 비용을 메모리 안전성과 맞바꾸는 선택지가 생겼어요
검증 방식	테스트 스위트, 퍼즈 테스트, Miri를 함께 써요	“Rust라서 안전해요”가 아니라 실제 호환성과 정확성을 확인하는 쪽에 가까워요

1. Zstandard가 Rust 구현을 얻었어요

Zstandard는 gzip보다 빠르고 압축률도 좋은 압축 형식으로 많이 쓰여요. Trifecta Tech Foundation은 zlib-rs, bzip2-rs에 이어 Zstandard도 Rust로 옮기는 프로젝트를 진행하고 있어요. 이번에 공개된 `libzstd-rs-sys`는 그 첫 프리릴리스예요. 2

중요한 점은 이 구현이 Rust 프로젝트에서만 쓰이는 보조 라이브러리에 머물지 않는다는 거예요. Trifecta 쪽은 이를 드롭인 호환 C 라이브러리로도 컴파일할 수 있게 만들고 있어요. 기존 C 참조 구현을 바로 대체할 수 있는 선택지를 만들겠다는 뜻이에요.

압축 라이브러리는 애플리케이션의 가장 바깥보다 안쪽에 가까워요. 그래서 한 번 자리 잡으면 오래 가요. 이런 계층에서 Rust 구현이 늘면, 메모리 안전성 논의가 브라우저나 서버 프레임워크를 넘어 더 낮은 레벨의 인프라까지 내려가는 셈이에요.

2. Rust 개발자가 체감할 변화는 이식성이에요

Rust에서 Zstandard를 쓰는 길은 이미 있었어요. 다만 기존 `zstd` 크레이트는 C 코드를 소스에서 컴파일해요. 이 방식은 대상 플랫폼에 맞는 C 툴체인과 빌드 환경이 있어야 해요. 2

일반적인 리눅스 서버에서는 큰 문제가 아닐 수 있어요. Windows, WebAssembly, 교차 컴파일 환경에서는 얘기가 달라져요. 빌드 스크립트 하나가 C 컴파일러를 찾지 못해 막히는 경험은 Rust 개발자에게 꽤 익숙해요.

순수 Rust 구현은 이런 마찰을 줄여요. 의존성이 Rust 생태계 안에서 빌드되면 타깃 지원과 패키징이 단순해져요. 특히 WASM이나 임베디드처럼 툴체인이 예민한 환경에서는 “그냥 빌드돼요”에 가까워지는 게 큰 장점이에요.

3. 성능은 거의 맞췄지만, 선택지가 남아 있어요

Trifecta는 기본 압축 해제 성능이 C 참조 구현보다 몇 퍼센트 느리다고 밝혔어요. 원문에서는 약 3% 수준의 성능 저하를 메모리 안전성을 위한 비용으로 설명해요. 2

흥미로운 부분은 실험 플래그예요. `unsafe-performance-experimental` 기능을 켜면 C 구현과 성능을 맞출 수 있어요. 대신 입력 데이터가 자료구조 인덱싱에 쓰이는 일부 위치에서 경계 검사를 끄는 방식이에요.

이건 꽤 현실적인 선택지예요. 기본값은 안전한 쪽에 두고, 마지막 성능이 필요한 사용자는 위험을 알고 플래그를 켤 수 있어요. 모든 사용자를 한쪽으로 몰지 않고, 안전성과 성능 사이의 기준선을 드러낸다는 점이 좋아요.

4. “Rust로 포팅했어요”보다 검증 방식이 더 중요해요

프로젝트는 처음에 C 구현을 `c2rust`로 변환한 뒤 압축 해제와 딕셔너리 빌더 쪽 정리 작업을 진행했어요. 이후 Rust 코드를 C 정적 라이브러리로 컴파일해 참조 구현 테스트 스위트로 검증하고 있어요. 퍼즈 테스트와 Miri도 함께 사용해요. 2

압축 알고리즘은 결과가 한 비트만 달라도 문제가 돼요. 성능만 빠른 구현은 충분하지 않아요. 기존 구현과 같은 결과를 내는지, 이상한 입력에서 깨지지 않는지, 경계 조건에서 안전한지를 계속 확인해야 해요.

이 과정에서 Miri의 한계가 발견돼 해결됐고 Clippy에도 기여가 있었다고 해요. 라이브러리 하나를 Rust로 옮기는 작업이 Rust 도구 자체를 더 낫게 만드는 쪽으로 이어진 셈이에요.

5. 아직 끝난 프로젝트는 아니에요

현재 정리 작업은 압축 해제와 딕셔너리 빌더 중심이에요. 압축 구현은 아직 많은 정리 작업이 남아 있고, 프로젝트는 이 부분의 펀딩도 찾고 있어요. 남은 작업은 Encoder implementation 마일스톤에 정리돼 있어요. 2

생태계 통합도 남아 있어요. Trifecta는 `libzstd-rs-sys`를 C 라이브러리 대신 쓰는 `zstd` 포크를 갖고 있고, 향후 업스트림 반영을 원해요. 자주 쓰는 API에서는 비교적 단순하지만, 실험 기능 쪽에서는 FFI 안전성 때문에 타입 설계 차이가 생겨요.

그래서 이번 발표는 “Zstd가 이제 Rust로 완전히 대체됐어요”라는 소식은 아니에요. 더 정확히는, C 압축 라이브러리를 Rust 구현으로 대체하기 위한 첫 공개 지점이에요. 앞으로 성능, 호환성, 업스트림 통합이 얼마나 매끄럽게 이어지는지가 관건이에요.

왜 중요한가요

오픈소스 인프라는 화려한 기능보다 오래 버티는 기본기가 중요해요. 압축 라이브러리는 그중에서도 많은 소프트웨어가 조용히 의존하는 영역이에요. 여기에 Rust 구현이 들어온다는 건, 메모리 안전성을 애플리케이션 바깥이 아니라 기반 라이브러리 안쪽에서 다루겠다는 움직임이에요. 2

개발자 입장에서는 이식성이 먼저 와닿아요. C 툴체인 없이 Rust 의존성을 빌드할 수 있으면 Windows, WebAssembly, 교차 컴파일 환경에서 실패 지점이 줄어요. 성능이 아주 중요한 서비스라면 실험 플래그와 벤치마크를 따져야 해요. 일반적인 사용처라면 약간의 성능 비용을 안전성과 빌드 단순성으로 바꿀 수 있어요. 2

참고 자료

Rust로 구현한 Zstandard 발표 — GeekNews
Announcing Zstandard in Rust — Trifecta Tech Foundation
libzstd-rs-sys GitHub 저장소 — GitHub
libzstd-rs-sys v0.0.1-prerelease.2 — GitHub Releases

AI 시대, 기술 면접은 무엇을 봐야 할까요

부지런한 게으름뱅이 — Tue, 2 Jun 2026 11:12:14 +0900

AI 시대, 기술 면접은 무엇을 봐야 할까요

AI 뉴스 썸네일

AI 코딩 도구가 좋아질수록 기술 면접은 더 애매해져요. 과제를 집에서 풀게 하면 도구 도움을 어디까지 봐야 할지 흐려지고, 라이브 코딩을 시키면 실제 업무와 너무 다르다는 불만이 남아요. 이번 글의 핵심은 단순해요. 면접은 최신 도구 사용법보다, 도구가 바뀌어도 남는 기초 역량을 더 선명하게 봐야 해요.

핵심 요약

구분	핵심	왜 볼 만한가요
기술 면접	AI 사용을 기본값으로 열어두기보다, 기초 역량을 먼저 보자는 주장	개발자 채용 방식이 AI 코딩 도구 때문에 다시 흔들리고 있어요
과제형 면접	take-home 과제는 AI 덕분에 후보에게 쉬워지고, 회사에는 리뷰 부담이 커져요	과제 제출물만 보고 실력을 판단하기 어려워져요
라이브 평가	live exercise와 리뷰형 질문의 비중이 커질 수 있어요	사람이 직접 추론하고 설명하는 장면을 더 잘 볼 수 있어요
채용 기준	AI 숙련도는 도구적 기술이고, 문제 분해·리뷰·판단은 기초 역량이라는 구분	지금 잘 쓰는 도구보다 오래가는 역량을 봐야 한다는 관점이에요

1. AI가 잘하는 코딩 과제는 면접 신호를 흐리게 해요

Charles-Axel Dein은 기술 면접을 볼 때 AI 사용을 대체로 제한해야 한다고 주장해요. 이유는 후보가 AI를 쓸 수 있는지 자체가 아니라, 회사가 정말 알고 싶은 신호가 흐려지기 때문이에요. 집에서 푸는 과제는 예전에는 설계, 구현, 테스트 습관을 한 번에 보여줬어요. 지금은 같은 과제가 AI 보조를 받으면 훨씬 쉬워지고, 회사는 사람이 만든 판단과 모델이 만든 산출물을 분리해서 봐야 해요. 1

이 변화는 후보에게만 유리한 문제가 아니에요. 회사로서는 제출물이 늘 비슷하게 좋아 보일 수 있고, 리뷰할 코드는 더 많아져요. 나쁜 코드나 애매한 설계를 반박하는 일은 새 코드를 만드는 일보다 시간이 더 걸릴 때가 많아요. AI가 만든 제출물을 다시 AI로 평가하면, 결국 사람은 그 평가를 또 확인해야 해요. 2

2. 좋은 면접은 신호 품질과 회사 비용을 같이 봐야 해요

원문은 좋은 면접을 두 축으로 나눠요. 하나는 신호 품질이에요. 후보가 실제로 문제를 이해하고, 모호한 요구사항을 풀고, 설계의 장단점을 설명할 수 있는지 보는 능력이에요. 다른 하나는 회사 비용이에요. 문제를 만들고, 면접관을 교육하고, 점수 기준을 맞추고, 후보 경험을 해치지 않는 데 드는 시간이에요. 2

이 두 축은 따로 움직이지 않아요. 아주 어려운 문제는 좋은 후보를 잘 드러낼 수 있지만, 좋은 후보를 놓칠 위험도 커져요. 반대로 너무 쉬운 문제는 후보에게 편하지만, 회사가 얻는 신호가 약해져요. AI 시대에는 이 균형이 더 까다로워져요. 과제가 쉬워질수록 제출물의 품질보다, 후보가 문제를 어떻게 이해하고 바꿔 설명하는지가 더 중요해져요.

3. take-home보다 live exercise와 리뷰형 질문이 더 중요해질 수 있어요

면접 유형은 크게 집에서 푸는 과제, 면접관 앞에서 푸는 실시간 과제, 발표형 면접, 실제 업무에 가까운 유급 협업으로 나눌 수 있어요. 이 중 take-home은 AI 코딩 도구와 가장 정면으로 부딪쳐요. 후보가 긴 과제를 빠르게 만들 수 있으면, 회사는 결과물만 보고 실력을 읽기 어려워져요.

반대로 실시간 과제나 리뷰형 질문은 사람이 생각하는 과정을 더 직접 볼 수 있어요. 예를 들어 기존 코드의 문제를 찾게 하거나, AI가 만든 계획을 검토하게 하거나, 제품 요구사항 문서의 빈틈을 짚게 할 수 있어요. 이런 질문은 단순 구현 속도보다 판단, 설명, 우선순위 감각을 드러내요. 원문이 말하는 방향도 여기에 가까워요. AI 산출물을 만드는 능력보다, 산출물을 읽고 고칠 수 있는 사람의 역량을 더 중시한다는 뜻이에요. 2

4. AI 숙련도는 필요하지만, 채용의 중심이 되긴 어려워요

AI 도구를 잘 쓰는 능력은 업무에서 분명히 중요해요. 하지만 원문은 그것을 기초 역량이 아니라 도구적 기술로 봐요. 프로그래밍 언어나 에디터 사용법처럼, 배울 수 있고 바뀔 수 있는 기술이라는 뜻이에요. 반면 문제를 쪼개는 능력, 복잡한 시스템을 이해하는 힘, 코드 리뷰에서 위험을 감지하는 습관은 더 오래가는 역량이에요.

이 구분은 개발 조직에 꽤 현실적인 질문을 던져요. 회사가 뽑으려는 사람은 특정 AI 도구의 능숙한 사용자일까요, 아니면 도구가 바뀌어도 문제를 끝까지 이해하는 엔지니어일까요. 둘 다 필요하지만, 면접 시간이 짧다면 우선순위를 정해야 해요. Anthropic도 후보 안내에서 별도 지시가 없으면 take-home 과제를 Claude 없이 완료하라고 안내해요. AI 기업조차 채용 평가에서는 사람의 기본 판단을 따로 보려는 셈이에요. 3

왜 중요한가요

개발자 채용은 이미 AI 코딩 도구의 영향을 받고 있어요. 후보는 더 빠르게 코드를 만들 수 있고, 회사는 더 그럴듯한 제출물을 받아요. 하지만 면접의 목표가 좋은 제출물 수집이 아니라 좋은 동료 찾기라면, 평가 방식도 달라져야 해요. 2

특히 스타트업이나 작은 팀에는 비용 문제가 커요. 새로운 문제를 계속 만들고, 유출을 막고, AI 저항 과제를 설계하는 데 시간을 많이 쓰기 어려워요. 그래서 더 현실적인 선택은 면접에서 AI를 무조건 찬양하거나 무조건 두려워하는 쪽이 아니에요. 후보가 직접 생각해야 하는 순간을 만들고, 그 생각을 설명하게 하고, 실제 업무에서 중요한 리뷰 감각을 확인하는 쪽이에요.

결국 기술 면접의 질문은 “AI를 쓸 줄 아나요?”에서 끝나면 부족해요. “AI가 만든 답을 이해하나요?”, “틀렸을 때 알아차리나요?”, “요구사항이 바뀌면 다시 설계할 수 있나요?”까지 봐야 해요. 이 글이 흥미로운 이유도 여기에 있어요. AI 시대의 채용 문제를 도구 사용 여부가 아니라, 사람이 어떤 역량을 가져야 하는지로 다시 돌려놓아요. 1

참고 자료

AI 시대의 기술 면접 — GeekNews
Interviewing in the age of AI — Charles-Axel Dein
Candidate AI guidance — Anthropic