만든 개발자가 떠나도 살아남는 소프트웨어

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

회사 소프트웨어를 기준으로 저는 회사의 부채를 줄이는 개발자를 좋은 개발자라고 봅니다. 부채를 더 늘리지 않고 유지하는 것도 괜찮은 결과일 수 있습니다. 좋은 소프트웨어를 판단할 때도 비슷한 질문을 합니다. 만든 사람이 퇴사한 뒤에도 살아 있을 수 있는가?

제가 이전 회사에서 작업한 시스템 중에는 아직 운영되는 것들이 있습니다. 제가 대단한 코드를 썼다는 증거로 생각하지 않습니다. 다음 사람이 배턴을 받아 시스템을 운영하고, 바꾸고, 또 다음 사람에게 넘길 수 있었다는 뜻입니다. 한 개발자의 영리함을 보여주는 설계보다 이런 연속성이 회사에는 더 가치 있습니다.

퇴사 직후의 재작성은 경고다

여러 번 본 흐름이 있습니다. 한 개발자가 익숙하지 않은 기술을 가져와 시스템을 만들고, 그 작업으로 외부 발표도 한 뒤 퇴사합니다. 남은 팀은 시스템을 살펴보고 학습하고 고치는 것보다 새로 만드는 비용이 더 낮다고 판단합니다. 다시 만든 시스템은 더 단순하고, 회사가 예상하는 트래픽과 향후 2~3년의 성장에는 충분한 경우가 많습니다.

외부 발표나 새 기술 자체가 문제는 아닙니다. 재작성됐다는 사실만으로 처음 만든 사람이 무책임했다고 단정할 수도 없습니다. 요구사항은 변하고 교체가 타당할 때도 있습니다. 경고해야 할 것은 설명하고 고칠 수 있는 유일한 사람이 사라지자 설계의 가치도 함께 사라지는 시스템입니다.

도입한 사람도 기술을 처음 배우면서 운영 시스템에 적용했다면 문제는 더 커집니다. 일반적인 역량이 부족하다는 뜻은 아닙니다. 누구나 익숙하지 않은 도구 앞에서는 서툽니다. 바로 그렇기 때문에 회사 시스템이 한없는 실험을 떠안아서는 안 됩니다. 주니어 개발자가 안전하게 수정할 수 없고, 남은 시니어도 장애 때 복구하지 못한다면 회사는 한 사람에게 매달린 취약한 의존성을 소유하게 됩니다.

프로 개발자는 급여를 받고 회사의 일을 진전시키는 사람입니다. 배우고 싶은 욕구는 건강하지만 모든 기술적 호기심을 운영 시스템에서 해결해야 하는 것은 아닙니다. 축구를 하기로 계약한 선수가 재미있다는 이유로 훈련 시간에 갑자기 다른 종목을 하겠다고 정할 수는 없습니다. 주말 모임이라면 가능합니다. 돈을 받고 일하는 맥락에서는 책임이 달라집니다.

비유가 강하고 회사 일은 스포츠보다 복잡합니다. 개발자에게 나아질 공간은 필요하고 회사도 구성원의 학습으로 이득을 얻습니다. 쓸 만한 경계는 실험이 실패하거나 도입자가 없어져도 복구할 수 있는가입니다.

누가 실험을 복구할지 묻기

팀이 영원히 같은 기술만 사용해야 한다고 생각하지 않습니다. 그 결론이라면 익숙한 데이터 접근 방식과 오래된 프레임워크 버전에서 한 발도 움직일 수 없습니다. 모든 실험을 금지하는 회사는 다른 종류의 부채를 만듭니다.

새 기술을 제안할 때는 실무적인 질문을 합니다.

• 개인 프로젝트나 작은 사내 프로젝트에서라도 써본 사람이 있는가?
• 구현을 안내하고 실패 조건을 리뷰할 사람은 누구인가?
• 도입한 사람이 떠나면 누가 운영하고 수정하는가?
• 장애가 나면 나나 다른 개발자가 코드에 들어가 짧은 시간 안에 복구할 수 있는가?
• 팀이 안전하게 배울 만큼 영향 범위가 작은가?

경험 있는 사람이 함께하는 작은 사내 프로젝트는 실험하기 좋은 장소가 될 수 있습니다. 그래도 도입한 사람이 떠나거나 장애가 났을 때 남은 팀이 고치거나 교체할 수 있어야 합니다. 팀의 현재 능력에서 벗어나는 폭은 팀이 흡수할 수 있는 정도여야 합니다.

여기서 저는 깨진 항아리를 떠올립니다. 물은 가장 낮게 깨진 곳까지만 찹니다. 뛰어난 한 명이 정교한 설계를 계속 부어도 다른 사람이 유지할 수 없다면 그 사람이 멈추는 순간 수위가 내려갑니다.

물을 영원히 낮게 유지하자는 뜻은 아닙니다. 깨진 부분을 올려야 합니다. 교육하고, 페어로 일하고, 리뷰하고, 문서를 남기고, 작은 프로젝트를 운영합니다. 팀이 현재 수준에서 조금 더 뻗게 해야 합니다. 학습 과정에서 물이 조금 흐를 수는 있지만 닦을 수 있는 양이어야 합니다. 항아리에 홍수를 붓는다고 성장 속도가 빨라지지는 않습니다. 장애가 나고 항아리 자체가 깨질 수 있습니다.

성장은 계단에 가까워야 합니다. 팀이 감당할 수 있는 실천을 하나 도입하고 운영하는 법을 익힌 뒤 다음 계단으로 갑니다. 개발자 한 명만 크게 뛰고 나머지가 그대로라면 그 사람이 떠날 때 낙폭도 커집니다.

엔지니어링 선택 안에는 인수인계가 숨어 있다

많은 설계 논의는 사실 인수인계에 관한 논의입니다.

모듈은 의존성 제약을 걸어 다음 개발자가 경계를 넘기 전에 멈추게 합니다. 테스트는 중요한 동작을 기록해 이후 변경이 그 의도를 마주치게 합니다. 문서는 판단의 이유를 보존합니다. 단순한 기술 선택은 새벽 장애에 대응할 수 있는 사람의 수를 늘립니다. 어느 것도 좋은 소프트웨어를 보장하지는 않지만 한 사람의 머릿속에만 있는 지식을 줄일 수 있습니다.

개인 프로젝트의 아키텍처를 회사에 그대로 적용하지 않습니다. 개인 프로젝트는 제가 계속 운영할 가능성이 높고, 학습이나 재미가 목적의 일부라서 복잡성을 선택할 수도 있습니다. 회사에서는 예상 트래픽, 팀 역량, 채용, 장애 대응, 제품 수명과 실패 비용이 적정 수준을 정합니다.

이 절제는 엔지니어링을 낮게 보는 태도가 아닙니다. 적절한 엔지니어링은 회사의 가치를 계속 사용할 수 있게 합니다. 바꾸고, 배포하고, 복구하고, 인계하기 쉬운 시스템은 비즈니스가 전달을 계속하게 합니다. 흥미롭지만 한 명의 퇴사 뒤 버려야 하는 시스템은 기술적 야심을 회사의 부채로 바꿉니다.

기념비 대신 자산 남기기

급여를 받는다고 무리한 요구를 전부 받아들이거나 품질을 포기해야 하는 것은 아닙니다. 부족한 테스트, 느린 변경, 반복 장애와 특정 개인 의존도 비즈니스 비용입니다. 프로의 책임에는 명령을 수행하는 일뿐 아니라 그 비용을 설명하고 시스템을 개선하는 일도 들어갑니다.

회사 코드는 개인의 기념비가 아니라는 사실도 기억해야 합니다. 아키텍처에 만든 사람의 이름이 보일 필요는 없습니다. 다른 사람이 의도를 이해하고, 실패를 복구하고, 처음부터 다시 만들지 않은 채 제품을 이어가는 상태가 쓸모 있는 유산입니다.

설계나 의존성을 고르기 전에 이어달리기가 어떻게 계속될지 묻습니다. 다음 달에 내가 떠나도 팀이 운영할 수 있는가? 익숙하지 않은 장애가 나면 누군가는 볼 곳을 아는가? 실수 비용이 큰 곳에 테스트, 제약과 설명을 남겼는가? 소프트웨어가 팀이 지속할 수준에 맞으면서 그 수준을 높일 길도 주는가?

좋은 소프트웨어는 만든 사람 없이도 살아남습니다. 좋은 개발자는 그 생존을 특별한 일이 아니게 만듭니다.