안녕하세요!강의 수강중 예시로 보여주신 이력서를 보고 궁금한게 있어서 질문글 남깁니다! 수정후 B님과 수정후 C님의 이력서를 비교해보았을때, 포맷이 살짝 다른데요. 프로젝트나 내용을 작성할때,B님같은 경우는 내용과 불릿을 거의 50:50비율로 사용하여 컴팩트하게 보여주셨고 C님 같은 경우는 내용을 줄글로 작성하셨습니다.  물론 정답이 없다는 것은 알고 있지만 제미니님의 취향이라던지 선호하는 스타일은 어떤 쪽이신지 궁금하여 참고차 문의드립니다!

안녕하세요. 혹시 라이브 내용 모두 녹화본이 제공되나요?

안녕하세요 재미니님, 강의 정말 유용하게 보고 있습니다.강의에서 회사 기밀은 이력서에 작성하지 말라고 하신 것을 봤는데 혹시 아래와 같은 쿼리 개선기도 좀 조심스러운 부분일까 싶어 여쭤보게 되었습니다.https://byeongmin.kr/posts/2023-07-30-mongodb-aggregation-query-optimization/회사나 서비스를 식별할 수 있는 정보는 최대한 검열했다고 생각합니다.추가적으로 이력서에서 이 개선기가 “어떤 도메인이었는지” 까지는 보통 공개해도 괜찮은 편인지 여쭙고 싶습니다.시간 내주셔서 감사합니다.

안녕하세요. 기존에 이력서와 포트폴리오 두개를 작성한게 있는데 막혀서 강의를 듣게 됐습니다.기존에 작성한 이력서 형식 중 프로젝트 부분을 강의와 비슷하게 기술 스택, 프로젝트 설명, 수행하게된 원인, 수행한 역할, 결과 및 수치를 각각 한줄씩 작성을 해서 총 4장 분량이 나왔습니다.강의를 수강하기 전에 시니어 개발자분께 멘토링을 한번 받았는데 이력서가 너무 길다고 프로젝트 부분은 빼고 각 회사별로 경력 영역만 작성하라고 하셨습니다. 이력서는 짧으면 짧을수록 좋고 최대한 1장으로 만들라는 피드백을 받았습니다. 해당 강의가 2년 전에 업로드 되었던데 지금 시점과 차이가 있는걸까요? 아니면 강의에서 알려주신대로 따라가되, 내용을 더 줄이고 프로젝트를 몇개 빼서 분량을 줄이는게 좋은걸까요?그리고 포트폴리오에서는 문제->해결과정->결과->배운점 흐름으로 상세하게 작성했는데 해당 내용을 요약한게 이력서인 걸까요? 중복되면 안된다고 하는데.. 어떤게 맞는건지 너무 어려워서 질문 남깁니다.그리고 혹시 인프런 멘토링 기능에서 이력서 멘토링은 따로 안하시나요? 하신다면 받고 싶습니다.

첫회사에서 jsp 유지보수 경력을 쌓다가 스타트업의 프론트엔드 개발자로 이직을 하려고 하는데 회사 경력이 유지보수 위주라 react관련 실무 경험을 적을수 없어서 이런 상황은 어떻게 작성하면 좋을까요?

안녕하세요!궁금한 점이 있습니다회사의 시스템 아키텍처를 포트폴리오에 써도 되나요? 면접에서는 프로젝트의 시스템 아키텍처가 어떠한지 물어본다고 들었습니다!그래서 포트폴리오에 시스템 아키텍처를 명시하려고 하는데,포트폴리오에 넣어도 되는건가요?아니면 보안상 문제 때문에 넣으면 안되는건가요?시스템 아키텍처를 넣어도 된다면 어느정도 수준? 까지 공개해도 되는건지 궁금합니다!  (제대로 그린건지는 잘모르겠습니다 ㅎㅎ;;)예를 들어, 이 정도 수준의 정보라면 포트폴리오에 넣어도 문제가 없는 걸까요?

안녕하세요. 인덱스를 활용한 조회 성능 개선을 공부하던 중 궁금한 점이 생겨 질문드립니다.현재 저는 OFFSET 기반 pagination을 사용하는 서비스를 개발하고 있으며, 다음과 같은 환경에서 성능 테스트를 진행했습니다.데이터: 약 1,000만 건서버: EC2 t3.smallDB: RDS t4g.microk6 vus1001. 문제 상황초기에는 OFFSET 제한 없이 마지막 페이지까지 이동 가능하도록 구현했습니다.하지만 데이터가 1,000만 건 수준으로 증가하자, 깊은 페이지로 갈수록 조회 속도가 급격히 느려지는 문제를 확인했습니다.2. 고민 및 제약일반적으로 이 문제는 Keyset Pagination(커서 기반)으로 해결하라고 많이 알려져 있습니다.하지만 제 서비스는👉네비게이션 바를 통한 페이지 직접 이동 (ex. 1, 10, 100 페이지 클릭)이 필요하기 때문에 Keyset 방식만으로는 요구사항을 만족시키기 어렵다고 판단했습니다.3. 적용한 개선 방법다음과 같은 방식으로 성능 개선을 진행했습니다.OFFSET 최대 범위를 제한 (최대 10,000 페이지 / OFFSET 100,000)커버링 인덱스 적용조회 방식 개선먼저 ID만 조회 → 이후 필요한 10건만 상세 조회전체 게시글 수(count)는 캐싱 처리4. 성능 개선 결과[Page 10] avg: 1.4s → 700ms p95: 4.5s → 1.8s [Page 100] avg: 17s → 1.18s p95: 24s → 3.3s [Page 1000] avg: 32.1s → 1.7s p95: 59s → 4.27s SQL 쿼리는 분석결과 약 1700MS -> 70MS 까지 단축한 것 같습니다.5. 추가 제약사항로그인 사용자와 비로그인 사용자의 조회 결과가 다름(사용자별 구독 게시글이 포함됨)따라서 캐시는 비로그인 사용자에만 적용위 성능 수치는 로그인 사용자 기준6. 현재 고민위와 같이 개선했지만,👉 여전히 성능이 충분하지 않다고 느끼고 있습니다.특히 궁금한 점은 다음과 같습니다.7. 질문OFFSET 기반 pagination을 유지하면서👉추가로 성능을 개선할 수 있는 방법이 있을까요?다음과 같은 방법들을 고려했는데, 방향성이 맞는지 궁금합니다.RDS를 2개를 사용하여 조회 성능 데이터를 각각 2개의 db가 처리하도록 한다?Keyset + OFFSET 혼합 방식(일반적인 페이지 이동은 Keyset Pagination을 사용하고,사용자가 특정 페이지를 직접 입력하거나 점프하는 경우에만제한적으로 OFFSET 기반 조회를 사용하는 혼합 방식)RDS 스펙 업그레이드또한 에펨코리아(https://www.fmkorea.com/)와 같은 대형 커뮤니티는 제가 원하는 페이지 네이션 방식을 사용하면서 깊은페이지(최대 1만)도 지원하고동시접속자 수십만페이지 수천~수만대량 데이터환경에서도 빠른 조회 성능을 유지하는데👉이러한 서비스들은 어떤 방식으로 pagination 및 조회 성능을 처리하는지 궁금합니다.

안녕하세요 :) 이력서에 프로필 사진을 넣으라고 하셨는데, 이 프로필 사진이 증명사진 스타일이어야 좋은지 궁금해서 질문드립니다. 평소 GitHub, 혹은 SNS 프로필로 쓰고 있는 사진이 있는데, 이런 사진을 제출 서류에 사용해도 괜찮을까요? 증명사진보다는 조금 더 편안한 인상을 드리고 싶어서요.혹시 읽으시는 입장에서 정말로 지양하여야 하는 지점이 있다면 함께 알려주시면 감사하겠습니다.

안녕하세요 구글 폼 작성 완료하였습니다. 깃 허브 권한 부탁드립니다!미리 감사드립니다 :)

다른 분들에게 도움이 될까 글을 작성합니다.  저는 윈도우 환경에서 InteliJ를 사용하고 CLI 화면이 편하기 때문에 WSL를 사용하여 도커를 사용했습니다. 해당 전에 문제 해결들은 자료가 없어서 해결 방안만 말씀드리겠습니다.cloud... gradle 문제 해당 프로젝트가 One Driver에 있기 때문에 클라우드 상에 있는 그레이들이 안되는 것으로 알고 있습니다. 만약 프로젝트가 One Driver에 있다면 One driver 밖으로 이동 시켜주세요WSL 도커를 실행해도 윈도우 환경에서는 컨테이너를 찾지 못하는 경우가 있기 때문에 Window 환경에서 도커를 실행 하세요 해당 예외들이 터진 후에 모든 테스트 로직에 대해 예외가 발생합니다.BackendportfolioApplicationTests > contextLoads() FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDelegate.java:143 Caused by: java.lang.IllegalStateException at LoadingCache.java:75 Caused by: java.lang.ExceptionInInitializerError at Class.java:-2 Caused by: java.lang.IllegalStateException at DockerClientProviderStrategy.java:277원래 전에는 build와 테스트가 잘 진행되었는데 무슨 일인지 Test에서 도커를 만들지 못하는 문제가 생겼나 봅니다. 저는 테스트에서 사용되는 DB Config들을 사용하는 곳에 주석 처리하고 도커 컴포즈로 DB를 주석 처리하고 테스트에서 사용되는 DB들은 Docker compose에 사용되는 DB를 켜서 사용했습니다. Docker Compose에서 사용되는 DB로 사용되기 싫으시다면 Docker 컨테이너로 따로 만드시면 될 것 같아요 @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @SpringBootTest //@Import({TestDatabaseConfig.class, TestRedisConfig.class}) public @interface IntegrationTest { } docker compose up db redis -d   build 관련 에러들은 어노테이션 설정, gradle 설정, 컴파일 설정 등 많은 이유가 있어 하루 종일 붙잡아도 문제 해결이 안되는 점이 많아 시간으 며칠 잡아 먹었네요 글을 깔끔하게 가독성 좋게 작성하지 못해 아쉽지만 다른 사람들이 똑같은 문제를 맞았을 때 해당 글이 도움이 되길 바랍니다.

비전공 개발자로, 6년차 백엔드개발자입니다.이전회사에서 다른 업무로 2년정도 근무를 했는데, 해당 경력을 기입하는 게 맞는지 문의드려요

제미니님 안녕하세요, 이직 준비 방향에 대해 조언을 구하고 싶습니다. 현재 백엔드 개발자로 약 3년 차이고, 업무 강도가 높은 상황이라 준비 시간 확보가 쉽지 않습니다. (거의 매일 야근과 주말 출근이 병행되는 상황입니다..)그래서 아래 두 가지 방향 중 어떤 것이 더 효과적인지 고민하고 있습니다. 이력서와 면접 준비를 먼저 집중해서 빠르게 지원을 시작하는 방향블로그, 프로젝트 정리 등 포트폴리오를 충분히 보강한 뒤 지원하는 방향 머리로는 이력서를 먼저 쓰고 면접을 준비하는 것이 맞다는 것을 알고 있습니다. 다만 신입 때 취업한 것과 첫 번째 경력 이직 모두 블로그를 관리한 것의 이점으로 이직에 성공했다고 생각하여 두 번째 경력 이직 또한 블로그 관리를 먼저 수행해야하나 고민이 듭니다. 다만 블로그 관리와 깃헙 관리를 안 한지 한참되어 다시 관리하기에는 최소 1분기 내지 반년이 소요될 것으로 예상되고, 그렇게되면 이직이 너무 늘어지는 것 같아 고민입니다.  블로그나 깃헙이 관리가 안 되어있어도 이력서를 충분히 재밌게 잘(?) 쓰면 면접에 불리게되는지 궁금하기도 하네요... 모쪼록 제 상황에서는 어떤 전략이 더 현실적이고 효율적일지, 간단하게나마 조언해주시면 정말 감사하겠습니다. 바쁘신 와중에도 시간내어주셔서 감사드립니다.

안녕하세요 제미니님좋은 강의 잘 듣고 있습니다.강의를 들으며 이력서를 수정하고 있는데, 몇가지 고민이 생겨서 질문드립니다! 1.현재 저는 저연차 경력(1~2년)을 가지고 있습니다.이 상황에서 이력서를 작성할 때, 입사 전 팀 프로젝트에 대한 경험을 적어도 되는지 궁금합니다.해당 프로젝트는 서비스 런칭까지는 했지만 사용자가 적어 운영을 길게하지는 못했습니다.개발을 하면서 기술적으로 깊다고 하기는 좀 어렵지만 저연차의 기준에서 보면 나름 유의미한 경험들인 것 같습니다.(동시성이슈, 쿼리 튜닝, 트러블 슈팅 등)신입도 지원가능한 공고에는 프로젝트도 적고, 경력이 있어야만 지원가능한 공고에는 빼는 것이 좋을까요? 2.이력서와 경력기술서, 포트폴리오를 각각 어떻게 구성해야 좋을지 고민입니다.원래 이력서에는 해당 업무에 대한 내용과 성과를 두줄 정도로 적고, 포트폴리오에 배경과 문제, 해결 방법, 성과 등을 적어왔었습니다.그런데 강의를 보니 이력서에도 좀 자세하게 적는 것이 좋다고 말씀하셨는데, 포트폴리오랑 내용 겹치는 부분이 생길 것 같은데 괜찮을까요?보통 이력서와 포트폴리오 / 이력서와 경력기술서 이런식으로 같이 제출하고있습니다. 3.1~2 년 사이 기간동안 일하다가, 퇴사 후 다른 회사 인턴을 진행했습니다. 3달 안되는 기간이었는데, 이 내용도 이력서에 넣는 것이 좋을까요? 인턴을 빼는 경우 공백이 약 8개월 넘게 생겨서 고민입니다.만약에 적는다면 경력에 시간 순서대로 쓰는게 좋다고 하셨는데, 정규직 경력을 먼저쓰고 인턴을 적는 것이 좋을지.. 아니면 인턴 경력은 정규직 경력 밑에 따로 빼서 적는 것이 좋을지 조언부탁드립니다.질문 내용이 많은 것같아서 죄송합니다.긴글 읽어주셔서 감사합니다.

기존에 백엔드 개발자 포지션으로 오래 근무하다 새로운 회사의 초기팀으로 가서클라이언트 개발위주로 했지만 회사의 초기 설계, 발전까지 2년정도 깊게 수행했습니다.팀에서 백엔드도 개발했지만 제품의 특성상 크게 이력서로 적을 내용은 딱히 없는것 같은 상황입니다. 이직시 다시 백엔드 포지션으로 넣으려고 하는데 최근 경력의 포인트는 생각하기에 아래와 같습니다.클라이언트를 깊게 개발한 내용초기 팀 설계, 발전등 비즈니스적인 부분에 집중해 운영했던 부분제품에서 AI Agent 여러개를 병렬로 깊게 제품에 연동해 운영한 경험 다만 이력서를 최신으로 정리해서 보니 임팩트가 중요한 첫장에 백엔드 포지션으로 적절한 내용을 무엇으로 넣을지 고민입니다. 생각해본 내용은 다음 세가지와 같은데AI 개발 구현에 대한 설계 부분으로 논리적인 이유를 어필하고 마지막 줄에 클라이언트 개발 축약아니면 최신순의 내용은 아니지만 이전의 백엔드를 적고 밑에 초기팀 경력을 작성이력서에는 축약된 내용으로 작성 -> 경력기술서로 표현다만 3번의 경우는 이력서에서 너무 클라이언트 경력이 처음이라 좀 걱정이되어 1,2번의 상황에서 고민중입니다.외부인의 입장에서 보셨을때 혹시 다른 옵션이 생각나시는지, 아니면 지금 선택에서 좀더 괜찮은 부분이 보이는지 궁금합니다.

안녕하세요! 자세하게 이력서에 대한 노하우들을 들려주셔서 열심히 강의를 들으며 이력서를 수정해나가고 있습니다 :)강의를 듣다가 두 가지 궁금한 점이 생겨 질문드립니다. 이력서 내에 소프트 스킬을 어필하고 싶은데, 이를 어떻게 녹여내야 할 지 혹은 적는 게 이력서에 대한 매력을 더 떨어뜨리나 고민입니다.소프트 스킬은 사실 수치화가 어렵기 때문에 이력서의 자기 소개 부분에 어필하기에도 너무 뻔한 문장이 될 것 같고, 예를 들어, “다이어그램을 적극적으로 활용하여 더 이해하기 쉽게 팀원과의 지식을 공유한다” 같은 내용을 보여주기 위해 외부 링크들을 추가하면 강의에서 나왔던 내용처럼 집중력을 흩어지게 할 것 같아 고민되는 것 같습니다.  가끔씩 프로젝트에 대한 기여도를 작성하라는 공고를 마주하는데, 항상 프로젝트에 기여도를 첨부하는 것이 옳은 방식인지 고민입니다.       기술 스택과 비슷한 느낌으로 프로젝트에 얼마나 기여했는 지도 주관적인 느낌이라 숫자로 표기하기보단, 어떤 작업들을 하였는 지 간단히 나열하였는데 숫자로 보여지는 것이 더 면접관님 입장에서 이해하기 편할 지도 그 시선이 궁금합니다.

일반적으로 경력자의 포트폴리오는 어떤 형태를 가질까요? 처음 경력 이직을 준비하고 있는데 경력의 포트폴리오가 잘 이해되지 않습니다. 찾아보면 포트폴리오는 회사 업무 외에 개인적으로 진행한 프로젝트라고 하고, 또 다른 데에선 경력기술서라고도 하고, 어디선가는 회사 업무나 개인 프로젝트 진행 중에 인상적인 문제해결 과정을 설명하는 것이라고 합니다. 제가 생각하고 있던 포트폴리오란 프로젝트 코드 결과물이나 관련 문서입니다. 그런데 저마다 포트폴리오를 다르게 이야기 하고 있어 어떤 것이 가장 좋은 포트폴리오인지 갈팡질팡합니다. 따로 채용 사이트를 가지고 있는 회사는 포트폴리오가 선택이라 쓰여있지만 사실 상 필수라고 알고 있습니다. 가장 좋은 포트폴리오는 어떤 형태여야 할까요? 마지막으로 강의에서 프로젝트를 어필하는 내용을 작성하다 보면 흡사 경력기술서와 인상적인 문제해결 과정을 작성하게 될텐데, 포트폴리오가 단순히 프로젝트 코드 결과물이 아니라 경력기술서, 문제해결 과정 서술 형태도 가능하다면 이력서의 내용을 반복하는 것이 아닌가 하는 생각까지 미쳤습니다. 결국 포트폴리오에 대한 개념이 잡히지 않은 것 같은데 개발자, 경력자의 가장 좋은 포트폴리오가 무엇이라고 생각하시나요?

안녕하세요 취업폭격기 제로미니 입니다.정규과정을 신청하신분은 Zeromini-lab 권한, Zeromini Git Hub 취업자료 권한 신청 관련하여디스코드 (제로미니 IT취업 공부방) [초대장] 을 통해 '취업폭격기 제로미니'에게 다이렉트 메시지를 남겨주시면내용을 안내해드리도록하겠습니다!  제로미니님! 권한 부여 요청드립니다.! github

[강의 수강 직후 작성한 초안]서비스 개발 초기에는 가설 검증을 위해 빠르게 기능을 구현하는 것이 팀 목표였습니다. 하지만 화면 설계의 기준점이 될 공통 패턴과 가이드라인이 부재하여 화면마다 UI/UX를 새롭게 정의하는 방식으로 진행되었고 이로 인해 의사결정 시간이 길어지고 결과물의 일관성도 떨어지는 문제가 있었습니다. 이를 해결하기 위해 공통 가이드라인 안에서 필요한 기능과 형태를 선택해 활용할 수 있도록 디자인 시스템 구축을 제안하고 직접 설계·도입했습니다. 리소스가 부족한 상황에서 자칫 오버 엔지니어링이 될 수도 있었지만, 기능마다 UI/UX를 조율하는 방식이 오히려 전체 개발 속도를 저하시킬 수 있다고 판단했습니다.디자인 토큰 정의, 컴포넌트 별 기능과 형태를 표준화하고, 이를 기획·디자인이 기준 문서로 활용할 수 있도록 배포했습니다. 그 결과 한정된 선택지를 활용함으로써 디자인 의사결정 시간을 줄일 수 있었고, 재사용 가능한 컴포넌트 중심으로 개발 구조를 전환해 기능 개발 소요기간도 기존대비 평균 50% 이상 단축했습니다.--[수정]프로젝트 개발 초기에 화면 설계 가이드라인 부재로 화면마다 UI/UX를 개별 설계하는 방식으로 진행되어, 의사결정 시간이 길어지고 코드 재사용성이 떨어지는 비효율이 발생했습니다. 이 방식을 지속한다면 화면이 늘어날수록 UI 조율과 중복 구현 비용이 누적되는 구조였기 때문에, 디자인 시스템을 먼저 구축하고 정해진 범주 안에서 기획과 디자인을 하도록 제안했습니다.디자이너와 상의하여 디자인 토큰과 컴포넌트의 기능·형태를 정의한 뒤, Panda CSS를 활용해 토큰을 primitive, semantic 구조로 구현하고 컴파일 단계에서 유효성을 검증할 수 있도록 했습니다. 컴포넌트는 radix, base-ui를 기반으로 웹 접근성과 기능 안전성을 확보하되, 다양한 조합이 필요한 경우 컴파운드 패턴으로, 사용성이 중요한 경우 단일 구조의 prop 확장 방식으로 구현해 컴포넌트별 추상화 수준을 분리했습니다. 파운데이션 가이드와 컴포넌트 스토리는 별도 웹으로 배포하여 디자이너·기획자가 직접 스펙을 확인할 수 있도록 했습니다.그 결과 한 화면을 기획부터 개발까지 평균 2주 소요되던 기간이 4-5일로 단축되었습니다. 작성 시 고려한 것배경과 상황(스토리)을 제시"배경/상황 -> 문제 -> why?(문제원인) -> how?(어떻게 했나?) -> 결과" 구조로 접근주요 수정 부분첫번째 문단의 "상황,배경"의 내용을 간략화두번째 문단에서 "어떻게"를 구체적으로 추가세번째 문단 "결과"를 조금 더 상세한 수치로 수정질문수정전과 수정후의 차이가 "검토자 입장에서 느껴질만한 정도"인지 궁금합니다."배경"을 항상 강조하시는 것 같았습니다. 수정 후의 글에서 배경이 너무 부족한건 아닐지 궁금합니다.전체 글의 양이 너무 긴건아닌지 궁금합니다. C님의 조언후 이력서를 주로 참고하고 있는데 대부분 10줄 이내로 끊어내시는 것 같아, 더 줄여야하는건 아닌지 고민입니다. (과한 축약은 안티패턴이라고하셨지만..)10점 만점이라면, 이 글의 점수는 대략 몇점 정도 될지 궁금합니다.너무 질문을 크게 드려서 죄송합니다.하지만 이 질문 하나로 모든 방향성을 잡을 수 있을 것 같아.. 부끄럽지만 이렇게 질문을 드립니다.

1.국비학원 졸업후 2개월 가량의 짧은 웹개발 경험과 1년 반가량의 C# Winform의데스크탑 개발을 주로 했었는데데스크탑 개발 구인이 자체가 많지않고 CS프로그램 개발을 주력으로 밀고나가기엔 C++이나 C에 대한 이해가 많이 부족한 상태입니다.그래서 CS 개발자 자리가 나온다면 중점적으로 지원해볼생각이지만 자리가 적어 백엔드도 지원하려고 생각중입니다.만약에 이런경우에는 각각의 이력서를 별도로 또 작성을 하는게 맞는걸까요?2.제가 생각하기에 말씀해주신 경력사항과 프로젝트의 주된 차이점은 경력 상황: 주요역활에 따른 강점 및 핵심역량 작성 (역활이 주 / 기능은 포괄적)프로젝트 : 프로젝트별에서 기능 구현중 고민과 문제해결사항을 통해 나타난 강점작성이라고 생각이 드는데SI 환경에서는 제시해주신 [주요 역활이 주어지고 그거에 따른 상세 기능 들이 부과되는 형태] 가아니라 이럴경우에는 역활과 기능이 사실상 분리가 되어있지않은데 이럴경우엔 어떻게 작성해야하나요?

강의 초반부에서 강조하신이력서를 볼때 역량 뿐만아니라 이직하지않을 가능성도 많이 본다고 하셨습니다.2025년은 회사의 요청으로 인해서 파견회사 계약직입사 후 1.1일부로 재입사(원래 회사)2월까지 근무후 연봉협상 문제로 퇴사하게되었습니다.문제는 4대보험 기준으로 가게되면25년 6월 기존 회사 퇴사25년 12월 파견 회사 퇴사26년 2월 기존 회사 퇴사자진퇴사는 한번뿐인데 짧은기간내에 퇴사가 잦은것처럼 비춰질꺼같아 걱정이 되는데이런경우 일단은 경력사항에는 25 ~26.2 (기존회사) 작성 후 차후 면접때 전달 혹은4대보험 기준으로 작성 하는것중 어떤게 더 낫다고 보시나요?.