새벽에 장애 난 PHP 프로젝트를 개발자 포트폴리오로 바꾸는 법

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

새벽 두 시, PHP 서비스가 갑자기 느려지고 로그에는 정체불명의 경고가 쌓입니다. 급히 장애를 복구한 뒤 기록을 닫아 버리기 쉽지만, 바로 그 순간이 개발자 포트폴리오에 실무 역량을 남길 절호의 기회입니다. 완성된 화면보다 문제를 관찰하고 가설을 좁혀 해결한 과정이 훨씬 강한 증거가 되기 때문입니다.

장애가 끝난 직후 15분을 포트폴리오에 남기는 법

기억보다 타임라인을 먼저 저장합니다

서비스가 정상화되면 코드부터 다듬고 싶어집니다. 하지만 시간이 지나면 명령어 실행 순서, 최초 증상, 잘못 짚었던 원인이 빠르게 흐려집니다. 복구 직후에는 문장력을 고민하지 말고 발견 시각·사용자 증상·첫 대응·정상화 시각만 분 단위로 기록합니다.

잘 알려지지 않은 요령은 셸 히스토리를 그대로 복사하지 않고 명령의 목적을 옆에 붙이는 것입니다. 예를 들어 top 실행이 아니라 ‘CPU 병목 여부를 배제하기 위해 top 확인’이라고 적으면 판단 과정이 드러납니다. 포트폴리오의 기본 개념이 궁금하다면 Portfolio 용어 설명도 참고할 수 있습니다.

• 장애 전 마지막 정상 배포 시각을 적습니다.
• 사용자가 본 현상과 서버에서 관찰한 현상을 분리합니다.
• 효과가 없었던 조치도 한 줄 남깁니다.
• 회사명, IP, 계정, 토큰은 기록 단계부터 가립니다.

숨은 팁: 복구 직후 자신에게 30초짜리 음성 메모를 남기면 글을 쓸 때 당시 판단 근거와 긴박도를 훨씬 정확하게 복원할 수 있습니다.

에러 로그를 공개 가능한 증거로 바꾸는 익명화 기술

지우기보다 같은 형태로 치환합니다

실무 로그에는 도메인, 고객 식별자, 내부 경로와 데이터베이스 이름이 섞여 있습니다. 모두 삭제하면 맥락까지 사라지므로 일관된 가상 값으로 치환하는 편이 낫습니다. 실제 호스트명을 app.internal.test로, 주문 번호를 ORDER-1042로 바꾸되 문서 전체에서 같은 값은 같은 이름으로 유지합니다.

PHP 스택 트레이스는 전체를 캡처하지 말고 원인 파악에 기여한 앞뒤 몇 줄만 텍스트로 제시합니다. 화면 이미지보다 검색과 복사가 가능하고 접근성도 좋습니다. 다만 정규식으로 자동 마스킹했더라도 이메일, 세션 ID, 쿼리 문자열이 남았는지 별도로 확인해야 합니다. 공개 저장소에 올린 뒤 지우는 방식은 Git 기록에 비밀이 남을 수 있어 안전하지 않습니다.

1. 원본은 공개 저장소 밖에 보관합니다.
2. 샘플 복사본에서 도메인과 식별자를 치환합니다.
3. grep이나 rg로 회사명과 이메일 패턴을 재검색합니다.
4. 동료가 맥락 없이 읽어도 민감 정보를 추론할 수 없는지 확인합니다.

‘보안상 일부 값을 변경했으며 기술적 인과관계는 유지했다’는 안내를 덧붙이면 자료의 신뢰도도 지킬 수 있습니다. 비공개 업무를 허락 없이 공개하는 대신 구조가 같은 미니 재현 프로젝트를 만드는 것이 핵심입니다.

거대한 서비스 대신 20분짜리 재현 저장소를 만듭니다

실패 조건 하나만 살아 있으면 충분합니다

장애를 설명하려고 회사 서비스를 통째로 복제할 필요는 없습니다. PHP 파일 하나, 작은 SQLite 데이터베이스, Docker 설정으로 문제가 발생하는 최소 조건만 보존하세요. 면접관이 저장소를 내려받아 20분 안에 실패와 수정 결과를 모두 확인할 수 있다면 화려한 데모보다 설득력이 높습니다.

예를 들어 반복 쿼리 때문에 응답이 느려졌다면 가짜 상품 1,000개를 생성하고, 수정 전 코드에서는 요청마다 쿼리가 늘어나도록 구성합니다. 수정 후에는 조인이나 일괄 조회를 적용해 실행 횟수와 응답 시간을 함께 표시합니다. 단, 측정값은 장비에 따라 달라지므로 ‘평균 42ms’처럼 고정 성능을 약속하기보다 측정 환경과 여러 번 실행한 중앙값을 씁니다.

• make broken: 의도적으로 장애 조건을 실행합니다.
• make fixed: 수정된 경로를 같은 데이터로 실행합니다.
• make test: 회귀 테스트로 차이를 검증합니다.
• make clean: 생성 데이터를 제거해 재실행을 쉽게 만듭니다.

Zend Framework 같은 구형 구조를 다룬 사례라면 최신 프레임워크로 억지로 바꾸지 않아도 됩니다. 레거시 제약을 이해하고 위험을 작게 줄인 판단 자체가 프로젝트의 주제입니다. README 첫 화면에는 요구 PHP 버전, 예상 실행 시간, 실패가 정상인 단계부터 명확히 적어 두세요.

남들이 빼먹는 실패 가설을 사례의 중심에 놓습니다

정답보다 배제 과정이 실력을 보여 줍니다

많은 개발자 포트폴리오가 ‘캐시를 적용해 해결했다’는 한 줄에서 끝납니다. 그러나 실무자는 왜 데이터베이스, 네트워크, PHP-FPM 중 특정 원인을 먼저 의심했는지 궁금해합니다. 따라서 원인 후보를 표처럼 나열하고 각 후보를 어떤 관찰로 배제했는지 보여 주면 디버깅 능력이 선명해집니다.

HTML 표를 넣을 때는 항목을 과도하게 늘리지 않습니다. 예를 들어 ‘가설, 확인 방법, 관찰 결과, 판단’ 네 열이면 충분합니다. CPU 사용률이 낮았다는 사실만으로 애플리케이션 병목이 아니라고 단정하지 말고, 요청 대기열과 느린 쿼리 기록을 함께 봤다는 식으로 판단의 한계도 적어야 신뢰를 얻습니다.

포트폴리오의 일반적인 의미처럼 결과물을 모으는 데 그치지 않고, 개발 사례에서는 선택의 이유까지 편집해야 합니다. 실패한 첫 가설 하나를 숨기지 않고 공개하면 ‘처음부터 답을 알았다’는 인위적인 인상도 줄일 수 있습니다.

성과 숫자가 없을 때도 설득력을 높이는 측정 요령

회사 매출 대신 기술 지표를 전후로 맞춥니다

개인 프로젝트나 내부 도구는 매출과 사용자 수를 공개하기 어렵습니다. 이때 ‘성능이 크게 개선됐다’고 쓰지 말고 수정 전후에 같은 조건으로 얻을 수 있는 쿼리 수, 메모리 최고점, 오류 재현율, 테스트 실행 시간을 사용합니다. 숫자의 크기보다 비교 조건이 동일한지가 중요합니다.

숨은 요령은 평균값 하나만 제시하지 않는 것입니다. 느린 요청이 문제였다면 중앙값과 상위 95% 지연 시간을 함께 기록하고, 처음 한 번의 워밍업 결과는 분리합니다. 로컬 측정이라면 CPU, 메모리, PHP 버전, 데이터 개수를 짧게 밝혀 과장으로 보이지 않게 합니다. 정확한 운영 수치를 공개할 수 없다면 가상 데이터에서 얻은 값임을 분명히 표시하세요.

• 전: 상품 1,000개 조회 시 쿼리 1,001회
• 후: 동일 데이터에서 쿼리 2회
• 검증: 결과 집합이 같은지 자동 테스트로 비교
• 주의: 로컬 시간 수치를 운영 환경 성능처럼 표현하지 않기

좋은 성과 문장은 ‘몇 퍼센트 빨라졌다’에서 멈추지 않습니다. 무엇을 고정하고, 무엇을 측정했으며, 어떤 부작용을 확인했는지까지 포함합니다.

캐시를 넣었다면 속도뿐 아니라 데이터 갱신 지연이라는 대가도 적습니다. 인덱스를 추가했다면 쓰기 비용과 저장 공간을 확인합니다. 이런 작은 단서가 프로젝트를 단순 성공담이 아니라 실제 운영 판단의 기록으로 바꿉니다.

바쁜 채용 담당자와 깊게 보는 개발자에게 다르게 보여 줍니다

한 저장소 안에 두 개의 읽기 경로를 만듭니다

같은 포트폴리오라도 독자가 쓸 수 있는 시간은 다릅니다. 첫 화면에는 60초 안에 읽는 요약을 두고, 세부 분석은 별도 문서로 연결하세요. 요약에는 증상, 원인, 조치, 검증을 각각 한 문장으로 적습니다. 깊게 보는 독자를 위해서는 타임라인, 재현 명령, 가설 표, 벤치마크 원본을 남깁니다.

의외로 유용한 장치는 README에 ‘어디부터 볼까요?’라는 분기 메뉴를 넣는 것입니다. 코드를 보고 싶은 사람은 수정 커밋으로, 운영 판단을 보고 싶은 사람은 사고 기록으로 바로 이동하게 합니다. 커밋도 한 번에 모두 올리지 말고 재현 테스트, 수정, 회귀 방지 순으로 나누면 프로젝트의 사고 흐름이 자연스럽게 보입니다.

1. 첫 화면에 네 문장짜리 장애 요약을 배치합니다.
2. 수정 전후 diff로 연결되는 고정 링크를 만듭니다.
3. 실행이 어려운 독자를 위해 30초 이하 터미널 녹화를 제공합니다.
4. 마지막에 ‘다시 한다면 바꿀 점’ 두 가지를 적습니다.

지원서를 빠르게 검토받아야 하는 독자라면 한 화면 요약과 전후 숫자를 우선 선택하세요. 반대로 PHP·Linux 운영 역량을 깊게 증명하려는 독자라면 최소 재현 저장소와 실패 가설 기록에 시간을 더 쓰는 편이 좋습니다. 전자는 발견 속도를 높이고, 후자는 기술 면접에서 이어질 질문의 질을 높여 줍니다.