이직에 바로 쓰는 프론트엔드 AI 실무: 면접관을 설득하는 작업 로그북 운영법
요즘 Velog 트렌딩을 보면 AI 관련 글이 많이 보입니다. 공통점은 “짧은 기간에 많이 만들었다”는 속도 중심 서사입니다.
속도 자체는 분명 강점입니다. 다만 이직 면접에서는 여기서 한 단계 더 들어옵니다.
- 무엇을 자동화했고
- 어디서 사람이 개입했으며
- 어떤 기준으로 배포 여부를 결정했는지
즉, 결과보다 의사결정 기록을 묻습니다.
이번 글은 그 질문에 답하기 위한 실무형 문서, 작업 로그북(Work Logbook) 운영법을 다룹니다. 이미 다뤘던 AI 코드리뷰 실무 적용 플레이북, AI 산출물 검증 스코어카드 운영법, Playwright 기반 E2E Eval 운영 가이드와 연결해서 보면 더 효과적입니다.
왜 로그북이 이직에 강한가
포트폴리오에서 가장 자주 나오는 문장은 다음과 같습니다.
“AI로 개발 생산성을 크게 높였습니다.”
문제는 이 문장만으로는 신뢰를 만들기 어렵다는 점입니다. 면접관 관점에서는 아래가 빠져 있기 때문입니다.
- 재현 가능한가?
- 실패를 통제했는가?
- 팀에 이식 가능한 방식인가?
로그북은 이 3가지를 동시에 해결합니다.
- 재현성: 같은 프롬프트/같은 조건에서 결과를 다시 낼 수 있음
- 리스크 통제: 실패 패턴과 차단 규칙이 문서화됨
- 팀 확장성: 개인 요령이 아닌 운영 기준으로 공유 가능
로그북 최소 구조 (복잡하게 시작하지 말기)
처음부터 거대한 템플릿을 만들면 대부분 2주 안에 무너집니다. 아래 5칸만 고정해도 충분합니다.
1) 작업 맥락
- 기능/버그 제목
- 사용자 문제 한 줄
- 제한 조건(시간, 브라우저, 레거시 제약)
2) AI 입력
- 사용한 모델/도구
- 핵심 프롬프트 요약
- 참고한 코드/문서 경로
3) 사람의 개입 지점
- 구조 변경 결정 이유
- 보안/접근성/성능 리스크 판단
- AI 제안 반려 사유
4) 검증 결과
- 테스트 통과 여부
- 성능 변화(LCP/INP/CLS)
- 에러 로그 유무
5) 최종 결정
- 배포 / 보류 / 롤백
- 근거 3줄
- 다음 반복에서 개선할 1가지
핵심은 “많이 쓰기”가 아니라 결정의 근거를 남기기입니다.
실무 예시: 검색 결과 페이지 필터 리팩터링
면접에서 설명 가능한 형태로 로그를 남기려면, 결과보다 분기점을 기록해야 합니다.
상황
- 증상: 태그 필터 변경 시 렌더링 지연 체감
- 제약: 기존 URL 쿼리와 하위 호환 유지 필요
AI 초안 결과
- 필터 상태를 전역 store로 승격
- 연산을 selector로 분리
- 코드량은 줄었지만 hydration mismatch 가능성 발생
사람의 결정
- 전역 승격은 보류
- 로컬 상태 + debounce + URL 동기화 유지
- 이유: 현재 트래픽 규모에서 단순 구조가 운영 리스크가 낮음
검증
- E2E: 주요 사용자 시나리오 통과
- 성능: 타이핑 시 불필요 연산 감소
- 회귀: 기존 공유 링크 동작 정상
최종
- 배포 승인
- 로그북에 “전역 상태화는 트래픽/복잡도 증가 시 재평가” 항목 추가
이 구조를 유지하면 “AI가 이렇게 하라 해서 했다”가 아니라, 엔지니어로서 통제했다는 메시지가 됩니다.
바로 붙여 쓰는 로그북 템플릿
## Work Logbook
### 1) 작업 맥락
- 작업명:
- 사용자 문제:
- 제약 조건:
### 2) AI 입력
- 도구/모델:
- 핵심 프롬프트:
- 참고 컨텍스트:
### 3) 사람 개입 지점
- 채택한 제안:
- 반려한 제안:
- 최종 설계 근거:
### 4) 검증 결과
- 테스트:
- 성능 지표(LCP/INP/CLS):
- 모니터링/에러 로그:
### 5) 최종 결정
- 결과(배포/보류/롤백):
- 근거:
- 다음 반복 개선 1가지:PR 본문에 이 블록을 붙이고, 점수화는 AI 산출물 검증 스코어카드와 함께 쓰면 면접 자료로 바로 전환됩니다.
1주 운영 루틴 (이직 준비 버전)
월/화: 기능 1개 선정 + 로그 시작
- 사용자 영향이 있는 기능만 선택
- AI에게 초안 생성 → 사람이 구조 결정
- 로그북 1~3항목 작성
수/목: 검증 + 리스크 문서화
- E2E/접근성/성능 확인
- 실패 1건 이상을 반드시 기록
- “왜 보류했는지”를 명시
금: 포트폴리오 반영
- 전/후 비교(코드, 지표, 결정 근거) 1장으로 요약
- README/회고 문서에 링크
- 다음 주 개선 실험 1개 예약
중요한 건 완벽한 성공 사례가 아니라, 의사결정 품질의 반복입니다.
면접에서 이렇게 말하면 강하다
아래 3문장 구조로 답변하면 전달력이 좋습니다.
- “AI로 초안은 빠르게 만들었습니다.”
- “하지만 배포 기준은 로그북과 스코어카드로 통제했습니다.”
- “그 결과, 기능 속도뿐 아니라 회귀 리스크를 줄였고 팀 공유가 가능해졌습니다.”
이 답변은 도구 자랑이 아니라, 제품 개발자의 판단력을 보여줍니다.
마무리
AI 시대 프론트엔드 이직에서 차이를 만드는 건 “얼마나 빨리 만들었는가”보다 다음입니다.
- 기준이 있었는가
- 실패를 기록했는가
- 그 기록이 다음 배포 품질을 올렸는가
로그북은 거창한 문서 작업이 아닙니다. 당신의 판단을 증명하는 최소 단위입니다.
다음 사이드 프로젝트부터 한 주만 운영해 보세요. 포트폴리오의 밀도가 확실히 달라질 겁니다.