| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- leedcode
- DaleStudy
- 알고리즘
- 협업문화
- leetcode
- RxJS 오퍼레이터
- 자바스크립트 고차 함수 vs Observable
- 알고리즘스터디
- 달래스터디
- RxJS 멀티캐스팅
- React hooks 남용 사례
- React useEffect 안티패턴
- RxJS 변환 오퍼레이터
- contains duplicate
- RxJS 마블 다이어그램
- RxJS 에러 처리
- Climbing Stairs
- Observable vs Array
- RxJS 생성 오퍼레이터
- Blind75
- React 성능 최적화 방법
- React useMemo 사용법
- RxJS 함수형 프로그래밍
- useCallback 성능 최적화
- RxJS 결합 오퍼레이터
- 개발자커뮤니케이션
- 스쿼드조직
- useMemo 성능 최적화
- React 리렌더링 최적화
- React useCallback 사용법
- Today
- Total
수쿵의 IT월드
스쿼드에서 배운 커뮤니케이션 이야기 본문

안녕하세요. 오늘은 개발자가 아닌 스쿼드의 한 팀원으로서 느낀 커뮤니케이션 경험담을 나눠보려고 합니다.
이직 면접을 볼 때, 이런 질문을 받은 적이 있습니다.
"수경님은 협업을 할 때 문제가 있었던 적이 있나요?"
그때 저는 자신 있게 "없다"고 대답했지만, 지금은 주저 없이 "있다"고 대답할 수 있을 것 같습니다.
오늘 글에서는 제가 기능조직과 스쿼드조직에서 겪었던 커뮤니케이션 차이, 그리고 스쿼드에서 왜 Communication Miss가 생기는지, 이를 줄이기 위해 제가 시도한 방법을 공유해보겠습니다.
기능조직에서의 경험: Miss가 거의 없었던 이유
이전 회사는 전형적인 기능조직이었습니다.
기획자 → 개발자(나) → 프론트엔드 팀장 → 다시 기획자 로 이어지는 단순한 구조였죠.
- 기능을 어떻게 풀어낼지는 팀장과만 논의하면 되었고
- 불가능한 부분은 팀장과 해결책을 정한 뒤 기획자에게 통보하면 끝이었습니다.
경로가 짧다 보니 Miss가 생길 일이 거의 없었죠. 다만, 팀 간 사일로(silo, 벽 쳐놓고 따로 일하는 상태)가 강해진다는 단점이 있었습니다.
스쿼드에서의 경험: 공유는 많지만 Miss도 늘어난다
현재 회사는 스쿼드 조직입니다.
기획자, 디자이너, 백엔드, 프론트, 팀장이 모두 모여 같은 자리에서 의사결정을 합니다.
덕분에 투명하게 공유할 수 있고 함께 책임지는 구조가 만들어지지만, 동시에 새로운 문제가 생깁니다.
- 팀장이 비개발자이다 보니 기술적 맥락에서 이해 차이가 발생
- DB 구조나 API 설계 같은 구현 디테일까지 모두가 관여 → 대화가 길어지고 소모적이 됨
- 기획자와 개발자가 서로 다른 컨텍스트로 대화 → 아직 일어나지도 않은 가정을 두고 논쟁이 길어짐
예를 들어, 기획자가 이런 말을 할 때가 있습니다.
“추후에 이런 기능을 넣을 수도 있으니, 지금 DB 구조에 미리 추가해놓는 게 좋지 않을까요?”
사실 지금은 단순한 회원가입 기능만 필요하지만, 여기서 개발자들은 “미리 넣자 vs 필요할 때 바꾸자”로 나뉘게 되고, 불필요하게 오버엔지니어링으로 흘러가 버립니다.
결국 지금 당장 해결할 문제보다 미래의 가능성에 시간을 더 쓰면서 대화가 길어지고 Miss가 생기는 것이죠.
Communication Miss는 개인 문제가 아니다
저는 지난 6개월 동안 회의에서 반복적으로 나타나는 문제를 꾸준히 관찰해왔습니다.
때로는 회의 내용을 녹음해 ChatGPT에게 들려주며, 어디서 어긋나는지를 분석하기도 했습니다.
결론은 명확했습니다.
Communication Miss는 특정 개인의 문제가 아니라 팀 전체의 구조와 방식의 문제였습니다.
- 기능조직 → Miss는 적지만 사일로가 강해진다
- 스쿼드조직 → Miss는 많아지지만 투명성과 책임감이 커진다
결국 중요한 건 누가, 어떤 깊이까지, 어떤 맥락에서 이야기할지 팀 차원에서 합의와 습관을 만드는 일이라고 생각합니다.
제가 분석한 우리 팀의 문제점은 꽤 현실적이었습니다.
- 하나의 주제에서 벗어나 다른 주제로 쉽게 샌다
- 회의 주체자가 책임 있게 끌고 가지 못한다
- 같은 말을 해도 서로 다른 컨텍스트로 이해해 불필요한 논쟁이 길어진다
Miss를 줄이기 위해 해본 시도들
저는 이런 Miss를 줄이기 위해 몇 가지 방법들을 시도하고 있습니다.
- 대화 주제 환기시키기
- “지금 논의 주제는 회원가입 방식이었는데, OOO님은 A안을, OOO님은 B안을 선호하신다는 거죠?”
- 문맥 맞추기
- “OOO님의 말씀은 결국 DB에 저장하자는 건데, 팀장님 말씀도 같은 의미 아닌가요?”
- 깊은 기술 질문은 따로 하기
- 전체 회의가 아니라 백엔드 개발자에게 직접 물어보기
- 대안 제시하기
- 무조건 “안 된다” 대신 A안/B안을 같이 준비해 선택할 수 있도록 하기
- 공개 자리에서 편들지 않기
- “OOO님 말씀이 맞아요(X)” 대신 “각자 이런 장점이 있는 것 같아요(O)”
- 헛도는 대화 환기하기
- “제가 이해한 게 맞는지 확인 부탁드립니다”
- 감정 싸움으로 흐를 때 정리하기
- “A안을 고집하시는 이유가 있을까요?” → 근거 확인 후, 필요하면 투표
작은 습관이지만 이런 시도 덕분에 회의가 한결 매끄러워졌습니다.
스쿼드에서는 커뮤니케이션 Miss가 자주 생깁니다.
솔직히 말하면 회의가 길어지고, 불필요한 논쟁으로 지칠 때도 있습니다.
하지만 동시에, 기능조직에서는 느끼기 어려웠던 투명성과 책임감, 그리고 서비스에 대한 애정을 더 크게 느낍니다.
모두가 같은 목표를 바라보면서 치열하게 이야기하다 보니, 갈등 속에서도 더 나은 답을 찾아가는 보람이 있거든요.
그래서 저는 다음 회사를 고를 때도, 조금 힘들더라도 스쿼드 조직을 가진 곳을 선택하고 싶습니다.
Communication Miss를 줄이는 건 어렵지만, 그 과정을 통해 성장하는 즐거움은 분명 크니까요.