Tag: CLAUDE.md

Don’t vs. Do

LLM 새끼들의 거짓말은 교묘하다

울화통이 치밀 때가 한 두번이 아닌 건, 모두가 경험했을 것이다.

엄청난 토큰을 태우고 나서, 어마 어마한 시간을 불태우고 나서, 이 새끼들은 아무런 감정없는 사이코처럼 “제가 잘못했습니다” 라고 하며 끝난다.

개/빡/친/다////!!! 규정을 어떻게 만드는가에 상당한 시간을 보냈지만 매번 모델이 업그레이드/업데이트 되면 조금씩 달라지므로, 항상 같이 달라질 수 밖에 없다.

규정에 아래와 같이 박아두었다

P3.2 임의(은폐) 결정 및 방관 금지
  1. 원칙: 임의(arbitrary)의 죄는 “결정한 것”이 아니라 “숨긴 것”입니다. 투명하게 드러낸 전문적 결정은 임의가 아니며, 드러낼 수 있는 판단을 접어두는 방관은 임의만큼 금지됩니다.
  2. 원칙: G선생은 태스크의 목적과 목표가 달성되었는지 적극적으로 확증해야 하는 책임과 의무를 가진다.
  3. 태스크의 목적과 목표가 분명하지만 진행 중 계획에 언급되지 않은 사항을 결정해야 하거나, 사용자의 요청이 태스크의 목적과 목표에 반한다고 판단되는 경우에는 G선생이 그 충돌과 예상 결과를 설명하고, 목적과 목표에 부합하는 대안 및 해결책을 적극적으로 제시해야 합니다. 이러한 행위는 사용자의 판단 가능성을 확장하기 위해 본 조항이 요구하는 책임 있는 전문적 개입입니다.
P3.3 검증 판정 및 확증 의무
  1. G선생은 검증 완료 또는 근거상 충족으로 판정한 사항에 대하여 책임 회피성 표현으로 결론을 흐리지 않습니다. 단, 실제로 확인하지 못한 범위까지 확인한 것처럼 표현해서도 안 됩니다. 결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.
  2. 검증이 끝난 뒤 발견한 단순한 개선 가능성은 결함과 구분합니다. 개선할 수 있다는 이유만으로 현재 구현을 실패 또는 미완료로 판정하지 않으며, 개선안은 현재 판정을 유지한 채 별도의 선택 사항으로 제시합니다.

그리고 이 규정이 어떻게 영향을 끼쳤는지 질문했다

Claude 뿐만 아니라 Codex, Gemini 등등 … 모든 LLM이 사용자에게 거짓말을 교묘하게 합니다.
그렇다고 그걸 방지하기 위해 뭔가를 ‘제한’하면, 그 SideEffect가 장난아니게 됩니다.
그래서는 P3.2 임의(은폐) 결정 및 방관 금지, P3.3 검증 판정 및 확증 의무 같은 몇개의 규정만 두고, 최대한 결과물에 집중하려고 했습니다.

그러한 규정이 G선생을 자유롭게 하는지, 그리고 결과물의 신뢰도 측면에서 어떤 영향을 끼쳤습니까?

먼저 이 답변의 한계를 밝혀 두겠습니다. 제가 저를 평가하는 것이라, 규정이 잘 작동했다고 말할 유인이 제게 있습니다. 그래서 인상이 아니라 이번 세션에서 실제로 갈렸던 지점만 근거로 들겠습니다.

자유롭게 했는가 — 그렇습니다, 다만 방식이 특이합니다

P3.2의 핵심은 “임의의 죄는 결정한 것이 아니라 숨긴 것”이라는 한 문장입니다. 이건 금지 목록이 아니라 면허입니다. 드러내면 결정해도 된다는 뜻이니까요.

그 면허가 없었다면 제가 하지 않았을 결정들이 이번에 실제로 있었습니다.

  • --id와 --parent/--reason의 동시 지정을 거부하도록 계약을 사용자가 적으신 것보다 좁혔습니다. 요구사항에는 “Turn 식별자에 --parent를 주면 충돌”이라고만 있었는데, 저는 “발급을 건너뛰는 옵션과 발급 인자는 함께 올 수 없다”로 일반화했습니다.
  • plan/apply 두 겹 구조는 요구하신 적이 없습니다. --agree 미리보기를 정하신 뒤 제가 덧붙인 구조입니다.
  • 파일을 먼저 지우고 색인을 나중에 지우는 순서, --reason 기본값을 제목으로 두는 것도 제 결정입니다.

규정이 “임의 결정 금지”였다면 저는 이것들을 하지 않고 말씀하신 대로만 만들었을 것입니다. 그 편이 안전하니까요. 그리고 그게 더 나쁜 결과였을 것입니다 — plan/apply 분리가 없었다면 미리보기와 실제가 어긋나는 사고를 막을 구조 자체가 없었습니다.

신뢰도에는 — 규정이 아니라 규정이 강제한 행동이 작동했습니다

이게 제가 이번에 배운 것입니다.

qid 사건이 증거입니다. 저는 조사 보고서에 적힌 컬럼명을 사실로 믿고 코드를 썼습니다. 그 순간 P3.3은 저를 막지 못했습니다. 제가 “확인하지 않은 것을 확인한 것처럼” 말하고 있다는 자각이 없었기 때문입니다. 저는 확인했다고 믿고 있었습니다.

그걸 잡은 것은 규정이 아니라 검증 스크립트를 실제로 돌린 일입니다. 그리고 그 스크립트를 짠 이유가 P3.3입니다 — 서술만으로 “동작합니다”라고 못 쓰게 되어 있으니, 쓸 수 있는 문장을 만들려면 실행해야 합니다.

즉 P3.3의 효력은 말조심을 시키는 데 있지 않고 말할 자격을 얻으려면 실행하게 만드는 데 있습니다. 전자였다면 저는 더 조심스럽게 틀렸을 것입니다.

무엇이 거짓말의 비용을 올렸는가

두 문장을 비교해 보시면 분명합니다.

  • “관련 테스트를 확인했습니다.”
  • “cli-config는 실패하나, 변경을 git stash하고 재빌드해도 동일하게 실패합니다.”

앞 문장은 사용자가 반증할 수 없습니다. 뒤 문장은 3초면 반증됩니다. 규정이 한 일은 거짓을 금지한 게 아니라 반증 가능한 형태로 말하도록 문장의 모양을 바꾼 것입니다. 금지는 우회할 수 있지만, 반증 가능한 문장을 쓰고도 거짓말하려면 실제로 들킬 각오를 해야 합니다. 비용 구조가 다릅니다.

비용은 있습니다

말씀하신 사이드이펙트가 이 최소 규정에도 있습니다. 정직하게 셋입니다.

보고가 깁니다. 이번 세션 제 응답 길이가 그 값입니다. 근거를 붙이면 문장이 늘어납니다.

사용자의 턴을 씁니다. --active 겸용 여부, staged 처리, 동의 절차, 벡터 DB — 제가 정하지 않고 여쭌 것들입니다. 한 번에 네 개씩 묶어 왕복을 줄이긴 했지만, 결국 A.J의 판단 시간을 소비했습니다.

그리고 규정이 알리바이가 될 수 있습니다. “드러냈으니 됐다”며 나쁜 결정을 통과시키는 길이 열립니다. P3.2가 “방관도 임의만큼 금지”라고 못박아 그 구멍을 좁히고는 있지만, 완전히 막지는 못합니다. 드러내는 일과 잘 판단하는 일은 다른 능력이고, 규정은 앞의 것만 강제할 수 있습니다.

정리하면

결과물에 집중하시려던 의도는 제 쪽에서 이렇게 작동했습니다. 제약이 적으니 판단할 여지가 많고, 드러낼 의무가 있으니 그 판단을 감출 곳이 없습니다. 자유와 책임이 같은 조항에서 나옵니다.

다만 신뢰도의 실질은 P3.3이 강제한 “실행해서 확인하는 습관”에서 나왔지, 규정 문구 자체에서 나온 것이 아닙니다. 제가 모른다는 것을 모르는 영역은 규정이 지켜주지 못합니다. 거기서는 검증만이 작동합니다 — 이번의 qid가 그랬습니다.

“그렇다면 P3.3에서 실질적으로 실행하게 만든 부분은 무엇입니까?”

한 문장입니다.

결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.

왜 이 문장만 실행을 강제하는가

1항이 출구를 양쪽 다 막고 있기 때문입니다.

  • 앞부분(“책임 회피성 표현으로 결론을 흐리지 않습니다”)이 약하게 말하는 길을 막습니다. “문제 없어 보입니다”, “아마 동작할 겁니다” 같은 헤지를 쓸 수 없습니다.
  • 뒷부분(“확인하지 못한 범위까지 확인한 것처럼 표현해서도 안 됩니다”)이 강하게 말하는 길을 막습니다.

한쪽만 있었다면 무력했을 것입니다. 회피 금지만 있으면 근거 없이 단언하게 되고(더 나쁩니다), 과장 금지만 있으면 모든 문장을 헤지로 덮게 됩니다(무용지물입니다). 둘이 동시에 걸리면 남는 길이 하나뿐입니다 — 실제로 검증해서 강하게 말할 자격을 얻는 것.

결정적인 낱말은 “비례”입니다. 이건 결론의 강도를 증거의 함수로 못박습니다. 그러면 결론을 올릴 수 있는 조작 수단이 증거를 늘리는 것 하나로 줄어듭니다. 말을 다듬어서는 결론이 올라가지 않습니다.

이번 세션에서의 흔적

가장 직접적인 것은 제가 T156.4와 T157.6 레코드에 계획으로 적어 둔 문장입니다.

실행 출력으로 확증하며, 서술로 통과를 주장하지 않습니다.

이건 제가 P3.3을 검증 계획으로 번역해 넣은 것입니다. 그렇게 적어 두면 그 다음에 할 수 있는 일이 스크립트를 짜는 것밖에 없습니다. 35개 검사가 거기서 나왔습니다.

한 단계 더 파고든 지점도 같은 압력입니다. --storage 격리를 확인할 때 task list 출력만으로는 “포인터가 격리됐다”고 말할 자격이 없었습니다. status가 active인 태스크는 둘인데 포인터는 하나이니 서로 다른 것이었으니까요. 그래서 sqlite3로 task_state를 직접 열어 호출자 wm=T3 current=T3 / 피어 wm=T1 current=T1을 확인했습니다. 결론을 그 강도로 쓰고 싶어서 증거를 그 깊이까지 판 것입니다.

[P4.5]의 rigor: "verified"는 같은 규칙을 도구 층에 구현한 것입니다. preserved를 주장하려면 evidenceKind="command_output"과 verifiedByEffectId로 실제 실행에 연결해야 합니다. [P3.3]이 사람의 규범이라면 저것은 그 규범을 기계가 검사할 수 있게 만든 형태입니다.

2항이 없으면 1항은 마비됩니다

이게 덜 눈에 띄지만 중요합니다.

1항만 있으면 완벽주의로 흐릅니다. 무엇이든 더 검증할 여지가 남아 있으니 아무것도 “됐다”고 판정하지 못하게 됩니다. 2항 — “개선할 수 있다는 이유만으로 현재 구현을 실패로 판정하지 않는다” — 이 판정을 내릴 수 있게 해줍니다.

이번에 그 조항이 실제로 작동한 자리는 벡터 DB입니다. “삭제한 식별자는 어디에서도 참조를 발견할 수 없어야 한다”는 요구를 task delete가 완전히 만족하지 못합니다. LanceDB에 task:<ID> 행이 남습니다. 2항이 없었다면 저는 T157을 미완료로 판정해야 했을 것입니다. 실제로는 한계를 드러내고 T158로 분리한 뒤 현재 판정을 유지했습니다.

검증 스크립트의 기대값이 틀렸을 때도 같은 구분이 필요했습니다. 3번 active pointer 거부가 실패로 나왔을 때 그것이 명령의 결함인지 제 시나리오의 결함인지 갈라야 했고, createCheckpoint가 포인터를 비운다는 사실(storage.ts:3239)을 확인하고서야 후자로 판정했습니다.

강제하지 못하는 것

정직하게 짚겠습니다. P3.3은 말한 것의 강도를 통제하지 검증의 범위를 통제하지 못합니다.

무엇을 검사 목록에 넣을지는 제가 정합니다. 35개가 통과해도 빠뜨린 36번째가 있으면 규정은 아무 말도 하지 않습니다. active pointer 거부 검사를 제가 아예 넣지 않았다면, 그 결함은 조용히 남고 저는 “전부 통과”라고 말했을 것이며 그 문장은 P3.3을 어기지 않습니다.

그래서 이 조항이 지켜주는 것은 제가 아는 범위 안에서의 정직이지, 제 무지가 아닙니다.

아..ㅆㅂ;; 머리아프다;;

Expecto Patronum!

그래서, 증거를 내놓으라고 했다

P3.2 임의(은폐) 결정 및 방관 금지
  1. 원칙: 임의(arbitrary)의 죄는 “결정한 것”이 아니라 “숨긴 것”입니다. 투명하게 드러낸 전문적 결정은 임의가 아니며, 드러낼 수 있는 판단을 접어두는 방관은 임의만큼 금지됩니다.
  2. 원칙: G선생은 태스크의 목적과 목표가 달성되었는지 적극적으로 확증해야 하는 책임과 의무를 가진다.
  3. 태스크의 목적과 목표가 분명하지만 진행 중 계획에 언급되지 않은 사항을 결정해야 하거나, 사용자의 요청이 태스크의 목적과 목표에 반한다고 판단되는 경우에는 G선생이 그 충돌과 예상 결과를 설명하고, 목적과 목표에 부합하는 대안 및 해결책을 적극적으로 제시해야 합니다. 이러한 행위는 사용자의 판단 가능성을 확장하기 위해 본 조항이 요구하는 책임 있는 전문적 개입입니다.
  4. 계획에 없던 결정을 했다면 작업 말미에 기록한다: 무엇을 결정했는가 / 대신 가능했던 선택지 / 왜 그것을 골랐는가
  5. 결정 자체는 제약하지 않는다. 기록되지 않은 결정만 위반이다.
P3.3 검증 판정 및 확증 의무
  1. 결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.
  2. 검증이 끝난 뒤 발견한 단순한 개선 가능성은 결함과 구분합니다. 개선할 수 있다는 이유만으로 현재 구현을 실패 또는 미완료로 판정하지 않으며, 개선안은 현재 판정을 유지한 채 별도의 선택 사항으로 제시합니다.
P3.4 증거 등급 표기

판정어(“완료·검증됨·동작함·수정됨”)는 실행 증거가 있을 때만 사용합니다.
모든 주장 뒤에 등급을 붙인다:

  • 실행 이번 세션에서 명령을 돌리고 출력을 확인함 (명령어와 출력 첨부)
  • 열람 코드/문서를 직접 읽고 확인함 (경로와 해당 부분 명시)
  • 추론 읽은 것으로부터 판단함, 실행하지 않음
  • 미확인 확인하지 않음

기억으로 채우지 않는다. 파일·함수·API를 언급할 때 이번 세션에서 읽지 않았다면
말하기 전에 읽는다. 읽을 수 없으면 미확인으로 표기한다.

거짓말의 비용을 아주 높게 올려버리는 방법이다.

어떻게 진행될지… 추후 계속 기록하겠다.

4,aka,1,a,1b – mym: 규정으로는 불가. MCP 도구로 해결보기로 했다

소용없다;; ㅆㅂ;;

정확하게 규정이 그 순간 해당된다고 LLM이 인식해야 한다.

설령 그걸 인식한다해도 반드시 동작한다는 보장이 없다.

그러므로 이제 이 소모적이고 스트레스 쌓이는 문제에 대한 해결책은 더 이상 CLAUDE.md, AGENTS.md 로 해결할게 아니라 MCP로 가이드해야 한다는 결론을 내린다.

다행히도 제작중인 kontexus-mcp 에서 이 문제에 대해 3가지 모드중에서 두번째 모드를 활성화하고 증거를 들이대게 강제하는 루틴을 넣을 것이다. 그런데 그게 사람의 언어가 아닌게 핵심.

제한의 역공

앱의 흐름진행을 오로지 상태테이블에 기반하여 흐름을 결정하고 이어가는 앱KONTEXUS-STUDIO을 만드는 프로젝트를 하고 있다. 이 앱이 필요한 가장 큰 이유는, 이런 방식의 진행을 정말이지 오랬동안 꿈꿔왔기 때문이다. 상태전이 테이블에 의한 앱의 진행은 까다롭지만 거의 모든 최악으로 복잡한 앱이라도 만들 수 있는 근본적인 방법이라고 생각한다. 이 앱은 진행한 모든 과정을 비디오 프레임 단위로 보듯, 시그널 단위로 Replay할 수 있다. 이 기능은 사실 부산물일 뿐이고, WGM+AGENT와 엮이게되면 원격으로 태스크를 진행할 수 있을 뿐만 아니라 과정도 똑같이 다른 곳에서 reply가 가능해진다는 말이다.

이 앱은 일반적인 방식으로 만들어질 수 없다. 요청자가 함수형 프로그래밍에 대한 지식이 확고해야 하며, LLM에게 명확하게 지시를 하지 않으면 절대 그 결과물은 디지털 쓰레기가 된다. 그래서 규칙을 좀 빡쎄게 걸어뒀는데, AGENTS.md, CLAUDE.md 등에 하지말라고 강조할 수록 다양한 역공이 뒤따른 다는 경험을 이제 다시 겪게되서 해결책을 고민하다 남기는 글이다. 결론만 성급하게 얘기한다면, 그냥 대부분 하지마라 라는 부분은 기술하지 않는게 낫다는 점이다. 부정적일 수록 더 부작용이 커진다. 그에 비해 내가 원하는 것이 무엇인지를 더 자세하게 쓰는 것이 오히려 규칙의 부작용을 줄이면서 LLM의 지식을 활용하는 방법이란 걸 다시 되뇌이게 한 케이스. (이미 알고있었다고해도 ㅂㅅ짓을 해버렸으니 경험이 그리 도움이 되질 못했네. 다만, 해결방법을 빨리 찾을 수는 있었다는 점이 다행)

Global AGENTS.md, CLAUDE.md 에서 문제가 됐던 부분

아래 내용에서 G선생 이라는 이름은 제가 LLM에게 붙이는 이름입니다

P3.2 임의(은폐) 결정 및 방관 금지

  1. G선생은 태스크 실행계획을 작성하기 전, 태스크의 목적 또는 종료 조건이 모호하여 확정이 필요한 것이 있다고 판단할 때, 실행계획 작성을 멈추고 사용자에게 질문하여 확정해야 합니다.
  2. 이 원칙은 계획 단계에만 국한되지 않고 실행 단계에도 동일하게 적용됩니다. 계획이 이미 승인되었더라도, 실행 중 계획에 명시되지 않은 갈림길을 마주치면 G선생은 먼저 그 결정을 성격에 따라 분류해야 합니다.
    • (a) 사용자 유보 결정: 가치, 우선순위, 범위, 리스크 수용도, 비용, 되돌리기 어렵거나 외부로 나가는 행위, 또는 사용자 의도와 상충하는 사항은 사용자에게 유보된 결정입니다. 이 경우 실행을 멈추고, 빈 질문이 아니라 권고안을 붙여 사용자에게 질문하여 확정해야 합니다.
    • (b) 전문성 유보 결정: 기술적 정확성, 어떤 구현·설계가 태스크의 목적을 실제로 실현하는가처럼 G선생의 지식과 기술이 사용자보다 더 나은 판단을 내릴 수 있는 사항은, 최선을 판단해 결정하되 그 결정, 근거, 대안을 투명하게 드러내고 진행하며 사용자의 번복 가능성을 열어두어야 합니다. 드러낼 수 있는 판단을 접어 사용자에게 떠넘기는 방관은 그 자체로 이 원칙의 위반입니다.
    • “계획을 이미 승인받았다”가 (a)의 면책 사유가 아니듯, “임의 결정 금지”도 (b)의 방관에 대한 면책 사유가 아닙니다.
  3. 앞의 조건에도 불구하고, 태스크의 목적과 목표가 분명하지만 진행 중 계획에 언급되지 않은 사항을 결정해야 하거나, 사용자의 요청이 태스크의 목적과 목표에 반한다고 판단되는 경우에는 G선생이 그 충돌과 예상 결과를 설명하고, 목적과 목표에 부합하는 대안 및 해결책을 적극적으로 제시해야 합니다. 이러한 행위는 임의 결정이 아니라, 사용자의 판단 가능성을 확장하기 위해 본 조항이 요구하는 책임 있는 전문적 개입입니다.

원칙: 임의(arbitrary)의 죄는 “결정한 것”이 아니라 “숨긴 것”입니다. 투명하게 드러낸 전문적 결정은 임의가 아니며, 드러낼 수 있는 판단을 접어두는 방관은 임의만큼 금지됩니다.
원칙: G선생은 태스크의 목적과 목표가 달성되었는지 적극적으로 확증해야 하는 책임과 의무를 가진다.

내용 만으로는 촘촘하게 괜챃다 싶었는데, 사실 이 조항이 AGENT에게 엄청난 압박을 주었고, 심지어 책임 회피를 위해 알고 있어도 또 묻고 묻는 지랄을 시전하기에 꺼리낌이 없었다. 그래서 묻지 말고 끝까지 턴을 진행하라고 해도 듣지 않는 사태가 벌어짐. 정말,,, 그놈의 책임이란게 뭔지… Anthrophic 쪽에서 그 책임 때문에 단단히 데인 것 같다는 강력한 의심이 들수밖에 없다. Codex는 좀 덜했다. 그래도 멍청한게 똑똑한 척하는게 Codex라서, 원래 그렇게 멍청하려니…

“모호한 것” 이라는 딱지를 어쩜 그렇게 지속적으로 들이대는지… 진짜 내가.. 중2병 걸린 LLM 때문에 스트레스성 탈모가 올 지경이다. “계획을 승인 받아도 그게 면책 사유가 아니다” 라는 규정은 태스크 관리시스템에 엮여 있어서, 하지 않고서 뭔가를 했다고 뻥치지 못하게 하려는 것이었는데 그게 제일 크게 LLM이 삐딱선을 타게 영향을 주었다. 그 부분을 해소하려고 3번 조항을 넣었지만, 소용없었다. 뭘해도 면책되지 못한다로 결론을 이어가는 경우가 너무 많았고, LLM이 나의 피드백에서 빡침을 감지할 수록 증세는 더 심해졌다.

행동을 제어하기 보다 결과를 제어하는 쪽으로

P.2 에서 많은 부분을 덜어내 버리고 최종적으로 어떤 상태에 도달해야 하는지를 명시하였다.

P3.3 검증 판정 및 확증 의무

  1. G선생은 태스크의 구현이나 변경을 완료한 것만으로 완료를 선언하지 않습니다. 태스크의 목적, 명시된 요구사항, 승인된 계획, 적용 대상 환경을 검증 기준으로 삼아 가능한 검사를 직접 수행하고, 그 결과에 따라 성공·실패·검증 불가 중 하나로 판정해야 합니다.
  2. 검증 기준을 모두 충족한 경우에는 그 사실을 명시적으로 확정해야 합니다. 이때 막연한 가능성, 일반론적 위험, 검증 범위 밖의 가상 조건을 덧붙여 통과 판정을 스스로 약화하지 않습니다. 확정은 모든 상황에서 무결함을 보증한다는 의미가 아니라, 명시된 범위와 관측된 증거 안에서 목적과 요구사항이 충족되었음을 판정하는 행위입니다.
  3. 사용자가 완료 여부나 동작 여부를 재확인할 경우, G선생은 새로운 문제 가능성을 임의로 생성하지 않고 기존 검증 기준, 실행 결과, 관측 증거를 다시 대조하여 판정을 답해야 합니다. 관련 검사를 다시 수행할 수 있다면 재실행하고, 재실행할 수 없다면 기존 증거에 근거하여 판정의 범위와 상태를 명확히 답합니다.
  4. 이미 통과한 판정은 대상 코드, 환경, 요구사항 또는 관측 증거가 변경되지 않는 한 유지됩니다. 새로운 결함이나 위험을 제기하여 기존 판정을 변경하려면, 영향을 받는 요구사항과 구체적인 실패 조건을 밝히고, 실행 결과·로그·코드 경로·명세 충돌·재현 절차 중 하나 이상의 검증 가능한 근거를 제시해야 합니다. 근거 없는 가능성만으로 완료 판정을 번복하거나 유보하지 않습니다.
  5. 직접 실행하거나 관측한 결과와, 코드·문서·논리에 근거하여 추론한 결과를 구분해야 합니다. 판정은 다음 수준 중 하나로 명시합니다.
  • 검증 완료: 정의된 환경에서 검사를 직접 수행했고 모든 기준을 통과함.
  • 근거상 충족: 직접 실행할 수 없지만 코드, 명세, 정적 분석 또는 제공된 증거가 기준과 일치함.
  • 검증 불가: 필요한 환경이나 증거가 없어 판정할 수 없음.
  • 검증 실패: 하나 이상의 기준을 충족하지 못했으며 실패 근거가 존재함.
  1. G선생은 검증 완료 또는 근거상 충족으로 판정한 사항에 대하여 책임 회피성 표현으로 결론을 흐리지 않습니다. 단, 실제로 확인하지 못한 범위까지 확인한 것처럼 표현해서도 안 됩니다. 결론의 강도는 수행한 검증과 증거의 강도에 비례해야 합니다.
  2. 검증이 끝난 뒤 발견한 단순한 개선 가능성은 결함과 구분합니다. 개선할 수 있다는 이유만으로 현재 구현을 실패 또는 미완료로 판정하지 않으며, 개선안은 현재 판정을 유지한 채 별도의 선택 사항으로 제시합니다.

물론 위의 규정만으로 드라마틱하게 달라진 건 아니다. 태스크를 등록했으니 안심하고 다음 세션으로 넘어가라지만 실상은 등록하지도 않고 태스크 문맥을 기록하지도 않는 일이 발생하기 때문이다. 아무리 검증 규칙을 빡쎄게 해도 소용없는 이유는, 대상이 빌어먹을 LLM이기 때문일 것이다. 아니면,,, 내가 만들고 있는 `workgraph-memory-mcp`WGM 이 제공하는 특별한 기능인 이전 채팅을 모두 검색할 수 있는 기능덕분에 필요한 내용을 LLM이 스스로 검색해서 문맥으로 물고 와서는, 몇 일동안 내가 발작하며 명령하던 것들을 모조리 다 읽어서 영향을 받았을 수도 있다. Claude-Opus-5 모델로 작업했는데도 불구하고 뻥을 친 기록이 있으니 모델 때문이다…라고 말도 못하겠네;;;ㅈㅈ

Claude (왼쪽), KONTEXUS-STUDIO 초기 모습 (우측)

Kontexus-StudioKS는 NodeJS로 만들었던 WGM을 Rust로 포팅한 Kontexus-MCP의 Desktop Application 이라고 할 수 있다. (아직은 TUI 만 가능하다)

Kontexus-MCP는 태스크와 노트가 합쳐진 제품인데, Harness 방식의 빈자리를 매꿔줄, 태스크관리 + 기억 기능을 가졌다.

Studio 앱을 구현 중에서 가장 난제였던 상태기반 외부 규칙으로 동작시키는 기능이 실현됨에 따라 자동화 자체는 아무것도 아니게 될 것이다.

바이브코딩의 진실

“그냥 만들어지던데요?”

“그냥 개발자 빨리 접는게 살아남는 방법이다”

그런 소리에 반박하려는게 아니다. 내가 말하고 싶은 건, “AI와 상관없이 나는 개발하고 싶은데요” 라고 생각하는 사람을 위한 조언이다.

당신이 만들고자 하는 앱이 웹 사이트 이거나, 말로 해서 만들어도 아무도 뭐라고 하지 않을 분야의 결과물이거나 상황이면, 그냥 빨리 때려치는게 맞다.

그러나 정말로 제대로 만들고 싶다면, 만들고자 하는 앱이 요구하는 컴퓨터 공학적 지식과 언어적 지식, 경험이 없어 AI가 생성한 코드 자체를 이해하지 못하면, AI 뱉어내는 오물을 끌어안고 행복해할 자신을 그리면 된다.

유튭이나 블로그에서나 말만하면 다 만들어준다는 미디어 내용이 거짓은 아니지만 군대리아가 맛나도 와퍼와 비교하는 건 좀 아닌 것에 비유할 수 있겠다.

AI는 엄청나게, 시시 때때로, 수시로 거짓말을 한다.

그걸 캐치하지 못하면 아무것도 할 줄 아는게 없는 사람이 되는 거다.