일본에서 3년간 소프트웨어 엔지니어로 일하며 느낀 한국과 일본 개발 문화의 차이
일본에서 3년간 소프트웨어 엔지니어로 일하면서 가장 크게 느낀 차이는 기술력 자체가 아니었다. 사용하는 언어, 프레임워크, 개발 도구는 생각보다 크게 다르지 않았다. 오히려 가장 큰 차이는 일을 시작하는 방식에 있었다.
한국에서는 어떤 문제가 보이면 일단 움직이는 것이 비교적 자연스럽다. 내가 어떤 과제감을 느꼈고, 다른 팀과 이야기해 보니 그쪽도 비슷한 문제의식을 가지고 있었다면, 어느 정도 생각을 정리해서 테크 리더나 상사에게 “이런 식으로 개선하면 괜찮을 것 같습니다”라고 제안할 수 있다. 때로는 간단한 프로토타입이나 Pull Request를 만들어서 보여줄 수도 있다.
이런 행동은 대체로 긍정적으로 받아들여진다. 물론 모든 한국 회사가 그렇다는 뜻은 아니다. 하지만 적어도 내가 경험한 한국의 개발 문화에서는 “시키지 않았는데도 문제를 발견했고, 다른 팀과도 이야기했고, 해결책까지 고민해 왔다”는 점이 주도성으로 평가되는 경우가 많았다. 테크 리더 입장에서도 팀원이 알아서 괜찮은 제안을 가져오면 고마운 일이다. 그것은 문제 해결 능력이고, 조직에 대한 기여로 받아들여진다.
그런데 일본에서는 이 방식이 잘 통하지 않는 경우가 많았다.
내가 느낀 일본의 개발 문화에서는 문제를 발견한 순간부터 먼저 상사나 테크 리더에게 상담해야 한다. “이런 문제가 있는 것 같습니다”라는 단계에서 공유하고, “이 방향으로 생각하고 있습니다”라는 단계에서 상담하고, “이제 만들어 보겠습니다”라는 단계에서도 합의를 받아야 한다. 이미 어느 정도 조사하고, 다른 팀과 이야기하고, 가능성을 검토한 뒤에 제안하는 방식은 오히려 부담스럽게 받아들여질 때가 있었다.
특히 인상적이었던 것은 생산성 향상을 위한 작은 개선 작업에서도 비슷한 반응이 나온다는 점이었다. 나는 개발하다가 불편한 부분을 발견하면, 먼저 간단한 개선을 만들어 놓고 Pull Request로 보여주는 방식이 자연스럽다고 생각했다. 테크 리더가 보기 좋으면 받아들이면 되고, 별로면 거절하면 되고, 방향은 좋은데 수정이 필요하면 리뷰를 통해 고치면 된다고 생각했다. 이것이 개발 조직에서 흔히 말하는 빠른 피드백 사이클이라고 믿었다.
하지만 일본에서는 이런 방식이 “먼저 상담하지 않고 진행한 일”로 받아들여질 수 있었다. “왜 먼저 말하지 않았느냐”, “리뷰하는 사람의 부담이 커진다”, “문제가 생기면 책임은 누가 지느냐”라는 이야기가 나왔다. 개선 자체가 나쁘다는 것이 아니라, 개선을 시작하는 방식이 문제라는 것이다. 좋은 의도였더라도, 절차를 거치지 않은 행동은 조직에 부담을 주는 행동으로 해석될 수 있었다.
나는 이 지점에서 한국과 일본의 개발 문화가 근본적으로 다르다고 느꼈다.
한국은 상대적으로 “일단 해보고 이야기하자”에 가깝다. 완벽하지 않아도 방향이 좋아 보이면 시도한다. 작은 실패는 감수하고, 빠르게 고치면서 앞으로 나아간다. 누군가가 문제를 발견하고 먼저 움직이면, 그것은 추진력으로 평가된다.
반대로 일본은 “먼저 공유하고, 먼저 합의하고, 먼저 책임 범위를 정하자”에 가깝다. 어떤 일을 시작하기 전에 관련된 사람들에게 충분히 설명해야 하고, 리뷰할 사람의 부담을 고려해야 하며, 문제가 생겼을 때 누가 책임질 것인지도 생각해야 한다. 그래서 실제 개발에 들어가기 전에 회의와 상담과 조율이 많이 발생한다.
물론 이 방식에도 장점은 있다. 일본식 방식은 안정적이다. 갑작스러운 변경으로 인해 다른 팀이 피해를 보는 일을 막을 수 있다. 담당자가 모르게 코드가 바뀌거나, 충분한 검토 없이 기능이 추가되는 일을 방지할 수 있다. 품질이 매우 중요한 시스템이나 장애 비용이 큰 서비스에서는 이런 신중함이 분명히 도움이 된다.
문제는 이 방식이 모든 일에 똑같이 적용될 때다.
내부 개발 생산성을 높이기 위한 작은 개선과 사용자 데이터에 영향을 주는 대규모 변경은 리스크의 크기가 다르다. 되돌리기 쉬운 자동화 작업과 장애 가능성이 큰 시스템 변경도 다르다. 그런데 모든 일을 같은 무게로 다루면, 작은 개선조차 시작하기 어려워진다.
좋은 아이디어는 처음부터 완벽한 형태로 존재하지 않는다. 개발자는 만들면서 생각하고, 부딪히면서 배우고, 작은 결과물을 통해 가능성을 확인한다. 그런데 시작하기도 전에 너무 많은 승인 절차를 요구하면, 그 아이디어는 실제로 검증되기도 전에 사라진다.
품질을 중시하는 문화가 실패 비용을 키울 때
일본 개발 문화에서 반복적으로 느낀 키워드는 품질이었다. 충분히 테스트해야 하고, 영향을 파악해야 하고, 예외 상황을 고려해야 하고, 릴리즈 전에 최대한 완성도를 높여야 한다.
이 자체는 나쁜 것이 아니다. 오히려 배워야 할 점도 많다. 문제는 품질에 대한 집착이 실패 비용을 지나치게 키울 때 발생한다.
소프트웨어에서 80%까지 만드는 것과 80%에서 100%까지 끌어올리는 것은 난이도가 다르다. 어느 정도 동작하는 기능을 만드는 것은 상대적으로 쉽다. 하지만 모든 예외 상황을 고려하고, 모든 케이스를 확인하고, 모든 영향을 문서화하고, 모든 관계자에게 합의를 받는 것은 훨씬 어렵다. 마지막 10%, 20%에 들어가는 비용은 매우 크다.
한국에서는 경우에 따라 80%나 90% 수준에서 먼저 사용자에게 내보내고, 문제가 생기면 빠르게 고치는 접근을 선택한다. 물론 이것이 항상 옳다는 뜻은 아니다. 금융, 의료, 보안, 인프라처럼 실패 비용이 큰 영역에서는 그렇게 해서는 안 된다. 하지만 일반적인 서비스 개발이나 내부 생산성 도구에서는 빠르게 내고 빠르게 고치는 방식이 훨씬 효율적일 때가 많다.
반면 일본에서는 처음부터 100%에 가까운 상태를 요구하는 경우가 많다. “혹시 문제가 생기면 어떻게 할 것인가”, “누가 책임질 것인가”, “영향 범위는 완전히 파악했는가”라는 질문이 먼저 나온다. 그 결과 개발자는 새로운 시도를 하기 전에 너무 많은 것을 증명해야 한다.
여기서 중요한 것은 실패 비용이다.
조직이 실패를 작게 다루면 사람들은 더 많이 시도한다. 작은 실패가 허용되면 개발자는 더 자주 개선하고, 더 자주 실험하고, 더 자주 제안한다. 반대로 실패 비용이 커지면 사람들은 움직이지 않는다. 실패했을 때 책임을 크게 묻는 조직에서는 누구도 먼저 나서지 않는다. 좋은 아이디어가 있어도 “괜히 했다가 문제가 생기면 내가 책임져야 한다”는 생각이 앞선다.
이런 분위기가 평가 지표와 결합하면 문제는 더 커진다.
품질, 비용, 납기, 안전을 관리하자는 취지 자체는 당연히 중요하다. 안정적인 서비스를 운영하려면 인시던트를 줄여야 하고, 같은 문제가 반복되지 않도록 관리해야 한다. 하지만 이것이 “인시던트 0건”처럼 절대적인 목표가 되는 순간, 사람들의 행동은 달라진다.
사람들은 더 안전한 시스템을 만들기보다, 인시던트가 발생할 가능성이 있는 행동 자체를 피하게 된다. 새로운 기능을 만들지 않고, 레거시를 건드리지 않고, 자동화를 시도하지 않고, 새로운 도구를 도입하지 않는다.
무언가를 했다가 문제가 생기면 책임을 져야 한다. 하지만 아무것도 하지 않아서 잃어버린 기회는 평가에 잘 드러나지 않는다. 자동화를 만들지 않아서 매일 반복 작업에 시간이 낭비되는 것, Warning과 Error가 방치되는 것, 레거시가 계속 쌓이는 것은 조용한 손실로 남는다. 반대로 새로운 시도를 했다가 문제가 생기면 그것은 명확한 실패로 기록된다.
그러면 합리적인 사람일수록 움직이지 않는다.
이건 개인의 게으름이나 무능의 문제가 아니다. 조직의 평가 구조가 그렇게 행동하도록 유도하는 것이다. 실패했을 때의 책임은 크고, 시도했을 때의 보상은 작다면, 사람들은 변화를 피하는 쪽으로 최적화된다.
결국 조직은 품질을 높이는 것이 아니라 변화를 피하는 방향으로 움직인다. 겉으로는 안정적인 조직처럼 보이지만, 내부적으로는 레거시가 쌓이고, 개선 기회가 사라지고, 개발자의 문제 발견 능력과 실행력이 약해진다.
책임을 명확히 하는 문화가 오히려 책임 회피를 만든다
일본에서 일하면서 흥미로웠던 점은 책임을 매우 중요하게 말하지만, 그 결과가 항상 책임 있는 행동으로 이어지지는 않는다는 점이었다.
“문제가 생기면 누가 책임질 것인가”라는 질문은 겉으로 보면 합리적이다. 실제로 서비스 운영에서는 책임 범위를 명확히 하는 일이 중요하다. 하지만 이 질문이 너무 자주, 너무 강하게 사용되면 사람들은 책임을 지기보다 책임을 피하는 방향으로 움직인다.
새로운 개선을 제안하면 리뷰어의 부담이 늘어난다. 리뷰어가 승인하면 그 변경에 대한 책임도 일부 져야 한다. 문제가 생기면 “왜 승인했느냐”는 질문을 받을 수 있다. 그렇다면 리뷰어 입장에서는 적극적으로 받아들이기보다 보수적으로 대응하는 것이 안전하다.
상사도 마찬가지다. 팀원이 새로운 아이디어를 가져왔을 때, 그것이 성공하면 좋지만 실패하면 문제가 된다. 특히 실패가 학습의 일부가 아니라 책임 추궁의 대상으로 받아들여지는 조직에서는, 상사가 새로운 시도를 밀어주기보다 먼저 막는 것이 더 안전한 선택이 된다.
개발자 입장에서도 마찬가지다. 작은 개선을 제안할 때마다 사전 상담, 영향 범위 설명, 리뷰 부담, 책임 소재를 모두 고려해야 한다면 점점 제안을 줄이게 된다. 문제를 발견해도 “이거 말 꺼내면 일이 커지겠지”라고 생각하게 된다.
이 구조에서는 아무도 명시적으로 혁신을 반대하지 않는다. 하지만 모두가 자신의 리스크를 줄이는 방향으로 행동한다. 그 결과 조직 전체는 점점 더 보수적으로 변한다.
기존 방식을 개선하는 것과 일하는 방식 자체를 바꾸는 것은 다르다
안정성을 지나치게 중시하는 조직은 기존 방식을 더 정교하게 만드는 데에는 강하다. 리뷰 절차를 더 촘촘하게 만들고, 보고 라인을 더 명확하게 하고, 책임 범위를 더 세밀하게 나눈다. 이것은 분명히 품질을 높이는 데 도움이 된다.
하지만 문제는 기존 방식 자체가 병목일 때다.
그때 필요한 것은 더 정교한 절차가 아니라, 절차 자체를 바꾸는 시도다. 사람이 로그를 더 열심히 보고, 사람이 이슈를 더 꼼꼼히 만들고, 사람이 리뷰를 더 신중하게 하는 것은 기존 방식 안에서의 개선이다. 반면 운영 데이터에서 이슈를 자동 생성하고, 사람이 수정 필요 여부를 판단한 뒤, AI가 밤사이에 수정안을 만들고, 다음 날 사람이 QA하는 흐름은 일하는 방식 자체를 바꾸는 시도에 가깝다.
최근 AI 도입에서도 비슷한 장면을 직접 경험했다.
나는 BugSnag이나 Kibana에 쌓인 Warning, Error를 기반으로 이슈를 자동 생성하고, 사람이 그 이슈를 보고 실제 수정이 필요한 것에만 need-fix 라벨을 붙이고, 밤사이에 Claude Code가 수정안을 만들고, 다음 날 아침 사람이 QA한 뒤 배포하는 흐름을 제안한 적이 있다.
이 구조에서 AI는 최종 의사결정자가 아니다. AI가 마음대로 판단하고, 마음대로 수정하고, 마음대로 배포하는 방식도 아니다. 판단은 사람이 한다. QA도 사람이 한다. 배포도 사람이 한다. AI는 사람이 수정이 필요하다고 판단한 작업을 밤사이에 대신 수행하는 보조자 역할을 한다.
즉, 이것은 무모한 자동화가 아니었다. 오히려 사람의 판단과 검증을 남겨둔 상태에서 반복적인 수정 작업만 AI에게 맡기는, 꽤 통제된 형태의 실험이었다.
하지만 실제 논의에서는 한도 제한 리스크나 현재 팀 운영 플로우에서 부담이 커질 것 같다는 우려가 먼저 나왔고, 결국 작은 실험으로도 이어지지 못했다.
물론 그런 우려가 완전히 틀렸다는 뜻은 아니다. 비용도 관리해야 하고, AI가 만든 수정안의 품질도 검증해야 하며, 리뷰 부담이 늘어날 가능성도 있다. 운영 플로우와 맞지 않는 부분도 있을 수 있다.
하지만 리스크를 발견하는 것과, 그 리스크를 이유로 시도를 멈추는 것은 다르다.
좋은 조직이라면 우려를 이유로 제안을 사장시키는 것이 아니라, 우려를 통제할 수 있는 작은 실험으로 바꿔야 한다. 하루에 최대 3개의 이슈만 처리하게 할 수 있다. 특정 유형의 Warning만 대상으로 할 수 있다. 처음에는 자동 수정이 아니라 수정안 제안까지만 하게 만들 수 있다. 민감한 영역은 제외할 수 있다. 배포는 반드시 사람이 하도록 제한할 수 있다.
문제는 리스크가 있다는 사실이 아니다. 모든 새로운 시도에는 리스크가 있다. 진짜 문제는 리스크를 어떻게 줄여서 실험할지 고민하기보다, 리스크가 있다는 이유로 제안 자체를 멈추는 태도다.
기존 방식 안에서의 개선은 비교적 받아들여지기 쉽다. 지금 하던 일을 조금 더 안전하게, 조금 더 꼼꼼하게, 조금 더 체계적으로 만드는 일이기 때문이다. 반대로 기존 방식 자체를 바꾸는 제안은 훨씬 쉽게 거부된다. 책임 구조가 바뀌고, 리뷰 방식이 바뀌고, 팀의 운영 리듬이 바뀌기 때문이다.
하지만 진짜 생산성 향상은 대부분 후자에서 나온다. 더 열심히 일하는 것이 아니라, 일하는 방식 자체를 바꿀 때 큰 변화가 생긴다.
레거시는 취향이 아니라 구조의 결과다
나는 일본이 단순히 레거시를 좋아한다고 생각하지 않는다. 낡은 시스템이 불편하다는 것을 모르는 것도 아니다. 오래된 프로세스가 비효율적이라는 것도 알고, 반복 작업이 생산성을 떨어뜨린다는 것도 안다.
그런데도 레거시는 쉽게 사라지지 않는다. 이유는 간단하다. 레거시를 바꾸는 리스크는 눈에 잘 보이지만, 레거시를 유지하는 비용은 잘 보이지 않기 때문이다.
레거시를 고치다 문제가 생기면 그것은 명확한 실패가 된다. 장애가 발생하거나, 일정이 밀리거나, 예상하지 못한 영향이 생기면 “왜 바꿨느냐”는 질문이 나온다. 반대로 레거시를 그대로 둬서 발생하는 비용은 특정 사건으로 기록되지 않는다. 반복 작업에 낭비되는 시간, 느린 개발 속도, 신규 개발자의 높은 온보딩 비용, 장애 대응의 어려움은 조직 전체에 넓게 퍼져 있을 뿐이다.
그래서 레거시는 유지된다. 더 좋은 방법이 없어서가 아니다. 바꾸는 비용은 한 사람이나 한 팀의 리스크로 보이지만, 바꾸지 않는 비용은 조직 전체에 희미하게 분산되기 때문이다.
이런 환경에서는 오래된 도구가 계속 쓰이고, 불편한 프로세스가 유지되고, 반복 작업이 자동화되지 않는다. 모두가 불편함을 알고 있지만, 그것을 바꾸는 일은 항상 후순위로 밀린다. 지금 당장 큰 문제가 터진 것은 아니기 때문이다.
결국 조직은 안정성을 얻는 대신 변화 가능성을 잃는다. 레거시는 취향의 문제가 아니라, 변경 리스크만 크게 보이고 유지 비용은 작게 보이는 구조의 결과다.
한국식 방식과 일본식 방식의 장단점
여기까지 일본식 안정성 중심 문화의 한계를 주로 이야기했지만, 그렇다고 한국식 방식이 무조건 옳다는 뜻은 아니다.
한국식 “일단 해보자” 문화에는 분명한 장점이 있다. 속도가 빠르다. 새로운 아이디어가 쉽게 시도된다. 실무자가 느낀 문제의식이 실제 개선으로 이어질 가능성이 높다. 위에서 완벽하게 이해하지 못한 문제라도, 현장에서 먼저 움직이며 해결할 수 있다.
이런 문화는 빠른 성장과 변화에 강하다. 새로운 시장에 진입하거나, 기술 전환이 빠른 영역에서 경쟁하거나, 아직 정답이 없는 문제를 풀 때 강력한 힘을 발휘한다.
하지만 단점도 있다. 충분한 검토 없이 진행하다가 품질 문제가 생길 수 있다. 문서화가 부족해질 수 있다. 다른 팀에 미치는 영향을 과소평가할 수 있다. 특정 개인의 추진력에 지나치게 의존할 수도 있다. “일단 했다”가 누적되면 시스템은 복잡해지고, 나중에 더 큰 기술 부채로 돌아올 수 있다.
일본식 방식도 마찬가지다. 일본식 문화는 품질, 안정성, 책임 범위, 관계자 조율을 중요하게 여긴다. 이 점은 분명히 장점이다. 대규모 시스템, 장기 운영 시스템, 장애 비용이 큰 서비스에서는 이런 신중함이 필요하다. 개인의 독단으로 전체 시스템이 흔들리는 것을 막는 데에도 효과적이다.
하지만 단점은 속도와 자율성의 상실이다. 모든 것을 사전에 조율하려 하면 실행이 늦어진다. 작은 개선조차 부담스러워진다. 실패에 대한 두려움이 커지고, 사람들은 새로운 시도를 줄인다. 결과적으로 조직은 안정적이지만 정체된다.
소프트웨어는 모든 것을 처음부터 완벽하게 예측할 수 없다. 사용자 반응, 시스템 병목, 개발자 생산성 문제는 실제로 만들고 운영하면서 드러나는 경우가 많다. 그래서 빠른 실험과 피드백 루프가 중요하다.
그런데 안정성을 지나치게 중시하는 방식은 이 피드백 루프를 느리게 만든다. 먼저 합의하고, 먼저 책임을 정하고, 먼저 모든 영향을 확인하려다 보면, 정작 배울 기회가 줄어든다.
필요한 것은 품질 포기가 아니라 리스크에 맞는 프로세스다
내가 말하고 싶은 것은 품질을 포기하자는 것이 아니다. 일본식 품질 문화에는 배울 점이 많다. 꼼꼼한 리뷰, 영향 범위 확인, 장애 예방, 문서화, 관계자 조율은 모두 중요하다.
하지만 모든 일에 같은 수준의 품질 기준을 적용해서는 안 된다. 내부 도구 개선과 결제 시스템 변경은 다르다. 개발 생산성 향상을 위한 작은 자동화와 사용자 데이터에 영향을 주는 대규모 마이그레이션은 다르다. 그런데 모든 변경을 동일하게 무겁게 다루면, 조직은 아무것도 빠르게 개선할 수 없다.
중요한 것은 리스크의 크기에 맞게 프로세스를 다르게 적용하는 것이다.
작은 개선은 가볍게 실험할 수 있어야 한다. 되돌릴 수 있는 변경은 빠르게 시도할 수 있어야 한다. 영향 범위가 좁은 작업은 담당자의 자율성을 더 인정해야 한다. 반대로 장애 비용이 큰 변경은 충분히 조율하고 검증해야 한다.
필요한 것은 무조건적인 자율성도 아니고 무조건적인 통제도 아니다. 필요한 것은 리스크에 비례하는 의사결정 구조다.
작은 실험에는 작은 절차가 필요하고, 큰 변경에는 큰 절차가 필요하다. 모든 일을 같은 무게로 다루는 순간, 조직은 느려진다. 그리고 느린 조직은 결국 변화에 뒤처진다.
어떻게 바뀌면 좋을까
첫째, 작은 개선에는 더 많은 자율성을 줘야 한다. 모든 것을 처음부터 상사에게 상담하게 만들면 개발자는 움직이지 않는다. 영향 범위가 작고 되돌리기 쉬운 변경이라면, 먼저 만들어 보고 리뷰를 통해 판단할 수 있어야 한다. Pull Request 자체가 상담의 장이 될 수 있다.
둘째, 사전 상담이 필요한 기준을 명확히 해야 한다. “무조건 먼저 상담”은 너무 넓다. 사용자 영향이 있는가, 장애 가능성이 큰가, 다른 팀의 업무를 바꾸는가, 되돌리기 어려운가, 보안이나 개인정보와 관련이 있는가 같은 기준을 정해야 한다. 기준이 명확하면 개발자는 어디까지 자율적으로 움직일 수 있는지 알 수 있다.
셋째, 리뷰를 책임 추궁의 장이 아니라 품질 개선의 장으로 봐야 한다. 리뷰어가 모든 책임을 떠안는 구조가 되면 리뷰어는 보수적으로 변할 수밖에 없다. 리뷰는 함께 품질을 높이는 과정이지, 나중에 책임자를 찾기 위한 도장이 되어서는 안 된다.
넷째, 실패를 작게 만드는 구조가 필요하다. 실패를 없애려고 하면 시도도 없어진다. 대신 작은 실패가 가능하도록 단계적 배포, 롤백 전략, 모니터링, 자동화된 테스트를 강화해야 한다. 그러면 새로운 시도를 하더라도 리스크를 통제할 수 있다.
다섯째, KPI도 바뀌어야 한다. 인시던트 0건만을 목표로 하면 조직은 변화를 피하는 방향으로 움직인다. 더 나은 지표는 심각한 인시던트 감소, 평균 복구 시간 단축, 재발 방지, 방치된 Warning과 Error 감소, 자동화로 줄인 반복 작업 시간, 배포 리드타임 개선 같은 것들이다. 단순히 문제가 없었는지가 아니라, 조직이 얼마나 빠르게 감지하고, 복구하고, 학습하고, 개선했는지를 봐야 한다.
여섯째, 리더는 아이디어를 초기에 자르는 사람이 아니라 실험의 범위를 정해주는 사람이 되어야 한다. 좋은 리더는 “하지 마라”라고 말하는 사람이 아니라 “어디까지라면 안전하게 해볼 수 있는가”를 함께 정해주는 사람이다. 완전한 승인과 완전한 금지 사이에는 작은 실험이라는 선택지가 있다.
안정성은 변화를 가능하게 하기 위한 기반이어야 한다
일본에서 일하면서 느낀 것은 일본의 개발 문화가 무능해서 느린 것이 아니라는 점이다. 오히려 많은 사람들이 성실하고, 꼼꼼하고, 책임감 있게 일한다. 문제는 그 성실함과 책임감이 때로는 조직 전체의 변화 속도를 늦춘다는 것이다.
품질을 중시하는 문화는 강점이다. 책임을 중시하는 문화도 필요하다. 다만 품질과 책임이 모든 변화를 사전에 막는 이유가 되면, 조직은 점점 새로운 시도를 하지 않게 된다. 작은 개선조차 먼저 설명하고, 합의하고, 책임 범위를 정해야 한다면, 개발자는 문제를 발견해도 움직이기보다 그냥 넘기는 쪽을 선택하게 된다.
내가 말하고 싶은 안정성은 “아무 일도 일어나지 않는 상태”가 아니다. 소프트웨어 개발에서 변화는 피할 수 없다. 새로운 기능도 만들어야 하고, 오래된 코드도 고쳐야 하고, 반복되는 문제도 줄여야 한다. 중요한 것은 변화를 막는 것이 아니라, 변화가 실패했을 때의 영향을 작게 만드는 것이다.
작은 단위로 시도하고, 문제가 생기면 빠르게 되돌릴 수 있고, 같은 문제가 반복되지 않도록 학습하는 구조가 있다면 개발자는 더 적극적으로 움직일 수 있다. 반대로 실패했을 때의 책임만 크고, 되돌릴 수 있는 장치가 없다면 누구도 먼저 나서려 하지 않는다. 작은 개선조차 리스크가 되고, 레거시는 그대로 남는다.
내가 일본에서 답답하게 느낀 부분도 바로 여기에 있었다. 안정성은 필요하다. 하지만 안정성이 새로운 시도를 가능하게 하는 기반이 아니라, 새로운 시도를 막는 이유로 쓰일 때 조직은 점점 느려진다.
앞으로의 개발 조직에 필요한 것은 품질을 낮추는 일이 아니다. 품질을 이유로 모든 변화를 막는 것이 아니라, 품질을 지키기 위해서라도 더 작게 시도하고 더 빠르게 회복할 수 있는 구조를 만드는 것이다. 안정성은 변화하지 않기 위한 명분이 아니라, 더 안전하게 변화하기 위한 조건이어야 한다.