AI 프로젝트가 늘어난 요즘, 기업이 좋아하는 포트폴리오 프로젝트 구조

AI 기능이 많아진 지금, 기업이 보는 포인트는 달라졌습니다.

 

현업 팀장 관점에서, 요즘 포트폴리오를 보다 보면
AI 기능이 포함된 프로젝트가 꽤 많아졌습니다.

 

추천, 요약, 분류 같은 기능은
이제 특별하다기보다 자연스러운 선택이 됐습니다.

 

그래서 프로젝트를 볼 때
AI를 썼는지보다,
그 프로젝트가 어떤 구조로 설계됐는지가 더 중요해졌습니다.

 

같은 AI 기능이 들어가 있어도
어떤 프로젝트는 바로 이해가 되고,
어떤 프로젝트는 설명이 어렵습니다.

그 차이는 대부분 구조에서 나옵니다.

 

결론부터 말하면 이렇습니다.
기업은 포트폴리오 프로젝트에서
복잡한 구조를 기대하지 않습니다.

대신,

• 왜 이 구조를 선택했는지
• 어디까지를 고려했고
• 어디부터는 과하다고 판단했는지

이게 설명 가능한 구조를 선호합니다.

그래서 MSA를 구현한 프로젝트보다,
단순해도 판단의 근거가 남아 있는 프로젝트가
더 좋아 보이는 경우가 많습니다.

기업이 좋아하지 않는 프로젝트 구조의 특징

1. 구조가 목적이 되어버린 경우

포트폴리오에서 종종 이런 설명을 봅니다.

• MSA 구조 적용
• 서비스 분리
• 복잡한 인프라 구성

기술적으로 틀린 선택은 아닙니다.
다만 문제는, 왜 이 구조가 필요한지 설명이 없는 경우입니다.

“이 정도 규모에서 이 구조가 꼭 필요했나요?”
이 질문에 답이 안 나오면 구조는 장점이 아니라 부담이 됩니다.

 

2. 기능 단위로만 쪼개진 구조

기능별로만 나뉜 구조는 겉보기엔 정리돼 보이지만,
프로젝트의 맥락을 이해하기 어렵게 만듭니다.

• API는 있지만, 흐름이 보이지 않고
• 컴포넌트는 있지만, 역할이 분명하지 않은 경우

이런 구조에서는 AI 기능이 들어가 있어도
프로젝트 전체 그림이 잘 보이지 않습니다.

 

3. 운영을 전혀 가정하지 않은 구조

AI 기능이 포함된 프로젝트일수록 이 부분이 더 중요해집니다.

• AI 호출이 실패하면 어떻게 되는지
• 응답이 느려지면 서비스는 어떻게 반응하는지
• 비용이나 사용량에 대한 고려가 있었는지

이런 고민이 보이지 않으면 프로젝트는 데모에 가까워 보입니다.

반대로, 기업이 좋아하는 프로젝트 구조는 이렇습니다

1. 전체 흐름이 먼저 보입니다

좋은 프로젝트는 코드 구조를 보기 전에
서비스 흐름이 먼저 이해됩니다.

• 사용자가 무엇을 입력하고
• 어떤 처리를 거쳐
• 어떤 결과를 받는지

AI 기능은 이 흐름 안에 자연스럽게 포함돼 있고,
구조를 설명할 때도 기술보다 이야기가 먼저 나옵니다.

 

2. AI 기능이 하나의 구성 요소로 자리 잡습니다

• 입력과 출력이 명확하고
• 다른 컴포넌트와의 경계가 분명하고
• 실패했을 때의 동작도 정의돼 있습니다

이러면 AI는 특별한 기능이 아니라
시스템의 일부로 보이게 됩니다.

 

3. 복잡해지기 전의 기준이 설명됩니다

지금 단계에서는 왜 이 구조가 적절한지,
나중에 어떻게 확장할 수 있는지 설명돼 있다면
구조는 충분히 설득력을 가집니다.

README에서 이 부분이 드러나면 좋습니다

• 서비스 전체 흐름 요약
• 주요 컴포넌트의 역할
• AI 기능이 들어간 위치와 이유
• 구조적으로 고민했던 지점

코드보다 먼저 생각의 구조가 보이면
질문이 자연스럽게 따라옵니다.

 

프로젝트를 제대로 준비하고, 이력서로 합격하고 싶다면

아래 프로그램을 참고해 보셔도 좋습니다.

👉 취업용 프로젝트 개발하기 4주 완성