이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 팀 프로젝트에서 기획 의도를 개발팀에 전달하는 과정에서 소통 문제를 경험했습니다. 기획자 입장에서 명확하다고 생각한 내용이 개발자 입장에서는 "어떻게 구현하라는 건지 모르겠다"는 피드백이 돌아왔습니다.
그 이후 저는 기능 명세 옆에 예시 화면 스케치를 추가했습니다. 글로만 설명하는 것보다 "이렇게 보여야 한다"는 시각 예시가 있으면 질문이 줄고, 방향 확인 회의도 빨라졌습니다.
다른 직군과 소통할 때 가장 중요한 건 상대가 무엇을 모르는지 미리 파악하는 것이라고 생각합니다. 같은 단어도 직군마다 다르게 해석할 수 있어서, 소통 전에 어휘 기준을 맞추는 것이 불필요한 재작업을 줄이는 가장 확실한 방법이라고 경험에서 확인했습니다.
다른 직군과 소통할 때 가장 어려운 자리는 내가 무엇을 모르는지를 모르는 상태입니다. 보안 쪽 배경이 없는 팀원에게 취약점을 설명할 때, 어떤 부분이 이미 이해된 건지 어떤 부분이 새로운 건지를 파악하는 것 자체가 시간이 걸립니다.
이 부분은 상대에게 직접 묻는 방식이 가장 빠르다는 걸 경험으로 알게 됐습니다. "이 부분까지는 알고 계신가요?"라는 확인 질문을 중간에 넣으면, 설명의 출발점을 조정하는 게 훨씬 쉬워집니다. 하지만 이 방식이 항상 통하지는 않습니다. 상대방이 모른다고 인식하지 못하는 경우도 있기 때문입니다. 직군 간 소통의 한계를 완전히 없애는 방법은 없고, 반복 확인으로 간격을 좁혀가는 것이 현실적인 결이라고 생각합니다.
직군이 다른 팀원과 공통 언어를 만드는 가장 효과적인 방법은 용어 정의를 초반에 함께 하는 것이라고 생각합니다. 기획자와 개발자가 "인증"이라는 단어를 다르게 이해한 채 회의를 진행하면, 나중에 수정 범위가 커집니다.
프로젝트 초반에 용어 정의 문서를 팀 내에서 공유하는 방식을 써봤습니다. 짧더라도 "이 단어는 이 맥락에서 이런 의미로 쓴다"는 합의 문서가 있으면 회의 중 오해가 줄어듭니다. 이 문서를 만드는 과정 자체가 서로 다르게 이해하는 부분을 드러내주기도 합니다. 한 단어가 직군마다 다른 의미로 쓰이는 경우가 생각보다 많습니다. 공통 언어는 저절로 만들어지는 것이 아니라 함께 정의하는 과정에서 생기는 결이라고 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.