AI 시대의 프로젝트 구조와 기술 스택 선택 기준

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

AI가 구현 시간을 줄여줘도 프로젝트를 어디서 나눌지, 어떤 기술을 쓸지까지 생성 속도만으로 결정할 수는 없다. 결과물을 검토할 사람, 팀이 일하는 방식, 실패했을 때 감당할 비용이 여전히 선택의 기준이다.

모든 프로젝트에 복사할 수 있는 하나의 ‘AI 네이티브 구조’는 없다. 지금 프로젝트가 어느 정도의 분리와 전문화를 감당할 수 있는지부터 봐야 한다.

프로젝트 경계는 팀의 형태를 따라간다

소수 인원이 움직이는 팀이나 개인 프로젝트라면 프론트엔드와 백엔드 저장소를 따로 운영할 실익이 작을 수 있다. 발표자는 개인 프로젝트에서 서버 렌더링 방식의 화면과 백엔드를 한 프로젝트에 넣어 실험했다. AI 덕분에 이런 시도를 쉽게 해볼 수 있었을 뿐, 모든 프로젝트를 합쳐야 한다는 결론은 아니다.

전문 직군과 충분한 엔지니어가 이미 있는 조직이라면 판단이 달라진다. 백엔드 개발자가 에이전트로 프론트엔드 코드를 만들 수 있어도 세부 결과가 타당한지 판단하려면 해당 분야의 전문성이 필요하다. 다른 분야의 코드를 생성하는 능력과 그 코드를 전문적으로 검토하는 능력은 같지 않다.

따라서 프로젝트 경계는 그 구조를 계속 운영할 조직과 맞아야 한다. 한 사람이 기능 전체를 넘나드는 작은 팀이라면 저장소 하나가 인수인계를 줄일 수 있다. 반대로 전문 인력이 큰 영역을 각각 맡는다면 프로젝트 분리가 집중할 경계를 지켜줄 수 있다.

익숙한 기술은 생성된 코드를 판단하게 해준다

AI 에이전트는 팀이 잘 모르는 언어로도 코드를 만들 수 있다. 그러나 그 결과가 맞는지 판단할 능력까지 팀에 만들어 주지는 않는다.

발표자는 자신이 익숙한 백엔드 기술을 주로 쓴다. 특별히 새롭기 때문이 아니라, AI가 만든 코드가 미심쩍을 때 추측하지 않고 직접 검토할 수 있기 때문이다. 에이전트의 생성 효율만 보고 낯선 기술을 택하면 타이핑에서 아낀 비용이 검증과 복구로 옮겨갈 수 있다.

새 기술을 실험하지 말라는 뜻은 아니다. 개인 프로젝트에서는 충분히 탐색할 수 있다. 회사의 기술 스택을 바꾸는 일이라면 누가 리뷰하고 운영할지, 도입한 사람이 떠난 뒤에도 고칠 수 있을지를 함께 봐야 한다. 그 비용을 받아들일 수 있는 조직 단위에서 결정할 문제다.

학습도 마찬가지다. 가고 싶은 회사가 특정 기술 스택을 사용한다면 그 목표는 여전히 학습 방향에 현실적인 의미를 준다. AI가 코드를 쓸 수 있다는 이유만으로 언어와 프레임워크가 이미 중요하지 않다고 단정하기는 이르다.

사람의 검토 범위를 실패 비용에 맞춘다

가장 어려운 변수는 AI가 코드를 얼마나 많이 만드느냐가 아니다. 사람이 그중 어디까지 확인할 것인지다.

위험이 낮은 실험이라면 종단 간 동작만 확인하고 넘어가는 전략을 택할 수도 있다. 하지만 돈이나 계약을 다루거나, 실패에 민감한 사용자가 많은 소프트웨어라면 같은 전략을 적용하기 어렵다. 어느 수준까지 리뷰할지는 제품과 팀의 판단이지 모든 곳에 통하는 규칙이 아니다.

구조도 같은 방식으로 조절해야 한다. 발표자는 AI와 만드는 프로젝트를 단일 모듈까지 단순화해 봤다가 지나친 선택이었다고 판단했다. 그렇다고 곧바로 많은 모듈과 계층으로 돌아가자는 뜻은 아니다. 사람이 결과를 이해하고 판단할 최소한의 구조는 남겨야 한다는 경험에 가깝다.

AI는 여러 구조를 시험하는 비용을 낮춰준다. 그 장점을 작은 실험에 쓰고, 팀의 전문성과 제품 위험에 맞는 경계, 기술 스택, 리뷰 방식을 남기는 편이 현실적이다.