#분리

7개월차 신입 이직 시 경력 기술서 따로 작성이 필요할까요?

안녕하세요. 현재 SI 회사에서 7개월 정도 다닌 신입 백엔드 개발자입니다. 이력서/포폴을 6개월에 한 번씩 업데이트를 해두면 좋다는 말을 들어서 업데이트를 할까 하는데 신입 때와 경력이 있을 때의 이력서는 많이 다를 것 같아 질문 드립니다..! 1. 이력서와 경력 기술서를 따로 작성해야 할까요? 1-1. 분리하는 게 좋다면, 두 문서의 차이는 무엇인가요? 2. 포트폴리오도 새로 정리하는 게 좋을까요? 3. SI 회사에서 외부 프로젝트를 진행했는데, 이런 프로젝트는 경력 기술서/포트폴리오에 어떤 형식으로 작성하면 좋을까요? 4. 회사에서 진행한 사내 스터디 경험도 경력 기술서에 넣어서 어필해도 괜찮을까요? 5. API 개발이나 PoC 진행처럼 성과가 크게 눈에 띄지 않는 업무는, - 단순히 어떤 일을 했는지만 작성해도 될까요? 6. 예전에 진행한 사이드 프로젝트를 포트폴리오에 넣어도 괜찮을까요? 7. 예전 이력서에 작성했던 수상 내역/대외활동 (ex: 해커톤 수상, 글로벌 인턴, 교육 이수 등)을 계속 적어도 될까요?

SaaS 운영시 Git이 구성되는 환경(?)

안녕하세요. 현재 자그마한 B2B 솔루션 회사에서 운 좋게 SaaS 프로젝트에 참가하게된 2년차 주니어 엔지니어입니다. 현재로써는 운영 아키텍처가 정해지지 않은 상태이고, EKS 기반의 퍼블릭 개발환경에서 CI/CD 및 메인 서비스에 대한 PoC를 진행하는 중에 있는데요,, 프로덕션으로 들어간다고 하면 Git과 같은 레포지토리 서버는 당연히 EKS 클러스터가 위치한 Private VPC에 구성되어야 하는게 맞는걸까요? ex) VPC Peering을 활용한 운영환경 <-> 개발환경 간의 분리, VPN G/W 활용...등 혹, 위 언급드린 방식이 올바른 경우라면 소스 커밋과 같은 작업들은 개발자들이 어떤 식으로 수행하는지 궁금합니다. 그 외로 SaaS <-> 레거시 개발환경과의 큰 차이가 존재하는 부분에 대해 언급을 주신다면 정말 감사하겠습니다:)

리액트 프로젝트에 FSD 아키텍처 적용. 이 구성이 맞을까요?

안녕하세요. 현재 진행 중인 리액트 프로젝트에서 유지보수성과 확장성에 어려움을 느껴 폴더 구조를 Feature-Sliced Design(FSD) 아키텍처 기반으로 전면 리팩토링했습니다. 기존에는 `components/`, `pages/`, `apis/` 등 기능과 역할이 섞인 구조로 되어 있어, 코드의 위치가 불분명하고 협업에 어려움이 있었습니다. 이를 해결하고자 다양한 아키텍처를 조사한 끝에, FSD의 레이어 개념(Layers)에 맞춰 다음과 같은 방식으로 구조를 정리했습니다. - `app/`: `App.js`, `index.js` 등 프로젝트 진입점과 글로벌 설정 파일을 포함 - ` entities/`: `User`, `Article`, `CodingZone` 등 주요 도메인의 데이터 모델과 API 연동 담당 - `features/`: 로그인, 게시글 작성, 코딩존 출석 등 각 기능별로 모듈화하고, 필요한 경우 `hooks/` 등의 내부 디렉토리로 세분화 - `pages/`: 라우팅과 연결된 실제 페이지 컴포넌트 관리 (예: `CreatePage`, `EditPage` 등) - `widgets/`: 재사용 가능한 독립 UI 요소들 (예: `Footer`, `Navbar`, `Pagination` 등) - `shared/`: 공통 API, 유틸, 모달 컴포넌트 등 여러 기능에서 공유되는 요소들을 배치 기능 중심의 구조로 바꾸면서, 각 요소의 역할이 명확해지고 코드 탐색 및 유지보수가 훨씬 쉬워졌습니다. 현재는 복잡한 비즈니스 로직이 없어 `processes/` 레이어는 생략했지만, 추후 워크플로우가 필요한 기능이 생긴다면 도입할 계획입니다. 제가 구성한 이 폴더 구조와 레이어 분리가 실제 FSD 아키텍처 가이드에 부합하는 방향인지, 혹시 보완하거나 개선할 부분이 있다면 조언을 구하고 싶습니다. 자세한 내용은 블로그에 정리해 두었습니다. 👉 [https://juncci.tistory.com/4](https://juncci.tistory.com/4) 읽어주셔서 감사합니다!

Jenkins & GitLab 환경을 구축하려 합니다.

운영 서버와 CI/CD 전용 서버를 분리해서 구축하는게 맞는걸까요 ? 저는 1년 미만 웹 개발자이고 회사에 물어볼 사수 동료가 전혀 없어서 여쭤봅니다 Jenkins & GitLab 환경의 선배님들 조언 주시면 감사하겠습니다

자바 비동기 처리에서 쓰레드 풀 공유 대해서 질문

spring boot로 개발을 @Async 사용해서 비동기 처리를 하고 있습니다. a, b, c 비동기 작업이 쓰레드 풀을 공유하고 있습니다. a 작업이 딜레이 되며 쓰레드를 점유하고 있어 다른 작업(b, c)에 영향을 끼칠 수 있는 경우라면 보통 쓰레드 풀을 분리해서 사용하나요?

웹프레임워크와 db 분리의 장점은 무엇인가요?

db 관련 내용들을 독학하다가 궁금한 점이 생겨서 질문드립니다. 기본적으로 db를 지원해주는 웹프레임워크를 사용할 때, 기본db를 사용하지 않고 mysql연동과 같이 db를 웹프레임워크에서 분리해 사용하면 어떤 장점이 있는지 궁금합니다! 추가로 mysql과 웹프레임워크를 연동했을 때, mysql에서 직접 트리거나 제약을 설정하면 그게 웹프레임워크에도 영향을 주나요? 로컬에서만 영향을 주고 배포 후에 영향이 없는 것은 아닌가요?

클래스가 너무 커질때

클래스를 기능별로 분리한 후 1. Facade 패턴을 이용해서 하나로 합친다. 2. 컨트롤러 단에서 분리된 클래스를 일일이 주입받아 사용한다. 1번 방법은 컨트롤러에서 쓰기 간편하니 좋지만, 하나로 합쳐진 클래스가 여러 책임을 지게 될까봐 걱정되고. 2번 방법은 컨트롤러 메서드 적을 때 이 클래스 저 클래스 다 끌어와야 해서 걱정됩니다. 스프링 공부하면서 간단한 게시판 만들고 있습니다. 조회 방식이 좀 다양해서 조회 관련 메서드만 14개가 나왔는데 등록, 수정, 삭제까지 합치니까 하나의 클래스에 담기에는 너무 무거워보입니다. 조회는 따로 떼어놓으려고 하는데 게시글 관련 클래스가 3개가 돼버려서 그 클래스를 대신 호출해줄 클래스를 두려고 합니다. 뭔가 해결책이 찝찝한데 좋은 방법 없을까요?

권한 관리 AOP와 영속성 컨텍스트 문제

프로젝트를 진행하던 중, 해당 펫이 api를 요청하는 유저가 소유하고 있는 펫이 정말 맞는지 확인하는 권한 검사 로직 등이 중복으로 발생해서 이를 비즈니스 로직에서 분리하고자 스프링 AOP 기술을 활용해보려고 했습니다. 동작은 잘 되지만.. Pet을 조회하는 쿼리가 중복해서 2번이 발생하더군요. 저는 OSIV가 꺼져있더라도, 비즈니스 레이어에서 같은 트랜잭션 내에서 동작하기에 AOP에서 조회한 엔터티도 같은 영속성 컨텍스트에서 관리될 거라고 생각하고 위처럼 작성했는데 어디가 문제인지 모르겠어서 도움을 부탁드립니다.. ㅠㅠ 혹시 가능하시다면 현업에서는 중복되는 권한 체크 로직을 어떻게 관리하시는지도 알려주시면 큰 배움이 될 것 같습니다!

Next.js 코드 가독성..

안녕하세요 프론트앤드 1년차에 다가가고 있는 신입 개발자입니다. 현재 Next14를 사용하고 있으며 코드의 가독성, 효율성을 많이 고려하면서 코드를 짜려고하는데 너무 고민이 되네요 저보다 앞서서 달려가고 있는 개발자 선배님의 생각을 듣고싶습니다 ㅠㅠ... 2가지가 궁금합니다. 먼저 첫번째 이미지처럼 Version에 관련된 파일을 저렇게 분리했을 때 저는 Version의 최상위 Layout.tsx에서 모든 것을 선언하기가.. 너무 오히려 가독성이 안좋다고 생각을 하고 있습니다 즉, 변수나 함수를 모두 최상위 Layout.tsx에서 선언 및 정의를 해두고 props로 내려주는게 이상하다고 생각을 합니다. 변수, 함수, useEffect 모두 직접 해당 변수나 함수를 컨트롤하는 부분에서 선언 및 가공을 하는게 맞다고 생각을 합니다. 최상위 Layout.tsx가 너무 무거우면 오히려 나는 VersionDataTable에 관련된 변수나 함수만 보려고 하였으나 최상위 Layout.tsx를 보고 아 이게 VersionDataTable에 필요하구나 뭐가 필요없구나, useEffect의 의존성 배열까지 고려하는것이 불필요하다고 생각을 하고 있습니다.. 근데 같이 프론트 앤드 개발하시는 분께서는 '단기적으로 절대 코드가 변하지 않는다고 생각하면 그 말씀이 맞는데 그건 아니잖아요? 우리는 계속 유지보수를 할거고 그러면 결과적으로 A에서만 사용하던 변수나 함수들을 A,B,C에서 같이 사용할 수 있게 변경하게 되면 그때 변경하면 유지보수 측면에서 너무 안좋습니다. 최상위에 모두 선언이나 정의를 해두고 props로 내려주는게 맞다 이런 형식으로 코드를 작성하면 몇개월 뒤에 코드를 수정할 때 A가서 수정했다가 C가서 수정했다가 D가서 수정하실 거에요? 바로 알아보실 수 있겠어요?' 라고 말씀을 하시더라구요.. 물론 몇개월 뒤에 코드를 보거나 하면 제가 작성한 코드인데도 저는 헷갈리는 경우가 많습니다. 그러나 최상위에 모두 선언 및 정의해둬도 마찬가지 아닌가..? 유지보수 측면에서 뭐가 안좋은거지..? 라고 생각되게 됩니다.. 선배님의 말씀을 따라가고는 싶은데 이해가 안돼서요 제가 아직 기본기가 많이 부족한 상황이라 이 상황에서 말씀드리면 이론부터 말하며 설득시키기가 부족하다고 생각하기 때문에 말씀드리면 오히려 '저는 이렇게 생각해요 틀렸는데요?' 라고 말하는 것 같아 말다툼이 될 것 같습니다. 2. 밑 사진을 보면 modalTemplate라는 폴더, ConfirmTemplate이라는 폴더가 존재하는데요 이것에 대해서 저는 사용하는 용도에 따라서 Create면 Create Create와 Update를 동시에 할 수 있는거면 BundleCreateAndUpdate 이런 형식으로 각각의 파일을 생성을 하고 문법상 공유되는 부분은 중복이 되어서 실제로 보여주는 부분을 영역으로 나눠서 BasicOptions, SelectList, VersionDetail, VersionOptions로 나누고 각각의 파일에서 사용하는 부분만 불러와서 쓰는 형식으로 코드를 작성했습니다. 그러나 이렇게 용도에 따라 구분하지 않고 최상위 Layout.tsx파일 하나만 만들고 ModalType이라는 props를 받아서 ModalType이 create, update, create&update, delete ... 등 JSX에서 삼항 연산자를 써서 처리를 할수도 있습니다. 저는 ModalType으로 처음에 구분하다보니 나는 'create' 속성일 때 어떤 형식으로 되는지 코드로 보고싶은데.. 그러면 너무 뜯어서 봐야하더라구요 그래서 용도에 맞게 파일을 만들고 거기서 form을 불러오기만해서 중복 코드를 줄이는 방식을 택했습니다.. (더 나은 코드라고 생각했습니다.) 그랬지만 선배님께서 'ModalType으로 나누는게 더 좋아요 저렇게 지으면 가독성이 너무 떨어지고 파일의 이름이 너무 길어지잖아요 이상하지 않나요?' 라고 말씀을 하시더라구요... 물론 가독성은 사람마다 다른거 알고있습니다. 그러나 ModalType으로 나누기 시작하면 한도 끝도없이 나누고 ModalType이 delete일 때만 사용하는 함수, create일 때만 사용하는 함수 등 필요없는 함수도 너무 많아져서 용도에 맞게 파일을 구분하고 거기서 중복 코드만 최대한 줄이자! 라고 생각하여 코드를 작성했는데 이 내용도 말씀드려 봤지만 '가독성' 이라는 이유 하나만으로 너무 안좋다고 합니다.. 진짜 안좋은건가요..? Next 도 그렇고 프론트 앤드 너무 어렵습니다..

react 컴포넌트 작게 쪼갤경우에 파일을 분리하는게 좋나요?

현재 공통으로 사용되지않고, 하나의 page에서만 사용되는 컴포넌트들의 경우 pages폴더의 signUp 폴더에서 (회원가입 페이지의 경우) 계층으로 작성하고있습니다. 단일책임원칙에 따라 하나의 컴포넌트가 하나의 일만 하도록 작게 쪼개고있는데, 폴더의 뎁스도 늘어나고 파일이 너무 많아지는거같아 이렇게 하는 방식이 옳은것인가? 라는 의문이 들어 질문을 작성합니다. 이처럼 컴포넌트를 하나의 일만 하도록 최대한 작게 쪼개는게 옳은 방식인지... 그렇다면 폴더를 계층으로 쪼개는게 맞는건지... 알려주시면 감사하겠습니다 ! 한가지 예시 signUp/content /form / buttonGroup.tsx 요런식입니다

신입 개발자 취준 고민이 있습니다

안녕하세요 신입 개발자로 취업을 하고싶은 준비생입니다. 부트캠프 수료한 지가 곧 있으면 1년이 다 되어가서 얼른 취업을 해야하지만 서류에서 광탈을 하는 상황입니다. 혼자서 생각하기에는 좀 고민되는게 있어서 경험이 많으신 분들에게 질문을 드리고 싶어서 글을 작성하게 되었습니다. 기존 포트폴리오는 자바스크립트,리액트 nodejs을 사용한 프론트, 백엔드를 둘다 다룬 프로젝트로 팀플 1개개인 프로젝트가 1개가 있고 구직기간 중 학습한 것을 바탕으로 만든 플러터 앱 프로젝트로 총3개가 있습니다. 취업을 위해 기존 프로젝트를 보완하거나 기존 스택을 이용하고 좀더 발전된 코드로 새로운 프로젝트를 추가하는 노력을 하는게 나을까요? (예를 들어서 상태관리 폴더 구조 관심사 분리 데이터베이스 설계 등을 기존 프로젝트보다 레벨업해서 새로 프로젝트 만들기) 아니면 취업을 위해 다시 한번 6개월 정도의 부트캠프를 다니는 것은 좋은 선택이 아닌걸까요? 찾아본 부트캠프로는 자바 풀스택 부트캠프 (지금까지 자바스크립트 기반으로 공부를 했기 때문에 자바까지 공부하게되면 이도저도 아닌 것 같이 보일까 걱정이긴하지만, 수료 후 취업 할 수 있는 기업수가 많아질 수 있어 좋겠다고 생각했고) 혹은 플러터 부트캠프가 있습니다. (기존 포트폴리오에 플러터 프로젝트가 하나 있어서 이와 연계해서 좀더 딥다이브하기 위해 플러터 부트캠프를 다니려고 했습니다

개발/업무 문화에 대한 의문점

안녕하세요 회사의 개발 문화에 대해 궁금점이 생겨서 질문드립니다. 저는 현재 중소기업에 AI 연구원으로 취직을 해서 이제 2~3달이 지났는데 개발 문화에 대한 의문점이 생겼습니다. 연구원이라 개발이 메인인 편은 아니지만 서비스화를 위해 현재는 연구보다는 개발에 비중이 더 큰 상황입니다. 그런데 팀에 인원이 많은 편도 아니며 파트가 분리되어 제 파트에는 사수님와 저 그리고 인턴들로 구성되어 있습니다. 그런데 거의 개별적인 프로젝트를 인턴포함해서 하나씩 맡고 코드를 완성되면 따로 피드백을 받지 못하고 사수님이 종합해서 하나의 운영 모듈로 제작하는데 이렇게 하는 방향이 맞는건지 모르겠습니다. 개별적인 프로젝트다 보니 실시간으로 업무 공유도 어렵고 코딩 실력도 늘지 않는거 같고 해서 어떻게 해야할지가 의문입니다. 이렇게 회사생활 하다가는 그냥 물경력이 될 것 같아 걱정도 됩니다.

[프론드엔드] 이력서, 포트폴리오 피드백 받고싶습니다.

대학 졸업 후 조교로 일하다 부트캠프 수료하고 이제 취업을 준비하고 있습니다. 학과가 정보통신공학이라 제로베이스 비전공자는 아닙니다. 처음에는 노션으로 이력서와 포트폴리오를 통합하여 되는대로 제출하다가 계속되는 불합격에 분리했습니다. 이력서는 꼭 필요하다고 생각되는 항목들을 한눈에 볼 수 있도록 간단하게 작성하였고, 자기소개서를 추가했습니다. 포트폴리오는 노션 포트폴리오로는 부족하다 생각해서 개인 포트폴리오 사이트를 제작했습니다. 현직자의 시선으로 제 이력서와 포트폴리오가 경쟁력이 있는지, 선배님들께 피드백을 받고싶습니다. <이력서 URL> https://drive.google.com/file/d/19bKofHn2hF8KYDQxJiPUbP8CQE6SDiBh/view?usp=drive_link/ <포트폴리오 URL> https://ksyee.netlify.app/

monorepo 에서 공통으로 사용하는 컴포넌트들 배포 관리 방법?

현재 FE 일부 서비스를 monorepo 안에서 관리하고 있습니다. 이 안에서 총 4개의 서비스를 운영중이고 서로 공통으로 사용하는 컴포넌트나 helper, util 등은 shared 라는 워크스페이스로 분리하였습니다. - apps ㄴ web1 ㄴ web2 ㄴ web3 ㄴ web4 - pacjages ㄴ shared 배포할때 변경점인 change path에 대한 고민이 있었는데, 현재는 shared가 변경되면 web1,2,3,4 전체가 배포되도록 구성했습니다. 서비스별로 수정된 shared에 의존적인 프로젝트를 특정하기 어려웠기 때문인데요. 혹시 더 나은 방법으로 운영하는 방법이 있을까요?

웹 프론트엔드 디렉토리 구조 어떻게 가져가나요?

3년차 서버 개발자입니다 반 년 전 부터 리액트 넥스트 시작 해서 공부 중 입니다 몇 개의 프로젝트를 해도 이거 컴포넌트 분할이 되게 힘들고 정리가 안되네요 서버는 뭐 DDD 헥사고날 MSA 등등 있지만 저는 경험에서 모든 것을 의존성 기준으로 도메인을 분리하고 이에 대한 트레이드 오프나 규칙같은 것도 리드할 수 있을 정도인데,,,, 프론트는 재사용성을 강조하는데 뭘 재사용하는 지도 모르겠고 UI랑 기능이랑 분리하기 힘든 것도 있고 많은 설계방식도 있는데 저한테는 과도하다 생각하고 프론트도 도메인 기준으로 나누는 FSD도 있지만 프론트 특성상 UI랑 기능이랑 분할이 되게 힘들어보이고 아무리봐도 프론트는 사용자 중심으로 가야할 거 같은데 어떻게 해야될지 모르겠네요..

프론트엔드 취준 이력서,포폴 고민

안녕하세요. 현재 부트캠프 다니는 학생입니다. 취업준비를 위해 포트폴리오, 이력서 비중을 둬야하는 것은 알지만 "포폴을 만들때 어느정도의 수준까지 만들어야 얼어붙은 취업시장의 경쟁력이 있는 포폴이 되는지 궁금"합니다 포토로폴리오 같은 경우 현재 부트캠프 외에 팀원들과 따로 만들고 있지만, 취업시장의 기대치에는 부족함을 느꼈습니다. <분리수거 배출방법 알려주는 프로젝트> typescript, styled-componets, zustand, firebase 등만 사용해서 진행하였는데 아주 간단하다보니 트러블슈팅도 없었고, 더 나아가 분리수거와 관련된 api를 활용하고자 했는데 해당 api도 없어서 분리수거 관련 퀴즈 기능, 동영상 추가 기능을 만들어볼 계획이고, moking data인 배출방법, 로그인, crud만 있는 프로젝트입니다..

MVC vs MVVM

어제부터 MVVM 아키텍처에 대해 공부를 시작했는데 이전에는 MVC 아키텍처를 사용해왔습니다. MVC의 단점은 프로젝트가 커질수록 Controller가 비대해지는 경향이 있다는 점입니다. 그래서 Controller의 부담을 줄이기 위해 ViewModel을 도입한 MVVM이 탄생한 것으로 알고 있습니다. 하지만 MVVM을 공부하면서 느낀 점은 View와 ViewModel 사이의 상호작용이 많아지면서 컴포넌트가 많아질수록 코드가 길어지고 복잡해진다는 것이었습니다. 그래서 MVC처럼 다시 View와 Controller를 분리하여 MVC와 MVVM을 혼용하여 작성하면 좋을 것 같다는 생각이 들었습니다. 이에 대해 구글링을 해봤지만 관련 글을 찾기 어려웠습니다. 이렇게 개발했을 때 발생할 수 있는 문제점은 무엇이 있을까요?

스프링부트에서 클린코드 사용 관련 질문

안녕하세요 선생님들 현업에서는 정말 아무 생각없이 사용하고 있는 개발 방식이었는데 클린 코드라는 책을 접하면서 고민이 되는 부분이 하나 있습니다. SpringBoot ServiceImpl 구현 부분에서 만약 로그인 API를 개발한다는 가정하에, 로그인 API 에는 수많은 기능들이 포함될 수 있습니다.(유효성 검증, 비밀번호 5회 연속 시 잠금, 권한에 따른 페이지 이동 기능 등등) 하지만 클린 코드의 원칙 상 '되도록 하나의 메소드는 하나의 기능만을 포함한다.' 라는 원칙에 위배되기 때문에 각각의 기능을 분리하여 작성하는 것이 맞을듯 합니다. 그러나 각각의 수많은 부가기능(이 될수도 있는)들을 만들면 인터페이스와 클래스의 개수도 그만큼 늘어나게 되고 개발에 소요되는 시간도 늘어납니다. 실제로 제가 있었던 SI회사에서는 하나의 큰 기능(로그인 API) 자체를 기준으로 메소드를 만들고 부가 기능들을 모두 하나로 구현하였습니다. SI 특성 상 마감시간 내에 빨리 완성시켜주고 빠지면 땡이기 때문에 이런 것이라 생각되는데 만약 시간적인 압박이 있는 SI개발에서 두 부분중 어떤 원칙을 지키는 것이 효율적인지에 대한 고민이 되는데 길을 좀 알려주시면 감사드리겠습니다.

API가 제공하는 데이터의 범위를 어떻게 잡을지 고민입니다.

안녕하세요. 개인 프로젝트로 풀스택 웹 서비스를 여러 번 만들어보다가 생긴 의문입니다. 보통 저는 백엔드는 nestjs와 프론트엔드는 nextjs로 개발을 합니다. 프론트 쪽에서 react query를 사용하여 백엔드의 데이터를 fetch하여 사용하는데, 한 화면에 여러 데이터가 필요한 경우가 있습니다. 원래 백엔드 api를 짤 때 resource를 기준으로 잡았었는데 이렇게 하다보면 재사용 측면에서는 좋으나 위에서 말한 경우와 같이 한 화면에 여러 resource에 대한 데이터마다의 api를 호출하기 때문에 한 화면에서 여러 api 통신이 이루어지게 되어 cost가 있지 않을까 생각이 들었습니다. 1. 그래서 아예 한 화면에 쓰이는 데이터를 전부 serving하는 api 라우트 하나를 두면 해당 api 하나만 호출했을 때 한 번의 통신만으로 데이터를 가져오기 때문에 이 방식이 괜찮다고 생각이 들었는데 실제로 어떤 것이 더 좋은지 궁금합니다. 뭔가 감으로는 리소스별로 독립된 api를 여러개 호출하는 방식이 장점이 많은 것 같은데(querykey로 캐싱을 따로 할 수 있는 등) api 갯수가 1개랑 3개라고 하면 사용자마다 3배 많은 통신이 이루어지게 되어 이 부분이 조금 걸립니다. 2. 그리고 유저에 대한 데이터를 응답한다고 했을 때 해당 테이블에 join으로 엮을 수 있는 다른 모든 테이블도 같이 포함시키는 것이 좋은지, 아님 분리시켜서 user 테이블의 속성만 제공하는 api(/users)와 다른 테이블의 정보도 같이 포함하는 api(/users/courses)를 따로 구분하는 것이 좋은지 그 범위를 아예 모든 정보를 다 가져오는 것과 딱 필요한 정보만 제공하는 것 중 어느 방식이 어떤 측면을 가지고 있는지 궁금합니다.

스프링 부트에서 웹 크롤링 파이썬 코드 호출

스프링 부트에서 웹 크롤링 파이썬 코드를 호출하고 싶은데 호출하려면 따로 장고로 API를 분리하여 스프링 부트에서 장고 웹 크롤링 파이썬 코드를 호출하여야 하나요? 아니면 jyton을 사용하여야 하나요? 추후 웹 크롤링을 하여 해당 데이터로 추천 모델링을 만들어 확장시킬려고 합니다

커리어가 꼬인거 같네요

이제 스타트업 2년차입니다 입사당시 면접에서 현재 개발중인 솔루션이 있고 내가 나의 역량을 증명하면 솔루션 개발에 참여할 수 있다고 해서 저는 저의 역량을 증명하여 개발에 합류하겠다는 마인드로 입사했습니다. 그렇게 회사에서 개발중인 솔루션의 사용법을 배우고, 전반적인 흐름이나 데이터 처리를 따로 공부하며 해외출장에도 빠지지 않고 참여하는 등 나름대로 제 역량을 증명하고자 야근도 거르지 않았습니다. 하지만 1년이 되고 회사가 커지면서 부서 개편이 되었는데 제가 솔루션 엔지니어팀에 있더라고요.. 기존에는 개발팀이지만 솔루션 엔지니어쪽 업무도 병행하고 있어서 그런줄 알았는데 이번에 개편이 되면서 개발파트와 솔루션엔지니어파트가 분리되면서 아 난 애초에 개발을 시켜줄 생각이 없었구나.. 싶더라고요 그래서 이부분에 대해 부서이전을 요청하니 여태 맞췄던 러스트나 c#쪽 개발은 이제 없고 파이썬이 대부분이라 힘들다며 정 하고 싶으면 파이썬을 공부해서 면접을 보라고 하셨습니다. 그리고 4월초에 입사한지 이제 1년을 채워 첫 연봉협상도 했는데 사실상 동결입니다..ㅋㅋ (연봉에 못들어간 1년의 성과나 희생은 모두 고과 평가로 들어가진다고....) 이직을 하기엔 이 1년 회사에 적응하고 흐름을 이해하고자 올인을 해버려서 사실 이직할 준비가 안되어 있습니다. 다만 저축을 꾸준히 해와서 아마 1년정도는 퇴사하고 시간확보가 가능한 상태입니다. 원래는 혼자 유데미에서 사왔던 강의를 보며 준비를 할까 했는데 다들 국비나 학원을 통해 만든 포폴을 보며 저도 이를 통해 준비할지.. 혼자 할지.. 고민이 많은 하루네요

신입 프론트엔드 개발자 이력서 피드백과 공부 방향성에 대해 질문드리고 싶습니다!

안녕하세요! 현재 부트캠프에서 공부중인 프론트엔드 개발지망생입니다! 현재 여러 회사에 이력서를 제출하였으나 아쉬운 소식만 들리고있습니다 이력서에 대해 많이 고민을 하고 수정을 거치고있으나, 현직 선배분들의 입장에서 어떠한 부분을 수정 하면 좋을지에 대해 알려주시면 너무 감사할 것 같습니다! 아래는 제 이력서 주소입니다! https://hallowed-amethyst-e04.notion.site/a18c3f5f74244a2982d58e8a781a1e41 두 번째로는 앞으로의 공부 방향성에 대해 여쭙고 싶습니다. 현재 공부하려는 목표는 총 네 가지입니다. 1. 최근 프로젝트를 리팩토링하기 최근 프로젝트가 기한내의 완성에 신경을 쓰다보니 컴포넌트와 비즈니스 로직 분리부분에 아쉬운 부분이 많이 있는 것 같습니다. 또 리팩토링을 통해 최근에 공부하고있는 테스트코드와 최적화 부분을 연습할 수 있는 좋은 기회라 생각하여 목표로 하고있습니다 2. 순수 Js로 프레임워크 만들어보기 Js에 대한 이해도를 올리기 위해 직접 간단한 리액트와 같은 프레임워크를 만들어보는 작업을 해보면 어떨까 생각했습니다. 특히 자바스크립트에서 어려운 개념 (클로저, 클래스) 등을 실제로 사용하면서 이해도가 높아 질 수 있을 기회가 아닐까 합니다 3. Next js 공부 심화 Next js에 관한 간단한 프로젝트는 진행한 경험이 있지만 이해도가 부족하다 생각하여 추가적인 공부를 계획중입니다. 최근 채용 공고에서 대부분의 회사가 Next js를 사용하는 것을 보아 중요성을 깨닫고있습니다 4. 실제 이용자가 있는 앱 만들어보기 부트캠프 내의 프로젝트다보니 특정 기한이 끝나면 서버가 닫혀서 직접 보여줄 서비스가 없던 것이 아쉬웠습니다. 또 이용자의 진실한 피드백과 이용자가 있는 서비스를 만들다보면 더 열정이 생겨서 프로젝트를 깊게 수행 하지 않을까라는 생각도 들었습니다. 이용자의 접근성을 높이기 위해 리액트 네이티브를 추가적으로 공부해서 앱형식으로 서비스를 만들어 보려합니다 총 네가지의 목표를 잡고있는데, 우선순위를 어떻게 두면 좋을지가 고민입니다. 이 외에도 선배님들께서 이러한 부분을 신입이 알면 좋겠고, 공부하면 좋겠다 하는 부분이 있으시다면 말씀해주시면 감사하겠습니다! 글이 길어졌는데 읽어주셔서 감사합니다!

Flutter 환경 분리 질문드립니다

Flutter 작업중에 요구에 배포환경 이랑 로컬환경을 분리를 원하십니다. 이유가 로컬에서는 사용하는 코드가 배포에는 사용을 하지않을수도 있어서 분리를 해놓는게 좋다 라고 전달받앗는데 방법이있을까요? 서버같은 경우에는 Kdenugmode 로 구분지어놧는데 이 방법이 구분 방법은 아닌거같아 질문드립니다

프로젝트 메인스택 선정 기준(react vs next.js)

안녕하세요. 입사 7개월차인 주니어 프론트엔드 개발자입니다. 사수가 없는 작은 스타트업에서 일하고 있는데, 이번에 새로운 프로젝트가 들어가면서 메인스택을 어떻게 해야하는지 고민이 됩니다. 1. 채팅 기능이 메인 2. 장기적으로 추가 기능 계속 들어갈 계획 nextjs가 csr ssr 모두 확장성이 있다는 생각이 들어서 reactjs 혹은 nextjs로 스택을 분리해서 기술스택을 선정한다는게 의미가 없어보이는데, 그러면 매번 프로젝트 할 때마다 nextjs면 만사해결! 이라는 느낌이 들어서요. 다른 분들은 메인스택을 어떻게 선정하시나요?

react에서 복잡한 상태를 관리할때.. 한번에 관리? 분리해서 관리? (jotai, recoil, useState)

안녕하세요 react를 이용해서 복잡한 작성 페이지를 만들고있습니다. 아래의 타입은 예시입니다. type payload = { name: string; message: string; type: string; url: { pc: string; mobile: string; }; contents: { images: { url: string; name: string; }[]; buttons: { name: string; url: string; }[]; }; conditions: { ... }, .... }; 위처럼 복잡한 데이터를 서버로 보내줘야해서 데이터를 관리해야하는데 현재는 페이지내에 구조가 복잡하고 컴포넌트도 매우많아 props drilling이 너무 심해질거같아서 recoil, jotai와 같은 상태관리 라이브러리를 이용해서 작업을 진행하고있습니다. 이러한 상황에서 관리하는 데이터를 한객체에 모아서 관리하는게 좋은지 아니면 const nameAtom = atom(''); const messageAtom = atom(''); const typeAtom = atom(''); const urlAtom = atom({ pc: '', mobile: ''}); .... 처럼 일일히 쪼개서 관리하는게 맞는 방향인지 모르겠어서 질문드립니다 ! (사수가없어서 물어볼곳이없어요...) 현재는 아래와같이 쪼개서 작업한뒤 submit시에 합쳐주는 방식으로 구현해놓았는데 atom 갯수가 20개 정도 되버리니까 너무 복잡해보여서 이게맞나... 싶어서 질문드리게되었습니다.

비지니스로직 분리 질문드려요!

사이드 프로젝트를 완료했고 비지니스로직을 분리하고 싶습니다 hooks라는 폴더를 만들어 action과 api로 나눠 action에는 파이어베이스를 사용하기에 여러가지 행동적인 함수 ( 좋아요 기능, 글쓰기 기능, 조회수 등등) Api에는 탄스택쿼리를 사용하기에 해당되는 쿼리 로직들을 나눌려고 합니다. 훅을 사용하는것처럼 하나의 파일에 하나의 로직을 담아야하나요? 아니면 비슷한것끼리 파일에 넣고 export로 여러개를 두어야하나요? 제 스타일대로 하면 될꺼 같지만 현업에서는 어떤식으로 비지니스 로직을 분리하고 관리하는지 궁금해요 TMI. 로그인 페이지 하나 적용해봤는데 코드가 완전 깔끔하고 이컴포넌트에서 무엇을 하는지 딱 보여서 좋네요!!

리액트에서 어떤 걸 전역상태로 관리해야 하고, 어떤 걸 하지 말아야 할까요?

단순히 props drilling이 너무 과도해지거나 상태를 공유하기 힘든 상황일 때 협의를 통해서 사용하면 될지, 아니면 의미를 생각해서 전반적으로 전역으로 관리되어야 할 필요가 있는 데이터를 전역 상태로 관리해야 할까요? 이번에 공부 용으로 사이드 프로젝트를 진행하면서 자식 컴포넌트의 상태를 부모,조상으로 전달해줘야 하는 복잡한 컴포넌트가 하나 만들어지게 되었습니다.. (하나의 필드 안에 검색, 필터,select 등등이 있고 이를 동적으로 생성할 수 있는...) 상태를 공유할 수 있는 다양한 패턴을 통해서 해결이 가능하지만, 구현의 복잡도가 훨씬 높아진다는 생각을 했는데 이럴 때도 전역 상태를 사용해도 괜찮을까요? 사실 전역 상태로까지 관리할 데이터인가?에 대해서는 아니라고 생각하지만 사실 전역 상태라는 것이 구현의 복잡도를 줄여준다는 측면에서 만들어 진 것이라고 생각해서 내가 불편하면 사용하는게 맞지 않나? 라는 생각이 드네요 아니면 아예 구현 부분에서 잘못 되었던 걸까요? 컴포넌트 분리에만 초점을 맞추다 보니 이 점을 많이 신경쓰지 못한 것 같습니다..

여러 이미지 파일을 저장하는 DB 구조에 대해서

오답 노트에서 한 문제에 대한 풀이를 쓸 때 여러 개의 사진을 추가하는 기능을 개발 중인데, 여기서 1. 오답노트와 사진 테이블을 분리해서 사진 테이블에 오답노트 ID(FK)를 줄지 아니면 2. 오답노트 테이블에서 사진만 배열 형식으로 저장할지 고민 중입니다. 여러 사진 파일을 어떻게 데이터베이스에 저장하는 것이 가장 안전하고 효율적일까요? 참고로 이미지 수 제한은 없습니다!

개발 속도가 너무 더딥니다

스프링부트로 백엔드 서버를 개발 중인 대학생입니다. 맨날 소스파일 한 두개 쓰는 장난 코드만 적다가 제대로 프로젝트 만들어보는 건 이번이 처음이에요. 코드 자체는 굉장히 간단한데 클래스 구조를 설계하는 과정에서 시간이 너무 많이 지체되는 것 같아서 고민입니다. 여기서는 인터페이스를 쓰는게 좋지 않을까, 얘는 상속 쓰면 겹치는 코드를 줄일 수 있을 거 같기는 한데 구조가 복잡해보여서 오히려 프로젝트가 더 복잡해지는 건 아닐까, 이 기능은 어떤 서비스 객체에 넣는게 더 자연스러울까, 어디에도 넣기가 부자연스러운데 차라리 서비스 객체를 분리할까 등등 만들면서 코드 짜는 시간보다 클래스 간의 구조를 짜는데 시간이 더 많이 걸립니다. 주변에 동기들 보면 금방금방 코드 짜고 포트폴리오 완성하는 것 같은데 저는 아무리 시간을 쏟아도 성과가 빠르게 나오지 않아서 걱정입니다. 최근에는 인터넷에 잘 만든 코드를 먼저 검색해본 후에 구조를 따라 하는 식으로 공부하고 있는데, 코드를 찾아보고 왜 저 구조를 쓴 건지 이해하는데 또 시간이 소모됩니다. 계속 이렇게 진행하는게 맞을까요? 너무 초조해요...

서버 SSL 적용 시 도메인

안녕하세요. 현재 AWS EC2에서 amazon linux로 인스턴스를 생성하고 spring boot, java 프로젝트를 배포했습니다. Https로 전환하기 위해서 ssl을 적용하려고 하는데 도메인이 필요하다고 하더라구요. 이 도메인을 사용자가 볼 일이 있을까요? 아니라면 서비스 이름과는 상관없이 가격이 가장 저렴한 도메인을 구매하고 싶어서요! 참고로 프론트엔드는 react이고 백엔드와는 깃허브 프로젝트가 분리되어 있으며 깃허브 페이지로 배포했습니다. 해보신 분 조언 부탁드립니다!