우선 제목에서 나왔듯이 약 한달간 spring 약 2만라인, flutter 약 1만라인 정도를 짰습니다.

당연히 손수 3만라인을 작성하기에는 하루 8~9시간으로는 턱도 없어요.

그러면 프로젝트의 메인 기능을 맡게 된 만 1년차 개발자가
AI를 도대체 어떻게 썼는지, 무엇을 깨달았는지 공유해드리겠습니다.

무슨 AI를 사용하셨나요?

---

요즘 다들 Claude에 열광합니다. Claude Code는 현존 최고의 코드 에이전트라고 해도 무방할 정도로 무섭게 명성을 쌓아가고 있죠.

하지만 제가 사용한 툴은 Gemini CLI 와 Cursor입니다.

이유는 간단했습니다. 제가 Gemini pro 6개월 무료이용권을 받아서, Cursor는 회사에서 결제해줘서죠.

만약 AI 코드 에이전트를 써보고 싶은데 돈값 잘 못할까봐 걱정되는 분들은 무료 사용량이 넉넉한 Gemini CLI로 시작하는 것을 강력 추천합니다.

저는 무료 사용기간이 끝나면 그때 Claude Code로 갈아탈 예정입니다.

AI와 협업하는 개발 루틴

---

실제 최근에 제가 지시한 내용은 아니고, 간단한 예시들 위주로 저만의 루틴을 공유해드리겠습니다.

1. 페르소나 설정 및 업무범위 지시

---

우선 저는 하루의 업무를 시작하기 전, 다음과 같이 지시합니다.

당신은 시니어급 코어 백엔드 엔지니어입니다.
오늘 당신은 저의 지시를 받아 <프로젝트 이름>의 개발을 진행할 부하직원 개발자입니다.

모든 작업은 **근거있는 계획** 하에 이루어져야 하며, 빌드를 통한 테스트를 해야 합니다.
작업 후에는 이전과 이후를 비교하여 **한국어**로 결과보고를 해야 합니다.

우선 오늘은 <프로젝트 이름>의 <하위 패키지>를 개발할 예정입니다.
전체 코드를 대략적으로 읽어 해당 서버의 기술 스택을 이해하고,
<하위 패키지>의 파일을 꼼꼼히 읽어 비즈니스와 로직을 파악하세요.

이 외에는 업무별로 강조하고 싶은 것을 추가로 작성하는 편입니다.

한국어를 굳이굳이 강조한 이유는 얘가 자꾸 영어를 뱉습니다. 저렇게 해놔도 자꾸 영어로 말할 때가 있긴 해요.

그리고 이렇게 코드를 많이 읽게 한다면 “토큰은 썩어나냐” 라고 할 수도 있는데 괜찮은 이유는 다음과 같습니다.

1. 코드를 읽어서 파악하게 할 때에는 gemini-3-flash-preview모델로 설정하여 토큰을 잘 사용하지 않는 모델로 파악하게 하여 캐시시켜 둡니다.
   개발 시에는 gemini-3-pro-preview모델로 변경하여 진행하기 때문에 캐시된 코드를 읽고 사고하는 것은 pro모델이라 사용량이 별개입니다.
2. 캐시라는 것이 존재하기 때문에 이렇게 해도 진짜 빡세게 하루종일 쓰지 않는 한 거의 부족하지 않습니다.

모든 판단을 AI에게 맡기지 않고 로직 설계 후 AI에게 업무지시를 내리는 것이기 때문에 “바이브 코더”분들만큼까지는 많은 토큰을 사용하지 않습니다.

2. 1차 작업 지시(기초)

---

아무리 AI가 코드를 잘 짜도 100%마음에 드는 코드를 뱉기란 쉽지 않습니다. 그래서 저는 애초에 한 기능을 여러 차례에 걸쳐 진행할 생각을 하고 1차 업무지시를 내립니다.

Rest API 개발 예시(희망편)

<클래스>의 <메소드>에 "이벤트 검색 API"의 엔드포인트만 지정해 둔 껍데기만 만들어두었습니다.
다음 요구사항을 만족하는 API를 개발하세요.
---
* 기능명: 이벤트 검색 API
* 검색 파라메터: 이벤트명, 주최사, 기간(시작일시, 종료일시), 이벤트 상태코드, 장소명
* Response DTO: 이벤트명, 주최사, 이벤트 날짜, 이벤트 상태코드, 장소명, 생성일시, 수정일시
* 상세 요구사항:
- 이벤트의 도메인 클래스는 "Event"입니다
- "시작일시 < 이벤트 날짜 < 종료일시" 인 데이터
- 이벤트 상태코드 클래스는 "EventStatusCode"클래스를 참조하세요

명확하게 말로 설명하기 쉬운 작업은 위와 같이 깔끔하게 정리하여 요구사항을 전달합니다.

저기서 조금 더 대략적으로 설명해도 됩니다.

추가적으로 저의 팁은, 꽤나 복잡하거나 멋대로 수정하면 곤란한 경우에는
”개발 계획을 세우고 저에게 보고하세요. 저의 승인 후 개발을 진행해야 합니다.” 와 같은 방식을 사용하는 것도 괜찮습니다.

Rest API 개발 예시(절망편?)

Event 도메인 객체를 사용하는 CRUD API를 설계하고 작성하세요.
비슷한 예시로는 "NoticeController"의 전체적인 로직과 비슷하게 짜면 됩니다.
단계적으로 생각하고 꼼꼼히 똑바로 짜세요.

라는 방식도 괜찮아요. 어차피 잘못된 거는 읽고 수정하라고 하면 되니까요.

3. 2차 작업 지시(수정)

---

진짜 쉬운 CRUD를 제외하고는 마음에 100% 들지 않는 결과물이 나올 확률이 꽤나 높습니다.

저는 1차 작업 결과물을 읽어 로직의 흐름을 파악하고 다음과 같은 방식으로 지시합니다.

비즈니스 로직 수정 예시(희망편)

방금 작업물에서 다음 내용들을 수정해야 합니다.
---
1. 방금 작업한 EventService 클래스의 getEventList 메소드의 검증 로직을 살펴보면,
EventStatusCode가 실제 DB 레코드에는 들어가지 않지만, 조회에만 사용하는 "ALL"이 존재합니다.
해당 케이스를 고려하여 비즈니스 로직을 수정하세요.

2. updateEvent 메소드에서 코드 컨벤션을 준수하기 위해, Domain 객체를 @Builder를 사용하여
메소드 내부에서 생성하여 사용하는데, 이 내용을 EventConverter 클래스에 선언하고 가져다 쓰도록 수정해주세요.

3. (내용은 대충 기억나진 않지만, 제가 생각한 비즈니스 로직의 순서로 수정하라고 지시하기도 합니다.)

사실 2번같은 자잘한 내용들은 프롬프트 적는 시간에 제가 직접 수정하는 것이 훨씬 빠르지만 예시로 작성했습니다.

코드를 읽고 상세하게 개발 의도를 파악하여 반박해보고 가능한 한 상세하게
(메소드 레벨까지, 필요시 변수도) 수정 흐름을 지시하는 편이 좋습니다.

비즈니스 로직 수정 예시(절망편)

검색조건에는 "ALL"이 존재합니다. 수정하세요.
또한 updateEvent()에서 Event를 만들어 쓰는 것이 아닌 것 같습니다.
다른 방법 생각해서 수정해주세요.

바쁠때는 이렇게 하기도 합니다.

프롬프트는 어떻게 짜든 상관 없지만 저의 결론은 다음과 같습니다.

내용이 어렵고 복잡한 로직일 수록 최대한 상세하고 가독성 좋게 지시한다.

4. 마무리 작업 지시(정리)

---

이건 최근에 너무 복잡한 기능을 짜다보니 코드를 제대로 구조화하지 않으면 AI가 개발한 작업물들을 읽고 판단하기에 어려워집니다.

따라서 요즘에는 다음과 같은 간단한 프롬프트를 추가로 지시합니다.

방금 개발한 코드들을 리팩토링하세요.
SOLID원칙과 클린코드 원칙을 최대한 준수하여 작업하세요.
추가로 디자인패턴 적용이 가능한 포인트가 있는지 한번 검토하세요.
적당한 수준에서 디자인패턴을 적용하세요.

또는 간단한 수정만 했다면

방금 개발한 updateEvent 메소드는 너무 fat합니다.(혹은, 파라메터가 많아 code smell을 경계해야 합니다)
해당 메소드에서 내부적으로 사용하는 비즈니스 로직들을 책임에 따라 분리하세요.

이렇게 하여 이후 코드의 가용성과 유지보수성을 최대한 높입니다.

또한 어느정도 작업이 한번 이루어지면 한번 더 지시합니다.
계속 작업하다 보면, 중앙화시킬 수 있는 코드들이 분명 생기기 때문이죠.

사람 뿐만이 아니라 AI도 결국 코드를 읽는 것이기 때문에 의도에 맞게 클래스와 메소드를 분리하고,
한 클래스나 메소드에 책임 등이 너무 몰리는 것을 경계해야 합니다.

번외로 ‘클린코드’라는 책을 추천합니다.

사람이 코드 짜는 시대는 저물어가지만, AI의 사용성을 높이기에도 좋은 소프트웨어 개발의 가장 근본적인 책이라고 볼 수 있습니다.

번외

---

제가 위에서 예시로 작성한 코드들을 살펴보면 “하지 마라”라는 키워드는 단 한번도 사용하지 않았습니다.

요즘에는 많이들 알고있듯이, AI도 사람과같이 “하지 마라”등의 부정적인 언어는 그걸 더 생각하게 되는 경향을 보인다는 이야기가 있거든요.

원래 사람도 하지말라는 것을 더 하고 싶어지는 법이잖아요.

AI와 회의하기

---

때때로 특정 기능에 대한 처음 가닥을 잡기가 막막할 때가 있습니다.

이럴 때 사용하는 저만의 방법은 요구사항을 달성하기 위해 “AI와 회의를 하는 것”입니다.

예시

Redis streams를 사용하여 행사의 상태를 다른 클라이언트에게 전파하고 해당 내용을 저장해야 합니다.
이걸 WebSocket에서 텍스트메세지를 받아 handleTextMessage() 메소드에 구현하려고 하는데,
어떤 방법이 최적의 방법일까요?

또한 scale-out되었을 때를 고려하여
이벤트의 상태 업데이트 시점을 handleTextMessage()에 클라이언트의 요청이 도착했을 때 시점이 아닌,
브로드캐스팅을 위해 구현하 BroadcastService에서 다른 클라이언트에 메세지를 내려주기 직전의
시점에서 구현하는 것이 낫다고 생각하는데, 어떻게 생각하나요? 혹시 다른 좋은 방법이 있을까요?

--- 다른 예시

상태 변경이 비동기 멀티스레딩 환경이라 객체의 원자성이
updateEventStatusCode() 메소드에서 보장이 되나요?

--- 다른 예시

ConcurrentHashMap으로 Event객체들을 관리하는데,
메모리 해제가 제대로 이루어져야 장기적인 운영환경에서 안정적으로 돌아갑니다.
메모리 누수가 일어날 수 있는 부분이 있을까요?
또한 이를 방지하기 위해 배치 스케줄러를 통해 좀비 객체들을 주기적으로 정리하는 것은 어떻게 생각하나요?

위에는 제가 비슷하게 물어보며 회의했던 질문의 유형들입니다.

이 외에도 몇 가지가 있지만, 직접 AI와 회의하는 것이 의미있기 때문에 이만 줄이겠습니다.

에이전트를 쓰며 내린 결론

---

요즘 시대에 AI없이 개발한다는 말은 “저는 시대에 뒤떨어지는 사람입니다”라고 고백한다는 말과 같습니다.

AI를 잘 쓰기 위해서는 많이 써봐야 되고, 자신에게 최적화된 사용법이 중요합니다.

바이브코더처럼 AI로 단기간에 폭발적인 속도로 개발하는 것도 좋지만, 개발자라면 개발자에게 어울리는 AI 활용법이 존재합니다.

비즈니스 로직을 검토하고, 메모리 관리에 더 나은 방법을 검토하고, 오류 발생시 추적하기 쉽도록 하고, fallback로직을 설계하고… 바이브코더와는 다른 개발자만의 장점을 AI로 살릴 수 있을 때 경쟁력이 올라간다고 생각합니다.

AI 에이전트를 사용하는데 익숙하지 않다면, Gemini CLI로 저처럼 개발을 시작해보는 것을 다시 한 번 강력하게 추천드립니다.

다른 AI 활용 팁들이 있다면 공유해주세요.

피드백은 언제나 환영합니다 :)