AI로 만든 개인 프로젝트, 채용에서 어떻게 평가할까?

AI 도구의 도움을 받아 개인 프로젝트를 만드는 일은 이제 흔합니다. 그렇다면 채용하는 쪽은 그 프로젝트를 어떻게 볼까요? 정답은 회사마다 다르지만, 도구를 썼는지 여부보다 "그 프로젝트를 얼마나 이해하고 책임지는가" 를 본다는 점은 공통으로 말할 수 있습니다.

도구를 썼다는 사실 자체가 기준은 아니다

AI 도구를 활용해 개발하는 것은 점점 일반적인 작업 방식이 되고 있습니다. 그래서 "썼다/안 썼다"가 핵심 평가 항목이 되는 경우는 많지 않습니다. 대신 이런 질문이 나옵니다.

• 이 프로젝트의 구조를 직접 설명할 수 있는가
• 중요한 결정을 누가, 왜 내렸는가
• 잘못된 부분을 찾아 고칠 수 있는가
• 만든 뒤에 검증하고 운영했는가

평가에서 보는 다섯 가지

1. 이해도

• 특정 파일이나 함수를 가리키며 "여기는 왜 이렇게 되어 있나요?"라고 묻는 경우가 많습니다. 코드를 읽어 보고 의도와 한계를 설명할 수 있어야 합니다.

2. 기술적 판단

• 선택한 구조, 라이브러리, 데이터 모델의 이유. 도구가 제안했더라도 내가 받아들인 이유를 말할 수 있으면 됩니다.

3. 검증

• 테스트, 실제 사용, 오류 확인 같은 검증의 흔적이 있는가. 생성된 코드가 의도대로 동작하는지 확인한 경험은 가장 중요한 증거 중 하나입니다.

4. 문제 해결 과정

• 막혔을 때 어떻게 원인을 좁혔는지. 도구의 답이 틀렸을 때 어떻게 알아챘는지.

5. 지속성

• 처음 만든 뒤에도 고치고, 정리하고, 운영한 이력이 있는가.

이력서에 AI 활용을 쓰는 방법

숨길 필요는 없고, 과장할 필요도 없습니다. 핵심은 정직한 범위입니다.

예시(재구성한 문장입니다)

• 약함: 개인 서비스 개발 (AI로 전체 구현)

• 강함: 반복 업무를 줄이기 위한 개인 서비스를 설계하고 운영. 초안 코드 작성에 AI 도구를 활용했고, 데이터 구조와 예외 처리 기준은 직접 설계. 생성된 코드는 테스트를 추가해 검증하고, 성능 문제가 생겼을 때 원인을 분석해 조회 방식을 변경

두 번째 문장은 무엇을 도구에 맡기고, 무엇을 내가 결정했고, 어떻게 확인했는지를 보여 줍니다. 이런 문장은 도구 사용 여부와 상관없이 신뢰를 줍니다.

피해야 할 것

• 이해하지 못한 코드를 내 구현처럼 서술하기: 면접에서 한 번만 깊이 물어도 드러납니다.
• 규모와 성과를 부풀리기: 사용자 수, 트래픽 등은 확인 가능한 범위로만 씁니다.
• 도구 이름 나열: 어떤 도구를 썼는지보다 무엇을 판단했는지가 중요합니다.
• 만들기만 하고 끝내기: 배포·검증·개선이 없는 프로젝트는 인상이 약합니다.

학습이 목적이었다면

도구로 빠르게 만든 결과물이 있다면, 그 안에서 핵심 부분 하나를 도구 없이 직접 다시 구현해 보세요. 그 경험은 이해도를 확실히 증명해 줍니다. 면접에서 "이 부분은 직접 다시 만들어 보며 이해했다"고 말할 수 있는 힘은 큽니다.

포트폴리오에 넣으면 좋은 증거

• 설계 이유와 대안을 정리한 짧은 문서
• 테스트 코드와 실행 결과
• 장애·오류를 만났을 때 대응한 기록
• 개선 전후의 변화
• 이후 유지보수의 이력

점검 질문

1. 이 프로젝트에서 내가 직접 결정한 것 세 가지를 말할 수 있는가
2. 가장 중요한 코드 한 군데를 열어 한 줄씩 설명할 수 있는가
3. 도구가 틀렸던 사례와 내가 바로잡은 방법이 있는가
4. 이 프로젝트를 지금 다시 만든다면 무엇을 바꾸겠는가

도구는 빠르게 만들어 줍니다. 그러나 이해하고 책임지는 사람이 있어야 프로젝트가 경험이 됩니다.