수강완료 후 문의 드립니다.

안녕하세요 겸상님 미션과 진도 모두 정상적으로 완료된 것으로 확인되었고, 길벗포인트 지급 대상에도 포함되어 있어요!현재 길벗 측에서 명단 정리 후 일괄 지급 예정이라 조금만 기다려주시면 감사하겠습니다 모든 과정 끝까지 완료하시느라 정말 고생 많으셨어요 😊감사합니다!

테스트 질문드립니다.

syhan님은 항상 깊은 생각을 하시는 것 같아요. 테스트에 대해서도 많은 관심을 가지고 계시다니 개발자로서 매우 좋은 태도를 갖추고 계신 것 같습니다.^^ 테스트 전략은 팀마다 다양해서 다르긴 하지만 그래도 본인의 기준을 가지고 있는 것도 좋은 태도라고 생각해요. 질문 주신 방향에서 이미 잘 알고 계셔서 다른 답변은 따로 드릴게 없을 것 같네요 ㅎㅎ두 테스트는 목적성이 다르고, 목적을 기준으로 진행하다 보면 겹치는 부분이 있는 것은 어쩔 수 없는 부분인 것 같아요. 둘 다 진행하는 것이 물론 좋다고 봅니다.저도 그 생각에 동의합니다. 단위 테스트는 웬만해선 꼼꼼하게 모두 테스트해야 하고, 전체 테스트는 사실상 예외 케이스까지 모두 다루기에는 시간이 부족하니까요. 그래도 상황마다 예외에 대해서도 생각해야 할 경우도 있을테니 적절한 판단이 필요할 것 같아요.API 문서화를 위한 API 테스트 단위로 작성하는 경우가 일반적이지 않나 싶어요. 제가 있던 조직에선 사실 통합 테스트는 생략되는 경우도 많았고 모두 돌려보기엔 시간적 제약이 있으니까요. 문서화 목적과 검증 목적의 테스트를 구분해두면 좋을 것 같습니다.마지막까지 좋은 질문 주셔서 감사해요.주말 아침 라방에도 참여해주시고, 챌린지도 끝까지 함께하시느라 고생 많으셨습니다!!

점진적 배포에 대해 질문있습니다!

실무에서 어떤 문제가 생길 수 있는지까지 깊이 고민하고 질문해주시는 점이 참 좋아요.^^ 서버 한 대씩 배포하는 방식이 '점진적 배포'가 맞습니다.그렇기 때문에 우려하신 것처럼 서비스에서 특히 유의해야 해요.배포 중에는 배포 완료된 서버와 아닌 서버 간의 로직 차이가 있기 때문에 여러 상황이 발생할 수 있고 그에 맞게 적절히 선택해야 합니다.일반적으로는 배포된 서버에서도 예전 요청을 처리할 수 있도록 하위 호환을 유지합니다.간단한 로직 변경: 서로 다르게 동작해도 사용자 경험에 큰 영향 없다면 차이를 감안하고 배포합니다.(도메인, 쿼리 변경 포함)DB 스키마가 변경된 경우: 한쪽에서 에러가 발생하지 않게끔 옛 코드와 새 코드 모두 동작하도록 설계합니다.'양쪽 쓰기'를 합니다. (이전 컬럼/테이블에과 새로운 컬럼/테이블 양쪽에 데이터를 쌓음)배포가 모두 완료된 후에는 새로운 곳에만 쌓게 됩니다.이전 쪽에만 쌓인 데이터는 batch 시스템으로 데이터를 이전합니다.(마이그레이션)마이그레이션이 끝나면 이전 컬럼/테이블을 제거합니다.또는 플래그 방식도 사용할 수 있어요. 코드를 미리 배포해두고 기능을 꺼둠 상태로 둔 다음에 배포가 모두 완료되면 플래그를 켜서 모든 서버에 기능을 적용하게 할 수도 있습니다.

회사 내 AI 툴 사용에 대한 질문

지인들에게 물어보면 회사마다 정말 다 다르더라고요.보안이 중요한 금융이나 공공기관 등에서는 아예 제한되는 경우도 많고, 반대로 IT 기업에서는 적극적으로 활용하도록 지원해주기도 해요.개인 계정을 허용하는 곳도 있고, 회사 차원에서 유료 계정을 지원해주는 경우도 있습니다. AI는 질문하는 사람이 아는 만큼 답변을 해주는 도구예요. 그래서 AI 사용이 제한되는 환경이라고 해도 충분히 효율적으로 배워나갈 수 있어요.신입의 입장에서 AI를 쓰지 못하는 경우에는 책에서 계속 강조해온 것처럼 '왜 쓰는지'에 대한 이해가 중요한 것 같아요. 항상 그 질문을 마음에 새기면서 기존에 정리된 사내 문서를 참고하고, 큰 흐름부터 잡아가는 방식으로 익히시면 좋습니다.그리고 가장 빠른 성장 방법은 동료나 사수에게 질문하는 거예요! AI가 있더라도 직접 묻는 것을 추천드립니다.질문하기 두려울 수 있지만 개발자분들은 알려주는 것을 좋아하는 분들이 정말 많아요. 받아들이고 배우려는 자세로 질문을 하신다면 더 많이 알려주고 싶어하고 그만큼 빨리 배우게 됩니다.특히 질문 전에 큰 그림을 미리 정리해두고 물으면 그 과정 자체도 학습이 되고 답변도 깊이 있게 받을 수 있어요.

docker compose에 대해 질문드립니다.

정말 질문을 깊이 있게 잘 정리해주셨네요!! 👍👍실무 환경과 연결해서 큰 맥락으로 접근해서 생각하시는 것도 좋습니다!!^^ 1. 도커 컴포즈를 자동화로 활용할 방법말씀하신 것처럼 직접 서버에서 수기로 하는 방식은 권장되지 않습니다.보통은 compose 파일을 git으로 관리해요.깃허브액션 같은 CI/CD 파이프라인에서 compose 파일을 전송해서(서버에서 git pull로 받거나 scp로 전송 받거나) docker compose up 명령어를 자동으로 실행하도록 설정해둡니다. 2. 대규모 환경에서 도커 컴포즈가 유용할까?말씀해주신 것처럼 실무 운영환경에서는 DB, Redis 등의 서버는 컴포즈가 아닌 별도 서버로 구성하는게 일반적입니다.그런데 개인 프로젝트나 사내 도구 같은 소규모 환경에서는 단일 서버로 구성할 때 컴포즈가 유용하게 쓰일 수 있어요.또 대규모 환경에서도 서버 구분 할 필요 없는 짜잘한 것들(예: nginx, nginx 모니터링 도구, ssl 인증서 갱신 도구)은 compose로 사용하기도 해요.

깃 풀(git pull)에 대한 궁금증이 있습니다!

질문을 정말 잘 정리해주셨습니다! 😀작업 전후로 pull을 받는 위치는 현재 자신이 작업하고 있는 브랜치라고 보시면 돼요.맨 마지막에 말씀 주신 것처럼 기준 브랜치인 main은 작업용 브랜치로 사용하지 않아요. 보통 버전이 붙어있는 이름의 브랜치나, 'develop' 브랜치, 'feature/xxx' 브랜치 등이 작업용 브랜치예요. 내가 로컬 v1.0을 작업중이라면 pull은 원격 v1.0로부터 변경분을 내려받게 됩니다.pull: 원격 v1.0 → 로컬 v1.0 병합은 작업 브랜치(예:v1.0)가 안정적인 것이 확인될 때쯤(개발자가 느끼기에) 기준 브랜치인 main에 합치게 돼요. 작업 브랜치에서 변경된 부분이 main에 반영되는 거예요. 두 가지 방법이 가능해요.merge 1: ① 로컬 v1.0 & 원격 v1.0(push로 이미 같은 상태) → 로컬 main으로 merge② 로컬 main → 원격 main으로 pushmerge 2:① 로컬 v1.0 → 원격 v1.0 push → PR(Pull Request) main merge실무에서는 보통 PR(Pull Request)을 통해 병합하는데, 조직마다 세부 방식은 다를 수 있어요.