배포방식차이 때문입니다. 수업에서 Frontend는 AWS Amplify 서비스를 이용해 배포합니다. GitHub과 연동해 Push 즉시 배포가 완료되도록 구성했기 때문입니다. 그러나 백엔드는 Jar 파일 빌드 후 EC2에 직접 업로드하고 배포하는 방식을 취하고 있습니다. 더 좋은 배포 방법이 없는 것은 아니지만 그렇다고 다른 내용을 수업에서 더 다루는 것도 적절치 않다고 판단했습니다. 약간 불편할 뿐이기 때문입니다. 저는 그런 문서들도 모두 함께 GitHub 저장소에 올립니다. 그렇게 해두는 것이 장점이 많습니다. 굳이 제외시킬 이유도 없고요. 바이브 코딩은 혼자서 개발하는 경우가 많습니다. 여러 사람이 함께 프로젝트를 개발하는 경우가 아니므로 일반적인 규칙을 따를 필요는 없을 것 같습니다. 자신의 상황에 알맞게 대응 하는 것이 오히려 더 중요하겠습니다. 참고하시기 바랍니다. :)
Claude Code에서 plan mode를 사용한다면 굳이 그럴 필요가 없을 수 있습니다. 그러나 Desktop이나 Web에서 설계 과정의 대화를 기록으로 남겨두면 그 자체로 하나의 훌륭한 회의록이 되어 줍니다. 그리고 각종 문제를 해결할 때도 대화 세션의 도움을 받을 수 있습니다. 초기 설계 대화 세션, 설계에 기반한 코드 작성 대화 세션, 코드리뷰 등 세 가지 세션은 별도로 분리하는 것이 나쁘지 않은 선택이라 하겠습니다. 참고하시기 바랍니다. :)
최초 강의 계획은 해당 차시를 따로 분리해 설명하려 했었습니다. 그러나 설명과정에서 자연스럽게 관련 내용들이 등장했고 별도로 논하는 것이 오히려 흐름에 방해가 된다고 판단해 생략 됐습니다. 내용이 아무리 좋더라도 불필요하게 긴 설명으로 이어지는 것은 좋지 않다 생각한 것입니다. 학습에 참고하시기 바랍니다. :)
PC2대를 추천하는 경우는 실제 서비스 시스템을 직접 구축하는 경우와 관련이 있습니다. 사실 개발보다는 운영관점에서 그렇습니다. 그러나 다른 차시에서 언급한 것처럼 프론트엔드/백엔드를 동시에 개발하도록 하는 것이 AI에게는 더 좋습니다. 실제로 결과물도 더 잘 나옵니다. AI환각은 생각보다 자주 발생합니다. 프론트와 백엔드를 분리해 개발할 경우 주고 받는 문서를 이용한다 하더라도 API 규정을 제대로 맞추지 못해 오류가 발생하는 일이 꽤 빈번합니다. 특히 Sonnet급 모델 및 그 이하 모델에서 이런 현상이 두드러집니다. 그러므로 가급적 기능 위주로 개발단위를 규정하고 프론트와 백엔드를 동시에 개발하는 것이 더 좋겠습니다. 참고하시기 바랍니다. :)
전반을 설명하는 맥락으로 보는 것이 좋긴 합니다. DBD 공격의 경우 Landing -> Hopping -> Repository 순으로 접속이 일어납니다. 이 과정에서 한 가지만 연결이 끊기면 최종적으로 공격은 성공하지 못합니다. CORS가 DBD를 막기 위해 만들어졌다고 할 수는 없지만 결과적으로 DBD 공격을 막는 것에도 영향을 준 것으로 이해할 수 있겠습니다. 본인의 생각과 더불어 함께 생각해보시면 좋겠습니다. :)
