Q＆A
안녕하세요 질문 감사드립니다 해당 내용 앞 부분에 말씀드렸는데 빠르게 지나가서 설명이 좀 부족한 부분이 있네요! 지금 코드 기준으로는 프레젠테이션 레이어에 클라이언트를 위한 로직들 이있고 그 코드들을 백엔드가 직접적으로 알고 있는 형태 입니다 만약 시스템 설계적으로 프론트단에 SSR서버가 있거나, BFF 서버 같은 것이 존재한다면, 지금 현재 우리 코드가 가지고 있는 클라이언트를 위한 로직을 그 쪽 서버로 옮겨놓을 수 있다는 의미였습니다 그렇게 되면 백엔드 API자체는 외부 UI/UX 변화에 직접적인 영향을 훨씬 적게 받는 구조가 될 수 있고 그 만큼 순수함을 가지고 있을 수 있는 구조가 되는 것 입니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다 우선 2년 정도 지난 상황이면 검토자 입장에서 경력이 완전히 살아있는 것 처럼 보여지지는 않습니다 다만 3년이 넘어가면 아예 시간적인 거리가 길어보이는데 2년은 그래도 가까운 편으로 보여지기 때문에 이력서 자체에는 적절히 넣는게 좋을 것 같구요 다만 기간을 떠나서 업무 경력에 대해서 보여주실게 없는 상황이라면, 최대한 추출을 해보는게 우선이겠고 그럼에도 정말 업무 내용이 없는 수준이라면 개인 프로젝트에 힘을 주는 것도 좋은 전략이 될 수 있을 것 같습니다. 일단 적어주신 것만봐서는 회사 경력이 2곳정도인데 다 6개월씩만 다닌 상태에, 마지막 회사에서 퇴사한지 2년 정도 된 상태라면 유효한 경력으로 보여지기 어려울 수 있을 것 같습니다 그치만 만약 퇴사 후 2년의 시간 동안 구직을 못한 배경이나 상황 등이 있고, 근거가 존재한다면 어느 정도 납득은 시킬 수 있지 않을까 싶습니다, 그 부분도 체크해보시면 좋을 것 같습니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! 단순히 적어주신 문장만으로는 상황이 전체가 그려지지 않고 어필이 되기 어렵다고 생각합니다, 걱정하시는 부분 처럼 비춰질 가능성도 있어보이구요 결국 저 내용을 어필하고자 한다면 혼자 몇 시간을 헤맸을 때 왜 시간을 혼자 써서 헤맸는지, 의도가 있었던건지, 상황이 있었던건지, 또 그 과정 속에서 내가 깨달은 것, 고민했던 것 이런 내용들이 들어가야한다고 생각합니다 핵심은 내가 어필 하고자 하는 내용을 추출해내서 강조하는 것 이라고 생각합니다 그 관점으로 적으시려했던 경험을 곱씹어보시길 추천드립니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! 일단 면접관들은 이력서를 적든 많든 무조건 보고옵니다, 그 상황에서 면접에서 자기소개를 해달라했을때에 이력서를 읽는 수준의 자기소개라면 마이너스까진 아니더라도 궁금증이나 추가적인 포인트 점수는 "0" 이라고 생각합니다 그래서 저는 멘토링이나 일반적으로 말씀을드릴때에는 자기소개를 기존 이력서에 있는 내용을 확장한 버전 (그러니까.. 대략 이력서 자기소개랑 뉘앙스는 어느정도 맞으면서 더 풍부하고 궁금증을 만들 수 있는 내용을 첨가한버전)을 준비하는 것을 권장드립니다 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
덕분에 출간 소식을 알게되었습니다 감사합니다!ㅎㅎ
Q＆A
엥??? 저도 아직 나왔단거 못 들었는데 어디서 보셨을까요!?😳ㅋㅋㅋㅌ 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! 말씀하신 것 처럼 단순 지식이 아니라 나의 과정을 AI를 활용해서 글을 정제하는 것은 효과적인 방법이라고 생각합니다 다만 주의할 점은 뻔한 AI문체 가 있다고 하는데요, 이게 모든 글에 너무 티나게 작성 되어있다면 직접 의도를 담아 쓰신 글도 AI로 찍어낸건지 아닌건지 알 수가 없습니다. 그래서 최종적인 글의 첨삭은 직접하시는게 제일 오해를 덜 불러일으키지 않을까 싶습니다 (아니면 그것에 대한 스킬들이 이미 있다고 한 것 같긴합니다, 그걸 사용해보셔도 좋구요!) 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! 꼼꼼히 잘 보신 것 같습니다!ㅎㅎ 해당 상황에 동시적 요청이라면 찜 데이터가 두 개가 생기는 문제가 있을테니 유니크 제약으로 방어 할 수 있을 것 같습니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! 아무래도 전체 정보가 있는 상황이아니라 적어주신 단편적인 내용으로 판단한 것이기에 전적으로 신뢰보다는 참고하여 충분히 고민 부탁드립니다! [질문1] 우선 전반적으로 이력서에 경험을 적을 것이 너무 적다면 빼는 것 보다 기입하는게 좋을 것 같습니다 다만 시간이 많이 지난 것은 맞기에 너무 길지 않게 적는 것이 좋을 것 같다고 생각이드네요 사실 실제 사용자가 없었고 운영 경험이 없다면 확실히 어필 할 부분이 그렇게 크지는 않은 것 같습니다 그래서 그 부분을 강력하게 어필하기에는 아쉬운 부분이 있는 것은 팩트라고 생각됩니다 문제 정의 부분이 약하다 하더라도 업무를 진행함에 따라 어려움 또는 판단은 있었을 것 이라고 생각합니다 그 부분을 녹이는 전략을 써야 할 것 같습니다 [질문2] 이것 또한 현재 전체 경력 중 어필 할 내용이 많지 않은 느낌이라 적는게 낫다고 생각합니다 개인적으로는 오히려 별도의 트래픽을 만들 수 있는 서비스를 만들어서 실 운영에 가깝게 유저도 모아보고 성능테스트도 진행 해보는 프로젝트가 있는게 낫지 않나란 생각은 들긴하네요 종합적으로는 현재 적어주신 프로젝트 만으로는 조금 경력 사항으론 아쉬운 부분이 있는게 맞는 것 같습니다 아무래도 준비 기간도 중간에 끊겨있는 상태라서 쉽지 않은 부분이 있다고 보여집니다. 오히려 이런 경우라면 가고자하는 회사들에 채용공고를 분석해서 그에 맞춤으로 개인 프로젝트를 구성해서 준비하는 쪽에 무게를 주는게 좀 더 낫지 않을까 싶습니다만 이것도 상황에 따라 약간씩 다를 수 있어서 고민해보셔야 할 것 같습니다 아무쪼록 쉽지 않은 상황이지만 지원하고자 하는 회사들 기준으로 잘 분석해서 준비하는게 가장 뾰족해질 수 있는 방법인 것 같습니다! 제가 적은 말이 정답이 아닐테니 최종적 판단은 잘 고민하셔서 전략을 구성하시길 바라겠습니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
Q＆A
안녕하세요 질문 감사드립니다! Q1 해당 강의에서 개념과 격벽에 대하여 개념 정리를 하는데요 그런 문서를 만들고 팀에 공유합니다, 팀에 공유 자체는 PO, FE, 디자이너 모두에게 공유합니다 또 주기적으로 팀원들과 동기화 차원에서 공유를하기도합니다 해당 자료 같은것 들은 신규 입사자가 오면 활용하기도합니다 코드리뷰에서 나오기도하고, 조금 큰 개념에 대한 변경이나 추가라면 같이 모여서 리뷰를 하는 편입니다! Q2 상황마다 달라서 뭐라고 단정하긴 어렵지만 저는 중심은 개념 클래스들을 기준으로 잡고 시작합니다! API 나 DB 먼저 시작할 때도 있지만 애초에 개념 클래스와 API, DB는 격리되어있다고 생각하기 때문에 큰 축 자체는 개념 클래스로 기준을 잡고 진행합니다 추가로 저는 API 영역은 백엔드 개발자의 것이 아니라고 생각합니다 (API 자체가 제품이 되지 않는 이상) 기본적으로 사용하는 클라이언트를 위한 영역이라 생각하는 편입니다 회사 스타일 마다 다르지만 보통 기획/디자인이 나오고 개발에 들어간다면 API스펙은 뽑기 쉽기에 mock으로 구현해두고 내부 내실을 다지는 느낌입니다. 아무튼 전반적으로 개념클래스, DB구조에 더 집중하는 것 같습니다 Q3 사실 미래는 예측이 정말 불가능한 것 같습니다, 그렇지만 현재 기준으로 보면 아직 인간의 가치가 필요하고 그 부분이 설계, 접근법, 전략, 상황판단 이런 것들이라고 생각합니다 그 측면에서 여전히 인간으로써 고민하여 개념을 정의하고 격벽을 세우는 것은 의미가 있다 생각합니다 다만 이것도 AI와 협업하면 더 잘나올 수 있다고 생각하구요 저는 개인적으로 이 방법론이 팀간 협업이 살아있는 기업 수준에서는 아직도 유효하다고 생각합니다! 모쪼록 답이 되었길 바랍니다! 감사합니다!
