전체 글 (114) 썸네일형 리스트형 [CS/백엔드] 같은 작업을 두 번 만들지 마라: 상태 머신(State Machine)으로 비동기 작업 생명주기 관리하기 🚨 발단: 작업은 줄 세웠는데, 지금 어디쯤 진행 중인지 모른다면?앞서 메시지 큐를 이용해 사용자의 요청을 안전하게 대기열에 넣어 두었다. 그런데 여기서 끝이 아니다. 사용자가 답변 생성 버튼을 연타하거나, 네트워크가 불안정해 재시도(Retry) 요청을 날릴 때 시스템이 "이 작업이 지금 정확히 어디쯤 진행되고 있는지" 상태를 알지 못하면 어떤 일이 벌어질까? 이미 생성 중이거나 완료된 작업인데도 큐에서 또 꺼내어 똑같은 답변을 두 번 만들어 버리거나(중복 실행), 에러 난 작업을 방치하는 대참사가 벌어진다.🔑 해결책: 상태 머신 (State Machine)이 문제를 해결하는 핵심 패턴이 바로 상태 머신(State Machine)이다. 작업이 거쳐 가는 단계를 명확한 '상태(State)'로 정의하고,.. [CS/백엔드] 메시지 큐라고 다 같은 큐가 아니다: 단순 인메모리부터 Reliable Queue까지의 성격 비교 🚨 발단: "큐에 넣었으니 안전하겠지?"라는 착각앞서 비동기 작업을 처리하기 위해 메시지 큐를 도입해야 한다고 정리했다. 그런데 막상 큐를 도입하려고 보니 의문이 생겼다. "시중에 수많은 메시지 큐가 있는데, 아무거나 갖다 쓰면 서버가 죽었을 때 내 작업도 안전하게 지켜줄까?" 결론부터 말하면 아니다. 메시지 큐라고 해서 전부 서버가 꺼져도 데이터를 안전하게 보존해 주는 것은 아니다. 데이터의 보관 방식과 목적에 따라 큐의 성격은 완전히 나뉜다.🔑 메시지 큐의 3가지 유형과 성격 비교1. 인메모리 기반 큐 (In-Memory Queue)특징: 데이터를 오직 메모리(RAM) 상에서만 관리한다.장단점: 디스크 I/O가 발생하지 않아 속도가 엄청나게 빠르다. 하지만 서버가 갑자기 다운되거나 재시작되면 메모.. [CS/백엔드] 서버가 죽어도 일은 사라지지 않는다: 메시지 큐(Reliable Queue)로 비동기 안전하게 처리하기 🚨 발단: 서버가 재시작되면 사용자의 무거운 요청은 어디로 갈까?실시간으로 처리하기 벅찬 무거운 작업(예: LLM 답변 생성, 대용량 파일 업로드 등)을 처리할 때, 서버가 직접 요청을 받아 곧바로 처리하도록 코드를 짜면 큰일 난다. 만약 작업 중에 트래픽이 한꺼번에 몰리거나, 배포 등으로 인해 서버가 갑자기 재시작(Crash)되기라도 하면 사용자의 요청 데이터는 메모리에서 증발해 버린다. 사용자는 로딩만 되다가 에러를 마주하고, 서비스의 신뢰도는 바닥으로 떨어진다.이 문제를 해결하기 위해 도입해야 하는 개념이 바로 메시지 큐(Message Queue, 그중에서도 신뢰성을 보장하는 Reliable Queue)이다.🔑 메시지 큐(Reliable Queue)란?사용자의 요청이 들어오면 서버가 직접 처리하.. [CS/백엔드] 분산 락, 잠그는 것보다 '안전하게 푸는 것'이 더 어렵다? (feat. Redis Lua 스크립트) 🚨 발단: 분산 락, 걸었다고 끝이 아니었다Redis로 분산 락을 구현하면서 SETNX(값이 없을 때만 세팅)로 락을 거는 것까진 쉽게 이해했다. "이제 동시성 문제는 끝났네!"라고 생각했는데, 진짜 무서운 함정은 락을 '걸 때'가 아니라 '풀 때(Unlock)' 숨어 있었다.영원히 안 풀리는 데드락(Deadlock)을 막기 위해 락에 TTL(만료 시간, 예: 3초)을 설정해 두는데, 바로 여기서 끔찍한 엣지 케이스가 발생한다. A서버가 락 획득 (TTL 3초 설정)A서버의 DB 로직이 지연되어 4초가 걸렸다. 그 사이 락은 수명이 다해 자동으로 풀려버렸다.B서버가 빈자리인 줄 알고 락을 획득해 작업 시작.뒤늦게 작업을 끝낸 A서버가 무턱대고 DEL lock_key를 날려 락을 지워버린다.대참사: B서.. [CS/백엔드] 서버가 여러 대일 때 발생하는 끔찍한 일들: 분산 락(Distributed Lock) 개념 정리 🚨 발단: 서버 1대일 땐 멀쩡했는데 왜 이럴까?트래픽이 적어 단일 서버(서버 1대)로 운영할 때는 문제가 없었다. 결제 버튼을 '따닥!' 하고 두 번 눌러도, 코드 레벨에서 synchronized나 Mutex로 스레드 접근을 순차적으로 제어하면 중복 결제를 막을 수 있었기 때문이다.하지만 서비스가 커져서 서버를 3대(다중 서버 환경)로 스케일 아웃(Scale-out)한다면 상황이 완전히 달라진다. 사용자가 결제 버튼을 두 번 누르면 첫 번째 요청은 A서버로, 두 번째 요청은 B서버로 날아갈 수 있다. A서버와 B서버는 서로 독립된 메모리를 가지므로 다른 서버가 무슨 작업을 하는지 알 수 없다. 결국 두 서버가 동시에 DB에 접근하게 되고, '돈이 두 번 빠져나가는(중복 결제)' 대형 사고가 터진다.이.. 하네스, 루프 엔지니어링 참고 자료 기록 - OpenAI — Harness engineering (2026-02-11) (https://openai.com/index/harness-engineering/)- InfoQ — OpenAI harness engineering with Codex (https://www.infoq.com/news/2026/02/openai-harness-engineering-codex)- Marmelab — The State Of AI Harness Engineering 2026 (https://marmelab.com/blog/2026/09/24/the-state-of-ai-harness-engineering-2026.html)- Faros — Harness Engineering: A Guide to AI Coding .. 루프 엔지니어링 루프 엔지니어링 (2026년 7월~)- 정의: 사람이 매번 프롬프트를 넣는 대신, 목표 → 행동 → 관찰(CI 테스트 등) → 조정을 반복하는 루프를 설계하는 일이에요.- 확산: Claude Code를 만든 Boris Cherny와 OpenClaw를 만든 Peter Steinberger의 언급이 퍼지면서 주목받았어요(ADTmag, 2026년 7월 1일). Andrew Ng은 루프를 세 겹으로 설명해요. - 에이전트 코딩 루프 - 개발자 피드백 루프 - 사용자 반응 같은 외부 피드백 루프- 구성 요소(IBM, 2026년 7월 17일): - 스케줄과 자동화 - 이벤트 훅 - 워크트리 - 스킬 파일 - 검증 서브에이전트(만드는 쪽과 확인하는 쪽 분리) - 루프를 이어 주는 기억 장치("spin.. 하네스 엔지니어링 하네스 엔지니어링 (2026년 2월~)정의: Agent = Model + Harness. 모델 바깥에서 규칙, 도구, 훅, 권한, 센서, 평가로 에이전트가 안정적으로 일하게 만드는 일이에요.기원:- 2026년 2월 초 Mitchell Hashimoto가 이름을 붙였어요. 원칙은 "에이전트가 실수하면, 그 실수를 다시 못 하게 하네스를 고친다"예요.- 2026년 2월 11일 OpenAI의 Ryan Lopopolo가 공식 글로 정의했어요.구조: Thoughtworks는 하네스를 두 가지로 나눠요.- feedforward: 생성 전에 맥락을 주는 컨벤션, 스킬, 가드레일- feedback(센서): 생성 결과를 확인하는 장치. 다시 둘로 나뉘어요. - 계산형: 린터, 테스트처럼 결과가 결정적인 것 - 추론형.. 이전 1 2 3 4 ··· 15 다음
