제품·하드웨어 개발자 면접｜비개발자 대표가 양산 경험을 확인하는 방법
핵심 요약
- 하드웨어 개발자 면접에서는 시제품 제작과 양산·인증·품질 대응 경험을 구분해 확인해야 합니다.
- 실제 맡은 역할과 문제 해결 과정을 질문하고 자신이 모르는 부분도 인정하는지 살펴보세요.
- 비개발자 대표는 기술 검토의 도움을 활용해 시장에서 반복 생산·판매할 제품을 만든 경험을 평가해야 합니다.
소형가전·생활가전 등 제품·하드웨어 개발자를 채용할 때는 시제품을 만든 경험과 실제 양산까지 책임진 경험을 구분해야 합니다. 이 글은 회로·기구·펌웨어 개발과 생산 대응에 참여하는 개발자를 면접하는 비개발자 대표를 위한 실무 판단 기준을 다룹니다. 좋은 개발자를 채용하는 것은 단순히 직원 한 사람을 잘 뽑는 일이 아닙니다.
특히 자체 브랜드로 제품을 만들어 쿠팡이나 네이버 같은 온라인 채널에서 판매하려는 중소기업이라면, 경험 많은 개발자 한 사람을 확보하는 것이 회사 전체의 제품개발 능력을 바꿔놓기도 합니다.
대표가 엔지니어 출신이 아니라면 그 중요성은 더 커집니다.
제품을 기획하고 판매하는 능력은 있어도, 그 제품이 실제 양산 가능한 구조인지, 목표 원가에 맞출 수 있는지, 불량이 어디에서 발생할 가능성이 있는지까지 대표가 직접 판단하기는 어렵습니다.
이럴 때 경험 많은 개발자는 단순한 직원 한 명이 아니라 회사가 갖지 못한 기술적 판단력을 보완해 주는 사람이 됩니다.
특히 소형가전이나 생활가전과 같은 제조업에서는 이런 개발자의 가치가 더욱 큽니다.
국내 제조 기반이 예전보다 줄어들고 많은 생산이 중국을 비롯한 해외로 이전되면서, 실제 제품을 여러 차례 개발하고 대량 양산까지 경험해 본 개발자를 찾는 것이 갈수록 쉽지 않아졌습니다.
어렵게 찾아보면 이미 50대 후반이나 60대에 접어든 경우도 많습니다.
그래서 저는 중소기업 대표들에게 종종 이렇게 조언합니다.
정말 양산 경험이 많은 개발자를 만날 기회가 있다면 회사에 앉아서 이력서만 기다리지 말고, 필요하다면 찾아가서라도 한번 만나보라는 것입니다.
이미 은퇴한 개발자라고 해도 마찬가지입니다.
여러 제품을 실제로 개발하고 수천 개, 수만 개씩 양산해 시장에 내보낸 경험이 있는 사람이라면, 비개발자 대표에게는 쉽게 구하기 어려운 매우 귀한 인재일 수 있습니다.
문제는 면접에서 그런 사람을 어떻게 알아보느냐는 것입니다.
개발자 면접에서 가장 조심해야 할 말, “제가 다 했습니다”
개발자 면접을 하다 보면 비슷한 이야기를 자주 듣게 됩니다.
“그 제품은 제가 개발했습니다.”
“회로도 할 수 있고 기구도 할 수 있습니다.”
“소프트웨어도 알고 금형도 압니다.”
“처음 개발부터 양산까지 전부 해봤습니다.”
물론 실제로 여러 분야에 걸쳐 폭넓은 경험을 가진 개발자도 있습니다.
하지만 기업 현장에서 한 사람이 제품개발의 모든 부분을 완벽하게 혼자 담당하는 경우는 생각보다 많지 않습니다.
대부분은 프로젝트의 일부를 담당했거나, 여러 개발자 가운데 특정 분야를 맡았거나, 외부 전문업체와 협업했을 가능성이 큽니다.
그 자체는 전혀 문제가 아닙니다.
오히려 정상적인 제품개발 과정입니다.
문제는 본인이 실제로 담당한 일과 회사나 개발팀 전체가 한 일을 구분하지 않고 모두 자신의 경험처럼 이야기하는 경우입니다.
따라서 면접에서는 “어떤 제품을 개발했습니까?”라는 질문만 해서는 부족합니다.
반드시 그 사람이 실제로 맡은 범위까지 들어가 봐야 합니다.
시제품을 만든 경험과 양산제품을 만든 경험은 전혀 다릅니다
제가 개발자 면접에서 중요하게 보는 부분 가운데 하나가 시제품 개발과 실제 양산 경험의 차이입니다.
기능이 작동하는 시제품을 만드는 것만 놓고 본다면 생각보다 많은 사람이 할 수 있습니다.
대학이나 대학원에서도 실습과제나 연구과정에서 센서를 연결하고, 모터를 돌리고, 소프트웨어를 붙여 원하는 기능을 구현한 시제품을 만들 수 있습니다.
요즘은 부품과 개발도구도 잘 나와 있기 때문에 일정한 기술력을 가진 사람이라면 기능을 구현하는 것 자체는 과거보다 훨씬 쉬워졌습니다.
하지만 기업의 제품개발은 거기서 끝나지 않습니다.
진짜 어려운 것은 그 제품을 수천 개, 수만 개 만들어도 문제가 발생하지 않도록 만드는 것입니다.
기업의 개발자는 단순히 기능을 구현하는 사람이 아닙니다.
사용자가 편리하게 사용할 수 있어야 하고, 시장에서 경쟁할 수 있는 가격으로 만들 수 있어야 하며, 생산현장에서 쉽게 조립할 수 있어야 합니다.
생산 과정에서 작업자의 실수를 줄일 수 있는 구조도 고려해야 합니다.
부품의 공차가 조금씩 달라져도 문제가 발생하지 않는지, 특정 부품의 열이나 진동이 장기간 사용했을 때 다른 문제를 만들지는 않는지도 생각해야 합니다.
이런 것들이 모두 제품개발에 포함됩니다.
좋은 개발자는 제품이 공장을 떠난 뒤까지 생각합니다
양산 경험이 많은 개발자는 제품이 공장에서 정상적으로 조립되어 나왔다고 해서 개발이 끝났다고 생각하지 않습니다.
제품이 이후 어떤 환경을 거칠지도 생각합니다.
수출제품이라면 컨테이너에 실려 수주간 이동할 수도 있습니다.
뜨거운 지역을 통과할 수도 있고 항만이나 창고에서 장시간 보관될 수도 있습니다.
높은 온도와 습도, 진동 때문에 포장재가 변형되거나 플라스틱 부품에 문제가 생길 가능성은 없는지도 고려해야 합니다.
소비자가 제품을 몇 개월 사용했을 때 가장 먼저 고장날 가능성이 있는 부분은 어디인지도 생각해야 합니다.
그리고 실제 고장이 발생했을 때 수리가 쉬운 구조인지도 중요합니다.
부품 하나가 고장났는데 제품 전체를 분해해야 한다면 A/S 비용이 크게 올라갑니다.
반대로 고장이 많이 발생할 가능성이 있는 부분을 미리 예상하고 쉽게 교체할 수 있도록 설계했다면 회사의 사후관리 비용을 크게 줄일 수 있습니다.
이런 판단은 몇 번의 실험이나 이론 공부만으로 쉽게 만들어지지 않습니다.
여러 제품을 개발하고 양산하고, 불량을 경험하고, 소비자 클레임을 받아보고, 다시 설계를 고쳐본 사람에게 경험으로 축적됩니다.
이것은 하드웨어만의 이야기도 아닙니다.
소프트웨어도 마찬가지입니다.
몇 명이 사용하는 테스트 프로그램과 수천 명, 수만 명이 동시에 사용하는 서비스는 전혀 다른 문제입니다.
금형도 마찬가지입니다.
컴퓨터 화면에서 보기 좋은 설계와 실제 금형에서 안정적으로 찍혀 나오는 설계는 다를 수 있습니다.
그래서 개발자를 채용할 때는 무엇을 만들어봤느냐보다 그것을 실제 시장에 얼마나 많이 내보내봤느냐가 매우 중요합니다.
포트폴리오보다 “몇 대나 팔렸습니까?”를 물어보십시오
개발자의 포트폴리오는 중요합니다.
하지만 포트폴리오에 제품 사진이 많다고 해서 그 사람이 실제 양산까지 책임졌다고 단정해서는 안 됩니다.
저라면 면접에서 먼저 이렇게 묻겠습니다.
“이 제품은 실제 몇 대 정도 생산됐습니까?”
그리고 가능하다면 실제 시장에서 얼마나 판매됐는지도 물어보는 것이 좋습니다.
10대나 20대의 시제품을 만든 경험과 1만 대, 10만 대를 시장에 판매한 제품을 개발한 경험은 다를 수밖에 없습니다.
수량이 커지면 이전에는 보이지 않던 문제가 드러납니다.
1,000대 가운데 한 대에서 발생하는 문제라면 시제품 단계에서는 발견하지 못할 가능성이 큽니다.
하지만 10만 대를 판매하면 100건의 문제가 될 수 있습니다.
그래서 대량 양산을 경험한 개발자는 작은 가능성의 문제도 다르게 바라보는 경우가 많습니다.
다음에는 이렇게 물어보는 것이 좋습니다.
“그 제품에서 본인이 직접 담당한 부분은 어디까지였습니까?”
회로를 담당했는지, 펌웨어를 담당했는지, 기구설계를 했는지, 금형까지 관여했는지, 인증과 양산 대응을 어디까지 경험했는지를 구체적으로 확인해야 합니다.
실제로 경험한 사람일수록 오히려 자신의 역할과 다른 사람의 역할을 명확하게 구분해서 설명하는 경우가 많습니다.
성공보다 실패를 물어보면 진짜 경험이 보입니다
저는 개발자 면접에서 성공한 제품 이야기만 듣는 것보다 실패한 경험을 물어보는 것이 훨씬 중요하다고 생각합니다.
예를 들어 이렇게 질문할 수 있습니다.
“양산 후 가장 크게 문제가 된 불량은 무엇이었습니까?”
그리고 답변이 나오면 바로 이어서 물어봅니다.
“왜 그런 문제가 발생했습니까?”
“개발 단계에서는 왜 발견하지 못했습니까?”
“그 문제를 어떻게 해결했습니까?”
“금형을 수정했습니까, 부품을 변경했습니까?”
“다시 개발한다면 처음 설계부터 무엇을 바꾸겠습니까?”
이런 질문을 몇 번 이어가면 실제 양산 경험이 있는 사람과 그렇지 않은 사람의 차이가 상당히 드러납니다.
실제 양산을 경험한 개발자는 실패 사례를 구체적으로 기억하는 경우가 많습니다.
특정 부품의 내구성이 부족했다거나, 플라스틱 사출품 공차가 예상보다 컸다거나, 조립공정에서 작업자가 부품을 잘못 끼우는 문제가 있었다거나, 장시간 사용 후 열 때문에 문제가 발생했다는 식입니다.
그리고 중요한 것은 그 문제를 어떻게 해결했는가입니다.
부품을 바꿨는지, 구조를 수정했는지, 금형을 수정했는지, 조립방법을 바꿨는지, 검사공정을 추가했는지까지 이야기할 수 있어야 합니다.
저는 오히려 이런 실패 이야기를 들을 때 개발자의 실제 실력이 보인다고 생각합니다.
양산 경험을 확인하는 네 단계 질문
같은 제품 사례를 따라 질문하면 답변의 연결성을 볼 수 있습니다. 생산수량만으로 역량을 단정하지 말고 본인의 역할과 판단을 함께 확인합니다.
“그 기능을 만들 수 있습니까?”라고만 묻지 마십시오
비개발자 출신 대표가 개발자 면접에서 가장 쉽게 하는 질문이 있습니다.
“이 기능을 만들 수 있습니까?”
대부분의 개발자는 “할 수 있습니다”라고 대답합니다.
하지만 대표의 질문은 거기서 끝나서는 안 됩니다.
이렇게 이어가야 합니다.
“목표 원가 안에서 만들 수 있습니까?”
“이 제품을 1만 대 생산한다면 현재 설계에서 가장 먼저 바꿔야 할 부분이 무엇입니까?”
“조립할 때 가장 문제가 될 가능성이 높은 부분은 어디입니까?”
“고장이 많이 발생할 것으로 예상되는 부품은 무엇입니까?”
“그 부품이 고장나면 수리가 쉽게 되도록 어떻게 설계하시겠습니까?”
“원가를 줄여야 한다면 어느 부분부터 손대시겠습니까?”
이런 질문을 해보면 단순히 기능을 구현할 수 있는 사람과 제품을 실제 사업으로 연결할 수 있는 개발자의 차이가 드러납니다.
좋은 개발자는 원가를 모르는 사람이 아닙니다
중소기업 제품개발에서는 원가가 매우 중요합니다.
아무리 좋은 제품이라도 시장에서 5만원에 팔아야 하는데 제조원가가 4만원이라면 사업으로 성공하기 어렵습니다.
따라서 경험 있는 개발자는 단순히 기술적으로 가장 좋은 부품만 선택하지 않습니다.
필요한 성능과 안정성을 확보하면서도 시장에서 판매할 수 있는 원가를 맞출 방법을 찾습니다.
부품 가격만 보는 것도 아닙니다.
조립시간, 금형비, 검사비용, 포장비용, 불량률까지 생각해야 합니다.
조금 싼 부품을 사용했다가 불량률이 크게 올라간다면 결국 회사 전체 비용은 더 커질 수 있습니다.
그래서 면접에서는 다음과 같은 질문도 의미가 있습니다.
“과거 개발했던 제품에서 원가를 낮추기 위해 어떤 설계변경을 해봤습니까?”
실제 경험이 있는 개발자라면 단순히 싼 부품으로 바꿨다는 이야기만 하지 않을 가능성이 높습니다.
부품 수를 줄였거나, 여러 제품에서 공용부품을 사용했거나, 조립공정을 단순하게 만들었거나, 금형구조를 개선한 경험이 나올 수 있습니다.
실제 경험이 많은 사람은 어려운 기술을 쉽게 설명합니다
비개발자 대표가 개발자를 면접할 때 기술적 질문을 잘 하지 못한다고 걱정하는 경우가 있습니다.
하지만 반드시 전문적인 공학 지식을 가지고 있어야만 좋은 개발자를 구별할 수 있는 것은 아닙니다.
오히려 지원자에게 기술적인 내용을 쉽게 설명해 달라고 해보는 것도 좋은 방법입니다.
실제로 그 분야를 깊이 이해하고 있는 사람은 비전문가에게도 비교적 쉽게 설명할 수 있습니다.
예를 들어 대표가 이렇게 물을 수 있습니다.
“이 부품을 조금 더 싼 것으로 바꾸면 안 됩니까?”
경험 있는 개발자라면 단순히 “됩니다” 또는 “안 됩니다”라고만 답하지 않을 가능성이 큽니다.
어느 부분은 원가를 낮춰도 괜찮고, 어느 부분은 안전이나 수명 때문에 건드리면 안 되는지 설명할 것입니다.
또 다른 부분을 변경해서 전체적인 원가를 낮추는 대안을 제시할 수도 있습니다.
개발자는 기술적으로 가장 뛰어난 제품만 만드는 사람이 아닙니다.
회사가 시장에서 실제로 판매할 수 있는 제품을 만드는 사람이어야 합니다.
“제가 개발했습니다”라는 말을 꼬리질문으로 확인하십시오
지원자가 “제가 그 제품을 개발했습니다”라고 말했다고 해서 의심부터 할 필요는 없습니다.
그러나 확인은 반드시 필요합니다.
예를 들어 지원자가 공기청정기를 개발했다고 이야기한다면 다음 질문으로 들어가 볼 수 있습니다.
“어떤 방식의 공기청정기였습니까?”
“팬은 어떤 기준으로 선정했습니까?”
“소음 문제는 어떻게 해결했습니까?”
“실제 양산수량은 얼마나 됐습니까?”
“양산 후 가장 많이 발생한 불량은 무엇이었습니까?”
“인증 과정에서 문제가 된 부분은 없었습니까?”
“금형 개발에는 어느 정도 관여했습니까?”
“본인이 직접 담당하지 않은 부분은 무엇이었습니까?”
몇 단계만 질문을 이어가도 실제 경험의 깊이는 상당히 드러납니다.
면접에서 중요한 것은 첫 번째 답변보다 그 다음 답변입니다.
지원자가 말한 내용을 바탕으로 계속 한 단계씩 들어가 보는 것입니다.
면접에서는 지원자의 첫 답보다 그다음 답을 보게 됩니다
제가 면접관의 입장에서 지원자들에게 조언한 글에서도 비슷한 이야기를 한 적이 있습니다.
면접관은 지원자가 자기소개서나 경력기술서에 써놓은 내용을 그대로 믿고 넘어가기보다, 그 내용을 바탕으로 질문을 계속 이어가는 경우가 많습니다.
지원자가 어떤 경험을 했다고 썼다면 구체적으로 무엇을 했는지, 왜 그렇게 했는지, 어떤 문제가 있었는지를 확인합니다.
지원자 입장에서 면접의 꼬리질문에 어떻게 대비해야 하는지가 궁금하다면 「면접, 어떻게 해야 할까? 사람을 뽑아본 면접관이 취업준비생에게 드리는 조언」도 함께 읽어보시면 도움이 됩니다.
AI로 작성한 자기소개서일수록 꼬리질문은 더 중요합니다
요즘은 자기소개서나 경력기술서를 작성할 때 AI를 활용하는 지원자도 많습니다.
AI를 활용해 문장을 다듬는 것 자체가 문제라고 생각하지는 않습니다.
하지만 실제 경험보다 자기소개서가 지나치게 훌륭하게 작성되어 있다면 면접에서는 곧바로 문제가 드러날 수 있습니다.
개발자 채용에서도 마찬가지입니다.
포트폴리오와 경력기술서는 매우 전문적으로 보이는데 그 내용에 대해 두세 단계 질문을 이어가면 답변이 막히는 경우가 있을 수 있습니다.
그래서 이제는 서류 자체의 완성도보다 지원자가 그 내용을 자기 경험으로 얼마나 깊이 설명할 수 있는가를 보는 것이 더 중요해졌다고 생각합니다.
AI를 활용한 자기소개서와 면접의 관계에 대해서는 「자기소개서에 AI를 어디까지 활용해도 될까? 면접까지 생각한 AI 자소서 활용법」에서 별도로 다루고 있습니다.
모든 것을 할 수 있다는 개발자보다 자기 한계를 아는 개발자가 낫습니다
오랫동안 개발을 해온 사람일수록 오히려 모든 것을 자신이 할 수 있다고 말하지 않는 경우가 많습니다.
“회로는 제가 했지만 금형은 전문업체와 협업했습니다.”
“펌웨어는 제가 담당했지만 앱 개발은 다른 팀에서 했습니다.”
“제가 처음부터 개발한 제품은 아니고 양산 개선 단계부터 참여했습니다.”
저는 오히려 이런 대답에서 신뢰감을 느낍니다.
제품개발은 혼자 하는 일이 아니기 때문입니다.
회로, 기구, 금형, 소프트웨어, 디자인, 인증, 생산기술, 품질관리 등 여러 분야가 연결됩니다.
좋은 개발자는 자신이 무엇을 잘하는지뿐 아니라 어디서부터 다른 전문가의 도움이 필요한지도 알고 있습니다.
그래서 “저는 다 할 수 있습니다”라는 사람보다 자신의 전문분야와 한계를 정확하게 설명하는 사람이 회사에는 더 안전할 수도 있습니다.
은퇴한 개발자를 다시 볼 필요가 있습니다
중소기업 대표들이 사람을 뽑을 때 연령을 중요하게 보는 경우가 있습니다.
물론 장기근속 가능성과 조직문화도 고려해야 합니다.
그러나 자체 개발 경험이 거의 없는 회사라면 다른 접근도 필요합니다.
특히 소형가전이나 생활가전처럼 과거 국내 제조업에서 오랫동안 경험을 쌓은 개발자를 구하기 어려운 분야라면 60대 개발자라는 이유만으로 제외하는 것은 아까운 일입니다.
오히려 처음부터 젊은 개발팀만 구성하는 것보다 양산 경험이 많은 시니어 개발자를 먼저 확보하고 그 사람을 중심으로 후배 개발자를 붙이는 방식도 생각해볼 수 있습니다.
이미 은퇴한 개발자라도 좋은 후보가 될 수 있습니다.
그들의 입장에서도 평생 축적한 경험을 활용할 수 있는 새로운 일이 될 수 있습니다.
기업 역시 반드시 정규직만 생각할 필요는 없습니다.
기술고문, 개발자문, 프로젝트 계약, 주 2~3일 근무 등 회사 상황에 맞는 여러 형태의 협업이 가능합니다.
중요한 것은 나이가 아닙니다.
그 사람이 어떤 제품을 실제로 만들어봤고, 얼마나 많은 양산과 시장의 문제를 경험했느냐가 중요합니다.
비개발자 대표라면 좋은 개발자를 더 가까이 두어야 합니다
대표가 영업이나 유통, 마케팅 출신이라면 시장을 보는 능력은 뛰어날 수 있습니다.
어떤 제품이 팔릴지, 소비자가 무엇을 원하는지, 어느 가격대에서 경쟁력이 있는지를 잘 알 수 있습니다.
그러나 개발과 생산은 또 다른 영역입니다.
이때 대표 옆에 경험 많은 개발자가 있다면 의사결정의 질이 크게 달라집니다.
중국 공장에서 새로운 제품을 제안했을 때도 단순히 외관과 가격만 보는 것이 아니라 제품 구조까지 함께 볼 수 있습니다.
기존 금형을 사용할 수 있을지, 새로운 금형을 만들어야 할지, 특정 부품을 변경했을 때 어떤 문제가 발생할지를 판단할 수 있습니다.
공장에서 “문제없습니다”라고 이야기할 때 정말 문제가 없는지 기술적으로 검토할 사람도 생깁니다.
대표가 몰랐기 때문에 발생할 수 있었던 문제를 개발자가 사전에 막아줄 수도 있습니다.
비개발자 대표에게 경험 많은 개발자는 단순히 직원 한 사람이 아닙니다.
회사의 기술적 눈이 되어주는 사람입니다.
좋은 개발자를 만나는 것도 회사의 경쟁력입니다
기업을 운영하다 보면 자금도 중요하고 영업도 중요합니다.
브랜드와 마케팅 역시 중요합니다.
그러나 제품을 판매하는 회사라면 결국 좋은 제품을 안정적으로 만들어내는 능력이 있어야 합니다.
그리고 그 능력의 상당 부분은 사람에게 축적되어 있습니다.
여러 제품을 개발하고 실제 대량양산까지 경험하면서 수많은 실패와 불량을 겪어본 개발자는 하루아침에 만들어지지 않습니다.
제품 하나를 기능적으로 구현한 사람과 그 제품을 수천 개, 수만 개 시장에 내보내고 그 이후 발생하는 문제까지 경험해 본 사람은 다를 수밖에 없습니다.
그래서 그런 개발자를 만났다면 이력서의 나이나 현재 직위만 볼 필요는 없습니다.
회사에 앉아서 지원자가 오기만을 기다리는 것도 때로는 사치일 수 있습니다.
정말 필요한 사람이라면 대표가 직접 찾아가서라도 한번 만나보는 것이 좋습니다.
특히 처음 제조업에 뛰어든 비개발자 출신 대표라면 더욱 그렇습니다.
제품 하나를 만들 줄 아는 사람보다, 그 제품을 시장에서 수천 개, 수만 개 팔 수 있는 상태까지 만들어본 사람을 찾으십시오.
그런 개발자를 만나는 것은 작은 회사에게는 때때로 새로운 거래처 하나를 얻는 것보다 더 큰 행운이 될 수 있습니다.
