.claude 폴더 규칙 생성 방법

안녕하세요 형씌님 좋은 질문 주셔서 감사합니다. 1)"추후 ... 프로젝트 특성에 맞게 커스텀해야 할 것 같다고 생각합니다." 말씀해주신 이 부분 정말 잘 캐치하셨습니다!현재 제공된 .claude 폴더는 도메인 성격, 아키텍처 방식, 팀 규모에 따라 반드시 조정해야 합니다. 예를 들어 도메인 분리 기준, 레이어 구조, 네이밍 규칙, 코드 리뷰에서 꼭 봐야할 점, 보안 규칙 등은 프로젝트마다 달라지기 때문에 이 부분은 프로젝트에 맞게 수정해주는 것이 좋습니다. 2)새 프로젝트에서 .claude 폴더가 없는 상태라면 특히 프로젝트 기획과 규칙이 이미 있다면이를 바탕으로 먼저 정해볼 수 있는 부분은 도메인 개념 정리, 코딩 컨벤션, 구체적인 개발 규칙에 대한 설명입니다. 이를 미리 정의해두면, 추가 기능을 구현할 때 이 부분을 미리 참고하여 전체적으로 통일감있고 예측가능한 코드를 만들 수 있게 될 수 있습니다. (물론 AI 를 계속 사용해보시면 알겠지만, AI agent 가 기존 코드를 읽고 이를 자동으로 분석하여 해당 코드베이스 맞는 구조로 새로운 코드를 알아서 만들어주기도 합니다.)이후 실제 개발을 진행하면 반드시 반복해서 AI 에게 요청하는 부분이 생길겁니다. 따라서 “AI가 자주 헷갈리는 부분”이나 “매번 설명하게 되는 내용”을 발견할 때마다 .claude 문서를 보완해 나가면, 점점 프로젝트에 최적화된 형태로 완성됩니다. 정리하면, .claude 폴더는 한 번 만들어두고 끝나는 설정이 아니라 프로젝트와 함께 성장시키는 문서에 가깝습니다. 처음에는 단순하게 시작하고, 개발을 진행하면서 반복되는 의사결정과 규칙을 하나씩 녹여내는 방식이 가장 현실적이고 효과적인 접근이라고 보시면 좋겠습니다. 감사합니다.

강의를 어떻게 보면 좋을 까요?

안녕하세요 토니님! 제 추천으로는 챕터별로 [AI 다루기] 까지 모두 학습한 후, 매 챕터마다 있는 미션을 진행할 때 스스로 구현해보시면 좋을 것 같습니다. 제가 드린 깃헙링크의 코드를 따라치기보다는, 무엇을 만들지 머릿속에 그린 상태에서 AI agent 로 직접 구현해보는 경험을 해보시면 좋을 것 같습니다. 감사합니다.

배포 후 Entity 수정 관련

안녕하세요 석석님. ddl-auto=validate 는 엔티티가 변경되더라도 DB 구조는 자동으로 수정되지 않고 검증만 하는 옵션인데요. 애플리케이션과 DB의 상태를 정말 정확하게 맞출때는 validate를 사용할수도있지만, 실무에서는 none 옵션을 사용하기도 합니다. 이유는 운영 환경에서 애플리케이션 기동 자체가 스키마 검증 실패로 막히는 상황을 피하기 위함입니다. 실제 운영에서는 DB 변경이 마이그레이션 도구(Flyway, Liquibase, 또는 사내 DBA가 만들어놓은 절차)를 통해 이미 관리되고 않을 것이기 때문에, JPA가 추가로 검증까지 수행할 필요가 없는 경우가 많습니다. 오히려 컬럼 하나 차이로 서비스가 아예 올라오지 않는 문제가 더 큰 장애로 이어질 수 있어, JPA의 역할을 명확히 분리하기 위해 none 옵션을 선택하는 경우도 많습니다.운영 DB 의 스키마가 바뀌는 작업은 데이터를 보호함에있어 신중히 이루어져야할 작업입니다. 예를 들어 컬럼이 추가된다면, DB 선 적용후 애플리케이션을 배포해야하며, 컬럼이 삭제된다면 애플리케이션에서 먼저 컬럼삭제 배포후 DB 에 후적용하는게 필요합니다. 이를 통해 배포 과정 중 서비스가 중단되지않고 상위, 하위호환성을 유지할수있게 말이죠.그래서 이 과정을 자동화 하기 보다 개발자가 직접 보면서 배포하는 경우가 많습니다. 신중히 처리하고, 예상치 못한 문제 발생시 즉시 대응할 수 있기 위함이예요. 도움이되셨으면 좋겠습니다.감사합니다.

EC2 HTTPS에 관련하여 질문 드립니다!

안녕하세요 석석님! 실무에서도 Nginx를 사용하는 경우가 많습니다.다만 현재구조처럼 서버 안에서 직접 인증서를 관리하는 방식보다는, 역할을 분리해서 HTTPS를 처리하는 구조를 더 선호합니다. 이유는 보안, 운영 안정성, 인증서 갱신 자동화 등이 있을 것 같아요. 다른 방식으로는 예를 들어 AWS 환경에서는 EC2 앞단에 ALB(Application Load Balancer) 를 두고, HTTPS는 ALB에서 처리할 수 있습니다. 인증서는 ACM(AWS Certificate Manager) 을 사용해 발급받고, 갱신 역시 자동으로 관리합니다.EC2 내부의 애플리케이션은 HTTP로 통신하고, 외부 트래픽만 HTTPS로 보호하는 방식입니다. 트래픽 영역과 애플리케이션 영역을 분리해서 운영한다고 보면 됩니다.(물론, 이와 비슷한 기술이 다른 클라우드 서비스에도 있습니다.) 이번 프로젝트에서 이어서 HTTP 를 구성하시는 것이라면, 처음에는 Nginx, Certbot 등으로 HTTPS를 직접 설정해보는 경험이 충분히 의미 있고, 그 다음 단계로 ALB + ACM 구조까지 함께 경험해보신다면 좋을것같습니다. 감사합니다.

SKILLS.md나 agents 작성 문의

안녕하세요 김수용님!좋은 질문 주셔서 감사합니다. 결론부터 말씀드리면, SKILLS.md나 agents 파일은 반드시 영어로 작성해야 하는 것은 아닙니다. 기술적으로는 한글로 작성해도 전혀 문제없이 동작합니다. 다만 많은 예제나 가이드에서 영어를 사용하는 이유는우선 대부분의 AI 모델이 영어 데이터로 가장 많이 학습되어 있기 때문에, 동일한 내용을 작성하더라도 영어가 의도를 더 안정적으로 이해하는 경우가 많습니다. (하지만 이는 모델이 개선되면서 점점 큰 차이가 없을 수도 있습니다.) 또 하나는 협업과 재사용 관점입니다. SKILLS나 agents 설정은 프로젝트 내부 문서이면서 동시에 AI에게 주는 사용 설명서 역할을 하기 때문에, 이후 다른 사람과 공유하거나 오픈소스로 확장될 가능성을 고려하면 영어가 범용적으로 쓰이기 쉽습니다. 그래서 관례적으로 영어 예제가 많이 사용되고 있는 것입니다. 하지만 상황에 따라 한글로 하셔도 큰 문제는 없습니다.감사합니다.

EC2 <-> RDS 연동 후 로컬에서의 Docker에 대해 궁금한 점이 있습니다.

안녕하세요 석석님!좋은 질문 주셔서 감사합니다. 말씀해주신 것처럼 docker compose up -d를 실행하면 compose 파일에 정의된 모든 서비스가 함께 실행됩니다. 따라서 springboot-twitter 컨테이너도 동시에 올라가게 되고, 이 상태에서 로컬 IDE에서 Spring Boot 애플리케이션을 다시 실행하면 이미 컨테이너가 8080 포트를 사용 중이기 때문에 8080 already in use 오류가 발생하게 됩니다. 이 현상 자체는 정상적인 동작입니다. 이럴 경우 로컬 개발 단계에서는 DB만 Docker로 띄우고, 애플리케이션은 IDE에서 직접 실행하는 방식을 가장 많이 사용합니다. 즉, 말씀하신 것처럼 docker compose up -d mysql-twitter 처럼 특정 서비스만 실행하거나, 아예 로컬 전용 compose 파일을 만들어 MySQL만 정의해두는 방식이 실무에서도 많이 쓰입니다. 이렇게 하면 포트 충돌 없이 편하게 디버깅과 개발이 가능합니다. 감사합니다.

Docker에 관하여 궁금한 점이 있습니다!

안녕하세요 석석님 좋은 질문 주셔서 감사합니다.도커 구조가 처음에는 헷갈릴 수 있는데, 핵심 흐름을 잘 짚어주셨어요. 정리해서 말씀드리면, docker buildx build 명령은 Dockerfile을 기반으로 컨테이너를 만드는 단계가 아니라 이미지를 생성하는 단계입니다. 이때 만들어지는 결과물은 실행 전 상태의 이미지이며, 아직 컨테이너는 생성되지 않습니다. Docker Hub 역시 컨테이너를 저장하는 공간이 아니라, 이러한 이미지를 보관하는 저장소라고 이해하시면 됩니다. 이후 해당 이미지를 Docker Hub에 push 해두면, Docker Compose가 실행될 때 필요한 이미지를 자동으로 내려받게 됩니다. 만약 로컬 환경에 이미지가 없다면 Docker Hub에서 이미지를 pull 하고, 그 이미지를 기반으로 실제 실행 단위인 컨테이너를 생성하여 서비스가 동작하게 됩니다. 감사합니다.

CSRF 관련 궁금한게 있어요

안녕하세요 SPRING 님! 보안 관련 지적해주신 부분 맞는 내용입니다.쿠키/세션 기반 로그인시 쿠키가 자동으로 전달되는 점을 이용하여 CSRF 공격이 들어올 수 있습니다.따라서 CSRF 방어를 해주는게 맞구요. 현재 코드에서는 그 점은 반영되어 있지 않습니다. 다만, 이 강의에서는 개발 편의상 현재 main 브랜치는 csrf 를 비활성화하는 것을 유지하도록 하려고 합니다. (특히 Postman 사용시 추가 CSRF 관련 header 를 넣어야해서 자동화하려면 스크립트 필요) SPRING 님께서 말씀해주신 부분은 수정해서 새로운 브랜치(feature/security)에 반영해놓았습니다.front: reactbackend: springboot꼼꼼하게 봐주셔서 감사합니다.

안녕하세요 강사님 데이터베이스 선택 질문있습니다!!

안녕하세요 정인호님!재밌게 듣고계시다니 감사합니다!! 개발자의 경험에 따라 다르겠지만, MySQL는 대체적으로 운영 예측성과 안정성이 높습니다. 예를 들어 PostgreSQL은 데이터를 수정하면 새 버전을 테이블에 쓰고, 이전 버전은 같은 테이블 안에 남아 있다가 VACUUM으로 정리됩니다. 그래서 관리가 잘 안 되면 테이블이 커지고 성능에 영향을 줄 수 있습니다. 반면 MySQL(InnoDB)은 이전 버전을 Undo Log에 따로 저장하고 자동으로 정리하기 때문에, 테이블 크기와 성능이 비교적 안정적으로 유지됩니다. 따라서 수정작업이 많은 경우 관리 난이도가 달라질 수 있습니다. 또한 MySQL 복제본을 구성할 때, binlog 기반 복제구조가 직관적이어서 장애 상황에서도 원인 파악과 복구 절차가 명확한 편입니다. 따라서 DBA 리소스가 제한된 팀이나, 운영 자동화가 충분히 갖춰지지 않은 환경에서도 안정적으로 운용하기 조금 더 쉽지 않을까 생각합니다. 위 장점 덕분에 MySQL은 대규모 트래픽을 처리하는 전형적인 웹 서비스에 특히 잘 맞습니다. 예를 들어 커머스 서비스의 주문, 결제, 재고 관리처럼 쓰기(수정) 트랜잭션이 빈번하게 발생하는 영역, 콘텐츠 서비스처럼 읽기부하가 커서 복제 기반으로 읽기를 수평 확장해야 하는데 DB 인적자원이 부족한 팀에서 강점을 보입니다. 실제로 많은 글로벌 커머스·콘텐츠 플랫폼들이 핵심 OLTP DB로 MySQL을 선택해 왔고, 이 과정에서 축적된 운영 사례와 패턴도 풍부합니다. 추가로.. MySQL, PostgreSQL 은 버전이 올라갈수록 대용량 처리같은 요구사항에 맞게 새로운 기능이 추가되거나 기존 단점이 개선되어가고 있기 때문에 서로 닮아가는 부분도 있고 점차 비슷해는 부분이 많아지지 않을까 생각이 듭니다. 그래서 우리팀은 어떤 DB 경험이 많고 익숙한지 여부가 RDB 를 고르는데 중요한 기준이지 않을까 싶습니다. 좋은 질문 감사합니다.

안녕하세요 질문있습니다.

안녕하세요 정인호님! 질문 주신 부분 충분히 의아해하실 수 있는 지점이라고 생각합니다.강의 소개 영상에서도 말씀드렸듯이, 이 강의에서는 코드를 직접 함께 구현하는 방식은 취하지 않습니다. 강의는 크게 도메인 설계 → 기술/구조 선택 → 구현과 동작 이해의 흐름으로 구성되어 있는데,이 중 ‘구현’ 자체를 강의에서 따라 치는 형태로 진행하지는 않습니다.대신, 어떤 도메인이 왜 그렇게 나뉘는지, 구조가 어떻게 잡히는 게 좋은지, 최종적으로 코드가 어떤 형태로 나오고, 어떻게 동작해야 “정상적인 상태”인지를 중심으로 함께 살펴봅니다. 실제 코드 구현은 각 챕터 마지막의 미션 과정에서 수강생 분이 AI Agent(예: Claude Code)를 활용해 직접 만들어보는 방식으로 진행하시는 것을 의도했습니다.즉, 강의 중간에 보이는 유저 도메인 변화 역시 "AI Agent를 통해 이런 식으로 도메인이 만들어질 수 있다”는 결과와 흐름을 보여드리기 위한 예시라고 보시면 됩니다. 이 강의에서 제가 가장 중요하게 생각한 포인트는백엔드 설계를 충분히 이해한 상태에서, AI Agent에게 올바르게 지시할 수 있는 능력입니다.그래서 코드 한 줄 한 줄을 설명하기보다는 설계 의도와 흐름을 이해하고그 이해를 바탕으로 AI에게 구현을 맡기는 경험에 초점을 두었습니다. 정리하면,강의에서 말하는 ‘구현과 동작’ 파트는 직접 코드를 작성하는 시간이 아니라,구현 결과를 보며 “이렇게 동작해야 맞다”라는 기준과 흐름을 이해하는 과정이라고 생각해주시면 좋을 것 같습니다. 감사합니다.