개발자 소프트 스킬이 과소평가되는 이유

코딩만 잘하면 되는 줄 알았다

3년 차까지 나는 "개발자는 코드로 말한다"고 진심으로 믿었다. 회의에서 말을 잘 못해도, 문서화를 안 해도, 코드 퀄리티가 좋으면 인정받을 수 있다고 생각했다. 실제로 코딩 실력 하나로 평가받는 기간이 있긴 했다.

근데 3년 차를 넘기면서 상황이 달라졌다. 혼자 짤 수 있는 코드의 범위가 줄어들고, 협업이 필수가 됐다. API 스펙 논의, 디자인 리뷰, PM과의 요구사항 정리, QA 팀과의 소통. 하루에 코드 짜는 시간보다 대화하는 시간이 더 많아졌다.

내가 겪은 협업 실패

한번은 백엔드 팀과 API 연동을 했는데, 서로 다른 스펙으로 개발한 적이 있다. 나는 Slack에서 "날짜 포맷 ISO 8601로 하죠"라고 썼고, 상대방이 "네"라고 답했다. 근데 나는 2026-05-22T09:00:00Z를 기대했고, 상대방은 2026-05-22만 보낸 거다. 둘 다 ISO 8601은 맞는데, 구체적인 포맷을 합의 안 한 거다.

이 사소한 커뮤니케이션 실수 때문에 양쪽 다 코드를 수정해야 했고, 일정이 이틀 밀렸다. 기술적 문제가 아니라 대화의 문제였다.

(이 사건 이후로 API 스펙은 항상 문서로 남기기 시작했다. 구두 합의는 의미가 없더라.)

소프트 스킬이 과소평가되는 이유

개발자 커뮤니티에서 소프트 스킬 이야기를 하면 반응이 미지근하다. "그건 PM이 할 일", "나는 코드나 잘 짜면 된다"는 의견이 많다. 이해는 된다. 코딩이 측정 가능하고 즉각적인 결과가 나오니까. 소프트 스킬은 측정하기 어렵다. "커뮤니케이션 능력이 20% 향상됐다" 같은 지표는 없다.

근데 실제로 프로젝트가 실패하는 원인을 보면, 기술적 문제보다 커뮤니케이션 문제가 많다. 요구사항 오해, 팀 간 의견 충돌, 일정 착오. 전부 대화의 문제다.

내가 부족했던 것들

피드백 주는 법을 몰랐다. 코드 리뷰에서 "이거 왜 이렇게 짰어요?"라고 쓰면 상대방이 방어적이 된다. "이 부분을 이렇게 바꾸면 성능이 개선될 것 같은데, 어떻게 생각하세요?"로 바꾸니 반응이 완전히 달라졌다.

회의에서 반대 의견을 내는 법도 몰랐다. "그건 아닌 것 같은데요"라고 하면 분위기가 싸해진다. "그 접근법의 장점은 이해되는데, 이런 경우에는 문제가 될 수 있지 않을까요?"라고 하면 같은 내용인데 건설적인 토론이 된다.

사소해 보이지만 이런 차이가 쌓이면 협업의 질이 완전히 달라진다.

소프트 스킬도 기술이다

코딩을 배울 때처럼 소프트 스킬도 의식적으로 연습해야 늘어난다. 나는 1:1 미팅 후에 "이 대화에서 뭘 잘했고 뭘 못했나"를 돌아보는 습관을 만들었다. 처음엔 어색했는데, 6개월쯤 하니까 자연스러워졌다.

글쓰기도 마찬가지다. 기술 문서, PR 설명, Slack 메시지. 다 글쓰기다. 명확하게 쓰는 연습을 하면 커뮤니케이션 전반이 좋아진다.

솔직히 아직도 부족한 부분이 많다. 갈등 상황에서 감정을 잘 다루지 못하는 게 큰 과제다. 근데 적어도 "소프트 스킬은 개발자한테 불필요하다"는 생각은 완전히 바뀌었다.

시니어가 될수록 코딩보다 소통에 쓰는 시간이 늘어난다. 이걸 일찍 깨달으면 좋겠는데, 대부분 나처럼 삽질해봐야 깨닫는다.