AI 전환은 도구가 아니었다 - 직방이 일하는 방식을 다시 쓴 이유 

AI 코딩 도구를 쓰면 개발이 빨라질까?

처음엔 단순한 질문에서 시작했어요. 직방은 이 질문에 직접 답을 찾아보기로 했어요. 올해 1월부터 개발·기획·디자인·QA 전 직군에 AI 코딩 도구를 제공하고, 3개월간 실제 데이터를 쌓았어요.

막혀 있던 건 코드 앞이었어요

AI가 코드를 빠르게 써준다고 해서 개발이 빨라지는 게 아니었어요.

기획 문서(스펙)의 완성도와 안정성, 의사결정이 얼마나 명확하게 정리되어 있는지가 업무의 전체 속도를 결정하고 있었어요. 코딩은 이미 충분히 빠른 단계였어요. 막혀 있던 건 그 앞이었고요.

이 발견이 직방의 방향을 바꿨어요. "AI 도구를 더 잘 쓰자"에서 "일하는 방식 전체를 다시 설계하자"로요. 도구만 바꾸는 건 AI 도입이에요. 직방이 택한 건 AI 전환이었어요.

규칙을 지키는 도구를 직접 만들었어요

AI 코딩 도구가 빨라졌다고 해서 아무렇게나 쓸 수는 없었어요.

AI가 코드를 쓸수록 새로운 문제가 생겼어요. 직방의 개발 규칙을 AI가 모르거나 무시하는 경우, 일관성이 깨지거나 테스트를 통과하지 못하는 코드가 나왔어요. 빨라졌지만 검토에 다시 시간이 걸리는 구조였어요.

그래서 직방 AI Native 조직에서 직접 만들었어요. AI 코딩 환경 위에서 작동하는 직방 전용 AI 개발 도구예요. 빠르게 쓰되, 직방의 규칙 안에서 쓸 수 있도록 설계했어요.

단계마다 AI와 사람의 역할을 나눴어요.

AI는 문서 초안 작성, 일관성 체크, 규칙 감시 등 빠르게 만들고 일관성을 지켜요. 사람이 처음부터 혼자 하면 시간이 걸리는 것들이에요.

사람은 판단하고 최종 결정을 내려요. 무엇을 먼저 만들지, 어떤 기술 방식이 더 나은지, AI가 놓친 예외 상황은 없는지 등 데이터만으로는 알기 어려운 것들이에요. 각자 잘할 수 있는 것을 나눈 거예요.

검토가 끝나는 순간, 다음 단계로 넘어가요

기존 방식에는 단계를 넘어갈 때마다 별도의 확인·승인 절차가 필요했어요. 개발을 시작하기 전, 기획된 것을 더 이상 바꾸지 않겠다고 정한 뒤 그 이후엔 내용이 바뀌어도 "이미 시작됐어요, 반영을 위해선 다음 주기를 기다려야 해요"와 같은 상황이 자주 발생했어요.

직방은 이 방식을 바꿨어요. 단계마다 별도의 결재 절차를 두는 대신, 각 단계의 산출물이 팀원들의 검토를 거쳐 최종 반영되는 시점, 별도의 승인 회의 필요 없이 그 자체가 자동으로 단계 완료가 되는 구조에요.

중간에 내용이 바뀌어도 코드 수정과 동일한 절차로 처리되기 때문에 변경 이력이 자동으로 남아 추적이 가능하고, 변경이 생겨도 같은 흐름으로 즉시 반영할 수 있어요.

3주마다 기다리는 걸 없앴어요

도구를 만드는 것만으로는 부족했어요. 도구가 제대로 작동하려면 일하는 리듬도 함께 바뀌어야 했어요.

기존 스프린트 방식은 3주에 한 번 출발하는 버스 같았어요. 기능이 일찍 완성돼도 출발 시간까지 기다려야 했고, 시간이 됐는데 준비가 덜 됐다면 다음 버스를 타야 했어요. 직방은 이걸 상시 배포 체제로 바꿨어요. 마치 준비되면 바로 출발하는 택시와 같아요. 기능 하나가 완성되고 테스트를 통과하면 그 즉시 사용자에게 전달할 수 있어요. 

배포 결정도 별도 단계로 독립시켜 사람이 직접 판단하도록 했어요. 속도를 높이면서도 품질을 잃지 않는 구조예요.

직방은 계속 실험중이에요

리드타임이 30% 줄어든 것처럼 AI 코딩 도구 활용의 효과는 확인했어요. 하지만 3개월의 실험으로 이 모든 변화의 효과를 알기에는 시간이 더 필요해요. 효과를 섣불리 단정지을 수는 없어요.

도구와 체제는 준비했어요. 더 확실한 효과는 조직 차원의 파일럿 실험을 통해 "해봤더니 이랬다"는 데이터가 쌓이면 그때 다시 이야기하려고 해요. 코딩이 병목이 아니라는 걸 확인한 것처럼요.