안녕하세요! 그로스로그 입니다!😊 🌱
"굳이 이렇게 해야 하나"라는 의문이 납득으로 바뀌는 과정, 그리고 동작은 하는데 설명은 못 하는 코드에 대한 고민입니다.
5기 9회차입니다. 새 기술을 처음 만난 기록 두 편인데, 두 분 다 불편했던 감각을 버리지 않고 끝까지 따라갔어요.
01
⚛️ React + TypeScript를 처음 경험하며 느낀 React의 철학
황대웅 님
Vue를 쓰다가 처음 React와 TypeScript를 만난 기록입니다. 첫인상이 좋지 않았어요 — "왜 이렇게까지 JavaScript 안에 모든 것을 넣으려고 하지?"
그 의문을 그대로 두지 않고 React가 왜 만들어졌는지부터 따라갑니다. 2010년대 초 Facebook이 마주한 문제와 "UI는 현재 State의 결과일 뿐"이라는 아이디어요.
결론은 납득입니다. React를 UI 라이브러리가 아니라 컴포넌트 중심의 애플리케이션 설계 철학으로 정리하며 맺습니다.
낯설다에서 납득한다까지의 거리가 그대로 남아 있는 글입니다.
조금 더 들어가 보면
첫인상이 정직합니다. Vue에 익숙했던 입장에서 React의 JSX가 어색했다고요.
<template>, <script>, <style>로 역할을 분리하는 방식이 자연스럽다. HTML은 HTML답게, JavaScript는 JavaScript답게 작성하는 것이 익숙했기 때문이다.""처음에는 오히려 복잡해 보였고, '굳이 이렇게 해야 할 이유가 있을까?'라는 의문도 들었다."
이 의문을 버리지 않고 왜 그렇게 만들어졌는지를 찾아갑니다.
🏗️ React가 풀려던 문제
2010년대 초 웹은 지금보다 단순했지만, Facebook 같은 서비스는 달랐다는 데서 출발합니다. 수많은 데이터가 실시간으로 바뀌고 화면 여러 부분이 동시에 업데이트되는 UI를 관리해야 했는데, 당시엔 DOM을 직접 조작하는 방식이 일반적이었다고요.
그리고 React의 답이 나옵니다.
개발자가 화면을 직접 고치는 게 아니라 데이터를 바꾸면 React가 화면을 다시 계산하는 구조. 이 선언형 접근이 이후 대부분의 프레임워크에 영향을 줬다고 정리합니다.
문제를 알고 나니 형태가 이해된 것입니다. JSX가 왜 그렇게 생겼는지가 여기서 풀려요.
🧩 컴포넌트를 보는 눈이 바뀐 대목
가장 크게 느낀 변화로 꼽은 게 컴포넌트를 대하는 관점입니다.
그리고 재사용에 대한 관점도 뒤집힙니다.
재사용이 아니라 책임의 단위로 본 것. 그래서 결론이 "Component는 UI를 그리는 함수라기보다 하나의 독립된 단위"가 됩니다.
단방향 데이터 흐름에 대해서도 처음의 불편함과 나중의 납득을 같이 적습니다. "처음에는 조금 번거롭게 느껴졌지만 프로젝트 규모가 커질수록 데이터가 어디에서 변경되는지 추적하기 훨씬 쉬웠다."
📝 원문에서는 이렇게 정리합니다
TypeScript에 대한 평가가 특히 구체적입니다.
무엇이 좋아졌는지를 셋으로 답니다 — Props 타입이 명확해지고, 자동완성이 풍부해지고, 리팩토링 때 IDE가 미리 알려준다는 것. 특히 컴포넌트 간 데이터가 여러 단계를 거칠 때 런타임 오류를 사전에 줄일 수 있었다고요.
그리고 대가도 같이 적습니다. "JavaScript만 사용할 때보다 코드를 조금 더 많이 작성해야 하지만, 그만큼 유지보수성과 안정성을 얻는다." 얻는 것과 치르는 것을 나란히 놓은 것이죠.
React의 진화 방향을 읽은 대목도 좋습니다. Concurrent Rendering, Suspense, Server Components, React Compiler를 나열하면서 공통 흐름을 잡아내요.
그래서 개발자는 "'어떻게 렌더링할 것인가'보다 '어떤 문제를 해결할 것인가'에 집중"하게 된다고요.
마무리에서 Vue와 React를 비교하는 태도도 균형이 있습니다.
큐레이터 노트
낯섦이 납득으로 바뀌는 과정을 남긴 글이라 뽑았습니다.
새 기술 학습기는 대개 결론부터 씁니다. "React는 이래서 좋다"로요. 이 글은 "굳이 이렇게 해야 할 이유가 있을까"라는 첫 감정을 그대로 적어두고 시작합니다. 그리고 그 의문이 풀리는 경로를 보여줘요 — 왜 만들어졌는지를 알고 나니 형태가 이해된 것입니다.
문법을 외우는 단계와 설계를 이해하는 단계의 차이가 이 글 전체에 드러납니다. JSX를 쓸 줄 아는 것과 "UI는 State의 결과"라는 문장을 납득하는 건 다른 일이니까요. 새 기술을 배우는 회원들이 공감하며 읽을 만한 지점입니다.
Vue 경험이 비교의 축이 된 것도 좋았습니다. 이전에 쓰던 것이 있으면 새것이 더 낯설게 느껴지는데, 그 낯섦을 두 철학의 차이로 정리해냈어요. 우열이 아니라 방향의 차이로요.
02
🎧 성장일지 10. 바이브코딩 어디로 가야 할까
이경진 님
바이브코딩이 무엇인지부터 정리하고, 직접 써본 좋은 점과 위험 신호를 나눠 적은 글입니다.
좋았던 점은 명확합니다 — 개발 직군이 아닌 자리에서도 간단한 스크립트를 몇 분 만에 만들 수 있게 됐다는 것.
그런데 후반부가 이 글의 핵심입니다. 위험 신호 세 가지를 짚고, 거기서 자기 기준 세 가지를 세웁니다.
편리함을 인정하면서 그 편리함의 대가를 같이 세는 글입니다.
조금 더 들어가 보면
정의부터 명확합니다.
그리고 첫 감상이 이 글의 씨앗이 됩니다.
신기함과 불편함이 같은 데서 나옵니다. 못 짜도 돌아간다는 것과 뭘 만드는지 모른다는 것은 사실 한 현상의 두 면이에요.
⚡ 실제로 좋았던 것
효용을 구체적으로 적습니다. 개발 직군이 아닌 자리에서 일하는데, 간단한 비용 계산 스크립트나 데이터 정리용 코드가 필요할 때가 있다고요.
할 수 있게 된 일을 셋으로 정리했습니다 — 반복 데이터 정리 자동화, 문서 초안이나 표 형식 산출물 빠르게 뽑기, 모르는 개념을 코드와 함께 설명받으며 학습하기.
세 번째가 특히 눈에 띕니다. 결과물을 얻는 데 그치지 않고 배우는 도구로도 쓰고 있다는 것이니까요.
🚨 세 가지 위험 신호
그리고 "여기서부터가 이 글의 핵심이다"라고 선언하며 넘어갑니다.
① 내가 이해하지 못한 코드가 굴러간다
손쓸 방법이 없다는 표현이 정확합니다. 이해하지 못한 코드는 고칠 수도 없으니까요.
② AI는 그럴듯하게 틀린다
여기서 실제 경험이 붙습니다.
두 모델의 답이 갈렸다는 게 핵심입니다. 하나만 물었으면 몰랐을 일이에요. 그리고 갈렸을 때 고르는 건 결국 사람이라는 것.
③ 기본기가 약하면 지시조차 못 한다
가장 실용적인 지적입니다.
그리고 한 문장으로 정리합니다.
증폭기라는 비유가 정확합니다. 곱셈이니 앞의 값이 작으면 결과도 작아요.
📝 원문에서는 이렇게 기준을 세웁니다
고민 끝에 세운 방향이 셋입니다.
① AI는 '실행'을, 나는 '이해와 판단'을
"통과되면 넘어가는 게 아니라"가 실행 규칙입니다. 동작 확인이 곧 이해는 아니라는 것.
② 기본기 공부는 멈추지 않는다
편입한 이유를 여기에 답니다.
③ 비개발 직군의 무기로 쓴다
개발자와 같은 방식으로 경쟁하는 게 아니라, 자기 자리에서 쓸 수 있는 도구로 삼겠다는 방향입니다.
큐레이터 노트
편리함의 대가를 세어본 글이라 뽑았습니다.
AI 도구 사용기는 대개 "이렇게 편해졌다" 아니면 "이래서 위험하다" 한쪽으로 기웁니다. 이 글은 효용을 구체적으로 인정하고 나서 위험 신호로 넘어가요. 몇 분 만에 처리하게 됐다는 것도 사실이고, 왜 동작하는지 모른다는 것도 사실이라는 겁니다.
두 모델의 답이 갈린 경험이 이 글에서 가장 값어치 있는 대목입니다. 한 곳에만 물었으면 몰랐을 일이고, 갈린 걸 봤기 때문에 "결국 판단은 내가 해야 했다"는 결론이 실감으로 남았어요. 추상적인 경계가 아니라 겪은 것에서 나온 기준입니다.
"기본기 위에서 증폭되는 도구"라는 정리가 이 글의 압축입니다. 증폭기는 없는 걸 만들어내지 못하니까요. 그래서 CS 기본기를 계속 쌓겠다는 결론이 자연스럽게 따라옵니다.
개발 직군이 아닌 자리에서 쓴 기록이라는 점도 이 커뮤니티에 드문 각도입니다. 코드를 업으로 하지 않는 사람에게 AI 도구가 실제로 무엇을 바꾸는지, 그리고 그때 필요한 기준이 무엇인지를 보여주니까요.
💡 두 편을 겹쳐 읽으며
한쪽은 새 프레임워크를 처음 만난 기록, 한쪽은 AI 도구를 쓰며 든 고민입니다. 그런데 두 글이 같은 선을 긋고 있어요.
돌아가는 것과 아는 것은 다르다
이경진 님 글의 첫 번째 위험 신호가 이겁니다. "동작은 하는데 왜 동작하는지 설명하라고 하면 못 하는 경우"요. 그리고 그게 왜 위험한지도 분명합니다 — 문제가 생겼을 때 손쓸 방법이 없으니까요.
황대웅 님 글은 그 반대편에서 같은 선을 긋습니다. JSX를 쓸 줄 아는 것과 "UI는 현재 State의 결과일 뿐이다"를 납득하는 건 다른 일이에요. 글이 다룬 건 문법이 아니라 왜 그렇게 만들어졌는가입니다.
둘 다 "쓸 줄 안다"와 "안다" 사이에 선을 긋고, 그 선을 넘으려고 합니다.
불편했던 감각을 버리지 않았다
두 글 다 첫인상이 좋지 않았습니다.
황대웅 님은 "굳이 이렇게 해야 할 이유가 있을까?"라고 느꼈고, 이경진 님은 "내가 지금 뭘 만들고 있는지 정확히 모른다"는 감각이 불편했다고 적었어요.
그런데 둘 다 그 감각을 무시하지 않았습니다. 황대웅 님은 그 의문을 따라가 React의 설계 의도까지 갔고, 이경진 님은 그 불편함을 기준 세 개로 만들었습니다.
낯설다는 느낌은 대개 무언가를 아직 모른다는 신호입니다. 그걸 지나치면 익숙해지기만 하고, 따라가면 이해가 됩니다.
대가를 같이 적었다
세 번째 공통점은 기록의 형태입니다. 둘 다 얻는 것과 치르는 것을 나란히 놓습니다.
황대웅 님은 TypeScript에 대해 "코드를 조금 더 많이 작성해야 하지만, 그만큼 유지보수성과 안정성을 얻는다"고 적었습니다.
이경진 님은 바이브코딩의 효용을 구체적으로 적고 나서 위험 신호 셋을 답니다.
한쪽만 적으면 홍보이거나 경고가 됩니다. 둘 다 적으면 읽는 사람이 자기 상황에 대볼 수 있는 자료가 돼요.
이번 회차에서 가져갈 것
1. 새 기술이 낯설면 "왜 이렇게 만들어졌나"부터 찾기.
JSX가 어색한 건 문법 문제가 아니라 어떤 문제를 풀려고 나온 형태인지 모르기 때문일 수 있습니다. 만들어진 이유를 알면 형태가 이해됩니다.
2. AI 결과물은 "통과되면 넘어가지" 않기.
동작 확인과 이해는 다릅니다. 한 번은 읽고, 모르는 부분은 다시 묻는 것을 규칙으로 만들어두면 이해하지 못한 코드가 쌓이지 않습니다.
3. 같은 질문을 두 모델에게 던져보기.
답이 갈리는 순간이 옵니다. 그때 판단은 결국 사람이 해야 하고, 판단할 지식이 없으면 틀린 걸 그대로 받게 됩니다.
4. 기본기는 대체되는 게 아니라 증폭된다.
무엇을 요청할지 모르면 지시조차 못 합니다. AI 시대라서 CS 기본기가 덜 필요해지는 게 아니라 더 필요해집니다.
5. 컴포넌트를 재사용이 아니라 책임의 단위로 보기.
"한 번 만들어 여러 곳에서"보다 "하나의 책임만 갖도록"이 설계 기준으로 오래갑니다.
6. 도구를 고를 때 우열이 아니라 철학의 차이로 보기.
Vue는 많은 부분을 추상화하고 React는 JavaScript 중심의 유연함을 줍니다. 어느 쪽이 낫냐가 아니라 지금 무엇이 필요하냐의 문제입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
좋은 글 남겨주신 황대웅 님, 이경진 님께 감사드립니다! 😊
5기 큐레이션은 여기까지입니다. 아홉 회차 동안 좋은 기록을 남겨주신 모든 멤버분들께 감사드립니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.
'성장일지' 카테고리의 다른 글
| [5기_10 ①] 맡길 수 있는 상태로 만들기 — Re:Verse 하드닝, AI 코드 검증 루프, 반복 업무 자동화 🌱 (0) | 2026.08.16 |
|---|---|
| [5기_9 ②] 만들려는 것이 있어서 배운다 — 프로젝트가 부른 AI 개념, GPU 실측 프로파일링, SQL에서 판다스로 🌱 (0) | 2026.08.16 |
| [5기_8 ②] 재는 일이 어려운 이유 — DBMS를 쓰는 근거, LLM 서빙 엔진 계측, 테스트를 알아채는 AI 🌱 (0) | 2026.08.16 |
| [5기_8 ①] 배터리 잔량에 속도를 맞추기 — 하고 싶은 마음과 버거운 현실 사이 🌱 (0) | 2026.08.16 |
| [5기_7 ②] 시험이 알려준 건 점수가 아니라 방법 — 학기 회고 세 편 🌱 (0) | 2026.08.14 |