[Communication] 거절하기

0. 목차

1. 상황
2. 상대 주장
3. 내 대응
4. 확인할 점
5. 대응 개선점

1. 상황

• 내 전임자가 개발환경 등에 있어서 독단적으로 정한 부분이 많음
• 이미지, 첨부 파일은 현재 Supabase를 사용하고 있음
• Supabase 내의 데이터에 관하여 폴더 구분, 파일 규칙, 백업 등 전혀 관리가 안되는 상황
• 이미 10여 년 정도의 데이터가 쌓여있다고 함
• 백엔드 개발자 한명이 AWS를 사용하여 Cloud Storage를 구축하여 사용하는 것을 제안함

2. 상대 주장

• Supabase라는 많이 알려져있지 않은 서비스보다 AWS를 사용하는 것이 더 안정적이고 성능이 높다고 주장
• 현재 AWS클라우드 환경에서 백엔드를 운용하고 있으므로 Storage도 AWS로 신청해서 관리하는 것이 관리 일원화에 도움이 된다는 주장

3. 내 대응

• Supabase가 해킹을 걱정해야할 정도로 알려지지 않은 서비스는 아니다.
• Supabase에 데이터 백업, 보안 관련 기능들이 있는지 확인해봐야한다.
• 비용 측면도 고려를 해야한다. 런칭 후 데이터가 더 많아졌을 때 비용을 각 서비스별로 파악해봐야한다.
• 현재 코드에 Supabase를 사용하고 있으므로 수정해야할 부분들이 또 발생하므로, 위 사항들을 확인 후에 결정을 내리자

4. 확인할 점

• Supabase에 데이터 백업, 보안 관련 기능들이 있는지 확인
• 런칭 후 데이터가 더 많아졌을 때 비용을 각 서비스별로 파악
• 현재 코드에서 Supabase를 사용하고 있는 부분, 의존도 파악

5. 대응 개선점 (거절할 때)

• 상대방의 주장이 틀렸다고 말하지 않는다
  • 그 자리에서 틀렸다고 하기보단, 확인해봐야 한다고 말해야한다
  • 감정적인 충돌을 피할 수 있고, 서로의 생각이 다른 부분에 대해서 좀 더 확실한 사실에 기반해서 논의할 수 있다
• 반박해야할 부분이 있다면 상대방의 말의 핵심만 반박한다
  • Supabase가 알려지지 않은 서비스는 아니라는 사실은 중요한 부분이 아니다
  • 알려져있냐 아니냐는 것은 주관적인 부분일뿐 아니라, 핵심은 안정성이나 보안에 있어서 쓸만 하냐는 것이다
  • 심지어 상대방이 AWS로 변경을 하자는 주장은 단순히 성능이나 안정성의 이유를 넘어서, 일원화 등의 다른 이유를 가지고 있을 가능성이 높다
  • 따라서 먼저 상대방이 바꾸자고 하는 이유에 대해서 좀 더 들어본 후에, 진짜 바꾸자고 하는 이유가 뭔지를 파악하고 그 이유에 대한 타당성을 따져봐야 한다
• 만약 그래도 거절을 해야한다고 하면, 최대한 뒤로 미루자
  • 선행 작업들이 있다, 좀 더 확인해볼 사항이 있다, 의사결정이 필요하다 등 상황에 맞는 이유를 대면서 뒤로 미루자
  • 뒤로 미룰 때는 생각해볼 문제였다, 좋은 제안이었다는 식의 뉘앙스를 적절하게 주는 것이 상대방에 따라서는 필요할 수 있다 (자신의 의견을 강하게 피력하는 경우, 반복적으로 의견을 제시하는 사람의 경우 등)