이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대학원 연구실 인턴 시절 교수님의 국가 R&D 과제 제안서 작성에 보조로 참여했습니다. 연구 배경과 선행 연구 조사를 맡았는데, 연구 목표를 기관 심사 기준에 맞게 서술하는 방식이 일반 보고서와 다르다는 걸 처음 배웠습니다. 기술 완성도와 활용 가능성을 분리해서 평가 지표별로 근거를 제시하는 구조가 중요했고, 초안을 여러 번 고치면서 논리 흐름을 잡는 데 집중했습니다.
증빙 자료 항목이 생각보다 많아서, 참고 문헌 형식 오류 하나가 검수에서 반려될 수 있다는 걸 실무적으로 배웠습니다. 제안서가 최종 통과됐을 때 가장 기뻤던 건 기술 내용보다 서류 체계를 맞추는 데 기여했다는 점이었습니다. 다음에는 예산 편성 파트까지 직접 담당해 보고 싶은 목표가 생겼습니다.
R&D 제안서 작업에서 실수한 경험이 있습니다. 인턴 시절 교수님 과제 제안서 작업을 도우면서 선행 연구 정리 파트를 맡았는데, 중요하다고 생각되는 논문을 많이 모아 요약 형태로 정리했습니다. 교수님 피드백 시 이 연구들이 우리 과제와 어떻게 다른지 공백이 보이지 않는다는 지적이 돌아왔습니다. 많이 조사했지만 조사 결과가 우리 연구의 필요성을 입증하는 논리로 연결되지 않았습니다. 이후 선행 연구를 정리할 때는 기존 연구의 한계와 우리 연구의 차별점을 쌍으로 서술하는 구조로 재편했습니다.
분량보다 논리 연결이 제안서 설득력을 만든다는 것을 배웠습니다. 이 실수가 이후 문헌 조사를 정리할 때 연구 공백 서술을 함께 작성하는 기준이 됐습니다. 제안서의 힘은 조사량이 아니라 공백을 보여주는 논리입니다.
국가 R&D 제안서를 평가자 입장에서 읽어보는 경험을 한 적이 있습니다. 대학원 세미나에서 모의 평가 역할을 맡아 동료 팀의 제안서를 검토했습니다. 평가를 하다 보니, 연구 내용이 좋아도 기대 성과가 구체적이지 않으면 점수를 주기 어렵다는 것을 직접 느꼈습니다. 연구자 입장에서는 과정 자체가 의미 있지만, 평가자 입장에서는 이 연구가 끝나면 무엇이 생기는가가 판단 기준이었습니다. 이 경험을 통해, 제안서에서 성과물을 기술할 때 수치·결과물·활용 가능성을 묶어 한 문단으로 요약하는 것이 평가자에게 더 명확하다는 것을 알게 됐습니다. 이후 제안서를 보조할 때 성과 요약 단락을 먼저 확인하는 방식으로 기여했습니다.
이 관점이 이후 연구 결과물을 설명할 때 수신자 기준으로 역산해 구성하는 습관을 만들었습니다. 제안서는 쓰는 사람의 논리가 아니라 읽는 사람의 판단 기준으로 설계됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.