안녕하세요! 지성조님 회사 업무에 AI를 활용해보시려는 목적이라면, 아래 관점으로 수강하시면 좋겠습니다. 1) 지금 수강해도 도움이 될까요? 네. 이 강의의 핵심은 백엔드 설계의 이유를 이해하고, AI에 구현을 맡긴 뒤 결과를 검토하는 연습 입니다. 예를 들어 “세션은 왜 Redis에 저장할까?”, “팔로우 수를 동시에 변경하면 문제가 없을까?”, “타임라인은 언제 미리 만들어두는 게 좋을까?” 같은 판단을 다룹니다. 이런 판단 기준은 사용하는 AI 도구나 모델이 바뀌어도 활용할 수 있습니다. 다만 촬영 당시의 도구 설정이나 모델 설정은 현재와 차이가 있을 수 있습니다. 최신 하네스 기능을 폭넓게 익히는 것이 주목적이라면 별도 학습이 필요하지만, AI를 활용하면서도 설계와 코드의 적절성을 스스로 판단하는 기본기 를 익히는 데는 도움이 됩니다. 2) 코드를 직접 손으로 작성해야 할까요? 모든 코드를 그대로 따라 칠 필요는 없습니다. 오히려 다음 순서를 권장합니다. 강의를 보며 요구사항과 설계 이유를 이해합니다. 예제 코드를 직접 구현하기 보다는, 이해한 내용을 바탕으로 AI에 구현을 요청해봅니다. 직접 실행하고 테스트하면서 강의 코드와 차이를 비교합니다. 각 챕터의 미션에서 요구사항을 바꿔보고, AI가 만든 코드가 그 조건을 충족하는지 확인해보시면 좋습니다. 이해되지 않는 핵심 로직은 직접 수정해보시면 좋습니다. 내가 이 코드의 동작과 선택 이유를 설명할 수 있는가? 를 기준으로 학습하시면, 회사 업무에도 연결하기 좋을 거라고 생각합니다.
안녕하세요 아라레님! 괜한 질문이라니요. 좋게 봐주셔서 오히려 감사하고 힘이 납니다 😊 저도 모든 설정을 외우고 있지는 않아요. 비결이라면 설정을 하나씩 외우기보다, 왜 필요한지, 바꾸면 어떻게 되는지를 이해하려고 하는 편입니다. 모르는 부분은 문서를 찾아보고 직접 실행하면서 확인하고요. 예를 들어 이번 실습도 로그가 어디서 생기고, Collector를 거쳐 Loki에 어떻게 저장되고, Grafana에서 어떻게 조회되는지 흐름을 먼저 잡으면 세부 설정을 이해하기가 훨씬 수월해져요. 설정 하나를 바꿔보고 결과를 예상한 뒤, 실제 동작과 비교해보시는 걸 추천드립니다. 예상과 다를 때 이유를 찾아보는 과정이 기억에 오래 남더라고요. 처음부터 전부 이해하려고 부담 갖지 않으셔도 괜찮습니다. 강의 재미있게 들어주셔서 감사합니다!
안녕하세요. 아라레님! 원인 분석과 해결 방법을 자세히 공유해주셔서 감사합니다! 말씀해주신 내용을 확인하고, 제 맥북(M3 Max)에서도 GHCR의 amd64 이미지를 실습과 같은 앱 리소스 제한과 상태 검사 설정으로 다시 실행해봤습니다. 제 환경에서는 Docker Desktop의 amd64 이미지가 Rosetta 로 실행되어 애플리케이션 기동이 성공했고 (약 34초 소요), liveness 검사에서도 재시작 없이 정상 동작했습니다. 다만 Apple Silicon의 모든 환경에서 동일하게 동작하지는 않을 수 있고, Docker Desktop의 가상화와 에뮬레이션 설정, 할당 자원 등에 따라 아라레님 처럼 기동 시간과 실행 결과가 달라질 수 있습니다. 말씀해주신대로 강의 자료에서 기존 설정이 CI 러너의 아키텍처에 맞는 이미지 하나만 생성하는 건 맞구요. 로컬 빌드 환경과 CI 이미지의 실행 환경이 달라지는 경우를 제가 충분히 고려하지 못했네요. 공유해주신 것처럼 amd64와 arm64를 모두 지정해 멀티 플랫폼 이미지로 이미지 저장소(ghcr)에 게시하면, 로컬 PC 에서 이 이미지를 불러올 때 맥북 실리콘(ARM64 노드)은 더이상 AMD64 가 아니라 ARM64 이미지를 선택하므로 해당 변환 과정 없이 실행할 수 있습니다. 그래서 제안해주신 수정 방향은 적절해보입니다! 이 부분은 조만간 강의를 업데이트하도록 하겠습니다 직접 해결하신 과정을 공유해주셔서 감사합니다 🙇♂️
안녕하세요! 감성코딩님 정말 잘 짚어주셨습니다. 말씀하신 대로 Redis 호출도 네트워크 I/O이므로, 트랜잭션 안에서 호출할 때는 HTTP Client와 같은 관점으로 주의해야 합니다. 해당 실습 코드를 보면 CouponService.issue() 에 @Transactional 이 붙어 있고, 그 안에서 Redis를 호출하고 있어요. 따라서 트랜잭션을 짧게 유지하는 관점에서는 개선할 부분이 맞습니다. 이 챕터는 Redis Lua로 재고 차감을 원자적으로 처리하는 단계이고, 이후 단원 비동기 큐 실습에서는 issue() 의 @Transactional 을 제거하고 DB 저장을 별도의 트랜잭션으로 분리합니다. 다만 트랜잭션과 별개로 Redis와 DB 사이의 정합성 문제는 트랜잭션 분리만으로 해결되지 않으므로, 실패 복구와 정합성 보정도 함께 고려해야 합니다. 이 부분도 이후 뒷단원에서 진행하니 아키텍처가 개선되는 것을 느끼면서 내용을 학습해주시면 좋을 것 같습니다. 감사합니다.
안녕하세요, 애송이님. AWS가 2026년 9월부터 신규 가입자에게 새로운 가입 방식을 적용 하고 있는데, Google 로그인으로 가입하고 계정이 만들어졌다면 새 방식으로 가입하신 겁니다. 새 방식은 권한 관리를 AWS가 대신 해주는 구조라서, 콘솔에 로그인하는 IAM 사용자는 아예 만들 수 없게 되어있어요. 해결 방법 1 지금 새 방식으로 만드신 계정으로 그대로 쭉 진행을 해주셔도 됩니다. 다만, 아쉽게도 강의 마지막 섹션의 'Github Actions와 AWS SSM 연동' 에 대해 실습을 진행할 수가 없는데 이 부분을 감안해주시고 수강해주시면 됩니다. 해결 방법 2 (추천) 현재 강의가 기존 방식(advanced)으로 진행되기 때문에, 현재 강의와 실습을 비슷하게 해보시려면 계정을 새로 만드시는 걸 추천드립니다. 기존 방식 가입은 이렇게 하시면 됩니다. 1. https://aws.amazon.com 에서 계정 생성 클릭 2. 가입 화면의 안내에서 새 방식(new)이 아닌 advanced(고급) 방식 선택 (못 찾겠다면, https://signin.aws.amazon.com/signup?request_type=register 로 바로 이동해주세요 ) 3. 이메일, 비밀번호로 가입한 뒤 강의 순서대로 진행 이미 사용한 이메일로 가입이 안 되면 다른 이메일을 쓰시면 됩니다. 새 방식으로 만든 계정은 리소스를 만들지 않았다면 비용이 나오지 않으니 그냥 두셔도 괜찮아요. 참고로 새 방식 계정에서 "고급 기능 활성화"로 기존 방식처럼 바꾸는 방법도 있긴 한데, 유료 플랜 업그레이드가 필요하고 되돌릴 수 없어서 학습용으로는 추천하지 않습니다. (2026-10-05 23:37 수정) 추가로 확인한 내용이 있어 보충드립니다. 앞서 새 방식 계정으로 그대로 진행해도 된다고 말씀드렸는데 정정하겠습니다. 새 방식 계정은 AWS 정책상 'ID 제공업체(OIDC) 등록'이 막혀 있어서, 마지막 섹션의 'Github Actions와 AWS SSM 연동' 실습을 진행할 수 없습니다. 강의를 끝까지 따라오시려면 위 절차대로 advanced 방식으로 새로 가입하시는 걸 권장드립니다. AWS 정책이 변경되었는데 혼란이 있을 것 같아요. 위에 말씀드린 대로 해보시고, 혹시나 제가 빠뜨린 것이 있다면 또 질문 주시면 빠르게 확인해보겠습니다. 관련해서 커리큘럼에 수업 자료 추가해두었습니다. 감사합니다.
안녕하세요, 사랑2님. 첫 번째 질문에 확인 절차를 댓글로 남겼습니다. 첫 번째 질문에 남긴 답변 확인하기 안내드린 명령의 실행 결과를 해당 글에 남겨주시면, 이어서 원인을 확인하고 해결 방법을 안내드리겠습니다. 정상적으로 실습을 진행하실 수 있도록 함께 확인할게요. 감사합니다.
안녕하세요, 사랑2님. 제공된 소스를 그대로 실행했는데 처음부터 오류가 반복되어 불편을 드린 점 죄송합니다. 정상적으로 실습을 진행하실 수 있도록 제가 방금 더 확인는데, 결론은 제 로컬에서는 잘 실행이 됐습니다. 그래서 사랑2님의 PC 환경을 체크해보면 좋을것같은데요. 남겨주신 로그는 PostgreSQL에 접속하는 과정에서 snsuser 계정의 비밀번호 인증이 실패했다는 내용입니다. 제가 제공한 소스를 확인해보니 앱 설정과 Docker Compose의 계정 정보는 모두 snsuser / snspassword 로 일치해요. 다만 설정 파일의 값이 같아도, 기존 DB에 다른 비밀번호가 저장되어 있거나 sns-app 애플리케이션이 PC에 설치된 다른 PostgreSQL에 접속하면 같은 오류 가 발생할 수 있습니다. 그런데 현재 적어주신 로그만으로는 어느 경우인지 확정하기 어렵습니다. [확인해볼사항] 우선 데이터를 유지한 상태에서 실제 실행 중인 DB를 확인해야합니다. sns-app 폴더에서 아래 세 명령을 실행한 결과를 댓글로 남겨주시면 감사하겠습니다. docker compose ps -a docker compose logs --tail=100 postgres docker compose exec -e PGPASSWORD=snspassword postgres psql -h postgres -U snsuser -d snsdb -c "SELECT current_user, current_database();" 마지막 명령은 강의용 PostgreSQL에 제공된 계정 정보로 접속이 되는지 확인하는 명령입니다. 오류가 나오면 그 메시지를 그대로 댓글에 남겨주시면 됩니다. 사용 중인 운영체제와 앱을 IntelliJ에서 실행하셨는지, 터미널에서 실행하셨는지도 함께 알려주세요. 결과를 확인해서 필요한 해결 절차를 구체적으로 안내드리겠습니다. 감사합니다.
안녕하세요, Jang Jaehoon님! 먼저 도커 데스크탑이 잘 설치되었는지 확인해주세요. docker ps 위 명령어로 도커 프로세스가 확인되는지 (도커 명령어가 잘 실행되는지) 확인해주세요. 잘 된다면, 올바른 경로에서 docker compose up -d 를 확인해주세요. docker-compose.yaml 파일이 있는곳에서 실행해주셔야 합니다. 감사합니다!
안녕하세요, Jang Jaehoon 님 위 쪽의 Access denied 문제만 해결하면 될 것 같은데요. 원인을 짐작할 수 있는 단서는 에러 메시지의 'coupon'@'localhost' 부분입니다. 강의에서 사용하는 mysql:8.4 이미지는 PC에서 Docker 컨테이너의 MySQL로 접속하면 접속자가 'coupon'@'172.x.x.x' 처럼 IP 주소로 기록됩니다. 그런데 질문 주신 에러에는 localhost 로 찍혀 있으니, 애플리케이션이 Docker 컨테이너가 아니라 PC에 직접 설치된 다른 MySQL에 접속했을 가능성이 높습니다. 로컬에 설치된 MySQL이 이미 3306 포트를 쓰고 있으면 컨테이너는 정상적으로 떠 있어도 localhost:3306 으로 들어온 요청을 로컬 MySQL이 받아 가게 되고, 그 MySQL에는 coupon 계정이 없으니 Access denied가 나는 것입니다. 1 실행중인 컨테이너 MySQL 계정 확인) 먼저 컨테이너 쪽 계정이 정상인지 확인해 보시면 좋겠습니다. docker-compose.yml 이 있는 디렉터리에서 아래 명령을 실행했을 때 1 이 출력된다면 컨테이너에 자체는 문제가 없음을 확인할 수 있습니다. docker compose exec mysql mysql -ucoupon -pcoupon coupon -e "select 1" 만약 위의 확인 명령에서부터 Access denied가 난다면, 볼륨에 예전 데이터가 남아 있는 경우일 수 있습니다. MySQL 이미지는 데이터 디렉터리가 비어 있을 때 딱 한 번만 MYSQL_USER , MYSQL_PASSWORD 로 계정을 만들기 때문에, 이전에 다른 설정으로 컨테이너를 띄운 적이 있다면 compose 파일을 고쳐도 반영되지 않습니다. 이때는 docker compose down -v 로 볼륨까지 지운 뒤 docker compose up -d mysql 로 다시 띄워 주세요. 볼륨을 지우면 DB 데이터가 모두 삭제된다는 점은 참고해 주세요. 또 IntelliJ Run Configuration에 SPRING_DATASOURCE_PASSWORD 같은 환경 변수를 넣어 두셨다면 그 값이 application.yaml 기본값보다 우선하니 함께 확인해 보시면 좋겠습니다. 2 다른 MySQL 프로세스가 있는지 확인) 다음으로 3306 포트를 어떤 프로세스가 쓰고 있는지 확인해 주세요. macOS에서는 lsof -nP -iTCP:3306 -sTCP:LISTEN , Windows에서는 netstat -ano | findstr :3306 으로 확인할 수 있습니다. 결과에 mysqld 가 보이면(Windows는 출력된 PID를 작업 관리자에서 찾아보시면 됩니다) PC에 설치된 MySQL이 포트를 차지하고 있는 것입니다. 이 경우 해결 방법은 두 가지입니다. 하나는 로컬 MySQL을 중지하는 방법 으로, Homebrew로 설치하셨다면 brew services stop mysql , Windows라면 services.msc 에서 MySQL80 서비스를 중지하신 뒤 docker compose up -d mysql 로 컨테이너를 다시 띄우고 애플리케이션을 실행하시면 됩니다. 다른 하나는 로컬 MySQL은 그대로 두고 컨테이너 포트를 바꾸는 방법 입니다. docker-compose.yml 의 포트를 "3307:3306" 으로 바꾸고, application.yaml 의 url 기본값도 jdbc:mysql://localhost:3307/coupon 으로 맞춰 주시면 됩니다. 그래도 해결되지 않으면 위 두 확인 명령의 출력 결과를 댓글로 남겨 주세요. 같이 확인해보겠습니다. 감사합니다.
