AI로 만든 걸 올려도 되나 하는 찜찜함, 그 고민 자체가 이미 나쁘지 않은 신호입니다. 결론부터 말하면 AI를 썼다는 사실은 그 자체로 감점 요인이 아닙니다. 지금은 현업에서도 대부분 쓰고 있고, 평가하는 쪽도 그걸 모르지 않습니다. 문제가 되는 건 AI를 썼다는 게 아니라, 그렇게 나온 결과물을 본인이 설명하지 못하는 경우입니다.
면접에서 깃허브를 보는 방식이 생각보다 단순합니다. 코드가 예쁜지를 보는 게 아니라 레포 하나를 찍어서 왜 이 구조로 갔는지, 만들다가 어디서 막혔고 어떻게 해결했는지, 다른 선택지는 왜 버렸는지를 묻습니다. 여기서 대답이 막히면 그 레포는 안 올린 것보다 오히려 마이너스가 됩니다. 반대로 초안은 AI로 빠르게 뽑고 이 부분이 이런 이유로 위험해서 이렇게 바꿨다는 말이 나오면 그건 확실한 플러스입니다. 도구를 잘 쓰는 사람으로 보이니까요.
그래서 지금 하실 일은 개수를 늘리는 게 아니라, 있는 걸 설명 가능한 상태로 만드는 쪽입니다. 완성본을 한 번에 커밋하지 말고 시행착오가 히스토리에 남도록 쪼개서 올리고, 리드미에 왜 만들었는지, 어떤 선택을 했고 무엇을 포기했는지, 알려진 한계는 무엇인지를 적어두세요. AI를 썼다는 걸 숨기기보다 이 부분은 생성된 코드라 이런 식으로 검증했다고 적는 편이 오히려 신뢰를 얻습니다.
정보보호 전공이면 방향이 조금 더 분명합니다. 잡다한 유틸 여러 개보다 도메인 깊이가 남는 산출물이 훨씬 세게 먹힙니다. 특정 취약점을 직접 재현해보고 왜 그렇게 터지는지 정리한 레포, 탐지 규칙을 짜고 오탐을 어떤 식으로 줄였는지 기록한 것, CTF 풀이 기록, 공개된 취약점 하나를 골라 원리와 패치 지점까지 뜯어본 글 같은 것들이요. 이런 건 AI가 초안을 도와줘도 본인 이해가 없으면 끝까지 못 씁니다. 실습은 당연히 본인 환경이나 허가된 대상에서만 하시고요.
정리하면 잡동사니 열 개보다 끝까지 설명할 수 있는 두세 개가 낫습니다. 이미 올리신 것들을 지울 필요는 없고, 그중 애착이 가는 한두 개만 골라 리드미와 테스트를 붙여 다듬어 보세요. 그걸 다듬는 과정에서 배우는 것이 사실 포트폴리오의 본체입니다.