그만큼 "0부터 배송까지" 신규 개발자를 위한 프레임워크
\
:::팁 이 기사에는 더 나은 학습을 위해 시각적으로 보기 좋은 ASCII 아트워크가 많이 포함되어 있으므로 이 기사를 가장 잘 볼 수 있도록 노트북/데스크탑의 웹 브라우저를 사용하십시오. 감사합니다.
:::
소개
소프트웨어 개발은 필수적입니다. 모든 것이 코드에서 실행되며 프로토타입을 구축하는 것은 필수 단계입니다. 어떤 면에서 소프트웨어는 프로그래머의 마음이 물리적으로 표현된 것입니다.
개발을 시작하는 것은 꽤 어렵습니다. 코딩을 잘하려면 경험이 필요하고, 경험을 얻으려면 코딩을 잘해야 합니다. 바람직하지 않은 Catch-22입니다.
\
Breaking the Catch-22 with Framework
================================================
Skill
Level
^
| *Framework-Guided Path*
| /
| /
| / <-- Accelerated Growth
| /
|/_____ *Traditional Path*
+-------------------------> Time
Key: Framework shortcuts the
experience-to-skill gap
\
다이어그램 1: 함정 깨기
그러나 다음은 빠른 개발에 도움이 될 수 있는 프레임워크를 제공하고 싶습니다. 제품 전략과 아이디어 부분은 따로 기사를 작성할 가치가 있으므로 건너뛰겠습니다.
\
뼈대
더 이상 고민하지 않고 프레임워크는 다음과 같습니다.
1. 기술 스택을 결정합니다. 프런트엔드에는 무엇이 있고, 백엔드에는 무엇이 있으며, 어떤 데이터베이스, 어떤 종류의 API가 있습니까? 그런 다음 도구를 결정하십시오.
결정하는 동안 다음을 고려하십시오.
-
a) 동질성 및 호환성: 소프트웨어는 구축 및 유지 관리가 쉬워야 합니다. 원하는 최대 기능을 얻고 스택의 다양한 레이어를 지원하는 데 사용할 수 있는 범용 언어를 선택하세요. 디자인의 레이어는 서로 다르지만 이러한 구성 요소가 서로 통신하려면 지연 시간이 짧은 방법이 있어야 합니다.
-
예: JavaScript는 React 및 Angular와 같은 프레임워크의 프런트엔드 언어입니다. Node.js 및 Express가 포함된 백엔드에서도 사용할 수 있습니다. 이는 API(예: GraphQL) 및 데이터베이스(예: JSON과 유사한 구조를 사용하는 MongoDB)에서 사용되는 JSON과 같은 데이터 형식의 기초입니다. JavaScript App Store와 유사한 npm을 활용하면 프로젝트에 수천 개의 라이브러리를 설치할 수 있습니다.
\
-
b) 확장성: 개발하려는 것은 확장 가능해야 합니다. 이는 매우 중요합니다. 최고의 다국적 기업(MNC)에서 사용하는 프레임워크를 선택하거나 MNC에서 개발한 프레임워크를 선택하세요.
-
예를 들어, React와 GraphQL은 Facebook에서 만들었고 내부적으로 사용하므로 확장 가능하다는 것을 알 수 있습니다. MongoDB 웹사이트에서는 Google을 비롯한 여러 회사가 MongoDB의 파트너 중 하나임을 알 수 있으므로 MongoDB의 확장성이 뛰어납니다. 도구의 GitHub 저장소 및 커뮤니티 지원을 살펴볼 수도 있습니다. 많을수록 좋습니다. 마지막으로 주요 클라우드 제공업체가 개발 스택을 지원하는지 여부도 확인할 수 있습니다. 이는 초기 개발 후 확장하려는 경우 또는 개발 중인 소프트웨어의 빠른 프로토타입화에 도움이 필요한 경우에 도움이 되기 때문입니다.
\
Measuring Community Support
=======================================
[Technology/Framework]
|
+--------+--------+--------+
| | | |
v v v v
GitHub Stack npm Reddit/
Stars Overflow Downloads Discord
| | | |
v v v v
>1K+ >1K >100+/ Active
Qs week Community
| | | |
+--------+--------+--------+
|
v
[Strong Ecosystem ✓]
다이어그램 2: 커뮤니티 지원 측정
\
Homogeneous vs Heterogeneous Stack
==============================================
HOMOGENEOUS (Good):
JS → JS → JS → JS
✓ Easy to maintain
✓ Low context switching
✓ Unified tooling
HETEROGENEOUS (Complex):
Python → Java → PHP → Ruby
✗ Multiple paradigms
✗ Different toolchains
✗ Team expertise split
다이어그램 3: 동종 스택과 이기종 스택
\
Scalability Validation Checklist
============================================
Technology Choice: [React]
☑ Used by MNCs?
→ Facebook, Netflix, Airbnb ✓
☑ Large Community?
→ 240K+ GitHub stars ✓
☑ AWS Support?
→ AWS Amplify supports React ✓
☑ Active Development?
→ Regular updates ✓
Result: SCALABLE ✓✓✓
다이어그램 4: 확장성 검증 체크리스트(예: React, AWS)
\
AWS Service Support
================================
Your Stack AWS Service
────────── ───────────
React/Angular → CloudFront
| Amplify
| S3 Hosting
v
Node.js/API → Lambda
| Elastic Beanstalk
| EC2
v
MongoDB → DocumentDB
|
v
[Fully Supported!]
If AWS supports it,
it's production-ready!
다이어그램 5: 클라우드 서비스 지원(예: AWS)
\
API Architecture Choice
====================================
REST API:
GET /users/1 → Full User Object
GET /posts/1 → Full Post Object
(Multiple Requests, Over-fetching)
GraphQL:
query {
user(id: 1) {
name
posts { title }
}
}
(Single Request, Exact Data)
┌──────────────────────┐
│ Facebook uses │
│ GraphQL internally │
│ = Proven at Scale │
└──────────────────────┘
다이어그램 6: GraphQL 사례
\
2. 오픈소스를 활용하세요. GitHub. GitLab. 비트버킷. 오픈 소스는 현대 개발자에게 귀중한 리소스입니다. 그것을 사용하십시오. 어떤 아이디어를 생각해냈다면 다른 사람이 이미 그 아이디어를 구현했을 가능성이 높습니다(항상 독창적일 수는 없습니다. 그렇죠?). 코드를 살펴보세요. 그것을 이해하십시오. 그것을 사용하고 개선하십시오. 기한이 있는 곳에 신용을 부여하면 괜찮을 것입니다. 이를 통해 개발 속도를 높이고 프로젝트를 빠르게 부트스트랩하는 데 도움이 됩니다. 절약된 시간을 더 나은 기능을 생각하는 데 사용할 수 있습니다.
\
Standing on Giants' Shoulders
=========================================
[Your Innovation]
|
╔═════╧═════╗
║ You ║ <- Your contribution
╠═══════════╣
║ Library A ║ <- Open source tools
╠═══════════╣
║ Library B ║ <- Previous work
╠═══════════╣
║ Library C ║ <- Community effort
╠═══════════╣
║ Core Lang ║ <- Foundation
╚═══════════╝
Don't reinvent the wheel!
Build on existing solutions.
다이어그램 7: 오픈 소스 기반 구축
\
Time Investment Comparison
======================================
Build From Scratch:
├─ Research: 40 hours
├─ Architecture: 30 hours
├─ Implementation: 120 hours
├─ Testing: 40 hours
├─ Debugging: 50 hours
└─ TOTAL: 280 hours (7 weeks)
Using Open Source:
├─ Search: 2 hours
├─ Understand: 8 hours
├─ Integrate: 6 hours
├─ Customize: 10 hours
└─ TOTAL: 26 hours (3 days)
SAVINGS: 254 hours (6+ weeks!)
↓
[Use for Features]
다이어그램 8: 절약된 시간은 얻은 시간입니다(예제 시나리오).
\
Common Open Source Licenses
=======================================
MIT License
├─ ✓ Commercial use
├─ ✓ Modification
├─ ✓ Distribution
└─ ✓ Private use
[Most Permissive]
Apache 2.0
├─ ✓ Patent protection
├─ ✓ Commercial use
└─ ! State changes
GPL v3
├─ ✓ Strong copyleft
├─ ! Must open source
└─ ! Derivative works
[Most Restrictive]
Always check before using!
다이어그램 9: 공통 오픈 소스 라이선스
\
Repository Quality Checklist
=========================================
╭───────────────────────────────────────╮
│ Evaluating: [repository-name] │
├───────────────────────────────────────┤
│ [ ] README with clear instructions │
│ [ ] License file present │
│ [ ] Active maintenance (commits) │
│ [ ] Issues being addressed │
│ [ ] Good test coverage │
│ [ ] Documentation/Wiki │
│ [ ] Examples provided │
│ [ ] High stars-to-forks ratio │
│ [ ] Contributors > 3 │
│ [ ] Release/version tags │
├───────────────────────────────────────┤
│ 7+ checked = Safe to use! │
╰───────────────────────────────────────╯
다이어그램 10: 리포지토리 품질 체크리스트
\
Smart Development Strategy
===============================================
[ Your Idea ]
|
v
< Is it novel? >
/ \
[ Yes ] [ No ]
| |
| v
| < Someone built it? >
| |
| [ Yes! ]
| |
| v
| [ Use their work ]
| [ + Attribution ]
| |
+----------+-----------+
|
v
[ Add YOUR unique value ]
├─ Your UI/UX
├─ Your features
├─ Your integration
└─ Your innovation
|
v
[ Ship Product Faster ]
Originality ≠ Reinventing
Be original where it matters!
도표 11: 스마트 개발 전략
\
3. 적절한 코딩 환경을 선택하세요. 프로그래밍을 위해 항상 Mac이나 Linux가 필요한 것은 아닙니다. Windows에도 좋은 옵션이 있습니다. VS Code, Sublime Text 등과 같은 좋은 코드 편집기를 선택할 수 있습니다. 코드를 백업하려면 GitHub 저장소를 만드세요. 당신이 무엇을 하고 있는지 다른 사람이 알기를 원하지 않으면 개인 저장소를 만들 수 있습니다. GitHub Desktop과 같은 동기화 애플리케이션을 사용하면 로컬 컴퓨터에서 작업하고 코드를 GitHub에 원활하게 푸시할 수 있습니다.
\
The Complete Coding Environment
============================================
╔════════════════════════════════════════╗
║ YOUR DEVELOPMENT SETUP ║
╠════════════════════════════════════════╣
║ LAYER 1: Operating System ║
║ ┌──────────────────────────────────┐ ║
║ │ Windows / macOS / Linux │ ║
║ └──────────────────────────────────┘ ║
╠════════════════════════════════════════╣
║ LAYER 2: Code Editor ║
║ ┌──────────────────────────────────┐ ║
║ │ VS Code + Extensions │ ║
║ │ • Prettier, ESLint │ ║
║ │ • GitLens, Live Server │ ║
║ └──────────────────────────────────┘ ║
╠════════════════════════════════════════╣
║ LAYER 3: Version Control ║
║ ┌──────────────────────────────────┐ ║
║ │ Git + GitHub Desktop │ ║
║ └──────────────────────────────────┘ ║
╠════════════════════════════════════════╣
║ LAYER 4: Cloud Backup ║
║ ┌──────────────────────────────────┐ ║
║ │ GitHub Repository │ ║
║ │ (Public or Private) │ ║
║ └──────────────────────────────────┘ ║
╠════════════════════════════════════════╣
║ LAYER 5: Language Runtime ║
║ ┌──────────────────────────────────┐ ║
║ │ Node.js, Python, etc. │ ║
║ └──────────────────────────────────┘ ║
╚════════════════════════════════════════╝
| |
v v
[Local Code] [Cloud Backup]
Professional Setup Complete!
다이어그램 12: 환경 설정의 예
\
Command Line vs GitHub Desktop
===========================================
COMMAND LINE: GITHUB DESKTOP:
═══════════════ ═══════════════
$ git init Click "New Repo"
$ git add . Check boxes
$ git commit -m "msg" Type message,
click "Commit"
$ git remote add origin Paste URL,
<url> click "Add"
$ git push origin main Click "Push"
$ git pull Click "Fetch"
$ git log See "History" tab
Learning Curve: Learning Curve:
████████░░ 80% ██░░░░░░░░ 20%
Both work! Choose comfort level.
다이어그램 13: CLI와 UI
\
Managing Repository Privacy
========================================
[New Repository]
|
+------+------+
| |
v v
┌────────┐ ┌────────┐
│ PUBLIC │ │PRIVATE │
└───┬────┘ └───┬────┘
| |
v v
Visible to: Visible to:
• Everyone • You
• Employers • Invited
• Portfolio • Team only
| |
v v
Can switch Can switch
to Private to Public
(anytime) (anytime)
| |
+-----+------+
|
v
Settings > Danger Zone
|
v
"Change visibility"
Start Private → Go Public Later
(Common Strategy)
다이어그램 14: 리포지토리 개인정보 보호 관리
\
4. ‘모른다’는 것은 전혀 문제가 되지 않습니다. 당신은 이것을 할 수 있습니다! 그러나 개별 구성 요소나 프레임워크의 문서를 자세히 조사하려고 하면 하나의 튜토리얼을 완료하는 데 수년이 걸릴 수 있습니다. 대신, 이러한 구성 요소를 통합하는 책이나 비디오 튜토리얼을 선택하십시오. 이는 이러한 모든 기술을 결합한 좋은 프로젝트를 개발하는 데 도움이 됩니다. GitHub에서 제공되는 “Awesome Lists”를 참조하세요. X의 전문가를 팔로우하세요. Reddit 커뮤니티에 참여하세요. 블로그와 샘플 프로젝트 튜토리얼을 읽어보세요. “daily.dev/hackernoon/dev.to/freecodecamp”를 사용하여 기사를 검색하세요. 읽다. 읽다. 개발하다. 읽다. 개발하다. 개발하다. 개발하다.
\
The Documentation Rabbit Hole
=========================================
[Want to Learn React]
|
v
Read React Docs
|
+-------+-------+
| |
v v
Hooks Docs JSX Docs
| |
v v
useState Docs Babel Docs
| |
v v
useEffect Webpack
| |
+-------+-------+
|
v
[6 months later...]
[Still in docs, no project!]
BETTER APPROACH:
[Tutorial Project] → Learn by doing!
그림 15: 문서화 토끼굴
\
Effective Content Discovery
=========================================================
[ Need to Learn XYZ ]
|
v
+---------------------------------------------------------+
| Step 1: Run Parallel Searches |
+----------------+----------------------+-----------------+
| Platform | Action | Refinement |
+----------------+----------------------+-----------------+
| Google | Search keywords | "XYZ tut 2025" |
| daily.dev | Browse feed/tags | Filter by tag |
| Reddit | Find recent posts | Sort by "Top" |
| YouTube | Find recent videos | Sort by views |
+----------------+----------------------+-----------------+
|
v
+---------------------------------------------------------+
| Step 2: Consolidate & Vet Results |
| (Compare 3-5 top links) |
+---------------------------------------------------------+
|
v
+-----------------+---------------+
| |
v v
< Is it recent? > < Is it complete? >
(e.g. 2024+) (Has full examples)
| |
+----------------+----------------+
|
v
[ Start Learning! ]
다이어그램 16: 효과적인 콘텐츠 검색
\
5. 마지막으로, 프로젝트를 어떻게 개선할 수 있을지 지속적으로 생각해 보세요. 어떻게 더 많은 기능을 개발할 수 있나요? 어떤 기능 ~할 수 있다 당신은 개발? 당신의 아이디어를 사람들로부터 전달하고 좋은 피드백을 얻으세요. Product Hunt, a16z, AngelList 등을 보고 좋은 아이디어를 얻으세요. 팟캐스트를 들어보세요. 그러나 결국, 개발하다. 열정적으로 코딩하세요.
\
Multi-Channel Feedback Strategy
===========================================
[Your Application]
|
Collect Feedback From:
|
+-------+-------+-------+-------+
| | | | |
v v v v v
Users Friends Reddit GitHub X/
Issues Twitter
| | | | |
v v v v v
Real Honest Public Bug Quick
world opinion discus- reports reactions
usage sions
| | | | |
v v v v v
What Improve- Feature Tech Viral
works ments requests debt features
| | | | |
+-------+-------+-------+-------+
|
v
[Prioritized Roadmap]
Listen > Ego
도표 17: 다중 채널 피드백 전략
\
Sources of Product Inspiration
==========================================
[Your Project]
|
What features next?
|
+---------+----------+---------+
| | | |
v v v v
┌─────────┐┌──────┐┌─────────┐┌────────┐
│ Product ││ a16z ││AngelList││Podcasts│
│ Hunt ││ Blog ││ ││ │
└────┬────┘└───┬──┘└────┬────┘└───┬────┘
| | | |
v v v v
Trending VC Startup Expert
Products Insights Trends Advice
| | | |
v v v v
User pain Market Business Best
points trends models practices
| | | |
+----+----+----+---+----+----+
|
v
[Feature Ideas List]
[Innovation Backlog]
도표 18: 제품 영감의 원천
\
요약
이 글이 여러분의 프로그래밍 여정에 도움이 되기를 바랍니다. 제 글을 읽어주셔서 감사합니다.
\
질문이 있으시면 언제든지 저에게 이메일을 보내주세요.이메일. 다음을 통해 저에게 연락하실 수도 있습니다.링크드인. 당신은 또한 나를 따라갈 수 있습니다엑스.
내 기사를 읽을 수 있습니다시스템 설계여기.
내 기사를 읽을 수 있습니다 데브옵스 여기.
다른 주제로 글을 쓰고 싶다면 댓글로 알려주세요.
내 링크HackerNoon 프로필.
\
Post Comment