건강문제, 공백과 개인서비스에 대한 질문입니다.

안녕하세요 도현님 질문 감사드립니다!우선 건강이 회복 되셨다니 정말로 다행입니다! 제가 감히 과정을 모르지만 대단히 고생 많으셨습니다!! 개인 프로젝트로 실 사용자가 있는 서비스를 운영하고 있는 것은 아주 좋게 보이는 부분이라고 생각합니다또한 스토리를 덧대면 건강 회복 과정에서도 꾸준히 그 서비스를 운영 했다는 것은 도현님이 어떤 사람인지 보여줄 수 있는 부분이라고 생각합니다 제 생각에는 단순 개인프로젝트 처럼 아래에 두기에는 너무 아깝다고 생각합니다그래서 상단에 배치하는게 맞다고 생각하구요, 그에 대해서 충분히 이력서에서 보여주고 면접에서도 배경 설명이 된다면, 전혀 나쁘게 보지 않을 것이라고 생각합니다결국은 서류 검토자, 면접관을 설득하는 과정이기에 그 기준에서만 부합하면 나쁘게 볼 이유는 없다고 생각합니다해당 내용을 이력서에 충분히 설명하시면 좋을 것 같습니다!앞으로도 건강 유의하시길 바라며 취준도 화이팅 하시길 바랍니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

페이징 처리에서 offset/limit에 대한 질문

안녕하세요 질문 감사드립니다![질문1]맞습니다, 그래서 보통은 lmit(한번에 조회 하는 수)가 달라지면 첫 페이지부터 다시 조회하는 식으로 하거나 현재 페이지 기준으로 재 계산하여 조회하는 처리가 필요합니다 [질문2]일반적인 경우에서는 offset, limit 이 자연스럽습니다, 다만 성능이나 변경이 너무 빠르거나 조회 정합성이 중요하다면 커서 방식을 검토해봐야합니다 [질문3]어느 정도 범용성을 제공해야하는 API 관점에서는 limit을 고정시키는게 좋지 않다고 생각합니다클라이언트 스펙이 바뀔때 서버가 바뀌는 구조가 되니까요! [질문4]이 부분은 99% 요구사항에 따라 결정 됩니다, 다만 대부분 규모의 서비스에서는 offset / limit 으로 처리하면 되었던 것 같고, 관리자 페이지나 어드민 같은 경우는 page/size 방식이 적합한 경우가 많은 것 같습니다두 가지에서 선택의 기준이 기술적 관점 보다는 요구사항을 맞추는 관점이 크다고 보며, 이 조회 방식 자체는 비즈니스 로직 보다는 노출 영역에 가까운 스펙이라고 생각하는 편입니다!모쪼록 답이 되었길 바랍니다! 감사합니다!

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

안녕하세요 질문 감사드립니다!첫째로 어느 정도의 상황과 제약에 대해서 언급하는 것은 괜찮다고 생각합니다다만 너무 다 써서 내용이 과해지지 않는 것을 조심해야할 것 같고, 서류 검토자에게 상황이 전달 될 정도의 정보만 넣으면 될 것 같습니다고객사에 요청 자체가 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를 사용하는 것이 효율적일 것 같습니다!