전술적 공감 (Tactical Empathy)

1. 전술적 공감 (Tactical Empathy) + 내가 원하는 바 표현하기

핵심 개념:

  • 상대의 감정을 먼저 인정하고 신뢰를 구축한 후, 내가 원하는 바를 자연스럽게 제시.

  • 상대가 중요하게 신경 쓰는 핵심 요소를 캐치하는 것이 중요함.

  • 감정을 인정한 뒤, 내 입장을 효과적으로 전달하여 협상을 유리하게 이끌어야 함.

실무 간단 사례: PM이 비현실적인 일정으로 프로젝트를 밀어붙이는 경우 👉 감정을 인정하며 협상 후, 내가 원하는 대안 제시

💡 구체적 예시:

  1. PM: "이 기능을 2주 안에 출시해야 합니다."

  2. 개발자:

    • "(전술적 공감) 일정이 굉장히 빡빡하게 들리네요. 이 기능이 중요한 이유가 있을까요?" (핵심 요소 파악)

  3. PM: "마케팅 일정이 잡혀 있어서 광고와 함께 나가야 해요." (핵심 요소: 마케팅 일정)

  4. 개발자:

    • "(전술적 공감) 마케팅 일정과 개발이 맞물려 있어서 큰 부담이 되시겠네요." (상대 입장 공감)

    • "(내 입장 표현) 하지만 이 일정대로 진행하면 품질에 문제가 생길 가능성이 높아요. 우리가 핵심 기능을 먼저 제공하고, 부가 기능을 후속 업데이트로 진행하면 일정이 맞춰질까요?" (현실적인 대안 제시)

  5. PM: "그 방법이라면 가능할 수도 있겠네요!"

핵심 포인트:

  • 전술적 공감: 상대의 감정과 고민을 먼저 인정하여 신뢰를 쌓음.

  • 내 입장 표현: 일방적인 거절이 아니라, 현실적인 한계를 설명함.

  • 대안 제시: 상대가 받아들이기 쉬운 방식으로 해결책을 제공.

결과:

  • 상대방의 방어적인 태도를 줄이고 협상 가능성을 높임.

  • 내가 원하는 방향으로 자연스럽게 대화의 흐름을 유도.

  • 서로 윈윈할 수 있는 현실적인 해결책을 찾음. 🚀


디자인팀과의 협업: Figma Token 자동화 도입 과정

🚀 배경: 디자인 시스템 자동화의 필요성

개발과 디자인의 협업에서 가장 반복적이고 비효율적인 과정 중 하나는 스타일(텍스트 스타일, 컬러, 그림자, Spacing 등)의 코드 변환이다. 기존 방식대로라면 디자인팀이 수동으로 값을 정리하고, 개발팀이 이를 코드화하는 과정에서 반복적인 작업과 오류 가능성이 높아진다. 이를 해결하기 위해 Figma Token → Style Dictionary → Code Generation 자동화 프로세스를 도입하려 했고, 이를 위해 디자인팀에게 Figma 플러그인을 활용한 Token Export to GitLab Repository 방식을 제안했다.


🎯 도전 과제: 디자인팀의 부담감 해소

하지만 디자인팀은 최근 인원이 줄어들면서 기존 업무만으로도 바쁜 상황이었다. 추가적인 태스크는 부담이 될 수 있었고, 새로운 툴 도입이 오히려 학습 부담과 업무량 증가로 느껴질 가능성이 있었다. 따라서 바로 솔루션을 제시하는 대신, 먼저 디자인팀의 입장을 이해하고 공감하는 과정이 필요하다고 판단했다.


🛠 접근 방식: 전술적 공감 + 내 입장 표현하기

1. 디자인팀의 상황을 먼저 이해하려고 노력함

  • 점심시간을 활용해 디자인팀과 자주 대화하며 현재의 업무 부담과 프로세스 문제점을 직접 들음.

  • 위키를 통해 디자인팀이 어떻게 소통하고 일하는지 살펴보고, 현재 집중하고 있는 업무가 무엇인지 파악하려고 노력함.

2. 디자인팀의 언어를 이해하기 위해 스스로 학습

  • 개인저으로 Figma 토큰에 대해 학습하며 디자인팀이 사용하는 용어와 프로세스를 이해하려고 함.

  • Figma Token export 방식 , Style Dictionary 을 직접 공부하며 개인 프로젝트에서 직접 Figma Token을 활용해 테스트하며 실용성을 검증함.

3. 디자인팀과 개발팀에 미치는 긍정적 영향 강조

  • 단순히 **"이걸 도입하면 좋아요"**가 아니라, "이걸 도입하면 기존의 반복 작업이 얼마나 줄어드는지"실질적인 예시 기반으로 설명함.

  • 디자인팀 측면: 디자인 시스템 값이 크게 변경될 경우, 디자인 QA 과정이 많아지고 변경된 요소를 일일이 설명해야 하는 번거로움이 존재. 하지만 자동화된 워크플로우를 통해 변경된 디자인 토큰이 즉시 코드에 반영되므로 QA 및 커뮤니케이션 부담이 줄어듦.

  • 개발팀 측면: 기존에는 디자인 값이 변경될 때마다 개발자가 수동으로 입력해야 했지만, 자동화 프로세스를 통해 디자인 토큰이 코드로 자동 변환되므로 개발자의 반복 작업을 줄이고, 오류 발생 가능성을 낮출 수 있음.

  • 결과적으로 디자인팀은 더 창의적인 작업에 집중할 수 있고, 개발팀은 디자인 반영 속도를 높이며 유지보수성을 향상할 수 있음. 🚀

4. 신뢰감 형성: ‘나는 개발팀이 아닌, 디자인팀과 함께하는 사람이다’

  • 디자인팀의 입장에서 고민하는 모습을 보이며 신뢰를 쌓음.

  • "이건 단순히 개발팀한테만 좋은 프로젝트가 아니라, 우리 개발팀, 디자인팀 모두의 효율성을 높이는 과정이다"라는 메시지를 전달.


🎉 결과: 코드 제너레이션 성공 & 디자인-개발 협업 강화

이 과정을 거친 결과, 디자인팀도 새로운 프로세스의 장점을 인식하고 협력적으로 참여하기 시작했다. 최종적으로 Figma Token을 GitLab Repository에 자동으로 Export → Style Dictionary 변환 → Code Generation까지의 워크플로우가 성공적으로 구축되었고, ✔ 텍스트 스타일, 컬러, 그림자(Shadow), Spacing 등의 디자인 요소들이 자동화되면서 디자인-개발 간 불필요한 반복 작업이 대폭 줄어들었다.

단순한 자동화 도입이 아니라, 디자인팀과의 신뢰를 먼저 쌓고 협업 문화를 강화하는 것이 더 중요한 과정이었다. 앞으로도 기술적 솔루션을 도입할 때, 먼저 팀원들의 고민을 듣고 공감하는 과정이 중요하다는 것을 다시금 실감했다. 🚀

Last updated