우리는 매일 실패하지만, 그 실패가 다음 시도의 성공이 된다 (feat. Claude Code)
Source: Dev.to
위의 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 기술 용어는 그대로 유지됩니다.)
실패 반복
얼마 전, 제가 운영하는 서비스에서 프로덕션 사고가 발생했습니다.
SQS‑트리거된 Lambda 핸들러가 단일 이벤트를 처리하면서 과도한 수의 DynamoDB 트랜잭션을 병렬로 생성했습니다. 결국 Lambda가 타임아웃 한도에 도달했습니다.
이는 Promise‑기반 병렬 처리가 항상 최적은 아니라는 것을 일깨워 주었습니다. I/O‑바운드 워크로드는 경우에 따라 동시성 제어가 필요하거나 순차 실행이 필요할 수도 있습니다. 코드는 논리적으로는 올바르게 보였지만 실제 리소스 제약 하에서는 실패했습니다.
저는 장난 프로젝트에서도 비슷한 경험을 했습니다. 메모리 기반 영속성 레이어는 로컬 환경에서는 완벽히 작동했지만, 클라우드 기반 Docker 환경에 배포한 뒤 일관성 테스트가 실패했습니다. 근본 원인은 컨테이너 인스턴스가 요청마다 바뀔 수 있는 환경에서 상태를 유지하도록 설계된 것이었습니다.
두 사건 모두 단순한 버그 수정 이상의 교훈을 주었습니다:
- 코드는 논리적으로 올바를 수 있지만, 실행 환경의 제약을 무시한다면 시스템은 결국 깨집니다.
- 이러한 교훈은 앞으로의 프로젝트에 명확히 도움이 됩니다.
모든 실패가 성공으로 이어지는가?
우리는 매일 실패합니다. 버그에 부딪히고, 잘못된 가정을 하며, 성능 문제와 씨름합니다.
시니어 엔지니어가 된다는 것은 이러한 경험들을 쌓아 직관으로 바꾸는 것을 의미합니다. 운영 사고, 스케일링 실패, 잘못된 아키텍처 결정 등이 점차 “뭔가 위험하게 느껴진다”는 감각을 형성합니다.
하지만 실제로는 모든 실패가 미래의 성공으로 이어지는 것은 아닙니다. 많은 교훈이 기록되지 않고, 다시 검토되지 않으며, 비슷한 실수가 다른 상황에서 반복됩니다.
문제는 실패 자체가 아니라, 실패가 사라진다는 점입니다.
Dev Sentinel: 실패 감지 및 보존
Dev Sentinel는 이 관찰에서 시작되었습니다. 핵심 아이디어는 간단합니다: 실패 사이클을 감지하고, 기록하며, 유사한 상황이 다시 발생했을 때 이를 표출하는 것입니다.
저는 실패를 다음과 같은 사이클로 정의합니다: 시도 → 좌절 → (포기 | 해결).
이 사이클 내에서 저는 두 가지 개념을 설계했습니다.
1. 경험 캡처
좌절을 감지하고, 시도가 포기로 끝났는지 해결로 끝났는지 추적한 뒤 이를 경험으로 저장합니다. 이는 단순한 로그가 아니라, 상황을 구조화합니다: 문제는 무엇이었는지, 어려움이 어디에서 발생했는지, 그리고 어떻게 마무리됐는지.
2. 능동적 회상
유사한 좌절이 다시 감지되면, 관련된 과거 경험을 표출합니다. 목표는 문제를 자동으로 해결하는 것이 아니라, 개발자에게 “이와 비슷한 상황을 이전에 본 적이 있다”는 것을 상기시키는 것입니다.
이를 구현하기 위해 Dev Sentinel는 Claude Code의 UserPromptSubmit 및 Stop 훅을 활용합니다.
UserPromptSubmit중 – 좌절의 신호(표현, 반복 시도, 컨텍스트 전환 등)를 감지합니다.Stop중 – 실패 사이클이 종료되었는지 판단하고 구조화된 경험을 저장합니다.
만약 Dev Sentinel이 존재했다면?
이전 사건들을 되돌아보면:
- 과도한 병렬성으로 인한 Lambda 타임아웃
- 컨테이너 환경에서의 상태 저장 설계 실패
두 경우 모두 단순한 구현 실수가 아니라, 환경 제약을 과소평가한 공통된 패턴이었습니다.
Dev Sentinel이 존재했다면, 이후 프로젝트에서 다음과 같은 상황에서
- 고동시성 처리 로직을 설계할 때
- 인메모리 캐싱을 가볍게 도입할 때
과거 경험을 떠올리게 하여 답을 제공하기보다는 “이 패턴이 이전에 실패한 사례를 본 적이 있나요?” 라는 질문을 던졌을 것입니다.
조직 런북과 개인 기억 사이
많은 조직이 런북, SOP, 위키, 그리고 지식 베이스를 통해 실패를 줄이고 있습니다. 이는 매우 효과적이지만, 조직의 지식이 항상 개인의 상황과 완벽히 일치하는 것은 아닙니다.
Dev Sentinel은 반대 방향을 취합니다:
- 개인의 실패 경험을 먼저 포착한다
- 이를 시간이 지남에 따라 축적한다
- 관련될 때 개인에게 다시 제공한다
이러한 기대는 축적된 개인 경험이 더 나은 설계 판단을 이끌어내며, 그 판단이 궁극적으로 프로젝트와 조직에 영향을 미친다는 것입니다.
Closing Thoughts
우리는 매일 실패합니다. 하지만 실패가 자동으로 자산이 되는 것은 아닙니다. 기억되지 않는 실패는 반복됩니다.
Dev Sentinel은 거대한 AI 시스템이 아닙니다. 이는 실패가 조용히 사라지는 것을 방지하는 작은 메커니즘입니다. 오늘 밤은 오늘의 교훈이 무엇이었는지 되돌아볼 좋은 시기인 것 같습니다.
Git repo: