예산 제약이라는 현실적 장벽 앞에서 어떻게 대안을 모색하는지를 확인한다. 실무적 문제 해결 능력과 협상·조율 역량을 평가한다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
예산 제약이 생기면 먼저 프로젝트의 핵심 목표가 무엇인지를 다시 정의합니다. 전체를 축소하기보다 반드시 실현해야 하는 기능과 예산이 생기면 추가할 기능으로 나누는 것이 현실적인 접근이라고 생각합니다. 그다음으로는 무료 또는 저비용 대안이 있는지를 먼저 탐색합니다. 오픈소스 도구나 학교·기관 지원 프로그램을 활용해 핵심 검증을 먼저 하고, 이후 투자 유치나 지원금으로 확장하는 순서가 더 안전합니다. 중요한 건 예산이 없다는 사실을 프로젝트 중단의 이유가 아니라 설계 제약으로 받아들이는 태도라고 생각합니다.
제약 조건이 생기면 범위를 줄여서라도 핵심을 먼저 실행하는 것이 멈추는 것보다 낫습니다.
예산이 막히면 저는 가장 먼저 비용이 발생하는 항목과 오픈소스로 대체 가능한 항목을 목록으로 분리합니다. 팀 프로젝트에서 유료 클라우드 API 예산이 갑자기 끊긴 적이 있었는데, 하나씩 뜯어보니 전체 기능의 절반 이상이 무료 라이브러리로 대체 가능했습니다. 나머지 기능도 발표 시점에 반드시 필요한 것과 이후에 붙여도 되는 것으로 나누자, 실제로 당장 유료 서비스가 필요한 항목은 하나뿐이었고 팀원 중 학생 크레딧을 쓸 수 있는 사람이 있어 해결됐습니다.
예산 제약이 오히려 요구사항 전체를 다시 들여다보게 만드는 계기가 됐고, 덕분에 기능 범위가 처음보다 훨씬 명확해졌습니다. 이후로는 새 도구를 도입할 때 항상 무료 대안 후보를 함께 조사해두는 것이 습관이 됐고, 비용 발생 가능성 자체를 설계 초반에 드러내는 방식으로 바꿨습니다.
예산 부족이 확인되면 저는 바로 팀 전체가 같은 상황을 공유하고 있는지 확인하는 것부터 시작합니다. 각자 해결책을 찾으면 방향이 엇갈리기 때문입니다. 한 번은 외부 API 비용이 예상의 세 배가 나왔을 때, 팀 내에서 해당 기능을 직접 구현할 수 있는 사람이 있는지 먼저 물었습니다. 마침 백엔드 담당자가 유사한 기능을 직접 만들 수 있다고 했고, 구현에 일주일이 더 걸렸지만 비용 없이 동일한 동작을 얻으면서 팀이 내부 역량을 더 명확히 파악하는 기회가 됐습니다.
돈이 없으면 시간이나 역량으로 메울 수 있는 부분을 먼저 찾는 것이 현실적인 첫 수순이라고 생각합니다. 이 판단이 팀 안에서 가능한 것과 불가능한 것의 경계를 빠르게 합의하게 해줬고, 협업이 예산 문제를 해결하는 실질적인 자원이 된다는 걸 그때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 포스코인터내셔널 글로벌 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.