"vibecoded: yes/no?"를 넘어서 — AI 관여도를 더 유익한 방식으로 포착하려는 시도, 버전 1

유익한 레이블(label)과 카테고리(category)를 고안하려고 할 때, 제 경험상으로는 항상 하향식(top-down)보다는 상향식(bottom-up)으로 시작하는 것이 가장 좋습니다.

제가 실제로 접했던 전형적인 현실 세계의 사례들은 무엇일까요?

사례 A: 순수 vibecoder (vibecoder)
접근 가능한 어떤 AI든 코드를 생성합니다.
인간은:

• 아키텍처(architecture)를 이해하지 못함
• 코드를 전혀 읽지 않음
• 솔루션이 좋은지 여부를 알지 못함
• 작동하는 것처럼 보일 때까지 이것저것 클릭하며 테스트함
• 반복적으로 "이것 좀 고쳐줘"라고 말함

인간의 기여는 다음과 같습니다:

• 제품 아이디어
• 취향 (taste)
• 주관적 평가

--> vibecoding (vibecoding)은 분명히 그 나름의 자리가 있으며, 완전히 올바른 선택이 될 수도 있습니다!
동시에, 이는 변화 속에서 살아남기 어려울 가능성이 높으며, 어떻게 만들어졌는지에 대한 매우 명시적인 경고와 정직함을 바탕으로 타인과 공유되어야 합니다.
"vibecoded"라는 단어는 이를 표현하기에 아주 좋습니다.

사례 B: 끈기 있는 비코더(non-coder) AI 빌더
(만약 이것이 여러분에게 "그가 자신의 접근 방식이 실제보다 덜 나쁘게 느껴지도록 노력하는 지점"처럼 느껴진다면 — 어느 정도 맞습니다 :)
인간은 소프트웨어를 처음부터 직접 구현할 수 없습니다.
하지만 그들은 다음과 같이 행동합니다:

• 여러 모델의 출력을 비교함
• AI들에게 서로를 비판하도록 요청함
• 아키텍처 개선을 요청함
• 모듈성(modularity)을 고집함
• 이해할 수 있도록 AI에게 추상적인 수준에서 흐름을 설명해 달라고 요청함
• 문서(documentation)를 읽음
• 광범위하게 테스트함
• 좋고 나쁜 솔루션에 대한 직관을 점진적으로 쌓아감
• 몇 달 동안 소프트웨어를 유지 관리함

그들이 모든 줄을 이해하지는 못할 수도 있습니다.
하지만 그들은 다음을 이해합니다:

• 컴포넌트(component)의 목적
• 원하는 아키텍처
• 사용자 경험 (user experience)
• 실패 모드 (failure modes)

사례 C: AI를 강력한 도구로 사용하는 전통적인 프로그래머
프로그래머는:

• 모든 것을 이해함
• 스스로 코드를 작성할 수 있음
• 시간을 절약하기 위해 AI를 사용함

전형적인 사용 사례:

• "기본 구조를 설정해줘"
• "이것에 대한 좋은 접근 방식은 무엇인가요?"
• "초안을 작성해줘."

인간이 검토하고 다시 작성합니다.

사례 D: 최첨단 "에이전트 기반 소프트웨어 엔지니어링 (agentic software engineering)"
(이것이 현재 기술이 나아가고 있는 방향으로 보입니다.

적어도 이것에 접근할 수 있고, 토큰 비용을 감당할 수 있는 소수의 행운아들에게는 말입니다.

프로그래머는:

직접 코드를 거의 작성하지 않고
사양 (specifications)을 생성하며
에이전트 워크플로우 (agent workflows)를 생성하고
자동화된 테스트 (automated testing)를 사용하며
리뷰 루프 (review loops)를 생성하고
전략적으로 모델을 선택하며
아키텍처 (architecture)를 평가합니다.

그들은 최종 구현 코드를 직접 타이핑하지 않을 수도 있습니다.
하지만 시스템을 깊이 이해하고 있습니다.

---

---

이것을 어떻게 포착할 수 있을까요?
이것을 살펴보면, 적어도 4개의 독립적인 차원 (dimensions)이 나타나는 것으로 보입니다.
(조금 번거롭긴 하지만, 결과가 처음부터 복잡하거나 망가진 것처럼 들리지 않게 하려면 이보다 적은 수는 생각해낼 수 없었습니다.)

축 1: 기술적 이해도 (Technical understanding)
낮음:

"이 코드가 무엇을 하는지 모르겠습니다."

높음:

"모든 주요 설계 결정 (design decision)을 설명할 수 있습니다."

축 2: 프로세스 정교함 (Process sophistication)
낮음:

하나의 채팅창.
"이게 작동하게 만들어줘."

높음:

다수의 에이전트 (agents).
벤치마크 (Benchmarks).
테스트 (Tests).
리뷰 (Reviews).
모델 선택 (Model selection).
자동화된 루프 (Automated loops).

축 3: 인간의 구현 관여도 (Human implementation involvement)
낮음:

AI가 거의 모든 코드를 작성함.

높음:

인간이 대부분의 코드를 작성함.

참고:
이 버전에서는 축 1과 축 3이 여전히 약간 겹칩니다.
실제로는 기술적 이해도와 인간의 구현 관여도가 모호해질 수 있습니다.

축 4: 실제 사용 규모 (The real world usage scale)
0 - 생성됨 (Generated)
작성자가 진지하게 사용해 보지 않음.
1 - 시도함 (Tried)
작성자가 실행해 보고 명백한 문제들을 수정함.
2 - 정기적으로 사용함 (Regularly used)
작성자가 실제 작업을 위해 실제로 사용함.
3 - 데일리 드라이버 (Daily driver)
작성자가 이에 의존하며 실제 사용을 통해 반복적으로 개선함.

---

---

---> 미래인가 - 아니면 현재인가?

• 최상위 프로그래머 (top tier programmer)는 아마도 (제가 틀렸다면 교정해 주세요) 다음과 같은 모습일 것입니다:

인간 구현 관여도 (Human implementation involvement): 낮음
기술적 이해도 (Technical understanding): 매우 높음
프로세스 정교함 (Process sophistication): 매우 높음

반면, 전형적인 바이브코더 (vibecoder)는 다음과 같습니다:

인간 구현 관여도 (Human implementation involvement): 낮음
기술적 이해도 (Technical understanding): 낮음
프로세스 정교함 (Process sophistication): 낮음

제가 단지 다음과 같이만 질문한다면, 이 둘은 동일해 보입니다:

"AI 관여도가 얼마나 높았나요?"

이것이 바로 우리가 단순히 "vibecoded"라는 단어 그 이상이 필요한 이유입니다.
여기에 더해, 사람들이 어떤 코드가 실제로 형편없이 작성되었다는 실제적인 지표 없이, 단지 높은 AI 관여도로 작성되었다는 사실만 알고 있을 때 반사적으로 "vibecoded!"라고 외치는 현상도 고려해야 합니다.
라벨이 실제로 적용된 예시 (Case C, 테스트되었으나 아직 실무에 사용되지는 않음):
AI 보조형 (AI-assisted), 기술적으로 잘 이해되었으며, 테스트되었으나 아직 배포되지 않은 시스템
이것은 "vibecoded" 여부(on/off)를 따지는 것보다 훨씬 더 많은 정보를 저에게 전달해 줄 것입니다.

제가 여전히 혼란스러워하는 부분이 어디라고 생각하시나요?
제가 놓친 기성 용어가 있나요? 여러분은 무엇을 사용하시나요? "AI 증강 개발 (AI-augmented development)", "켄타우로스 프로그래밍 (centaur programming)"?
더 간결한 라벨에 대한 제안이 있으신가요?
제출자: /u/hugo-the-second
[link] [comments]