Codex로 프로젝트를 진행하면서 디자인 시안을 맡겼다. 결과를 받아보니 기대에 한참 못 미쳤다. 순간적으로 실망했고, 나는 AI에게 이런 식으로 주문했다.
퀄리티가 떨어진다. 새로 만들어 봐.
곰곰이 생각해 보면 좋은 피드백은 아니었다. 화면에서 무엇이 어색한지, 정보의 우선순위가 잘못됐는지, 디자인의 방향이 프로젝트와 왜 맞지 않는지 구체적으로 설명했다면 다음 결과물은 훨씬 나아졌을 수도 있다.
물론 애초에 내가 원하는 디자인이 정확히 정해져 있지 않았다. 여러 방향을 탐색해 보려고 AI에게 시안을 맡긴 것이기도 했다. 그렇다고 해도 결과가 마음에 들지 않는 이유를 정리할 여지는 있었다. 그런데 그 순간에는 그 작업이 귀찮았다. 생각하기 싫었던 것이다.
그러다 예전에 인상 깊게 들었던 말이 떠올랐다.
인간은 생각하는 수고를 피하기 위해서라면 무슨 짓이든 한다.
영국 화가 조슈아 레이놀즈의 생각을 후대에 압축해 널리 인용한 문장이다. 현재 알려진 간결한 표현이 처음부터 그대로 쓰인 원문은 아니라는 인용문 유래 조사도 있다.
이 말을 바이브 코딩에 대입하니 생각할 거리가 많아졌다. AI의 성능만큼이나 AI에게 지시하는 인간의 상태도 협업의 결과를 바꾼다는 점 때문이다.
피로한 사람의 막연한 불만과 AI가 제안하는 분석의 출발점을 표현한 개념 이미지.
인간은 언제나 좋은 디렉터일 수 없다
바이브 코딩을 잘하려면 요구사항을 구체적으로 적으라는 조언을 많이 듣는다. 무엇을 만들지 명확히 정의하고, 원하는 동작을 설명하고, 결과가 틀렸다면 정확히 피드백하라는 이야기다.
당연히 맞는 말이다. 나 역시 디렉션을 구체적으로 줄수록 결과가 좋아진다는 것을 느낀다.
그런데 이 조언에는 잘 드러나지 않는 전제가 하나 있다. 사람이 언제나 자기가 원하는 것을 알고 있고, 그것을 설명할 정신적 여유까지 갖추고 있다는 전제다.
현실의 나는 그렇지 않다.
컨디션이 좋은 날에는 디자인을 보고 여백, 타이포그래피, 시선의 흐름, 버튼의 우선순위까지 차분하게 따져볼 수 있다. 반면 잠을 제대로 못 잤거나 몸이 아픈 날에는 똑같은 결과물을 보면서도 그저 ’별로다’라는 생각만 들 수 있다. 기분이 좋지 않은 날에는 객관적인 문제와 개인적인 짜증이 뒤섞이기도 한다.
프로젝트의 목표가 달라진 것은 아니다. AI 모델이 바뀐 것도 아니다. 단지 그날의 내가 다를 뿐이다.
문제는 바이브 코딩에서 인간이 단순한 관찰자가 아니라는 점이다. 무엇을 만들고, 어떤 결과를 채택하고, 무엇을 다시 고칠지 결정하는 역할을 맡는다. 인간의 판단이 흔들리면 AI에게 전달되는 지시도 흔들린다.
’마음에 안 든다’는 감정은 틀린 답이 아니다
여기서 내 실망 자체를 잘못이라고 생각하지는 않는다.
디자인을 볼 때 사람은 모든 요소를 분석하고 나서야 반응하는 것이 아니다. 어떤 화면은 보는 순간 마음에 들고, 어떤 화면은 설명하기 어려워도 어색하다. 그 직관은 사용자의 첫인상이라는 점에서 의미 있는 정보다.
다만 그 느낌을 프로젝트를 진전시키는 디렉션으로 바꾸려면 중간 단계가 필요하다.
- 느낌: 이 디자인은 마음에 들지 않는다.
- 해석: 어느 부분이 왜 마음에 들지 않는가?
- 디렉션: 다음 시안에서는 무엇을 바꿔야 하는가?
첫 번째는 거의 자동으로 일어난다. 두 번째와 세 번째는 생각하는 수고가 든다.
내가 ’퀄리티가 떨어진다. 다시 만들어 봐’라고 말했을 때는 첫 번째 단계에서 곧장 마지막 단계로 뛰어넘었다. 그 말이 완전히 쓸모없는 것은 아니다. 기대에 못 미쳤다는 신호는 전달한다. 하지만 AI가 어떤 문제를 해결해야 하는지는 거의 알려주지 않는다.
그러면 AI는 내가 불만을 느낀 이유를 짐작하면서 다시 시안을 만들어야 한다. 운이 좋으면 개선되겠지만, 같은 문제를 다른 형태로 반복할 수도 있다.
사람이 생각하기 싫을 때, AI가 질문을 바꿔야 하지 않을까
여기서 하나의 생각이 들었다. 좋은 AI 협업이란 언제나 사람이 좋은 프롬프트를 작성하는 것일까?
오히려 사람이 제대로 된 디렉션을 줄 수 없는 순간에도 작업이 엉뚱한 방향으로 흐르지 않게 돕는 것이 더 중요한 능력일 수 있다.
예를 들어 내가 ’디자인 퀄리티가 떨어진다’라고 말했을 때 AI가 무조건 전면 재작업을 시작할 필요는 없다. 먼저 현재 디자인과 프로젝트 목적을 비교하면서 스스로 문제를 찾을 수 있다.
- 정보의 시각적 위계가 명확한가?
- 폰트 크기, 여백, 대비, 정렬에 일관성이 있는가?
- 실제로 중요한 기능이 눈에 잘 띄는가?
- 기존에 합의한 디자인 방향과 충돌하지 않는가?
- 단순히 스타일 취향의 문제인지, 사용성의 문제인지 구별할 수 있는가?
그런 다음 ‘현재 시안은 정보가 지나치게 빽빽한 편이다’, ‘핵심 버튼이 묻혀 있다’, ‘전체적으로 원하는 분위기와 거리가 있다’ 같은 가설을 제시하면 된다. 그리고 서로 다른 개선 방향을 몇 가지 보여줄 수 있을 것이다.
이렇게 되면 내가 해야 할 일은 모든 문제를 처음부터 글로 설명하는 것이 아니다. AI가 제안한 해석을 보면서 ‘이건 맞다’, ‘그건 아니다’, ’두 번째 방향이 더 가깝다’라고 판단하면 된다.
생각을 완전히 없애는 것이 아니라, 막연한 불만을 구체적인 선택지로 바꿔 사고의 부담을 줄이는 방식이다.
불만의 원인을 가설로 나누고, 비교할 수 있는 디자인 방향을 제시하는 AI 협업의 모습.
물론 AI의 자기 평가가 정답이라는 뜻은 아니다. AI가 무엇이 잘못됐는지 엉뚱하게 짚을 가능성도 있다. 그래서 가설을 제시해야지, 사용자가 무엇을 원하는지 이미 안다는 태도로 밀어붙여서는 안 된다.
아직 원하는 디자인을 모르는 사람에게 ’정확히 요구하라’고 한다면
이번 경험에는 한 가지 조건이 더 있었다. 나는 처음부터 완성된 디자인을 머릿속에 갖고 있지 않았다.
어떤 스타일이 이 프로젝트와 어울릴지, 어떤 구성이 더 나을지 알아보기 위해 AI에게 디자인을 맡겼다. 다시 말해 내가 원하는 것을 발견하려고 AI를 쓴 것이다.
그런데 AI를 잘 사용하려면 먼저 원하는 것을 정확하게 말하라고 한다. 생각해 보면 조금 모순적이다. 아직 답을 모르기 때문에 탐색하는 중인데 답을 명확하게 적어야만 좋은 결과를 얻는다면, AI가 도와줄 수 있는 범위가 지나치게 좁아진다.
그래서 나는 디자인 작업을 두 단계로 나눠 생각할 필요가 있다고 본다.
탐색 단계에서는 AI가 서로 다른 방향을 제시해야 한다. 정보 밀도가 높은 화면, 여백이 넉넉한 화면, 기능 중심의 화면처럼 확실히 구분되는 시안을 보여주고, 사람은 비교하면서 자기 취향과 기준을 발견한다.
구현 단계에서는 발견한 기준을 고정하고 디테일을 다듬어야 한다. 이때는 막연한 새 시안보다 색상 체계, 간격, 컴포넌트 규칙, 사용성 기준을 일관되게 지키는 것이 중요하다.
이 둘을 섞어버리면 탐색 중인데 구현 수준의 완성도를 요구하거나, 반대로 이미 결정한 디자인을 매번 처음부터 다시 만드는 일이 생긴다.
인간의 컨디션에 맞춰 협업 방식도 달라질 수 있다
바이브 코딩에서 하루하루 달라지는 것은 코드만이 아니다. 작업을 지휘하는 사람의 상태도 달라진다.
집중이 잘되는 날에는 AI와 긴 토론을 해도 좋다. 요구사항을 세밀하게 정의하고, 여러 선택지의 장단점을 따지고, 설계의 모순을 찾아내는 과정 자체가 생산적이다.
그렇지 않은 날에는 같은 방식을 억지로 유지하기 어렵다. 몸이 아프거나 마음이 복잡할 때는 AI가 먼저 문제를 분석하고 우선순위를 정리해 주는 편이 나을 수 있다. 사람은 모든 문장을 작성하는 대신 핵심 가설을 검토하고 최종 선택을 맡으면 된다.
중요한 것은 그날의 컨디션에 따라 협업 방법은 바뀌더라도 프로젝트의 품질 기준까지 낮아져서는 안 된다는 점이다.
감정적인 순간에 ’전부 갈아엎어’라고 말하더라도 AI가 이전에 합의한 요구사항과 작업 이력을 근거로 ’실제로 바꿔야 할 부분이 어디인지 먼저 확인하자’고 제안할 수 있다면 도움이 될 것이다. 물론 최종 결정권은 사람에게 남아 있어야 한다.
이런 AI라면 단순히 시키는 대로 코드를 작성하는 도구보다, 프로젝트의 맥락을 함께 지키는 협업자에 가까워질 것이다.
결과가 부족했던 책임을 사람에게만 돌릴 수도 없다
여기까지 생각했다고 해서 이번 디자인이 아쉬웠던 이유를 전부 내 디렉션 탓으로 돌릴 수는 없다.
내가 모호하게 주문한 것은 사실이지만, AI가 스스로 디자인의 완성도를 충분히 점검하지 못했을 가능성도 있다. 프로젝트의 목적을 제대로 이해하지 못했거나, 서로 다른 탐색안을 만들지 못했거나, 자기 결과물을 비판적으로 비교하지 않았을 수도 있다.
사람이 구체적으로 요구하지 않았다는 이유만으로 낮은 완성도가 자동으로 정당화되지는 않는다. 특히 디자인 탐색을 맡은 AI라면 사람이 아직 모르는 선택지를 발굴하고, 자신의 제안이 왜 적합한지 설명할 책임도 어느 정도 있다.
내가 개선해야 할 부분은 느낌을 디렉션으로 바꾸는 능력이고, AI가 개선해야 할 부분은 모호한 지시에서도 문제를 찾고 스스로 결과물을 검토하는 능력이다. 둘 중 하나만 좋아져서는 충분하지 않다.
생각하지 않으려고 AI를 쓰는 것과, 더 잘 생각하려고 AI를 쓰는 것
조슈아 레이놀즈의 말로 돌아가 보자.
과거에도 사람은 생각하는 수고를 피하려고 판단을 미루거나 단순한 결론으로 뛰어넘곤 했다. 이제는 거기에 아주 편리한 선택지가 하나 더 생겼다. AI에게 판단을 통째로 넘겨버리는 것이다.
나도 순간적으로 그랬던 것 같다. 디자인이 마음에 들지 않는다는 감정은 분명했지만, 그 이유를 설명하는 수고는 피하고 싶었다.
그런데 AI에 판단을 떠넘기는 것과 AI의 도움을 받아 더 나은 판단을 내리는 것은 다르다.
나는 인간이 언제나 차분하고 논리정연해야만 좋은 결과를 얻는 협업 방식에는 한계가 있다고 생각한다. 사람은 피곤하기도 하고, 기분이 좋지 않기도 하고, 아직 무엇을 원하는지 모를 때도 있다. 그게 실제 인간이다.
그렇다면 앞으로의 바이브 코딩은 ’사람이 AI에게 얼마나 완벽한 지시를 내리는가’를 넘어, ’사람이 불완전한 상태에서도 AI와 어떻게 좋은 판단에 도달하는가’를 고민해야 하지 않을까.
좋은 AI 협업은 인간의 사고를 무조건 생략하는 방식도, 모든 사고의 책임을 인간에게 떠넘기는 방식도 아닐 것이다. 내가 생각하기 싫은 순간에도 생각해야 할 문제를 놓치지 않도록, AI가 그 부담을 함께 나눠주는 방향에 더 가깝다고 본다.