EF Core Code First와 AI 코딩 도구의 궁합을 다시 봅니다

닷넷으로 작은 서비스를 만들다 보면 데이터베이스 작업이 생각보다 자주 발목을 잡습니다. 테이블을 먼저 설계하고, 그에 맞춰 모델을 만들고, 다시 API 코드를 연결하는 흐름은 익숙하지만 손이 많이 갑니다. 그래서 요즘은 Entity Framework Core의 Code First 방식이 다시 편하게 느껴집니다.

특히 VS Code에서 Codex나 Claude Code 같은 AI 코딩 도구를 함께 사용할 때, Code First 방식은 궁합이 꽤 좋습니다. 이유는 단순합니다. 데이터 구조가 C# 코드 안에 먼저 표현되기 때문입니다. AI 도구 입장에서도 엔티티 클래스, DbContext, 설정 코드, 마이그레이션 흐름을 한 프로젝트 안에서 읽고 이해하기가 좋습니다.

Code First는 데이터 구조를 코드로 남기는 방식입니다
EF Core는 닷넷 개발자가 데이터베이스를 .NET 객체로 다룰 수 있게 도와주는 ORM입니다. 복잡한 데이터 접근 코드를 많이 줄여주고, 여러 데이터베이스 공급자와 함께 사용할 수 있습니다.

Code First 방식에서는 먼저 C# 클래스로 엔티티를 정의합니다. 예를 들어 Post, User, Comment 같은 클래스를 만들고, DbContext에 DbSet으로 연결합니다. 그 다음 EF Core 마이그레이션을 통해 이 모델의 변화가 데이터베이스 스키마로 반영됩니다.

공식 문서에서도 EF Core 마이그레이션은 데이터 모델의 변경 사항에 맞춰 데이터베이스 스키마를 점진적으로 업데이트하는 기능으로 설명합니다. 실제 프로젝트에서는 기능이 늘어나면서 속성이 추가되거나 관계가 바뀌기 때문에, 이 흐름이 꽤 자연스럽습니다.

VS Code와 AI 도구는 코드 중심 흐름을 잘 따라옵니다
Codex의 VS Code 확장은 IDE 안에서 코드를 읽고, 수정하고, 실행하는 코딩 에이전트로 사용할 수 있습니다. Claude Code 역시 코드베이스를 이해하고 기능 구현, 버그 수정, 개발 작업 자동화를 돕는 도구로 안내되어 있습니다.

이런 도구들은 데이터베이스 안쪽을 직접 바라보기보다, 현재 열려 있는 프로젝트의 코드와 명령어 흐름을 기반으로 작업할 때 더 편합니다. EF Core Code First는 이 점에서 잘 맞습니다. 테이블 설계가 C# 클래스와 설정 코드로 표현되어 있으니, AI에게 “이 엔티티에 상태 값을 추가하고 마이그레이션까지 만들어줘”처럼 요청하기가 쉽습니다.

물론 AI가 만든 결과를 그대로 믿으면 안 됩니다. 데이터베이스 변경은 되돌리기 어려운 경우가 있기 때문에, 마이그레이션 파일과 생성된 SQL은 사람이 직접 확인해야 합니다. 그래도 초안을 만들고 반복 작업을 줄이는 면에서는 도움이 됩니다.

dotnet CLI 덕분에 흐름이 단순해졌습니다
VS Code에서 닷넷 개발을 할 때 중요한 장점은 대부분의 작업을 CLI로 처리할 수 있다는 점입니다. EF Core 도구는 마이그레이션 생성, 데이터베이스 업데이트 같은 설계 시점 작업을 .NET CLI로 수행할 수 있습니다.

예를 들어 엔티티를 수정한 뒤에는 dotnet ef migrations add 명령으로 변경 이력을 만들고, dotnet ef database update 명령으로 데이터베이스에 반영할 수 있습니다. 이 흐름은 AI 코딩 도구와도 잘 맞습니다. 명령어가 명확하고, 결과물이 파일로 남고, 변경 내용을 Git diff로 확인할 수 있기 때문입니다.

Visual Studio의 강한 도구 지원도 여전히 좋지만, VS Code 기반 작업은 가볍고 반복이 빠릅니다. 특히 작은 서비스나 개인 프로젝트에서는 에디터, 터미널, AI 도구, Git diff만으로도 꽤 안정적인 개발 흐름을 만들 수 있습니다.

궁합이 좋은 이유는 책임 경계가 보이기 때문입니다
AI 코딩 도구를 잘 쓰려면 프로젝트의 책임 경계가 코드에 드러나야 합니다. EF Core Code First는 이 점에서 장점이 있습니다. 엔티티는 데이터 구조를 표현하고, DbContext는 데이터베이스 연결과 모델 구성을 담당하며, 마이그레이션은 구조 변경 이력을 남깁니다.

이렇게 역할이 나뉘어 있으면 AI에게 작업을 맡길 때도 요청이 구체적이 됩니다. “게시글에 공개 여부를 추가해줘”, “조회용 DTO에는 작성자 이름만 포함해줘”, “마이그레이션 이름은 AddPostVisibility로 만들어줘”처럼 말할 수 있습니다. 요청이 구체적일수록 결과를 검토하기도 쉬워집니다.

저는 이 부분이 Code First와 AI 도구의 가장 큰 접점이라고 봅니다. AI가 모든 설계를 대신해주는 것이 아니라, 이미 코드 안에 드러난 구조를 따라 반복 작업을 빠르게 처리해주는 방식입니다.

그래도 기준은 사람이 잡아야 합니다
Code First가 편하다고 해서 모든 데이터베이스 설계를 가볍게 다뤄도 되는 것은 아닙니다. 인덱스, 관계, 삭제 정책, nullable 여부, 마이그레이션 순서 같은 부분은 여전히 사람이 판단해야 합니다. 특히 운영 중인 서비스에서는 마이그레이션 하나가 실제 데이터에 영향을 줄 수 있습니다.

AI 도구도 마찬가지입니다. Codex나 Claude Code는 좋은 보조자가 될 수 있지만, 프로젝트의 기준을 대신 정해주지는 않습니다. 어떤 이름을 쓸지, 어떤 관계를 허용할지, 어느 시점에 DB 변경을 배포할지는 결국 운영자가 결정해야 합니다.

그래서 저는 이 조합을 “자동 개발”이라기보다 “검토 가능한 초안을 빠르게 만드는 흐름”에 가깝게 보고 있습니다. 코드는 AI가 도와서 빠르게 만들 수 있지만, 기준과 책임은 여전히 사람에게 남습니다.

마무리
EF Core Code First, VS Code, Codex나 Claude Code 같은 AI 코딩 도구는 서로 잘 맞는 편입니다. 데이터 구조가 C# 코드로 표현되고, 마이그레이션은 파일로 남으며, CLI 명령으로 흐름을 반복할 수 있기 때문입니다.

작은 서비스를 혼자 만들고 운영하는 입장에서는 이런 단순한 흐름이 꽤 중요합니다. 복잡한 도구를 많이 붙이기보다, 코드로 구조를 남기고, AI에게 반복 작업을 맡기고, 사람은 변경 내용을 검토하는 방식이 현실적입니다.

결국 좋은 궁합은 도구가 똑똑해서만 생기는 것이 아닙니다. 사람이 이해할 수 있는 구조로 프로젝트를 정리해두었을 때, AI 도구도 그 구조를 따라 더 잘 도와줄 수 있습니다. EF Core의 Code First 방식은 그런 점에서 지금의 닷넷 개발 흐름과 잘 어울리는 선택지라고 느낍니다.