원본: [유튜브] 이직한 회사의 개발 문화 갱생시키기 - 제미니의 개발실무
AI 기반 정리본
- 속도에만 집착하는 개발
- 테스트 코드 전무
- 정책 문서 없음
- 개발자가 스펙을 채우고 구전으로 전달
- 장애/문제 파악 자체가 오래 걸림
- 정책이 최신인지 아닌지도 모름
- 신규 요구사항/수정 대응이 느림
(위 3개는 개발팀만 바꾸면 작은 문제, 아래로 내려갈수록 기획/운영/PM 등의 문화도 바꿔야 하는 큰 문제)
1. 최소 3개월은 관망
- 스며들지 말고, 귀는 열고 입은 닫아라
- 일은 해내면서 결과 내라
- 동료(개발자 + 비개발자)의 신뢰를 먼저 얻어라
- 신뢰 없이 의견 피력하면 안 먹힘
2. 개발자끼리 정기 모임 만들기
- 최소 2주에 한 번, 1시간 이상
- "도메인 스터디" 형태 (DDD 아님, 비즈니스/서비스 이해 목적)
- 슬랙 채널 만들어서 궁금한 것, 깨달은 것 올리고 모여서 리뷰
- 페어 프로그래밍, 모브 프로그래밍으로 테스트 코드 같이 짜보기
3. 팀 먼저 바꿔라
- 회사 전체 바꾸려 하지 말고 내 팀부터
- 내 팀이 바뀌면 옆 팀이 관심 가짐
- "쟤네 뭐 하는데?" → 자연스럽게 전파됨
- 실제로 물어보는 사람 많았음: "어떻게 하는 거냐", "우리 팀도 하고 싶다"
4. 효과를 보여줘야 함
- 테스트 코드 덕에 장애 안 남
- 수정하다가 테스트 깨져서 장애 막음
- 이런 경험 하면 사람들이 "나한테 도움 되네" 느낌
- 인간은 자기한테 도움 돼야 받아들임, 그전까진 "그게 뭐가 도움이 돼" 마인드
- 개발팀이 나아지면 자연스럽게 느낌
- "예전엔 2달 걸렸는데 왜 1달 만에 되지?"
- "운영 이슈 요즘 줄었네"
- 그때 한마디 얹어줘라: "우리가 이런 식으로 정리하고 있다"
- 우호적인 기획자/PO는 도메인 스터디에 초대해도 좋음
- 정책 얘기하다 보면 기획자도 "나도 그거 몰랐는데" 하는 경우 있음
- 기획자가 개발자한테 스펙 배워가는 경우도 실제로 있음
안 바뀌는 사람들에 대해:
"너무 이기적이거나 사회 부적응자 같은 개발자 아닌 이상은... 너무 비하했나? 어쨌든 그런 이상한 사람들 있거든요. 또라이 같은 사람들 있어요."
도메인 독점하는 사람:
"오래 다녔고 '나 철밥통이니까 내 도메인 내 거야'라고 하면서 안 알려주는 사람들... 정리해야죠. 회사에 도움이 안 되는 사람입니다."
팀이 팀이 아닌 경우:
"우리 팀이라는 말 자체가 안 나오는 팀들 있거든요. 같이 밥도 안 먹고, 커피도 안 마시고, 대화도 안 하고... 그건 팀이 아니라 월급 받기 위한 유닛이죠."
도망쳐야 할 때:
"기획과 개발자 꼰대가 초창기부터 다녀서 권력 쥐고 있는 카르텔이 있으면? 그냥 빨리 도망치는 게 답입니다."
- 이런 경험 몇 번 하면 "어디 가서든 정상화시킬 수 있겠다"는 자신감 생김
- 바꾸려는 의지 있으면 노력해볼 가치 있음
- 단, 카르텔 있으면 탈출이 답