프로젝트를 어떤 과정으로 수행하는지 사고 방식을 봅니다. 결과보다 어떻게 문제를 정의하고 접근하는지 프로세스 사고를 평가합니다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
전공 프로젝트를 시작할 때 저는 목표 정의와 범위 확정을 가장 먼저 합니다. 모든 기능을 구현하려다 핵심을 못 잡는 실수를 초반에 했기 때문에, 이후에는 완성할 수 있는 핵심 3가지를 우선순위로 정하는 방식을 씁니다. 이후 주차별 마일스톤을 설정하고 중간 점검을 팀과 공유합니다. 막히는 지점이 생기면 30분 이상 혼자 고민하지 않고 확인하는 규칙이 있고, 이 방식이 팀 전체 속도에 도움이 됐습니다. 프로젝트 마지막에는 무엇이 잘 됐고 무엇이 아쉬웠는지를 짧게 회고하는 습관이 있고, 이 기록이 다음 프로젝트에서 실질적으로 쓰입니다. 프로젝트를 마칠 때 회고를 남기는 습관이 다음 프로젝트 품질을 높여줬습니다.
무엇을 배웠는지를 기록하는 것이 경험을 자산으로 만드는 방법이라고 생각합니다.
전공 프로젝트에서 가장 어려웠던 상황은 중간에 요구사항이 바뀌었을 때였습니다. 첫 번째 중간 발표 이후 교수님 피드백으로 핵심 기능 중 하나를 수정해야 하는 상황이 생겼는데, 이미 그 기능을 기반으로 다른 부분이 연결돼 있었습니다. 처음에는 전체를 다시 짜야 한다고 생각했는데, 영향 범위를 먼저 파악하고 수정이 필요한 부분과 그렇지 않은 부분을 분리했더니 실제로 건드려야 할 양이 생각보다 작았습니다. 변경 사항이 생겼을 때 전체를 다시 보는 것보다 어디까지 파급되는지를 먼저 파악하는 것이 효율적이라는 것을 이 경험에서 배웠습니다. 요구사항 변경은 프로젝트에서 피할 수 없는 일이기 때문에, 변경에 빠르게 대응하는 구조를 미리 생각해두는 것도 설계의 일부라는 인식이 생겼습니다.
변화에 강한 구조는 변화가 왔을 때 만드는 것이 아니라 처음부터 설계에 포함돼 있어야 합니다.
전공 프로젝트 협업에서 어려웠던 것은 역할 분담이 명확하지 않아 같은 부분을 두 사람이 동시에 작업하는 상황이었습니다. 서로 다른 방향으로 구현한 것을 합칠 때 어느 쪽을 기준으로 할지를 정하는 것이 예상보다 시간이 걸렸습니다. 이 경험 이후부터는 프로젝트 초반에 어느 파트는 누가 담당하는지를 명시적으로 적어두는 방식을 쓰게 됐습니다. 역할이 겹치는 것 자체가 문제가 아니라 겹치는 것을 모른 채로 각자 작업하는 것이 나중에 더 많은 시간을 쓰게 만든다는 것을 배웠습니다. 협업에서 명시적인 경계가 있으면 서로의 작업을 신뢰하고 자기 부분에 집중할 수 있는 환경이 만들어집니다.
협업은 커뮤니케이션이 아니라 역할 구조를 먼저 설계하는 것에서 시작됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 LG전자 일반 연구개발 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.