채용 면접 3일 전, Zend Framework 프로젝트를 설명하는 법

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

면접은 사흘 앞으로 다가왔는데 포트폴리오의 대표 작업은 오래된 Zend Framework 프로젝트뿐입니다. 최신 프레임워크로 만든 화려한 서비스와 나란히 놓으면 불리해 보이지만, 실제 평가에서는 기술의 연식보다 왜 그렇게 설계했고 무엇을 개선했는지 설명하는 능력이 더 선명한 차이를 만듭니다.

이번 글은 레거시 PHP 시스템을 여러 차례 인수하고 채용 기술 면접에도 참여한 백엔드 개발자 ‘이현오’ 님과의 가상 전문가 인터뷰 형식으로 구성했습니다. 사흘이라는 제한된 시간 안에서 코드를 무리하게 갈아엎지 않고, Zend Framework 프로젝트를 검증 가능한 개발자 포트폴리오로 바꾸는 방법을 묻고 답합니다.

첫날에는 낡은 코드를 고치기보다 설계 판단을 발굴합니다

Q. Zend Framework 프로젝트를 포트폴리오에 올리면 기술이 낡아 보이지 않을까요?

A. 버전만 덩그러니 적으면 그렇게 보일 수 있습니다. 그러나 어떤 요구사항 아래에서 프레임워크를 선택했고, 컨트롤러·서비스·데이터 접근 계층을 어떻게 나눴는지 보여주면 이야기가 달라집니다. 레거시 시스템을 읽고 위험을 통제하는 능력은 새 프로젝트를 시작하는 능력과 별개의 전문성입니다.

먼저 프로젝트의 시대적 맥락을 한 문단으로 고정하세요. 예를 들어 ‘PHP 7 환경과 기존 MySQL 스키마를 유지해야 했으며, 관리자 기능을 8주 안에 추가해야 했다’처럼 제약을 명시합니다. 그러면 오래된 의존성은 방치의 흔적이 아니라 당시 판단을 해석할 수 있는 근거가 됩니다. 포트폴리오라는 용어의 일반적 의미는 지식백과의 Portfolio 정의와 함께 살펴보면, 단순 결과물 모음보다 역량을 보여주는 선별된 기록에 가깝다는 점을 이해하기 쉽습니다.

• 문제: 사용자가 겪던 불편이나 조직의 운영 부담을 한 문장으로 씁니다.
• 제약: PHP 버전, 데이터베이스 구조, 배포 환경, 일정, 인력 규모를 구분합니다.
• 선택: Zend Framework의 모듈, 라우팅, 폼 검증 또는 서비스 구조를 왜 사용했는지 밝힙니다.
• 결과: 응답 시간, 오류 건수, 수작업 단계처럼 전후를 비교할 수 있는 값을 제시합니다.
• 회고: 지금 다시 만든다면 유지할 결정과 바꿀 결정을 각각 하나 이상 적습니다.

Q. 첫날 몇 시간 안에 무엇부터 찾아야 합니까?

A. 커밋을 처음부터 끝까지 읽지 말고 사용자 요청 하나가 처리되는 경로를 따라가세요. 라우트에서 컨트롤러로, 서비스에서 저장소와 데이터베이스로 이어지는 흐름을 그림 한 장에 담으면 면접관이 코드베이스를 훨씬 빨리 이해합니다. 로그인, 주문 등록, 파일 업로드처럼 입력과 실패 조건이 명확한 기능 하나가 적당합니다.

그 과정에서 ‘내가 작성한 코드’와 ‘기존 코드’를 분리해야 합니다. 팀 프로젝트라면 담당 범위를 과장하지 말고, 기존 구조에서 발견한 문제와 본인이 변경한 부분을 커밋 링크로 연결하세요. 소유권을 정확히 표시하는 태도 자체가 협업 능력의 증거가 됩니다.

“레거시 포트폴리오의 핵심은 오래된 코드를 새것처럼 포장하는 데 있지 않습니다. 제한된 조건에서 위험을 발견하고 합리적인 선택을 했다는 사실을 재현하는 데 있습니다.”

1. 90분 동안 실행 환경과 주요 요청 경로를 확인합니다.
2. 60분 동안 아키텍처와 외부 의존성을 한 장으로 그립니다.
3. 90분 동안 대표 기능의 요구사항·선택·결과를 작성합니다.
4. 60분 동안 본인 기여분에 해당하는 커밋과 이슈를 연결합니다.

둘째 날에는 면접관이 직접 확인할 증거를 만듭니다

Q. 저장소만 공개하면 충분하지 않은 이유는 무엇인가요?

A. 면접관에게 수백 개 파일을 읽어 달라고 요구하는 셈이기 때문입니다. 좋은 개발자 포트폴리오는 코드를 많이 진열하는 페이지가 아니라 평가자가 짧은 시간 안에 핵심 판단을 검증하도록 돕는 인터페이스입니다. 프로젝트 첫 화면에는 3분 요약, 실행 절차, 대표 코드, 테스트 결과, 알려진 한계를 순서대로 배치하세요.

특히 Zend Framework 프로젝트는 환경 차이로 실행이 실패하기 쉽습니다. 지원 PHP 버전, 필요한 확장 모듈, 웹 서버 설정, 데이터베이스 초기화 방법과 샘플 계정을 README에 적어야 합니다. 비밀 키를 제거한 .env.example, 최소 샘플 데이터, 한 번에 실행되는 테스트 명령도 준비하면 좋습니다. 공개가 어려운 업무 코드라면 구조를 재현한 축소판 저장소와 익명화된 화면 녹화로 대체할 수 있습니다.

포트폴리오를 결과물과 제작 과정의 증거로 바라보는 관점은 포트폴리오 개념 설명에서도 확장해 볼 수 있습니다. 중요한 것은 링크 개수가 아니라 각 자료가 어떤 질문에 답하는지입니다. 스크린샷 열 장보다 ‘중복 쿼리를 제거해 동일 조건의 응답 시간을 420ms에서 180ms로 줄였다’는 재현 가능한 기록 하나가 강합니다.

Q. 리팩터링은 어느 수준까지 해야 안전할까요?

A. 사흘 전이라면 대규모 업그레이드는 피해야 합니다. 프레임워크 교체나 전체 디렉터리 재구성은 새 결함을 만들고, 정작 설명 자료를 준비할 시간을 빼앗습니다. 대신 입력 검증 누락, SQL 조립, 비밀 정보 커밋, 예외 삼키기처럼 평가에 직접 영향을 주는 위험을 우선 확인하세요.

수정할 때는 한 커밋에 한 목적만 담습니다. 예를 들어 ‘컨트롤러의 데이터 조회를 서비스로 이동’, ‘매개변수 바인딩 적용’, ‘실패 경로 테스트 추가’를 분리하면 사고 과정이 드러납니다. 수정 전후의 테스트 결과와 동작 화면을 함께 남겨야 단순한 코드 정리가 아니라 회귀를 통제한 개선으로 읽힙니다.

• 즉시 처리: 노출된 자격 증명, 개인정보 샘플, 명백한 인젝션 가능성
• 작게 개선: 긴 메서드 분리, 의존성 주입, 오류 메시지 표준화, 핵심 테스트 보강
• 문서화 후 보류: 프레임워크 전환, 전체 ORM 교체, 대규모 프런트엔드 재작성
• 삭제 금지: 실패 기록과 트레이드오프를 숨기기 위한 무리한 커밋 정리

“면접 직전의 좋은 리팩터링은 코드 줄 수를 많이 바꾸는 작업이 아니라, 가장 위험한 가정을 테스트 가능한 형태로 바꾸는 작업입니다.”

셋째 날 6시간은 발표와 운영 비용에 배분합니다

Q. 면접에서는 어떤 순서로 설명해야 설득력이 생기나요?

A. 프레임워크 기능부터 말하지 말고 사용자 문제에서 시작하세요. ‘관리자가 매일 CSV 세 개를 합치던 작업을 하나의 승인 흐름으로 바꿨다’고 설명한 뒤, 그 흐름을 구현하기 위해 Zend Framework의 컨트롤러와 서비스 경계를 어떻게 정했는지 연결합니다. 기술은 주인공이 아니라 문제 해결을 뒷받침하는 수단이어야 합니다.

발표는 7분 분량으로 준비하면 질문 시간을 확보하기 좋습니다. 첫 1분은 문제와 제약, 다음 2분은 구조와 본인 역할, 이어지는 2분은 가장 어려웠던 장애와 해결 과정, 마지막 2분은 결과와 현재 다시 설계한다면 달라질 선택에 사용하세요. 면접관이 ‘왜 최신 PHP 프레임워크로 옮기지 않았나요?’라고 물으면 방어적으로 반응하지 말고 이전 비용, 테스트 범위, 서비스 중단 위험을 기준으로 답합니다.

1. 문제 60초: 사용자, 빈도, 손실을 구체적으로 말합니다.
2. 구조 120초: 요청 흐름과 데이터 경계를 도식으로 보여줍니다.
3. 사건 120초: 실패 증상, 가설, 측정, 수정, 검증 순서로 설명합니다.
4. 성과 60초: 수치가 없다면 처리 단계나 오류 가능성의 감소를 비교합니다.
5. 회고 60초: 유지할 결정 하나와 교체할 결정 하나를 근거와 함께 제시합니다.

작업집이 선별과 편집을 통해 메시지를 만든다는 관점은 또 다른 포트폴리오 용어 해설에서도 참고할 수 있습니다. 모든 기능을 보여주려 욕심내기보다 지원 직무와 가까운 장면을 선택하세요. 백엔드 직무라면 인증 흐름과 트랜잭션 경계를, 풀스택 직무라면 API 계약과 오류 상태가 화면에 전달되는 과정을 강조하는 식입니다.

Q. 남은 시간과 공개 데모 비용은 숫자로 어떻게 제한할까요?

A. 먼저 총 작업 시간을 18시간으로 고정하는 편이 현실적입니다. 첫날 6시간은 코드 발굴과 기여 범위 확인, 둘째 날 6시간은 문서·테스트·보안 점검, 셋째 날 6시간은 데모와 발표 연습에 배분합니다. 부족한 부분을 발견해도 각 작업에 종료 시각을 두어야 핵심 자료가 미완성으로 남지 않습니다.

공개 데모는 월정액부터 결제하기보다 예상 면접 기간만 운영하는 방식을 검토하세요. 예산 상한을 월 3만 원으로 잡고, 도메인·서버·데이터베이스·백업에 각각 얼마를 쓸지 기록합니다. 이는 특정 업체의 실제 가격표가 아니라 포트폴리오 운영을 위한 개인 예산 기준입니다. 무료 구간을 쓰더라도 절전 후 첫 요청 지연, 데이터 보존 기간, 트래픽 제한을 README에 알려야 합니다.

• 0~1만 원: 정적 설명 페이지와 영상, 로컬 실행 저장소 중심으로 구성합니다.
• 1만~3만 원: 소형 데모 서버를 제한 기간 운영하고 샘플 데이터만 제공합니다.
• 운영 시간 30일: 채용 일정이 끝나면 데모를 종료하거나 읽기 전용 영상으로 전환합니다.
• 점검 15분: 면접 당일 링크, 테스트 계정, 인증서, 모바일 화면을 다시 확인합니다.
• 리허설 2회: 첫 발표는 시간을 재고, 두 번째는 예상 질문 세 개까지 포함해 12분 안에 끝냅니다.

데모 계정에는 관리자 권한과 실제 개인정보를 넣지 말고, 쓰기 작업은 재설정 가능한 샘플 데이터로 제한하세요. 최종 30분에는 새 기능을 추가하지 않고 링크 깨짐, 저장소 공개 범위, 라이선스 표기만 확인합니다. 이렇게 사흘을 18시간·예산 3만 원 이하·발표 7분·데모 30일이라는 숫자로 제한하면, Zend Framework 프로젝트는 오래된 코드 묶음이 아니라 판단과 운영 능력을 보여주는 소프트웨어 포트폴리오가 됩니다.