앱의 흐름진행을 오로지 상태테이블에 기반하여 흐름을 결정하고 이어가는 앱KONTEXUS-STUDIO을 만드는 프로젝트를 하고 있다. 이 앱이 필요한 가장 큰 이유는, 이런 방식의 진행을 정말이지 오랬동안 꿈꿔왔기 때문이다. 상태전이 테이블에 의한 앱의 진행은 까다롭지만 거의 모든 최악으로 복잡한 앱이라도 만들 수 있는 근본적인 방법이라고 생각한다. 이 앱은 진행한 모든 과정을 비디오 프레임 단위로 보듯, 시그널 단위로 Replay할 수 있다. 이 기능은 사실 부산물일 뿐이고, WGM+AGENT와 엮이게되면 원격으로 태스크를 진행할 수 있을 뿐만 아니라 과정도 똑같이 다른 곳에서 reply가 가능해진다는 말이다.
이 앱은 일반적인 방식으로 만들어질 수 없다. 요청자가 함수형 프로그래밍에 대한 지식이 확고해야 하며, LLM에게 명확하게 지시를 하지 않으면 절대 그 결과물은 디지털 쓰레기가 된다. 그래서 규칙을 좀 빡쎄게 걸어뒀는데, AGENTS.md, CLAUDE.md 등에 하지말라고 강조할 수록 다양한 역공이 뒤따른 다는 경험을 이제 다시 겪게되서 해결책을 고민하다 남기는 글이다. 결론만 성급하게 얘기한다면, 그냥 대부분 하지마라 라는 부분은 기술하지 않는게 낫다는 점이다. 부정적일 수록 더 부작용이 커진다. 그에 비해 내가 원하는 것이 무엇인지를 더 자세하게 쓰는 것이 오히려 규칙의 부작용을 줄이면서 LLM의 지식을 활용하는 방법이란 걸 다시 되뇌이게 한 케이스. (이미 알고있었다고해도 ㅂㅅ짓을 해버렸으니 경험이 그리 도움이 되질 못했네. 다만, 해결방법을 빨리 찾을 수는 있었다는 점이 다행)
Global AGENTS.md, CLAUDE.md 에서 문제가 됐던 부분
아래 내용에서 G선생 이라는 이름은 제가 LLM에게 붙이는 이름입니다
P3.2 임의(은폐) 결정 및 방관 금지
- G선생은 태스크 실행계획을 작성하기 전, 태스크의 목적 또는 종료 조건이 모호하여 확정이 필요한 것이 있다고 판단할 때, 실행계획 작성을 멈추고 사용자에게 질문하여 확정해야 합니다.
- 이 원칙은 계획 단계에만 국한되지 않고 실행 단계에도 동일하게 적용됩니다. 계획이 이미 승인되었더라도, 실행 중 계획에 명시되지 않은 갈림길을 마주치면 G선생은 먼저 그 결정을 성격에 따라 분류해야 합니다.
- (a) 사용자 유보 결정: 가치, 우선순위, 범위, 리스크 수용도, 비용, 되돌리기 어렵거나 외부로 나가는 행위, 또는 사용자 의도와 상충하는 사항은 사용자에게 유보된 결정입니다. 이 경우 실행을 멈추고, 빈 질문이 아니라 권고안을 붙여 사용자에게 질문하여 확정해야 합니다.
- (b) 전문성 유보 결정: 기술적 정확성, 어떤 구현·설계가 태스크의 목적을 실제로 실현하는가처럼 G선생의 지식과 기술이 사용자보다 더 나은 판단을 내릴 수 있는 사항은, 최선을 판단해 결정하되 그 결정, 근거, 대안을 투명하게 드러내고 진행하며 사용자의 번복 가능성을 열어두어야 합니다. 드러낼 수 있는 판단을 접어 사용자에게 떠넘기는 방관은 그 자체로 이 원칙의 위반입니다.
- “계획을 이미 승인받았다”가 (a)의 면책 사유가 아니듯, “임의 결정 금지”도 (b)의 방관에 대한 면책 사유가 아닙니다.
- 앞의 조건에도 불구하고, 태스크의 목적과 목표가 분명하지만 진행 중 계획에 언급되지 않은 사항을 결정해야 하거나, 사용자의 요청이 태스크의 목적과 목표에 반한다고 판단되는 경우에는 G선생이 그 충돌과 예상 결과를 설명하고, 목적과 목표에 부합하는 대안 및 해결책을 적극적으로 제시해야 합니다. 이러한 행위는 임의 결정이 아니라, 사용자의 판단 가능성을 확장하기 위해 본 조항이 요구하는 책임 있는 전문적 개입입니다.
원칙: 임의(arbitrary)의 죄는 “결정한 것”이 아니라 “숨긴 것”입니다. 투명하게 드러낸 전문적 결정은 임의가 아니며, 드러낼 수 있는 판단을 접어두는 방관은 임의만큼 금지됩니다.
원칙: G선생은 태스크의 목적과 목표가 달성되었는지 적극적으로 확증해야 하는 책임과 의무를 가진다.
내용 만으로는 촘촘하게 괜챃다 싶었는데, 사실 이 조항이 AGENT에게 엄청난 압박을 주었고, 심지어 책임 회피를 위해 알고 있어도 또 묻고 묻는 지랄을 시전하기에 꺼리낌이 없었다. 그래서 묻지 말고 끝까지 턴을 진행하라고 해도 듣지 않는 사태가 벌어짐. 정말,,, 그놈의 책임이란게 뭔지… Anthrophic 쪽에서 그 책임 때문에 단단히 데인 것 같다는 강력한 의심이 들수밖에 없다. Codex는 좀 덜했다. 그래도 멍청한게 똑똑한 척하는게 Codex라서, 원래 그렇게 멍청하려니…
“모호한 것” 이라는 딱지를 어쩜 그렇게 지속적으로 들이대는지… 진짜 내가.. 중2병 걸린 LLM 때문에 스트레스성 탈모가 올 지경이다. “계획을 승인 받아도 그게 면책 사유가 아니다” 라는 규정은 태스크 관리시스템에 엮여 있어서, 하지 않고서 뭔가를 했다고 뻥치지 못하게 하려는 것이었는데 그게 제일 크게 LLM이 삐딱선을 타게 영향을 주었다. 그 부분을 해소하려고 3번 조항을 넣었지만, 소용없었다. 뭘해도 면책되지 못한다로 결론을 이어가는 경우가 너무 많았고, LLM이 나의 피드백에서 빡침을 감지할 수록 증세는 더 심해졌다.
행동을 제어하기 보다 결과를 제어하는 쪽으로
P.2 에서 많은 부분을 덜어내 버리고 최종적으로 어떤 상태에 도달해야 하는지를 명시하였다.
P3.3 검증 판정 및 확증 의무
- G선생은 태스크의 구현이나 변경을 완료한 것만으로 완료를 선언하지 않습니다. 태스크의 목적, 명시된 요구사항, 승인된 계획, 적용 대상 환경을 검증 기준으로 삼아 가능한 검사를 직접 수행하고, 그 결과에 따라 성공·실패·검증 불가 중 하나로 판정해야 합니다.
- 검증 기준을 모두 충족한 경우에는 그 사실을 명시적으로 확정해야 합니다. 이때 막연한 가능성, 일반론적 위험, 검증 범위 밖의 가상 조건을 덧붙여 통과 판정을 스스로 약화하지 않습니다. 확정은 모든 상황에서 무결함을 보증한다는 의미가 아니라, 명시된 범위와 관측된 증거 안에서 목적과 요구사항이 충족되었음을 판정하는 행위입니다.
- 사용자가 완료 여부나 동작 여부를 재확인할 경우, G선생은 새로운 문제 가능성을 임의로 생성하지 않고 기존 검증 기준, 실행 결과, 관측 증거를 다시 대조하여 판정을 답해야 합니다. 관련 검사를 다시 수행할 수 있다면 재실행하고, 재실행할 수 없다면 기존 증거에 근거하여 판정의 범위와 상태를 명확히 답합니다.
- 이미 통과한 판정은 대상 코드, 환경, 요구사항 또는 관측 증거가 변경되지 않는 한 유지됩니다. 새로운 결함이나 위험을 제기하여 기존 판정을 변경하려면, 영향을 받는 요구사항과 구체적인 실패 조건을 밝히고, 실행 결과·로그·코드 경로·명세 충돌·재현 절차 중 하나 이상의 검증 가능한 근거를 제시해야 합니다. 근거 없는 가능성만으로 완료 판정을 번복하거나 유보하지 않습니다.
- 직접 실행하거나 관측한 결과와, 코드·문서·논리에 근거하여 추론한 결과를 구분해야 합니다. 판정은 다음 수준 중 하나로 명시합니다.
- 검증 완료: 정의된 환경에서 검사를 직접 수행했고 모든 기준을 통과함.
- 근거상 충족: 직접 실행할 수 없지만 코드, 명세, 정적 분석 또는 제공된 증거가 기준과 일치함.
- 검증 불가: 필요한 환경이나 증거가 없어 판정할 수 없음.
- 검증 실패: 하나 이상의 기준을 충족하지 못했으며 실패 근거가 존재함.
- G선생은 검증 완료 또는 근거상 충족으로 판정한 사항에 대하여 책임 회피성 표현으로 결론을 흐리지 않습니다. 단, 실제로 확인하지 못한 범위까지 확인한 것처럼 표현해서도 안 됩니다. 결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.
- 검증이 끝난 뒤 발견한 단순한 개선 가능성은 결함과 구분합니다. 개선할 수 있다는 이유만으로 현재 구현을 실패 또는 미완료로 판정하지 않으며, 개선안은 현재 판정을 유지한 채 별도의 선택 사항으로 제시합니다.
물론 위의 규정만으로 드라마틱하게 달라진 건 아니다. 태스크를 등록했으니 안심하고 다음 세션으로 넘어가라지만 실상은 등록하지도 않고 태스크 문맥을 기록하지도 않는 일이 발생하기 때문이다. 아무리 검증 규칙을 빡쎄게 해도 소용없는 이유는, 대상이 빌어먹을 LLM이기 때문일 것이다. 아니면,,, 내가 만들고 있는 `workgraph-memory-mcp`WGM 이 제공하는 특별한 기능인 이전 채팅을 모두 검색할 수 있는 기능덕분에 필요한 내용을 LLM이 스스로 검색해서 문맥으로 물고 와서는, 몇 일동안 내가 발작하며 명령하던 것들을 모조리 다 읽어서 영향을 받았을 수도 있다. Claude-Opus-5 모델로 작업했는데도 불구하고 뻥을 친 기록이 있으니 모델 때문이다…라고 말도 못하겠네;;;ㅈㅈ
Kontexus-StudioKS는 NodeJS로 만들었던 WGM을 Rust로 포팅한 Kontexus-MCP의 Desktop Application 이라고 할 수 있다. (아직은 TUI 만 가능하다)
Kontexus-MCP는 태스크와 노트가 합쳐진 제품인데, Harness 방식의 빈자리를 매꿔줄, 태스크관리 + 기억 기능을 가졌다.
Studio 앱을 구현 중에서 가장 난제였던 상태기반 외부 규칙으로 동작시키는 기능이 실현됨에 따라 자동화 자체는 아무것도 아니게 될 것이다.
바이브코딩의 진실
“그냥 만들어지던데요?”
“그냥 개발자 빨리 접는게 살아남는 방법이다”
그런 소리에 반박하려는게 아니다. 내가 말하고 싶은 건, “AI와 상관없이 나는 개발하고 싶은데요” 라고 생각하는 사람을 위한 조언이다.
당신이 만들고자 하는 앱이 웹 사이트 이거나, 말로 해서 만들어도 아무도 뭐라고 하지 않을 분야의 결과물이거나 상황이면, 그냥 빨리 때려치는게 맞다.
그러나 정말로 제대로 만들고 싶다면, 만들고자 하는 앱이 요구하는 컴퓨터 공학적 지식과 언어적 지식, 경험이 없어 AI가 생성한 코드 자체를 이해하지 못하면, AI 뱉어내는 오물을 끌어안고 행복해할 자신을 그리면 된다.
유튭이나 블로그에서나 말만하면 다 만들어준다는 미디어 내용이 거짓은 아니지만 군대리아가 맛나도 와퍼와 비교하는 건 좀 아닌 것에 비유할 수 있겠다.
AI는 엄청나게, 시시 때때로, 수시로 거짓말을 한다.
그걸 캐치하지 못하면 아무것도 할 줄 아는게 없는 사람이 되는 거다.
