신뢰와 작은 성공으로 개발 문화를 바꾸는 법

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

새 회사가 테스트 없이 빠르게 배포하고, 최신 정책 문서도 없으며, 스펙을 개발자끼리 구전으로 넘길 수 있다. 장애가 나면 기억 속 정책이 지금도 맞는지 몰라 파악부터 오래 걸린다. 그렇다고 입사하자마자 전사를 고치려 하지 않는다. 최소 첫 3개월은 귀를 열고 맡은 일을 잘해 개발자와 비개발자의 신뢰부터 얻는다.

실제 업무 하나를 놓고 정기적으로 모인다

팀을 이해한 뒤 2~3주에 한 번 한 시간 정도 실제 서비스를 이야기하는 시간을 제안한다. 이름은 중요하지 않다. 불명확한 정책, 최근 장애나 모두가 이해하지 못한 흐름을 가져온다. 외부 이론을 공부하려는 자리가 아니라 팀의 코드와 비즈니스 지식을 보이게 하는 시간이다.

테스트도 같은 업무에서 시작한다. 레거시 전체를 덮자고 요구하지 않는다. 최근 버그를 함께 다루거나 다음 변경을 지킬 회귀 테스트를 만든다. 나중에 그 테스트가 비슷한 문제를 배포 전에 잡으면 동료는 테스트의 장점을 설명이 아니라 경험으로 받아들인다.

한 팀의 결과가 다음 팀의 초대를 만든다

먼저 영향력을 행사할 수 있는 내 팀부터 바꾼다. 실제 업무를 푸는 공개 채널을 본 옆 팀 개발자들이 참관을 요청하고 자기 팀에도 적용하는 법을 물었다. 달라진 분위기와 실제 문제를 다루는 모습이 전사 명령 없이도 실천을 보이게 했다. 기획자와 제품 담당자는 나중에 요청이 더 빨리 끝나거나 운영 이슈가 줄어드는 변화를 알아챌 수 있다. 원문은 두 달 걸리던 변경이 한 달 만에 끝나는 상황을 예로 든다. 그런 결과가 나타나면 어떤 실천과 연결됐는지 설명한다. 정책 지식이 필요한 자리에는 이들을 초대한다. 정책을 문서로 만들거나 테스트로 옮기는 과정에서 기획과 개발이 서로 다른 스펙을 기억했다는 사실이 드러날 수도 있다.

이 순서를 허용하지 않는 구조도 있다

성과는 한 달 만에 나올 수도, 1년이 걸릴 수도 있어 끈기가 필요하다. 동시에 함께 바꿀 동료도 필요하다. 오래 일한 사람이 암묵지를 권력으로 쓰고 고착된 집단이 모든 개선을 막는다면 아래에서의 노력만으로 부족할 수 있다. 그런 경우 끈기로 구조를 이길 수 있는 척하기보다 떠난다.

사람들이 개선할 의지는 있지만 방법을 모르는 조직이라면 순서는 현실적이다. 관찰하고, 일을 끝내고, 신뢰를 얻고, 쓸모 있는 팀 실천 하나를 만들고, 달라진 결과를 보여준 뒤 주변이 가져가게 한다.