면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
인턴 때 개발팀과 자주 회의를 하면서, 기술을 모르는 채로 들어가면 회의가 겉돈다는 걸 느꼈습니다. 그 이후로 회의 전에 관련 기술 개념을 간단히 찾아봤는데, 모든 걸 이해하려다 보면 끝이 없어서, 이 기능이 '왜 어려운지'와 '무엇이 제약인지'를 파악하는 데 집중했습니다. 개발팀에서 '기획자 중에 이런 질문 하는 분이 드물다'는 말을 들었고, 논의 속도도 빨라졌습니다. 기술 배경지식은 구현을 이해하는 것보다 제약을 이해하는 것이 소통에 더 유용하다는 걸 배웠습니다.
제약을 이해하는 것이 소통에 더 유용하다는 걸 배웠고, 이후에도 회의 전에 기술 제약을 먼저 파악합니다.
기획 공부를 하면서 간단한 웹 페이지를 직접 만들어본 경험이 있습니다. 처음엔 버튼 하나 추가하는 게 왜 시간이 걸리는지 몰랐는데, 직접 짜보니 디자인, 동작, 예외 처리를 각각 고려해야 한다는 걸 알게 됐습니다. 그때부터 개발자에게 '버튼 하나만 추가하면 돼요'라는 말을 안 하게 됐습니다. 이후 개발팀과 일정 협의할 때 더 현실적인 기준으로 논의할 수 있었습니다. 개발자와 소통하려면 코드를 잘 짜는 게 아니라 왜 어려운지를 아는 것이 먼저라는 걸 배웠습니다.
왜 어려운지를 아는 것이 개발자 소통의 시작이라는 걸 배웠고, 이후에도 직접 짜보는 경험을 이어가고 있습니다.
취준 중 기술 블로그와 개발 문서를 꾸준히 읽는 습관이 있습니다. 처음엔 내용이 어려웠는데, 기술 용어를 외우는 대신 '이게 왜 생겼는지'를 중심으로 읽으니 개념이 맥락으로 이해됐습니다. 예를 들어 캐싱이 왜 필요한지를 알면, 개발팀이 '이 기능엔 캐시가 안 된다'고 할 때 왜 어려운지 바로 이해됩니다.
이런 배경이 있으니 개발팀과 회의에서 전달이 더 잘 됐습니다. 기술 지식은 구현 방법보다 맥락을 이해하는 것이 소통에 더 효과적이라는 걸 배웠습니다. 맥락을 이해하는 것이 소통에 더 효과적이라는 걸 배웠고, 이후에도 원리 중심으로 기술 문서를 읽습니다. 기술의 맥락을 알면 개발자의 말이 다르게 들립니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.