2026 젠드 프레임워크 포트폴리오 현대화 사용 후기

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

오래된 PHP 프로젝트를 포트폴리오에 공개하려니 가장 먼저 걸린 것은 디자인이 아니라 Zend Framework 의존성과 낡은 실행 환경이었습니다. 코드에는 분명 실무적인 가치가 있었지만, PHP 버전과 패키지 상태를 설명하지 않으면 방치된 저장소처럼 보일 수 있었습니다.

그래서 2026년 상반기에 개인 프로젝트 하나를 직접 손보며 Zend Framework 기반 애플리케이션을 Laminas 중심으로 전환했습니다. 이 글은 단순한 설치법이 아니라, 실제로 마이그레이션하면서 확인한 장점과 단점, 예상보다 오래 걸린 부분, 그리고 개발자 포트폴리오에 효과적으로 기록한 방법을 담은 사용 후기입니다.

오래된 Zend 프로젝트를 다시 꺼낸 이유

삭제보다 현대화가 포트폴리오에 유리했습니다

처음에는 저장소를 비공개로 돌릴 생각이었습니다. 그러나 주문 처리, 권한 분리, 메일 발송, 데이터 검증처럼 당시 고민했던 기능은 지금도 충분히 설명할 가치가 있었습니다. 새 프로젝트만 나열하는 것보다 레거시 소프트웨어를 진단하고 안전하게 개선한 과정이 제 개발 역량을 더 입체적으로 보여줬습니다.

포트폴리오는 단순한 작품 모음이 아니라 경험과 판단 근거를 선별해 보여주는 자료입니다. 용어의 일반적인 의미는 Portfolio 지식백과 설명에서도 확인할 수 있습니다. 저는 이를 개발 작업에 적용해 완성 화면뿐 아니라 문제, 선택지, 검증 결과를 한 흐름으로 구성했습니다.

2026년 7월 기준 PHP 공식 지원표를 확인하면 PHP 8.2는 보안 지원 종료가 가까우며, 8.4와 8.5는 더 긴 지원 기간을 확보하고 있습니다. 따라서 단순히 PHP 8에서 실행된다고 쓰기보다 어떤 버전에서 테스트했고 지원 종료 일정을 어떻게 고려했는지 밝히는 편이 신뢰를 높였습니다.

• 장점: 기존 비즈니스 로직을 살리면서 유지보수 역량을 증명할 수 있습니다.
• 장점: 변경 전후의 오류와 성능을 비교할 자료가 자연스럽게 생깁니다.
• 단점: 신규 개발보다 화면상 변화가 작아 문서화가 부족하면 노력의 크기가 보이지 않습니다.
• 주의점: 고객 데이터나 회사 코드를 옮기는 것이 아니라 공개 가능한 개인 프로젝트에서 진행해야 합니다.

포트폴리오에서 중요한 것은 최신 기술 이름의 개수가 아니라, 왜 바꿨고 어떤 위험을 줄였는지 설명하는 능력이었습니다.

마이그레이션 전에 실제로 점검한 항목

코드보다 실행 환경을 먼저 고정했습니다

첫 시도에서는 곧바로 패키지를 바꿨다가 오류 원인을 구분하지 못했습니다. PHP 버전 문제인지, Composer 의존성 문제인지, 애플리케이션 설정 문제인지 한꺼번에 섞였기 때문입니다. 두 번째 시도부터는 기존 상태를 재현하고 테스트 기준을 기록한 뒤 작업했습니다.

저는 별도 브랜치를 만들고 데이터베이스 스키마와 샘플 데이터를 백업했습니다. 로그인, 목록 조회, 등록, 수정, 메일 전송 등 핵심 경로는 브라우저로 직접 실행해 결과를 남겼습니다. 자동 테스트가 적은 레거시 프로젝트라면 이 수동 기준선이라도 있어야 변경 후 퇴행을 발견할 수 있습니다.

비용은 로컬 Docker 환경을 사용해 추가 지출이 없었고, 공개 데모용 소형 서버에는 월 1만~3만원 정도의 예산을 잡았습니다. 다만 호스팅 가격은 사업자, 지역, 트래픽에 따라 달라지므로 특정 금액을 정답처럼 제시하지 않았습니다. 데모를 상시 운영하지 않는다면 영상과 캡처, 재현 가능한 설치 문서만으로도 충분한 경우가 많았습니다.

1. composer show로 Zend 관련 패키지와 버전을 목록화합니다.
2. composer audit --locked로 잠금 파일 기준 보안 경고와 중단된 패키지를 확인합니다.
3. PHP 확장 모듈, 웹 서버 설정, 환경 변수 목록을 별도 문서에 적습니다.
4. 핵심 사용자 흐름을 체크리스트로 만들고 변경 전 결과를 저장합니다.
5. Git 태그를 생성해 실패해도 기존 실행 상태와 비교할 수 있게 합니다.

시간을 가장 많이 아껴 준 범위 설정

처음부터 PHP 최신 버전 적용, UI 개편, 데이터베이스 변경까지 모두 하려 하면 원인 추적이 어려워집니다. 저는 1차 목표를 Zend 네임스페이스와 패키지를 Laminas 계열로 이전하고 기존 기능을 유지하는 것으로 제한했습니다. 디자인과 신규 기능은 별도 단계로 미뤘습니다.

• 1차 범위: 의존성 전환, 부팅 성공, 핵심 기능 유지
• 2차 범위: PHP 버전 상향과 경고 제거
• 3차 범위: 테스트 보강, 정적 분석, 배포 자동화
• 제외 범위: 전면 UI 교체, 불필요한 기능 추가, 데이터 모델 재설계

Laminas 전환을 직접 사용하며 겪은 장단점

자동 변환은 출발점이지 완성본은 아니었습니다

Laminas는 종료된 Zend Framework 프로젝트의 공식적인 후속 흐름이므로 Zend Framework 2·3 계열 프로젝트에서는 마이그레이션 도구를 검토할 수 있습니다. 도구를 실행하자 패키지 이름과 네임스페이스가 빠르게 바뀌어 수작업량이 크게 줄었습니다. 특히 파일 수가 많은 프로젝트에서는 검색과 치환을 직접 반복하는 것보다 일관성이 좋았습니다.

반면 사용자 정의 클래스명에 Zend라는 문자열이 들어 있거나 외부 패키지의 고유 클래스명이 비슷한 경우에는 과도한 변경이 생길 수 있었습니다. 설정 배열 구조가 표준 예제와 다르면 모듈 삽입도 완전하지 않았습니다. 실제로 제 프로젝트에서는 부팅 오류보다 메일 전송 어댑터와 캐시 설정을 정상화하는 데 더 많은 시간이 들었습니다.

공식 절차처럼 작업 전 버전 관리를 적용하고 변환 후 git diff를 검토한 것이 가장 효과적이었습니다. 데이터와 이미지 폴더는 변환 대상에서 제외했고, 캐시 파일을 삭제한 다음 의존성을 다시 설치했습니다. 한 번에 성공시키려 하기보다 작은 커밋 단위로 원인을 좁히는 방식이 안전했습니다.

• 좋았던 점: 반복적인 패키지·네임스페이스 변경 시간을 줄여 줬습니다.
• 좋았던 점: 변경 내역이 명확해 코드 리뷰용 사례를 만들기 쉬웠습니다.
• 아쉬운 점: 비표준 설정과 사용자 정의 명칭은 사람이 다시 확인해야 했습니다.
• 아쉬운 점: 테스트가 없는 영역은 실행 성공만으로 정상 동작을 보장하기 어려웠습니다.

자동 마이그레이션 직후에는 성공 메시지보다 Git diff를 먼저 보세요. 예상하지 못한 클래스명 변경 한 줄이 운영 오류의 출발점이 될 수 있습니다.

실패했던 순서와 개선한 순서

처음에는 운영과 비슷한 브랜치에서 변환 도구를 실행한 뒤 바로 Composer 업데이트를 진행했습니다. 그러자 패키지 전환과 버전 상승에서 발생한 오류가 함께 나타났습니다. 다시 시작할 때는 변환, 설치, 테스트, PHP 상향을 분리했고 각 단계마다 커밋을 남겼습니다.

1. 기존 상태에서 테스트와 수동 점검을 통과시킵니다.
2. 변환 도구를 실행하고 소스 차이만 검토합니다.
3. 의존성을 설치한 뒤 설정 캐시를 비우고 부팅을 확인합니다.
4. 핵심 기능 테스트를 통과한 후 PHP 버전을 한 단계씩 올립니다.
5. 마지막에 정적 분석과 Composer 보안 감사를 추가합니다.

포트폴리오 프로젝트로 보여 준 방법

README를 문제 해결 보고서처럼 구성했습니다

코드만 공개했을 때는 방문자가 무엇이 개선됐는지 알아보기 어려웠습니다. 그래서 README 첫 화면에 프로젝트 목적, 기존 기술 스택, 발견한 위험, 목표 환경, 검증 결과를 짧게 배치했습니다. 자세한 커밋을 보기 전에도 작업의 의미가 전달되도록 만든 것입니다.

작품을 선별하고 맥락을 제공한다는 관점은 포트폴리오의 개념 설명과도 맞닿아 있습니다. 개발자에게는 완성된 화면뿐 아니라 코드 품질, 의사결정, 재현 방법이 작품의 일부입니다. 저는 실패 로그를 전부 늘어놓는 대신 대표 오류 세 가지와 해결 근거를 골라 읽는 시간을 줄였습니다.

전후 비교에는 막연한 표현을 쓰지 않았습니다. 설치 성공 여부, 테스트 개수, 지원 중인 PHP에서의 실행 여부, 취약 의존성 경고 수, 첫 화면 응답 시간처럼 다시 측정할 수 있는 항목을 넣었습니다. 성능 수치는 동일한 장비와 데이터에서 여러 번 측정하고 중앙값을 사용했다고 명시했습니다.

• 프로젝트 한 줄 소개와 사용자가 해결하려는 문제
• Zend Framework 기반의 기존 구조와 주요 제약
• Laminas 전환을 선택한 이유와 검토했던 대안
• 변경 전후의 패키지, 테스트, 보안 감사 결과
• 로컬 실행 명령과 필요한 PHP 확장 모듈
• 남아 있는 기술 부채와 다음 개선 계획

채용 담당자가 확인하기 쉬운 증거

저장소에는 너무 많은 배지를 붙이지 않고 CI 통과 여부, 지원 PHP 버전, 라이선스 정도만 표시했습니다. 별도 문서에는 주요 아키텍처 흐름과 마이그레이션 전후 패키지 표를 넣었습니다. 누구나 10분 안에 실행 여부를 판단하도록 구성한 것이 체감상 가장 큰 개선이었습니다.

개발 결과물을 체계적으로 보여 주는 목적은 포트폴리오 관련 참고 설명처럼 분야가 달라도 공통적입니다. 다만 개발자 포트폴리오에서는 예쁜 화면만큼 재현성과 변경 근거가 중요합니다.

2026년 기준 공개 전 최종 점검표

보안과 재현성은 반드시 분리해 확인했습니다

공개 직전에는 기능 테스트가 통과했다는 이유로 곧바로 배포하지 않았습니다. 저장소 이력에 비밀키가 남아 있는지, 예제 환경 변수에 실제 계정 정보가 들어 있지 않은지, 개발용 디버그 화면이 노출되는지를 따로 확인했습니다. 특히 과거 커밋에 비밀 정보가 있었다면 현재 파일에서 삭제하는 것만으로는 부족하므로 키를 폐기하고 새로 발급해야 합니다.

Composer 감사 결과도 캡처 한 번으로 끝내지 않고 CI에서 반복 실행하도록 구성했습니다. 2026년 현재 Composer의 정책 설정은 변화가 이어지고 있으므로 예전 config.audit 예제만 복사하기보다 현재 문서를 기준으로 config.policy와 감사 실패 조건을 확인하는 편이 안전합니다. PHP 버전 역시 지원 종료 날짜를 주기적으로 확인해야 합니다.

마지막으로 데모 서버가 없어도 평가할 수 있도록 샘플 환경 파일, 익명화된 시드 데이터, 설치 순서, 예상 출력, 문제 해결 항목을 제공했습니다. 여러분의 저장소를 처음 보는 사람이 설명 없이 실행할 수 있을까요? 이 질문에 자신 있게 답할 수 있어야 소프트웨어 프로젝트 포트폴리오가 단순한 코드 보관함을 넘어섭니다.

• 저장소 전체 이력에 API 키, 비밀번호, 개인정보가 없는지 검사합니다.
• 지원 중인 PHP 버전에서 새로 설치하고 테스트합니다.
• composer audit --locked 결과와 중단된 패키지를 확인합니다.
• 프로덕션에서 디버그 모드와 상세 오류 출력을 끕니다.
• README 명령을 빈 환경에서 그대로 따라 해 봅니다.
• 전후 비교 수치의 측정 조건과 한계를 함께 기록합니다.

직접 해 보고 남은 현실적인 판단

Zend Framework 1처럼 지원이 끝난 구조는 자동 전환 범위가 제한적이므로 부분 수정만 반복하기보다 재작성이나 단계적 기능 분리를 비교해야 합니다. 반대로 Zend Framework 2·3 기반이고 테스트 가능한 핵심 로직이 많다면 Laminas 전환 자체가 좋은 현대화 사례가 될 수 있습니다.

제가 체감한 가장 큰 이익은 화려한 기능 추가가 아니라 프로젝트의 현재 상태를 정확히 설명할 수 있게 된 점이었습니다. 시간은 소규모 개인 프로젝트 기준 주말 이틀과 평일 저녁 몇 차례가 들었지만, 테스트가 거의 없거나 외부 연동이 많다면 더 넉넉하게 잡아야 합니다. 공개 전에는 자동화 범위, 남은 위험, 실행 가능한 PHP 버전을 솔직하게 적는 것이 가장 좋은 사용 팁입니다.

1. 코드 가치가 남아 있는지 먼저 평가합니다.
2. 자동 변환이 지원되는 Zend 세대인지 확인합니다.
3. 기능 유지와 PHP 상향을 서로 다른 단계로 나눕니다.
4. 측정 가능한 결과를 README와 커밋에 남깁니다.
5. 지원 종료 일정과 보안 감사를 정기 점검 항목으로 등록합니다.