누구를 탓할지보다 중요한 건 세 가지다.
감정을 덜고, 재발을 막고, 회복을 보장하는 것.

긴급 대응은 헌신이나 책임감의 문제가 아닙니다.

지속 가능성의 문제입니다.

새벽 호출, 주말 호출 그 자체보다

개발자를 더 소진시키는 것은

긴급 상황 이전과 이후의 태도와 구조입니다.

그리고 긴급 대응에 감정 압박이 더해지는 순간,

그 사람은 다음 호출을 버텨내기 점점 힘들어집니다.

긴급 대응은

헌신이나 책임감의 문제가 아닙니다.

그 상황을 다음에도 다시 감당할 수 있는가의 문제입니다.

존중

긴급 대응에서 가장 먼저 지켜야할 것은

'얼마나 빨리 고치느냐'가 아니라

누가, 어떤 상태로 그 자리에 서 있었는가 입니다.

국경을 지키고 있는 군인,

치안을 지키고 있는 경찰,

안전을 지키고 있는 소방수처럼

긴급 대응 이전에

누가, 어떤 상태로 그 자리에 서 있었는지에 따라

긴급 상황이 발생했을 때,

대응이 크게 갈릴 것입니다.

그리고 긴급 상황에서

휘말리는 감정적인 여파를 어떻게 다루느냐에 따라

다음 긴급 상황에 있어

소명감을 가지고 임하는 개발자가 될지

상황을 회피하고 싶은 개발자가 될지가

판가름나게 됩니다.

존중에 대한 프로세스

단지 긴급 대응을

사람의 책임감으로 버티기 시작하는 순간,

이미 그 조직은 위험합니다.

긴급 대응은 영웅을 만드는 시간이 아닙니다.

한 사람이 반복해서 그 자리에 서게 되는 구조는
단기적으로는 안정처럼 보이지만,

시간이 지날수록
조직이 대응 방식을 점검할 기회를 잃게 만듭니다.

존중은 태도의 문제라고 생각하기 쉽습니다.

하지만 운영에서는 결국 프로세스의 문제로 귀결됩니다.

아무리 존중하는 말을 건네더라도

그 다음 호출이 똑같은 방식으로 반복된다면,

그 존중은 오래 가지 못합니다.

그래서 긴급 대응에서의 존중은

말이 아니라 프로세스로 확인되어야 합니다.

그래서 긴급 대응 이후에

조직이 해야 할 프로세스는 명확합니다.

• 누군가를 탓하지 않는 것
• 감정을 덜어내는 것
• 다음 상황을 대비하는 것

이 세가지가 없으면

긴급 대응 반복될수록 개발자를 갉아먹게 됩니다.

그렇게 다음 상황을 대비할 때에는

• On-Call이 특정 인원에게 고착되지는 않았는지
• 대체 휴무나 회복 시간이 보장되었는지
• 같은 상황이 다시 발생할 여지가 있는지

를 반드시 확인해야 합니다.

당연하게도 확인한 것들을 바로 적용할 수는 없을 것입니다.

다만 확인하는 것 만으로도

고칠 수 없는 상태가

고칠 수 있는 상태로 바뀌게 됩니다.

구성원들이 고칠 수 있는 방향성을 생각하게 됩니다.

맺는말

긴급 대응을 견디는 조직은 많지만,

긴급 대응을 지속 가능하게 다루는 조직은 많지 않습니다.

중요한 것은 다음 호출이 올 때 같은 사람이 같은 방식으로 다시 서게 만드는 것이 아니라,

그 상황을 조직 전체가 어떻게 감당할 수 있을지에 대한 기준을 남기는 일입니다.

이전글

"누구의 잘못인가?"
or
"어떻게 수습할 것인가?"

• 실력 부족으로 생기는 버그
• 실력이 있어도 생기는 버그

실무에서는 둘을 구분하지 않습니다.

왜냐하면 결과는 동일하게 장애로 연결되기 때문입니다.

버그를 책임 소재로 보는 조직

이러한 접근은 다음의 질문으로 시작합니다.

• "왜 이런 버그가 나왔죠?"
• "누가 이 코드 짰어요?"
• "테스트 안해보셨어요?"

이러한 방식의 질문은

문제해결보다는 책임 규명이 먼저일 때 튀어나옵니다.

그리고 이러한 질문이 반복되면

개발자는 문제 해결 모드가 아니라

상황 설명을 최소화하는 모드로 전환됩니다.

이 전환은 감정의 문제가 아니라,

정보가 흐르는 방식을 바꿉니다.

무엇이 문제였는지보다

어디까지 말해도 되는지가 먼저 계산되기 시작합니다.

개발자 개인의 책임으로 돌리는 것은

단기적으로 감정이 해소될지 몰라도

구조적 안정성을 확보할 수는 없습니다.

버그를 시스템 이벤트로 보는 조직

버그를 시스템 이벤트로 보는 접근법은

다음의 질문으로 이어집니다.

• "사용자 영향 범위는 어떻게 돼요?"
• "롤백이 빠를까요, 핫픽스가 빠를까요?"
• "재발 조건에는 뭐가 더 있을까요?"

이 질문들은

수습 > 원인 > 구조 개선 순서를 만듭니다.

그리고 이 순서가 유지되는 조직에서는
버그 하나가 조직의 판단 기준을 갱신하는 계기로 작동합니다.

해당 구조에서는

"다음엔 더 빨리 잡자"라는 학습이 일어납니다.

"이거 왜 이렇게 했어요?"

"지금 빠르게 수습하려면 어떻게 해야하죠?"

이 한 문장의 차이가

• 팀 신뢰
• 장애 대응 속도
• 개발자의 성장 방향

을 전부 바꿉니다.

운영에서 가장 중요한 관점은

조직이 무엇을 학습하느냐 입니다.

맺는말

이 글은 개발자를 위로하기 위한 글이 아닙니다.

조직이 손해를 보지 않게 하기 위해 작성한 글입니다.

버그를 잘못 다루는 조직은 결국

• 개발자를 잃고
• 품질을 잃고
• 고객을 잃습니다.

버그는 피할 수 없습니다.

다만 그 버그가
한 번의 사고로 끝나는지,
아니면 조직의 판단을 갱신하는 계기가 되는지는
전적으로 조직이 버그를 다루는 방식에 달려 있습니다.

버그를 사람의 문제로 처리하는 조직은
같은 문제를 다른 형태로 반복하게 되고,

버그를 흐름의 문제로 다루는 조직은
점점 같은 문제를 더 빨리, 더 작게 만납니다.

다음 편에서는

개발자를 대하는 태도 - 긴급 대응편에서

더 극단적인 상황을 다뤄볼 수 있도록 하겠습니다.

안정적인 조직은
문제 앞에서 프로세스를 먼저 만든다.
사람부터 찾지 않는다.

초기 조직에서 개발 프로세스를 먼저 갖추는 경우는 거의 없습니다.

사람이 우선시되고, 그중에서도 가장 잘하는 개발자에게 의존하는 구조로 시작하는 것이 대부분입니다.

초기에는 선택지가 없기 때문에 이건 잘못이 아닙니다.

문제를 정의할 사람도, 설계할 사람도, 구현할 사람도 결국 한두명뿐이기 때문입니다.

문제는 이 다음입니다.

조직이 성장하면서도 여전히 "그 사람이라서 되는 개발"에 머무를 때,

조직은 개발자를 믿는 구조에서 벗어나지 못하기 때문입니다.

반대로 안정적인 조직은 능력이 뛰어난 개발자를 중심으로 프로세스를 끌어내는 선택합니다.

사람의 판단과 경험을 문서와 흐름으로 옮기고, 그 사람이 없어도 돌아갈 수 있는 구조를 만듭니다.

이 글은 "특정 개발자를 믿는 조직"과 "프로세스를 믿는 조직"이

어디에서 갈라지기 시작하는지에 대한 이야기입니다.

개발자 의존 구조가 강화되는 순간들

"이 문제는 누구님이 해결해주실거에요."

신규 조직이 처음 문제를 맞닥뜨리는 순간은 대부분 비슷합니다.

예상하지 못한 이슈가 발생하고, 일정은 촉박하고, 정리된 기준이 없습니다.

이때 조직은 가장 쉬운 선택을 합니다.

능력 있는 개발자에게 문제를 맡깁니다.

그 개발자는 경험과 감각으로 문제를 잘 처리해냅니다.

서비스는 멈추지 않고, 일정을 가까스로 지켜냈습니다.

조직 입장에서는 성공적인 대응처럼 보입니다.

하지만 이 지점에서 중요한 단계가 하나 빠집니다.

[회고가 없습니다.]

왜 문제가 발생했는지, 어떤 판단으로 해결했는지,

다음에는 어떻게 대응해야 하는지에 대한 정리가 이루어지지 않습니다.

시간이 지나 또 다른 문제가 발생합니다.

이번에도 기준은 없고, 초반 정리도 생략됩니다.

조직은 다시 같은 선택을 합니다.

"이 문제는 누구님이 보시면 금방 해결할 거에요."

문제는 또 해결됩니다.

그리고 또 기록은 남지 않습니다.

이 과정을 몇 번 반복하면 구조는 고정됩니다.

문제가 생기면 정리부터 하지 않고, 사람부터 찾는 조직이 됩니다.

이때부터 개발자는 문제 해결자가 아니라 조직의 완충제가 됩니다.

하지만 반복될 수록 조직은 '문제를 해결하는 방식'을 잃고,

'특정 사람을 호출하는 방식'만 남기게 됩니다.

그 구조가 낳는 실제 비용

이 구조가 유지될수록 조직은 눈에 보이지 않는 비용을 지불하게 됩니다.

대부분은 당장 드러나지 않고, 시간이 지나서 한꺼번에 터집니다.

1. 개발자 개인의 판단 구조에 회사가 존속됨

프로세스가 없는 조직에서는

의사결정의 기준이 문서나 합의가 아니라 개인의 머릿속에 존재합니다.

무엇을 우선할지, 어디까지를 리스크로 볼지,
언제 타협할지에 대한 판단이 특정 개발자의 경험과 감각에 의존하게 됩니다.

이 시점부터 회사는 시스템 위에 서 있는 것이 아니라,

특정 개인의 컨디션과 기억력이라는 가장 변동성이 큰 리스크 위에 서 있게 됩니다.

이는 단순한 위험이 아니라,

매 의사결정마다 '확인 비용'과 '대기 비용'을 지불하는 구조적 비효율로 굳어집니다.

2. 개발팀(혹은 개발자)와 나머지 조직 간의 마찰이 시작됨

문제가 반복되면 조직 내부에서는 자연스럽게 역할 인식이 갈라집니다.

• 개발자는 "설명할 시간에 내가 하는 것이 빠르다."고 느끼고,
• 다른 구성원들은 "왜 항상 개발자만 알고 있는지"를 의문으로 갖습니다.

기준이 공유되지 않기에 의사소통은 점점 감정 소모로 변하고,

마찰은 개인 간의 문제가 아니라 구조적 갈등으로 누적됩니다.

3. 개발자 번아웃, 그리고 마찰의 가속화

문제를 해결할수록 일이 줄어들지 않는 구조에서는

유능한 개발자가 가장 먼저 지칩니다.

문제해결 > 다음 문제 투입 > 기준 정리 생략

이 루프가 반복되면 개발자는 점점 완충재 역할을 수행하게 됩니다.

이때부터 번아웃은 개인의 체력 문제가 아니라

구조가 만든 결과가 됩니다.

4. 개발자 이탈 이후, 조직의 급격한 붕괴

결정적인 순간은 그 개발자가 떠난 이후입니다.

문서가 없고, 판단 기준이 남아 있지 않으며,

누구도 왜 그렇게 설계되었는지 설명하지 못합니다.

조직은 이때서야 그동안 유지되고 있던 것이

프로세스가 아니라 사람이었음을 인식하게 됩니다.

그리고 대부분의 경우, 이 인식은 너무 늦게 찾아옵니다.

언제, 어떻게 전환해야 하는가?

많은 조직은 이렇게 생각합니다.

프로젝트 마일스톤마다 기록을 어느 정도는 남기고,

그 기록을 바탕으로 사람에게 의존하던 구조를

조금씩 프로세스로 전환해 가면 된다고 말입니다.

지금이라도 늦지 않았고,

필요하다면 대표가 직접 PM 역할을 맡아서라도

그렇게 해야 한다고 판단합니다.

이 생각 자체가 틀렸다고 보기는 어렵습니다.

실제로 많은 조직이 이 방식을 선택합니다.

다만 문제는,

이 판단이 현실에서는 거의 실행되지 않는다는 점입니다.

기록은 늘 '시간이 나면' 남겨야 할 일이 되고,

대표의 PM 역할은 기존 의사결정에 또 하나의 부담으로 추가됩니다.

결국 구조를 바꾸기 위한 시도는 항상 다음 일정 뒤로 밀립니다.

이것은 구성원들의 의지가 부족해서가 아닙니다.

이미 '사람 의존적 방식'이 가장 저렴하게 동작하도록

조직의 모든 근육이 적응해버렸기 때문입니다.

내부 구성원끼리는 서로의 합의를 깨고 프로세스를 강제하는 데 드는 '설득 비용'이,

당장 급한 불을 끄는 '수행 비용'보다 훨씬 높게 느껴질 수밖에 없습니다.

그래서 내부에서의 개혁은 대부분 "좋은 이야기지만, 지금은 아닌 이야기"로 끝납니다.

사람이 해결하고,

문제는 넘어가고,

기록은 남지 않습니다.

맺는말

혹자는 말합니다.

"기술이 세상을 지배한다."고요.

하지만 실제로 조직을 움직이는 것은

기술 그 자체가 아니라,

그 기술을 어디까지, 어떻게 사용할 것인지에 대한 프로세스 입니다.

프로세스 없이 사용되는 기술은

속도를 높이기도 하지만

동시에 리스크를 높이는 선택이 되기도 합니다.

기술과 프로세스 사이의 긴장은 불편하지만,

그 불편함을 피하는 대가는 '속도'가 아니라 '부채'로 돌아옵니다.

지금 조직이 겪고 있는 문제가 단순히 일이 많아서 발생하는 '물리적 과부하'인지,

아니면 누구에게 물어봐야 할지 몰라 발생하는 '구조적 병목'인지 구분해 볼 시점입니다.

만약 후자라면,

그 균형을 잡는 데 필요한 것은 더 많은 개발자가 아니라

그 흐름을 끊고 정리해 줄 제 3의 관점일지도 모릅니다.

현재 문제를 과대평가하면,
미래의 부채가 폭발한다.
구조 대신 사람으로 버티는 순간,
사일로가 고정된다.

프로젝트가 망하는 이유는 기술이 아니라 ‘수주 시점의 판단’에서 이미 결정됩니다.

프로젝트별 사일로 생성

 속도를 위해 분리한 결정이 시간이 지날수록 조직을 분리한다.

대부분의 조직은 사일로가 문제라는 사실을 이미 알고 있습니다.

하지만 프로젝트 수주가 일정과 무관하게 늘어나기 시작하면 이 전제는 쉽게 무너집니다.

빠른 대응을 위해 특정 인력들이 반복적으로 같은 프로젝트에 배치되기 시작하면서,

공식적인 협업 구조보다 비공식적인 커뮤니케이션을 우선하게 됩니다.

그렇게 이 인력 묶음은 '검증된 조합'이라는 이유로 그대로 이동하기 시작합니다.

결국 회사는 프로젝트 단위로 돌아가는 것이 아니라 사람 단위의 묶음이 조직의 기본 단위가 됩니다.

이 상태를 우리는 사일로 라고 부릅니다.

현재의 부채 > 미래의 부채

수주 시점의 판단은 항상 [지금 당장의 문제]를 과대평가한다.

많은 조직들은 당면한 일정과 요구사항을 해결하는 것이

곧 고객의 문제를 해소하는 것이라고 생각하곤 합니다.

이 믿음은 자연스럽게 다음 프로젝트 수주로 이어집니다.

사업팀은 이미 한번 해소한 일처럼 보이기 때문입니다.

하지만 프로젝트가 진행될수록 해결되고 있는 것은 과제일 뿐,

개발팀의 입장에서 고객의 근본적인 문제는 그대로 남아있는 경우가 많습니다.

이 때 해결되지 않은 문제들은 눈에 보이지 않는 형태로 누적되고,

미래의 부채로 연결됩니다.

문제는 이 부채가 즉시 비용으로 드러나지 않는다는 점입니다.

그래서 대부분의 조직은 이를 나중에 정리해도 되는 문제로 과소평가합니다.

시간이 지나고 나서야 그 부채가 이미 단순히 정리할 수 없는 수준으로

커져있음을 발견합니다.

뒤늦게 이를 해소하려 하지만,

여전히 반복되는 당면 과제들이 발목을 잡습니다.

결국 조직은 현재의 문제도, 미래의 부채도,

모두 제대로 해결하지 못한 채 이도 저도 아닌 상태에 머무르게 됩니다.

코드 단일화 난이도 상승

프로젝트 수가 늘어날수록 코드 단일화의 난이도는 기술적인 문제가 아니라 의사결정 문제로 변한다.

수주가 연속적으로 진행되는 상황에서는 어떤 기능을 공통으로 가져가고,

어디까지를 각 프로젝트의 책임으로 둘 것인지에 대한 정리가 선행되기 어렵습니다.

이 상태에서 개발은 가장 빠른 선택을 반복하게 됩니다.

이미 존재하는 코드가 있음에도, 프로젝트별 요구사항에 맞춰 유사한 구현이 다시 만들어지는 것이죠.

시간이 지나면서 중복 코드는 자연스럽게 누적됩니다.

하지만 이 중복은 즉시 문제로 드러나지 않습니다.

이후 유사한 요구가 다시 등장하면

사업팀의 입장에서는 이미 한 번 작업했던 내용처럼 보입니다.

반면 개발팀의 입장에서는 다른 프로젝트에 종속된 구현일 뿐입니다.

이 시점부터 대화는 어긋나기 시작합니다.

사업팀은 속도를 묻고, 개발팀은 코드 구현의 비용을 설명합니다.

문제는 이 간극이 개인의 역량이나 협업 태도의 문제가 아니라,

초기 수주 단계에서 단일화에 대한 판단이 이루어지지 않았던 구조의 결과라는 점입니다.

결국 코드는 합칠 수 없고, 논의는 반복되며,

조직은 같은 문제를 두고 계속 다른 언어로 말하게 됩니다.

맺는말

많은 개발자분들이 이 지점에서 스스로를 자책을 하곤 합니다.

'내가 코드를 막 짜서 이렇게 된건가.'

'그 때, CI/CD 좀 손 봐둘껄...'

'이제 다음 코드는 어떻게 하지'

하지만 이것은 프로젝트 중간에 해결할 수 있는 성질이 아닙니다.

이 지점부터는 기술의 문제가 아니라, 수주 시점에 어떤 판단이 내려졌는가에 대한 문제입니다.