2024-09-28

목차

1. 트리 데이터 구조와 탐색 방법
2. Flat 리스트와 트리 변환 기법
3. 드래그앤드랍 UI와 데이터 업데이트 문제
4. NoSQL과 트리 관리 방식
5. GPT 및 생성형 AI에 대한 인식과 활용
6. 개발자의 이직 준비: 기술 스택과 성장 방향
7. React Hook과 API 관리 고민
8. CSS 도구, 스타일 관리 방식에 대한 논의
9. 프로젝트 스타일 가이드와 UI 구현 팁
10. 팀 내 커뮤니케이션과 협업 인사이트

1. 트리 데이터 구조와 탐색 방법 🌳

• 대규모 트리 데이터를 다룰 때 DB엔진은 B트리, B+트리와 같은 고성능 자료구조를 사용.
• 프론트엔드에서는 React-complex-tree 같은 라이브러리 활용 가능.
• 트리의 리프 노드는 보통 '폴더'와 '파일'로 구분하며, 파일에는 고유 식별자(id)가 필요.
• 트리에서는 단순 Map처럼 키로 바로 접근이 어렵기 때문에 부모-자식 관계를 포함한 별도 탐색 로직 필요.
• ID와 parentId를 활용해 각 노드가 자신의 위치를 파악하는 전통적 방법이 흔함.
• children 프로퍼티가 있는 트리(nested 구조)와 같이 필요에 따라 복합구조를 사용할 수 있음.

용어 설명

• B트리, B+트리: 데이터베이스에서 대용량 데이터를 효율적으로 인덱싱하고 탐색하기 위해 사용하는 균형 잡힌 트리 구조.
• 리프노드: 트리에서 자식 노드가 없는 가장 끝단 노드. 보통 실제 데이터가 위치.

2. Flat 리스트와 트리 변환 기법 🔄

• 트리 데이터를 필요에 따라 플랫 리스트(flat list) 형태로 관리함.
• 플랫 리스트는 { id, parentId, name } 식으로 각 아이템이 자신의 부모를 가리킴.
• 필요할 때 재귀 함수를 통해 플랫 리스트 → 트리 구조로 변환(getTreeFromFlatData 같은 알고리즘).
• 이런 방식은 드래그앤드랍 후나 노드 재정렬에 유용함.
• 중간 노드 삭제 시 하위 노드 처리 방법 등 구현 세부사항에 따라 복잡성 증가 가능.

추가 설명

• Flat 리스트는 각 노드가 부모를 가리키는 단순 리스트여서 탐색을 위해서는 변환이 필요.
• 재귀적 변환은 기본적으로 모든 노드를 순회하며 부모-자식 관계에 맞게 트리를 구축.

3. 드래그앤드랍 UI와 데이터 업데이트 문제 🖱️

• UI에서 트리 드래그앤드랍 시 각 노드의 path나 id, parentId 등의 정보가 갱신되어야 함.
• nested 구조를 UI에 표현할 때마다 재계산이 필요해 성능 고려해야 할 때가 많음.
• 중간 노드 삭제나 이동 시 하위 노드들 처리 및 순회가 필수.
• DB와 UI 간 트리 데이터 동기화가 어려운 편임.

4. NoSQL과 트리 관리 방식 🗃️

• NoSQL (예: MongoDB)은 트리 구조를 도큐먼트 내 nested 데이터 구조로 저장.
• children 배열을 가진 트리 노드 방식이 많이 사용됨.
• 그러나 대규모 트리 탐색 및 업데이트에는 복잡성 및 성능 문제 존재.
• 관계형 DB와 달리 고정된 스키마가 없어 설계 시 고려할 요소 다양.

5. GPT 및 생성형 AI에 대한 인식과 활용 🤖

• GPT(대형 언어 모델)는 자연어 생성에 특화되어 문장 표현이 뛰어남.
• 번역이나 문서 작성에 효과적이나, 문법 등 세세한 부분에서 오류가 있을 수 있음.
• 생성형 AI는 만능이 아니고, 검증과 보완이 필수임.
• 실제 개발 현장에서는 아이디어 발굴이나 초기 초안 작성 용도로 유용하게 사용 가능.

6. 개발자의 이직 준비: 기술 스택과 성장 방향 🚀

• B2B 회사에서 신입 개발자는 복잡하게 얽힌 레거시 코드와 낮은 라이브러리 버전 문제가 흔함.
• 단순히 최신 기술을 쓴다는 점만으로는 어필이 어려움.
• 상태관리(RTK 등) 도입 경험은 장점일 수 있으나 설득 가능한 근거와 결과물이 중요.
• 이직 준비 시 회사 내에서 성과를 내는 데 집중하고, 문제 해결 능력과 논리적 근거 기반 개선 사례를 만드는 것이 효과적.
• Typescript 학습은 강력 추천. 프론트엔드 품질 향상과 시장성에 유리함.

7. React Hook과 API 관리 고민 🔄

• API 호출을 훅(useQuery, useBoardQuery 등) 단위로 분리하는 경우가 많음.
• 각 API마다 훅을 만드는 것이 중복이나 관리 문제를 낳을 수 있음.
• 반대로 너무 많은 API를 한 훅에 넣으면 분리가 어렵고 유지보수 어려움.
• 협업 환경에서는 일관된 명세 및 코드 리뷰 프로세스가 가장 중요.
• 훅 사용 자체가 문제라기보다 프로젝트 내에서 어떻게 표준화하느냐가 관건임.

8. CSS 도구, 스타일 관리 방식에 대한 논의 🎨

• CSS module, styled-components, Tailwind 등 다양한 스타일링 도구 존재.
• 퓨어 CSS나 CSS 모듈을 잘 쓰는 것도 강점으로 평가될 수 있음.
• 툴 선택은 학습 난이도와 프로젝트 특성에 맞게 하면 됨.
• 이직 시 특정 스타일링 도구 미사용으로 탈락할 가능성은 낮음.
• 개인 프로젝트에서는 색상, 폰트, 아이콘 등의 핵심 요소 위주로 구성하고, 상세 스타일 가이드에 집착할 필요는 적음.

9. 프로젝트 스타일 가이드와 UI 구현 팁 💡

• 복잡한 스타일 가이드를 만들기보다는 와이어프레임 수준에서 기능 레이아웃을 빠르게 구성.
• 아이콘은 직접 제작하거나 AI 도움 받아 차근차근 늘려가는 전략 추천.
• 회사 브랜드 컬러 간단하게 정의하고 일관되게 사용.
• 지나친 세부 디자인보다는 사용자 경험과 기능 구현에 중점 두는 방법이 효율적.

10. 팀 내 커뮤니케이션과 협업 인사이트 🤝

• 같은 단어를 사용해도 서로 이해하는 바가 달라 소통이 어려울 수 있음.
• 코드 없이 말하거나 상황 설명이 없이 이야기하면 오해 발생 빈도 증가.
• 개발자 간 협업에서 일관성 있는 명세와 문서화 그리고 코드 리뷰가 가장 중요함.
• 채팅방 내 자연스러운 농담과 소소한 대화도 팀 분위기 유지에 도움됨.

면접팁⚡

• 트리 구조를 설명할 때는 flat 리스트와 nested 트리의 차이를 명확히 하여 설명하면 좋음.
• 대규모 데이터 탐색 시 B트리, B+트리 개념을 알고 있으면 인상적.
• 상태관리 도입 시 근거와 성과를 함께 보여주면 설득력 증가.
• 훅과 API 관리에 대해서는 프로젝트 상황에 알맞은 표준화 경험을 강조할 것.
• CSS 도구는 무엇을 썼느냐보다 문제 해결 능력과 유지보수성을 어필하길 추천.

링크🔗

• react-complex-tree: https://www.npmjs.com/package/react-complex-tree
• Flat List to Tree Conversion 개념 및 알고리즘(블로그 참고)
• 타입스크립트 + React 학습 강의:
  https://madiadesigner.cafe24.com/shop2/product/detail.html?product_no=11&item_code=P000000L000A&utm_content=YT3-Q5Uuck3jn7NgVZLo7c5r_x8zyUyAl84knZ7bwNuwjxwYI4ZUWym9U1AHFhuhtyxnw8iYZAiOod8Am9zZIw&utm_term=UCxRnfrmJAkRLarzeBJETB5g&utm_medium=product_shelf&utm_source=youtube&yts_source=AZqtsIo2ETWPN1x_PTNYQhy2brl85OLXeCoNRzoFkstEfmcJGR6NX1WeHlXQASUAqHvWxHBj_XIGpPklwWj0bUscv2z0BLZmwU4NUOWPNWTtoq2pxbhuakWzTYYMc56uTbiCQDygOXZzx4menWEJ90E5IgjxaFxHKuPFw9M1fLDlYCHgo8xebny79oc
• React Query + Next.js 패턴(블로그): https://soobing.github.io/react/next-app-router-react-query/
• 타입스크립트 & 서버사이드 JS 논의 참고