AI로 논문 같은 문장은 만들 수 있었다. 하지만 논문은 되지 않았다 ― 실증의 골짜기와 품질 테일러링에 대하여

ADR(Architecture Decision Record)이나 설계 문서, 기술 선정 비교 메모를 AI에게 정리해 달라고 요청해 본 경험이 있나요? 산만한 생각을 던지면 주장, 근거, 대안을 갖춘 정연한 문서가 돌아옵니다. 쓰는 과정에서 자신의 이해가 부족한 부분도 보입니다. 매우 편리한 "생각하는 도구"입니다.

저도 똑같은 방식으로 사용하고 있습니다. 떠오른 생각을 음성으로 AI에게 던져서 논문 형식으로 정리하게 합니다. 머릿속에 있는 것은 정리되지 않은 파편들입니다. "그건 이랬지", "아니, 하지만 이런 경우에는"이라며 화제가 여기저기 튑니다. 그것을 모아서 던지며 이렇게 부탁합니다.

"논점을 정리하고, 의견을 서술하고, 화제가 전환되는 부분은 연결해서, 전체 내용을 MECE(Mutually Exclusive, Collectively Exhaustive)하고 논리적으로 완성해 줘."

이는 ADR을 작성하는 감각과 겹칩니다. 주장을 먼저 고정하고, 근거와 분리하며, 반론을 상정합니다. 쓰게 하는 것 자체가 목적이 아니라, 쓰게 하는 과정에서 머릿속이 정리되어 갑니다.

그런데 그 문장을 "진짜 논문"으로 만들려고 한 순간, 손이 멈췄습니다. 움직이는 프로토타입과 실제 투입 가능한 시스템 사이에 깊은 골이 있는 것처럼, 정리된 의견과 검증된 주장 사이에도 깊은 골짜기가 있었습니다. 그리고 이번 일을 통해 도달한 결론은, "품질은 목적에 맞춰 테일러링(Tailoring)해야 한다"라는, 당연하지만 간과하고 있었던 사실이었습니다.

왜 논문 형식일까요? 메모나 블로그가 아닌 논문 형식으로 정리할 때 머릿속이 정리되는 이유는 아마 다음 세 가지 때문일 것입니다.

주장이 먼저 나온다: 무엇을 말하고 싶은지가 서두에서 고정되므로 이야기가 흐트러지지 않습니다 -
근거와 주장이 분리된다: "생각하는 것"과 "뒷받침할 근거가 있는 것"이 구별됩니다 -
반론을 상정하는 틀이 있다: 자신에게 유리한 이야기만 하고 있지는 않은지 체크하게 됩니다

ADR이나 설계 문서를 쓰면 머릿속이 정리된다는 이야기와 같은 구조입니다. 쓰는 대상을 이해하고 있지 않으면 쓸 수 없습니다. 그래서 쓰는 과정에서 "이 부분은 나도 잘 모르겠네"라는 점이 드러납니다. 논문 형식은 프레임워크(Framework)나 템플릿(Template) 같은 도구였습니다.

어느 날, 한 가지 아이디어가 떠올랐습니다.

조직이 생성형 AI(Generative AI)를 일괄 금지하더라도, 다단계 하도급의 말단에서는 섀도우 AI(Shadow AI, 무단 이용)가 발생하고 만다. 그렇다면 "사용하지 마라"가 아니라 "위험한 데이터에 접촉하지 못하게 한다"는 설계로 가면 되지 않을까.

평소처럼 AI에게 정리를 부탁했더니 꽤 설득력 있는 문장이 되었습니다. 기분이 좋아져서 저는 이렇게 생각했습니다.

"이거, 제대로 된 논문으로 만들 수 있지 않을까?"

거기서 멈췄습니다.

조사해 보니, 논문 형식의 문장과 진짜 학술 논문 사이에는 깊은 골짜기가 있다는 것을 알게 되었습니다. 제가 써왔던 것은 "논문 같은 형식을 갖춘, 정리된 의견"이었습니다. 하지만 학술 논문에 필요한 것은 그것만이 아니었습니다.

관점	논문 형식의 문장 (내가 했던 것)	학술 논문 (진짜)
목적	머릿속을 정리하고 의견을 전달함	검증 가능한 새로운 사실을 제시함
...

제 아이디어는 논리적으로는 통했습니다. 하지만 "섀도우 AI가 다단계 하도급에서 실제로 어느 정도 발생하는지", "더미 데이터로 정말 개발 품질이 떨어지지 않는지"를 보여줄 데이터는 단 하나도 가지고 있지 않았습니다. 이것이 실증의 골짜기였습니다.

이 골짜기를 건너려면 무엇이 필요할까요? 공정으로 분해해 보니 개발 프로젝트의 마일스톤(Milestone)과 겹쳐 보였습니다. 의견과 논리만으로는 넘을 수 없는 구간을 나열해 봅니다.

#	마일스톤	할 일	개발에 대입한다면
M0	질문을 검증 가능한 형태로 좁히기	"○○은 △△에 효과가 있는가"를 한 문장으로. 측정할 수 없는 질문은 여기서 걸러냄	수용 조건(Acceptance Criteria)의 정의
...

이 표를 통해 분명해진 것이 있습니다. M0~M2는 책상 위에서 할 수 있지만, M3 이후는 수개월 단위의 실무 작업입니다. 특히 M3의 데이터 수집(현장 설문조사나 실제 데이터 가공)이 가장 무겁습니다. 여기서 저는 주저했습니다.

역으로 말하면, M2까지만 진행해도 "정리된 제안"으로서 충분히 사용할 수 있다는 뜻이기도 했습니다. 이는 PoC(Proof of Concept)에서 타당성을 확인한 단계와, 실제 투입 가능한 품질까지 만들어낸 단계의 차이와 비슷하다고 생각합니다.

여기서 가장 중요한 결론에 도달했습니다. M0부터 M6까지 전부 하는 것이 "정답"은 아니다라는 점입니다.

평소에 하는 "음성을 던져 논문 형식으로 정리하는" 방식은 M3 이후를 건너갈 필요가 없습니다. 목적이 "자신의 머릿속을 정리하는 것" 혹은 "상대방에게 괜찮아 보이게 만드는 것"이라면, M0~M2의 논리와 납득감만으로도 충분하기 때문입니다. 반대로, 새로운 사실로서 세상에 던지려 한다면 M6까지 건너가지 않으면 의미가 없습니다.

결국, 필요한 품질은 목적에 따라 달라집니다. 이를 목적에 맞춰 다시 맞춤 제작하는 것을 여기서는 **테일러링 (Tailoring)**이라고 부릅니다.

목적	어디까지 맞춤 제작할 것인가	과부족
자신의 생각 정리	M0~M2	M3 이후는 완전히 과잉
...

사내 제안에 심사(Peer Review) 수준의 실증을 가져오는 것은 과잉 품질입니다. 반대로, 세상에 내놓을 논문을 납득감만으로 통과시키려 한다면 그것은 태만입니다. 같은 '논문 형식의 문장'이라도 어디까지 맞춤 제작할지는 상황마다 다릅니다. PoC(Proof of Concept)에 갑자기 본 서비스 수준의 SLA (Service Level Agreement)를 요구하지 않는 것과 같은 맥락입니다. 그리고 맞춤 제작의 규모를 잘못 설정한 채 달리면, 과잉일 경우 '시간'이라는 기술적 부채를, 과소일 경우 '신뢰'라는 부채를 떠안게 됩니다.

제가 했어야 했던 일은 "논문으로 만들 수 있을까?"라고 의욕을 앞세우는 것이 아니라, 목적에 대해 어디까지 맞춤 제작할지를 처음에 결정하는 것이었습니다. 맞춤 제작의 규모를 잘못 잡았기 때문에 손이 멈췄던 것입니다.

마지막으로 한 가지. 저는 논문을 써본 적은 없지만, 비평문이나 화이트 페이퍼(White Paper), 논문 종류는 많이 읽어왔습니다. 이것이 생각보다 효과가 있었습니다.

많이 읽다 보면 적어도 "형식에서 벗어났을 때의 위화감"은 알아챌 수 있습니다. 서론에서 무엇을 말하고, 본론에서 어떻게 쌓아 올리며, 결론에서 어떻게 마무리하는가. 그 흐름을 따르지 않는 문장은 이유를 언어화하지 못하더라도 "뭔가 이상하다"며 걸리게 됩니다.

AI에게 "논문 형식으로 정리해줘"라고 부탁해서 나온 결과물을 "이 부분은 약하다"라고 수정할 수 있었던 것도 이 위화감 덕분이었습니다. 좋은 코드를 많이 읽은 사람일수록 리뷰에서 위화감을 알아챌 수 있는 것과 비슷한 감각이라고 생각합니다. 쓸 수 있는 것과 좋고 나쁨을 알아챌 수 있는 것은 별개이며, 후자만으로도 충분히 활용할 수 있었습니다.

• "보이스(Voice)를 던져 논문 형식으로 정리하는 것"은 ADR (Architecture Decision Record)을 작성하는 감각에 가까운 우수한 사고 정리 도구입니다.
• 단, "논문 형식의 문장"과 "진짜 학술 논문" 사이에는 **실증의 골짜기 (Valley of Demonstration)**가 있습니다. 골짜기의 정체는 M3(데이터 준비) 이후의 수개월 단위의 실무 작업입니다.
• 모든 공정을 수행하는 것이 정답이 아니라, 품질은 목적에 맞춰 맞춤 제작(테일러링)하는 것이 본질입니다.
• 사내 제안에 심사 수준의 실증은 과잉이며, 세상에 내놓을 논문을 납득감만으로 통과시키는 것은 태만입니다.
• PoC에 SLA를 요구하지 않는 것과 마찬가지로, 맞춤 제작 규모를 잘못 설정하면 시간 혹은 신뢰의 부채가 됩니다.
• 중요한 것은 "논문으로 만들 수 있는가"가 아니라 "목적에 대해 어디까지 맞춤 제작할 것인가"를 처음에 결정하는 것입니다.