나의 첫 해커톤, 딸깍톤

HoonDong_K·2026년 4월 4일

참가 계기

정말 많은 AI 도구부터 AI 활용법, 그리고 여러 AI 트렌드까지 정신없이 변화하고 발전하는 가운데 나는 그 흐름을 제대로 타지 못한다고 생각하였다.

개발하면서 단순히 코드를 생성하는 용도부터 치열하게 AI의 의견에 반박하며 할루시네이션을 쳐내가는 무료 AI는 지금도 없으면 허전할 정도로 애용한다.

하지만 실제 내 프로젝트의 구조를 이해하고, 내가 작성한 프롬프트에 따라 계획을 짜주고, 나보다 훨씬 뛰어난 코딩 실력으로 서비스를 만들어주는 유료(a.k.a 비싼) AI는 사용해본 적이 없다.

그렇기 때문에 Claude Code, Codex, Gemini Pro 등등 새롭고 핫한 도구들이 등장하더라도 제대로 사용해보지 못하게 되니, 자연스럽게 트렌드에 뒤쳐지고 있다는 느낌이 들기 시작하였다.

AI에 대해 스스로 부족하다고 인지하기 시작하였고 그 간극을 채워줄 수 있는 어떤 수단이 필요하다고 느끼던 와중, 우연히 오픈채팅방을 통해 "딸깍톤" 해커톤에 대한 홍보문을 접하게 되었다.

마침 '만우절을 기념으로 한 엉뚱한 서비스'를 주제로 하였기에 부담감은 적으면서 짧은 시간 안에 하나의 완성품을 도출해내야 하는 치열한 환경이 나의 부족한 AI 경험을 채워나갈 수 있다고 판단하여 큰 고민없이 해커톤에 나를 던져넣었다.

다행히 짧은 시간 안에 동료들을 모아 해커톤에 신청할 수 있었고 이번 글을 통해 내가 해커톤에서 경험한 것과 바이브 코딩에 대한 인사이트를 공유해보려 한다.

기획부터 개발까지

1️⃣ 어떤 도구를 사용하지?

바이브 코딩 해커톤이었기에 실제 프로젝트를 관리하고 서비스를 생성할 수 있는 AI 도구를 미리 경험해볼 필요가 있었고 바이브 코딩을 통해 간단히 하나의 서비스를 만들어보기로 결정하였다.

구글에서 공개한 에이전트 중심의 IDE, Antigravity가 등장하고 여러 사람들이 사용 경험을 공유하였던 것이 생각나 Antigravity를 설치하여 바이브 코딩을 진행하였다.

최근 개발자 지인들과 함께 있는 채팅방에서 읽어보면 좋은 아티클, 밋업 홍보, 학습 블로그 등 다양한 링크들이 공유되던 가운데, 시간이 지나면 링크를 찾기 위해 이전 채팅 기록을 불러오거나 채팅 링크 목록까지 들어가서 확인해야 하는 불편함을 느끼고 있었다. 이에 대해서 공유되는 링크들을 한 번에 모아둘 수 있는 간단한 서비스가 있으면 좋겠다고 판단하여 이를 주제로 바이브 코딩을 시작하였다.

계획 → 실행 → 검증

바이브 코딩을 통해 서비스를 만드는 것은 그리 어렵지 않았는데, 서비스를 만드는 과정에서 가장 인상깊었던 점은 생각보다 서비스가 뚝딱 만들어지진 않았다는 점이다.

내가 만들고 싶은 서비스에 대한 기획과 동작 방식, 데이터를 저장하기 위한 간단한 설계 등등 생각했던 것들을 프롬프트에 작성하더라도 그대로 진행되는 것이 아니라 AI Agent가 실행될 계획을 먼저 보여준 뒤 사용자의 동의를 구하는 작업이 우선적으로 시행된다.

이 과정에서 개발자는 실행 계획을 읽어보고 실제 자신이 의도한대로 작성되지 않았다면 계획을 수정하고, 보완된 계획을 실행하여 AI Agent로부터 실제 코드를 작성하도록 실행시킬 수 있다.

마지막으로 실제 구현된 내용이 제대로 동작하는 지, 혹은 에러가 발생하지 않는지 브라우저 동작을 통해 테스트를 진행하게 된다.

"브라우저 내에서 폴더를 추가할 때 패스워드 모달 창이 정상적으로 띄워지는 지 테스트해줘"

실제 제작 당시에 진행된 테스트는 아니고, 글을 작성하면서 위와 같은 프롬프트를 통해 진행된 브라우저 테스트 녹화본을 올렸다. 참고로 녹화된 파일도, 브라우저 내 커서도 내가 직접 동작시킨 것은 아무 것도 없다. 모두 AI Agent가 작업한 내용이다.

바이브코딩을 통해 간단한 서비스를 만들어보며 느꼈던 한 가지 인사이트는 "단순히 서비스를 만드는 것을 넘어, 생산까지의 그 일련의 과정들이 구체화되고 체계적인 단계들을 갖춰나가고 있다." 였다.

2️⃣ 간단한 기획

만우절 기념 서비스를 만드는 것만큼 도파민이 터지고 개발할 때 웃음이 끊이지 않는 그럼 서비스를 만드는 것이 목표였다.

해커톤에 참여하기 전 날 각자 어떤 서비스를 만들어오고 싶은지 간단히 고민해오고 피그잼을 통해 프로젝트 구체화를 진행하였다.

서비스의 목적성도 가지면서 사용하는 사람들이 어떻게 하면 더 '킹받을 수 있을까?'에 초점을 두며 아이디어를 확장해나갔고 그렇게 만들어진 서비스는 "반성문 작성 애플리케이션"이었다.

가장 직관적으로 사용자를 킹받게 할 수 있는 요소는 웹 서비스의 Interaction에 있다고 생각하여 사용자의 입력에 있어 불편함을 의도적으로 발생시키고, 이 불편함을 반성에 대한 진성성으로 승화시키는 그런 웹 서비스에 해당한다.

1️⃣ STEP 1 — 메인 페이지
- 랜딩 페이지로 서비스에 대한 간단한 소개 및 로고
- 서비스를 시작할 수 있는 진입점
2️⃣ STEP 2 — 잘못 심문
- 닉네임 입력을 통한 신원 확인
- 잘못한 점이 있으면 그대로 반성할 수 있게 입력창 제공
- 잘못한 점이 없다면 유도 질문을 통해 압박 및 억지 죄명을 제공

3️⃣ STEP 3 — 반성문 작성
- 키보드 타이핑 금지
- 자음과 모음이 결합된 글자를 직접 클릭하여 반성문을 작성
- 다른 탭 이동 및 글자 제거 시, 진정성이 느껴지지 않는다 판단하여 입력된 글자 모두 제거
- 숫자 클릭 시 랜덤 숫자 재배치
- 마침표 클릭 시, 인터렉션을 통해 움직이는 마침표를 잡아야 입력 가능

등등 여러 요소들을 포함하여 기획하게 되었다.

사실 OCR과 같이 캔버스에 글자를 그려 입력하게끔 하는 기능이나 AI를 도입하는 여러 요소들도 추가되면 더 재밌을 거라 판단하였지만 개발 시간이 4시간 밖에 없었고 유료 API가 도입되는 순간 서비스 관리가 어려워질 것이라 판단하여 간단하지만 담백한 애플리케이션 제작으로 방향성을 잡았다.

3️⃣ 해커톤 당일

해커톤 당일 열심히 모임 장소에 도착하였는데, 예상했던 것보다 준비가 많이 되어있어서 놀랐고 내가 원했던 컨셉이라 입장부터 흥미진진하였다.

입장과 함께 굿즈도 제공해주셨는데, 개인적으로 키보드 키링(?)이 너무 마음에 들었다. 개발할 때 고민하면서 키보드로 딸깍거리면 문제해결능력이 갑자기 수직 상승하는 느낌이랄까..

바이브 코딩 후기

바이브 코딩을 통해서 서비스를 만들어가면서 최대한 다양한 AI 도구를 활용해보는 것을 목적으로 하였다.

실제 바이브 코딩을 하며 사용했던 AI 도구들을 살펴보면 아래와 같다.

카테고리	도구
UI/UX	Lovable, Stitch
프로토타입 생성	Figma Make, Lovable, v0
AI / IDE	Claude Code, Antigravity, Gemini, Perplexity

서비스에 대해 AI를 통해 기획한대로 빠르게 디자인을 뽑아내고 프로토타입을 만들어서 서비스를 구체화하는 과정까지는 정말 빠르게 진행되었던 것 같다.

하지만 한 가지 간과했던 점은 이 작업은 개개인이 따로 시도하고 있었단 점이다.

그라운드 룰이나 협업 방식에 대해 따로 이야기를 나눠 합의해지 못했기 때문에 각자가 생각한대로 먼저 AI를 돌려보고 결과만을 공유하다보니, 정작 개개인이 만든 결과물은 도출되어도 이걸 하나의 프로젝트로 합치기 어렵다는 문제에 직면하게 되었다.

서로의 결과물이 각자 분산되는 문제를 해결하기 위해 한 가지 고안하였던 방법은 "JSON 파일과 Markdown 파일을 적극적으로 활용하는 것" 이었다.

최근 AI 아티클을 읽다가 각 기능들에 대해 Markdown 파일을 만들어두고 그 기능과 관련된 명세 내용들 혹은 규칙들을 적어, AI Agent가 해당 내용을 기반으로 작업할 수 있도록 하는 내용이 생각나 이를 활용해보려 하였다.

최대한 각자가 만든 결과물에 대한 기능들을 마크다운이나 JSON 파일과 같은 문서로 변경하여 새로운 환경에서도 구현되었던 결과물의 기능들을 그대로 사용하여 재구현이 가능하도록 합치는 것이 목표였다. 또한, 규칙이 되는 마크다운 파일들도 추가하여 이 후에 만들어지는 기능들 또한 해당 규칙을 토대로 만들게 하도록 설정하려했다.

1️⃣ 디자인 통일

Google에서 만든 Stitch를 통해 기획 내용을 프로토타입을 뽑아내니 프로젝트의 디자인을 테마 형태로 제공해주었다.

Stitch에서는 Figma, MCP 등으로 다양한 방식으로 export가 가능하다. 이를 활용해서 AI를 통해 Design.md 파일을 생성하였고 팀원들에게 공유하여 지금까지 만들었던 결과물을 합칠 때, 통일된 디자인을 사용할 수 있도록 규칙을 설정하였다.

2️⃣ 역할 분담

우리의 서비스는 총 3가지의 페이지로 구성되어있다.

메인 페이지
반성 주제 선정 페이지
반성문 작성 페이지

이에 대해, 각자 모든 서비스를 만드는 것이 아닌 페이지를 하나씩 담당하여 서로의 작업 범위가 겹치지 않도록 분담하였다. 이 때 중요했던 점은 각자의 작업한 내용을 마크다운과 JSON 파일로 관리하는 것이었다.

예를 들어, 내가 그 당시 담당했던 작업은 반성 주제 선정 페이지를 만드는 일이었다. 위 기능을 어떻게 하면 어느 환경에서도 일관되게 기능을 구현할 수 있을까를 고민하다, JSON 파일을 통해 주제와 죄명 그리고 그에 따른 반성문 테마 등을 정의한다면 조금 더 관리하기 편할 것이라 판단하였다.

{
  "meta": {
    "title": "반성문 심문 시스템",
    "flow": [
      "q1은 항상 첫 질문",
      "이후 질문은 랜덤",
      "모든 답변은 결국 유죄로 귀결"
    ],
    "rules": {
      "no_10_times": "자동 죄 확정",
      "min_answers": 13,
      "shake_effect": "아니오 누적 시 화면 흔들림 증가"
    }
  },

  "flow": {
    "step1": "질문 시작 (q1 고정)",
    "step2": "예/아니오 반복",
    "step3": [
      "예 → 즉시 죄 확정",
      "아니오 → 다음 질문",
      "아니오 10회 → 강제 죄 확정"
    ],
    "step4": "최종 죄목 생성"
  },

  "question": {
    "id": "qX",
    "question": "질문 내용",
    "answers": {
      "yes": {
        "type": "confirm | input | branch",
        "result": "죄 확정"
      },
      "no": {
        "next": "다음 질문"
      }
    }
  },

  "crime": {
    "title": "죄목 이름",
    "description": "설명",
    "severity": "처벌 수준",
    "theme": "UI 테마 (원고지, 연애편지 등)"
  },

  "forced_case": {
    "condition": "아니오 10회",
    "result": "현실 부정 및 반성 회피의 죄"
  },

  "themes": [
    "원고지",
    "연애편지",
    "각서",
    "사직서",
    "가족",
    "친구",
    "건강",
    "디지털",
    "환경"
  ]
}

실제 사용한 파일에 대한 느낌만 살펴보기 위해 간소화된 버전이다. 해당 JSON 파일에 대한 버전 및 기획 내용을 위한 메타 데이터, 답변에 따라 어떤 질문들과 죄명을 판정하는 유도 질문들과 죄명에 따른 원고지 테마 등등을 데이터로 정의하여 관리하였다.

일관성있는 데이터 파일은 만들었지만 이를 통해 만들어지는 기능 구현 방식에도 일관성을 부여하기 위해 마크다운 파일 또한 생성해주었다.

# 🔨 진정성 100% 반성문 생성기 — 기획 문서 v3

> 어떤 답을 해도 죄목이 확정되는 만우절 인터랙티브 심문 웹앱.

---

## 1. 프로젝트 개요
---

## 2. 전체 플로우

---

## 3. 질문 시스템

### 3-2. 질문 답변 유형 (type)

| type | 설명 | 동작 |
|---|---|---|
| `confirm` | 예/아니요 단순 선택 | 예 → 죄 확정 / 아니요 → 다음 질문 |
| `input` | 예 선택 후 텍스트 입력 | 입력값이 죄명 설명에 템플릿으로 삽입됨 |
| `branch` | 예 선택 후 3지선다 | 선택지마다 다른 죄명 |
| `양방향` | 예/아니요 모두 죄로 귀결 | q5, q17, q18, q20, q22 등 |

### 3-3. 아니요 연속 카운터 (noCount)


noCount  shakeClass  화면 효과              메시지
──────────────────────────────────────────────────
3        shake-sm    0.3s, 2px 진폭        "...그래요?"
5        shake-md    0.4s, 5px 진폭        "정말요? 🤨"
7        shake-lg    0.5s, 8px 진폭        "저희 다 알고 있습니다."
9        shake-xl    0.6s, 12px 진폭       "화면이 흔들립니다..."
10       shake-max   폭발 애니메이션        → 강제 죄 확정 트리거


> **10회 아니요 강제 확정 죄명:**  
> *"현실 부정 및 반성 회피의 죄"*  
> 추가 혐의 10개 자동 부과 (아니요 1회당 죄 1개 누적)

---

## 4. 죄명 확정 화면


### 테마별 반성문 스타일

| theme | 스타일 | 대상 |
|---|---|---|
| `manuscript` | 원고지 | 일반 반성문 |
| `love` | 연애편지 | 연인 관련 죄 |
| `contract` | 각서 | 사회적·환경적 죄 |
| `resignation` | 사직서 | 직장 관련 죄 |
| `family` | 가족 반성문 | 가족 관련 죄 |
| `friend` | 친구 반성문 | 친구 관련 죄 |
| `health` | 건강 각서 | 건강·식습관 죄 |
| `digital` | 디지털 범죄 각서 | SNS·폰 관련 죄 |
| `environment` | 환경 범죄 각서 | 환경 관련 죄 |

---

간략하게 위와 같은 방식으로 파일을 생성하여 추후 프로젝트 결합 시, 데이터와 문서를 통해 기능 구현에 있어 일관성을 부여하였다.

3️⃣ 프로젝트 결합

역할을 분담하더라도 각자의 작업 환경을 모두 상이하였다.

나는 Claude, ChatGPT를 통해, 한 명은 Lovable를 통해, 한 명은 Figma Make를 통해 각자의 기능들을 만들고 있었다. 그리고 각자 맡은 기능의 구현이 어느 정도 완료되면서, 이제 하나의 프로젝트로 통합할 시점에 이르렀다.

문제는 Lovable과 Figma Make 무료 버전은 구현된 코드들을 따로 export할 수 없었단 점.. 이에 대해 해결 방법을 찾아보다가 다행히 Github Repository를 연동할 수 있다는 점을 발견하였다.

조금 비효율적일 순 있지만 해커톤을 위한 Organization을 하나 만들어서 3개의 Repository를 관리하였다.

Lovable Repository
Figma Make Repository
Original Repository

그리고 각각의 기능들을 Original Repository에 기능 상세 마크다운과 JSON 파일와 디자인 마크다운을 통해 최종적으로 결합시킬 수 있었다.

이제 하나의 Repository를 통해 프로젝트를 관리할 수 있었으니, 이 부분에 대해선 IDE에서 제공하는 AI Agent를 통해 기능을 고도화하거나 부족한 부분은 개선하며 협업을 진행하였다.

결과

결과적으로 최종 3위를 하게 되었다. (왜..?)

25팀 정도가 참여하였고 5개의 조로 나뉘어서 각 조에서 예선전을 치룬 뒤, 각 조의 1등팀이 본선에 올라가 경쟁하는 구도였다.

예선에서 만난 다른 프로젝트들도 홍미로운 서비스들이 많았다. 가장 흥미로웠던 프로젝트는 Mac에서 어떤 앱을 시작하려면 게임에서 통과해야하는 서비스였다. 다양한 종류의 게임이 존재하며 실제 브라우저를 키려고 할 때 랜덤한 하나의 게임이 실행되며 목표 점수에 도달해야 브라우저가 정상적으로 실행될 수 있는 서비스였다.

서비스 자체적으로도 딸깍톤 주제에 맞게 킹받았지만, 더 흥미롭게 봤던 내용은 각 게임 기능들에 대한 Spec + Plan을 각각 마크다운 파일로 정리하여 관리하고 있다는 점이었다.

위에서 언급하였듯 나 또한 그렇게 기능에 대한 명세서를 파일로 만들어 관리하려 시도하였지만, 정돈되지 않은 폴더구조나 난잡하다는 느낌을 받는 반면 위의 팀은 각각 docs로 폴더를 관리하여 어떤 게임이 어떤 기능과 스펙을 갖는 지에 대해 쉽게 파악할 수 있었다.

한 편으로는 그런 생각도 하였다. 인간이 추론하기 쉬운 형태로 폴더를 관리하여 깔끔히 정돈하는 것이 AI 또한 어떤 파일이 어떤 폴더에 있을 지 쉽게 추론할 수 있으니 이 또한 토큰 관리에 해당하지 않을까... 아무튼 깔끔한 폴더 구조에 대해서도 한 번 더 배울 수 있는 기회였다.

근데 웬걸 우리 팀이 예선에서 1등을 하게 되었고 본선에 진출하게 되었다.

참고로 팀 명은 "AI야 해줘."다.

전혀 기대하지 않았는데 본선에 올라가게 되어서 얼떨떨한 상태로 급하게 발표를 준비하게 되었다. 본선에 진출한 5개의 팀은 발표를 통해서 참여자들에게 프로젝트를 소개하고 투표와 AI 심사 점수를 합산하여 순위를 정하게 된다.

우리 팀은 허겁지겁 발표 자료를 준비하게 되었고 발표 자료 또한 PPT를 만들기 보다는 AI를 통해 온보딩 페이지를 하나 만드는 것이 더 효과적으로 서비스를 소개할 수 있을 것이라 판단하였다.

Claude를 통해 프로젝트를 기반으로 하는 간단한 페이지를 하나 만들어서 발표 자료로 만들었고 이를 기반으로 간단한 발표와 데모를 준비하였다.

떨리기도 하였지만 한 편으로는 이렇게 사람들 앞에서 (AI가) 직접 만든 서비스를 발표하는 경험도 가져보고 싶었기에 설렌 마음으로 발표를 잘 마칠 수 있었다.

딸깍톤에서 준비한 AI 심사를 통해서도 우리 서비스에 대한 심사와 피드백을 받을 수 있었고 최종적으로 3위를 기록할 수 있었다!

회고

만족했던 점

1️⃣ AI를 통한 협업 방식을 고민하고 어떻게든 합쳐보려 시도한 것

AI에 대한 활용이나 경험은 직접 그 도구를 사용해봐야지만 알기 때문에 그 접근성으로 인해 쉽게 취득하긴 어려웠지만, AI에 대한 트렌드는 여러 아티클을 통해 나름 인사이트를 쉽게 얻을 수 있다고 생각하여 꾸준히 GeekNews를 읽으려 노력했다.

그리고 거기서 얻어걸린 희미한 지식들이 다행히 실전에서 직면한 문제에 대해 해결의 실마리로 동작한 것 같아서 성취감을 얻을 수 있었다.

물론 내가 기억해낸 것은 'AI Agent가 참고하여 따라야할 행동 규율이나 기능에 대한 명세서를 마크 다운 파일로 보관하는 것' 뿐이었고 내부 상세 내용에 대해서는 하나도 알고 있지 않았기 때문에 이를 응용하는 방법은 맨땅에 헤딩 방식으로 나아가야 했다.

그렇기 때문에 깔끔하지 못한 폴더 구조, 애매한 내용들이 들어간 마크 다운 파일, 그 외 협업 과정에서의 자잘한 이슈들이 발생했다고 생각한다.

그럼에도 불구하고 희미한 지식을 실제 활용해보며 협업해보는 것, 그리고 그것을 넘어 크게 와닿지 않았던 이론적인 내용들이 실제 겪어보며 구체화 되어가는 경험을 가져감으로써 AI와 관련된 내용들에 더 흥미를 가지고 고민하면서 접하게 되는 태도를 가져갈 수 있었다.

2️⃣ 동료들과 함께 하나의 서비스를 만드는 경험

네부캠을 한 이후로 동료들과 함께 하나의 목표를 잡고 나아간다는 경험은 항상 소중하다는 것을 늘 느끼는 것 같다.

비록 4시간의 짧은 시간이었지만 그 안에서도 함께 고민하고 리뷰하고 서로 즐길 수 있는 그런 환경 속에 같이 있다는 것이 나에게는 소중한 시간으로 남겨질 수 있었다.

쌰라웃 투 쥬니버

아쉬웠던 점

1️⃣ 조금 더 AI 트렌드에 대해 관심갖지 못했던 점

나에게 성취감을 주기도 하였지만 반대로 아쉬움을 주기도 하였다.

반쪽짜리 지식을 응용해봤다는 점이 나에게 성취감으로 다가온 반면, 제대로 응용해보지 못했다는 것이 아쉬움을 준 것이다.

그런 아쉬움이 존재하였기에 예선전에서 만났던 그 프로젝트 구조가 인상깊었다고 느껴졌던 것 같다. 그 또한 정답이라고 말하기는 어렵겠지만 나에게는 내가 가려고 했던 그 방향성에서 더 완성도가 높은 결과물에 해당했던 것 같다.

그럼에도 이 경험을 통해 AI 엔지니어링에 대한 더 많은 관심을 가질 수 있게 되어, 더 많은 아티클을 접하고 어떻게 활용해볼 수 있을까 항상 고민하는 자세를 가져보려 한다.

인사이트

마지막으로 바이브 코딩을 하며 느꼈던 두 가지 인사이트만 적어보려 한다.

1️⃣ 아직 AI를 사용하는 환경에서의 협업 방식이 자리 잡진 못한 것 같다.

빠르게 등장하는 AI 도구들과 다양하게 등장하는 AI 엔지니어링 방식들이 나오고 있지만 이들은 모두 개인 혹은 AI와의 협업에 초점을 두고 있지, AI를 사용하는 여러 사람들 간의 협업을 어떻게 풀어나가야 하는가에 대한 아티클을 크게 접해보지 못했다고 느꼈다.

이 또한 해커톤에서 실제 협업을 할 때도 쉽게 그 방법이 떠오르지 않아 느꼈던 인사이트에 해당한다. 개개인이 사용하는 AI 결과물을 하나로 결합하기 위해 사용하였던 방식인 마크다운 & JSON 파일을 사용하는 방식 또한 사실상 협업이라기보단 해당 기능을 일관성있게 개발할 수 있도록 하는 AI 활용법에 해당한다. 그리고 나는 그저 이 활용법을 협업하는 곳에 끌어다쓴 것 뿐이다.

AI 도구들이 빠르게 나오고 그 도구를 활용하여 서비스를 더 효율적으로 만드는 엔지니어링 방식들이 나오고 있고, 그 다음은.. 더 효율적으로 협업할 수 있는 방법들이 나올 차롄가..?

2️⃣ 개발자 개인의 명확한 기준과 근거가 더 중요해진 것 같다.

좋은 기회로 커피챗을 진행하였을 때, 선배 개발자님으로부터 이런 이야기를 들은 적이 있다.

"가끔씩 어떤 친구들은 경험에서 축적된 자신만의 근거를 갖는 경우가 있다. 그리고 그런 노하우로 사람들을 설득하는 힘이 있다."

그 당시에 이런 이야기를 들었을 때, 최대한 많은 경험을 해보고 나만의 근거를 쌓아가야겠다고 생각하고 넘겼었다. 반대로 생각해보면 경험이 부족한 사람들은 자신만의 근거를 쉽게 가지기 어려울 것이라 판단하였고 그럼에도 자신만의 기준을 갖고 있는 사람들은 대단한 사람들이라 생각하였다.

하지만 경험이 부족한 사람들 또한 자신만의 명확한 근거를 가져야 하는 시기가 코 앞까지 앞당겨진 것 같다고 생각이 들었다.

단순히 개발에 대한 자신의 취향을 말하기보단 이를 직접 문서화하거나 하나의 규칙으로 세울 수 있을 정도의 구체화된 자신만의 근거가 있어야 실제 AI로부터 작업에 대한 명확한 계획을 세워 지시가 가능할 것이라 판단하였다.

everything-claude-code에서도 skills 폴더에 들어가면 각 상황에 따른 규칙과 기준들이 명확하게 적혀있다. 이처럼 AI에게 작업을 시키기 위해 전달해야할 규칙들을 개발자로 부터 발생하며, 그렇기 때문에 개발자 자신의 설계 내용에 대한 명확한 근거가 AI를 통한 생산성에 직결될 것 같다고 생각하였다.

딸깍콘: https://ttalkkakthon.vibecodingclub.kr/gallery
암쏘쏘리: https://github.com/ttalkkak-and-pray/im-so-sorry-but-i-love-you

HoonDong_K

더 도전하고 더 성장하자

이전 포스트

[네이버 멤버쉽 10기 마무리] 행복하기만을 빌었던

다음 포스트

AWS Summit Seoul 2026 후기

2개의 댓글

neisii

2026년 6월 25일

인상깊게 잘 읽었습니다

1개의 답글