프로젝트 상황설명, 레거시 개선 관련 질문드립니다!

안녕하세요 질문 감사드립니다!첫째로 어느 정도의 상황과 제약에 대해서 언급하는 것은 괜찮다고 생각합니다다만 너무 다 써서 내용이 과해지지 않는 것을 조심해야할 것 같고, 서류 검토자에게 상황이 전달 될 정도의 정보만 넣으면 될 것 같습니다고객사에 요청 자체가 why가 되는 것은 케이스마다 다르지만 대부분 어려울 수 있습니다단순히 고객사가 요청을 해서 그대로 했다 이런 뉘앙스로 빠질 수 있기 때문에 한번 작성해보시고 검토자 입장에서 충분히 아 그럴만한 이유가 있었네가 나올지 고민 해보시면 좋을 것 같습니다그리고 결과적으로 그러한 배경과 상황에서 유의미한 결과와 임팩트를 만들 었다면 그 점을 강조하면 더욱 좋을 것 같습니다 두번째로 레거시 개선은 지원하는/팀 마다 받아들이는 관점이 다르지만 대부분 회사가 레거시가 없을 수 없기 때문에 부정적으로 보지는 않는 것 같습니다그래서 적어주신 예시는 유의미한 어필이 가능한 부분이라고 생각합니다자체적으로 모니터링과 운영에서 발견했다는 점은 단순 개발만 하는게 아니라 운영에 대한 경험이 있다는 것을 설명하는 것 이기에 잘 풀어내면 검토자들의 호기심을 유발 할 수 있을 것 입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

usecase 사용 기준

안녕하세요 질문 감사드립니다!저는 개인적으로 usecase를 빠르게 사용하는 것을 선호하지 않습니다!대부분의 경우 과한 경우가 많다고 생각하고 각 개념 서비스 단위가 성숙해진다면 그것을 조합할 때 usecase를 쓸까에 대한 고민을 하는 편입니다추가적으로 이것도 많이 개인적이지만 usecase라는 네이밍 자체를 선호하진 않습니다!이유는 너무 특정 아키텍처에 기인하여 맹목적이고 관습적인 네이밍이라고 생각하기 때문입니다그렇지만 모든 경우가 그렇지는 않을 것 이기 때문에 적절히 잘 판단해서 쓰면 된다고 생각합니다모쪼록 답이 되었길 바랍니다! 감사합니다!

이력서 내용 구성 관련 질문 있습니다.

안녕하세요 질문 감사드립니다!이 부분은 취향이나 선호 스타일 보다는 경력으로 적을 프로젝트의 성향마다 다른 것 같습니다그래서 저는 두개를 적절히 혼합해서 작성하는게 좋다고 생각합니다!가령 어떤 수치나 사실 함축 했을 때 전달이 훨씬 잘 되는 내용이 있을 것이고반대로 어떤 배경(레거시, 구조조정 등등)을 더 강조할 수 있는 일이 있다고 생각합니다그래서 한 패턴 보다는 내용에 따라 적절히 혼합하는 것이 좋을 것 같습니다!결국 스토리로 쭉 풀더라도 내용이 읽기 어렵거나 혼잡하다면 불릿을 사용하는게 맞을 것 같습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

실무에서 진행한 쿼리 개선 사례 공유 관련 질문드립니다

안녕하세요 질문 감사드립니다! 해당 내용정도는 문제 없을 것 같습니다!도메인 분류나 어느정도 설명은 충분히 괜찮다고 생각합니다기밀사항이나 너무 실무적인 디테일만 기입하지 않으면 되기 때문에 만약 커머스 도메인이면 일반적으로 상품, 주문, 쿠폰 등 일반적으로 누구나 존재에 대해 알고 있는 도메인에 대해서 언급하고 설명해도 괜찮습니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

궁금한점이 여러개 생겼습니다.

안녕하세요 질문 감사드립니다! 2회독이라니 너무 감사하네요!ㅎㅎ[질문1]이것 또한 트레이드오프가 있지만 저는 객체지향을 선호하는 파라서ID와 같은 단일 타입보다는 객체로 보내는게 훨씬 더 확장성에 열려있다고 생각합니다!그치만 단순한 조회이고 명확하다면 ID 컬렉션을 보내는 부분은 괜찮다고 생각합니다다만 요구사항은 계속 변하고 그에 따라 코드도 변해야하기 때문에 getCouponsForMenus 가 지금은 ID만 필요할 수 있어도 장기적으로 coupon 의 다른 값도 같이 넘어와야한다면, 함수 시그니처(함수의 중요 인터페이스)가 수정되어야 하기 때문입니다, 그래서 왠만한 상황에선 객체가 더 좋다고 생각합니다 [질문2]개인적으로 인증은 항상 직관성과 복잡성이 중요하다고 생각하는데 괜찮은 접근이라고 생각합니다 :D [질문3]우선 성능상 처리는 대부분 상황에서 99% 쿼리가 우세합니다문제는 복잡도와 직관성의 차이라고 생각합니다 AI 100%의 신뢰성 있는 시스템이 된다면 쿼리가 무조건 유리하겠죠ㅎㅎ다만 사람이 봐야할때 만약 엄청 큰 쿼리 기반으로 만들어진 소프트웨어라면 그 재앙이.... 😅저는 단기 미래적으론 사람과 AI협업이 중요하다고 생각해서 코드 기반을 선호합니다아무리 AI가 잘 해줘도 복잡한 쿼리와 런타임에서 문제가 발생 할 수 있는 변수는 무시 못 하겠더라구요(게시판 서비스 정도라면 약간의 장애가 나도 괜찮으니 무방하다고도 생각합니다ㅎㅎ)다만 적어주신 것 처럼 서비스가 성능 최적화가 필요하다면 얘기는 달라진다고 봅니다물론 그럼에도 저는 쿼리를 적용하는 것 보다 캐시 레이어에 대한 고민을 하겠지만요ㅎㅎ그래서~ 마지막에 질문주신 네이밍 일관성은 크게 중요한 부분은 아니지만 가급적 프로젝트 내에 일관성을 유지해주면 좋을 것 같다고 생각합니다!저도 질문을 보면서 의식의 흐름대로 답변했는데 잘 되었는지 모르겠네요!모쪼록 답이 되었길 바랍니다! 감사합니다!

회사의 시스템 아키텍처를 포트폴리오에 써도 되나요?

안녕하세요 질문 감사드립니다대외비 및 민감 부분을 제외한 회사의 시스템을 작성하는 것은 가능하다고 생각합니다다만 너무 상세하게 회사 내부 문서 수준으로 적는 것은 지양하는 것이 좋다고 생각합니다전략에 따라 다르다고 생각합니다만 저라면 포트폴리오에는 약식으로 적고 면접 시에 보안 이슈가 없는 부분에 대해서 추가적으로 설명하면 좋을 것 같습니다어짜피 포트폴리어에 아키텍처라고 적어놔도 서류 검토자든 면접관이든 100% 문서만 보고 이해하기는 어려우니까요제 기준이긴하지만 이력서가 충분하다면 포트폴리오는 잘 보지 않게 되고 면접에서 필요 시에만 사용하게 되는 것 같습니다 첨부해주신 그림 수준 정도로는 적어도 되지 않나 싶습니다 (별개로 DNS가 그려져있는 디테일은 따로 의미가 없다면 굳이 안 그려도 되지 않나 싶습니다!)모쪼록 답이 되었길 바랍니다! 감사합니다!

Sequence 관련 질문

안녕하세요 질문 감사드립니다저는 요구사항과 본질적으로 그 요구사항을 분석/이해 해봤을 때 타당한 사항이라면 데이터베이스에 반영하는 편입니다항상 개발을 할 때 더 하는 것은 쉽지만 뺴는게 어려운 것 같습니다, 특히 레거시가 무지막지하면 더욱 그렇죠그렇기 때문에 가능하면 더하는 부분, 특히 반영하면 영구적으로 추가되는 디비 필드 같은 경우는 고민을 좀 더 많이 하는 편입니다.image reordering이 어떤 기능인지 잘 모르겠지만 기능의 요구사항상 충분히 타당하면 추가하는게 맞겠지요!

Image Only Query

안녕하세요 질문 감사드립니다데이터량이 많다는 전제라면 EXISTS를 사용하는 것이 효율적일 것 같습니다!

프로필 사진 세팅과 관련하여 질문 드립니다

안녕하세요 질문 감사드립니다이것 또한 지원하는 회사 스타일에 따라 다른 부분이긴합니다!다소 경직되어있거나 전형적인 회사의 경우 증명사진 스타일이 좋을 것 같구요일반적인 테크/서비스 기업이나 스타트업의 경우는 얼굴이 충분히 보여서 인식이 가능한 일반적인 사진으로해도 전혀 문제 없다고 생각합니다!강의에서도 언급하였지만 저 같은 경우도 SNS/GitHub/이력서 모든 사진을 한개로 통일해서 인식성(?)을 높이는 편입니다!

이직 준비 방향에 대한 조언을 구하고 싶습니다.

안녕하세요 질문 감사드립니다사실 성공적인 이직을 위해서는 두가지 모두 병행해야한다고 생각합니다그치만 현실적으로 불가능하다면 1번에 무게를 두시는 게 좋을 것 같습니다외부링크는 서류 합격탈락에 엄청 큰 영향이 있지는 않습니다 부가 정보 역할입니다현재 이력을 잘 풀어내는게 더 중요할 것 같습니다!