TO. 협업이 조금은 망설여지고 두려운 동료에게-015
프롤로그: 첫 출근, 그리고 첫 미팅
입사 첫날, 지수는 떨리는 마음으로 회사 문을 열었다.
3개월간의 포트폴리오 준비, 수십 번의 면접 끝에 얻은 이 자리.
"드디어 진짜 디자이너가 됐어."
오리엔테이션을 마치고 자리에 앉자마자, 팀장이 다가왔다.
"지수님, 오늘 오후 2시에 킥오프 미팅 있어요. 신규 프로젝트인데, 개발팀, 기획팀이랑 같이 진행해요. 준비되셨죠?"
'킥오프? 개발팀? 기획팀?'
학교 프로젝트에서는 디자이너끼리만 작업했는데, 이제는 다른 팀과 함께 일해야 한다는 게 실감났다.
회의실에 들어서자 낯선 얼굴들이 가득했다.
개발자 3명, 기획자 2명, 그리고 디자이너는 팀장과 지수 둘뿐이었다.
"자, 그럼 시작할게요. 이번 프로젝트는..."
기획자가 발표를 시작했지만, 지수의 머릿속은 복잡했다.
'API가 뭐지? 프론트엔드는? 백엔드는?'
학교에서 한 번도 들어보지 못한 용어들이 쏟아졌다.
미팅이 끝나고, 지수에게 첫 태스크가 떨어졌다.
"회원가입 플로우 UI 디자인해주세요. 개발팀과 싱크 맞춰서요."
지수는 밤을 새워 정성스럽게 디자인했다.
깔끔한 레이아웃, 세련된 컬러, 트렌디한 타이포그래피.
"이 정도면 괜찮을 거야."
다음 날, 개발자 민준에게 디자인을 전달했다.
"민준님, 디자인 완성했어요!"
민준이 피그마 파일을 열어봤다. 그리고 잠시 침묵이 흘렀다.
"지수님, 이거... 컴포넌트 분리가 안 돼 있네요. 그리고 반응형은 어떻게 되는 거예요? 모바일 기준이 뭐죠?"
"네? 컴포넌트요? 반응형은... 그냥 비율 맞춰서 하시면 안 돼요?"
민준이 난감한 표정을 지었다.
"음... 그게 그렇게 간단한 게 아니에요. 디자인 시스템 파일 보셨어요?"
지수는 당황했다. 무슨 말인지 하나도 이해가 안 됐다.
그날 밤, 지수는 혼자 남아서 울었다.
"나는 디자인을 열심히 했는데... 왜 안 된다는 거지?"
일주일 후, 이번엔 기획자 수진과의 미팅이었다.
"지수님, 이 버튼 위치 좀 바꿔주세요. 여기가 사용자 동선상 더 자연스러워요."
지수는 내심 불만이었다.
'나는 디자이너인데, 왜 기획자가 디자인까지 간섭하지?'
하지만 선배 디자이너가 조용히 귀띔했다.
"지수야, 기획자는 사용자 플로우를 설계하는 사람이야. 그 사람 말에도 일리가 있을 수 있어. 한번 들어보고, 네 생각도 논리적으로 설명해봐."
지수는 다시 수진을 찾아갔다.
"수진님, 제가 이 위치로 배치한 이유는요..."
대화를 나누다 보니, 서로의 관점이 달랐을 뿐이었다.
수진은 데이터 기반으로 생각했고, 지수는 시각적 균형으로 접근했다.
두 가지를 함께 고려하니, 더 나은 해결책이 보였다.
"아, 그렇게 생각하신 거였구나. 그럼 이렇게 하면 어떨까요?"
그날, 지수는 깨달았다.
협업은 '내 방식을 관철시키는 것'이 아니라 '함께 더 나은 답을 찾는 것'이라는 걸.
여전히 개발팀과의 협업은 어려웠다.
피그마에서는 완벽해 보이던 디자인이 실제 구현되면 미묘하게 달랐다.
여백이 어긋나고, 폰트가 다르고, 색상도 조금씩 틀렸다.
"민준님, 이거 왜 디자인이랑 다르게 나왔어요?"
민준이 피곤한 표정으로 답했다.
"지수님, 여백 값을 명확하게 안 주셨잖아요. 그냥 '적당히'라고만 써있어서 제가 임의로 한 거예요."
지수는 억울했다.
'피그마에 다 있는데 왜 안 보는 거지?'
그날 점심시간, 선배가 조언했다.
"개발자는 디자이너만큼 디자인 파일을 자세히 보지 않아.
시간도 없고, 그게 그들의 주 업무가 아니거든. 전달할 때 스펙 시트를 따로 만들어주면 훨씬 수월해."
지수는 다음 작업부터 바꿨다.
여백 값을 명확히 표기했다 (16px, 24px 등)
색상 코드를 정리했다 (#FF5733)
폰트 사이즈와 굵기를 명시했다 (16pt, Medium)
인터랙션 설명을 추가했다 (클릭 시 0.3초 페이드 효과)
그리고 민준에게 물어봤다.
"민준님, 이렇게 하면 보기 편하세요? 더 필요한 정보 있으면 말씀해주세요."
민준의 표정이 밝아졌다.
"오, 훨씬 좋네요! 이러면 작업하기 편해요."
그날부터 둘의 협업은 한결 수월해졌다.
프로젝트가 중반에 접어들었을 때, PM(프로덕트 매니저) 재현이 회의를 소집했다.
"이번 스프린트에서 이 기능은 빼기로 했어요. 우선순위가 낮아서요."
지수가 만든 화면 3개가 통째로 사라지는 순간이었다.
일주일 동안 밤새워 작업한 것들인데...
"재현님, 이거 왜 빼는 거예요? 사용자한테 꼭 필요한 기능인데요."
재현이 데이터를 보여줬다.
"지수님, 여기 보세요. 이 기능은 전체 사용자의 5%만 쓸 것 같아요. 그런데 개발 공수는 2주나 걸려요. 지금 우리 리소스로는 이게 더 중요해요."
지수는 속상했지만, 재현의 설명을 듣고 나니 이해가 됐다.
디자이너는 '사용자 경험'을 중심으로 생각하지만,
PM은 '비즈니스 임팩트'와 '리소스 효율'도 함께 봐야 한다는 것을.
"아... 그렇군요. 그럼 이 기능은 나중에 추가하는 걸로 하고, 지금은 핵심만 집중하는 게 맞겠네요."
재현이 고마워하며 말했다.
"이해해줘서 고마워요. 대신 다음 스프린트에서는 꼭 넣을게요."
런칭을 한 달 앞두고, 마케팅팀 소영이 요청을 했다.
"지수님, 메인 화면에 프로모션 배너 크게 넣어주세요. 이번 캠페인 중요해요."
지수는 난감했다.
디자인 시스템상 그 위치에 배너가 들어가면 전체 균형이 깨졌다.
무엇보다 사용자 경험을 해칠 것 같았다.
"소영님, 배너를 저기 넣으면 사용자가 핵심 기능을 못 찾을 것 같아요. 다른 위치는 안 될까요?"
"안 돼요. 광고 효과는 메인 화면이 최고거든요. 다른 데 넣으면 클릭률이 떨어져요."
둘은 팽팽히 맞섰다.
결국 팀장이 중재에 나섰다.
"둘 다 일리가 있어. 지수야, UX도 중요하지만 비즈니스도 중요해. 소영님, 사용자 경험 해치면 장기적으로 손해야. 절충안을 찾아보자."
결국 배너는 넣되, 크기를 줄이고 닫기 버튼을 추가했다.
완벽하진 않았지만, 둘 다 수긍할 수 있는 선이었다.
지수는 그날 배웠다.
"회사에서는 완벽한 디자인보다, 모두가 받아들일 수 있는 합리적 디자인이 필요하다는 것을."
입사 6개월,지수는 이제 제법 협업에 익숙해졌다.
그 과정에서 스스로 정리한 협업의 원칙들이 있었다.
원칙 1: 먼저 경청하고, 이해하려 노력한다
예전엔 내 디자인을 설명하기 바빴다면,
이제는 상대방의 말을 먼저 듣는다.
개발자가 왜 "안 된다"고 하는지,
기획자가 왜 그 위치를 고집하는지,
이유를 이해하면 해결책이 보인다.
원칙 2: 내 전문성을 논리적으로 설명한다
"이게 더 예뻐요"가 아니라
"이 레이아웃이 사용자 시선 흐름상 더 자연스럽고, 클릭률도 15% 높습니다"라고 말한다.
데이터와 논리로 뒷받침하면, 설득력이 생긴다.
원칙 3: 상대의 언어로 말한다
개발자에게는 개발 용어로 설명한다.
"이 컴포넌트는 재사용 가능하게 설계했어요."
기획자에게는 비즈니스 관점으로 설명한다.
"이 디자인이 전환율을 높일 거예요."
상대가 이해할 수 있는 언어로 말하면, 소통이 훨씬 쉬워진다.
원칙 4: 작은 것부터 자주 공유한다
완성될 때까지 기다리지 않는다.
중간 중간 진행 상황을 공유하고 피드백을 받는다.
"이 방향으로 가는 게 맞나요?"
초반에 방향을 맞추면, 나중에 큰 수정을 피할 수 있다.
원칙 5: 질문을 두려워하지 않는다
모르는 건 솔직히 물어본다.
"API가 정확히 뭐예요?"
"사용자 플로우를 다시 설명해주실 수 있나요?"
신입이라 모르는 게 당연하다. 모르는 척하는 게 더 위험하다.
원칙 6: 감사와 존중을 표현한다
"민준님, 어려운 작업인데 빠르게 해주셔서 감사해요."
"수진님, 그 관점은 생각 못 했는데 정말 좋네요."
작은 감사 표현이 관계를 부드럽게 만든다.
드디어 런칭 날이 왔다.
3개월간의 긴 여정 끝에, 서비스가 세상에 나왔다.
회의실에 모인 팀원들.
개발자 민준, 기획자 수진, PM 재현, 마케터 소영, 그리고 디자이너 지수.
모니터에는 실시간 사용자 수가 올라가고 있었다.
100명, 500명, 1000명...
"우와, 대박!"
팀원들이 환호했다. 지수도 눈물이 날 것 같았다.
처음엔 서로 부딪히고, 의견 충돌도 많았지만,
결국 함께 만들어낸 결과물이었다.
런칭 후 회식 자리에서, 민준이 말했다.
"지수님, 처음엔 어떻게 될까 싶었는데, 정말 많이 성장했어요. 특히 개발 관점까지 고려해서 디자인해주셔서 작업하기 편했어요."
수진도 거들었다.
"맞아요. 지수님이 사용자 경험에 대해 논리적으로 설명해주셔서 설득력 있었어요. 덕분에 더 좋은 서비스 만들었어요."
지수는 뿌듯했다.
협업이 처음엔 두렵고 어려웠지만,
이제는 혼자서는 절대 만들 수 없는 것을 함께 만드는 기쁨을 알게 됐다.
프로젝트가 끝나고, 팀장이 지수를 불렀다.
"지수야, 첫 프로젝트 정말 수고 많았어. 소감이 어때?"
"처음엔 협업이 너무 어려웠어요. 다른 팀 사람들이 이해가 안 되고, 제 디자인을 왜 이해 못 하는지 답답했어요. 하지만 지금은... 협업이 디자인의 일부라는 걸 알았어요."
팀장이 고개를 끄덕였다.
"맞아. 좋은 디자이너는 디자인만 잘하는 사람이 아니야. 다양한 사람들과 소통하고, 함께 문제를 해결하는 사람이지. 네가 그걸 배운 것 같아 뿌듯하다."
"팀장님, 협업 잘하려면 어떻게 해야 해요?"
팀장이 웃으며 답했다.
"첫째, 겸손해야 해. 내가 모든 걸 안다고 생각하지 마. 다른 팀에서 배울 게 많아.
둘째, 호기심을 가져. 개발이 어떻게 되는지, 기획이 뭔지 궁금해해. 이해하면 협업이 쉬워져.
셋째, 유연해야 해. 내 디자인이 항상 100% 구현되진 않아. 상황에 맞춰 조정할 줄 알아야 해.
넷째, 적극적으로 소통해. 혼자 끙끙 앓지 말고, 물어보고, 의견 나누고, 같이 고민해.
다섯째, 존중해야 해. 모든 직군이 각자의 전문성이 있어. 그걸 인정하고 존중해줘."
1년이 지났다.
지수는 이제 신입이 아니었다. 여러 프로젝트를 거쳤고, 후배도 생겼다.
새로 들어온 신입 디자이너 하린이 불안한 얼굴로 다가왔다.
"선배님, 내일 개발팀이랑 첫 미팅인데 너무 떨려요. 무슨 말 해야 할지 모르겠어요."
지수는 1년 전 자신의 모습이 떠올랐다.
"하린아, 괜찮아. 처음엔 다 그래. 내가 팁 좀 알려줄게."
지수는 자신이 배운 것들을 하나하나 알려줬다.
어떻게 디자인을 전달해야 하는지,
개발자와 어떻게 대화해야 하는지,
의견이 다를 때 어떻게 조율해야 하는지.
"그리고 하린아, 제일 중요한 거 하나 알려줄게.
협업에서 제일 중요한 건 완벽한 디자인이 아니라, 함께 만드는 과정이야.
혼자 완벽하게 하려고 하지 말고, 다른 팀과 함께 더 나은 답을 찾아가.
그 과정에서 네가 진짜 성장할 거야."
하린의 눈빛이 조금 밝아졌다.
"감사해요, 선배님. 그 말 들으니까 용기가 나요."
지수는 창밖을 바라보며 생각했다.
1년 전 처음 회의실에 들어갔을 때의 그 떨림.
아무것도 모르고, 두렵고, 실수투성이었던 그때.
하지만 지금은 다르다.
협업은 더 이상 두렵지 않다. 오히려 즐겁다.
혼자서는 절대 만들 수 없는 것들을 팀과 함께 만들어내는 그 순간이 좋다.
개발자가 "이거 멋지네요!"라고 말할 때,
기획자가 "이 디자인 덕분에 사용성이 좋아졌어요"라고 할 때,
PM이 "지수님 덕분에 프로젝트가 잘 마무리됐어요"라고 할 때,
그 순간들이 지수를 더 나은 디자이너로 만들었다.
협업은 완벽함을 추구하는 게 아니다.
함께 더 나은 답을 찾아가는 여정이다.
그리고 그 여정 속에서,
우리는 단순한 디자이너를 넘어
진정한 팀플레이어로 성장한다.
협업이 두렵나요?
다른 팀 사람들과 대화하기가 어렵나요?
괜찮습니다. 모두가 처음엔 그랬습니다.
중요한 건 완벽하게 시작하는 게 아니라,
조금씩 배워가는 것입니다.
실수해도 괜찮습니다.
모르는 걸 물어봐도 괜찮습니다.
의견이 다를 수도 있습니다.
하지만 그 모든 과정 속에서,
당신은 더 나은 디자이너로 성장합니다.
혼자가 아니라 함께,
완벽이 아니라 과정,
경쟁이 아니라 협력.
그것이 협업의 본질입니다.
당신의 협업 여정을 응원합니다.
입자 드림
#신입디자이너 #협업 #팀워크 #성장 #보마흐