쵸코쿠키의 연습장

프론트엔드 프리랜서·외주, 스택 말고 기존 코드를 본다

프론트엔드 프리랜서를 맡기는 쪽이 먼저 보는 것은 기존 코드를 이해하고 수정 범위를 통제하는지다. 프론트엔드 외주를 맡기기 전에 확인하는 기준을 아래에 정리했다. 프리랜서로 수주해 본 경험이 아니라 맡기는 쪽에서 본 기준이다. 프론트엔드 외주를 맡길 때, 스택 이름보다 먼저 보는 것맡기는 쪽이 먼저 보는 것은 기존 코드베이스를 이해하고, 그 방식에 맞춰 수정 범위를 통제할 수 있는지다.회사에서 외부 개발자·협력 인력의 결과물을 받아보거나 함께 개발한 적이 있다. 내가 직접 본 사례는 Java/Spring 백엔드 작업이다. 기준은 프론트엔드에도 같다."Spring을 할 줄 안다"는 말은 판단 재료가 못 된다. 기존 구조, 공통 라이브러리, 테스트 방식, 배포 과정을 파악하고 있는지가 중요하다. "Reac..

herdr·cmux 전에, 에이전트 3개부터의 병목

병렬 에이전트가 3개를 넘으면 병목은 터미널이 아니라 사람의 주의력이다. Claude Code와 Codex를 tmux에서 합쳐 2~4개 돌려보고 내린 판단이다.pane을 더 만드는 건 문제가 아니었다. 다른 pane을 보는 동안 한 에이전트가 승인 대기로 멈춘 걸 늦게 알아챘고, 결과가 한꺼번에 나오면 diff를 읽는 사람 쪽에 큐가 생겼다. 그래서 새 도구를 볼 때도 "몇 개를 띄울 수 있나"보다 "어디에 내 주의력이 필요한지 얼마나 빨리 알려주나"를 먼저 본다.범위부터 밝힌다. tmux는 수년간 사용했고, 현재 로컬 개발에서는 Ghostty도 쓴다. herdr와 cmux는 설치해서 짧게 직접 써 본 범위까지만 확인했다. Orca는 써보지 않아 공식 자료만 정리했다. worktree를 써도 남는 .en..

코딩테스트 부정행위, AI 사용은 어디까지 되나

코딩테스트에서 AI를 써도 되는지는 그 시험의 안내문이 정한다. 금지라고 적혀 있으면 쓰지 않는 것이 경계다. 준비 단계에서는 먼저 직접 푼 뒤에 AI로 다른 풀이를 확인하는 쪽이 안전하다고 본다.먼저 내 위치를 밝혀둔다. 실제 채용 코딩테스트에서 AI로 풀거나 답안을 받아 제출한 적은 없다. AI는 이직 준비 중 연습 문제와 모의 코딩테스트를 푼 뒤 풀이를 비교하는 데만 썼다. 준비 중에는 먼저 직접 풀고, AI는 그다음에 쓴다준비 중에는 먼저 직접 풀고 테스트까지 끝낸 뒤에 AI로 다른 접근과 놓친 edge case를 비교하는 순서가 안전하다고 본다.해시맵으로 중복을 처리하는 연습문제가 기억에 남는다. 혼자 연습하던 문제였고, 먼저 직접 푼 뒤 AI에게 정답을 묻는 대신 내 풀이를 깨뜨리는 최소 반..

MySQL 데드락 로그, 롤백된 쪽이 범인이 아니다

Deadlock found when trying to get lock; try restarting transaction. Spring 쪽 예외만 봤을 때는 DB가 느려져 락을 오래 기다린 문제인가 싶었는데, root cause에 이 문장이 있었다.1213은 timeout이 아니고, 롤백된 쪽은 범인이 아니며, 재시도는 복구일 뿐 고칠 것은 락 순서였다. 1213은 timeout이 아니었다1213은 InnoDB가 순환 대기를 감지해 transaction 하나를 바로 롤백한 사건이고, 1205는 락을 기다리다 대기 시간이 초과된 사건이다. 에러 문구도 ERROR 1213 (40001)과 Lock wait timeout exceeded로 다르다.처음 Spring 쪽 예외만 봤을 때는 락을 오래 기다린 tim..

채용공고 AI 점수를 믿었다가 틀린 두 방향

Apify로 채용공고를 모아 Claude에 넣는 POC를 직접 돌렸다. 올여름부터는 사람인·원티드·점핏 등의 AI 엔지니어 공고를 스프레드시트에 손으로 정리해 일부를 AI로 대조했다. 이 과정에서 채용공고 AI 점수를 지원 여부의 판정기로 쓴 것이 두 방향으로 틀렸다. 지금은 무엇부터 읽을지 정하는 정렬값으로만 쓴다.POC 규모는 수십 건~100건 안팎이다. 비용과 작업시간은 기록하지 못했다. 이 글은 자동 지원 가이드가 아니다. 점수를 매기기 전에 무엇이 먼저 막혔나점수보다 전처리가 먼저 막혔다. 마감·중복·표기 불일치·불필요한 문구를 정리하지 않으면 점수의 근거부터 오염된다.막힌 점은 다섯 가지였다.이미 마감된 공고가 섞여 들어왔다.같은 공고가 URL과 문구만 달리해 중복으로 잡혔다.신입·경력 표기..

Kafka lag, consumer 늘리기 전 확인순서

Kafka lag이 오르면 consumer부터 늘리지 않는다. partition별 lag, 처리시간, partition revoked/assigned 로그를 이 순서로 먼저 본다.회사 Spring Boot 서비스에서 Spring Kafka consumer를 운영하며 중복 처리, lag 급증, 리밸런싱 반복을 모두 겪었다. lag 급증과 리밸런싱 반복은 서로 다른 별개의 사건이다. consumer group은 partition 12개 정도에 평상시 instance 3개였다. broker 운영 전담은 아니고, 이 글의 경험은 classic consumer group 기준이다. Kafka 중복·lag·리밸런싱, 무엇부터 확인하나세 증상은 보는 곳이 다르다. lag은 partition별 lag과 처리시간, 리..

이중화와 백업 차이: replica는 실수도 복제한다

replica가 정상이라는 말은 데이터가 안전하다는 뜻이 아니었다. 잘못된 DELETE도 정상적으로 복제된다는 걸 직접 확인한 뒤로, 가용성·복제·백업·PITR을 같은 체크박스의 다른 이름으로 보지 않는다.이중화(Redundancy)·replica·Multi-AZ는 장애를 버티게 하고, 백업·PITR은 과거로 돌아가게 한다.여기서 redundancy는 정리해고가 아니라 시스템 이중화를 뜻한다. DB를 다루는 백엔드 개발자를 기준으로 쓴다. 이중화·복제·백업은 뭐가 다른가이중화는 부품이 죽어도 계속 돌게 하는 복사본, 복제는 변경을 그대로 따라가는 복사본, 백업은 과거 시점이 남아 있는 복사본이다.Microsoft Learn은 redundancy를 디스크에 가두지 않고 서비스 컴포넌트 단위(VM·API ..

git worktree 병렬 에이전트, 파일만 격리된다

git worktree로 Claude Code와 Codex를 병렬로 돌렸더니 파일 충돌은 줄었다. 대신 .env와 포트, DB가 깨졌다.worktree는 에이전트 격리가 아니라 working tree 격리다. 실패를 겪고 나서야 구분하게 됐다. 같은 폴더에서 에이전트 둘을 돌렸더니 diff가 섞였다git worktree는 에이전트가 아니라 working tree만 나눈다. 파일 diff는 분리되지만 환경·포트·DB 같은 실행 상태는 따로 준비해야 한다.처음엔 worktree 없이 같은 폴더에서 Claude Code와 Codex에 서로 다른 수정을 맡겼다. 한쪽이 파일을 고친 상태에서 다른 쪽이 같은 저장소의 git diff를 보고 작업했고, 자기가 만들지 않은 변경까지 현재 작업의 일부로 받아들였다.c..

컴공 졸업 후 취업 막막할 때, 지원 늘리기 전 점검

신입 개발자 취업이 막막하고 연락이 없을 때는 지원 수를 늘리기 전에 어느 단계에서 막혔는지부터 가르는 게 먼저다. 서류에서 멈춘 건지, 맞는 공고가 없는 건지, 코딩테스트나 면접에서 끊긴 건지에 따라 바꿀 것이 전혀 다르다.이 글은 면접 이전 단계를 중심으로 다룬다. 나는 현직 백엔드 개발자고, 채용 과정에서 지원자의 이력서와 프로젝트 자료를 직접 검토했고 기술면접에도 면접관으로 들어갔다. 11~12학번 컴퓨터공학과로 학교를 다녔고 졸업 전후에는 나도 신입 개발자 취업을 준비했다.그 경험은 2026년의 정답이 아니라 비교 기준이다. 시장 자료와 공고는 2026년 10월에 확인했다. 신입 개발자 취업이 막막할 때, 어느 단계에서 막혔는지 어떻게 가르나지원 후 연락이 없으면 서류, 적합한 공고, 코딩테스..

Primary Key Unique Key 차이

Primary Key(PK, 기본키)는 행 하나를 대표하는 키다. 값이 중복되지도 NULL이 되지도 않고 테이블에 하나만 둔다. Unique Key(UK, 유니크키)는 중복만 막는다. NULL을 몇 개 받는지는 DBMS마다 다르다.등록 전에 exists로 확인했으니 중복은 안 생길 거라고 믿었던 적이 있다. 동시 요청 두 개가 그 믿음을 깼고, 그 뒤로 UNIQUE의 NULL 처리까지 따로 확인하게 됐다. 이 글은 그 두 가지를 중심으로 PK와 UK의 차이를 정리한다. 기본키와 유니크키, 무엇이 다른가기본키(PRIMARY KEY)는 중복과 NULL을 모두 막는 행의 대표 식별자이고, 유니크키(UNIQUE 제약)는 중복만 막는다. 기본키는 테이블당 하나, UNIQUE는 여러 개 걸 수 있다. 항목PRIM..

DDL DML DCL 차이, DDL도 롤백될까

DDL은 테이블 같은 구조를, DML은 그 안의 데이터를, DCL은 권한을, TCL은 COMMIT·ROLLBACK 같은 트랜잭션을 다룬다. 이 중 롤백 여부가 가장 크게 갈리는 쪽은 DDL이고, 그 답은 DBMS마다 다르다.MySQL에서 START TRANSACTION 안에서 ALTER TABLE을 하고 ROLLBACK했는데 변경이 그대로 남아 있던 적이 있다. 그 일을 중심으로 분류, 롤백 경계, 실무에서 바뀐 판단을 정리한다. DDL·DML·DCL·TCL은 각각 무엇이 다른가DDL은 구조(스키마)를 정의하고, DML은 데이터를 다루고, DCL은 권한을 제어하고, TCL은 트랜잭션을 확정하거나 취소한다. 기준은 명령이 무엇을 대상으로 하느냐다. 분류대상대표 명령교재·DBMS별 분류 차이DDL테이블·인..

Claude effort 비용, 내 작업으로 재는 법

Sonnet 5.5(claude-sonnet-5-5)로 같은 코드 수정 작업을 low, medium, high에서 5회씩 돌렸다. 내 기록에서 low는 첫 호출이 가장 쌌다. 하지만 5회 중 2회는 테스트가 깨져 재호출이 필요했고, 그 두 건은 합계가 medium 1회보다 비쌌다.그래서 claude effort 비용은 단가표가 아니라 성공한 작업 1건당 비용으로 봐야 한다고 본다. Anthropic 발표문의 'up to 30% less per task'(Sonnet 5 대비 작업당 최대 30% 저렴)는 자체 테스트의 상한이라 내 측정과 비교 대상이 다르다. 이 글은 그 값을 확인하지도 반박하지도 않는다. effort별 작업당 비용은 어떻게 재야 비교가 되는가snapshot, prompt, 경로, 캐시 ..

Agent SDK 세션, 저장과 context는 다르다

Claude Agent SDK의 세션 기능을 쓰든 직접 loop를 짜든, 에이전트 세션 관리는 세 문제로 나눠야 했다. 대화를 저장하는 것, 모델에게 다시 보여줄 context를 고르는 것, 작업 상태를 복구하는 것이다. 나는 이 셋을 하나로 취급하다 직접 만든 loop에서 두 번 막혔다. Agents API, Managed Agents, Agent SDK, 직접 loop는 뭐가 다른가네 갈래는 기능 목록이 아니라 상태를 어디에 두고 누가 책임지느냐로 갈린다. 이 글은 그 한 축만 비교한다.아래 표는 2026년 10월 공식 문서 기준이다. 시간이 지나면 가장 먼저 낡는 부분이다. OpenAI Agents APIClaude Managed AgentsClaude Agent SDK직접 loop세션 저장 ..

Claude 장애 폴백, 응답 실패여도 파일은 바뀐다

LLM 폴백은 다른 모델을 고르는 문제가 아니라, 첫 번째 모델이 이미 바꿔 놓은 것을 복구하는 문제다. 에이전트 작업에서는 응답이 실패해도 파일 수정은 끝나 있을 수 있다.처음에는 Claude가 죽으면 Codex로 넘기면 된다고 생각했다. 2026년 9월 3일에 장애를 겪고, 응답이 실패해도 파일은 이미 바뀌어 있을 수 있다는 걸 알고 나서 그 생각을 접었다.2026년 10월 2일 기준으로 공식 status 기록은 이렇다. Anthropic은 9월 3일에 여러 모델의 elevated errors(13:26~ 16:23 UTC)를, 9월 29일에 claude.ai·Claude Code·Claude API의 elevated errors(영향 구간 14:00~14:59 UTC, 한국 시각 23:00~23:5..

download 속성이 안 먹힐 때 — 서버 헤더부터 확인

외부 파일 링크에 download만 붙이면 바로 내려받아질 줄 알았다. 브라우저는 파일을 그냥 새 페이지로 열어버렸다. 원인은 HTML 속성이 아니라 파일을 내려주는 서버의 응답이었다.세 줄로 줄이면 이렇다. download는 서버 헤더를 대체하지 못한다. 위치·알림은 권한 거부와 HTTPS 조건부터 설계한다. tel:은 전화 기능이 있는 환경에서만 의미가 있다.현직 백엔드 개발자로 이 네 가지를 직접 써봤다. 글에는 AI 코딩 도구인 Claude가 글을 쓰며 따로 만든 로컬 검증용 데모의 결과도 일부 들어간다. 그 부분은 Claude가 실행한 것이고 내 프로젝트가 아니다. 본문에서 "데모"로 표시한다. HTML5 download 속성은 서버 헤더를 이기지 못한다download 속성은 같은 출처 URL..

html placeholder와 체크박스 미체크 문제

체크를 해제한 체크박스는 서버에 false로 가지 않는다. 요청에서 name 자체가 빠진다. 의 placeholder도 비슷해서, 라벨처럼 보이지만 입력을 시작하면 사라지는 힌트일 뿐이다.둘 다 화면에 보이는 것과 실제로 전달되는 것이 다르다는 같은 문제다. 이 글은 체크박스가 중심이다. 사용자 설정 화면에서 알림 수신을 해제해도 true가 남았던 일과 Spring에서 고친 과정을 적고, placeholder와 datalist는 뒤에서 짧게 다룬다.예전에 이 주소에 올렸던 placeholder 글, datalist 글, $_POST 체크박스 글을 합쳐 다시 썼다. 체크박스를 해제해도 서버 값이 true로 남는 이유해제한 체크박스는 false를 보내지 않고 요청에서 name 자체가 빠지기 때문이다. 서버..

meta viewport 빠지면 모바일에서 생기는 일

meta viewport(viewport meta tag)가 없으면 모바일 브라우저는 페이지를 약 980px 폭의 가상 화면에 그린 뒤 실제 화면에 맞춰 줄여서 보여준다. 확대를 막는 태그가 아니라, CSS가 어느 폭을 기준으로 계산될지 정하는 기본 설정이다. 권장하는 한 줄은 이것이다. 이 한 줄이 빠진 페이지를 폰에서 열었다가 헤맨 적이 있다. 예전 글 네 편(viewport·트위터 카드·breadcrumb·그라바타)을 합쳐 다시 썼고, 오류는 해당 대목에서 바로잡는다. meta viewport가 없으면 모바일은 어떻게 렌더링하나viewport가 없으면 레이아웃 폭이 약 980px로 잡히고 화면에 맞춰 축소되기 때문에 768px 아래용 media query도 적용되지 않는다. MDN도 가상 vie..

추천 시스템 구조, 후보 생성과 랭킹은 왜 나눌까

추천 시스템은 보통 후보 생성으로 대상을 크게 줄이고, 필터링으로 이미 본 항목을 걷어낸 뒤, 랭킹이 남은 후보에 점수를 매기는 순서로 만든다. 나누는 이유는 카탈로그 전체에 무거운 모델을 돌리기 어렵고, 후보 단계에서 놓친 정답은 뒤에서 복구되지 않기 때문이다.직접 해본 것은 MovieLens 평점을 implicit interaction처럼 변환한 영화 추천 POC다. 작은 규모였고 회사 서비스 데이터가 아니다. 대규모 two-stage 서빙은 직접 경험이 아니라서, 그 부분은 공식 자료와 논문으로 정리하고 내 POC와 문장 단위로 구분해 쓴다.2020년에 쓴 글을 2026년 10월에 새로 썼다. Top-N은 추천 알고리즘의 종류가 아니라 사용자별 상위 N개 목록을 내는 문제 설정이고, 지표 정의와 데..

추천 시스템 평가 지표, RMSE만 보면 속는 이유

추천 시스템 평가에서 RMSE는 평점을 얼마나 맞혔는지를 재고, Hit Rate와 NDCG는 좋아할 아이템을 상위 몇 번째에 올렸는지를 잰다. 다른 질문이라서 RMSE가 낮아도 Top-10은 나빠질 수 있다.MovieLens 공개 데이터로 만든 영화 추천 POC에서 직접 겪은 일이다. 회사 서비스 데이터가 아니고 A/B를 돌려 본 경험도 없다. offline 평가까지 해 본 범위만 다룬다.2020년 시리즈의 RMSE·MAE 설명은 MAE가 RMSE보다 높다고 거꾸로 썼고, RMSE와 적중률이 무관하다는 단정도 과했다. 이 글이 정정한다. RMSE와 MAE는 무엇을 재나MAE는 예측과 실제 평점 차이의 절대값을 평균낸 값이고, RMSE는 차이를 제곱해 평균낸 뒤 제곱근을 씌운 값이다. RMSE는 큰 오차..

머신러닝 주가 방향 분류, 백테스트 정확도의 함정

머신러닝 분류 모델의 accuracy가 높다고 백테스트에서 쓸 만한 전략이 나오는 것은 아니다. 방향을 분류 문제로 풀 때는 모델보다 label, 분할, threshold, 비용을 먼저 정해야 한다.BTC/KRW 일봉으로 다음 날 방향을 분류해 본 기록이다. upbit-trader 관련 실험 과정에서 한 작업이다. 투자 권유가 아니고 수익을 보장하지도 않는다. 주가 방향 분류에서 label은 어떻게 정하나label은 "언제부터 며칠 뒤의 무엇을 맞히나"를 먼저 정해야 한다. 피처와 같은 날 끝난 수익률을 label로 쓰면 미래를 맞히는 문제가 아니다.분류는 값을 맞히는 회귀와 달리 상승·비상승 같은 범주를 맞힌다. 내 실험은 다음 1일 방향이었고, 다음 날 수익률이 0보다 크면 1, 아니면 0으로 시작..