회복탄력성, 개발자로서 지키려는 마음가짐

개발을 오래 하다 보면, ‘이번엔 완벽하게 하자’는 마음이 점점 ‘다시 일어날 수 있게 하자’로 바뀌는 순간이 온다.

처음에는 잘하고 싶었다. 레거시를 빨리 이해하고, 서비스를 안정적으로 만들고, 프로젝트 오너가 되어 구조를 예쁘게 잡고 싶었다.
그 마음은 여전히 있다. 다만 지금은 한 번에 잘하는 것보다 틀려도 회복할 수 있는 것을 더 중요하게 본다.

회복탄력성이라는 말을 들으면, 긍정적으로만 버티라는 뜻으로 오해되기 쉽다.
나에게는 그렇지 않다. 솔직히 말하면, 실패를 무시하지 않되, 실패에 머물지 않기에 가깝다.

오늘 이 글을 쓰게 된 것도, 최근에 ‘또 버텨야지’라는 말을 스스로에게 많이 했기 때문이다.
버티는 것과 회복하는 것은 다르다는 걸, 실무가 가르쳐 줬다.

왜 회복이 먼저였는가 (이유)

결제 — 돈이 걸린 순간, 집중력만으로는 부족했다

결제/정산을 붙이면서 처음으로 ‘회복’을 진지하게 생각했다. 사원카드, QR 쿠폰, 바우처, 가맹점 본인인증… 흐름을 하나씩 늘릴 때마다 기분이 비슷했다. 배포 전엔 괜찮을 거라 믿었고, 배포 후엔 로그를 더 자주 봤다.

한번은 재시도 로직만 넣고 멱등성이 해결됐다고 착각했던 적이 있다. 테스트는 통과했고, QA도 통과했다. 그런데 운영에서 타임아웃과 재시도가 겹치며 같은 건이 두 번 처리된 것처럼 보이는 로그가 남았다. 당시엔 큰 사고로 번지진 않았지만, 그날 새벽 나는 ‘다시는 안 틀리자’는 다짐만으로는 한계가 있다는 걸 몸으로 알았다. 밤샘 집중력은 언젠가 뚫린다. 피곤한 새벽의 나와, 아직 결제를 모르는 신규 입사자는 같은 실수를 반복할 수 있다.

그래서 체크리스트를 만들기 시작했다. 나를 못 믿어서가 아니라, 빠뜨려도 시스템과 글이 잡아주는 기준이 필요했다. 결제에서 한 번의 실수는 기능 버그가 아니라 신뢰의 문제였다. 회복이란 ‘기분을 다시 좋게 하기’가 아니라, ‘같은 유형의 사고를 더 짧은 시간에 막기’에 가까웠다.

레거시 — 고쳤는데 더 망가진 날

레거시 전산을 맡을 때는 반대로, 회복 자체가 불가능에 가까운 순간을 겪었다. PG·매출 전산을 받았을 때 솔직히 빨리 성과를 내고 싶었다. 분석 메모 없이 매입 마감 화면의 날짜 비교 로직을 ‘더 깔끔하게’ 바꿨다. 코드만 보면 중복이었고, 한쪽을 지우는 게 맞아 보였다.

그런데 그 화면은 c:forEach로 서버가 박아준 값과 jQuery가 다시 계산한 값을 둘 다 쓰고 있었다. 특정 카드사 건만 마감 금액이 어긋났다. 롤백은 했지만, 그날의 신뢰 회복은 코드 revert만으로 끝나지 않았다. 운영자와 같이 숫자를 다시 맞추고, ‘왜 그랬는지’를 설명해야 했다.

그때 느낀 건 분명했다. 읽히지 않는 코드는 회복 불가에 가깝다. 되돌릴 파일은 있어도, 되돌릴 신뢰는 한 번에 안 돌아온다. 그 이후로는 ‘왜 이 코드가 이렇게 생겼는지’를 한 줄이라도 못 적으면 손대지 않기로 했다. 분석을 먼저 기록으로 고정하는 습관은 성격이 아니라, 그날의 체감에서 나왔다.

SSO·배포 — 멋진 그림보다 되돌아오는 길

SSO 롤아웃을 맡았을 때 회의실에서 가장 오래 붙잡고 있던 질문이 있었다. ‘지금 인증을 먼저 통합할 것인가, 각 서비스 안정화를 먼저 할 것인가.’ 찬성 쪽 말도 맞았다. 통일되면 이후가 편해진다. 반대 쪽도 맞았다. 한 번에 건드리면 로그인 실패가 곧 장애다.

결제가 물린 메인 스키마에 완벽한 일괄 전환은 무리라고 봤다. 핵심 서비스부터 단계적으로 묶고, 실패 시 롤백 루트를 먼저 만들자고 정했다. SSO를 한 번에 다 깔았을 때의 그림은 회의 자료상 더 멋졌다. 하지만 그 그림은 실패했을 때의 비용을 숨기고 있었다.

나중에 GitHub Actions와 Jenkins로 배포 자동화를 만들 때도 똑같이 갈렸다. 새 버전을 빨리 내고 싶은 마음과, 문제 시 즉시 되돌려야 한다는 요구. blue & green으로 새 버전을 띄워 두고 트래픽만 전환하기로 했을 때, 안도감이 컸다. 실험이 가능해진 이유는 용기가 아니라 후퇴 경로가 있었기 때문이다.

팀장 — 내가 멈추면 팀도 멈춘다

팀장이 되고 나서 회복의 의미가 또 바뀌었다. 팀원일 때는 내가 지치면 내 일만 늦어졌다. 팀장이 되어 보니, 내가 무너지면 질문이 나에게만 몰리고 결정이 밀린다는 게 보였다. 주간 회의에서 안건이 길어지고, 장애 때 내 전화가 먼저 울릴 때 — ‘혼자 버티기’는 팀 전체의 회복 속도를 늦출 수 있다고 느꼈다.

그래서 기준이 옮겨졌다. 나 한 명이 강해지기보다, 팀이 다시 일어날 구조를 만드는 쪽으로.

처음엔 회복탄력성이 성격 이야기처럼 느껴졌다.
실무를 거치며 보니, 설계·기록·배포 방식·팀의 루틴의 문제에 가까웠다.

지금 지키려는 마음가짐 (당시 결론)

교과서 한 장으로 정리하긴 어렵지만, 요즘 나에게 맞는 문장은 경험에서 하나씩 붙었다.

1. 완벽보다 되돌릴 수 있음

결제 배포 전에 ‘이번엔 괜찮겠지’라고 말하던 시절이 있었다. 지금은 먼저 묻는다. 되돌릴 수 있는가. 작게 나누고, 롤백·멱등·체크리스트로 ‘다시 올 수 있는 길’을 먼저 깐다. 한 번에 맞히려다 운영을 거는 선택을 줄이려 한다.

2. 실패는 숨기지 않고, 반복하지 않는다

장애 보고를 미루고 싶은 순간이 있다. ‘아직 정리 안 됐는데’라는 핑계로. 하지만 숨기면 회복이 늦어진다. 보고·회고·문서화는 자책이 아니라 다음 회복 시간을 줄이는 투자다. 같은 실수를 두 번 하지 않으려면, 첫 번째 실패를 팀이 공유할 수 있어야 한다.

3. 기록이 있으면 다시 시작할 수 있다

PR 한 줄, 분석 메모, 런북, 개발자센터 글. 기억에만 남은 판단은 회복 비용이 크다. 6개월 뒤의 나는 당시의 맥락을 기억하지 못한다. 레거시 화면을 다시 열었을 때 ‘왜 이렇게 짰지’를 모르면, 또 같은 자리에서 같은 실수를 할 수 있다.

4. 사람은 지치고, 구조는 지치지 않게

리뷰에서 매번 같은 포맷 지적을 반복하다 지쳤던 적이 있다. 그래서 Prettier/ESLint를 CI에 걸었다. 사람의 의지가 아니라 기본값으로 옮기려는 이유도 비슷하다. 배치 멱등성도 마찬가지다. 새벽에 운영자가 ‘재시도 = 안전’이라고 믿지 않게, 구조가 먼저 말하게 하려 한다.

5. 성장 욕구와 안정성은 양립한다

React를 JSP 위에 iframe으로 붙였을 때(ES5→ES6 이전), ‘빨리 갈아엎자’는 마음과 ‘운영 전산을 멈출 수 없다’는 현실이 부딪혔다. 덮어쓰기 대신 확장을 택한 건 회의실에서 이긴 논리가 아니라, 운영 중인 화면을 끊지 않고도 다음 단계로 가고 싶었기 때문이다. 성장 욕구를 버린 게 아니라, 회복 가능한 속도로 옮긴 것이다.

• 이유: 개발자로서 오래 가려면, 한 번의 승리보다 여러 번의 회복이 더 많이 필요하다고 느꼈다.
• 당시 결론: 회복탄력성은 ‘긍정적으로만 생각하기’가 아니라, ‘다시 일할 수 있는 조건을 미리 만들어 두기’로 정의했다.

비슷한 경험 — 팀·도구·배포

애자일 — ‘끝난 척’하지 않아도 되는 주

애자일을 팀에 맞게 쓸 때 스프린트가 실패처럼 느껴지는 주가 있었다. 분기 목표는 그대로인데, 이번 주에 닫을 건 못 닫는다. 예전이었다면 ‘이번 달 끝나면 알겠지’며 넘겼을 것이다. 그때 도움이 된 건 위로가 아니라 짧은 주기와 기록이었다.

이번 주에 못 끝낸 걸 숨기지 않고 다음 주기로 넘기니, 팀이 ‘끝난 척’하지 않아도 됐다. 회복이란 기분 전환만이 아니라, 다음 주에 같은 자리에서 다시 시작할 수 있는 상태를 만드는 일이었다.

도구 교체 — 습관이 남으면 회복이 빠르다

도구를 남들 따라 들였다가 바꿀 때 Jira·Confluence·Slack에서 Discord·Notion으로 옮기며 느낀 건, 도구가 바뀌어도 이슈 번호와 문서 링크로 질문이 바뀌는 순간 회복이 빨라진다는 점이었다. ‘그거 어디 있어요?‘가 줄면, 팀의 에너지가 다시 설계로 돌아온다.

AI 리뷰 — 빠름과 책임 사이

AI 코드 리뷰를 들일 때도 비슷했다. 제안이 그럴듯해서, ‘AI가 봤으니 괜찮겠지’ 분위기가 생기는 게 무서웠다. 빠르다. 그런데 책임은 누구에게 남는가.

나는 도입을 막지 않되, 신뢰 범위를 선으로 그었다. AI는 참고 의견, 결제·인증·배치는 사람 필수 리뷰. 도구를 믿는 게 아니라, 실패했을 때 사람이 다시 잡을 수 있는 자리를 남겼다. 쓸까 말까가 아니라 어디까지 맡길까 — 이 질문이 회복과도 연결돼 있다.

회복이 빨라졌다고 느낀 지점

• 장애 후 ‘왜 그랬는지’를 같은 패턴으로 설명할 수 있게 됐다. 말이 통하면, 다음 대응이 빨라진다. 예전엔 로그만 던지고 끝났다.
• 배포·인증·결제 변경에 되돌리기 경로가 붙으면서, 실험에 대한 두려움이 줄었다. 실패해도 서비스가 끊기지 않는다는 건, 회의실에서가 아니라 실제 전환 버튼 앞에서 느껴지는 안도다.
• 레거시를 손대기 전 분석을 고정하는 습관이 생기면서, ‘고쳤는데 더 망가졌다’는 최악의 회복이 줄었다.
• 팀 회고에서 나온 개선이 문서·체크리스트로 남기 시작했다. 같은 실수를 개인 기억에만 의존하지 않게 됐다.
• 팀원이 먼저 ‘이렇게 하면 될 것 같다’고 말하는 순간이 늘었다. 내가 다시 일어나는 것보다, 팀이 스스로 회복하는 것이 더 큰 변화였다.

아직 부족한 것 (개선점)

• 롤백 경로는 있지만, 정기적으로 실제로 되돌려 보는 연습이 부족하다. 문서에 ‘될 것이다’라고 적어 둔 것과, 손이 기억하는 것은 다르다.
• 회고는 하지만, 회복 시간(복구까지 걸린 시간) 을 숫자로 남기지 못한다. 개선이 체감인지 데이터인지 구분이 어렵다.
• 팀장으로서 모든 위기가 나에게 모이는 날이 있다. 회복 구조를 팀에 더 넓게 펴야 한다.
• 번아웃 직전의 신호를 일찍 알아채는 기준이 아직 약하다. 구조만 튼튼해도 사람이 지치면 회복은 느려진다. 최근에도 ‘조금만 더’가 길어지는 날이 있다.

앞으로 나가야 할 방향

1. 분기마다 한 번은 결제/정산·배포·인증 흐름에 장애 대응 리허설을 넣어, 회복을 믿음이 아니라 절차로 만든다.
2. 장애·배포 후 복구 시간과 원인을 짧게라도 기록해, 같은 유형의 회복이 빨라지는지 추적한다.
3. 회고 결과를 개발자센터·런북과 연결해, 다음 사람이 같은 구멍에 같은 시간을 쓰지 않게 한다.
4. 팀장의 역할을 ‘위기 때 맨 앞에 서기’에서 ‘위기 후 다시 일할 수 있는 환경 만들기’로 더 옮긴다.
5. 성장 욕구는 유지하되, 되돌릴 수 있는 실험 주기 안에서만 새 것을 시도한다.

회복탄력성은 타고나는 성격만의 이야기가 아니었다.
롤백, 기록, 짧은 주기, 체크리스트, 팀의 공유 — 익숙한 실무 도구들이 쌓이면서, 나는 실패를 덜 두려워하게 됐다.

그리고 그건 ‘아무 일 없는 것처럼 넘기자’는 뜻이 아니다.
다시 일어서서, 같은 실수를 반복하지 않는 것 — 개발자로서 지금도 고치고 있는 마음가짐이 그쪽에 가깝다.

오늘 회복탄력성을 떠올린 이유도 비슷하다.
완벽한 하루를 기대하기보다, 내일도 같은 팀과 같은 기준으로 다시 시작할 수 있는가를 더 자주 묻게 됐다. 결제 로그를 다시 열고, 레거시 분석 메모를 한 줄 보태고, 롤백 절차가 아직 ‘믿음’인지 ‘검증’인지 짚어 보는 일 — 그게 오늘 내가 할 수 있는 회복에 가까운 일이다.