THE STEADY COMPANY
Ignite로 시작했다가 React로 돌아온 이유 cover image

Ignite로 시작했다가 React로 돌아온 이유

AI 시대에 ‘스킬’이 퀄리티를 만든다고 느낀 순간들

2026-02-13 10:00

·
  • AI
  • Prompt
  • Skill
  • React
  • Ignite
  • Blog

Ignite로 시작했다가 React로 돌아온 이유

한 줄 요약

Swift로 블로그를 만들겠다고 Ignite를 붙잡고 시작했는데, 결국 React로 돌아왔다.
전환의 결정타는 “프레임워크”가 아니라 스킬(AGENTS/SKILL)의 유무가 결과물 퀄리티를 갈랐다는 체감이었다.

Ignite는 좋았다. 그런데…

Ignite는 정말 매력적인 도구였다.

  • SwiftUI처럼 UI를 구성할 수 있고
  • 정적 사이트를 만들기 위한 문법도 친숙하고
  • 무엇보다 “Swift로 블로그를 한다”는 낭만이 있었다

그런데 어느 순간부터는, 내가 원하는 퀄리티에 도달하는 속도가 생각보다 느렸다.

솔직히 말하면… AI에게 “그냥 말하면” 다 만들어줬다.
근데 “다 만들어주는 것”과 “내가 만족하는 것”은 달랐다.

첫 프로토타입의 교훈: AGENTS/SKILL이 없으면 결과가 흐릿해진다

첫 번째 프로토타입은 이거였다.

  • https://thevibecompany.github.io/

이때는 AGENTS나 SKILL에 대한 설정이 없었다.
그러니까 결과물이 “나쁘진 않은데, 어딘가 애매한” 상태로 자주 착지했다.

내가 느낀 문제는 대충 이런 거였다.

  • UI가 일관되게 정리되지 않음 (간격/타이포/버튼 톤이 흔들림)
  • 코드 구조가 금방 비대해짐 (컴포넌트 역할이 섞이고, 나중에 수정할 때 피로도가 커짐)
  • 디테일(접근성/메타/SEO 같은 것들)이 계속 빠짐
    내가 원래 잘 모르니, 빠져도 “빠진 줄” 모르고 넘어가게 됨

AI가 만들어주긴 하는데, 기준점이 없으면 결과가 흐릿해진다.
결국 **“잘 만들기 위한 규격(=스킬)”**이 필요했다.

전환 계기: Vercel 스킬을 보고 충격을 받았다

전환한 계기는 Vercel에서 제공하는 스킬 덕분이었다.

여기서 체감한 건 “모델이 똑똑해서”라기보다,
잘 정리된 절차와 기준이 이미 스킬로 박혀 있으면 결과가 안정적으로 나온다는 거였다.

그리고 inference.sh 같은 걸 보면, 이제는 좋은 스킬이 오픈소스로 쌓이고
그걸 “어떻게 조합하는지” 자체가 다음 스텝이 될 것 같은 느낌이 든다.

남이 잘 만들어둔 걸 잘 쓰는 게… 편하긴 하더라

oh-my-opencode를 쓰면서 느꼈던 것도 비슷했다.

  • 남이 이미 삽질하면서 다듬어 둔 설정/워크플로우를
  • 내가 그대로 가져다 쓰는 순간
  • “생각보다 빨리” 만족스러운 결과에 가까워진다

결국 생산성을 끌어올리는 건, 내가 천재가 되는 게 아니라
좋은 프리셋을 잘 가져다 쓰는 것일지도 모르겠다.

이번 블로그에서 내가 활용한 것들

나는 SEO도 잘 모르고, TS/React도 잘 모른다.
그래서 더더욱 “규칙이 박힌 스킬”이 필요했다.

대략 이런 것들을 활용했다.

  • Vercel에서 제공하는 React 관련 best-practice 스킬
  • 여러 콘텐츠를 생성하기 위한 스킬
  • 이미지 생성 스킬
    이건 개인적으로는… 아직 좀 구린 것 같다

근데 이 블로그는 소스 코드를 한 줄도 안 고쳤다

이게 제일 재밌는 포인트다.

이 블로그는 소스 코드를 단 한 줄도 수정하지 않았다.
그냥 plan → action 이것만 반복했다.

예전엔 “내가 코드를 직접 만져서 고친다”가 기본 루프였다면,
요즘은 “내가 방향을 잡고, AI가 손을 움직인다”가 기본 루프가 됐다.

회사 iOS 앱에서는 프롬프트를 위해 진짜 많이 삽질했는데

회사에서 만드는 iOS 앱은 프롬프팅을 위해 정말 많은 시행착오를 거쳤다.
그래도 어느 정도 만족도 있는 결과물이 나오긴 한다.

근데 이번엔 잘 만든 스킬을 쓰는 순간, 다른 감각이 들었다.

  • “코드를 잘 아는 것”보다
  • “프롬프트를 잘 짜는 것”이 더 중요한 시대가
  • 생각보다 빨리 도달할 것 같다

코드를 안 써도 되는 시대라기보단,
코드를 직접 치는 시간이 급격히 줄어들고
대신 “방향 + 검증 + 기준”을 잡는 시간이 더 중요해지는 시대에 가까운 것 같다.

다음 스텝은 ‘스킬이 반영됐는지’ 확인하는 기능 아닐까

스킬을 많이 쓰다 보니 이런 생각이 든다.

  • 내가 이 상황에서 “어떤 스킬”을 실제로 탔는지
  • 스킬의 규칙이 결과물에 “잘 반영”됐는지
  • 어디서부터 스킬이 깨졌는지 (혹은 내가 잘못 지시했는지)

이걸 가시화해주는 기능이 생기면, 스킬은 더 빠르게 고도화될 것 같다.
프롬프트를 자산으로 삼는 사람들에겐 거의 “테스트/로깅/프로파일링” 같은 존재가 될 듯하다.

스킬트리(프롬프트) 커뮤니티가 생길 것 같은 이유

이제는 게임처럼 스킬트리가 나올 것 같다.

  • 전사 / 마법사 같은 직업이 있고
  • 대검 전사, 한손검 전사처럼 빌드가 갈리고… ㅋㅋㅋ

여기에 토큰 최적화까지 붙으면,

  • “이 빌드는 빠르다 / 싸다 / 결과가 예쁘다”
  • “이 빌드는 디버깅이 세다”
  • “이 빌드는 글을 잘 쓴다”

같은 얘기가 진짜로 굴러갈 것 같다.

게임 커뮤니티처럼 스킬트리 커뮤니티에서
“어떤 스킬 조합이 요즘 메타냐” 같은 논쟁이 많아질 거고,
결국 중요한 건 그 스킬트리(=프롬프트)를 어떻게 잘 쓰느냐가 되겠지.

결국엔, 사람이 쥐고 있는 건 ‘사용법’이다

아직까지는 게임처럼 좋은 스킬트리 찍은 AI를
사람이 잘 활용하는 그림이 더 현실적이라고 생각한다.

  • 어떤 결과가 “좋은 결과”인지 정의하고
  • 결과가 흔들릴 때 어디를 조정할지 감으로 알고
  • 실패했을 때 다음 액션을 선택하는 것

이런 것들은 여전히 사람이 더 잘한다.

Ignite에서 React로 돌아온 이유도 결국 비슷했다.
도구는 많아졌고, 만드는 건 쉬워졌는데,
퀄리티는 ‘기준(스킬)’과 ‘운영(사용법)’에서 갈린다는 걸 체감했기 때문이다.

다음엔 또 어떤 스킬을 주워오게 될까.