말하지 않은것에 대하여

vibe coding 혹은 agentic coding 에 대한 수많은 논의들이 오가고 있다.

 

llm으로 코딩을 할때, 말한 것을 어떻게 처리하느냐도 문론 큰 이슈이다. LLM이 학습한 내용에 있는것 혹은 학습한 내용으로 보간할 수 있는것에 대해서는 당연히 정상적인 결과를 내 놓는다. 하지만 사용자가 학습한 내용에서 벗어난 것을 말하게 되면 알수 없는 경로에서 전혀 엉뚱한 것들이 보간된 결과가 튀어 나오게 된다. 이게 일반적으로 말하는 halucination이다.

 

여기까지가 여태까지 논의에서 이야기 되던 것들이고, 그 나머지는 "말하지 않은것"에 대한 처리방식에 대한 문제가 있다. 사용자가 무언가를 요청해서 LLM이 결과를 내 놓으려면 결과와 요청사이의 간극, 즉 수많은 말하지 않은 것들이 존재할 수 밖에 없다. 모든 것을 이야기 한다는 것은 결국 사용자가 코드를 작성하는 것이고(혹은, 아주 정밀한 사양서를 만들어, 예전에 은행권에서 얘기하던 "워드로 코딩한다" 라는 수준의 사양서,  야 한다.

 

각 LLM별로 그 말하지 않은것에 대한 기본값을 가지고 있고(문론 온도에 따라서 기본값은 왔다 갔다 할 수도 있다.) 그 기본값으로 채워 넣은것들이 바로 평균값, 일반 상식에 준하는 내용인 것이다.

 

vibe coding 의 과정은 저 기본값으로 채워진 것에 대해서 내 의도와 다른 부분들을 발견해서 지적해 나가는 과정이다.  하나를 얘기하면 하나를 알아 듣는 사람이 있는가 하면 하나를 얘기하면 열을 알아듣는 사람이 있다고 한다. 이것은 그 알아듣는 사람의 능력의 문제라기 보다는 말하는 사람과 듣는 사람간에 겹치는 상식이 얼마나 되느냐의 문제이다. LLM은 기본적으로 모든 영역에 대해서, 모든 사람들의 상식의 평균값을 가지도록 되어 있다. 또한 요청 사항, 말한 내용이 특정 도메인을 지칭하게 될경우, 그 도메인의 평균값이 다시 일반 상식을 override한다. 즉 요청 받은 도메인에 대해서도 꽤 잘, 하나를 말하면 열을 알아 들을 수 있다는 얘기이다. 이제 여기부터 인간사이의 소통에서 합을 맞춰 나간다는 작업이 진행된다. 내가 하나에서 열까지 다 얘기할 수는 없기 때문에 하나를 얘기하고는 열을 알아듣고 작동하기를 바라지만, LLM이 열을 다 궁예질해서 맞추어 줄 수는 없기 때문에 말하지 않은 부분에 대해 다시 설명을 하는 과정을 가지게 된다. 앞서 얘기했듯 이것이 vibe coding 의 과정이다.

 

상식이 겹치는 영역은 좀더 전문적인 용어를 사용해서, 충분히 좁은 domain으로 영역을 줄여 나갈 수 있다. 이게 바로 개발을 잘하는 사람이 vibe coding도 잘한다. 라는 얘기가 나오는 이유이다.

vibe coding은 매번 새 과제를 시작할때 마다 다시 합을 맞추는 과정을 거쳐야 한다는 문제가 있었다.

 

그 불편함을 해결하기 위해 agentic coding 의 경우에는 soul.md 에 사용자가 생각하는 "기본 상식" 들을 적어 놓고 매번 다시 얘기하지는 않는 형태로 진화하게 된다. 합을 맞추는 과정을 생략하게 되면, 하나를 말하면 정말 열을 알아듣고 작업을 하는 상황을 목격하게 된다. 문론 soul.md 혹은 harness 라고 불리우는 것을 잘 만들어 두었을 경우의 이야기이고.. 저 soul.md 조차도 매번 내가 업데이트 하기 귀찮으니 내가 요청했던 내용들을 요약해서 업데이트 해줘... 하는 형태로 지속적 갱신이 일어나게 되어 있다.

 

그럼 모든 문제가 해결되었는가. 말하지 않아도 하나를 말하면 열을 말한것처럼 행동하면서, 열개의 항목에는 처음에 얘기한 학습할때 포함되었던 내용, 비슷한 내용, 그리고 전혀 색다른 내용들이 섞여 있게 된다. 열가지 내용의 조합 방식까지 따지면 수백가지의 요청이 만들어지게 되는 것이다. 수백 가지의 항목중 학습할때 포함되었거나 비슷한 내용은 잘 처리하겠지만 나머지 항목에 대해서는 알수 없는 이상한 응답이 튀어나오게 된다는 의미이다.

 

어찌 될지 아직 잘 모르겠다. 되는 영역 안되는 영역이 점차 구분되어 나갈 것으로 기대했었는데, 업계에서는 다 될거다 라고 계속 얘기를 하고 있다. 한계와, 되는것 안되는 것이 정리되어 나가야 개발자 우울증이 점차 사라지지 않을까.