개발자가 싫어하는 대표의 5가지 습관 - 피해야 할 커뮤니케이션

"이거 간단한 거니까..."

어느 날 저녁 8시, 개발자의 슬랙에 메시지가 옵니다.

 

"내일 투자자 미팅이 있는데, 데모할 때 이 기능 하나만 더 보여주고 싶어요. 간단한 거니까 오늘 밤에 만들 수 있죠?"

개발자는 한숨을 쉽니다. 또 시작이구나.

 

7년간 수많은 개발자들과 일하며, 그리고 수많은 대표님들과 대화하며 느낀 것이 있습니다. 좋은 대표와 나쁜 대표의 차이는 능력이 아니라 습관에 있다는 것을요.

 

특히 개발자와의 커뮤니케이션에서 몇 가지 습관은 정말 치명적입니다. 이런 습관이 반복되면, 아무리 좋은 개발자도 퇴사를 고민하게 됩니다.

습관 1: "간단한 거잖아요" 증후군

왜 문제인가

"이거 그냥 버튼 하나 추가하는 건데..."

 

"다른 데서 복붙하면 되는 거 아닌가요?"

 

"간단한 거니까 금방 되죠?"

 

이 말을 들을 때마다 개발자는 속으로 생각합니다. '간단하면 대표님이 하시죠.'

 

아는 한 개발자는 이런 말을 했습니다. "대표님이 '간단한 거'라고 말하면, 저는 자동으로 예상 시간에 3배를 곱합니다."

 

왜 간단하지 않을까요?

 

겉으로 보이는 건 버튼 하나지만:

• 버튼 클릭 이벤트 처리
• API 호출
• 에러 핸들링
• 로딩 상태 관리
• 성공/실패 메시지
• 다른 화면과의 연동
• 데이터베이스 스키마 수정
• 백엔드 로직 구현
• 보안 검증
• 테스트 작성

한 스타트업 대표는 "텍스트 색깔만 빨간색으로 바꿔주세요"라고 했습니다. 개발자가 3일 걸린다고 하자, "색깔 하나 바꾸는 데 3

 

일이나요?"라고 반문했습니다.

 

알고 보니 그 텍스트는:

• 10개 이상의 다른 화면에서 사용
• 디자인 시스템 전체 수정 필요
• 이미 빨간색으로 다른 의미로 사용 중
• 색약 사용자를 위한 대체 표현 필요
• QA 테스트 필요

결국 5일이 걸렸습니다.

대신 이렇게 하세요

"이게 얼마나 걸릴까요?" (O)

 

"복잡도가 어느 정도인가요?" (O)

 

"이 작업의 범위를 설명해주실 수 있나요?" (O)

 

개발자의 판단을 존중하세요. 그들이 "3일 걸린다"고 하면, 그럴 만한 이유가 있습니다.

습관 2: 야근과 주말 근무 강요

왜 문제인가

"이번 주말에 이거 좀 만들어주실 수 있나요?"

 

"투자자 미팅이 급한데, 밤새워서라도..."

 

"다들 야근하는데, 개발팀만 칼퇴하면 안 되죠?"

 

한 스타트업 개발자는 3개월간 주 6일, 하루 12시간 일했습니다. 결국 번아웃이 와서 퇴사했습니다. 그리고 그 회사는 6개월 동안 대체 인력을 구하지 못했습니다.

 

개발은 창의적인 작업입니다. 육체노동과 다릅니다. 시간을 2배 투입한다고 결과물이 2배 나오지 않습니다. 오히려 피곤하면:

• 버그가 많아집니다
• 코드 품질이 떨어집니다
• 의사결정이 나빠집니다
• 나중에 더 많은 시간이 듭니다

그리고 무엇보다, 개발자도 사람입니다. 가족이 있고, 취미가 있고, 쉬어야 합니다.

 

어떤 회사는 2주간 개발자들을 연일 야근시켜 서비스를 출시했습니다. 출시 후 1주일 만에 3명의 개발자가 동시에 퇴사 의사를 밝혔습니다. 서비스는 출시했지만, 회사는 마비됐습니다.

대신 이렇게 하세요

긴급한 일이 생겼을 때:

 

"이번 주말에 급한 일이 생겼는데, 도움을 줄 수 있을까요? 물론 대체 휴가나 추가 수당을 드리겠습니다." (O)

강요가 아닌 요청입니다. 그리고 보상이 있습니다.

 

반복적으로 야근이 필요하다면:

 

그건 일정 계획이 잘못된 겁니다. 야근을 강요하지 말고, 우선순위를 조정하세요.

 

"이번 달에 A, B, C 기능을 모두 만드는 건 무리인 것 같습니다. 어떤 걸 먼저 할까요?" (O)

 

한 스타트업 대표는 개발자들에게 "칼퇴근"을 장려했습니다. 대신 업무 시간 동안 집중력을 높였습니다. 회의를 줄이고, 불필요한 업무를 제거했습니다. 결과적으로 야근할 때보다 생산성이 높아졌습니다.

습관 3: 수시로 방향 바꾸기

왜 문제인가

월요일: "소셜 로그인 기능 만들어주세요."
화요일: "아, 그거 잠깐 멈추고, 결제 기능 먼저 해주세요."
수요일: "결제는 나중에 하고, 검색 기능이 더 급해요."
목요일: "다시 생각해보니 소셜 로그인이 제일 중요해요."
금요일: "이번 주에 아무것도 안 끝났네요?"

 

개발자는 매일 다른 일을 시작했다가 멈춥니다. 하나도 완성하지 못했습니다. 대표는 "일을 왜 이렇게 느리게 하냐"고 합니다.

 

개발자의 가장 큰 적은 컨텍스트 스위칭입니다.

 

소셜 로그인을 하다가 멈추면:

• 어디까지 했는지 기억해야 함
• 다음에 다시 시작할 때 파악하는 데 시간이 듦
• 이미 작성한 코드가 낭비됨
• 동기부여가 떨어짐

한 연구에 따르면, 개발자가 한 작업에서 다른 작업으로 전환하는 데 평균 23분이 걸린다고 합니다. 하루에 5번 전환하면 2시간이 날아갑니다.

 

어떤 스타트업은 대표가 매일 아침 "오늘의 최우선 과제"를 바꿨습니다. 개발자들은 어떤 일도 끝까지 해본 적이 없었습니다. 결국 6개월간 출시한 기능이 하나도 없었습니다.

대신 이렇게 하세요

우선순위를 정하고 지키세요:

"이번 2주는 소셜 로그인에 집중합시다. 다른 요청은 그 다음에 하겠습니다." (O)

 

정말 방향을 바꿔야 한다면:

"소셜 로그인보다 결제 기능이 더 급합니다. 지금 하던 일을 멈추고 결제 기능으로 전환해도 될까요? 소셜 로그인은 다음 스프린트로 미루겠습니다." (O)

 

투명하게 설명하고, 트레이드오프를 명확히 하세요.

 

한 대표는 "2주 단위 스프린트"를 도입했습니다. 스프린트 중간에는 절대 우선순위를 바꾸지 않았습니다. 정말 급한 일이 생기면 다음 스프린트에 넣었습니다. 개발자들은 드디어 일을 끝까지 완성할 수 있었습니다.

습관 4: 다른 회사와 비교하기

왜 문제인가

"○○ 회사는 이 기능을 1주일 만에 만들었대요."

 

"△△ 스타트업은 개발자 3명으로 이만큼 했는데..."

 

"페이스북도 처음엔 대학생 몇 명이 만든 거잖아요."

 

이 말을 들을 때마다 개발자는 자존감이 떨어집니다.

 

왜 비교가 무의미한가:

• ○○ 회사는 그 기능만 만들었고, 다른 건 다 망가졌을 수도 있습니다
• △△ 스타트업은 기술 부채가 엄청나서 지금 고생하고 있을 수도 있습니다
• 페이스북 초기 코드는 지금 다 버려졌습니다

한 스타트업 대표는 매주 경쟁사를 언급하며 "저기는 벌써 저 기능이 있던데"라고 말했습니다. 개발자들은 사기가 떨어졌고, "어차피 우리는 못 따라가"라는 분위기가 됐습니다. 결국 핵심 개발자 2명이 동시에 퇴사했습니다.

대신 이렇게 하세요

벤치마킹은 건설적으로:

"○○ 회사의 이 기능이 좋던데, 우리도 비슷한 걸 만들 수 있을까요? 어느 정도 시간이 걸릴까요?" (O)

비교가 아니라 참고입니다.

 

개발자의 노력을 인정하세요:

"경쟁사가 빠르긴 하지만, 우리 제품이 품질은 더 좋은 것 같아요. 그동안 고생하셨습니다." (O)

 

어떤 대표는 개발팀 미팅 때마다 "이번 주 잘한 것 3가지"를 공유했습니다. 다른 회사와 비교하지 않고, 자기 팀의 성장에 집중했습니다. 개발자들의 만족도가 높아지고, 이직률이 낮아졌습니다.

습관 5: 문제를 해결책처럼 말하기

왜 문제인가

"로그인 화면에 카카오 버튼을 추가해주세요."

 

이건 해결책입니다. 진짜 문제가 뭔가요?

 

개발자가 물어봅니다. "왜 카카오 버튼이 필요한가요?"

 

대표: "사용자들이 로그인하기 귀찮아하니까요."

 

아하! 진짜 문제는 "로그인 과정이 불편하다"입니다.

 

이제 개발자는 다른 해결책도 제안할 수 있습니다:

• "로그인 없이 둘러보기 기능은 어떨까요?"
• "구글 로그인도 추가하면 어떨까요?"
• "비밀번호 없는 로그인은 어떨까요?"

어떤 스타트업은 대표가 "메인 화면에 팝업을 3개 띄워주세요"라고 했습니다. 개발자는 그대로 만들었습니다.

 

결과? 사용자들이 짜증내며 앱을 지웠습니다.

 

나중에 알고 보니 대표가 진짜 원한 건 "신규 기능을 더 많이 알리기"였습니다. 팝업이 아니라 온보딩 튜토리얼이나 툴팁이 더 나은 해결책이었을 겁니다.

대신 이렇게 하세요

문제를 먼저 설명하세요:

"사용자들이 회원가입 과정을 불편해합니다. 전환율이 30%밖에 안 돼요. 어떻게 개선할 수 있을까요?" (O)

 

개발자와 함께 해결책을 찾으세요:

"제가 생각한 방법은 소셜 로그인 추가인데, 더 좋은 방법이 있을까요?" (O)

 

개발자는 기술적으로 더 나은 방법을 알고 있을 수 있습니다.

 

한 대표는 매주 "문제 정의 미팅"을 했습니다. 해결책을 말하지 않고, 문제만 설명했습니다. 개발자들이 여러 해결책을 제안했고, 그중 최선을 선택했습니다. 결과적으로 더 창의적이고 효과적인 기능들이 나왔습니다.

보너스: 개발자가 좋아하는 대표의 습관

나쁜 습관만 이야기했으니, 좋은 습관도 말씀드리겠습니다.

1. 명확한 우선순위

"이번 달 목표는 A입니다. B와 C는 다음 달입니다."

 

개발자는 무엇에 집중해야 할지 명확히 압니다.

2. 충분한 시간

"언제까지 가능할까요?"

 

개발자: "2주요."

 

"그럼 3주로 잡겠습니다."

 

버퍼를 두는 대표를 개발자는 존경합니다.

3. 자율성 부여

"이 문제를 해결해주세요. 방법은 개발팀에서 정하셔도 됩니다."

 

마이크로매니징하지 않는 대표를 개발자는 좋아합니다.

4. 성과 인정

"이번 배포 수고하셨습니다. 덕분에 서버 속도가 30% 빨라졌어요."

 

구체적으로 성과를 인정해주는 대표를 개발자는 따릅니다.

5. 솔직한 소통

"솔직히 제가 기술을 잘 모릅니다. 설명해주시면 감사하겠습니다."

 

모르는 걸 인정하는 대표를 개발자는 신뢰합니다.

실제 사례: 개발자가 떠난 회사, 남은 회사

떠난 회사

한 스타트업은 1년에 개발자 5명이 퇴사했습니다.

 

대표는 이렇게 말했습니다:

• "요즘 개발자들은 참을성이 없어"
• "연봉을 더 올려줬어야 했나"
• "좋은 개발자를 뽑기가 너무 어려워"

하지만 진짜 문제는 대표의 습관이었습니다:

• 매일 우선순위를 바꿨습니다
• "간단한 거니까 오늘 해"를 입버릇처럼 했습니다
• 주말 근무를 당연시했습니다
• 다른 회사와 끊임없이 비교했습니다

결국 그 회사는 개발자를 구하지 못해 외주로 돌아갔습니다.

남은 회사

한 스타트업은 3년간 개발자 퇴사율이 0%였습니다.

 

대표는 이렇게 했습니다:

• 2주 스프린트를 지켰습니다
• "얼마나 걸릴까요?"라고 물었습니다
• 칼퇴근을 장려했습니다
• "우리 팀만의 속도"를 존중했습니다
• 문제를 설명하고 함께 해결책을 찾았습니다

그 회사는 좋은 개발자들이 추천으로 지원했습니다. "일하기 좋은 회사"라는 소문이 돌았기 때문입니다.

마지막 조언

대표님, 개발자는 여러분의 가장 중요한 자산입니다.

 

좋은 개발자 한 명을 잃는 것은:

• 6개월치 개발 일정이 밀리는 것
• 재채용에 3개월 이상 걸리는 것
• 기술 부채가 쌓이는 것
• 팀 사기가 떨어지는 것

입니다.

 

그리고 좋은 개발자가 떠나는 이유는 대부분 연봉이 아닙니다. 일하는 환경과 대표의 태도 때문입니다.

 

이 글에서 말씀드린 5가지 습관, 혹시 본인에게 해당하는 게 있나요?

 

있다면 오늘부터 고치세요. 늦지 않았습니다.

 

개발자를 존중하는 대표가 성공합니다.

 

기술을 몰라도 괜찮습니다. 하지만 사람을 존중하는 건 필수입니다.

---

이 글은 '모두의 CTO' 시리즈의 열 번째 글입니다. 이 글을 마지막으로 해당 시리즈를 마칩니다.