Claude로 서비스 A-Z 만들어보기 (시작편)

글쓰기에 앞서

 

지금까지의 블로그 글들은 꽤 노력하면서 작성했습니다. 특히 "어떤 글을 써야 새롭고 차별화된 정보를 줄 수 있을까?"를 계속 생각하면서 그림도 직접 그리고, 동작 원리를 잘 설명하려고 노력했던 것 같아요.

 

AI 카테고리에 있는 글들은 큰 힘을 들이지 않으려고 합니다. 느낀점과 제 생각을 간단하게만 작성할 생각이에요.

---

AI공부... 해야할까?

 

초반에는 누구보다 AI에 진심이었습니다. n8n을 통해 자동화 시스템도 구축하고, RAG을 사용해서 AI Agent도 만들어봤습니다. 그런데 제가 사용한 기술이 한 달 뒤에 레거시가 되어있더라고요...?

 

해당 경험을 겪은 후, 취업을 준비하는 개발자로서 AI를 공부하는 게 의미가 있나?? 싶었던 것 같아요. 지금 유행하는 AI 툴을 공부해도 몇 달 뒤에 이 기술은 레거시가 되어있을 확률이 높으니까요. 그런 생각을 가지면서 AI가 아무리 좋아져도 개발자한테는 본질이 중요하다!라고 기술적인 공부만 계속 학습했습니다. 기술적으로 깊이 공부를 하면 그만큼 전문성이 있는 거니깐요.

 

그러던 중, 같은 학교에 다니는 우테코 크루의 개인 프로젝트를 봤습니다. 정말 퀄리티가 높더군요. 디자인도 깔끔하고, 상당히 어려워 보이는 기능 구현도 잘 되어있었어요. 그때 확 느꼈던 것 같아요. AI가 이 정도라고?? 

 

작년 10월쯤 바이브코딩을 도전했다가 실패를 했었습니다. React Native로 구현을 하니까 모르는 부분이 나올 때 아예 막혀버리더라고요... 코드 이해도 잘 안 갔고요.  6개월 동안 정말 빠르게 AI가 발전한 것 같네요. 이번에는 제대로 각 잡고 AI 공부하면서 개인 프로젝트를 다시 도전해보려고 합니다. 완성도가 높다면 창업까지도 생각하고 있어요.

 

구현하고자 하는 프로젝트의 난이도가 상당히 높습니다. AI를 통해 어디까지 만들 수 있는지, 한계점이 있다면 어느 부분에서 막히는지를 직접 경험해보려고 합니다. 파이팅!!!!!!!!!!!

---

Cluade 초기 md 파일 작성 

 

규칙을 꽤 상세하게 적었습니다.  저만의 코드 스타일을 담은 md 파일을 만드는데만 하루정도 걸린 것 같네요...

.claude
|- CLAUDE.md
|-rules/
   |--code-style.md
   |--exception.code.md
   |--package-structure.md
   |--test-code.md

 

정말 상세하게 담은 것 같습니다. md 파일 전부 합치면 300 라인은 될 것 같아요.

 

code-style.md (일부분) 

# 설계 규칙
- 기본적으로 DDD 방법론을 따른다 
- 같은 Aggregate 내부 객체는 직접참조를 우선 고려한다
- 다른 Aggregate는 기본적으로 식별자(ID)로 간접참조한다

# 네이밍 규칙
- 검증/boolean 반환 메서드는 긍정문 사용 (isNotValid, hasNotRank 등 금지)
- dto 네이밍 대신 request/response로 구분
- dto는 record로 생성
        
# 코드 스타일
- Google Code Style 기반 (Tab/Indent: 4, Continuation: 8)
- 클래스와 선언부 필드 사이 개행
- 메서드 매개변수와 지역 변수에 final 사용
- 초기화되지 않은 상태로 변수를 선언하지 않는다
- else 예약어를 쓰지 않는다 (조기 리턴으로 대체)
- switch식 문장이나 삼항 연산자는 사용하지 않는다
- 컬렉션에 도메인 동작(검증/필터링/집계 등)이 붙거나, 불변성을 보장해야 한다면 일급 컬렉션으로 래핑한다

 

test-code.md (일부분)

# Domain 테스트
- 순수 단위 테스트로 작성 (Spring 컨텍스트 미로드, 의존성은 직접 생성)

# Repository 테스트
- JPA 기본 제공 메서드(`save`, `findById` 등)는 테스트하지 않는다
- Custom 구현된 메서드만 테스트 대상
- Mocking 없이 실제 의존성 주입으로 검증 (`@DataJpaTest` 활용)

# Service 테스트
- Mocking 금지 — `@SpringBootTest` + `@Autowired`로 실제 빈 주입
- 실제 Repository를 통해 DB 상태까지 검증
- 테스트 격리를 위해 `@Transactional`로 롤백 (별도 지시가 없는 한)

 

정해진 방법은 없고, 제 코드 스타일과 최대한 비슷하게 작성시키고 싶어서 꽤 노력을 들였습니다.

 

 

나만의 commands 작성

 

github issue 생성, github issue 가져오기, github pr 생성 총 3개의 command를 우선 만들었습니다. 추후에 github merge 등 다양한 command를 추가할 것 같아요.

---

편의성을 위한 팀 구성 (사실은 개인적인 재미를 위한 팀 구성)

 

최근에 이직로그라는 웹툰을 재밌게 봤습니다ㅎㅎ 해당 웹툰의 등장인물들로 팀원들을 꾸려봤어요. @멘션을 해서 작업을 시키는 등 정말 사람처럼 행동하게 할 수도 있을 것 같지만... 불필요한 토큰 소비를 할 수도 있다고 판단해 간략하게만 만들어봤습니다.  

 

저희 팀입니다ㅎ

---

느낀 점

코드 작성이 마음에 안 드는 부분이 꽤 있습니다. 초반부라 그런 것 같아요.

 

아직은 제가 개입을 많이 하고 있습니다. 추후에 원하는 workflow는 다음과 같습니다. 

 

1) issue 자동 생성 후 branch 이동

2) 태스크 할당 (개입)

3) 작업 완료 후 자동 PR

4) PR 확인 후 머지 (개입)

 

PR만 확인하면서 개입을 최소화하려고 해요. 이게 가능한지는 코드의 퀄리티를 계속 지켜봐야 할 것 같습니다. 

 

설계 관련해서는 제가 직접 진행했습니다. 디자인 초안 HTML 페이지를 주고, ERD를 작성하라고 하니깐 잘 못 만들더라고요... 하지만 수동으로 만든 ERD를 토대로 Entity 작성 후 CRUD 작성해라. 이런 건 굉장히 잘합니다. 

 

아키텍처와 기술 결정은 제 몫입니다. 이 부분에서 추가적인 학습을 했던 것 같아요. Next.js가 무엇이고, React가 무엇이고, 내 프로젝트에 맞는 기술은 어떤 건지 등등... 프런트엔드 쪽 시야도 넓힐 수 있었던 것 같아요. 

 

Harness Engineering은 아직은 도입을 안 하려고 합니다. 설명을 읽어보면 어마무시하게 토큰을 잡아먹을 것 같거든요...  우선은 Harness 없이 작업하면서 토큰 소모량을 느껴봐야 할 것 같아요. 또 md 파일 자세하게 작성하고 custom 하게 skill 만든 거랑 뭐가 다르지?라는 생각도 있어서 공부를 더 해봐야 할 것 같네요. md 파일도 계속해서 다듬고, skill과 command의 개념 차이에 대해서도 알아봐야 할 것 같네요. 🧐