디자이너와 개발자 사이의 기획자, 중재자가 되는 법

09 Dec, 2025
- 스프린트

오늘도 통역 중

오전 10시. 화면 정의 회의.

왼쪽엔 디자이너 수진님. 오른쪽엔 개발자 민수님. 나는 가운데.

수진님: “이 버튼은 사용자가 누를 때 약간 바운스되면서 피드백이…” 민수님: “그거 애니메이션 라이브러리 새로 써야 하는데요.”

시작도 안 했는데 벌써 삐걱.

나: “일단 스펙부터 정리할게요.”

피그마 켜고 화면 공유. 지라 티켓 열고. 노션에 정리 시작.

5년 차 되니까 안다. 이런 상황에서 누가 옳고 그른 게 아니라는 걸. 둘 다 각자의 영역에서 최선을 고민하는 거다.

문제는 언어가 다르다는 것.

디자이너의 언어

수진님은 사용자 경험을 생각한다.

“이 화면에서 저 화면으로 넘어갈 때, 자연스러운 트랜지션이 있어야 사용자가 맥락을 이해해요.”

맞는 말이다. 인터랙션은 중요하다.

하지만 개발자 입장에선 ‘자연스러운 트랜지션’이 뭔지 모른다. 300ms? 500ms? fade? slide? 라이브러리는? CSS로 가능한지?

이럴 때 내가 하는 것.

레퍼런스 찾기 “인스타그램 스토리 넘기는 느낌이요? 아니면 토스 화면 전환?”
수치로 변환 “300ms 정도면 될까요? 민수님, 이 정도면 네이티브로 가능하죠?”
우선순위 정리 “이번 스프린트엔 기본 전환만. 다음에 고도화.”

디자이너의 비전을 개발 가능한 스펙으로 바꾸는 작업.

통역이다. 정확히.

수진님: “아, 그렇게 말하면 되는구나.” 나: “네. 다음엔 바로 이렇게 얘기해주세요.”

회의록에 적는다.

화면 전환: slide 애니메이션, 300ms, ease-in-out
레퍼런스: 토스 메인 화면 전환
우선순위: P1 (이번 스프린트)

개발자의 언어

민수님은 기술 구현을 생각한다.

“이 기능 API 새로 만들어야 하는데, 2주 걸려요.”

디자이너는 당황한다. 화면 하나 추가인데 왜 2주?

이럴 때도 통역.

나: “수진님, 이 화면에 실시간 업데이트 필요하잖아요. 그러려면 웹소켓 연결이 필요해서 백엔드 작업이 커요.”

수진님: “아… 그럼 일단 새로고침 버튼으로 시작하면 안 돼요?”

민수님: “그건 하루면 됩니다.”

해결.

개발자가 ‘안 된다’고 할 때, 진짜 물리적으로 불가능한 게 아니다. 시간/리소스/기술 부채를 고려한 판단이다.

이걸 디자이너에게 설명하려면:

기술 용어를 풀어서 “API는 서버랑 대화하는 거예요. 지금은 대화 통로가 없어서 새로 만들어야 해요.”
대안 제시 “실시간은 나중에. 일단 수동 새로고침으로 MVP 만들죠.”
트레이드오프 설명 “이거 지금 하면 다른 기능 2개는 밀려요.”

디자이너: “그럼 우선순위 조정해야겠네요.” 나: “네. 대표님께 공유드릴게요.”

지라 티켓에 적는다.

[Backend] 실시간 업데이트 API 구축: 10 story points, Sprint+2
[Frontend] 수동 새로고침 버튼: 2 story points, 현재 Sprint
의존성: 백엔드 완료 후 프론트 고도화 가능

중재의 기술

사실 이 일이 제일 어렵다.

둘 다 프로페셔널이다. 각자 영역에서 최선을 추구한다. 하지만 목표가 다르면 충돌한다.

디자이너: 최고의 사용자 경험 개발자: 안정적이고 유지보수 가능한 코드

둘 다 맞다. 그래서 더 어렵다.

지난주 실제 상황.

수진님: “이 페이지, 사용자별로 맞춤 레이아웃 보여주면 좋겠어요.” 민수님: “그거 개인화 알고리즘 개발해야 해요. 3개월 프로젝트인데요.”

둘 다 나를 본다.

나: “좋아요. 일단 목표부터 정리하죠.”

화이트보드에 쓴다.

문제: 사용자가 원하는 콘텐츠 찾기 어려움
목표: 콘텐츠 발견율 30% 증가
제약: 현재 스프린트 2주

나: “개인화가 목표인가요, 콘텐츠 발견이 목표인가요?”

수진님: “콘텐츠 발견이요.”

나: “그럼 대안이 있어요. 카테고리 필터 강화하면?”

민수님: “그건 이번 스프린트에 가능해요.”

수진님: “음… 일단 그걸로 데이터 보고 개인화는 다음 분기에?”

나: “좋아요. 민수님 개발하시고, 수진님은 필터 UI 디자인. 2주 후 릴리즈하고 데이터 보죠.”

중재의 핵심은 이거다.

목표로 돌아가기 무엇을 해결하려는가? 방법은 여러 개다.
제약 인정하기 시간, 인력, 기술. 현실을 본다.
대안 제시하기 한 방법이 안 되면 다른 방법. 항상 플랜 B.
단계 나누기 지금 할 것, 나중 할 것. MVP 사고.

컨플루언스에 정리한다.

콘텐츠 발견율 개선 방안

Phase 1: 카테고리 필터 강화 (2주)
Phase 2: 데이터 수집 및 분석 (4주)
Phase 3: 개인화 알고리즘 검토 (분기 단위)

두 사람 다 고개 끄덕인다.

언어 배우기

5년 전엔 이게 안 됐다.

디자이너가 “인터랙션”이라고 하면 무슨 소린지 몰랐다. 개발자가 “API”라고 하면 긴장했다.

지금은 안다. 둘 다 배웠으니까.

디자인 배우는 법:

피그마 직접 써본다. 기초 기능은 안다.
UI/UX 기초 책 읽는다. “Don’t Make Me Think” 같은 거.
디자인 시스템 공부한다. Atomic Design, 8pt grid.
레퍼런스 많이 본다. 좋은 앱 쓸 때 화면 캡처.

개발 배우는 법:

기술 용어 정리한다. API, DB, 서버, 클라이언트.
개발자 회의 듣는다. 모르면 나중에 물어본다.
간단한 코드 읽어본다. HTML, CSS 정도는.
SQL 배운다. 데이터 직접 뽑을 수 있으면 협업 빨라진다.

완벽하게 알 필요 없다. 디자이너처럼 디자인할 순 없다. 개발자처럼 코딩할 순 없다.

하지만 그들의 언어를 이해하면 된다. 통역하려면 양쪽 언어를 알아야 한다.

요즘은 수진님이 “이거 API 호출 몇 번이에요?”라고 물어본다. 민수님은 “사용자 플로우상 여기서 막히는데요?”라고 말한다.

서로 언어를 배우고 있다. 내가 계속 통역해줘서.

좋은 신호다.

회의록이 답이다

중재의 증거는 문서다.

말로만 하면 나중에 “그런 적 없는데요?”가 나온다.

그래서 나는 회의 때마다 적는다.

컨플루언스에 템플릿 만들어뒀다.

화면 정의 회의록

일시: 2024.01.15 10:00
참석: 수진(디자인), 민수(개발), 나(기획)
안건: 홈 화면 개편

결정 사항

화면 전환 애니메이션: slide, 300ms
실시간 업데이트: Phase 2로 연기
카테고리 필터: 이번 스프린트

액션 아이템

수진: 필터 UI 디자인 (01.17까지)
민수: 필터 API 개발 (01.22까지)
나: 대표님 보고 (01.16)

이슈/리스크

실시간 업데이트 딜레이로 사용자 피드백 우려
대안: 수동 새로고침 버튼 명확히 노출

이렇게 적어두면:

누가 뭘 하기로 했는지 명확
나중에 왜 이렇게 결정했는지 추적 가능
대표님한테 보고할 때 근거 자료

말싸움 날 때 회의록 꺼내면 끝난다.

“여기 보세요. 그때 이렇게 합의했어요.”

문서는 기획자의 무기다.

감정 관리

사실 제일 어려운 건 이거다.

디자이너도 사람. 개발자도 사람. 나도 사람.

수진님이 열심히 만든 디자인, 민수님이 “이거 구현 힘든데요”라고 하면 기분 상한다.

민수님이 고민해서 짠 코드, 수진님이 “근데 이거 왜 이렇게 느려요?”라고 하면 짜증난다.

나는 그 사이에서 감정까지 조율한다.

수진님한테: “민수님이 안 된다는 게 아니라, 시간이 더 필요하다는 거예요. 기술적으로 복잡해서.”

민수님한테: “수진님이 완벽주의라서 그래요. 사용자 경험 진짜 중요하게 생각하시거든요. 최대한 맞춰드리면 나중에 QA 때 편해요.”

양쪽 다 이해시킨다.

그리고 내 감정도 관리한다.

“왜 나만 힘들지?” 생각하면 끝이다. 중재는 원래 힘들다. 양쪽 다 만족시킬 순 없다.

목표는 최선의 타협.

완벽한 디자인도, 완벽한 코드도 아니다. 주어진 시간에 최선의 결과.

그걸 받아들이면 조금 편하다.

신뢰 쌓기

중재가 되려면 신뢰가 필요하다.

수진님과 민수님이 나를 믿어야 내 말을 듣는다.

신뢰는 어떻게 쌓나?

약속 지키기 “내일까지 정리해드릴게요.” 하면 정말 한다.
양쪽 이해하기 디자이너 편도, 개발자 편도 아니다. 프로덕트 편.
솔직하기 “이거 제가 잘 모르겠어요. 같이 알아봐요.” 괜찮다.
인정하기 “수진님 디자인 정말 좋았어요.” “민수님 코드 리뷰 감사합니다.” 진심으로.
실수 인정하기 “제가 스펙을 명확히 안 적어서 혼선 있었어요. 죄송해요.” 당당하게.

시간 걸린다. 1년 정도?

지금은 수진님도 민수님도 내가 중간에서 정리하면 따라온다. 내가 “이게 최선”이라고 하면 믿는다.

그 신뢰가 있어서 중재가 가능하다.

실패 사례

잘될 때만 있는 건 아니다.

지난달에 망한 적 있다.

새 기능 기획. 디자이너는 복잡한 인터랙션 원했고, 개발자는 단순하게 하자고 했다.

나는 디자이너 편을 들었다. “사용자 경험이 중요하니까.”

결과: 개발 일정 2주 초과. 버그 투성이. 결국 롤백.

민수님이 그랬다. “진짜님, 그때 제 말 들으셨어야죠.”

맞다. 내가 기술적 제약을 무시했다.

교훈:

한쪽 편 들면 안 된다.
기술 제약은 진짜 제약이다.
개발자가 “힘들다”고 하면 정말 힘든 거다.

다음부터는 양쪽 의견 다 듣고 천천히 결정한다.

실패도 배움이다.

도구 활용

중재를 돕는 도구들.

Figma: 디자이너랑 같은 화면 본다. Jira: 개발자랑 같은 일정 본다. Confluence: 모두가 같은 문서 본다. Slack: 비동기 소통. Zoom: 얼굴 보며 회의.

특히 Figma는 중요하다.

“이 버튼이요”가 아니라 Figma 링크 공유하면 오해가 없다.

“이 티켓이요”가 아니라 Jira 티켓 번호 말하면 명확하다.

도구는 언어를 통일시킨다.

그리고 Notion.

나만의 중재 가이드를 정리해뒀다.

디자이너-개발자 중재 체크리스트

회의 전에 이거 보면 덜 헤맨다.

지금도 배우는 중

5년 차지만 아직도 어렵다.

어제도 회의에서 막혔다.

수진님: “이 화면 구조 바꿔야 해요.” 민수님: “지금 바꾸면 DB 마이그레이션이…”

나: “음… 일단… 데이터 보고…?”

명확한 답이 안 나왔다. 결국 CTO님께 여쭤봤다.

아직 모르는 게 많다.

하지만 계속 배운다.

디자인 강의 듣는다. 개발 세미나 간다. PM 커뮤니티에서 물어본다.

“중재 잘하는 법” 같은 글 찾아 읽는다.

다른 기획자들은 어떻게 하는지.

그리고 매번 회고한다.

“오늘 회의는 왜 잘 됐지?” “저번엔 왜 안 됐지?”

반복하면 조금씩 는다.

보람

힘들지만 보람도 있다.

지난주 릴리즈.

수진님 디자인에 민수님 개발. 내가 중간에서 조율했다.

출시 후 사용자 반응 좋았다. 리뷰 평점 4.7.

수진님: “우리 잘했네요!” 민수님: “다음엔 더 잘할 수 있을 것 같아요.”

둘이 하이파이브.

나도 기분 좋다.

이게 중재의 보람이다.

혼자서는 못 만드는 걸 함께 만든다. 그 사이에 내가 있다.

다리 역할.

보이진 않지만 없으면 안 되는.

오늘도 회의 3개. 내일도 통역 중이다. 피곤하지만 할 만하다.