Haminni_

빼빼로데이 특집: 빼빼로 관상 서비스 만들기

Mon, 10 Nov 2025 07:05:16 GMT

"당신의 얼굴은 빼빼로 몇 개 값어치일까요?"

11월 11일, 빼빼로 데이를 맞아 재미있는 것을 만들어보고 싶었습니다. 그래서 탄생한 빼빼로 AI 관상 서비스! 셀카 한 장이면 AI가 당신의 "빼빼로 가치"를 측정해줍니다.

💡 아이디어의 시작

빼빼로 데이 하루 전, 문득 이런 생각이 들었습니다. "바이럴 서비스 만들어보고 싶다" 여러 아이디어를 고민하다가 최종 선택한 건

빼빼로 AI 관상 - 셀카로 빼빼로 몇 개 값어치인지 측정

왜 이걸 선택했냐면:

셀카 찍는 건 재밌음
결과가 황당할수록 공유하고 싶어짐
친구들이랑 비교하고 싶어짐

완벽한 바이럴 공식!

🛠 기술 스택

빠르게 만들기 위해 익숙한 스택으로 구성했습니다.

Gimini API?

프롬프트 엔지니어링이 핵심! _처음엔 그냥** "재미있게 분석해줘"** 했더니 너무 평범한 결과가 나왔어요. _ 여러 번 시도 끝에 찾은 최적의 프롬프트:

당신은 빼빼로 관상가입니다. 
이 사진을 보고 재미있고 황당한 빼빼로 관상을 봐주세요.

다음 JSON 형식으로만 응답하세요:
{
  "peperoCount": 숫자 (100-999 사이),
  "peperoType": "빼빼로 종류",
  "personality": "한 줄 성격 분석 (재미있게)",
  "fortune": "오늘의 빼빼로 운세 (황당하고 웃기게)",
  "tip": "빼빼로 조언 (말도 안 되지만 그럴싸하게)"
}

JSON 형식을 강제해서 파싱 에러를 줄였습니다!

💭 배운 점

1. 바이럴 서비스의 핵심

즉각적인 재미: 복잡한 설명 없이 바로 이해 가능
공유 욕구: 결과가 황당할수록 친구들에게 보여주고 싶음
비교 심리: "나는 몇 개일까?" → "친구는 몇 개일까?"

2. 빠른 실행의 중요성

완벽한 서비스보다 빠르게 출시하는 게 중요합니다.
특히 시즌성 있는 이벤트(빼빼로 데이)는 타이밍이 생명!

3. AI API의 가능성

Claude API만으로도 이렇게 재미있는 서비스를 만들 수 있다는 게 신기했습니다.
프롬프트 엔지니어링의 중요성을 다시 한번 느꼈어요.

결론

"한순간 빛나고 사라져도 괜찮은" 서비스를 만들어봤습니다.

중요한 건 완벽함이 아니라 재미와 타이밍이었어요.

여러분도 다가오는 기념일에 맞춰 재미있는 사이드 프로젝트 만들어보는 건 어떨까요? 🍫

P.S.

실제로 이 서비스가 얼마나 바이럴 될지는 모르겠지만, 만드는 과정 자체가 즐거웠습니다! 11월 11일, 여러분의 얼굴은 빼빼로 몇 개 값어치일까요? 😄

링크

GitHub: how-much-pepero 웹사이트: 사이트 링크

#2 나는 19개의 프로젝트를 포기한 사람입니다.

Mon, 03 Nov 2025 04:39:36 GMT

01. 들어가며

1화에선 병원 침대에서 떠올린 아이디어에 대해 이야기 했습니다. 이제 실제로 만들어야 합니다.

하지만 문제가 있습니다.

전 19개의 프로젝트를 포기한 사람입니다.

그래서 이번엔 달라?

솔직히 말하면, 확신이 없습니다. 이번에도 하다가 Archived가 될 수 있습니다. 그리고, 그렇게 진행 중이라고 느끼고 있습니다. 제 스프린트 계획서 중 일부입니다. 보시다시피 11월을 넘었는데, 스프린트 계획서는 아직 10/27에 있습니다. 솔직히 막막합니다.

02. 실패 패턴을 다시 보자

분명, 제가 1화에서 놓친 무언가가 있을 것이라고 생각했습니다. 이젠 커밋과 데이터보다, 인간적인 측면에서 분석해보기로 했습니다.

#1. 계획이 없었다.

사실 가장 큰 문제였던 것 같습니다. 어느정도의 계획의 뼈대만 보고, 그것이 계획인 것처럼 행동한 게 문제였죠.

무작정 시작했습니다. 어디로 가는 지도 모르고 달렸습니다.

#2. 스코프가 너무 컸다.

Phase 1: 기본 기능
Phase 2: 고급 기능
Phase 3: AI 통합
Phase 4: 모바일 앱
Phase 5: 글로벌 진출
...
Phase 100: ???

끝이 보이지 않았습니다. "완성"의 기준이 없었습니다.

#3. 초기 세팅이 너무 오래 걸렸다.

초기 세팅, DB 설계, 디자인 ... 시작에서 모든 힘을 다 쓰니 의지가 약해지는 건 당연하다고 생각했습니다.

03. 이번엔 다르게

이 패턴을 보고 역이용하기로 했습니다.

계획이 없었다 → 스프린트 계획서 작성
스코프가 너무 컸다 → 일단 MVP부터
초기 세팅이 너무 오래 걸렸다. → 보일러 플레이트 사용

04. 게다가

이번엔 친구와 함께 하기로 했습니다.

이젠 3인 개발 그 이상으로 생산력을 높이기로 했습니다.

전략 #2: 스코프를 칼같이 자른다

"나중에" 리스트 만들기

Phase 1 (MVP)
- [x] 프로젝트 등록
- [ ] 목록 조회
- [ ] 부활 신청

Phase 2 (나중에)
- [ ] 대댓글
- [ ] DM 기능
- [ ] 모바일 앱
- [ ] AI 추천

Phase 1만 봅니다. Phase 2는 성공한 후에 생각합니다.

전략 #3: 매일 기록한다

일일 개발 일지 (3분)

# 2025-10-20

## 오늘 한 것
- Supabase 프로젝트 생성
- Next.js 초기화
- GitHub 레포 만듦

## 막힌 것
- PostGIS 설정 어떻게 하지?
  → 내일 찾아보기

## 내일 할 것
- DB 스키마 작성
- 컬러 팔레트 정하기

하루 3분이면 됩니다. 나중에 회고할 때 귀중한 자료가 됩니다.

전략 #4: 공개적으로 진행한다

Velog 시리즈 (이거) 지금 이 글을 읽는 여러분이 증인입니다. 다음 주에 "3화 언제 나와요?" 댓글 달아주세요. 그게 제게는 동기부여입니다.

전략 #5: 완벽주의를 버린다

Done > Perfect

❌ "디자인 완벽하게 하고 시작" ✅ "일단 돌아가게 만들고 나중에 개선"

❌ "테스트 코드 100% 커버리지" ✅ "핵심 기능만 테스트"

❌ "코드 리뷰 받고 머지" ✅ "일단 머지하고 나중에 리팩토링"

MVP는 예쁠 필요 없습니다. 작동하면 됩니다.

05. 번아웃 방지 전략

규칙 #1: 주말 하루는 쉰다

일요일은 코드 안 봅니다. 산책, 영화, 게임, 친구 만나기. 뭐든 좋습니다. 코드만 아니면.

규칙 #2: 하루 목표는 3개만

1. [ ] 프로젝트 등록 폼 UI
2. [ ] ...
3. [ ] ...

3개 이상 쓰지 않습니다. 다 못 할 게 뻔합니다. 3개 하면 성공입니다.

규칙 #3: 막히면 넘어간다

30분 규칙

    문제 발생
         ↓
    30분 동안 삽질
         ↓
    안 풀림?
         ↓
    "나중에" 리스트로 이동
         ↓
    다른 거 함

1시간 넘게 삽질하지 않습니다. 그건 번아웃 지름길입니다.

규칙 #4: 작은 성공을 축하한다

Supabase 연결 성공! → 커피 한 잔 ☕

첫 프로젝트 등록 성공! → 치킨 한 마리 🍗

MVP 완성! → 하루 쉬기 🎉

보상이 있어야 합니다. 자신에게 칭찬하고, 보상합니다.

06. 기술 스택 선택 이유

Frontend: Next.js 15

왜?

익숙함 (러닝커브 없음)
SSR/SSG (SEO 좋음)
API Routes (백엔드 없이 시작 가능)
Vercel 배포 쉬움

Backend: Supabase

왜?

PostgreSQL (익숙한 SQL)
Auth 내장 (OAuth 쉬움)
Storage 내장 (S3 설정 필요 없음)
Realtime (WebSocket 무료)
무료 티어 관대함

대안 고려했던 것:

Firebase? → NoSQL 싫음
MongoDB? → Supabase가 더 익숙
직접 백엔드? → 시간 없음

AI/분석: FastAPI (나중에)

왜?

Python (데이터 분석 쉬움)
빠름
타입 힌트 (TypeScript처럼)

언제?

Sprint 5 (대시보드 만들 때)

지금은 필요 없음

07. 성공 기준

정량적 목표 (3개월)

프로젝트 등록100개
가입 유저 500명
DAU 50명
부활 신청 10건

정성적 목표

8주 안에 MVP 완성
Product Hunt 런칭
이 시리즈 완주 (최소 10화)
포기하더라도 과정 기록

실패 시나리오

솔직히 말하면, 실패 확률이 더 높습니다.

시나리오 1: Week 4에 번아웃 (40%) → 휴식 후 재시작 or 일정 연장

시나리오 2: 기술적 막힘 (30%) → 스코프 축소 or 대체 기술

시나리오 3: 동기 상실 (20%) → 여러분의 댓글이 필요합니다 🙏

시나리오 4: 예상치 못한 일 (10%) → 그럼 그때 가서 생각

08. 그래도 시도하는 이유

이번에 실패해도 괜찮습니다. 왜냐하면:

과정이 기록됨

Velog 시리즈 남음 배운 것 남음

다음번에 더 잘할 수 있음

실패 패턴 알게 됨 어디서 막히는지 알게 됨

이 자체가 콘텐츠

성공해도 좋고 실패해도 배움

메타적 완성도

코드묘지가 실패하면? 코드묘지에 등록하면 됨 🪦

09. 여러분께 부탁

이 시리즈를 계속 쓸 수 있도록 도와주세요.

방법 1: 댓글

"기대됩니다!" "응원합니다!" "다음 화 언제 나와요?"

이게 제게는 최고의 동기부여입니다.

방법 2: 질문

"이 부분 어떻게 하실 건가요?" "이거 대신 저거 쓰는 건 어때요?"

질문이 있으면 답하고 싶어집니다.

방법 3: 공유

트위터, 페이스북, 카톡 "이거 재미있네" 한 줄이면 됩니다

더 많은 사람이 보면 포기하기 어렵습니다.

10. 마치며

나는 19개의 프로젝트를 포기한 사람입니다.

하지만

이번엔 계획이 있습니다. 이번엔 여러분이 지켜보고 계십니다. 이번엔 실패해도 기록이 남습니다. 성공했든, 실패했든, 무언가는 남아있을 겁니다.

P.S. 이미 Sprint 1입니다

#1 병원 침대에서 떠올린 아이디어 — 실패한 프로젝트를 위한 무덤

Mon, 20 Oct 2025 04:47:57 GMT

01. 프롤로그

2025년 10월 19일 새벽 3시.

병원 침대에 누워 천장을 바라보고 있었습니다. 옆 침대에서 들려오는 코 고는 소리, 복도를 지나가는 간호사의 발소리. 잠은 안 오고, 폰만 만지작거리고 있었죠.

그때, 유튜브 알고리즘이 던져준 한 영상.

초콜릿 사업으로 초대박이 난 허쉬, 그가 성공한 이유는 바로 이것 때문이다 [브랜드 스토리]

별 기대 없이 클릭했습니다.

그리고 뭔가 이상했습니다.

영상 속 밀던 허쉬는 아래 사업을 실패했습니다.

캔디 가게 (중앙 펜실베이니아) 카라멜 가게 (시카고) 카라멜 가게 (뉴욕)

그런데 그는 부끄러워하지 않았습니다. 오히려 담담했고, 자랑스러웠습니다.

“그 실패가 없었다면 지금의 성공도 없었을 겁니다.”

영상이 끝나고, 자동재생이 넘어가기 전에 저는 생각했습니다.

“왜 실패를 기록하는 서비스는 없을까?”

🧱 02. 내 GitHub에는 무덤이 가득했다

노트북을 켜고 GitHub를 열었습니다.

Archived. 그 단어 하나로 덮여버린 프로젝트들.

🪦 프로젝트 #1 — 부동산 데일리 (2025.10.)

부동산 데일리

부동산 뉴스를 매일 요약해주는 서비스

Tech Stack

Next.js

Supabase

Status

개발 중단

“개발 중단.” 그게 전부였습니다.

왜 중단했는지, 뭘 배웠는지 — 아무 흔적도 없었습니다.

🎬 프로젝트 #2 — 연애 스타일 영화 매칭 (2025.05.)

거의 다 만들었습니다. 진짜 거의.

영화 DB 연동 ✔️ 추천 알고리즘 ✔️ 백엔드 개발 ✔️ ❌ 런칭... 못함

“나중에 마저 하지 뭐.”

그 ‘나중’은 오지 않았습니다. 이젠 코드도 낯설고, 의도도 잊었습니다.

그러곤 노션에 들어갔습니다.

완료율 16% 미만.

결과 통계

총 프로젝트 수: 19개
완성: 3개
평균 생존 기간: 3주
최단 생존: 1일

🔍 03. 패턴이 보였다

💥 패턴 #1 — 시작은 언제나 뜨겁다

Commit history

Day 1: ███████████████ (20 commits)
Day 2: █████████ (12 commits)
Week 3: ██ (2 commits)
Week 5~∞: (0 commits)

처음엔 밤을 새며 달립니다. “이번엔 진짜 된다!” 하지만 2주쯤 지나면, 식습니다.

🙈 패턴 #2 — 혼자 시작했고, 혼자 포기했다

10개 중 10개, 혼자만 알고 있던 프로젝트였습니다.

“말하면, 나중에 그거 어떻게 됐냐고 물어볼까 봐...” 그래서 조용히 시작하고, 조용히 끝냈습니다.

⏰ 패턴 #3 — 포기 이유는 항상 “우선순위”

“시험공부 해야지.” “과제 해야지.” “피곤해.”

결국, 프로젝트는 언제나 우선순위에서 꼴찌.

💀 패턴 #4 — 흔적을 남기지 않았다

“부끄럽다. 빨리 잊자.” 그래서—

블로그 ❌
README 업데이트 ❌
회고 ❌
그냥 Archive

그렇게 묻었습니다. 마치 존재하지 않았던 것처럼.

🤔 04. “실패는 자산이다.” 그런데 나는?

10개 프로젝트를 실패했는데, 무엇이 남았을까요?

아무것도.

문서 ❌
회고 ❌
배운 점 ❌
교훈 ❌

“실패는 자산”이라는데, 나는 그 자산을 전부 버렸습니다.

그 순간 깨달았습니다.

실패가 자산이 되려면, ‘기록’해야 한다.

🌍 05. 세상은 성공 이야기뿐이었다

Product hunt - Best of Today

모두 성공 이야기.

🧠 GitHub

Trending repositories on Github Today

Perplexity AI Search - Comet

1억개 이상의 죽은 프로젝트. 그런데 왜 죽었는지는 아무도 모릅니다.

✍️ 개발 블로그

“30일 만에 완성한 서비스!” “런칭하고 n일 만에 n만 명이 쓴 프로젝트!”

실패 회고는... 찾기 어려웠습니다.

그래서 생각했습니다.

“실패한 프로젝트를 위한 Product Hunt가 필요하다.” “죽은 코드를 위한 GitHub이 필요하다.” “실패를 기록하고 공유하는 문화가 필요하다.”

⚰️ 06. 코드묘지의 탄생

새벽 6시. Notion을 켰습니다.

코드묘지 (CodeGrave)

"실패도 포트폴리오다"

✅ 프로젝트 사망 진단서 ✅ 입양 시스템 (좋은 아이디어 부활) ✅ 실패 패턴 분석 ✅ 익명 모드

타이핑이 멈추지 않았습니다. 1시간 만에 기획서 15섹션 완성.

이번엔 달랐습니다.

“이건 된다!”가 아니라 “이건 필요하다.”

🧩 07. 코드묘지는 ‘우리’의 이야기다

이전 프로젝트는 “이거 만들면 나한테 좋겠다.” / "이거 만들면 재밌겠다" 였지만,

이번엔 “이거 우리한테 필요하다.” 였습니다.

실패를 숨기고 있는 우리 모두의 이야기.

🪦 08. 이번엔 달라요

#1 기록한다

Velog에 개발 일지 작성

#2 공개한다

숨기지 않는다. 모두에게 공유.

#3 완성이 목표가 아니다

목표는 ‘기록하는 문화’ 만들기

#4 혼자가 아니다

AI 협업 + 커뮤니티 피드백 + 공개 진행

🧱 09. 나의 20번째 프로젝트

19개를 포기한 제가 20번째를 시작합니다. 하지만 이번엔 이렇게 말할 수 있습니다.

“이번엔 포기해도 괜찮아.” 포기 자체가 콘텐츠니까. 포기 자체가 교훈이니까.

💭 10. 여러분의 무덤은 몇 개인가요?

Archived 레포 몇 개인가요?
가장 아쉬운 프로젝트는?
그 실패에서 배운 건?

💬 댓글로 함께 이야기해요.

실패는 부끄러운 게 아닙니다. 기록하지 않는 게 부끄러운 겁니다.

📎 관련 링크

🪦 코드묘지(개발 중): 404-grave.vercel.app
💻 GitHub: Hxmxx - 404 Grave
📧 이메일: haminni.dev@gmail.com

🪶 P.S.

이 글을 쓰며 문득 생각했습니다.

“이것도 3화까지만 쓰고 포기하는 거 아니야?”

그럴 수도 있죠. 그럼 제목을 이렇게 바꾸면 됩니다.

[코드묘지 #마지막] 코드묘지도 결국 실패했다 — 그리고 배운 것들

고2의 실리콘밸리에서의 도전과 성장, 그리고 수상까지

Sun, 08 Jun 2025 02:37:59 GMT

✈️ 실리콘밸리에서의 일주일

2025년 5월, 고등학교 2학년인 나에게 미국 실리콘밸리에 갈 수 있는 특별한 기회가 주어졌다. 산 호세 주립 대학교 (SJSU)에서 진행하는 연수 프로그램에 참가하게 되었다. 이번 연수는 단순한 견학이 아니라, 글로벌 무대에서 주어진 주제를 발표하고 피드백을 받으며, 직접 뛰어드는 실전형 프로젝트 중심의 프로그램이었다. 실리콘밸리에 위치한 다양한 글로벌 기업 탐방은 물론, 컴퓨터 역사 박물관, 구글, 애플 파크, 스탠포드 대학교 등 꿈에만 그리던 공간들은 직접 경험하는 뜻깊은 시간이었다. 하지만 그중 가장 기억에 남는 순간은, 아무래도 SJSU에서의 팀 프로젝트와 발표, 그리고 PITCH MASTERY AWARD 수상이었다.

💡 팀 프로젝트: 아이디어를 현실로, 발표를 무기로

프로젝트 주제: 감정 기반 노래 & 플레이리스트 추천 앱 우리는 5인으로 구성된 팀으로 나뉘어, 약 2주동안 구체화부터 최종 발표까지 모든 과정을 직접 준비해야 했다. 제한된 시간 속에서 아이디어를 구체화하고, 역할을 분담해 발표 자료를 만들고, 영어로 발표까지 해야 했기 때문에 부담도 컸다.

내 역할: PM + 디자인 + 프론트엔드

나는 아이디어 기획 및 발표 구조를 구성하는 역할과 함께, 디자인 및 프론트엔드 화면 와이어프레임 구상도 맡았다. 주제는 지정되어 있었기 때문에 발표 자료의 퀄리티와 분위기에 집중했다. 발표 자료의 이미있는 단계 구성을 위해 발표 자료를 만들기 전, 발표 시간을 고려하여 피치 덱을 매우 열심히 찾아봤고, 이를 통해 의미있는 발표 자료를 구성할 수 있었다. PPT에 문제 제기, 솔루션, 시장 분석, 데모, 기술 아키텍쳐, 향후 계획 및 팀 소개와 QNA를 끝으로 자료를 계획했다. 이를 시각적으로 녹여내기 위해 Figma와 프레젠테이션 도구를 적극 활용했다.

📣 영어로 발표하기, 그리고 멘토링

가장 큰 도전은 역시 영어로 발표하는 것이었다. 미국 대학 교수님과 실리콘밸리 멘토 분들 앞에서, 우리 팀이 준비한 아이디어를 짧지 않은 시간동안 정확히 전달해야 했기 때문이었다. 하지만 몇 번의 리허설을 거치며 점점 자신감을 얻었고, 발표 스크립트도 제 손으로 직접 정리하며 연습했다. 멘토님들께 받은 피드백도 큰 도움이 됐다. 단순한 영어 표현이 아니라, “왜 이 아이디어가 지금 필요한가?”, “사용자의 경험 흐름이 실제로 작동 가능한가?”, “투자자 앞이라면 무엇을 더 강조할 것인가?” 같은 질문들 덕분에 발표 내용이 훨씬 단단해졌다.

🏆 PITCH MASTERY AWARD 수상!

그렇게 완성된 발표는 전 참가 팀 앞에서 최종적으로 진행되었고, 놀랍게도 우리 팀이 Pitch Mastery Award를 수상하게 되었다. 이 상은 가장 설득력있고 매력적인 발표를 한 팀에게 수여되는 상이다.

🧠 얻은 것들

커뮤니케이션 능력: 영어 발표에 대한 두려움을 넘어서, 오히려 재미있게 느낄 수 있었다.
아이디어를 설득하는 힘: 그냥 좋은 생각이 아니라, “왜 지금 이 아이디어여야 하는가?“를 말할 수 있게 되었다.
로벌 협업 감각: 타국 멘토, 교수님, 친구들과 짧은 시간 안에 소통하고 협업했던 경험이 큰 자산이 되었다.
진짜 발표란 무엇인가? 발표란 단지 말하는 것이 아니라 공감시키는 기술이라는 것을 배웠다.
✍️ 마무리하며
나는 아직 고등학생이고, 여전히 배우는 과정에 있지만, 이번 실리콘밸리 경험은 내가 어디로 가야 할지를 조금 더 분명하게 보여준 시간이었다.

기획자, 디자이너, 발표자… 어떤 역할이든, 내가 만든 것에 확신을 갖고 사람들 앞에서 이야기할 수 있는 사람이 되고 싶다.

그리고 이 경험을 통해, 단지 실력을 쌓는 것이 아니라 ‘사람들과 연결되는 기술’을 더 배우고 싶어졌다.

RAM의 특징과 종류

Mon, 02 Dec 2024 06:58:56 GMT

RAM(Random Access Memory)은 컴퓨터 시스템에서 중요한 역할을 하는 휘발성 메모리이다.

이는 프로세서가 데이터를 빠르게 읽고 쓰는 데 사용되며, 시스템 성능에 직접적인 영향을 미친다. 이번 글에서는 RAM의 특징과 종류를 자세히 알아볼 것이다.

RAM의 특징

휘발성 메모리
RAM은 휘발성 메모리로, 전원이 꺼지면 저장된 데이터가 모두 사라진다. 이는 장기적인 데이터 저장이 아닌 일시적인 데이터 처리를 위해 설계된 메모리라는 점에서 중요하다.

빠른 데이터 접근 속도
RAM은 HDD나 SSD 같은 저장장치에 비해 매우 빠른 속도를 제공한다. 이는 프로세서가 실행 중인 프로그램과 데이터를 실시간으로 처리할 수 있도록 돕는다.
랜덤 액세스 (Random Access)
RAM은 데이터를 랜덤하게 접근할 수 있습니다. 즉, 메모리의 어떤 위치라도 동일한 시간에 접근할 수 있다는 뜻입니다. 이는 순차적으로 데이터를 읽어야 하는 HDD와의 큰 차이점입니다.

데이터 읽기/쓰기
RAM은 데이터를 읽고 쓰는 속도가 균일하다. 이는 컴퓨터가 여러 프로그램을 동시에 실행하거나 빠르게 작업을 전환하는데 유리하다.

RAM의 주요 종류

RAM은 크게 SRAM과 DRAM으로 나뉜다. 이 두 가지는 설계 방식과 사용 용도에 따라 세부적으로 구분된다.

SRAM (Static RAM)
SRAM은 데이터를 유지하기 위해 전원이 필요한 정적 메모리이다. DRAM보다 속도가 빠르고 전력 소모가 적지만, 제조 비용이 높아 용량이 제한적이다.
특징
빠른 속도 전력 효율이 높음 비싸고 용량이 작음
주요 사용처
CPU의 캐시 메모리 GPU 내부 메모리
DRAM (Dynamic RAM)
DRAM은 데이털르 유지하기 위해 일정 시간마다 재충전(Refresh)이 필요한 동적 메모리이다. SRAM보다 느리고 전력 소모가 크지만, 가격이 저렴하고 용량이 크다.
DRAM의 종류
SDRAM (Synchronous DRAM)* 클럭 신호를 기준으로 동작하며, CPU와 동기화된다. 구형 컴퓨터에서 사용되었다.
DDR (Double Data Rate SDRAM)* 한 클럭 사이클에 두 번 데이터를 전송할 수 있는 DRAM. 현재 사용되는 대부분의 RAM은 DDR 기반이다.
DDR1, DDR2, DDR3, DDR4, DDR5*로 발전하며, 세대가 높아질수록 속도와 대역폭이 증가하고 전력 소모는 감소한다.
GDDR (Graphics DDR)
저전력 설계로, 모바일 기기나 노트북에 적합하다.
LPDDR4, LPDDR5* 등이 사용중이다.

RAM 용량과 성능의 관계

용량
RAM 용량이 크면 동시에 실행할 수 있는 프로그램이 늘어나고 멀티태스킹 성능이 향상된다. 일반적으로 8GB는 보편적 사용에 적합하며, 고사양 작업(게임, 영상 편집 등)에는 16GB 이상이 권장된다.

클럭 속도와 대역폭
클럭 속도(MHz)가 높을수록 데이터 처리 속도가 빨라진다. 하지만 CPU와 메인보드가 지원하는 속도를 초과하면 성능에 제약이 발생한다.
채널 구성
싱글 채널보다 듀얼 채널 구성이 데이터 전송 속도에서 더 유리하다. RAM을 두 개의 슬롯에 장착하여 듀얼 채널로 구성하면 더 나은 성능을 얻을 수 있다.

결론

RAM은 컴퓨터의 일시적인 데이터 저장과 처리 속도를 담당하는 핵심 구성 요소이다. 사용 목적에 따라 적합한 종류와 용량의 RAM을 선택하는 것이 중요하며, RAM 업그레이드는 시스템 성능 향상의 주요 방법 중 하나이다.

React 진짜 제대로 이해하기

Tue, 08 Oct 2024 05:48:06 GMT

들어가며

주니어 개발자인 나에게 "어떻게 하면 리액트에 대해 더 깊게 이해할 수 있을까?"를 고민하던 중 "하나부터 열까지 다 적어보면 되지 않을까?"라는 생각에 시작하게 되었다.

React란 무엇인가?

React는 사용자 인터페이스 구축을 위한 자바스크립트 라이브러리이다. 2013년 페이스북에서 처음 개발되었으며, 현재는 많은 기업에서 사용하고 있다. React의 주요 매력은 효율적인 UI 렌더링과 컴포넌트 기반 개발을 가능하게 하는 것이다. ~~컴포넌트 기반 개발을 하지 않는다면 React의 진가를 못 볼 수도..~~

React의 주요 개념

1. 컴포넌트 기반 구조

React는 UI를 컴포넌트라는 독립적이며 재사용 가능한 작은 단위로 쪼개서 개발하는 방식이다.컴포넌트는 각각의 상태 & 로직을 가지고 있어, 대규모 어플리케이션을 더 효율적이고 직관적으로 관리할 수 있다. 컴포넌트는 함수형 혹은 클래스형으로 정의할 수 있다.

function Component() {
    return Hello, Velog!;
}

[함수형 컴포넌트] : function으로 정의하고, 간단한 UI 요소를 만들 때 자주 사용된다. ~~[클래스형 컴포넌트] : ES6의 클래스 문법을 사용해 정의하며, React 16.8 이후 훅(Hook) 도입으로 함수형 컴포넌트가 더 자주 사용된다.~~

2. JSX (JavaScript XML)

JSX는 자바스크립트 코드 내에 HTML과 비슷한 구문을 사용할 수 있게 해주는 문법이다. React 컴포넌트에서 UI를 정의할 때 사용하고, 실제로는 브라우저가 이해할 수 있는 자바스크립트로 변환된다.

const element = Hello, Velog!
;

JSX는 HTML과 매우 비슷하지만 자바스크립트를 지원하므로, 동적인 데이터를 쉽게 처리할 수 있다.

3. Virtual DOM (가상 DOM)

React는 Virtual DOM이라는 개념을 통해 성능을 최적화한다. ~~브러우저의 실제 DOM에 직접 접근하여 변경하는 것은 비용이 많이 들어서..~~ React는 가상 DOM을 메모리에 두고, 그곳에서 UI 업데이트를 처리한다. 이후 변화된 부분만 실제 DOM에 반영하여 성능을 향상시킨다.

Virtual DOM은 React의 핵심 성능 최적화 전략이다. 실제 DOM 조작을 최소화하여, 화면을 빠르게 갱신할 수 있다.

4. 리액티브(반응형) 프로그래밍

React는 리액티브 프로그래밍 방식으로 작동한다. 이는 상태가 변화하면 그에 따라 UI가 자동으로 다시 렌더링되는 구조다. 사용자가 상호작용하거나 데이터가 업데이트되면, 해당 부분만 다시 그려주어 효율적인 UI 업데이트가 가능하다.

React의 주요 개념들

1. 컴포넌트의 상태 (State)

컴포넌트는 상태를 가질 수 있고, 이 상태는 컴포넌트의 동작과 렌더링 결과를 결정한다. 상태는 동적인 데이터이며, 상태가 변경되면 컴포넌트가 다시 렌더링된다.

import React, { useState } from 'react';

function Counter () {
    const [count, setCount] = useState(0);
    return (
        
             현재 카운트 : {count} 
            
    );
}

useState는 상태를 관리하기 위해 사용되는 훅(Hook)이다. 상태가 업데이트되면, React는 해당 컴포넌트를 다시 렌더링하여 새로운 값을 화면에 보여준다.

2. Props (속성)

Props는 컴포넌트 간에 데이터를 전달하는 방법이다. 부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달할 때 사용되며, Props는 읽기 전용으로, 자식 컴포넌트에서는 수정할 수 없다.

function Welcome(props) {
    return  Hello, {props.name}! ;
}

function App() {
    return ;
}

위 예제는 App 컴포넌트가 Welcome 컴포넌트에 name이라는 Props를 전달하고, Welcome은 이를 이용해 "Hello, Velog!"를 렌더링한다.

3. 렌더링

React 컴포넌트에서는 렌더링이라는 과정을 통해 UI를 그린다. render() 함수 또는 함수형 컴포넌트에서 JSX를 반환하며, React는 이 JSX를 실제 DOM으로 변환해 브라우저에 표시한다.

function Greeting() {
    return Hello, world!;
}

4. useEffect (부수 효과 처리)

useEffect는 컴포넌트가 렌더링될 때 또는 특정 상태가 변경될 때 부수 효과(side Effects)를 처리할 수 있게 도와주는 훅이다. 예를 들어 API 호출, 구독(Subscription), DOM 업데이트와 같은 작업을 수행할 때 사용된다.

import React, { useState, useEffect } from 'react';

function Timer() {
    const [count, setCount] = useState(0);

    useEffect(() => {
        const timer = setInterval(() => {
            setCount(prevCount => prevCount + 1);
        }, 1000);

        return () => clearInterval(timer); // 컴포넌트가 사라질 때 정리 작업
    }, []);

    return  {count}초가 지났습니다. ;
}

위 코드는 타이머를 구현한 예시다. useEffect는 컴포넌트가 처음 렌더링될 때 타이머를 시작하고, 컴포넌트가 사라질 때 타이머를 정리(clean-up)한다.

React의 성능 최적화

1. 메모이제이션

React는 컴포넌트가 자주 렌더링될 때 성능을 최적화하기 위해 메모이제이션을 지원한다. useMemo 와 useCallBack 훅을 사용해 함수나 계산된 값을 메모이제이션할 수 있다.

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

2. Lazy Loading

React는 React.lazy() 와 Suspense를 이용해 지연 로딩을 지원한다. 이는 필요한 시점에만 컴포넌트를 로딩하여 초기 로딩 시간을 줄일 수 있게 한다.

const LazyComponent = React.lazy(() => import('./MyComponent'));

function App() {
    return (
        Loading...}>
            
        
    );
}

3. Code Splitting (코드 분할)

Webpack과 같은 도구를 결합해 코드를 분할하여 페이지 로딩 시간을 단축할 수 있다. React는 React.lazy()를 통해 필요한 컴포넌트만 로드하여 성능을 최적화한다.

React의 확장성

React는 다양한 도구 및 라이브러리와 잘 어우러져 큰 프로젝트에도 확장 가능하다.

1. React Router

페이지 간 라우팅을 관리한다.

2. Redux

전역 상태 관리를 도와주는 라이브러리로, 복잡한 상태 관리를 체계적으로 처리할 수 있다.

3. Styled Components

컴포넌트 스타일링을 위한 CSS-in-JS 라이브러리다.

4. Next.js

서버 사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 지원하는 React 프레임워크로, 성능과 SEO 최적화를 위해 자주 사용됩니다.

따라서

React는 컴포넌트 기반 개발 방식과 Virtual DOM을 통한 성능 최적화로 대규모 애플리케이션 개발에 적합한 라이브러리다. 사용자가 상호작용하거나 상태가 변화할 때 UI를 자동으로 다시 렌더링하여, 동적이고 반응형인 웹 애플리케이션을 쉽게 구축할 수 있다.