생각까치 | AI IT Repository

AI로 죽은 사람과 다시 대화할 수 있을까?｜그리프봇과 디지털 불멸

zeucise — Fri, 2 Oct 2026 14:43:24 +0900

고인의 사진·음성·메시지 데이터를 바탕으로 AI와 다시 대화하는 그리프봇 개념 이미지

사랑하는 사람이 세상을 떠난 뒤에도 다시 대화할 수 있다면 어떨까?

사진을 보고, 목소리를 듣는 것에서 끝나는 것이 아니라 내가 말을 걸면 그 사람이 생전에 사용하던 말투로 대답해주는 것이다.

몇 년 전까지만 해도 영화에서나 볼 것 같은 이야기였다.

그런데 생성형 AI가 빠르게 발전하면서 이제는 완전히 허무맹랑한 이야기도 아니게 됐다.

사람이 남긴 문자와 이메일, SNS 글, 사진, 음성 같은 데이터를 바탕으로 고인의 말투와 목소리, 행동 패턴을 모방하는 AI를 만들 수 있기 때문이다.

이런 기술을 Griefbot(그리프봇), Deathbot, 또는 조금 넓은 의미에서 Digital Afterlife(디지털 사후세계)라고 부른다. 최근 연구에서도 그리프봇은 고인의 기록을 바탕으로 말투와 행동을 모방하고, 남아 있는 사람이 다시 대화하는 경험을 제공하는 AI 시스템으로 다뤄지고 있다.

기술적으로는 흥미롭다.

그런데 생각해보면 조금 이상한 질문이 남는다.

그 AI와 이야기하고 있는 나는 정말 그 사람과 대화하고 있는 걸까?

우리는 이미 비슷한 장면을 본 적이 있다

2020년 MBC에서 방송한 《너를 만났다》를 기억하는 사람이 있을 것이다.

세상을 떠난 일곱 살 딸 나연이를 VR로 구현해 어머니가 다시 만나는 과정을 담은 다큐멘터리였다.

당시 방송은 큰 관심을 받았다. VR 속에서 딸의 모습을 보고, 목소리를 듣고, 짧게 대화를 나누는 장면은 기술을 소개하는 것을 넘어 ‘다시 한번 만나고 싶다’는 인간의 감정을 직접 보여줬다.

MBC도 이 프로그램을 VR과 인공지능, 실감 콘텐츠를 이용해 기억 속 만나고 싶은 사람을 구현하고, 기술이 인간의 마음에 어디까지 닿을 수 있는지 살펴보는 프로젝트로 소개했다

다만 당시의 기술과 지금의 생성형 AI는 조금 다르다.

지금의 생성형 AI는 사용자가 어떤 말을 하느냐에 따라 새로운 답을 만들어낼 수 있다.

여기에 고인이 남긴 대화 기록과 음성, 영상까지 결합하면 과거보다 훨씬 자연스러운 디지털 모습을 만들 수 있다.

그래서 이제 질문은 “죽은 사람을 디지털로 구현할 수 있을까?” 에서 조금씩 “그렇게 만들어진 존재를 우리는 어떻게 받아들여야 할까?” 로 바뀌고 있다.

그리프봇은 어떻게 만들어질까?

생각보다 원리는 어렵지 않다. 우리는 평생 많은 데이터를 남긴다.

카카오톡이나 문자, 이메일, SNS 글, 사진, 영상, 음성 녹음, 온라인 활동 기록 등이 있다.

이런 데이터를 이용하면 AI는 한 사람이 자주 사용했던 표현이나 말투, 관심사 등을 어느 정도 모방할 수 있다.

그리프봇이 고인의 문자·음성·사진·영상 기록을 분석해 대화형 AI로 구현되는 과정을 설명하는 이미지

음성 생성 기술을 결합하면 목소리도 비슷하게 만들 수 있다.

간단하게 정리하면 이런 형태다.

생전의 디지털 기록
↓
AI가 말투·목소리·행동 패턴 분석
↓
고인을 닮은 AI 생성
↓
사용자가 AI와 대화

하지만 여기서 반드시 구분해야 하는 것이 있다.

이 AI가 고인의 데이터를 사용한다고 해서 고인의 의식이 AI 안에서 다시 살아나는 것은 아니다.

현재의 그리프봇은 남겨진 데이터를 바탕으로 그 사람과 비슷하게 반응하도록 만든 시뮬레이션에 가깝다.

즉, 그 사람의 기억과 표현을 모방할 수는 있어도 그 사람 자체가 다시 돌아오는 것은 아니다.

그런데 사람이 느끼는 감정은 그렇게 간단하지 않을 수 있다.

“그 사람처럼 말한다” 와 “그 사람이다” 는 같은 말일까?

예를 들어 아버지가 생전에 이런 말을 자주 했다고 해보자.

“너무 걱정하지 마. 어떻게든 되겠지.”

아버지가 돌아가신 뒤 문자와 음성 기록을 학습한 AI가 있다고 해보자.

그리고 힘든 일이 생겼을 때 그 AI에게 말한다.

“아빠, 요즘 일이 너무 힘들어.”

AI가 대답한다.

“너무 걱정하지 마. 어떻게든 될 거야.”

순간에는 정말 아버지와 이야기하는 것처럼 느껴질 수도 있다.

그런데 여기서 조금 이상한 문제가 생긴다.

이 문장은 아버지가 실제로 한 말일까?

아니다. 아버지의 과거 데이터를 이용해 AI가 새롭게 만든 문장이다.

그렇다면 이 대화는 아버지와의 새로운 추억일까?

아니면 AI와 만든 새로운 기억일까?

개인적으로는 여기서 몇 가지 질문이 필요하다고 생각한다.

이것을 잠시라도 '그 사람' 이라고 느낄 수 있는가? 아니면 그래도 AI로 느끼는가?
만약에 느낀다면 사람을 사람답게 만드는것이 단순히 기억과 말투의 집합인가?
또한, 생성형 AI가 그 사람이 실제로 하지 않았던 말들도 만들어 내는 순간에는 어떻게 느낄 것인가?

AI는 기억을 보존하는 것일까, 새로운 기억을 만드는 것일까?

사진이나 영상은 과거의 순간을 기록한다.

아버지와 찍은 사진을 보면 그날의 기억을 떠올릴 수 있다.

하지만 그리프봇은 조금 다르다.

과거를 보여주는 것이 아니라 새로운 대화를 만들어낸다.

오늘 대화할 수도 있고, 내일 다시 이야기할 수도 있다.

몇 년 동안 계속 새로운 말을 들을 수도 있다.

그렇게 되면 어느 순간 실제로 그 사람과 나눈 대화와 AI가 만들어낸 대화를 얼마나 명확하게 구분할 수 있을까?

그리프봇에 관한 최근 연구에서도 고인의 성격이나 가치가 왜곡될 가능성, 그리고 실제 기억과 AI가 새롭게 만든 표현 사이의 경계 문제가 제기되고 있다.

결국 AI는 기억을 보존하는 도구이면서 동시에 존재하지 않았던 새로운 기억을 만들어낼 수도 있는 도구가 된다.

개인적으로는 사진이나 영상과 그리프봇의 가장 큰 차이가 여기에 있다고 생각한다.

사진은 이미 있었던 순간을 다시 보여준다.

하지만 그리프봇은 없었던 순간을 새롭게 만든다.

그래서 아무리 위로가 된다고 해도 이 둘을 같은 ‘기억’이라고 부를 수 있는지는 조금 고민스럽다.

기존의 함께 했던 기억과 생성된 기억에는 차이가 있다.

그래도 위로가 된다면 괜찮은 것 아닐까?

여기서 가장 어려운 질문이 나온다.

사랑하는 사람을 잃은 사람에게 그리프봇이 실제로 위로가 된다면 사용해도 괜찮지 않을까?

2026년 공개된 한 연구에서는 25명을 인터뷰해 그리프봇에 대한 사람들의 생각을 조사했다.

참여자들은 정서적 위로, 고인과의 연결감, 하지 못했던 말을 전달할 기회 등을 장점으로 꼽았다.

하지만 같은 사람들이 동시에 애도 과정의 방해, AI에 대한 의존, 심리적 피해, 고인의 왜곡, 개인정보 문제 등을 걱정했다.

흥미로운 점은 사람들이 명확하게 ‘좋다’ 또는 ‘나쁘다’ 로 나뉘지 않았다는 것이다.

상황에 따라 도움이 될 수도 있고 위험할 수도 있다고 봤다.

어쩌면 그리프봇의 가장 큰 특징도 여기에 있는 것 같다.

사람에게 위로를 줄 수 있는 바로 그 능력이 사람을 AI에 의존하게 만들 수도 있다.

보내주는 것도 애도의 일부라면?

사랑하는 사람이 죽었을 때 우리는 그 사람을 완전히 잊지는 않는다.

사진을 보고, 함께 갔던 장소를 떠올리고, 가끔 그 사람이 했던 말을 생각한다.

하지만 시간이 지나면서 관계의 형태는 조금씩 달라진다.

실제로 대화하는 관계에서 기억 속에서 함께 살아가는 관계로 바뀐다.

그런데 AI가 계속 새로운 대화를 만들어준다면 어떻게 될까?

우리는 더 이상 그 사람과의 대화를 끝낼 필요가 없을 수도 있다.

개인적으로는 여기에서 조금 불편함을 느낀다.

큰 상처를 겪은 사람에게 그리프봇이 잠시 위로가 될 수 있다는 점은 충분히 이해한다.

하지만 언젠가는 그 사람을 기억 속에서 보내줘야 하는 시간도 필요하지 않을까.

어쩌면 고인에게도, 남은 사람에게도 기억과 어느 정도 거리를 둘 수 있는 시간이 필요한 것은 아닐까.

사람을 기억하는 것과 사람을 보내주지 못하는 것은 어디에서 나뉘는지 쉽게 답하기 어려운 문제다.

고인은 AI로 만들어지는 것에 동의했을까?

또 하나의 문제가 있다.

죽은 사람은 자신의 AI 버전을 직접 결정하지 못할 수 있다.

예를 들어 내가 가지고 있는 가족의 사진, 카카오톡, 음성 녹음, 영상을 이용해 AI를 만들었다고 해보자.

기술적으로 만들 수 있다는 것과 만들어도 된다는 것은 다른 문제다.

그 사람이 살아 있었다면 자신의 말투와 목소리가 죽은 뒤에도 계속 새로운 말을 만들어내는 데 사용되는 것을 원했을까?

최근 그리프봇 연구에서도 고인의 동의, 사후 데이터 이용, 고인의 정체성을 어떻게 표현할 것인지가 중요한 윤리적 문제로 다뤄지고 있다.

AI 시대에는 어쩌면 유언장에 재산만 적는 것이 아니라

“내가 죽은 뒤 내 데이터를 AI로 만드는 것에 동의하는가?”

까지 적어야 하는 시대가 올지도 모른다.

죽은 뒤 내 데이터는 누구의 것일까?

이 질문을 본격적으로 다룬 책도 있다. Carl Öhman의《The Afterlife of Data: What Happens to Your Information When You Die and Why You Should Care》다.

이 책은 우리가 죽은 뒤 인터넷에 남은 데이터가 어떻게 되는지, 그리고 그 데이터를 이용해 우리의 디지털 정체성을 다시 만들어낼 수 있는 시대에 누가 그 데이터를 관리하고 결정해야 하는가를 다룬다.

Carl Öhman의 The Afterlife of Data 책 표지, 사후 디지털 데이터와 AI를 다룬 책

책에서 흥미로운 것은 개인의 추억만 이야기하지 않는다는 점이다.

우리가 남기는 디지털 기록은 시간이 지나면 개인의 데이터이면서 동시에 한 시대의 기록이 된다.

그런데 그 데이터가 특정 기업의 서버에 남아 있다면, 죽은 뒤에도 누군가는 그것을 보관하거나 삭제하거나 활용할 수 있다.

결국 질문은 “내가 죽으면 내 데이터도 죽는가?” 에서 “내가 죽은 뒤 내 데이터를 결정할 권리는 누구에게 있는가?” 로 바뀐다.

AI와 죽음의 문제는 생각보다 데이터의 소유뿐 아니라 사후 데이터에 대한 결정권 문제와도 깊게 연결되어 있다.

결국 우리는 누구와 대화하고 있는 걸까?

처음에는 기술에 대한 질문으로 시작했다.

AI로 죽은 사람과 다시 대화할 수 있을까?

기술만 보면 어느 정도 가능해지고 있다.

말투를 흉내 내고, 목소리를 재현하고, 그 사람이 남긴 기록을 이용해 새로운 답을 만들어낼 수 있다.

하지만 조금 더 생각하면 질문이 달라진다.

그렇게 만들어진 존재가 정말 그 사람일까?

아마 아닐 것이다.

그렇다고 아무 의미가 없는 것도 아닐 수 있다.

남겨진 사람이 그 대화를 통해 위로받을 수도 있고, 하지 못했던 말을 해볼 수도 있다.

문제는 우리가 그 존재를 무엇이라고 생각하느냐에 있는 것 같다.

고인을 다시 만들어낸 사람으로 볼 것인지, 고인에 대한 기억을 돕는 하나의 도구로 볼 것인지.

둘은 비슷해 보이지만 꽤 큰 차이가 있다.

생성형 AI는 학습된 기억과 말투로 그 사람이 생전에 하지 않았던 말들도 학습된 LLM에서 답변을 만들어서 답변을 할 것이다. 어떻게 보면, 이건 없는 기억이 생성되기 때문에 "고인에 대한 예의가 아니지 않을까?" 라는 개인적인 의견이다.

개인적으로는 그리프봇을 실제 고인을 대신하는 존재로 받아들이는 것에는 조금 조심스러운 입장이다.

생성형 AI는 고인이 남긴 기억과 말투를 참고해 그 사람이 생전에 한 적 없는 새로운 말까지 만들어낼 수 있기 때문이다.

처음에는 위로를 위한 대화였더라도 시간이 지나면 실제로 존재하지 않았던 대화와 기억이 계속 쌓일 수 있다.

그렇다면 그것은 고인을 기억하는 것일까?

아니면 남아 있는 사람이 원하는 모습으로 고인을 새롭게 만들어가는 것일까?

이런 의미에서는 오히려 고인에 대한 예의가 아닐 수도 있겠다는 생각이 든다.

사람을 사람답게 만드는 것은 무엇일까?

목소리일까? 말투일까? 기억일까? 아니면 함께 시간을 보내면서 만들어온 관계일까?

어쩌면 AI가 죽은 사람을 얼마나 비슷하게 만들 수 있는지를 보는 것보다,

우리가 왜 그 사람을 다시 만나고 싶은지를 생각하는 것이 더 중요한 질문인지도 모르겠다.

참고 자료

AI가 만든 결과를 어디까지 믿고 판단을 맡길 수 있을지 궁금하다면 이전 글 AI는 미래를 예측할 수 있을까?｜《AI Snake Oil》로 보는 예측 AI의 한계 도 함께 보면 좋다.

참고 자료

Carl Öhman, 《The Afterlife of Data: What Happens to Your Information When You Die and Why You Should Care》
MBC, 《너를 만났다》
Lu et al. (2026), Exploring public perceptions of artificial intelligence in bereavement support: a qualitative study of griefbots
Manevich & Haber (2026), Non-death loss and GenAI: ethical reflections on griefbots of the living

생각까치 소개｜AI와 IT를 직접 써보고 정리합니다

zeucise — Tue, 29 Sep 2026 15:51:40 +0900

안녕하세요. 생각까치를 운영하는 zeucise입니다.

금융회사에서 IT와 정보보호 업무를 하고 있는 평범한 직장인 입니다.

AI와 IT 도구를 업무와 일상에서 어떻게 활용할 수 있을지 살펴보고, 사용하면서 알게 된 점을 기록하는 개인 블로그입니다.

새로운 기술을 접하면 신기하기도 하지만, 막상 사용하려고 하면 어디서 시작해야 할지 막힐 때가 있습니다.

이곳에서는 그 과정에서 생기는 질문과 어려움을 하나씩 풀어보려고 합니다.

생각까치를 시작한 이유

대학원에 다닐 때부터 AI가 이미지를 인식하고 새로운 그림을 만들어내는 기술에 관심이 있었습니다.

이후 여러 AI 도구를 사용하면서 보고서를 작성하고, 코딩을 시도하고, 이미지를 만들어보게 됐습니다.

직접 써보니 설명만 읽었을 때와는 다른 점이 많았습니다.

간단해 보였던 설정에서 막히기도 하고, 그럴듯한 답변을 실제 자료와 비교하며 다시 고쳐야 할 때도 있었습니다.

그렇게 배운 내용을 정리해두면 저에게도 도움이 되고, 비슷한 문제를 겪는 분들의 시행착오도 줄일 수 있겠다고 생각했습니다.

이런 내용을 다룹니다

AI 업무 활용: 보고서 작성과 검토, 질문하는 방법, 복사해서 활용할 수 있는 프롬프트를 정리합니다.
코딩과 도구 사용: Codex, GitHub, ComfyUI, Obsidian 등을 사용하며 익힌 과정과 막혔던 부분을 기록합니다.
AI 논문과 책 읽기: 흥미로운 연구와 책을 읽고, 핵심 내용과 한계, 사용자의 입장에서 생각해볼 점을 풀어봅니다.

처음 사용하는 분도 따라 해볼 수 있도록 필요한 예시와 화면, 실행 방법을 함께 담으려고 합니다.

글을 작성할 때 중요하게 생각하는 것

직접 경험한 내용과 자료를 읽고 정리한 내용을 구분하겠습니다. 설명을 위해 만든 가상 사례도 실제 경험으로 오해하지 않도록 표시하겠습니다. 제품 기능이나 연구 결과를 소개할 때는 공식 문서와 논문 등 확인한 자료를 함께 안내하고, 자료에 나온 사실과 제 생각을 구분하겠습니다.

도구의 버전이나 사용 환경에 따라 결과가 달라질 수 있는 부분도 살펴보겠습니다. 글을 게시한 뒤 오류나 변경 사항을 확인하면 내용을 보완하겠습니다.

이 블로그가 AI와 IT를 써보려는 분들에게 작더라도 실제로 도움이 되는 공간이 되기를 바랍니다.

질문과 수정 의견

글을 따라 하다가 막힌 부분이나 잘못된 내용을 발견하셨다면 해당 글의 댓글로 알려주세요.

사용한 도구와 버전, 문제가 발생한 상황을 함께 적어주시면 내용을 확인하는 데 도움이 됩니다.

문의사항 : anjeonbubu@gmail.com

개인정보처리방침

생각까치는 블로그 이용 과정에서 처리될 수 있는 개인정보와 광고 쿠키에 대해 다음과 같이 안내합니다.

댓글과 이메일 문의

댓글 등 티스토리 서비스 이용 과정에서 플랫폼이 처리하는 개인정보는 카카오 개인정보처리방침을 따릅니다.

운영자에게 이메일로 문의하면 이메일 주소와 문의 내용이 전달됩니다. 해당 정보는 문의 응대에만 사용하며, 처리가 완료되어 보관할 필요가 없어지면 삭제합니다. 댓글이나 문의에는 주민등록번호, 비밀번호 등 민감한 정보를 적지 말아 주세요.

광고와 쿠키

이 블로그에는 Google 애드센스 광고가 게재될 수 있습니다. Google과 제3자 광고 파트너는 이용자의 이 블로그 및 다른 웹사이트 방문 기록을 바탕으로 광고를 제공하기 위해 쿠키를 사용할 수 있습니다. 광고 제공 과정에서 쿠키, IP 주소 등 식별자와 방문 정보가 수집·이용될 수 있습니다.

Google의 데이터 처리 방식은 Google의 파트너 사이트 및 앱 데이터 사용 안내에서 확인할 수 있습니다.

이용자는 Google 광고 설정에서 개인 맞춤 광고를 해제할 수 있으며, 제3자 광고업체의 맞춤 광고 쿠키 거부 방법은 이용자 선택 안내에서 확인할 수 있습니다. 브라우저 설정에서도 쿠키 저장을 제한하거나 기존 쿠키를 삭제할 수 있습니다.

문의 및 변경 안내

개인정보 관련 문의나 운영자가 보관한 문의 정보의 삭제 요청은 anjeonbubu@gmail.com으로 보내주세요.

처리 방식이 변경되면 이 페이지에 반영하겠습니다.

시행일: 2026년 9월 30일

OpenAI Codex 사용법 7편｜Plan Mode로 ComfyUI 프롬프트 생성기 설계하기

zeucise — Sat, 26 Sep 2026 22:11:55 +0900

OpenAI Codex Plan Mode로 ComfyUI 프롬프트 생성기 개발 계획을 설계하는 화면

대학원에 다닐 때부터 AI가 이미지를 인식하거나 새로운 그림을 만들어내는 기술이 신기했다.

특히 이미지를 단순히 그리는 것이 아니라, 확산(Diffusion) 과정을 통해 새로운 이미지를 생성한다는 점이 흥미로웠다.

그래서 Claude, ChatGPT, Midjourney 등 여러 AI 도구를 이용해 직접 이미지를 만들어보기도 했다.

그런데 계속 사용하다 보니 한 가지 아쉬운 점이 있었다. 이미지를 생성할 때마다 크레딧이나 사용량을 소모하기 때문에 마음에 드는 결과가 나올 때까지 마음껏 생성해보기는 어려웠다.

그래서 사용하기 시작한 것이 ComfyUI다. ComfyUI는 그래픽카드가 있는 PC라면 로컬에서 AI 모델을 실행해 이미지를 생성할 수 있다. 물론 사용하는 모델과 그래픽카드 성능에 따라 시간이 걸리지만, 생성할 때마다 별도의 크레딧을 신경 쓰지 않고 여러 번 테스트해볼 수 있다는 점이 마음에 들었다.

이제는 Workflow를 불러오고 모델을 선택해 이미지를 생성하는 과정 자체는 어느 정도 익숙해졌다.

그런데 다른 문제가 생겼다.

프롬프트였다.

머릿속에는 만들고 싶은 이미지가 어느 정도 그려져 있는데, 막상 그것을 프롬프트로 작성하려고 하면 생각보다 쉽지 않았다.

구도는 어떻게 할지, 조명은 어떤 느낌으로 할지, 어떤 분위기와 스타일을 넣을지 하나씩 고민하게 된다.

결과가 마음에 들지 않으면 다시 프롬프트를 수정하고, 또 이미지를 생성한다.

이 과정을 반복하다 보니 어느 순간 이런 생각이 들었다.

“이걸 AI가 좀 도와주면 안 될까?”

그래서 이번에는 ComfyUI에서 사용할 프롬프트를 만드는 과정을 Codex로 조금 더 편하게 만들어보려고 한다.

다만 바로 코딩부터 시작하지는 않을 생각이다.

먼저 Codex의 Plan Mode를 이용해 ComfyUI용 프롬프트 생성 프로그램을 어떻게 만들 것인지 개발 계획부터 세워보려고 한다.

ComfyUI를 처음 사용하는 사람이라면

나는 이미 ComfyUI를 설치해서 사용하고 있지만, 이번 글을 처음 보는 사람도 있을 수 있으니 설치 방법은 간단하게만 정리하려고 한다. Windows에서는 ComfyUI Portable을 사용하면 비교적 쉽게 시작할 수 있다.

※ ComfyUI Portable : Comfyui Portable 공식 다운로드 사이트

Portable 버전은 실행에 필요한 독립 Python 환경이 함께 포함되어 있기 때문에 Python 환경을 별도로 구성하는 과정을 줄일 수 있다. 공식 문서 기준으로 과정은 간단하다.

1. 자신의 GPU에 맞는 Portable 버전을 다운로드한다.

2. 압축을 해제한다.

3. GPU에 맞는 실행 파일을 실행한다.

NVIDIA GPU를 사용하는 경우에는 일반적으로 "run_nvidia_gpu.bat" 파일을 실행한다.

명령 프롬프트 창에서 필요한 항목이 로드된 뒤 브라우저에 ComfyUI 화면이 열린다.

ComfyUI Portable을 실행한 Windows 화면

그러면 정상적으로 사용할 수 있는 상태가 된 것이다.

설치 방법은 버전에 따라 달라질 수 있으므로 실제 설치를 진행한다면 ComfyUI Portable for Windows 공식 문서를 함께 확인하는 것을 추천한다.

이번 글에서는 설치보다 ComfyUI를 사용하면서 생긴 프롬프트 문제를 어떻게 해결할 것인가에 집중하려고 한다.

ComfyUI에서 이미지 한 장을 만들어보자

ComfyUI를 처음 접하면 화면에 연결된 여러 개의 사각형이 보인다.

각각을 Node라고 하고, Node를 연결한 전체 작업 구조를 Workflow라고 한다.

하지만 이번 글에서 Workflow 자체를 자세하게 다루지는 않는다.

이번 글에서 사용한 Z-Image-Turbo Workflow 기준으로는 다음 Node들을 연결해 사용했다.

Workflow는 아래의 그림을 참고하면 된다.

Z-Image-Turbo 모델을 연결한 ComfyUI Text-to-Image Workflow

※ 사용한 모델은

Load Diffusion Model : z_image_turbo_bf16.safetensors

Load CLIP(Text Encoder): qwen_3_4b.safetensors

Load VAE : ae.safetensors

그러면, Clip Text Encode에 프롬프트를 작성하면 된다.

예를 들어 아래의 이미지를 만들고 싶다고 생각해보자.

A small robot walking through a rainy Seoul alley at night,
holding a transparent umbrella,
neon signs reflected on the wet street,
cinematic photography,
soft atmospheric lighting

Z-Image-Turbo로 생성한 비 오는 서울 골목의 로봇 이미지

이제 위와 같이 그림을 생성해 낼 수 있다.

Z-Image-Turbo로 생성한 비 오는 서울 골목의 로봇 이미지 생성시간

내 PC 환경에서는 1024×1024 이미지 한 장이 약 13.74초에 생성됐다.

GPU : RTX5070TI 16G, RAM 32G

이제 그림을 생성할 수 있는 환경을 갖췄다.

ComfyUI에서 가장 고민됐던 것은 프롬프트였다

이미지 한 장을 생성하는 것은 어렵지 않다. 그런데, 그림을 생성하다가 보면, 한번에 원하는 그림을 얻기는 매우 어렵다.

그래서 원하는 이미지에 가까워지려면 프롬프트를 계속 바꾸게 된다.

예를 들어 처음에는:

비 오는 서울 골목에서
우산을 들고 걷는 작은 로봇

정도로 생각했다가 조금씩 조건을 붙이게 된다.

밤으로 만들자.

네온사인이 있으면 좋겠다.

카메라는 조금 낮게 잡자.

영화 같은 느낌이었으면 좋겠다.

젖은 도로에 빛이 반사되면 좋겠다.

프롬프트가 점점 길어진다. 그러다가 보면 두서없이 작성하게 되는 경우가 많아졌다.

그래서 프롬프트를 작성할 때 자주 사용하는 요소를 한번 나눠봤다.

Subject
→ 무엇을 그릴 것인가

Scene
→ 어디에서 어떤 상황인가

Composition
→ 화면을 어떻게 구성할 것인가

Lighting
→ 빛을 어떻게 표현할 것인가

Mood
→ 어떤 분위기로 만들 것인가

Style
→ 어떤 표현 방식으로 만들 것인가

물론 이미지 모델마다 효과적인 프롬프트 방식은 다를 수 있다.

그래도 막연한 이미지 아이디어를 몇 가지 요소로 나눠 생각하는 것 자체는 프롬프트를 만드는 데 도움이 된다.

그렇다면 이 과정을 프로그램으로 만들 수 있지 않을까?

Codex로 ComfyUI 프롬프트 생성기를 만들어보자

이번에 만들어볼 프로그램의 목표는 명확하다.

사용자가 원하는 이미지를 간단하게 설명하면 Prompt를 만들 때 필요한 요소를 정리하고 최종 Prompt를 만들어주는 프로그램

이름은 우선 ComfyUI Prompt Assistant 라고 정해봤다.

예를 들어 사용자가

비 오는 서울 골목에서
투명한 우산을 들고 걷는 작은 로봇을
영화처럼 만들고 싶어.

라고 입력한다고 해보자.

프로그램에서는 이를 다음과 같이 정리한다.

Subject
→ 작은 로봇

Scene
→ 비 오는 서울 골목

Composition
→ 골목을 걷는 장면

Lighting
→ 네온사인과 젖은 도로의 반사광

Mood
→ 조용하고 영화 같은 분위기

Style
→ Cinematic photography

그리고 마지막에는 하나의 Final Prompt 를 만들어 보여주는 것이다.

여기까지만 보면 프로그램은 간단해 보인다.

그런데 기능을 생각하기 시작하자 다시 일이 커지기 시작했다.

만들다 보면 금방 기능이 늘어난다

조금만 생각해도 추가하고 싶은 기능이 계속 나온다.

한국어로 입력하면 영어 Prompt로 만들어야 할까?

Negative Prompt도 만들어야 할까?

카메라 구도도 추천해줄까?

Prompt History도 저장할까?

마음에 드는 Prompt를 저장할까?

SDXL과 FLUX의 Prompt를 다르게 만들까?

ComfyUI에 바로 전송할까?

Workflow까지 실행할까?

하지만 처음부터 이것을 모두 개발하려고 하면 프로그램이 금방 복잡해진다.

이전에 CLAUDE.md 글에서 정리했던 AI에게 코딩을 맡겼더니 일이 커지는 상황과 비슷하다.

AI에게 코딩을 맡겼더니 일이 커진다면? CLAUDE.md의 4가지 원칙

지난 6편에서 AGENTS.md에도 그래서 다음과 같은 원칙을 넣었다.

Think Before Coding

Keep It Simple

Make Focused Changes

Verify the Result

이번에는 이 규칙을 실제 프로젝트에 적용해보기로 했다.

바로 코딩하지 않고 먼저 계획부터 세우는 것이다.

Codex에게 개발 Plan을 요청해보자

이제 Codex에서 Plan Mode를 사용한다.

/plan

그리고 다음과 같이 요청한다.

ComfyUI에서 사용할 이미지 프롬프트를
쉽게 만드는 프로그램을 개발하려고 해.

프로젝트 이름은
ComfyUI Prompt Assistant로 생각하고 있어.

목표:
사용자가 만들고 싶은 이미지 아이디어를 입력하면
이미지 프롬프트를 만들 때 필요한 요소를 정리하고
최종 Prompt를 보여주는 프로그램을 만든다.

첫 번째 버전에 필요한 기능:

- 이미지 아이디어 입력
- Subject 정리
- Scene 정리
- Composition 정리
- Lighting 정리
- Mood 정리
- Style 정리
- 최종 Prompt 확인
- 결과를 클립보드에 복사

이번 버전에서 제외할 기능:

- ComfyUI API 연결
- MCP
- Workflow 실행
- 이미지 생성
- Prompt History
- 모델별 Prompt 최적화

기존 AGENTS.md 규칙을 따라줘.

아직 코드는 작성하지 마.

먼저 현재 요구사항을 분석하고

1. 필요한 기능
2. 프로그램 구조
3. 필요한 파일
4. 구현 순서
5. 테스트 방법

을 포함한 개발 계획만 작성해줘.

여기서 가장 중요한 문장은 "아직 코드는 작성하지 마" 이다.

이번 단계의 목적은 프로그램을 만드는 것이 아니라 Codex가 어떤 프로그램을 만들려고 하는지 먼저 확인하는 것이다.

OpenAI Codex Plan Mode로 ComfyUI Prompt Assistant 개발 계획을 요청한 화면

그런데 프롬프트 생성에는 AI가 필요하다

여기에서 한 가지 문제가 남는다.

Python 프로그램을 만든다고 해서

비 오는 서울 골목에서
우산을 든 작은 로봇을
영화처럼 만들고 싶어.

라는 문장을 스스로 이해해서 좋은 Prompt로 바꿔주는 것은 아니다.

이 과정에는 결국 AI가 필요하다.

그래서 이번 프로그램은 한 번에 완성하지 않고 단계적으로 발전시키려고 한다.

1단계 : ComfyUI Prompt Assistant(기본 프로그램 개발)

↓

2단계 : Codex Skills(Prompt를 만드는 방법을 규칙화)

↓

3단계 : MCP(Codex와 ComfyUI 연결)

↓

4단계 : Codex가 만든 Prompt를 ComfyUI에 전달

↓

5단계 : Workflow 실행

↓

6단계 : 이미지 생성

이제 앞으로 Codex Skills와 MCP를 배우는 이유도 생긴다.

기능을 배우기 위해 기능을 배우는 것이 아니라 실제로 불편했던 문제를 하나씩 해결하면서 필요한 기능을 추가하는 방식이다.

다음에는 Plan을 실제 프로그램으로 만들어보자

이번 글에서 중요한 것은 ComfyUI 설치 방법이 아니다.

내가 ComfyUI를 사용하면서 불편하게 느꼈던 것은 매번 이미지 Prompt를 고민하고 다시 수정하는 과정이었다.

그래서 이번에는 바로 프로그램을 만들지 않고 계획만 잡았다.

문제 발견
↓
필요한 기능 정리
↓
필요 없는 기능 제외
↓
Codex Plan 작성
↓
사람이 Plan 확인

다음 글에서는 이번에 확정한 Plan을 그대로 이용해서 ComfyUI Prompt Assistant의 첫 번째 버전을 실제로 만들어볼 예정이다.

그리고 이후에는 이 프로그램을 조금씩 발전시킨다.

최종 목표는 Codex가 만든 프롬프트를 ComfyUI에 전달해 이미지 생성까지 연결하는 것이다.

ComfyUI를 쓰면서 매번 고민했던 Prompt 작성 과정을 어디까지 줄일 수 있을지 직접 만들어보려고 한다.

OpenAI Codex 사용법 6편｜AGENTS.md로 프로젝트 규칙 설정하는 방법

zeucise — Thu, 17 Sep 2026 23:32:24 +0900

OpenAI Codex에서 AGENTS.md로 프로젝트 규칙을 설정하고 반복 작업 지침을 관리하는 방법

Codex를 계속 사용하다 보니 비슷한 내용을 반복해서 입력하고 있었다.

기존 기능은 최대한 유지해줘.

요청하지 않은 부분은 수정하지 마.

수정한 뒤 테스트를 실행해줘.

사용 방법이 바뀌면 README.md도 수정해줘.

한두 번은 괜찮지만 같은 프로젝트를 계속 수정한다면 꽤 번거롭다.

예전에 비슷한 고민을 하면서 CLAUDE.md의 4가지 원칙을 정리한 적이 있다.

당시에는 Claude Code를 중심으로 설명했지만 핵심은 특정 AI에만 적용되는 내용은 아니었다.

AI에게 코딩을 맡길 때 어떤 방식으로 작업해야 하는지 미리 알려주는 것이 중요했다.

Codex에서도 비슷한 역할을 하는 파일이 있다.

바로 AGENTS.md다.

이번에는 이전에 정리했던 네 가지 원칙을 Codex의 AGENTS.md에 직접 적용해보려고 한다.

AGENTS.md는 무엇일까?

AGENTS.md는 Codex가 프로젝트에서 작업할 때 참고하는 지침 파일이다.

README.md
→ 사람이 프로젝트를 이해하기 위한 문서

AGENTS.md
→ AI Agent가 프로젝트에서 작업하기 위한 문서

README.md는 사용자가 알아야 할 설치 방법이나 프로그램 사용법 등을 작성한다.

반면, AGENTS.md에는 이런 내용을 넣을 수 있다.

기존 기능은 최대한 유지한다.

관련 없는 코드는 수정하지 않는다.

코드를 수정한 뒤 테스트를 실행한다.

사용 방법이 변경되면 README.md도 수정한다.

즉, 매번 프롬프트에 반복해서 적던 프로젝트의 기본 규칙을 따로 저장해두는 것이다.

프롬프트와 AGENTS.md는 무엇이 다를까?

처음에는 둘의 차이가 조금 헷갈릴 수 있다.

나는 이렇게 구분하면 가장 이해하기 쉬웠다.

구분	역할
AGENTS.md	프로젝트에서 계속 지켜야 하는 규칙
프롬프트	지금 해야 하는 작업

예를 들어 AGENTS.md에 "코드를 수정한 뒤 테스트를 실행한다." 라고 적어두었다면,

실제 프롬프트에서는 "전체 파일 개수와 함께 파일 크기도 표시하도록 수정해줘." 라고만 요청할 수 있다.

매번 테스트해줘, 기존 기능을 유지해줘 같은 말을 반복하지 않아도 되는 것이다.

CLAUDE.md에서 사용했던 4가지 원칙을 가져와보자

예전 글에서는 AI 코딩을 맡길 때 네 가지 원칙을 정리했다.

1. 코딩하기 전에 생각한다.
2. 가장 단순한 방법을 선택한다.
3. 요청받은 부분만 수정한다.
4. 성공 조건을 확인하고 끝낸다.

이 원칙들은 그대로 AGENTS.md에도 적용할 수 있다.

기존 원칙	AGENTS.md에서는
코딩 전에 생각하기	모호한 요구사항을 임의로 추측하지 않는다
단순하게 만들기	필요 없는 기능이나 구조를 추가하지 않는다
필요한 곳만 수정	관련 없는 코드와 파일을 수정하지 않는다
성공조건으로 끝내기	수정 후 테스트를 실행하고 결과를 확인한다

특히 지난 5편에서 Diff를 확인했던 이유도 세 번째 원칙과 연결된다.

☞ 이전 글 : OpenAI Codex 사용법 5편｜AI가 수정한 코드를 확인하는 방법

AI가 요청하지 않은 코드까지 수정했다면 Diff에서 확인할 수 있다.

이번에는 그보다 한 단계 앞에서 애초에 작업 규칙을 알려주는 것이다.

이제 프로젝트에 AGENTS.md를 만들어보자

이번에도 지금까지 사용했던 codex-file-analyzer 프로젝트를 그대로 사용한다.

현재 구조는 다음과 같다.

지금까지 사용했던 codex-file-analyzer의 파일 구조

프로젝트 폴더에서 Codex를 실행한다.

cd C:\GitHub\codex-file-analyzer\
codex

Codex CLI 실행한 화면

그리고 다음 명령을 입력한다.

/init

/init 명령어를 실행한 화면

Codex CLI에서 /init을 실행하면 현재 프로젝트용 AGENTS.md 기본 구조를 생성할 수 있다.

실행이 끝나면 프로젝트 폴더에 AGENTS.md 파일이 생성된 것을 확인할 수 있다.

AGENT.MD 파일이 생성된 것을 확인할 수 있다.

우리 프로젝트에 맞는 AGENTS.md를 작성해보자

자동으로 만들어진 내용을 그대로 사용하는 것보다 현재 프로젝트에 맞는 규칙을 직접 정리하는 것이 좋다.

이번에는 앞에서 이야기한 네 가지 원칙을 기준으로 작성했다.

길어 보이지만 내용 자체는 단순하다.

중요한 것은 규칙을 많이 만드는 것이 아니라 Codex가 반복해서 지켜야 할 내용만 남기는 것이다

# Project Rules

## Think Before Coding
- 요구사항이 모호하면 임의로 추측하지 않는다.
- 여러 방법이 있다면 가장 단순한 방법을 먼저 검토한다.

## Keep It Simple
- 요청하지 않은 기능을 추가하지 않는다.
- 필요하지 않은 구조나 추상화를 만들지 않는다.
- Python 기본 라이브러리를 우선 사용한다.

## Make Focused Changes
- 요청과 관련된 코드만 수정한다.
- 관련 없는 코드나 파일은 정리하지 않는다.
- 기존 기능은 최대한 유지한다.

## Verify the Result
- 코드를 수정한 뒤 테스트를 실행한다.
- 테스트가 실패하면 작업이 완료됐다고 보고하지 않는다.
- 프로그램 사용 방법이 변경되면 README.md도 수정한다.

## Safety
- 사용자 파일을 삭제하거나 이동하지 않는다.

AGENTS.md를 메모장이나 VS Code 같은 텍스트 편집기로 열고 위 내용을 붙여넣어 저장한다.

그럼 작성은 끝난다.

AGENTS.md가 제대로 적용됐는지 확인해보자

파일을 작성한 뒤 Codex에 다음과 같이 물어봤다.

현재 프로젝트에서 작업할 때
따라야 하는 규칙을 정리해줘.

앞에서 작성한 기존 기능 유지, 관련 없는 코드 수정 금지, 테스트 실행 등의 내용이 답변에 포함되는지 확인한다.

단순히 파일을 만드는 것보다 실제로 Codex가 프로젝트 규칙을 인식하고 있는지 한 번 확인해두는 것이 좋다.

Codex가 프로젝트 규칙을 인식하고 있는지 한 번 확인

AGENTS.md를 만들면 무조건 지킬까?

위에 내용대로 AGENTS.md 작성을 해서 실행을 시키면 Codex는 무조건 내용을 지키면서 실행을 할까?

아쉽지만, 그렇지는 않다.

AGENTS.md는 Codex에게 제공하는 작업 지침이다. 파일에 적어두었다고 해서 모든 지시가 항상 완벽하게 지켜지는 것은 아니다.

그래서 AGENTS.md가 있어도 테스트와 Diff 확인은 여전히 필요하다.

AGENTS.md
→ 어떻게 작업할지 알려준다

Test
→ 실제로 동작하는지 확인한다

Diff
→ 무엇을 변경했는지 확인한다

Review
→ 변경된 코드에 문제가 없는지 검토한다

AGENTS.md가 Git이나 테스트를 대신하는 것이 아니다.

오히려 지금까지 사용했던 개발 과정 앞에 작업 기준을 하나 추가하는 것에 가깝다.

AGENTS.md는 언제 유용할까?

간단한 코드 한 번 만드는 데 반드시 필요한 것은 아니다.

하지만, 지금까지 만든 codex-file-analyzer처럼 하나의 프로그램을 계속 발전시키는 경우라면 특히 잘 맞는다.

특히 같은 프로젝트에서 코딩 방식, 테스트 방법, 수정 범위처럼 반복해서 지켜야 할 규칙이 있을 때 유용하다.

반대로 프로젝트가 바뀌면 필요한 규칙도 달라질 수 있다.

다른 프로젝트에 기존 AGENTS.md를 그대로 복사하기보다 해당 프로젝트에 맞게 수정해서 사용하는 것이 좋다.

CLAUDE.md와 AGENTS.md에서 중요한 것은 결국 같다

Claude Code에서는 CLAUDE.md, Codex에서는 AGENTS.md라는 이름을 쓴다.

파일 이름과 동작 방식에는 차이가 있지만, AI에게 프로젝트의 작업 기준을 전달한다는 목적은 비슷하다.

AI가 코딩을 잘하도록 만드는 것보다, 어떻게 일해야 하는지를 미리 알려주는 것이다.

그리고 앞으로 프로젝트가 커지면 역할은 조금씩 나뉘게 된다.

AGENTS.md
→ 프로젝트에서 항상 지켜야 할 규칙

Skills
→ 반복해서 사용하는 작업 방법

MCP
→ Codex와 외부 프로그램 연결

지금은 AGENTS.md만 사용하지만 이후에는 이 구조를 하나씩 연결해볼 예정이다.

다음에는 코딩하기 전에 계획부터 세워보자

지금까지는 비교적 작은 기능을 바로 수정했다.

하지만 프로그램이 커지면 바로 코딩부터 시작하는 것이 항상 좋은 방법은 아니다.

같은 기능이 여러 개 들어간다면 먼저 어떤 구조로 만들지 생각해야 한다.

다음 글에서는 Codex에게 바로 코드를 작성시키기 전에 먼저 작업 계획을 세우는 방법을 알아보려고 한다.

그 다음에는 실제 프로그램을 하나 개발해 보고, 이후 Skills와 MCP를 거쳐 Codex와 ComfyUI까지 연결해볼 예정이다.

실제로 연결하여, 원하는 그림을 생성해보려고 한다.

AI는 정말 창의적일까?｜사람보다 새로운 방법을 찾았지만 성능은 낮았다

zeucise — Wed, 16 Sep 2026 13:35:08 +0900

AI가 많은 새로운 아이디어를 만들지만 좋은 방법을 선택하는 것이 더 중요

AI를 사용하다 보면 가끔 놀랄 때가 있다.

문제해결을 위한 아이디어를 몇 개만 달라고 했는데 생각하지 못했던 답을 내놓기도 하고,

같은 문제를 전혀 다른 방식으로 풀기도 한다.

이젠 AI도 창의적이라고 할 수 있는 걸까?

예전에는 AI가 기존 데이터를 조합해서 답을 만드는 것이라고 생각했다. 그런데 최근에는 AI는 직접 문제를 분석하고, 코드를 만들고, 실험하고, 결과를 보고 다시 방법을 수정하는 단계까지 발전하고 있다.

그렇다면 이제 AI가 정말 새로운 것을 만들어낸다고 말할 수 있을까?

이 질문을 직접 실험한 논문이 있다.

"Can LLM Agents Discover? Evaluating Creativity on ML Engineering Tasks"

2026년 8월 공개된 논문으로, AI Agent가 머신러닝 문제를 해결하는 과정에서 얼마나 새로운 아이디어를 만들고, 그 아이디어가 실제로 얼마나 유용한지를 평가했다. 이번 연구는 소설이나 그림 같은 일반적인 창작 활동이 아니라 머신러닝 문제 해결 과정에서의 창의성만을 평가했다. 코드가 실제로 실행되는지, 성능이 좋아졌는지를 함께 측정할 수 있기 때문이다.

논문에서는 AI는 생각보다 새로운 방법을 잘 찾아냈다고 한다.

하지만, 문제는 그다음이었다.

새로운 방법을 찾는 것과 좋은 방법을 찾는 것은 같은 일이 아니었다.

창의적이라는 것은 단순히 ‘새로운 것’ 일까?

우리는 흔히 남들과 다른 생각을 하면 창의적이라고 말한다.

하지만 논문에서는 창의성을 조금 다르게 본다.

단순히 새롭기만 해서는 부족하다. 새로움(Novelty)과 유용성(Usefulness)이 모두 있어야 한다는 것이다.

예를 들어 보자.

아무도 시도하지 않았던 새로운 다리 설계 방법을 만들었다.

굉장히 새로운 아이디어다. 그런데 실제로 만들어보니 무너진다.

그렇다면 새로운 아이디어라고는 할 수 있지만 좋은 설계라고 하기는 어렵다.

AI도 마찬가지다.

새로운 방법을 생각했다
        ↓
실제로 구현할 수 있는가?
        ↓
기존 방법보다 결과가 좋아졌는가?

여기까지 가야 실제로 의미 있는 발견이라고 볼 수 있다.

그래서 논문은 AI의 창의성을 새로운 생각을 만드는 능력과 실제 성능을 높이는 능력으로 나눠서 살펴본다.

AI가 자기 생각을 반복하는지도 확인했다 — P-Creativity

연구진은 창의성을 조금 더 세분화했다.

먼저 P-Creativity라는 개념을 사용한다.

쉽게 말하면, "AI가 자신이 이전에 했던 방법과 다른 아이디어를 냈는가?" 를 물어보는 것이다.

예를 들어 AI가 처음에는 XGBoost를 사용했다.(XGBoost는 머신러닝 알고리즘 정도로 이해하면 된다.)

그다음에는 learning rate만 조금 바꿨다.(Learning rate : 기계학습 및 통계학에서 손실함수의 최소값을 향해 이동하면서 각 반복에서 단계 크기를 결정하는 최적화 알고리즘의 조정 매개변수)

이건 완전히 새로운 방법이라고 보기 어렵다.

반대로 다음 시도에서 신경망 알고리즘을 사용하거나, 전혀 다른 데이터 처리 방법을 사용했다면 꽤 새로운 접근이다.

즉, AI가 한 가지 방법만 계속 수정하는지, 아니면 다른 방법을 새롭게 탐색하는지를 보는 것이다.

기존 인간 풀이와 얼마나 다른지도 확인했다 — H-Creativity

두 번째는 H-Creativity다.

이번에는 AI 자신의 이전 방법과 비교하는 것이 아니다.

사람들이 이미 했던 방법과 비교한다.

연구진은 실제 Kaggle 문제에서 공개된 수많은 인간 풀이를 비교 대상으로 사용했다.

각 과제마다 약 877개에서 3,747개의 인간 solution이 사용됐다. AI가 만들어낸 방법이 이런 기존 인간 풀이와 얼마나 다른지를 살펴본 것이다. AI에게는 처음 떠올린 아이디어라도, 사람들은 이미 수없이 사용했던 방법일 수 있다.

반대로 AI가 인간 참가자들이 거의 시도하지 않았던 영역까지 들어갈 수도 있다.

그리고 실제 실험에서 그런 일이 나타났다.

AI는 처음에는 생각보다 많은 것을 시도했다

AI는 문제를 처음 받으면 상당히 다양한 방법을 시도했다.

논문에서는 초기 행동의 약 75%가 새로운 해결 방향을 탐색하는 Strategic Exploration이었다고 분석했다.

쉽게 말하면 이런 식이다.

이 모델을 사용해볼까?

다른 알고리즘은?

Feature Engineering을 바꿔볼까?

아예 다른 구조로 풀어볼까?

그런데 시간이 지나면서 행동이 달라졌다. 새로운 방향을 탐색하는 비율은 약 25%까지 줄어들고, 기존 방법에서 조금씩 조정하는 행동이 크게 늘어났다.

처음에는 여러 길을 찾아보다가 어느 정도 괜찮아 보이는 길을 발견하면 그 주변만 파기 시작한 것이다.

사람이 문제를 푸는 과정과도 조금 비슷해 보였다.

그런데 AI는 너무 빨리 한 방법에 집중했다

여기서 재미있는 결과가 나온다.

AI Agent는 반복할수록 성능은 높아지고 창의성은 낮아졌다. 출처: Bhushan et al., Can LLM Agents Discover?, Figure 2

AI의 P-Creativity는 실험이 진행될수록 계속 감소했다.

즉, 시간이 지날수록 새로운 아이디어는 줄었다. 반면 성능은 올라갔다.

정리하면 이런 모습이다.

새로운 아이디어 ↓

기존 아이디어 개선 ↑

성능 ↑

처음에는 여러 방법을 시도하지만, 어느 정도 성능이 나오는 방법을 발견하면 새로운 방법을 찾기보다는 기존 방법을 계속 수정했다. 논문에서는 이를 exploration(탐색)에서 exploitation(활용)으로 이동하는 과정으로 본다.

여기까지는 크게 이상하지 않다. 우리도 문제를 풀 때 가능성이 있어 보이는 방법을 찾으면 그 방법을 조금씩 개선하기 때문이다.

그런데 AI는 사람보다 더 새로운 방법을 찾기도 했다

그렇다면 AI가 사람과 다른 방법을 내놓은 것이 단순히 엉뚱한 답을 만들었기 때문은 아닐까?

연구진도 이 부분을 확인했다. H-Creativity는 AI가 만든 방법을 같은 Kaggle 문제에서 사람들이 실제로 사용했던 수백~수천 개의 풀이와 비교해, 기존 인간 풀이와 얼마나 다른 방법을 사용했는지 평가한 지표다.

이 평가에서 GPT-5 기반 AIDE Agent의 평균은 1.423, 대회 종료 후 공개된 Gold medal 인간 풀이의 평균은 0.744였다.

그렇다고 해서 GPT-5가 인간보다 두 배 창의적이라는 의미는 아니다.

다만, 사람들이 주로 사용했던 해결 방법에서 더 멀리 떨어진 영역까지 AI가 탐색했다는 의미로 볼 수 있다.

연구진은 AI가 단순히 엉뚱한 방향으로 벗어난 것은 아닌지도 확인했다. 아예 다른 Kaggle 문제의 풀이를 가져와 비교했을 때 H-Creativity는 2.39까지 올라갔다. GPT-5의 1.42는 이것보다 훨씬 낮았다.

기존 인간 풀이와 비슷함                       매우 다름

Gold 인간          GPT-5 Agent        다른 문제의 풀이
  0.744               1.423                2.39
    │                    │                    │
    ●────────────────────●────────────────────●

즉, AI는 아무 방향으로나 다른 답을 낸 것이 아니라, 문제의 범위 안에서 인간이 상대적으로 덜 탐색했던 방법을 시도한 것이다.

하지만 여기서 중요한 문제가 하나 생긴다.

※ AIDE란? AIDE(AI-Driven Exploration in the Space of Code)는 AI가 머신러닝 문제를 풀면서 여러 방법을 직접 시도하고, 코드 실행 결과와 성능을 확인한 뒤 다음 방법을 결정하도록 만든 Agent다. 쉽게 생각하면 AI의 실험노트이자 실험 환경에 가깝다.

새롭기는 했는데, 결과는 사람보다 좋지 않았다

AI가 사람보다 더 새로운 방법을 많이 찾았다면, 성능도 더 좋았을까?

그렇지는 않았다. GPT-5를 사용한 Agent 실행 중 Kaggle 기준으로 medal-level 성능에 도달한 비율은 21.25%였다.

즉, 인간이 사용하지 않은 새로운 방법을 찾는 능력과 실제로 높은 성능을 만드는 능력 사이에는 상당한 차이가 있었다.

새로운 방법을 찾는 능력
        ≠
좋은 방법을 찾는 능력

나는 이 부분이 이번 논문에서 가장 중요하다고 느꼈다. 방법을 찾았지만, 실제로 사용할 수는 없는 경우가 많다.

새롭지만 ‘끝이 낮은 길’을 발견한 AI

논문에는 이 문제를 잘 보여주는 사례도 하나 나온다.

Cassava Leaf Disease Classification이라는 이미지 분류 문제다. 대표적인 머신러닝 분류 예시이다.

AI가 발견한 새롭지만 성능 한계가 낮은 해결 방법 출처: Bhushan et al., Can LLM Agents Discover?, Figure 5

AI는 처음에는 일반적인 방법을 사용한다. 그러다가 기존 인간 참가자들이 잘 사용하지 않았던 LightGBM + handcrafted image features + test-time augmentation 이라는 방법까지 탐색한다.

이 방법의 H-Creativity 점수는 최고점인 4였다. 즉 상당히 새로운 접근이었다.

실제 성능은 기대만큼 좋지 않았다. 논문에서 사용하는 성능 지표인 Impact는 약 0.680 수준에 머물렀다.

문제는 그다음이다. AI가 이 방향의 한계를 빨리 알아차리고 다른 방법을 찾아갔다면 좋았을 것이다.

하지만 그러지 않았다. 비슷한 방법을 계속 수정하면서 6번 연속 큰 성능 향상 없이 같은 영역을 반복했다.

논문에서는 이를 novel but low-ceiling paradigm이라고 설명한다.

나는 이 표현이 꽤 재미있었다.

쉽게 말하면,

아무도 가지 않았던 새로운 길을 발견했는데,
막상 가보니 좋은 길은 아니었던 것이다.

그리고 AI는 그 사실을 빨리 알아차리지 못했다.

그렇다면 AI에게 부족한 것은 창의력일까?

여기까지 읽으면 처음 질문을 조금 바꿔야 할 것 같다.

처음에는 "AI도 창의적일까?" 가 궁금했다. 그런데, 논문을 읽고 나니 오히려 이런 질문이 생겼다.

AI에게 부족한 것은 창의력이 아니라 판단력 아닐까?

AI는 새로운 방법을 생각할 수 있었다. 심지어 인간들이 잘 찾아보지 않았던 방법도 찾았다.하지만 그 방법이 정말 좋은 것인지, 더 발전시킬 가치가 있는지, 아니면 빨리 버리고 다른 방법을 찾아야 하는지를 판단하는 부분에서는 부족함을 보였다.

결국 중요한 것은 아이디어의 양이 아닐지도 모른다.

아이디어 생성
↓
좋은 아이디어 선택
↓
실험
↓
실패 판단
↓
버릴 것과 발전시킬 것 선택

이 과정을 얼마나 잘 반복할 수 있느냐가 더 중요해 보인다.

AI는 처음부터 창의적이지 않은 것이 아니었다

우리는 흔히 생성형 AI를 “기존 데이터를 조합해서 답을 만드는 시스템” 이라고 이야기한다.

물론 AI가 학습한 데이터의 영향을 받는 것은 당연하다.

하지만 이번 논문만 놓고 보면, AI Agent가 단순히 인간의 기존 solution을 그대로 반복했다고 보기는 어렵다.

인간이 잘 탐색하지 않은 영역까지 실제로 들어갔기 때문이다.

"AI는 새로운 것을 만들 수 없다."라고 단정하는 것도 이제는 조금 조심해야 할 것 같다.

AI의 다음 경쟁은 ‘더 많은 생각’ 이 아닐지도 모른다

얼마 전 Agent Zero Memory 논문을 읽으면서 이런 생각을 했다.

앞으로의 AI 경쟁은 단순히 누가 더 똑똑한 모델을 만드느냐에서 끝나지 않을지도 모른다고.

그때는 AI가 얼마나 많이 알고 있는가보다,

"필요한 정보를 얼마나 잘 기억하고, 필요한 순간에 정확하게 꺼내오는가" 가 중요해질 수 있다고 생각했다.

이번 논문을 읽고 나니 하나가 더 추가된 것 같다.

어떤 생각을 계속 발전시키고, 어떤 생각을 버릴 것인가.

AI는 이미 생각보다 많은 새로운 아이디어를 만들어낼 수 있었다. 심지어 인간이 잘 시도하지 않았던 해결 방법까지 찾아갔다.

하지만 새로운 아이디어가 항상 좋은 결과로 이어지는 것은 아니었다.

가능성이 낮은 방법을 발견하고도 그 방향을 계속 수정하면서 시간을 사용하기도 했다.

결국 앞으로 중요한 것은 AI가 얼마나 많은 아이디어를 만들어내느냐가 아닐지도 모른다.

새로운 아이디어 가운데

"어떤 것을 선택하고, 어떤 것을 더 실험하고, 언제 포기하고 다른 길로 갈 것인지" 판단하는 능력이 더 중요해질 수 있다.

이렇게 보면 최근 읽었던 두 논문이 조금 재미있게 연결된다.

Agent Zero Memory
→ 무엇을 기억하고 꺼낼 것인가?

Can LLM Agents Discover?
→ 무엇을 선택하고 버릴 것인가?

결국 AI에게 점점 중요해지는 것은 단순히 더 많이 아는 능력이 아니라, 필요한 것을 기억하고, 선택하고, 판단하는 능력인지도 모르겠다.

앞으로의 AI 경쟁은 누가 더 큰 모델을 만드는지를 넘어,

누가 더 잘 기억하고, 더 좋은 생각을 골라내며, 잘못된 길을 빨리 버릴 수 있는가

의 경쟁으로 이어질지도 모르겠다.

참고한 논문

Can LLM Agents Discover? Evaluating Creativity on ML Engineering Tasks
Shitanshu Bhushan, Yunxiang Zhang, Lu Wang / 2026

이 연구는 10개의 Kaggle 스타일 ML Engineering 과제에서 AIDE와 AIRA-Dojo Agent를 평가했다. 따라서 여기서 말하는 창의성은 머신러닝 문제 해결 과정에서의 창의성으로, 소설·그림·음악 등 모든 종류의 인간 창의성으로 확대해서 해석할 수는 없다.

옵시디언 노트 정리법｜폴더·링크·태그 차이와 사용법

zeucise — Tue, 15 Sep 2026 23:31:17 +0900

옵시디언에서 폴더, 링크, 태그의 차이와 사용법을 설명하는 썸네일

옵시디언을 처음 사용할 때는 노트를 만드는 것 자체는 어렵지 않았다.

새 노트를 만들고 Markdown으로 내용을 작성하면 된다. Markdown 작성이 아직 익숙하지 않다면 이전 글에서 자주 사용하는 문법을 먼저 정리해두었다.

그런데 노트가 하나둘 늘어나기 시작하니 다른 고민이 생겼다.

“이 노트는 어디 정리해야 하지?”

처음에는 폴더를 계속 만들면 될 것 같았다.

하지만, 폴더로 나누는데는 한계가 있었고, 정리를 하다가 보니 하나의 노트가 여러 주제와 연결되는 경우가 많았다.

옵시디언에서는 이런 노트를 정리할 때 폴더, 링크, 태그를 사용할 수 있다.

처음에는 비슷해 보이지만 역할을 나눠 생각하면 의외로 간단하다.

폴더 : 노트가 어디에 있는가
링크 : 어떤 노트와 관련 있는가
태그 : 어떤 공통점을 가진 노트인가

이번에는 내가 실제로 운영하고 있는 블로그 자료를 정리하면서 이 세 가지를 어떻게 나눠 사용하면 좋은지 알아보려고 한다.

먼저 블로그 자료를 폴더로 나눠봤다

현재 나는 크게 두 개의 블로그를 운영하고 있다.

하나는 AI와 IT 관련 내용을 정리하는 블로그이고, 다른 하나는 육아 기록을 남기는 윤호 블로그다.

그래서 Obsidian에서도 먼저 두 영역을 폴더로 나눴다.

옵시디언에서 AI 블로그와 윤호 블로그를 폴더로 나눈 화면

이렇게 정리하면 적어도 어떤 노트가 어느 블로그에 속하는지는 쉽게 알 수 있다.

Windows에서 파일을 폴더별로 정리하는 것과 크게 다르지 않아서 가장 익숙한 방법이기도 하다.

그래서 처음 옵시디언을 사용한다면 모든 것을 복잡하게 만들기보다 큰 범주부터 폴더로 나누는 것이 사용하기 쉽다.

그런데 폴더만으로 정리하면 애매한 노트가 생긴다

문제는 노트가 조금씩 늘어나면서 시작됐다.

예를 들어 지금 작성하고 있는 옵시디언 노트 정리법이라는 글을 생각해보자.

AI 블로그
└─ Obsidian
   ├─ Obsidian 설치 방법
   ├─ Obsidian Markdown 사용법
   └─ Obsidian 노트 정리법

여기까지는 어렵지 않다.

그런데 옵시디언 노트 정리법은 이전에 작성한 Obsidian Markdown 사용법과 이어지는 글이고, 앞으로 작성할 Obsidian 템플릿 사용법과도 연결된다. 폴더에서는 이 세 개의 노트가 같은 장소에 있다는 것은 알 수 있다.

하지만 이 글들이 어떤 순서로 이어지고 어떤 관계가 있는지는 알기 어렵다.

이때 사용할 수 있는 것이 링크다.

2026.08.27 - [Obsidian/입문] - 직장인 업무 메모에 Obsidian을 써보면 좋은 3가지 이유

링크는 관련 있는 노트를 연결할 때 사용한다

Obsidian에서 다른 노트를 연결하는 방법은 간단하다.

[[를 입력하고 연결하고 싶은 노트의 이름을 선택하면 된다.

예를 들어 지금 작성하고 있는 노트 안에 이렇게 입력할 수 있다.

옵시디언 노트에서 내부 링크로 다른 노트를 연결한 화면

이렇게 하면 노트가 단순히 같은 폴더 안에 존재하는 것이 아니라 실제로 노트끼리 서로 연결된다.

이게 Obsidian이 일반적인 메모 프로그램과 조금 다르게 느끼게 만드는 부분이기도 하다.

폴더가 노트의 위치를 정한다면, 링크는 노트와 노트 사이의 관계를 만든다.

Obsidian 설치 방법
        ↓
Obsidian Markdown 사용법
        ↓
Obsidian 노트 정리법
        ↓
Obsidian 템플릿 사용법

블로그에서는 각각 별개의 글이지만, Obsidian안에서는 하나의 흐름으로 연결되는 셈이다.

백링크는 나를 연결한 노트를 보여준다

링크를 사용하다 보면 재미있는 기능이 하나 더 생긴다. 바로 백링크(Backlinks)다.

일반적인 링크가 이 노트에서 어떤 노트로 이동할 것인가를 보여준다면, 백링크는 반대로 어떤 노트가 현재 노트를 연결하고 있는가를 보여준다.

예를 들어 Obsidian Markdown 사용법이라는 노트를 여러 글에서 링크했다면 백링크를 통해 그 글들을 확인할 수 있다.

옵시디언 백링크에서 현재 노트를 연결한 다른 노트를 확인하는 화면

하지만 노트가 수십 개, 수백 개가 되면 이야기가 달라진다.

예전에 작성했던 노트가 새로운 글과 연결되는 경우를 찾을 수 있기 때문이다.

개인적으로는 이 부분부터 Obsidian이 단순한 노트 프로그램이 아니라는 느낌이 강해진다.

그렇다면 태그는 언제 사용할까?

폴더도 있고 링크도 있는데 굳이 태그까지 필요한지 궁금할 수 있다.

나는 태그를 여러 폴더에 있는 노트를 하나의 기준으로 다시 묶고 싶을 때 사용하면 이해하기 쉽다고 생각한다.

예를 들어 윤호 블로그에 후쿠오카 여행 글이 있다고 해보자.

이 글은 폴더상으로는 다음 위치에 둘 수 있다.

윤호 블로그
└─ 여행
   └─ 후쿠오카 가족여행

그런데 이 글에는 여러 성격이 동시에 있을 수 있다.

#일본여행
#아기와여행
#후쿠오카

이렇게 태그를 붙이면 폴더 위치와 관계없이 같은 태그가 붙은 글을 다시 모아볼 수 있다.

AI 블로그도 마찬가지다.

예를 들어, Obsidian 글과 Codex 글은 서로 다른 폴더에 있지만 둘 다 #생산성이나 #업무자동화라는 관점에서는 관련된 글이 될 수 있다. 즉, 태그는 노트가 가진 성격이나 공통점을 표시하는 방법으로 생각하면 이해하기 쉽다.

옵시디언 노트에 태그를 설정한 화면

폴더·링크·태그를 한 번에 정리하면

처음에는 세 가지가 비슷해 보였는데 실제로 사용해보면 역할은 꽤 다르다.

기능	이렇게 생각하면 쉽다	예시
폴더	노트가 어디에 있는가	AI 블로그 → Obsidian
링크	어떤 노트와 관련 있는가	Markdown 글 → 노트 정리법
백링크	어떤 노트가 나를 언급했는가	현재 글을 연결한 다른 글
태그	어떤 성격을 가진 노트인가	#후쿠오카, #업무자동화

이 기준으로 보면 노트를 정리할 때도 조금 단순해진다.

먼저 큰 영역은 폴더로 나눈다.
관련된 노트가 있다면 링크로 연결한다.
여러 위치의 노트를 공통된 기준으로 묶고 싶다면 태그를 사용한다.

처음부터 복잡한 정리 방법을 만들 필요는 없다.

처음부터 완벽한 폴더 구조를 만들 필요는 없다

Obsidian 사용법을 찾아보다 보면 PARA, Zettelkasten, MOC처럼 다양한 노트 정리 방법을 접하게 된다.

물론 이런 방법도 익숙해지면 도움이 될 수 있다.

하지만 처음 사용하는 단계에서 반드시 알아야 하는 것은 아니다.

나 역시 지금은 내가 실제로 관리해야 하는 블로그를 기준으로 큰 폴더를 먼저 만들었다.

AI 블로그
윤호 블로그

그리고 그 안에서 필요한 만큼만 하위 폴더를 나누고 있다.

사용하다가 새로운 기준이 필요해지면 그때 링크나 태그를 추가하면 된다.

오히려 처음부터 너무 많은 폴더와 태그를 만들면 노트를 작성하는 것보다 “어디에 정리할지 고민하는 시간”이 더 길어질 수 있다.

Obsidian의 장점은 처음 만든 구조를 계속 유지해야 하는 것이 아니라 사용하면서 조금씩 바꿀 수 있다는 데 있다.

결국 중요한 것은 노트를 다시 찾을 수 있는가였다

폴더·링크·태그를 나눠서 생각하면 옵시디언의 노트 정리가 조금 쉬워진다.

다시 한번 간단하게 정리하면 이렇다.

폴더는 노트의 위치.
링크는 노트 사이의 관계.
태그는 여러 노트가 가진 공통점.

처음부터 완벽하게 정리할 필요는 없다.

나 역시 지금 운영하고 있는 두 블로그를 큰 폴더로 나누는 것부터 시작했다.

중요한 것은 멋진 폴더 구조를 만드는 것이 아니라, 나중에 필요한 노트를 다시 찾을 수 있고 관련된 기록을 자연스럽게 이어갈 수 있게 만드는 것이다.

그리고 노트를 계속 작성하다 보면 또 하나 반복되는 작업이 생긴다.

블로그 글이나 자료 정리처럼 매번 비슷한 형식의 노트를 만드는 일이다.

다음 글에서는 이런 반복 작업을 줄일 수 있는 옵시디언 템플릿 사용법을 직접 정리해보려고 한다.

참고자료

OpenAI Codex 사용법 5편｜AI가 수정한 코드를 확인하는 방법

zeucise — Tue, 15 Sep 2026 08:47:24 +0900

OpenAI Codex가 수정한 코드를 Diff와 Review로 확인하고 GitHub에 Commit·Push하는 과정

지난 글에서는 Codex로 만든 프로그램을 GitHub에 저장해봤다.

☞ 이전 글 : 2026.09.13 - [Codex] - OpenAI Codex 사용법 4편｜Codex를 쓴다면 GitHub를 써야 하는 이유

이제 정상적으로 동작하는 프로그램의 첫 번째 버전이 Git과 GitHub에 저장되어 있다.

그렇다면 이제 Codex에게 다시 코드를 수정시켜보자.

그런데 여기서 중요한 것은 코드를 수정하는 것보다 무엇이 바뀌었는지 확인하는 것이다.

이번에는 Codex가 수정한 코드를 GitHub Desktop의 Changes와 Diff로 확인하고,Codex Review로 다시 검토한 뒤 Commit과 Push까지 진행해보려고 한다.

Codex에게 기능을 하나 추가해보자

3편에서 만든 파일 분석 프로그램은 폴더 안의 파일을 확장자별로 확인한다.

이번에는 기능을 하나 추가해보자.

Codex에 다음과 같이 요청한다.

현재 프로그램에 기능을 하나 추가해줘.

기존 확장자별 파일 개수와 함께
전체 파일 개수도 출력하도록 수정해줘.

기존 기능은 그대로 유지하고
수정 후 테스트도 실행해서 정상 동작하는지 확인해줘.

Codex가 작업을 시작하면 기존 파일을 확인하고 필요한 코드를 수정한다.

작업이 끝났다고 바로 프로그램을 사용하는 것은 아니다.

이제부터 무엇이 바뀌었는지 확인해보자.

이번 예시는 Codex CLI 기준으로 진행했으며, Codex App 화면은 생략했다.

OpenAI Codex에 기존 Python 프로그램의 기능 수정을 요청한 화면

OpenAI Codex에 기존 Python 프로그램의 기능 수정을 요청결과 화면

GitHub Desktop에서 변경사항 확인하기

Codex가 코드를 수정한 뒤 GitHub Desktop을 실행한다.

왼쪽의 Changes 영역을 보면 수정된 파일이 나타난다.

GitHub Desktop에서 OpenAI Codex가 수정한 파일 목록을 확인하는 화면

여기서 Changes는 어렵게 생각할 필요가 없다.

마지막으로 Commit한 이후 변경된 파일

이라고 생각하면 된다.

4편에서 정상적으로 동작하는 프로그램을 Commit했기 때문에, 지금 보이는 Changes는 Codex가 그 이후에 수정한 내용이다.

GitHub Desktop Diff로 코드 변경사항 확인하기

Changes에서 파일을 클릭하면 오른쪽 화면에 수정된 코드가 표시된다.

GitHub Desktop Diff 화면에서 Codex가 수정한 Python 코드를 비교하는 모습

이 화면을 Diff라고 한다. Diff는 수정 전과 수정 후의 차이를 보여준다.

예를 들어:

- print(f"합계\t{sum(item[0] for item in stats.values()):,}")
+ print(f"합계\t{total_count:,}")

처음 보면 복잡해 보이지만 두 가지만 보면 된다.

빨간색 / -
→ 기존 코드에서 삭제되거나 변경된 내용

초록색 / +
→ 새롭게 추가된 내용

즉, Diff를 보면 Codex가 어떤 코드를 삭제하고 어떤 코드를 추가했는지 직접 확인할 수 있다.

Codex Review로 수정된 코드 검토하기

Codex CLI에서 /review를 입력한 뒤 현재 Commit하지 않은 변경사항을 검토하도록 한다.

OpenAI Codex Review 기능으로 수정된 코드를 다시 검토하는 화면

현재 변경된 코드를 기준으로 문제가 없는지 Codex에게 다시 검토하도록 하는 기능이다.

쉽게 구분하면 다음과 같다.

GitHub Desktop Diff
→ 무엇이 바뀌었는지 사람이 확인

Codex Review
→ 변경된 코드에 문제가 없는지 AI가 다시 검토

Diff는 변경 확인이고, Review는 코드 검토다.

Codex가 직접 만든 코드라도 다시 Review를 요청할 수 있다.

코드를 작성하는 과정과 검토하는 과정을 한 번 더 나누는 것이다.

그래도 마지막은 사용자가 직접 확인해야 한다

Codex 코드 수정
↓
테스트
↓
GitHub Desktop Changes
↓
Diff
↓
Codex Review

하지만, Codex Review에서도 문제가 없다고 나왔다고 해서 무조건 안전한 것은 아니다.

AI는 코드를 만들 수도 있고 실수할 수도 있다.

그래서 마지막에는 최소한 다음 정도는 직접 확인하는 것이 좋다.

요청한 기능이 실제로 추가됐는가?

기존 기능은 정상적으로 동작하는가?

요청하지 않은 파일을 수정하지 않았는가?

테스트는 실제로 통과했는가?

결국 AI가 코딩을 하더라도 최종 판단은 사람이 한다.

문제가 없다면 Commit한다

변경사항을 확인했고 테스트와 Review에도 문제가 없다면 현재 상태를 다시 저장한다.

GitHub Desktop 왼쪽 아래 Commit 메시지에 아래처럼 이번 변경 내용을 간단하게 작성한다.

Add total file count

그리고, Commit to main 을 클릭한다. 이제 내 컴퓨터의 Git에는 새로운 버전이 저장됐다.

Add total file count 라고 입력하고 Commit to main를 클릭

마지막으로 GitHub에 Push한다

Commit했다고 바로 GitHub Repository에 반영되는 것은 아니다.

Push origin을 클릭하면, 내 컴퓨터에 저장한 Commit이 GitHub Repository로 올라간다.

Codex가 수정한 코드를 GitHub Desktop에서 Commit하고 Push한 화면

이제 전체 과정을 정리하면,

Codex 수정
↓
Changes 확인
↓
Diff 확인
↓
테스트 결과 확인
↓
Review
↓
Commit
↓
Push

이 사이클은 앞으로 Codex로 개발할 때 반복해서 사용하게 될 과정이다.

Codex를 사용할수록 확인 과정이 중요하다

Codex를 사용하면 코드를 작성하는 속도는 확실히 빨라진다.

예전에는 직접 코드를 작성하고 수정해야 했다면, 이제는 자연어로 작업을 설명하는 것만으로도 여러 파일의 코드를 빠르게 수정할 수 있다.

하지만 빠르게 업무를 할 수 있다는 것은 반대로 많은 코드를 빠르게 잘못 수정할 수도 있다는 의미다.

그래서 개인적으로는 다음 과정을 기본으로 사용하는 것이 좋다고 생각한다.

AI에게 작업 요청
↓
테스트
↓
Diff 확인
↓
AI Review
↓
사람이 최종 확인
↓
Commit / Push

Codex에게 코딩을 맡기는 것보다 중요한 것은 Codex가 무엇을 바꿨는지 내가 확인할 수 있는 상태를 유지하는 것이다.

Git과 GitHub를 먼저 사용한 이유도 바로 여기에 있다.

다음에는 Codex에게 프로젝트 규칙을 알려줘보자

Codex를 사용하다 보면 또 다른 불편함이 생긴다. 매번 이런 내용을 반복해서 입력하게 된다.

기존 코드는 최대한 유지해줘.

테스트를 반드시 실행해줘.

불필요한 파일은 만들지 마.

README도 같이 수정해줘.

그렇다면 이런 규칙을 Codex가 처음부터 알고 있게 할 수는 없을까?

다음 글에서는 프로젝트마다 Codex가 지켜야 할 규칙을 작성하는 AGENTS.md를 직접 만들어보려고 한다.

그리고 이후에는 Plan 기능을 이용해 조금 더 큰 프로그램을 설계한 뒤, 지금까지 배운 Codex·GitHub·AGENTS.md를 이용해 실제로 하나의 프로그램을 처음부터 완성해볼 예정이다.

회사 자료를 ChatGPT 에 올려도 될까?｜AI에 넣으면 안 되는 정보

zeucise — Mon, 14 Sep 2026 15:42:51 +0900

회사 자료를 ChatGPT에 업로드할 때 개인정보와 기밀정보를 확인하는 방법

회사에서 생성형AI를 사용하다 보면 한 번쯤 이런 순간이 생긴다.

보고서가 길어서 요약하고 싶거나, 회의록을 정리하거나, Excel 데이터를 분석하고 싶은데 직접 하려니 시간이 오래 걸린다.

“그냥 파일을 생성형AI에 올리면 금방 끝날 것 같은데?”

파일을 첨부하려는 순간 또 다른 생각이 든다.

“그런데 회사 자료를 생성형AI에 올려도 괜찮을까?”

예전에는 생성형AI에 간단한 질문 정도만 했다면 이제는 PDF, Excel, 보고서까지 직접 올려 분석하는 경우가 많아졌다.

나 역시 이전 글에서 원본 자료를 AI에 넣고 보고서 작성을 자동화하는 방법을 소개했다.

그런데 업무 효율과는 별개로 생각해야 할 문제가 있다.

"우리가 AI에게 어떤 정보를 주고 있는가" 이다.

개인정보보호위원회도 2026년 「생성형 AI 서비스 이용자를 위한 개인정보 보호 가이드」를 발표하면서, 실제 민원과 상담에서 자주 나온 질문으로 AI에 입력한 내용의 학습 여부, 업무자료 입력, 대화 기록 관리 등이 수록되어 있다.

결론부터 말하면, 회사 자료라고 모두 AI에 넣으면 안 되는 것은 아니다.
다만, 회사 정책을 확인하고 개인정보나 기밀정보처럼 AI에게 필요하지 않은 정보는 먼저 지우고 사용해야 한다.

회사자료를 AI에 올리기 전 10초만 확인해보자

문서를 업로드하기 전에 아래의 내용을 확인해보는 것이 좋다.

자료에 포함된 정보	판단	먼저 할 일
회사 홈페이지 등에 공개된 정보	상대적으로 낮은 위험	정말 공개된 정보인지 확인
일반적인 내부 업무자료	주의	회사 AI 사용 정책 확인
직원 이름·연락처·이메일	주의	필요 없다면 삭제·대체
고객 개인정보	위험	원문 그대로 입력하지 않기
주민등록번호·계좌·카드정보	매우 위험	반드시 제거
비밀번호·API Key·인증코드	매우 위험	절대 포함하지 않기
미공개 실적·사업계획	위험	기밀정보 여부 확인
계약서의 비공개 조항	위험	계약·비밀유지 조건 확인
소스코드·보안 취약점	주의	회사 보안정책 확인

AI가 일을 하는 데 필요하지 않은 정보라면 굳이 주지 않는 것.

보고서를 요약하는 데 고객의 전화번호가 필요하지 않다면 전화번호까지 함께 전달할 이유가 없다.

ChatGPT는 내가 올린 회사자료를 학습할까?

이 부분에서 많이 헷갈린다.

생성형 AI에 문서를 올리면 보통 이렇게 생각하기 쉽다.

회사 자료를 ChatGPT에 업로드할 때 전송 저장 학습이 서로 다른 과정임을 설명하는 이미지

파일 전송 → ChatGPT가 저장 → AI가 학습

하지만 세 가지는 같은 의미가 아니다.

먼저 전송이다.
생성형AI에게 질문하거나 파일을 분석시키려면 내가 입력한 내용이 AI의 서비스로 전달된다.
이 과정은 ChatGPT를 사용하기 위해 필요하다.

다음은 저장이다.
전송된 대화나 파일은 서비스 운영이나 기능에 따라 일정 기간 보관될 수 있다.
즉, 모델 학습을 껐다고 해서 입력한 자료가 전송되지 않거나 바로 삭제되는 것은 아니다.

마지막이 학습이다.
말하는 학습은 내가 입력한 내용을 향후 모델을 개선하는 데 사용하는 것을 뜻한다.

생성형AI에서는 설정에 따라 대화나 파일 등의 콘텐츠가 모델 개선에 사용될 수 있다.

다만, ChatGPT에서는 설정 → 데이터 제어 → 모두를 위한 모델 개선을 끄면 이후 새 대화는 모델 학습에 사용되지 않는다.

자세한 설정 방법은 OpenAI 공식 안내에서도 확인할 수 있다.

※ OpenAI｜모델 학습을 비활성화하는 방법

그렇다면 이런 생각이 들 수 있다.

“학습만 꺼놓으면 회사 자료를 마음대로 넣어도 되는 것 아닌가?”

그렇지는 않다.

'학습하지 않는다' 와 '올려도 된다' 는 다른 이야기다

ChatGPT가 내 자료를 모델 학습에 사용하지 않는다는 것과 회사 자료를 외부 AI 서비스에 전달해도 된다는 것은 전혀 다른 문제다. 예를 들어 회사 정책이 고객 정보를 외부 생성형 AI에 입력하지 못하도록 하고 있다면 모델 학습을 꺼놓았더라도 입력해서는 안 된다.

회사 자료에는 개인정보 말고도 여러 종류의 민감한 정보가 있다.

아직 발표하지 않은 실적
신제품이나 신규 사업 계획
고객사와의 계약조건
영업전략이나 가격정책
내부 시스템 구성
소스코드
보안 취약점
비밀유지계약에 포함된 자료

따라서 회사 자료를 AI에 사용하려면 최소한 세 가지를 따로 확인할 필요가 있다.

① 회사에서 해당 AI 사용을 허용하는가

② 문서에 개인정보·기밀정보가 포함되어 있는가

③ 내가 사용하는 AI 서비스는 데이터를 어떻게 처리하는가

하나라도 잘 모르겠다면 원본 문서를 그대로 올리지 않는 편이 낫다.

Temporary Chat을 사용하면 괜찮을까?

ChatGPT에는 Temporary Chat, 즉 임시 채팅 기능도 있다.

현재 OpenAI 안내에 따르면 임시 상태의 Temporary Chat은 일반 채팅 기록에 나타나지 않고 모델 개선에 사용되지 않으며, 안전 및 보안 목적을 위해 사본이 최대 30일간 보관될 수 있다. 개인적인 내용이나 일회성 작업을 할 때 유용한 기능이다.

하지만 여기에도 같은 원칙이 적용된다.

Temporary Chat을 사용한다고 회사 기밀이나 개인정보를 마음대로 입력해도 된다는 의미는 아니다.

AI 서비스의 데이터 처리 방식과 회사의 정보보호 정책은 별개의 문제다.

파일을 올렸다가 채팅을 삭제하면 사라질까?

AI에서 대화를 삭제하면 업로드했던 파일도 당연히 같이 없어질 것처럼 생각하기 쉽다.

하지만 현재 OpenAI 정책에서는 Library를 사용할 수 있는 계정이나 워크스페이스의 경우 대화 중 업로드한 파일이 Library에 별도로 저장될 수 있다.

이 경우 채팅을 삭제해도 Library에 저장된 파일까지 자동으로 삭제되는 것은 아니다.

따라서 회사 문서를 올렸다면 채팅만 삭제하고 끝내지 않는 것이 좋다. Library에 파일이 남아 있다면 파일도 별도로 삭제해야 한다.

OpenAI의 채팅·파일 보존 정책은 아래에서 확인할 수 있다.

※ OpenAI｜ChatGPT 채팅 및 파일 보존 정책

이 부분은 앞으로 기능이나 정책이 변경될 수 있기 때문에 중요한 자료를 다룬다면 그때그때 최신 정책을 확인하는 편이 좋다.

그렇다면 회사 문서는 어떻게 사용하는 것이 좋을까?

회사 보고서에 다음 정보가 있다고 가정해보자.

고객명: A회사
담당자: 김○○
연락처: 010-XXXX-XXXX
계약금액: 8억 원
프로젝트 종료 예정: 2026년 12월
현재 일정: 약 3주 지연

내가 생성형AI에게 원하는 것이 프로젝트 일정의 위험요인을 분석하는 것이라면 담당자 이름과 전화번호는 필요하지 않다.

그러면 이렇게 바꿀 수 있다.

프로젝트 규모: 약 8억 원
종료 예정: 2026년 12월
현재 일정: 약 3주 지연

현재 일정의 주요 위험요인을 찾고 대응방안을 우선순위별로 정리해줘.

AI가 수행해야 하는 업무는 거의 달라지지 않는다. 하지만 불필요한 개인정보는 줄었다.

여기서 한 가지 주의할 점도 있다.

이름을 A사로 바꾸는 것만으로 항상 안전해지는 것은 아니다.

계약금액, 사업내용, 일정 등 다른 정보와 결합하면 특정 회사나 사람을 다시 알아볼 수 있는 경우도 있기 때문이다.

결국 중요한 것은 "가명, 익명화가 아니라 AI가 필요로 하지 않은 정보를 얼마나 지웠는가" 이다.

개인정보만 지우면 끝일까?

그렇지도 않다.

회사 자료에는 개인정보가 하나도 없더라도 외부에 전달해서는 안 되는 정보가 많다.

예를 들어 다음 분기 실적 전망이나 아직 발표하지 않은 조직개편 계획에는 개인정보가 없을 수 있다.

하지만 그렇다고 생성형AI에 그대로 넣어도 된다는 의미는 아니다.

따라서 문서를 볼 때는 단순히 “개인정보가 들어 있는가?” 만 확인하기보다,

“이 내용이 회사 밖의 서비스로 전달돼도 되는 정보인가?”

라고 한 번 더 생각하는 것이 좋다.

ChatGPT Business라면 회사 자료를 넣어도 괜찮을까?

OpenAI는 ChatGPT Business와 Enterprise 등의 비즈니스 데이터에 대해서는 입력과 출력을 기본적으로 모델 학습에 사용하지 않는다고 안내하고 있다.

※ OpenAI｜비즈니스 데이터 보호·보안 정책

다만 이것 역시 “Business니까 모든 회사 자료를 입력해도 된다.” 라는 의미는 아니다. AI 서비스의 보안 기능과 회사의 정보관리 정책은 별개다. 회사에서 어떤 정보를 어떤 목적으로 사용할 수 있도록 정했는지가 우선이다.

회사 자료를 ChatGPT에 넣기 전 체크리스트 6가지

파일을 올리기 전에 아래 질문만 한 번 확인해보자.

회사 자료를 ChatGPT에 넣기 전 회사 정책 개인정보 기밀정보 등을 확인하는 6가지 체크리스트

특히 다섯 번째 질문이 중요하다.

“이 정보를 빼도 ChatGPT가 같은 일을 할 수 있을까?”

가능하다면 빼는 것이 좋다.

AI를 사용하지 않는 것이 답은 아니다

회사 자료가 걱정된다고 해서 업무에서 AI를 아예 사용하지 않을 필요는 없다.

보고서 작성, 문서 요약, 자료 비교처럼 반복적인 업무에서는 AI가 상당한 시간을 줄여준다.

중요한 것은 AI를 쓰느냐, 쓰지 않느냐가 아니다.

무엇을 AI에게 전달하고 있는지 알고 사용하는가다.

원본 보고서 전체가 필요하지 않다면 필요한 부분만 가져오고,

고객 이름이 필요 없다면 제거하고,

정확한 금액이 중요하지 않다면 범위로 바꾸고,

무엇보다 회사가 승인한 AI 환경이 있다면 그 기준을 따르는 것이 우선이다.

그리고 안전하게 자료를 입력했다고 해서 AI가 만들어낸 내용까지 그대로 믿어서는 안 된다.

AI가 만든 주장과 원본 자료가 실제로 연결되는지도 한 번 더 확인해야 한다.

ChatGPT에 파일을 올리는 데는 몇 초밖에 걸리지 않는다.

그 전에 10초만, “이 문서 안에 AI에게 필요하지 않은 정보가 들어 있지 않을까?” 한 번 확인해보면 좋을 것 같다.

AI를 잘 사용하는 방법은 더 많은 정보를 주는 것이 아니라, 필요한 정보만 제대로 주는 것일지도 모른다.

참고 자료

이 글은 개인정보보호위원회의 2026년 「생성형 AI 서비스 이용자를 위한 개인정보 보호 가이드」와 OpenAI의 데이터 제어 및 비즈니스 데이터 처리 정책을 참고해 작성했다.

AI는 미래를 예측할 수 있을까?｜《AI Snake Oil》로 보는 예측 AI의 한계

zeucise — Sun, 13 Sep 2026 23:48:29 +0900

AI Snake Oil로 보는 예측 AI의 한계

요즘 AI를 사용하다 보면 이런 생각이 든다.

데이터가 충분히 많아지면 AI가 미래도 예측할 수 있지 않을까?

영화에서도 오래전부터 자주 등장하는 소재다.

《미션 임파서블: 데드 레코닝》(2023) 과 《파이널 레코닝》(2025)에 등장하는 엔티티(Entity)는 인간의 행동과 수많은 가능성을 계산해 가장 가능성 높은 미래를 예측하는 AI로 묘사된다.


미션 임파서블 : 데드 레코닝	미션 임파서블 : 파이널 레코닝

엔티티는 사람이 어떤 선택을 할지 계산하고 → 그 선택을 이용하고 → 현재를 조작해 자신이 원하는 미래가 일어날 가능성을 높인다.

최근 이와 관련해 흥미로운 책을 하나 읽었다. AI Snake Oil 이다.

처음 제목을 봤을 때는 ‘Snake Oil’ 이라는 표현이 조금 낯설었다.

영어에서 Snake Oil은 원래 효능이 검증되지 않은 만병통치약을 뜻하는 표현으로, 실제 효과보다 과장해서 판매되는 상품이나 기술을 비유할 때 사용한다.

따라서 AI Snake Oil은 쉽게 말하면,

실제로 할 수 있는 것보다 훨씬 더 많은 일을 할 수 있는 것처럼 포장된 AI

즉, AI라는 이름이 붙었다는 이유만으로 실제 능력보다 과장해서 받아들여지는 기술을 경계하자는 의미다.

이 책의 저자인 Arvind Narayanan과 Sayash Kapoor는 AI 자체를 부정하지 않는다.

오히려 AI가 실제로 잘하는 일과, AI라는 이름 때문에 능력이 과장되고 있는 일을 구분해서 봐야 한다고 이야기한다.

미래를 예측하기 어려운 이유가 정말 AI가 아직 충분히 똑똑하지 않기 때문일까?

아니면,

우리가 예측하려는 미래 자체가 원래 예측하기 어려운 것은 아닐까?

AI라고 모두 같은 AI는 아니다

ChatGPT도 AI라고 부르고, 은행에서 신용위험을 계산하는 시스템도 AI라고 부른다.

그런데 하는 일은 꽤 다르다.

생성형 AI(ChatGPT)	예측 AI(신용위험 계산 AI)
글 작성	대출 연체 가능성 예측
이미지 생성	고객 이탈 가능성 예측
코드 생성	보험사고 위험 예측
문서 요약	지원자의 성과 예측

ChatGPT 같은 생성형 AI(Generative AI)는 새로운 글이나 이미지, 코드 등을 만들어낸다.

반면 예측 AI(Predictive AI)는 과거 데이터를 이용해 앞으로 어떤 일이 일어날 가능성을 계산한다.

《AI Snake Oil》의 저자들은 이 둘을 똑같이 ‘AI’라고 부르는 것 자체가 혼란을 만들 수 있다고 이야기한다.

생성형 AI와 예측 AI는 사용하는 목적도 다르고, 잘못됐을 때 발생하는 문제도 다르기 때문이다.

예측 AI는 이미 우리 주변에 있다

예측 AI라고 하면 조금 거창하게 들린다. 하지만 활용 분야를 보면 생각보다 익숙하다.

채용과 대출 등에서 사람의 미래 가능성을 분석하는 예측

예를 들어,

이 고객이 대출을 연체할 가능성은 얼마나 될까?

이 지원자가 입사하면 일을 잘할까?

이 환자는 병원에 얼마나 더 있어야 할까?

처럼 과거 데이터를 이용해 앞으로의 결과를 예상하는 것이다.

문제는 이런 예측이 단순 추천에서 끝나지 않는다는 것이다.

취업이나 대출, 보험, 의료처럼 한 사람의 삶에 직접 영향을 줄 수도 있다.

Narayanan과 Kapoor가 생성형 AI보다 오히려 예측 AI의 현실적인 위험을 주의해서 보는 이유도 여기에 있다.

데이터가 많으면 사람의 미래도 알 수 있을까?

국내에서도 AI 면접을 통해 채용하는 일은 낯설지 않다.
고용노동부의 2025년 기업 채용동향조사에서도 조사 대상 기업의 21.7%가 AI를 공식적인 채용절차에 도입한 것으로 나타났다.

그런데 《AI Snake Oil》에서 소개하는 사례는 여기서 한 단계 더 나아간다.
일부 해외 채용 AI 업체는 지원자의 30초짜리 영상만으로 향후 업무성과를 예측할 수 있다고 주장했다.

저자들은 이런 예측을 뒷받침할 과학적 근거가 없다고 지적한다.

AI가 사용됐다는 사실보다 먼저 봐야 하는 것은 “무엇을 근거로 무엇을 예측한다는 것인가?” 라는 것이다.

30초 동안 말하는 모습을 분석할 수는 있다.

말투나 얼굴 움직임 같은 특징을 데이터로 바꿀 수도 있다.

하지만 그것을 분석할 수 있다는 사실이 그 사람이 앞으로 일을 잘할지 알 수 있다는 의미는 아니다.

AI 면접을 본 후 입사지원자를 분석하여, 이런 결과를 보여준다고 해보자.

입사 후 성공 가능성 78%

처음 보면 꽤 과학적으로 느껴진다. 그런데 생각해보면 조금 이상하다.

한 사람이 회사에서 일을 잘하는지는 무엇으로 결정될까?

학력과 경력도 영향을 줄 것이다. 하지만 어떤 상사를 만나는지, 어떤 동료와 일하는지, 어떤 업무를 맡는지 등 앞으로 어떤 일을 겪느냐에 따라 입사지원자는 많이 바뀔 수 있다.

결국 과거의 데이터 안에는 아직 일어나지 않은 미래가 들어 있지 않다.

그래서 과거의 패턴을 잘 찾는 능력과 한 사람의 미래를 예측하는 능력은 다른 문제다.

그런데 진짜 문제는 예측 다음에 있다

AI의 예측 결과를 바탕으로 인간이 최종 판단을 수

조금 더 재미있는 것은 여기서부터다.

AI가 미래를 꽤 정확하게 예측한다고 가정해보자.

어떤 사람의 대출 연체 가능성을 AI가 20%라고 계산했다.

이 사람에게 대출을 거절해야 할까?
20%까지는 허용해야 할까?
10%부터 위험하다고 봐야 할까?
금리를 다르게 적용하면 될까?

AI가 알려준 확률만으로는 답하기 어렵다. 여기서부터는 더 이상 예측의 문제가 아니다.

판단의 문제다.

Prediction
앞으로 무엇이 일어날 가능성이 있는가?

Decision
그렇다면 우리는 무엇을 할 것인가?

둘은 비슷해 보이지만 전혀 다르다.

AI가 예측할 때 도움을 준다고 해서 결정까지 해결되는 것은 아니다.

그렇다면 정확도 90%라면 믿어도 될까?

여기서 이런 생각도 들 수 있다.

“그래도 AI 정확도가 90%라면 믿어도 되는 것 아닐까?”

90%라는 숫자는 우리 일상생활에서는 상당한 신뢰감을 주는 숫자이다.

예를 들어 영화 추천 AI가 10번 중 한 번 틀렸다고 해보자.

큰 문제는 아니다. 재미없는 영화가 나오면 다른 것을 보면 된다.

그런데

대출 심사 AI가 10명 중 한 명을 잘못 판단한다면 어떨까?
채용 AI가 10명 중 한 명에게 잘못된 평가를 내린다면?

같은 90%라도 결과의 의미는 완전히 달라진다.

그래서 AI를 볼 때는 정확도와 함께 이것도 봐야 한다.

AI가 틀렸을 때 누가 피해를 보는가?

AI의 성능을 평가할 때 생각보다 놓치기 쉬운 질문이다.

예를 들어 100명에게 적용하면 10명이지만, 10만 명에게 같은 시스템을 적용하면 잘못된 판단의 대상은 1만 명이 될 수 있다.
물론 실제 오류율이 단순히 이렇게 계산되는 것은 아니지만, 같은 정확도라도 시스템이 적용되는 규모와 오류의 결과를 함께 봐야 한다.

숫자가 붙으면 왜 더 믿게 될까?

개인적으로 이 주제에서 가장 재미있는 부분이다. 위에서도 90% 라는 숫자 때문에 사람들은 그 결과에 대해서 믿게 된다.

사람이 이렇게 말한다고 생각해보자.

“제 생각에는 이 지원자가 우리 회사와 잘 맞지 않을 것 같습니다.”

아마 바로 물어볼 것이다.

"왜 그렇게 생각하지?"

위에서 말한 사람은 주관적인 생각에 의해서 답을 할 것이다.

그런데 시스템 화면에 이렇게 나온다면 어떨까?

조직 적합도 42.7%

왠지 조금 더 정확해 보인다. 심지어, 42%도 아니고 42.7%다.

하지만 숫자는 저절로 만들어진 것이 아니다. 이 숫자 역시 사람이 정한 기준과 데이터에 따라 계산된 결과다.

결과는 숫자로 나오지만 그 숫자를 만드는 과정에는 사람의 선택이 들어 있다.

그래서 숫자가 있다는 이유만으로 결과가 객관적인 것은 아니다.

《AI Snake Oil》이 AI를 반대하는 책은 아니다

위의 내용 또는 제목만 보면 AI를 강하게 비판하는 책처럼 보인다.

하지만 저자들의 주장은 조금 다르다.

생성형 AI처럼 실제로 큰 발전이 있었던 기술도 인정한다.

반대로 문제 삼는 것은 광고하는 것처럼 작동하지 않거나, 애초에 그렇게 작동하기 어려운 AI다.

Narayanan은 이런 기술을 ‘AI Snake Oil’이라고 설명한다.

그래서 어떤 서비스가 "AI 기반" 이라고 광고한다면 AI가 들어갔다는 사실보다 먼저 물어볼 필요가 있다.

그래서 이 AI가 실제로 잘하는 것이 무엇인가?

생각보다 단순한 질문이지만 AI가 빠르게 늘어나는 지금은 꽤 중요한 질문인 것 같다.

개인적으로 AI Snake Oil의 관점에서 생각해보면

이제 AI 서비스를 선택하거나, 사용할 때 정확도 같은 지표보다는 다음 네 가지를 먼저 보는 것이 좋을 것 같다.

1. 무엇을 예측한다는 것인가?
‘성공 가능성’, ‘위험도’, ‘적합도’ 처럼 애매한 표현이라면 기준이 무엇인지 먼저 확인한다.

2. 그 예측을 실제로 확인할 수 있는가?
틀렸을 때 틀렸다는 사실조차 확인하기 어려운 예측이라면 성능 자체를 검증하기도 어렵다.

3. AI가 틀렸을 때 어떤 일이 생기는가?
대출, 채용에서 잘못된 결정이 생기는 것은 단순한 오류로 끝나지 않는다. 실제 사람에게 불이익이 될 수 있다.

4. 최종 결정은 누가 하는가?
AI가 정보를 제공하는 것과 사람을 대신해 결정하는 것은 다른 문제다.

이 네 가지를 생각해보면 “AI가 분석했으니 맞겠지.” 라는 생각에서 조금 벗어날 수 있다.

결국 중요한 것은 ‘무엇을 AI에게 맡길 것인가’ 다

처음에는 이런 질문으로 시작했다.

AI는 미래를 예측할 수 있을까?

AI는 많은 데이터를 분석해 가능성을 계산할 수 있다.

어떤 분야에서는 인간보다 훨씬 많은 정보를 분석하고 더 좋은 예측을 만들어낼 수도 있다.

하지만 인간과 사회의 미래는 조금 다르다.

사람의 선택이 있고, 환경이 바뀌고, 예상하지 못한 일이 계속 발생한다.

그리고 설령 AI가 상당히 좋은 예측을 만들어낸다고 해도 마지막 질문은 남는다.

그 예측을 가지고 우리는 무엇을 할 것인가?

AI는 가능성을 계산할 수 있다.

하지만 어떤 위험을 받아들일지, 누구에게 기회를 줄지, AI가 틀렸을 때 누가 책임질지는 결국 사람이 결정해야 한다.

처음에는 AI의 성능에 대한 이야기라고 생각했는데, AI Snake Oil의 주장을 따라가다 보면 결국 인간의 판단에 대한 이야기로 돌아온다.

어쩌면 AI 시대에 필요한 능력도 비슷하지 않을까.

AI를 무조건 믿는 것도 아니고, 무조건 의심하는 것도 아니다.

AI가 잘할 수 있는 일과 사람이 판단해야 하는 일을 구분하는 것.

AI가 더 똑똑해질수록 오히려 이 구분이 더 중요해질 것 같다.

참고 자료

Arvind Narayanan · Sayash Kapoor, 《AI Snake Oil: What Artificial Intelligence Can Do, What It Can’t, and How to Tell the Difference》
Princeton University, AI Snake Oil: A conversation with Princeton AI experts Arvind Narayanan and Sayash Kapoor
Princeton School of Public and International Affairs, AI Snake Oil excerpt

OpenAI Codex 사용법 4편｜Codex를 쓴다면 GitHub를 써야 하는 이유

zeucise — Sun, 13 Sep 2026 12:52:21 +0900

OpenAI Codex와 GitHub Desktop을 이용해 프로젝트 버전을 관리하는 방법

지난 글에서는 Codex에게 직접 프로그램을 만들어보게 했다.

프롬프트만 입력했는데 Python 코드부터 테스트까지 수행해줬다.

그런데 앞으로 Codex에게 이런 요청을 계속한다고 생각해보자.

이 기능을 추가해줘.

이 코드를 수정해줘.

오류를 찾아서 고쳐줘.

Codex가 알아서 수정을 해주니까 처음엔 편하다.

Codex을 통해 계속 수정하다 보면 어느 순간 이런 생각이 든다.

원래 코드가 뭐였지?

또는

Codex가 잘못 수정하면 이전 상태로 어떻게 돌아가지?

이럴 때 필요한 것이 Git이다.

이번에는 Git의 기본 개념을 알아보고, GitHub Desktop을 이용해 지난 글에서 만든 프로젝트를 실제로 관리해보려고 한다.

Git은 무엇일까?

Git은 프로그램의 변경 이력을 관리하는 도구다.

쉽게 말하면 프로그램의 상태를 중간중간 저장해두고, 무엇이 바뀌었는지 확인할 수 있게 해준다.

예를 들어 프로그램을 만들면서 이런 과정을 거쳤다고 해보자.

처음 프로그램
↓
기능 추가
↓
오류 수정
↓
새 기능 추가

그러면 나중에

언제 코드가 바뀌었는지
무엇이 바뀌었는지
이전에는 어떤 상태였는지

확인할 수 있다.

AI가 직접 파일을 수정하는 환경에서는 이런 기록이 더 중요해진다.

Git과 GitHub는 같은 것일까?

처음에는 이 둘도 헷갈릴 수 있다.

간단하게 구분하면 된다.

Git
→ 내 컴퓨터에서 프로그램의 변경 이력을 관리

GitHub
→ Git으로 관리하는 프로젝트를 인터넷에 저장하고 공유

즉, Git과 GitHub는 같은 것이 아니다.

Git은 버전을 관리하는 도구이고, GitHub는 Git 저장소를 온라인에서 관리할 수 있게 해주는 서비스다.

그리고 GitHub를 사용한다고 프로젝트를 반드시 공개해야 하는 것도 아니다.

나만 볼 수 있는 Private Repository로 저장할 수도 있다.

왜 Codex를 쓰는데 Git이 필요할까?

사실 사람이 코딩할 때도 Git은 많이 사용한다.

그런데 AI 코딩에서는 더 중요하다고 생각한다.

Codex에게 한 번 요청했는데 여러 파일을 한꺼번에 바꿀 수도 있기 때문이다.

Git을 사용하면 아래와 같이 동작을 한다.

정상적으로 동작하는 상태 저장
↓
Codex에게 수정 요청
↓
변경사항 발생
↓
기존 상태와 비교
↓
문제가 있으면 수정 또는 되돌리기

그래서 Git은 개발자만 사용하는 어려운 도구라기보다 Codex가 내 코드를 수정하기 전에 만들어두는 안전장치라고 생각하면 편하다.

GitHub Desktop을 사용해보자

Git을 사용하는 방법은 크게 두 가지가 있다.

명령어를 직접 입력할 수도 있지만, 처음 사용하는 사람에게는 GitHub Desktop이 훨씬 이해하기 쉽다.

GitHub Desktop에서는 파일 변경 내용을 확인하고 Commit을 만들거나 GitHub에 Push하는 작업을 화면에서 처리할 수 있다. GitHub 공식 문서에서도 로컬 Repository를 추가하고 변경사항을 Commit한 뒤 GitHub에 게시하는 흐름을 제공하고 있다.

이번 글에서는 Git 명령어를 외우기보다 GitHub Desktop 화면을 기준으로 진행해보려고 한다.

1. GitHub Desktop 설치

먼저 GitHub Desktop을 설치한다.(정식사이트 : https://github.com/apps/desktop)

설치가 끝나면 GitHub 계정으로 로그인한다.

GitHub 계정이 없다면 먼저 계정을 만들어야 한다.

그렇게 설치하다가 보면 선택하는 것 중에서는 tutorial로 선택하면, 아래와 같은 화면이 나온다.

Windows에서 GitHub Desktop을 설치하고 GitHub 계정으로 로그인한 화면

이제 New repository를 선택해서, 우리의 프로젝트를 새로 만들어보자

New repository 설정해 보자

codex-file-analyzer 으로 이름을 설정하고, Create repository를 클릭

3편에서 프로젝트로 만든 codex-file-analyzer 으로 이름을 설정하고, Create repository를 클릭한다.

그럼 새로운 폴더가 만들어진다.

그럼 이제 GitHub Desktop에서 내 로컬 프로젝트와 GitHub 저장소를 관리할 수 있다.

2. 지난 글의 프로젝트를 Git으로 관리해보자

3편에서 만든 파일은 아래와 같다. (이번에도 새로운 프로그램을 만들지는 않는다.)

codex-file-analyzer/
├─ file_analyzer.py
├─ test_file_analyzer.py
└─ README.md

이 폴더에 있던 파일을 이번에 새로 만든 폴더에 복사를 한다.

그리고, Windows Powershell를 실행 후 아래와 같은 명령어를 입력한다.

아래의 명령어는

cd c:\GitHub\codex-file-analyzer
pwd

현재 위치도 확인한다.

프로젝트 폴더가 맞다면 다음 명령을 한 번 실행한다.

git init

git init은 어려운 명령이 아니다.

“이 폴더의 변경 이력을 지금부터 Git으로 관리하겠다.”

라는 의미다.

한 프로젝트에서 처음 한 번만 실행하면 된다. 이제 이 폴더는 Git Repository가 된다.

그 후, GitHub Desktop에 가보면 위와 같이 파일이 추가된 것이 보인다.

이제는 사용할 수 있는 상태가 되었다.

그럼, 사용할 때 반드시 알아야 할 용어들을 설명하겠다.

Changes는 무엇일까?

GitHub Desktop 왼쪽을 보면 Changes라는 영역이 있다. 위의 그림에서 보면 3 changed files 라고 나오는 것을 알 수 있다.

여기에는 아직 Git에 저장하지 않은 파일들이 표시된다.

README.md
file_analyzer.py
test_file_analyzer.py

앞으로 Codex가 파일을 수정하면 어떤 파일이 바뀌었는지 이곳에서 바로 확인할 수 있기 때문이다.

파일을 클릭하면 실제 코드가 어떻게 바뀌었는지도 확인할 수 있다.

이 부분은 다음 글에서 직접 사용해볼 예정이다.

Commit은 무엇일까?

이제 Git에서 가장 중요한 개념 중 하나가 나온다.

바로 Commit이다.

Commit은 현재 프로젝트의 상태를 하나의 기록으로 저장하는 것이다.

“지금 이 상태는 정상적으로 동작하니 기억해둬.”

라고 Git에게 알려주는 것과 비슷하다.

GitHub Desktop 왼쪽 아래에는 Commit 메시지를 입력하는 영역이 있다.

Initial file analyzer

라고 입력한다. (아래의 그림을 참조하자)

그리고 Commit to main 버튼을 누른다.

그런데 Commit했다고 GitHub에 올라간 것은 아니다

이 부분은 처음 사용할 때 헷갈리기 쉽다.

지금까지 만든 Commit은 내 컴퓨터에 저장된 기록이다.

아직 GitHub 인터넷 서버에는 올라가지 않았다.

내 컴퓨터

Git Repository
    ↓
Commit 완료


GitHub

아직 없음

이제 이 프로젝트를 GitHub에도 저장해보자.

GitHub에 프로젝트를 올려보자

GitHub Desktop 상단을 보면:

Publish repository

버튼이 있다.

버튼을 누르면 Repository 이름과 설명을 입력할 수 있다.

이름은 그대로 사용해도 된다.

codex-file-analyzer

여기서 한 가지 중요한 설정이 있다.

이제 Publish Repository 를 눌러보자

Keep this code private 옵션이다.

처음 연습하는 프로젝트라면 이 옵션을 켜고 Private Repository로 시작하는 것을 추천한다.

GitHub Desktop 공식 문서에서도 Publish Repository 과정에서 Repository 이름과 설명을 정하고, Keep this code private를 통해 비공개 여부를 선택할 수 있다.

설정을 확인한 뒤 Publish Repository 를 누른다.

GitHub에서 확인해보자

게시가 끝나면 GitHub 웹사이트에서도 Repository를 확인할 수 있다.

이제, 업데이트가 된 것을 볼 수 있다.

정상적으로 올라갔다면 아래처럼 프로젝트 파일이 보인다.

codex-file-analyzer

├─ README.md
├─ file_analyzer.py
└─ test_file_analyzer.py

GitHub의 Repository는 원격 저장소이고, 로컬 Repository와 연결하면 컴퓨터에서 만든 변경사항을 GitHub와 동기화할 수 있다.

이제 프로그램은 내 컴퓨터 ↔ Github 두 곳에서 관리할 수 있는 상태가 됐다.

GitHub에 올리기 전에 꼭 확인할 것이 있다

모든 파일을 GitHub에 올려도 되는 것은 아니다.

.env
API Key
비밀번호
인증정보
개인 설정 파일

같은 정보는 GitHub에 올리지 않는 것이 좋다.

이런 파일은 .gitignore를 이용해 Git의 관리 대상에서 제외할 수 있다.

Python 프로젝트라면 예를 들어 아래와 같이 사용할 수 있다.

__pycache__/
.venv/
.env

특히 앞으로 Codex에게 API를 사용하는 프로그램을 만들게 되면 .env에 중요한 키가 저장되는 경우가 있기 때문에 Commit이나 Publish 전에 어떤 파일이 포함되어 있는지 확인하는 습관이 중요하다.

GitHub Desktop에서는 Git 명령어가 어떻게 보일까?

Git을 공부하다 보면 이런 명령어를 많이 보게 된다.

git status
git add
git commit
git push

GitHub Desktop을 사용하면 대부분 화면에서 처리할 수 있다.

git status
→ Changes 화면 확인

git add
→ Commit할 파일 선택

git commit
→ Commit 버튼

git push
→ Push origin

처음부터 명령어를 모두 외울 필요는 없다. GUI로 개념을 이해한 뒤 필요할 때 CLI 명령어를 익혀도 충분하다.

Codex와 GitHub를 같이 쓰면 어떻게 될까?

이제야 3편과 4편이 연결된다.

Codex로 프로그램 생성
↓
Git으로 변경 이력 관리
↓
Commit
↓
GitHub에 저장

이제 Codex에게 다시:

현재 프로그램에
전체 파일 개수도 함께 표시하도록 수정해줘.

라고 요청한다고 생각해보자.

그러면 Codex가 파일을 수정한다.

GitHub Desktop을 열면 바로 Changes에 변경된 파일이 나타난다.

그리고 수정 전 코드와 수정 후 코드의 차이도 확인할 수 있다.

바로 이 과정을 다음 글에서 해보려고 한다.

다음에는 Codex가 무엇을 바꿨는지 확인해보자

이제 첫 번째 버전을 Git과 GitHub에 저장했다.

다음 글에서는 실제로 Codex에게 코드를 수정시켜볼 예정이다.

AI는 어떻게 기억할까?｜Agent Zero Memory로 보는 AI의 기억

zeucise — Sat, 12 Sep 2026 22:33:27 +0900

Agent Zero Memory의 시간 기억, 관계 기억, 장기 지식 구조를 표현한 AI 메모리

AI를 사용하다가 보면 나에 대해서 잘 아는 것 처럼 보인다.

물론, 나와의 대화 속에 내가 어떤 사람인지를 추측할 수 있는 단서는 많다.

그럼, AI는 대체 어떻게 기억하는 걸까?

아니면 나와의 기억을 모두 저장하는 것일까?

최근 이와 관련된 재미있는 논문을 하나 읽었다.

Agent Zero Memory: Provenance-Aware Long-Term Memory for LLM Agents(https://arxiv.org/pdf/2608.29606)

`26년 8월 공개된 논문으로, AI가 이전 대화나 파일, 프로젝트 내용을 어떻게 기억하고 필요할 때 다시 찾을 것인지를 다룬다.

AI는 모든 대화를 저장하고, 필요한 때에 찾아서 불러 오는 것이라 생각했다.

그런데 논문을 읽어보니 중요한 것은 저장이 아니었다.

필요한 순간에 필요한 기억을 어떻게 찾아올 것인가?

오히려 이런 질문에 가까웠다.

AI가 기억한다는 것은 그냥 저장하는 것이 아니다

예를 들어 프로젝트를 진행하면서 이런 일이 있었다고 해보자.

7월 1일
서비스 출시일을 9월 1일로 결정

8월 10일
테스트 과정에서 문제 발견

8월 14일
출시일을 9월 15일로 변경

현재 출시일만 알고 싶다면 간단하다. "9월 15일"

이것만 저장하면 된다.

그런데 이렇게 물어본다면 이야기가 달라진다.

원래 출시일은 언제였고, 왜 바뀌었지?

이 질문에 답하려면 현재 날짜뿐 아니라 처음 결정한 내용, 변경된 시점, 그 이유까지 기억해야 한다.

Agent Zero Memory는 이런 문제를 해결하기 위해 하나의 기억 저장소가 아니라 세 가지 기억 구조를 동시에 사용한다.

참고로 Agent Zero Memory는 이 논문에서 제안한 AI 장기 기억 시스템이다.

이전 대화나 파일, 작업 기록을 저장해두는 것에서 끝나지 않고, 필요한 순간에 관련 기억을 찾아 근거와 함께 다시 사용할 수 있도록 설계되었다.

AI가 기억하기 위한 세 가지 구조

논문에서 가장 재미있었던 부분이다.

같은 과거 기록을 시간, 관계, 중요한 정보라는 서로 다른 관점으로 정리한다.

구분	기억 구조	쉽게 생각하면(예시)	잘하는 질문
시간	Memory Events	일기장	언제 무슨 일이 있었지?
관계	Entity–Event Graph	관계도	누가 무엇과 연결되어 있지?
중요한 정보	HDM	잘 정리된 노트	계속 기억해야 할 것은 무엇이지?

1. Memory Events는 ‘시간의 흐름’ 을 기억한다

쉽게 말하면 AI의 일기장이다.

앞의 사례라면 단순히 "출시일 = 9월 15일" 만 남기는 것이 아니다.

7월 1일 → 출시일 9월 1일로 결정
8월 10일 → 테스트 문제 발생
8월 14일 → 출시일 9월 15일로 변경

처럼 변화 과정 자체를 기억한다.

그래서 나중에

원래 출시일은 언제였지?

언제 일정이 변경됐지?

같은 질문도 할 수 있다.

시간 흐름에 따라 현재의 상황을 기록하는 것이라 생각하면 될 것 같다.

2. Entity Event Graph는 기억 사이의 관계를 연결한다

두 번째는 Entity Event Graph다. AI 기억의 관계도라고 생각하면 쉽다.

예를 들어 보자

서로 다른 대화에서 다음과 같은 이야기가 나왔다고 해보자.

김 팀장 → Project A 담당
Project A → 서버 이전
서버 이전 → B사 담당

이 정보가 모두 같은 대화에 있다는 보장은 없다.

한 달 전에 김 팀장 이야기를 했고, 이후 서버 이전을 이야기하고, 며칠 뒤 B사를 이야기했을 수도 있다.

그런데 나중에

김 팀장이 담당했던 프로젝트의 서버 이전 업체가 어디였지?

라고 물으면 여러 기억을 연결해야 한다.

그래프에서는 이런 식으로 관계를 따라간다.

김 팀장
   ↓
Project A
   ↓
서버 이전
   ↓
B사

Memory Events가 언제 무슨 일이 있었는가를 기억한다면, Entity Graph는 그 일들이 서로 어떻게 연결되어 있는가를 기억한다.

3. HDM은 계속 기억해야 할 내용을 정리한다

마지막은 HDM(Hierarchical Documentary Memory)이다.

이름은 어렵지만 개념은 단순하다. AI가 계속 참고해야 할 내용을 따로 정리한 장기 노트라고 생각하면 된다.

예를 들면 이런 정보다.

주로 사용하는 프로그램
진행하고 있는 프로젝트
선호하는 작업 방식
중요한 사람이나 조직
자주 사용하는 설정

재미있는 것은 하나의 기억도 단계별로 나눈다는 점이다.

L0 → 한 줄 요약
L1 → 조금 더 자세한 설명
L2 → 전체 내용

예를 들면, 아래와 같이 기록한다.

L0
사용자는 Python을 주로 사용한다.

L1
데이터 분석과 자동화 작업에서 Python을 주로 사용한다.

L2
사용했던 프로젝트와 라이브러리,
관련 작업 기록 등

간단한 질문이면 짧은 요약만 확인하고, 더 자세한 정보가 필요할 때만 아래 단계까지 내려간다.

결국 AI가 과거 기록을 매번 처음부터 끝까지 모두 읽을 필요가 없는 것이다.

상황에 따라 요약, 자세한 설명, 전체내용으로 읽어 간다는 것이다.

결국 많이 기억하는 것보다 ‘잘 찾는 것’ 이 중요하다.

세 가지를 다시 정리하면 생각보다 단순하다.

Memory Events는 일기장이고, Entity Graph는 관계도이며, HDM은 잘 정리된 장기 노트다.

AI가 모든 정보를 하나의 거대한 저장공간에 넣는 것이 아니라,

질문에 따라 필요한 기억을 다른 방식으로 찾는다.

우리와 자료를 정리하는 방식이 비슷했다.

필요한 내용을 한꺼번에 보관하는 것이 아니라 용도별로 정리해서 따로 보관하기 때문이다.

AI도 크게 다르지 않은 것 같다.

처음에는 사람의 기억 방식과 닮았다는 생각도 들었다.

다만 이 구조가 인간의 기억을 그대로 모방했다기보다는, 서로 다른 질문을 효율적으로 처리하기 위해 기억을 나눈 설계에 가깝다.

위의 내용대로 라면 엄청난 저장소가 필요할 것 같다. 또, 이 내용을 계산할 수 있는 메모리도 필요할 것 같다.

여기까지 읽고 나니 또 궁금해졌다.

AI가 더 많은 정보를 기억하고 처리할수록 실제 데이터센터의 메모리도 더 많이 필요한 걸까?

모델보다 Memory가 더 중요해질 수도 있을까?

논문에서는 같은 Agent Zero Memory 구조를 유지한 채 백본 LLM만 8개로 바꿔 LongMemEval 성능을 비교했다.

가장 높은 정확도는 95.6%였고, 가장 낮은 모델도 92.2%였다.

차이는 3.4%p였다. 반면 질문당 비용은 모델에 따라 약 30배 차이가 났다

동일한 Agent Zero Memory 구조에서 8개 백본 LLM의 LongMemEval 정확도와 질문당 비용을 비교한 결과

물론 이 결과만 보고 "이제 좋은 모델은 필요 없다." 라고 말할 수는 없다.

특정 Memory Benchmark에서 나온 결과이기 때문이다.

그래도 한 가지 생각은 든다.

지금까지는 새로운 AI가 나오면 "얼마나 똑똑해졌지?" 부터 확인했다.

그런데 앞으로 개인 AI나 AI Agent를 오래 사용하게 되면, 다른 질문이 더 중요해질지도 모르겠다.

이 AI는 내가 했던 일을 얼마나 잘 기억하지?

그리고 또 하나,

필요한 기억을 얼마나 정확하게 꺼내오지?

AI에게 좋은 모델만큼 ‘좋은 기억’도 중요해질까?

이번 논문을 읽기 전에는 AI Memory를 이전 대화를 저장해두는 기능 정도로 생각했다.

그런데 생각보다 훨씬 복잡했다.

무슨 일이 있었는지, 언제 바뀌었는지, 서로 어떤 관계가 있는지, 어떤 내용은 오래 기억해야 하는지,

그리고 그 기억이 어디에서 나온 것인지까지 관리해야 한다.

앞으로의 AI 경쟁은 누가 더 똑똑한 모델을 만드느냐뿐 아니라, 누가 더 잘 기억하고 필요한 순간에 정확히 꺼내오느냐의 경쟁이 될지도 모르겠다. 이런 AI가 많아질수록 데이터센터에서는 또 다른 의미의 Memory도 더 많이 필요해진다는 점이다.

소프트웨어에서는 AI가 무엇을 기억할지 고민하고, 하드웨어에서는 그 데이터를 어떻게 더 빠르게 처리할지 고민한다.

서로 전혀 다른 Memory지만 AI가 발전할수록 둘 다 중요해지고 있다.

앞으로의 AI 경쟁은 어쩌면

누가 더 똑똑한 모델을 만드느냐에서 한 단계 더 나아가, 누가 더 잘 기억하고, 그 기억을 더 빠르게 처리하느냐의 경쟁으로 이어지고 있는지도 모르겠다.

참고한 논문

Agent Zero Memory: Provenance-Aware Long-Term Memory for LLM Agents
Ming Wu, Pengyuan Zhu / 2026

2026년 8월 30일 공개된 arXiv 프리프린트다. 논문은 LongMemEval 95.60%, LoCoMo 93.60%를 보고하고 있다. 아직 초기 공개 연구이고 기존 시스템들과 모든 조건을 동일하게 맞춘 직접 비교 결과는 아니라는 점은 함께 참고할 필요가 있다.

AI 보고서 작성 자동화｜8단계 프롬프트 한 번에 사용하는 방법(템플릿 포함)

zeucise — Fri, 11 Sep 2026 14:26:05 +0900

AI 보고서 작성 자동화 프롬프트를 ChatGPT Claude Codex로 활용하는 8단계 실무용 템플릿

앞에서 AI로 보고서를 작성할 때 사용할 수 있는 방법을 1편부터 8편까지 소개했다.

작성의 흐름은 다음과 같다.

01. 자료의 변화와 이상점 찾기 
02. 주장과 근거 검증
03. "그래서?" 질문하기
04. 대안 넓히기
05. 상사 관점에서 질문하기 
06. 반대 관점에서 검토하기 
07. 숫자·날짜·금액 검증 
08. 필요한 부분만 수정하기

그런데, 실제로 업무에서 직접 써보려면, 매번 복사한 프롬프트를 찾아서 복사를 해서 붙여넣기를 하던, 타이핑을 하던 해야한다.

상당히 번거롭다.....

그래서 이번에는 이 과정을 자동화 할 수 있는 방법을 소개한다.

마지막에는 다운로드 할 수 있도록 파일도 올려놓겠다.

어떤 보고서에 쓰면 좋을까?

모든 보고서에 8단계를 전부 사용할 필요는 없다.

월간 현황 보고서처럼 간단한 문서라면, 01 → 03 → 08만 사용해도 무방하다.

반대로 시스템 구축, 예산 요청, 투자 검토처럼 근거·대안·승인이 중요한 보고서라면 1~8단계를 모두 실행해보는 편이 좋다.

결국 이 프롬프트는 AI에게 보고서를 대신 쓰게 하는 것보다 내가 놓친 부분을 단계별로 확인하는 검토 도구에 가깝다.

연속된 프롬프트 사용방법

★ ChatGPT, Claude 에서 사용한다면

원본 보고서나 Excel, PDF 같은 자료와 00_master.md를 포함한 프롬프트를 함께 첨부한 뒤 이렇게 요청하면 된다.

첨부한 00_master.md의 순서대로
보고서를 검토해줘.

보고 목적: 시스템 개선안 검토
보고 대상: 담당 임원
최종적으로 받고 싶은 결과:
의사결정에 필요한 핵심 내용이 포함된 보고서

ChatGPT는 문서·스프레드시트 등 파일을 업로드해 분석할 수 있기 때문에 원본 자료와 프롬프트를 함께 사용하는 방식이 가장 간단하다. 위의 프롬프트를 자주 쓴다면 Project를 만들어 파일과 지침을 보관할 수도 있다.

★ Codex에서 사용한다면

Codex에서는 프롬프트 파일과 보고서 자료를 하나의 작업 폴더에 넣어두는 방식이 편하다.

아래 예시는 report 폴더 안에 프롬프트를 넣고, 참고가 될 자료는 source 폴더에 저장한다.

report/
├─ 00_master.md
├─ 01_change_analysis.md
├─ ...
├─ 08_final_edit.md
└─ source/
   ├─ 기존보고서.md
   └─ 참고자료.xlsx

위의 처럼 폴더에 파일을 저장하고, 아래와 같이 요청한다.

00_master.md를 읽고
source 폴더의 자료를 기준으로
1~8단계를 순서대로 실행해줘.

중간 결과와 최종 보고서는
output 폴더에 Markdown 파일로 저장해줘.

Codex처럼 실제 파일을 다루는 환경에서는 파일명과 폴더 위치를 프롬프트에 명확하게 적어주는 방식이 특히 유용하다.

OpenAI도 Codex 작업 지시에서 관련 파일 경로나 구성 요소를 구체적으로 알려주는 방식을 권장한다.

클로드 데스크탑도 위와 크게 다르지 않다.

하지만, 중요한 보고서는 한 단계씩 실행하는 편이 낫다

위의 내용대로 하면 빠르게 전체 과정을 확인할 때 편하다.

다만 예산이나 중요한 의사결정이 포함된 보고서라면 개인적으로는 순서로 하나씩 실행하는 방법을 추천한다.

이유는 간단하다. 중간 단계에서 AI가 잘못 이해한 내용이 있으면 바로 수정할 수 있기 때문이다.

그렇다면 위의 문장에 한 문장만 추가하면 된다.

00_master.md를 읽고
source 폴더의 자료를 기준으로
1~8단계를 순서대로 실행해줘.

단계가 끝날때 마다 다음 단계를 진행할지를 승인받고 진행해줘

중간 결과와 최종 보고서는
output 폴더에 Markdown 파일로 저장해줘.

회사 보고서에 맞게 바꿔서 사용해도 된다

프롬프트를 그대로 사용할 필요도 없다. 예를 들어 IT 보고서라면 대안 비교 기준에 아래와 같은 내용으로 수정한다.

개발 난이도
운영 부담
보안 영향
기존 시스템 영향

투자 보고서라면 아래와 같은내용으로 수정하면 된다.

투자비
예상 수익
회수 기간
시장 위험

상사 질문도 회사에서 자주 나오는 질문이 있다면 직접 추가하면 된다.

결국 이 프롬프트는 완성 된 정답이라기보다 회사와 업무에 맞게 고쳐 쓰는 기본 틀이라고 생각하면 좋다.

report_prompt_template.zip

0.01MB

OpenAI Codex 사용법 3편｜AI에게 코딩시키는 방법

zeucise — Fri, 11 Sep 2026 13:06:40 +0900

OpenAI Codex에서 프롬프트로 Python 프로그램을 만들고 테스트하는 방법

지난 글에서는 Windows에서 Codex GUI와 CLI를 설치하고 실행해봤다.

이제 Codex를 사용할 준비는 끝났다.

그런데 막상 화면을 열면 또 하나의 문제가 생긴다.

Codex에게 뭐라고 입력해야 할까?

ChatGPT처럼 그냥 질문해도 쉽게 만들 수 있다.

하지만, Codex는 하나의 작업을 맡기는 방식으로 사용할 때 더 편하다.

이번에는 간단한 프로그램을 만들면서, Codex에게 어떻게 하면 되는지 직접 해보려고 한다.

그냥 이렇게 요청해도 된다

Codex에게 이렇게 요청할 수 있다.

폴더 안의 파일을 분석하는 프로그램을 만들어줘.

이 정도만 입력해도 Codex는 프로그램을 만들 수 있다.

하지만 문제가 하나 있다.

내가 원하는 프로그램이 정확히 어떤 프로그램인지 Codex는 알 수 없다.

예를 들어

어떤 프로그램 언어로 만들지
파일을 이동해야 하는지
확장자만 확인하면 되는지
외부 라이브러리를 사용해도 되는지
테스트까지 해야 하는지

같은 조건이 빠져 있다.

그래서 작업이 조금 복잡해지면 무엇을 원하는지 조금 더 구체적으로 알려주는 것이 좋다.

Codex에게 일을 맡길 때 필요한 4가지

개인적으로는 4가지 정도만 생각하면 충분하다.

1. 목표 : 무엇을 만들 것인가

2. 프로그램 요건 :  어떤 프로그램이 필요한가

3. 제한사항 : 어떤 조건을 지켜야 하는가

4. 완료조건 : 어디까지 하면 작업이 끝나는가

쉽게 말하면 회사에서 동료에게 일을 요청하는 것과 비슷하다.

단순히 "이거 만들어줘" 라고 하는 것보다, 어떻게 할지를 명확히 알려준 것이다.

우리는 이제 python이라는 프로그램 언어를 통해 간단한 프로그램을 만들려고 한다.

실제로 프로그램을 만들어 보자.

※ 처음에는 사용법을 모두 기재하지만 앞으로는 실행화면만 스크린샷을 찍을 예정이다.

■ GUI를 사용한다면 새로운 프로젝트 폴더를 하나 만들어 Codex에서 연다.

codex에서 프로젝트에서 + 버튼을 클릭

프로젝트를 저장할 위치를 로컬로 선택

폴더를 만든다.

프로젝트 이름 작성한다.

■ CLI라면 아래의 명령어를 통해 폴더를 만들고 Codex를 실행한다.

cd $home
mkdir codex-file-analyzer
cd codex-file-analyzer
codex

Windows Powershell에서 위의 명령어를 복사하여 실행

위와 같은 화면이 나온다.

■ 요청

아주 간단하게 요청해본다.

폴더 안의 파일을 확장자별로
분석하는 Python 프로그램을 만들어줘.

GUI에서 프롬프트가 실행되고 있다.

CLI에서 프롬프트가 실행되고 있다.

■ 결과

GUI 실행결과

CLI 실행결과

위의 내용들을 보면 어떠한 방법을 쓰더라도 프로그램은 만들어준다.

하지만 그 프로그램이 정상적으로 동작하는지는 알 수가 없다.

그래서 이번에는 조금 더 자세하게 요청해본다.

■ 요청

내용은 조금 길어졌지만 구조는 단순하다.

무엇을 만들지, 무엇을 하지 말아야 할지, 어디까지 확인할지를 알려준 것이다.

현재 프로젝트에 Python 프로그램을 만들어줘.

목표:
지정한 폴더의 파일을 확장자별로 세어서 출력한다.

조건:
- Python 기본 라이브러리만 사용한다.
- 파일을 삭제하거나 이동하지 않는다.
- 기존 파일이 있다면 먼저 확인한다.

완료 조건:
- 프로그램이 정상적으로 실행되어야 한다.
- 간단한 테스트를 작성한다.
- 테스트를 직접 실행해서 통과 여부를 확인한다.
- 사용 방법을 README.md에 작성한다.

GUI 화면

CLI 실행화면

■ 결과

GUI 실행결과

CLI 실행결과

위의 내용에서는 테스트를 하는 프롬프트를 넣었다.

각 프롬프트 실행결과에도 써 있든디 테스트를 실행하고 모두 통과라는 결과를 받았다.

그 이유는 프로그램은 실제로 동작하지 않는 이유는 너무 많다. 그래서 되도록이면 테스트를 기본적으로 하는 것이 좋다.

위의 내용 처럼 테스트가 정상적으로 통과했다면 적어도 조건에 명시한 프로그램이 정상적으로 동작했다는 의미이다.

실제로 해보니, 굉장히 간단하다.

Python이라는 프로그램 언어를 처음해본 사람들도 바로 프로그램을 만들었다.

프로그램을 전혀 못하는 사람들도 프롬프트만으로도 프로그램을 만들었다.

지금처럼 작은 프로그램은 바로 작업을 맡겨도 괜찮다.

프로젝트 단위의 프로그램이라면 바로 코드를 작성 또는 변경하게 하는 것보다

자세한 계획을 먼저 하게 하는 것이 방법이다.

Codex의 Plan 기능을 이용해 먼저 작업 방향을 정리한 뒤 프로그램을 작성하는 단계로 넘어가는 것이 좋다.

이 기능은 이후 조금 더 복잡한 프로젝트를 다룰 때 별도로 살펴보려고 한다.

다음 글에서는 실제로 프로그램을 변경해볼 예정이다.

변경사항에 대해서 어떻게 확인하는지에 대해서 살펴보려고 한다.

git diff를 이용해 Codex의 코드 리뷰 기능도 함께 사용해볼 예정이다.

AI 보고서 작성법 8편｜전체를 다시 쓰지 않는 안전한 수정법

zeucise — Thu, 10 Sep 2026 14:12:56 +0900

다시 쓰지 않고 필요한 부분만 안전하게 수정하는 방법

AI로 보고서를 작성하다 보면 항상 마지막 단계에서 욕심이 생긴다.

더 길게 쓰면 좋은 보고서가 될까? 줄이는 게 좋을까? 아니면 내용은 거의 완성됐는데 문장이 조금 마음에 들지 않는다.

사람이기 때문에 또는 내가 처음부터 작성한 내용이 아니라서 고치고 싶은 욕구가 생긴다.

나도그렇다.

그래서 처음에는 AI한테 이렇게 요청했다.

전체적으로 더 전문적으로 다시 써줘.
추가적인 내용을 찾아서 수정해줘.

결과물은 더 자연스러워지고, 내용이 더 길어질 수도 있다.

하지만 문제는 고치지 않아도 될 부분까지 같이 바뀔 수 있다는 것이다.

특정 문장 또는 특정부분만 고치고 싶었는데 숫자가 달라지거나, 확정한 표현의 의미가 미묘하게 바뀔 수도 있다.

1~7편까지 내용을 통해 어느 정도 보고서가 완성됐다면 전체 재작성보다 필요한 부분만 수정하는 편이 좋다.

수정 범위를 최대한 작게 잡는다

마지막에 보고서를 수정할 때는 이게 핵심인 것 같다.

다른 글에서도 이야기했지만, AI는 요청한 범위를 넘어 내용을 수정하는 경우가 있다. 불필요한 수정을 줄이려면 어디를, 무엇 때문에 고치려는지 정확하게 알려주는 게 좋다.

예를 들면 이렇게 요청할 수 있다.

결론 부분의 반복 표현을 줄여줘.
가능하면 분량을 약 30% 줄이되, 숫자와 판단 조건, 결론의 의미를 유지하는 것을 우선해줘.

3번 항목에서 반복되는 문장을 찾아줘. 아직 수정하지 말고, 겹치는 부분만 표시해줘.

근거가 부족한 문장은 임의로 보완하지 말고, 확인이 필요한 이유를 적어줘.

숫자와 날짜는 그대로 두고 문장 표현만 정리해줘.

단순히 “더 좋게 써줘”라고 하기보다 수정 대상과 목적을 정하는 것이다.

사실관계와 숫자를 직접 확인한 보고서라면, 수정 요청에 다음 조건도 넣을 수 있다.

아직 확인하지 않은 내용까지 “검증이 끝났다”고 적지는 않는다.

아래 보고서에서 지정한 부분만 수정해줘.

수정 대상: [예: 결론의 두 번째 문단]
수정 목적: [예: 반복 표현을 줄이고 문장을 간결하게 정리]

다음 조건을 지켜줘.
1. 숫자, 날짜, 금액, 고유명사를 변경하지 말 것.
2. 사실관계와 결론의 의미를 유지할 것.
3. '예정', '추정', '가능성', '검토 중' 등의 표현을
   확정적인 표현으로 바꾸지 말 것.
4. 판단에 필요한 조건과 예외를 삭제하지 말 것.
5. 원문에 없는 사실, 원인, 대안, 실행 계획을 추가하지 말 것.
6. 요청한 범위 밖의 내용은 수정하지 말 것.
7. 오류나 모순이 의심되면 임의로 고치지 말고
   '확인 필요' 항목으로 따로 적을 것.

출력 형식:
- 수정한 문단
- 변경 내역: 기존 표현 / 수정 표현 / 수정 이유
- 확인 필요 사항: 없으면 '없음'

[수정할 문단 붙여넣기]

같은 문단을 실제로 줄여보면

아래는 부분 수정 방법을 설명하기 위한 가상의 보고서 문단과 수정 예시다. 실제 업무 결과나 AI 실행 기록은 아니다.

원문

시스템 운영팀은 9월 30일까지 응답 지연의 원인을 분석할 예정이다. 원인 분석을 마친 뒤에는 분석 결과를 바탕으로 서버 증설이 필요한지 검토할 예정이다.

이 문단은 내용이 어렵지는 않지만, “원인 분석”이라는 표현이 반복된다. 이때 필요한 작업은 새로운 해결책을 넣는 것이 아니라 반복을 줄이는 것이다.

수정 요청

위 문단의 반복 표현을 줄여줘. 시스템 운영팀이라는 담당 조직과 9월 30일이라는 분석 기한은 유지해줘. 서버 증설은 확정된 조치가 아니라 분석 결과를 바탕으로 필요성을 검토할 사항이라는 의미도 유지해줘.

수정문

시스템 운영팀은 9월 30일까지 응답 지연 원인을 분석할 예정이다. 분석 완료 후 그 결과를 바탕으로 서버 증설 필요성을 검토할 예정이다.

문장은 조금 짧아졌지만, 담당 조직과 분석 기한, 검토 예정이라는 상태는 그대로다. 원인 분석을 마친 뒤 증설 필요성을 검토한다는 순서도 유지했다.

반대로 다음처럼 줄이면 의미가 달라진다.

시스템 운영팀은 응답 지연을 해결하기 위해 9월 30일까지 서버 증설을 추진한다.

원문에서 9월 30일은 원인 분석의 기한이었다. 그런데 이 문장에서는 서버 증설의 기한처럼 읽힌다. 아직 검토할 사항이었던 서버 증설도 실행할 계획으로 바뀌었다. 문장이 매끄러운지만 보면 지나칠 수 있는 차이다. 그래서 마지막 수정에서는 무엇을 짧게 만들었는지보다, 줄이는 과정에서 어떤 의미가 사라졌는지를 확인해야 한다.

무엇이 바뀌었는지도 같이 확인한다

보통은 수정된 보고서를 보고, 문제가 없으면 최종본으로 생각한다.

하지만 AI가 무엇을 왜 수정했는지도 같이 받아보는 것이 좋다. 내가 요청한 방향대로 고쳤는지 비교하기 쉬워지기 때문이다.

수정된 보고서만 받지 않고, 수정사항 및 이유를 같이 요청한다.

원문과 수정문을 비교해서 변경한 부분을 정리해줘.

형식:
기존 표현 / 수정 표현 / 수정 이유

숫자, 날짜, 담당 조직, 확정 여부, 판단 조건에
변경이 있는지도 별도로 확인해줘.

수정하지 않은 문장은 변경 내역에 포함하지 말아줘.

다만 AI가 작성한 변경 내역도 빠진 부분이 있을 수 있다. “의미를 유지했다”는 설명만 보고 확인을 끝내지는 않는다. 원문과 수정문을 직접 비교해야 한다.

앞의 예시라면 다음 항목을 확인하면 된다.

확인 항목	확인할 내용
담당 조직	시스템 운영팀이 그대로 유지됐는가?
날짜와 적용 대상	9월 30일이 여전히 원인 분석의 기한인가?
확정 여부	“검토할 예정이다”가 “추진한다” 또는 “확정했다”로 바뀌지 않았는가?
판단 조건	분석 결과를 바탕으로 증설 필요성을 검토한다는 조건이 남아 있는가?
수정 범위	원문에 없던 예산, 조치, 일정이 추가되지 않았는가?

수정한 문단의 앞뒤도 함께 읽어본다. 문단 하나만 보면 자연스러워도, 앞에서 설명한 내용이나 보고서의 요약·결론과 맞지 않을 수 있기 때문이다.

보고서를 고칠 때도 검토 범위를 관리한다

AI 코딩을 할 때 요청한 부분만 수정하는 것이 중요한 것처럼 보고서 수정도 비슷하다.

수정 범위를 작게 잡으면 어디를 다시 확인해야 하는지 분명해진다. 불필요한 재작성과 반복 검토를 줄이는 데도 도움이 된다.

다만 한 문장만 고쳤다고 해서 그 문장만 확인하면 되는 것은 아니다. 수정한 내용이 다른 문단의 판단이나 결론에 영향을 주는지도 살펴봐야 한다.

표현을 다듬다가 사실관계의 문제가 발견됐다면, 그 부분은 별도의 검증 작업으로 돌리는 게 좋다.

예를 들어 원인 분석 기한이 잘못됐다는 사실을 발견했다면, AI에게 자연스럽게 고쳐달라고 맡길 문제가 아니다. 근거 자료에서 정확한 날짜를 확인하고, 같은 날짜가 들어간 요약이나 일정표도 함께 수정해야 한다.

이번 시리즈에서 정리한 과정을 다시 보면 다음과 같다.

자료에서 변화 찾기
↓
주장과 근거 확인
↓
"그래서?" 질문하기
↓
대안 넓히기
↓
상사 입장에서 질문하기
↓
반대 입장에서 검토하기
↓
숫자 검증하기
↓
필요한 부분만 수정하기

7편의 숫자 검증까지 마쳤다면, 마지막에는 수정 대상과 목적을 정해 필요한 문장만 다듬는다.

수정 후에는 변경 내역을 원문과 비교하고, 주변 문맥과 최종 결론까지 맞는지 확인하자.

AI를 통해 보고서를 작성해 보니!

AI로 보고서를 작성할 때는 정말 그럴듯하게 써줘서 놀랐다. 초안을 빠르게 만들어주고, 자연스럽지 않은 문장을 고치는 데도 도움이 됐다.

이번 시리즈에서는 그렇게 글을 잘 쓰는 AI에게 검토자의 역할도 맡겨봤다.

무엇이 빠졌는지 찾고, 주장의 근거를 확인하고, 다른 가능성을 검토하고, 마지막에는 숫자와 수정 결과를 점검하는 과정이다.

AI가 제시한 질문이나 반론은 보고서를 다시 살펴보는 계기가 된다. 다만 어떤 근거를 채택하고, 어떤 결론을 남길지는 작성자가 판단해야 한다.

이 8단계는 보고서를 검토하는 한 가지 방법일 뿐이다. 모든 보고서에 같은 순서와 질문을 적용할 필요는 없다. 보고서의 목적과 자료에 따라 필요한 단계를 골라 쓰거나 질문을 바꿔도 된다.

마지막에 문장이 조금 아쉽더라도 전체를 다시 쓰기 전에 먼저 생각해보자.

지금 고치려는 부분은 어디인가?
무엇을 바꾸고, 무엇을 유지해야 하는가?

이 두 가지를 정하고 수정하면, 이미 확인한 내용을 지키면서 보고서를 마무리하는 데 도움이 된다.

시리즈의 8단계 프롬프트를 한곳에서 활용하고 싶다면 아래 글에 정리해두었다.

AI 보고서 작성 자동화｜8단계 프롬프트 한 번에 사용하는 방법(템플릿 포함)

AI 보고서 작성법 7편｜날짜·금액·비율을 따로 확인하는 숫자 검증법

zeucise — Thu, 10 Sep 2026 10:41:59 +0900

날짜 금액 비율 등 숫자를 따로 확인하는 보고서 숫자 검증 방법

AI가 작성한 보고서를 검토할 때 특히 신경 쓰이는 것이 숫자다. 물론, 사람이 직접 작성해도 틀리기 쉬운 것이 숫자다.

날짜, 금액, 비율, 인원, 기간처럼 틀리면 의미 자체가 달라질 수 있는 내용이다.

그런데 긴 보고서 안에서 숫자를 하나씩 찾아 원본과 비교하는 것은 생각보다 번거롭다.

이럴 때는 숫자만 별도로 추출해서 따로 확인하는 것이 편하다.

보고서의 숫자만 따로 추출한다

AI에게 다음처럼 요청할 수 있다. 숫자가 나온 문장과 원본 자료의 위치를 함께 정리하게 하면 대조하기가 쉽다.

첨부한 보고서에서 사용된 숫자를 모두 찾아
함께 제공한 원본 자료와 비교해줘.

다음 항목을 포함해줘.

- 날짜
- 금액
- 비율
- 인원
- 기간
- 수량

결과는 다음 표로 정리해줘.

보고서의 숫자 / 의미·단위 / 사용된 문장 /
원본 값과 자료 위치 / 계산식 / 확인 상태

확인 상태는 다음과 같이 구분해줘.

- 일치: 원본 또는 계산식과 일치
- 불일치: 원본 또는 계산식과 다름
- 확인 필요: 자료나 기준이 부족해 판단할 수 없음

추가로 다음도 확인해줘.

- 같은 항목의 숫자가 본문과 표에서 다르지 않은지
- 원·천 원·백만 원 등의 단위가 맞는지
- 날짜와 기간의 기준이 일치하는지
- %와 %p를 혼용하지 않았는지
- 계산에 사용한 값과 계산식이 맞는지

원본이 없으면 숫자가 그럴듯해도
'일치'로 표시하지 말아줘.
출처나 누락된 값을 임의로 만들지 말아줘.

보고서 본문은 아직 수정하지 말고,
불일치 항목에는 수정할 값과 이유를 함께 적어줘.

‘확인’이라고 적기 전에 근거를 남긴다

예를 들어 보고서에 매출 증가율 15%, 완료 예정일 9월 30일, 예상 비용 2억 원이 적혀 있다고 해보자.

다음은 설명을 위해 만든 가상 자료와 검토 예시다. 실제 업무 자료나 AI 실행 결과는 아니다.

보고서의 숫자	원본 자료에서 확인한 내용	대조 방법	확인 상태
매출 증가율 15%	월간 실적표: 전월 1억 원, 당월 1억 1,500만 원	(1억 1,500만−1억)÷1억×100 = 15%	일치
완료 예정일 9월 30일	최신 일정표의 완료 예정일: 9월 30일	같은 연도·같은 작업의 예정일임을 확인함	일치
예상 비용 2억 원	근거로 적힌 견적서가 제공되지 않음	금액과 포함 범위를 대조할 수 없음	확인 필요

여기서 2억 원은 틀렸다고 확인된 숫자가 아니다. 맞는지 판단할 자료가 없는 숫자다.

보고서에 ‘견적서 기준’이라고 적혀 있어도 실제 견적서를 확인하지 못했다면 검증을 마쳤다고 표시하면 안 된다.

실제 업무에서는 출처를 ‘실적표’라고만 적기보다 파일명, 시트명, 셀 또는 페이지까지 남겨두면 다시 확인하기 편하다.

숫자보다 단위와 기준을 먼저 확인한다

여기서 나는 단위나 출처가 정확한지를 확인하는 것에 가장 신경을 많이 쓴다.

같은 1,000이라는 숫자도 단위가 무엇이냐에 따라 의미가 달라진다.

1,000원
1,000천 원 = 100만 원
1,000만 원
1,000백만 원 = 10억 원

표 위에 ‘단위: 백만 원’이라고 적혀 있는데 숫자만 복사하면 금액을 잘못 옮기기 쉽다. AI에게 자료를 줄 때도 표 제목과 단위를 함께 보여주는 것이 좋다. 금액이 같더라도 범위가 다르면 비교 결과가 달라진다. 예를 들어 견적 금액에는 초기 도입비만 있고 보고서에서는 전체 사업비로 표현했을 수 있다.

금액을 확인할 때는 다음도 함께 본다.

부가세가 포함된 금액인가?
초기 도입비만 있는가, 운영비도 포함돼 있는가?
월간 비용인가, 연간 비용인가?
최신 견적서의 금액인가?

날짜도 마찬가지다. ‘9월 30일’이 계획상 완료 예정일인지, 실제 완료일인지 구분해야 한다. 기간은 영업일 기준인지 달력 날짜 기준인지에 따라 달라질 수 있다.

10% 증가와 10%p 증가는 다르다

비율도 주의해서 확인한다. 10% 증가와 10%p 증가는 다른 표현이다.

예를 들어 점유율이 20%일 때,

10%p 증가하면 20% + 10%p = 30%가 된다.
10% 증가하면 20% × 1.10 = 22%가 된다.

그렇다면 원본 자료의 점유율이 20%에서 30%로 바뀌었는데 보고서에 이렇게 적혀 있다면 어떨까?

수정 전

점유율은 20%에서 30%로, 10% 증가했다.

수정 후

점유율은 20%에서 30%로, 10%p 상승했다.

20%와 30%의 차이는 10%p다. 기존 점유율을 기준으로 증가율을 계산하면 (30−20)÷20×100 = 50%다.

따라서 “점유율이 50% 증가했다”도 계산상 맞지만, 이 예시에서는 “20%에서 30%로 10%p 상승했다”고 적으면 변화가 더 분명하게 보인다. 숫자 자체가 맞아도 단위나 표현이 달라지면 보고서의 의미가 바뀔 수 있다.

AI의 재검토만으로 끝내지는 않는다

AI에게

숫자가 맞는지 다시 확인해줘.

라고 요청할 수도 있다. 하지만 AI가 자신의 답변이 맞다고 말한다고 해서 검증이 끝난 것은 아니다.

최종 단계에서는 원본 Excel, 견적서, 일정표 같은 실제 자료와 비교하는 것이 좋다. AI는 숫자를 찾아 검토하기 쉽게 정리하는 역할을 맡기고, 최종 확인은 사람이 직접 하는 것이 좋다.

특히 AI가 만든 표에서 ‘불일치’와 ‘확인 필요’로 표시한 항목부터 확인한다.

불일치: 원본과 계산식을 확인한 뒤 보고서의 값이나 표현을 수정한다.
확인 필요: 빠진 자료를 확보하거나 기준을 확인한다. 확인 전에는 확정된 숫자로 사용하지 않는다.
일치: 예산·일정처럼 중요한 항목은 사람이 원본 위치를 다시 열어 대조한다.

숫자를 수정했다면 본문뿐 아니라 요약, 표, 결론에 같은 숫자가 남아 있지 않은지도 확인한다. 본문의 비용만 고치고 요약의 비용을 그대로 두면 보고서 안에서 서로 다른 금액이 보일 수 있기 때문이다.

숫자를 많이 다루는 업무를 하다 보니, 보고서 작성 과정에서 가장 신경을 쓰는 단계이기도 하다.

앞선 AI 보고서 작성법 6편｜일부러 반대시켜 보고서의 약점 찾기까지 마쳤다면, 이번 단계에서는 보고서에 작성된 숫자와 출처의 관계를 한 번 더 확인해볼 수 있다.

다음 글에서는 확인을 마친 보고서의 필요한 부분만 고치는 AI 보고서 작성법 8편｜전체를 다시 쓰지 않는 안전한 수정법을 정리해보려고 한다.

OpenAI Codex 사용법 2편｜Windows에서 GUI와 CLI로 시작하는 방법

zeucise — Wed, 9 Sep 2026 23:05:40 +0900

OpenAI Codex GUI와 CLI의 Windows 설치 및 실행 방법

지난 글에서는 Codex가 무엇이고 ChatGPT와 어떤 차이가 있는지 알아봤다.

이번에는 실제로 Windows에서 Codex를 시작해보려고 한다.

일단, Codex를 쓰려면 유료를 써야한다. 적어도... PULS(29,000원)는 되야 쓸 수 있다.

Codex를 쓰기 위해선 PLUS를 결재해야 한다.

PLUS 요금제 이상을 선택하고, Codex를 설치하면 된다.

Codex를 사용하는 방법은 크게 두 가지로 생각하면 편하다.

GUI 앱으로 사용하는 방법
CLI에서 사용하는 방법

처음 사용하는 사람이라면 GUI가 더 쉽다.

1편에서도 작성했지만, 이 글의 최종 목표는 자동화를 염두에 둔 Codex의 사용법이다. 그럴려면, CLI도 알아두는 것이 좋다.

이번 글에서는 두 가지 방법을 모두 살펴보고, 어떤 방식을 선택하면 좋은지도 함께 정리해보려고 한다.

GUI와 CLI 중 무엇을 선택하면 될까?

둘 중 하나가 무조건 더 좋은 것은 아니다. 용도가 조금 다르다.

간단히 설명하자면, 아래의 표와 같다.

구분	Codex GUI	Codex CLI
처음 사용하기	쉬움	조금 낯설 수 있음
프로젝트 확인	매우 편함	가능
수정 내용 확인	편함	가능
터미널 명령	제한적	매우 편함
Git 연계	가능	편함
자동화	가능	더 유연함
MCP 설정	가능	설정·확인에 편함
로컬 프로그램 연동	가능	테스트와 문제 확인에 유리

처음 Codex를 써본다면 GUI부터 시작해도 충분하다.

반대로 개발 도구와 함께 쓰거나 앞으로 MCP와 ComfyUI까지 연결할 계획이라면 CLI도 같이 익혀두는 것이 좋다.

이 글의 최종목표를 같이 따라가는 독자들을 위해 둘다 설치하는 방법을 설명하려 한다.

1. 가장 쉬운 방법은 Codex GUI

GUI는 가장 부담 없이 시작할 수 있는 방법이다.

Codex 앱을 설치하고 로그인한 뒤 프로젝트 폴더를 선택하면 바로 사용할 수 있다.

ChatGPT를 로그인 후 상단에 보면 Work가 활성화된 것을 볼 수 있다.

Work를 선택하면 아래와 같은 그림이 나온다.

"무엇이든 작업하세요" 아래에 보면 "데크스톱 앱 열기" 를 선택하면 아래의 화면이 나온다.

Windows용 다운로드를 눌러 설치하면 끝이다.

GUI의 장점은 터미널 명령어나 별도 설치 과정에 익숙하지 않아도 된다.

특히 처음에는 프로젝트 파일과 Codex가 수정한 내용을 화면으로 확인할 수 있다는 점이 편하다.

첫 화면은 사실 들어가 보면 맨날 보던 화면과 같다. 그런데, 상단에 보면 ∨ 이런 표시가 생긴 걸 볼 수 있다. 눌러서 ChatGPT와 Codex를 변경할 수 있는 것을 확인할 수 있다.

이러면 GUI에서는 Codex가 정상적으로 설치가 된 것이다.

Codex에서 Chatgpt 사용 시

Codex로만 사용 시

2. CLI도 함께 사용해보자

GUI만 사용해도 기본적인 Codex 작업은 충분히 할 수 있다.

그런데 CLI를 익혀두면 조금 더 다양한 작업이 편해진다.

예를 들면 아래의 도구들과 함께 사용하기 좋다.

Git
Python
npm
Docker
MCP Server
ComfyUI

앞으로 이 시리즈에서는 MCP와 ComfyUI까지 연결할 예정이기 때문에 CLI도 설치해보려고 한다.

일단, Windows 시작 메뉴에서 PowerShell을 검색하여 실행한다.

처음부터 관리자 권한으로 실행할 필요는 없다. 정상적으로 열리면 아래와 비슷한 화면이 나온다.

PowerShell 실행화면

아래 명령어를 그대로 복사해서 실행한다.

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

아래와 같이 나오면 정상 설치가 된 것으로 보면 된다.

model은 gpt-6-astra 설정되어 있고, 저장 directory는 system32이다.

설치가 완료된 화면

컴퓨터를 좀 만져보신 분들이라면, system32폴더는 왠만하면 건들기 싫어하는 폴더이다.

아래의 명령어를 실행하면 C:\Users\사용자명\codex-test 폴더에서 시작을 하게 된다.

cd $HOME
mkdir codex-test
cd codex-test
codex

기본 실행폴더를 변경

로그인이 끝났다면 간단한 요청부터 시작한다.

현재 폴더를 확인해줘.

아직 파일을 만들거나 수정하지 말고
현재 상태만 설명해줘.

폴더에 아무 파일이 없다면 파일이 없다고 설명해도 정상이다.

중요한 것은 Codex가 현재 실행 중인 폴더를 확인하고 응답할 수 있다는 점이다.

여기까지 된다면 CLI 설치도 성공한 것이다.

여기서 만약에 문제가 생긴다면, 먼저 PowerShell을 완전히 종료하고 다시 실행해 보거나,

codex doctor

를 실행해볼 수 있다.

GUI 와 CLI를 같이 써도 될까?

실제로 사용하다 보면 둘을 나눠 쓰는 것이 자연스럽다.

처음 Codex를 사용한다면

GUI부터 시작

터미널과 개발 도구에 익숙하다면

CLI도 함께 설치

MCP, 자동화, ComfyUI 같은 로컬 도구까지 연결할 계획이라면

GUI + CLI 둘 다 사용

정도로 생각하면 된다.

이번 글에서 사용한 CLI 명령어

# Codex 설치
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

# 테스트 폴더 생성
mkdir codex-test

# 폴더 이동
cd codex-test

# Codex 실행
codex

# 문제 진단
codex doctor

다음 글에서는 실제로 프로젝트를 만들어서 실행해보려고 한다.

GUI는 쉽게 시작할 수 있었고, CLI는 앞으로 외부 도구와 연결하기 위한 준비가 됐다.

다음 글에서는 테스트 프로젝트를 만들고, Codex로 실행해보자.

OpenAI Codex 사용법 1편｜ChatGPT와 무엇이 다를까?

zeucise — Wed, 9 Sep 2026 22:04:09 +0900

ChatGPT와 Codex 다른점

Claude는 Claude Desktop이 있고, ChatGPT는 Codex가 있다.

왜, 현재도 잘 쓰고 있는데 이런 프로그램을 만들어 쓸까? 라는 생각이 든다.

난, 토큰량 등을 고려해서 ChatGPT(Codex)를 쓰고 있다.

처음 보면 이런 생각이 든다.

ChatGPT로도 코딩하고, 이미지도 만들 수 있는데, 왜 Codex는 왜 따로 쓰는 걸까?

이번 글에서는 복잡한 기능보다 먼저 Codex가 무엇이고 ChatGPT와 어떤 차이가 있는지만 간단하게 알아보려고 한다.

Codex는 무엇일까?

Codex는 OpenAI의 코딩 에이전트다.

거창한 설명이 있을 것 같지만, 그냥 이름이다.

ChatGPT 와 Codex는 무엇이 다를까?

간단히 표로 비교하자면 아래와 같다.

ChatGPT	Codex
질문하고 답을 받음	작업을 맡김
코드를 만들어줌	프로젝트 파일을 확인함
수정 방법을 알려줌	파일을 직접 수정할 수 있음
실행 방법을 설명함	명령과 테스트를 실행할 수 있음

실제 사용방식에서는 좀 다르다. 보통 ChatGPT에서는 이렇게 질문한다.

Python으로 CSV 파일을 읽는 코드를 만들어줘.

그러면 ChatGPT가 코드를 만들어준다.

하지만, Codex에서는 조금 다르게 요청할 수 있다.

이 프로젝트를 확인해줘.

오류가 있는 부분을 찾아 수정하고
테스트까지 실행해줘.

Codex는 코드를 알려주는 것뿐 아니라 프로젝트 파일을 확인하고, 작업을 수행하는 것에 더 초점이 맞춰져 있다.

브라우저에서 단순히 답을 찾아 말해주는 것이 아닌, "내 PC에서 무엇인가를 실제로 대신하여 수행한다." 라는 것이 다르다.

OpenAI Codex에서 프로젝트 폴더를 연 화면

처음에 설치하면 위와 같이 나온다.

Codex는 어디에서 사용할까?

현재 Codex는 여러 환경에서 사용할 수 있다.

Codex 앱
Codex CLI
IDE 확장
웹

처음에는 화면으로 변경 내용을 확인할 수 있는 Codex 앱부터 시작하는 것이 가장 편하다.

(아직은 앱만 사용해봐서, CLI는 공부 후 내용을 추가해보도록 하겠다....)

그래서 CLI와 자세한 설치 방법은 다음 글에서 직접 해보려고 한다.

이것만 기억하면 된다

Codex를 처음 접했다면 한 가지만 기억해도 충분하다.

ChatGPT가 코드에 대해 질문하는 데 익숙하다면, Codex는 프로젝트의 실제 작업을 맡기는 데 더 적합한 코딩 에이전트다.

나도 처음엔 굳이 왜 써야할지 잘 몰랐으나, 실제 파일을 만들어서 PC에 저장해주고, PC에 저장된 파일을 읽어서 내용을 파악하는 등 Codex에서만 할 수 있는 일들이 많았다. 그리고, 훨씬 효율적이다.

앞으로는 직접 Codex를 사용하면서 Comfyui를 자동화해서 AI로 이미지 및 동영상을 만들어 볼 예정이다.

그러면서, Codex → AGENTS.md → Skills → MCP → ComfyUI 순으로 점차 연결해 사용해 보려하는데,

글을 써가면서 한개씩 해볼 예정이다.

다음 글에서는 Windows에서 Codex를 설치하고 첫 프로젝트를 실행하는 과정부터 시작한다.

AI 보고서 작성법 6편｜일부러 반대시켜 보고서의 약점 찾기

zeucise — Wed, 9 Sep 2026 13:34:29 +0900

AI에게 일부러 반대 의견을 물어 보고서의 약점과 리스크를 찾는 방법

보고서에서 추진해야 하는 목표가 명확할 때가 있다.

문제는 작성자가 이미 추진 목표나 방향을 정해놓고 보고서를 쓰는 경우가 많다는 것이다.

그래서 보고서에는 장점은 쉽게 보이지만 단점은 놓치기 쉽다.

이럴 때 AI에게 일부러 반대편 역할을 맡겨볼 수 있다.

추천안을 승인하기 전에 근거와 위험을 꼼꼼하게 확인하는 검토자에게 보고서를 보여준다고 생각하면 된다.

앞선 글에서 AI에게 상사 입장의 질문을 만들게 했다면, 이번에는 한 단계 더 들어가 현재 추천안을 승인하기 어려운 이유가 있는지 살펴보는 것이다.

서버 증설을 추천하는 보고서가 있다고 해보자

4·5편에서 다룬 시스템 응답 지연 사례를 이어가 보자. 원인 분석을 시작한 뒤, 작성자가 다음과 같은 추천안을 만들었다고 가정했다.

점심시간에 서버 사용률이 높게 나타났으므로, 응답속도 개선을 위해 서버 증설을 추진할 것을 제안한다.

그런데 추천안을 뒷받침하는 자료가 다음 정도라면 어떨까?

자료	현재 확인한 내용
서버 사용률 기록	특정 날짜의 점심시간 사용률만 확인함
응답 지연 분석	서버 자원 부족이 지연의 직접 원인인지는 아직 확인하지 못함
대안 비교	프로그램 최적화의 효과와 비용은 미검토
비용표	초기 도입비는 있으나 증설 후 운영비는 미확인

서버 증설이 필요한 상황일 수도 있다. 하지만 현재 자료만으로는 다른 선택지보다 적절한지 판단하기 어렵다.

이 글의 추천안과 자료, 반론 및 수정 결과는 설명을 위해 만든 가상 예시다. 실제 시스템 분석이나 AI 실행 결과는 아니다.

AI에게 추천안에 반대해달라고 한다

예를 들어 서버 증설을 추천하는 보고서라면 이렇게 요청한다.

이 보고서의 추천안에 반대하는 의사결정자라고 생각해줘.
추천안을 승인하기 어려울 수 있는 이유를 찾아줘.

다음 관점에서 확인해줘.

- 근거가 부족한 부분
- 잘못됐을 수 있는 가정
- 빠진 비용
- 일정 위험
- 실행상의 위험
- 검토하지 않은 다른 대안
- 예상하지 못한 부작용

억지로 문제를 만들지 말고,
현재 보고서와 자료에서 합리적으로 제기할 수 있는
중요한 반론을 최대 5개만 찾아줘.

각 항목을 다음 표로 정리해줘.

반론 / 관련 자료와 위치 / 중요도와 이유 /
확인하거나 보완할 내용

자료에서 확인된 문제와
아직 확인이 필요한 가능성을 구분해줘.

자료가 없다는 이유만으로
실제로 문제가 발생했다고 단정하지 말아줘.
원본에 없는 사실이나 수치도 만들지 말아줘.

예를 들어 다음과 같은 내용이 나올 수 있다.

현재 사용률만으로 서버 증설 필요성을 판단하기 어렵다.
일시적인 트래픽 증가인지 확인되지 않았다.
시스템 최적화 비용과 비교하지 않았다.
증설 후 운영비가 비용표에 반영됐는지 확인되지 않았다.

반론을 받았다면 확인할 자료를 연결한다

반론 목록만 받아두면 보고서는 달라지지 않는다. 각 반론을 어떤 자료로 확인할지 정해야 한다.

반론	확인할 자료	확인 후 처리
일시적인 사용률 상승일 수 있다	여러 날짜와 시간대의 사용률·요청량	반복되는 현상인지 확인해 증설 근거 보완
서버를 늘려도 지연이 해결되지 않을 수 있다	서버 사용률과 응답 시간, 기능별 처리 기록	지연 원인과 증설 효과를 검증
최적화가 더 적절할 수 있다	최적화 가능 범위, 예상 효과와 작업 비용	서버 증설과 같은 기준으로 비교
운영비가 빠졌을 수 있다	도입 견적, 유지보수·사용료 등 비용 내역	빠진 비용은 추가하고 이미 포함된 항목은 근거 표시

여기서 “서버를 늘려도 해결되지 않을 수 있다”는 반론은 증설이 소용없다고 확인됐다는 뜻이 아니다. 증설이 효과를 낼 것이라는 가정을 검증해야 한다는 의미다. 반론을 통해 추천안을 뒷받침하려면 무엇을 더 알아야 하는지 찾는 것이다.

반론이 나왔다고 모두 맞는 것은 아니다

AI가 반대 의견을 냈다고 해서 모두 받아들일 필요는 없다. 내가 가지고 있는 자료를 기반으로 확인해야 한다.

중요한 반론이라면 추가 근거를 찾거나, 보고서에 한계를 명시하거나, 다른 대안과 비교하면 된다.

자료를 확인해 타당하지 않은 것으로 판명된 반론은 제외한다.

다만 자료가 부족해 판단하지 못한 반론은 확인 필요로 남기고, 추천안의 결정에 영향을 주는 항목부터 확인한다.

예를 들어 “운영비가 빠졌다”는 반론을 받았다고 해보자.

비용표에 운영비가 이미 포함돼 있다면 해당 항목을 확인하고 근거를 표시한다.
실제로 빠져 있다면 비용표를 보완한다.
견적을 아직 받지 못했다면 미확인 상태임을 밝히고 추가 확인한다.

이렇게 해야 AI의 반론을 그대로 받아들이거나, 불편하다는 이유로 무시하는 일을 줄일 수 있다.

반론을 검토한 뒤 추천안은 어떻게 달라질까?

앞의 가상 사례에서는 지연 원인, 대안의 효과, 운영비가 아직 확인되지 않았다. 이 상태라면 곧바로 증설을 추진하기보다 추가 검토가 필요한 조건을 보고서에 적을 수 있다.

수정 전

점심시간에 서버 사용률이 높게 나타났으므로, 응답속도 개선을 위해 서버 증설을 추진할 것을 제안한다.

수정 후

특정 날짜의 점심시간에 높은 서버 사용률이 관찰됐다. 다만 응답 지연의 직접 원인과 반복 여부는 아직 확인되지 않았다. 여러 날짜의 사용률과 응답 기록을 점검하고, 프로그램 최적화 대안 및 증설 후 운영비를 비교한 뒤 증설 추진 여부를 판단할 것을 제안한다.

추천안에 필요한 확인 조건이 분명해졌다. 추가 분석에서 서버 자원 부족이 주요 원인으로 확인되고 증설의 효과와 비용도 타당하다면, 근거를 보완해 추천안을 유지할 수 있다. 반대로 다른 대안이 더 적절하다면 추천안을 바꿀 수도 있다.

승인받아야 하는 보고서일수록 유용하다

단순 현황보고라면 이 단계까지 사용할 필요는 없을 수 있다.

하지만 예산 승인이나 시스템 변경처럼 누군가의 결정이 필요한 보고서라면 한 번쯤 사용해볼 만하다.

AI를 항상 내 의견을 강화하는 역할로만 쓰지 않고, 가끔은 내 의견에 반대하는 두 번째 검토자로 사용하는 것이다.

5편이 보고받는 사람에게 필요한 설명이 빠졌는지 확인하는 과정이라면, 6편은 추천안의 근거와 가정을 검토해 유지할지, 보완할지, 바꿀지 판단하는 과정이다.

이전 글인 AI 보고서 작성법 5편｜제출 전 ‘상사 질문’으로 빠진 내용 찾기 와 함께 사용하면 빠진 질문과 논리적인 약점을 각각 확인할 수 있다.

다음 글에서는 보고서에서 특히 실수하기 쉬운 날짜·금액·비율을 확인하는 AI 보고서 작성법 7편｜날짜·금액·비율을 따로 확인하는 숫자 검증법을 정리해보려고 한다.

AI 보고서 작성법 5편｜제출 전 ‘상사 질문’으로 빠진 내용 찾기

zeucise — Wed, 9 Sep 2026 11:18:40 +0900

AI를 상사처럼 활용해 보고서의 빠진 내용을 찾는 방법

보고서를 작성하고 검토를 하다가 보면 자신의 보고서를 검토하는 것은 생각보다 어렵다.

내용을 이미 알고 있기 때문이다.

설명이 조금 빠져 있어도 보고서를 읽으면서 빠진 내용이 머릿속에서 자연스럽게 채워진다.

하지만 상사는 이 보고서를 처음 본다.

그래서 보고서를 어느 정도 완성했다면 AI에게 다시 작성해달라고 하기보다 처음 보는 상사의 역할을 맡겨볼 수 있다.

짧은 보고서도 읽는 사람에게는 질문이 생긴다

앞선 AI 보고서 작성법 4편｜해결책 하나에 갇히지 않는 대안 찾기 에서는 시스템 응답이 느려졌을 때 가능한 대안을 살펴봤다.

이번에는 그 상황을 보고서에 이렇게 적었다고 해보자.

점심시간에 시스템 응답 지연 문의가 증가했다. 원인 구간을 확인한 뒤 서버 증설과 프로그램 최적화 등 가능한 대안을 비교할 예정이다.

틀린 내용은 없어 보인다. 그런데 처음 읽는 사람에게는 이런 질문이 생길 수 있다.

원인은 누가, 언제까지 확인하는가?
지금 승인해달라는 내용은 무엇인가?
서버 증설 비용은 이미 확인했는가?

작성자는 머릿속에 답을 가지고 있을 수 있다. 하지만 보고서에 적혀 있지 않으면 읽는 사람은 알기 어렵다.

이 글의 보고서와 질문, 수정 결과는 설명을 위해 만든 가상 예시다. 실제 업무 자료나 AI 실행 결과는 아니다.

AI에게 보고서를 고치지 말고 질문하게 한다

예를 들어 팀장이나 임원이 읽는 보고서라면 이렇게 요청해본다.

보고 목적과 관련이 큰 질문을 먼저 받고, 답변은 임의로 만들지 않도록 요청한다.

당신이 이 보고서를 처음 받아보는 팀장 또는 임원이라고 생각해줘.

보고서를 읽은 뒤
작성자에게 물어보고 싶은 질문을 만들어줘.

특히 다음 내용을 확인해줘.

- 왜 지금 해야 하는가?
- 비용은 얼마인가?
- 누가, 언제까지 진행하는가?
- 다른 방법은 없는가?
- 하지 않으면 어떤 문제가 생기는가?
- 가장 큰 위험은 무엇인가?
- 이번 보고에서 어떤 판단이나 승인을 요청하는가?

현재 보고서만 읽어도 답할 수 있는 질문은 제외해줘.
보고 목적과 관련이 큰 질문부터 최대 5개만 골라줘.

결과는 다음 표로 정리해줘.

질문 / 질문이 생긴 이유 / 보완하면 좋은 위치

보고서 본문은 아직 수정하지 말고,
질문의 답이나 보고서에 없는 사실을 임의로 만들지 말아줘.

예를 들어 이런 질문이 나올 수 있다.

왜 지금 해야 하나?

이 금액은 어떻게 계산했나?

다른 대안은 검토했나?

하지 않았을 때 발생하는 영향은 무엇인가?

글을 쓰고 있지만, 실제로 이런 이야기를 물어보면 식은땀이 흐른다...

질문을 받았다면 무엇을 확인할지 정한다

앞의 짧은 보고서에 적용하면 다음처럼 정리할 수 있다.

예상 질문	질문이 생긴 이유	확인하거나 보완할 내용
누가, 언제까지 원인을 확인하나?	담당자와 일정이 없음	담당 부서와 분석 일정 확인 후 추가
이번에 무엇을 승인해달라는 것인가?	상황 설명만 있고 보고 목적이 불분명함	현황 공유인지, 협조 요청인지, 예산 승인인지 명시
서버 증설 비용은 확인했나?	증설이라는 선택지가 있지만 비용 설명이 없음	이번 단계에서 필요한 정보인지 판단하고, 미산정 상태라면 그 사실을 표시

여기서 질문에 바로 답을 채우려고 하면 또 다른 문제가 생길 수 있다. 확인하지 않은 일정이나 비용을 그럴듯하게 적게 되는 것이다.

그래서 나는 먼저 자료는 있는데 보고서에서 빠진 것인지, 자료 자체가 아직 없는 것인지 나눠보는 편이 좋다고 생각한다.

질문을 모두 보고서에 넣을 필요는 없다

여기서 중요한 것은 AI가 만든 질문을 전부 보고서에 추가하는 것이 아니다.

질문 하나씩 보면서 "현재 보고서만 읽고 답할 수 있는가?" 를 확인한다.

답할 수 있다면 넘어간다.

답할 수 없다면 보통 두 가지 중 하나다.

필요한 자료가 부족하거나
자료는 있는데 보고서에서 설명이 빠졌거나

특히 승인이나 의사결정과 직접 관련된 질문부터 확인하면 된다.

보고 단계에 따라 필요한 답도 달라진다.

서버 증설 예산을 승인받는 보고서라면 비용과 산출 근거가 중요하다. 반면 원인 분석 착수를 알리는 보고서라면, 아직 선택하지 않은 모든 대안의 견적을 받을 필요는 없을 수 있다.

그 경우에는 “원인 분석 후 대안별 비용을 산정할 예정”이라고 적어 현재 단계와 다음 단계를 구분하면 된다.

확인한 내용만 넣어 보고서를 보완한다

앞의 예시에서 담당 부서와 협의한 결과가 다음과 같다고 추가로 가정해보자.

시스템 운영팀이 이번 주 금요일까지 1차 원인 분석을 진행한다.
이번 보고는 현황 공유와 분석 계획 안내를 위한 것이다.
대안별 비용은 원인 분석 후 확인한다.

이 조건을 반영하면 보고서 문장은 이렇게 달라진다.

수정 전

점심시간에 시스템 응답 지연 문의가 증가했다. 원인 구간을 확인한 뒤 서버 증설과 프로그램 최적화 등 가능한 대안을 비교할 예정이다.

수정 후

점심시간에 시스템 응답 지연 문의가 증가했다. 시스템 운영팀이 이번 주 금요일까지 1차 원인 분석을 진행할 예정이다. 이번 보고는 현황과 분석 계획을 공유하기 위한 것이다. 분석 결과를 바탕으로 서버 증설과 프로그램 최적화 등의 효과·비용을 비교해 후속 보고할 예정이다.

누가 언제까지 확인하는지, 이번 보고의 목적은 무엇인지, 비용은 언제 다룰지가 보인다.

실제 보고서에서는 상대적인 날짜인 ‘이번 주 금요일’을 구체적인 날짜로 적고, 담당 부서와 합의한 일정인지도 확인하는 것이 좋다.

‘검토해줘’ 보다 질문하게 하는 이유

AI에게 단순히

이 보고서를 검토해줘.

라고 하면 문장이나 표현까지 광범위하게 수정하려고 할 수 있다.

반면

이 보고서를 읽고 무엇을 물어보겠어?

라고 하면 내용의 빈틈을 찾는 데 집중할 수 있다.

개인적으로 보고서를 거의 완성한 단계에서는 이 방식이 더 도움이 될 때가 많았다.

앞선 4편에서 선택지를 정리했다면, 이번에는 보고받는 사람이 판단하는 데 필요한 설명이 빠져 있지 않은지 확인해보면 된다.

다음 글에서는 추천안에 반대하는 관점에서 근거와 가정의 약점을 살펴보는 AI 보고서 작성법 6편｜일부러 반대시켜 보고서의 약점 찾기 를 정리해보려고 한다.

AI 보고서 작성법 4편｜해결책 하나에 갇히지 않는 대안 찾기

zeucise — Wed, 9 Sep 2026 10:57:22 +0900

AI 보고서 작성법 4편 해결책 하나에 갇히지 않고 다양한 대안을 찾는 방법

앞선 글에서는 보고서의 핵심 내용에 “그래서?”라고 물어보면서 영향과 필요한 판단을 찾는 방법을 정리했다.

2026.09.08 - [AI Research/읽을 만한 자료] - AI 보고서 작성법 3편｜상사가 ‘그래서?’ 라고 묻지 않는 So What 질문법

그 다음에는 해결방법을 생각해야 한다. 보고서를 작성하다 보면 문제보다 해결책이 먼저 떠오를 때가 있다.

예를 들어 시스템이 느려졌다고 해보자.

서버를 증설하면 되지 않을까?

라는 생각이 들 수 있다.

문제는 해결책을 먼저 정하고 AI에게 물어보면 AI도 그 해결책이 좋은 이유를 찾는 방향으로 답할 수 있다는 것이다.

그래서 저는 이런 경우 정답을 물어보기 전에 선택지부터 넓혀보는 방법이 더 좋다고 생각한다.

해결책을 찾기 전에 관점을 나눠본다

방법은 생각보다 간단하다.

같은 문제를 몇 가지 다른 관점에서 보는 것이다.

1. 자원을 추가해서 해결할 수 있는가?
2. 기존 자원을 더 효율적으로 사용할 수 있는가?
3. 업무나 프로세스를 바꿀 수 있는가?
4. 범위나 일정을 조정할 수 있는가?
5. 다른 서비스나 방법으로 대체할 수 있는가?
6. 단기 대응과 장기 대응은 다른가?

시스템 속도 문제라면 다음처럼 서로 다른 방향의 대안을 찾을 수 있다.

서버 증설
프로그램 최적화
사용량이 많은 기능 분리
처리 시간 분산
클라우드 자원 확대

핵심은 처음 떠오른 해결책에서 한 번 벗어나 보는 것이다.

다만 대안을 비교하기 전에 문제의 범위부터 확인해야 한다. 예를 들어 아래와 같은 상황을 가정해보자.

평소에는 괜찮지만 점심시간에 시스템 응답이 느려진다는 문의가 늘었다. 아직 어느 구간에서 지연이 발생하는지는 확인하지 못했다.

이 상태에서 서버를 늘리면 해결될지, 특정 기능을 고쳐야 할지 판단하기 어렵다.

먼저 언제 느려지는지, 어떤 기능에서 발생하는지, 서버나 프로그램의 어느 부분이 바쁜지 확인할 자료가 필요하다.

아래 사례는 설명을 위해 만든 가상 상황이다. 실제 시스템 분석 결과가 아니다.

AI에게는 이렇게 대안을 찾아달라고 한다

문제의 범위와 아직 모르는 내용을 함께 알려주고 요청한다.

점심시간에 시스템 응답이 느려진다는 문의가 늘었어.
지연이 발생하는 구간과 원인은 아직 확인하지 못했어.

다음 관점에서 가능한 대안을 찾아줘.

- 자원을 추가하는 방법
- 기존 자원을 효율적으로 사용하는 방법
- 프로세스를 변경하는 방법
- 범위나 일정을 조정하는 방법
- 다른 서비스나 방식으로 대체하는 방법
- 단기 대응과 장기 대응

각 대안에 대해 다음 항목을 표로 정리해줘.

대안 / 효과가 있을 수 있는 조건 /
예상되는 비용·기간 / 위험 / 먼저 확인할 자료

예산·일정·인력이나 성능 수치를 임의로 만들지 말고,
모르는 값은 '확인 필요'로 표시해줘.

비슷한 방법은 합쳐줘.

AI가 대안을 여러 개 제시하더라도, 그것이 곧 실행 가능한 해결책이라는 뜻은 아니다.

특히 원인을 모르는 상태라면 어떤 조건에서 효과가 있을지를 함께 봐야 한다.

대안을 비교하면 무엇이 달라질까?

AI가 제시할 수 있는 방향을 지금 가진 정보만으로 정리하면 다음과 같다.

대안	효과가 있을 수 있는 조건	먼저 확인할 자료
서버 증설	서버 자원이 부족해서 느려지는 경우	시간대별 CPU·메모리 사용량, 처리 요청량
프로그램 최적화	특정 기능이나 처리 과정이 느린 경우	기능별 응답 시간, 오류 기록, 처리 흐름
처리 시간 분산	특정 시간에 작업이 몰리는 경우	시간대별 요청량, 예약 작업 실행 시간

이 표에서 ‘서버 증설이 정답’이라고 결론 내릴 수는 없다.

어느 조건에 해당하는지 아직 확인하지 못했기 때문이다.

비용과 소요 기간도 자료가 없다면 숫자를 채우지 않는 편이 정확하다.

보고서에는 우선 이렇게 적을 수 있다.

점심시간에 시스템 응답 지연 문의가 증가했다. 원인 구간은 아직 확인되지 않았다. 서버 자원 부족, 특정 기능의 처리 지연, 작업 집중 여부를 확인한 뒤 서버 증설과 프로그램 최적화 등 가능한 대안을 비교할 예정이다.

이 문장은 해결책을 미루자는 뜻이 아니다. 어떤 자료를 확인해야 대안 중 하나를 선택할 수 있는지 보여준다.

대안이 많이 나왔다면 모두 보고서에 넣을 필요는 없다. 실제로 검토할 수 있는 3~4개 정도를 남기고 비용, 기간, 기대 효과, 위험, 실행 가능성을 비교하면 된다.

이미 해결책을 정했다면 반대로 물어본다

이미 결론을 정해놓은 상태라면 이런 질문도 도움이 된다.

현재 추천안과 다른 방식으로 해결할 수 있는 대안을 찾아줘. 각 대안이 효과를 내려면 어떤 조건이 필요한지도 적어줘.

대안의 이름만 나열하면 비교하기 어려우므로, 효과가 있을 조건도 함께 확인한다.

AI에게 정답을 골라달라는 것이 아니다. 내가 생각하지 못한 선택지가 있는지 확인하는 것이 목적이다.

개인적으로 보고서에서 대안을 찾을 때는 AI가 결론을 대신 내려주는 것보다, 생각의 범위를 넓혀주는 용도로 사용하는 것이 더 유용했다.

다음 글에서는 AI를 상사처럼 사용해 보고서에서 빠진 내용을 찾는 AI 보고서 작성법 5편｜제출 전 ‘상사 질문’으로 빠진 내용 찾기 을 정리해보려고 한다.

GPT-6 Astra vs Claude Fable 5.1 비교｜코딩·문서·업무 차이

zeucise — Tue, 8 Sep 2026 14:49:31 +0900

GPT-6 Astra와 Claude Fable 5.1 코딩 문서 업무 비교

2026년 9월 공개된 GPT-6 Astra와 Claude Fable 5.1은 코딩과 긴 문서 처리 모두 강력하지만, 실제 사용 방향은 조금 다르다.

그래서 자연스럽게 궁금해진다.

그래서 둘 중 어떤 AI를 쓰는 게 좋을까?

벤치마크를 찾아보면 어떤 테스트에서는 Astra가 앞서고, 다른 테스트에서는 Fable 5.1이 더 좋은 결과를 보여준다.

하지만 실제 사용할 때 중요한 것은 점수보다 내가 하는 업무에서 어떤 차이가 느껴지는가인 것 같다.

복잡한 숫자는 줄이고 실제 사용 기준으로 정리해봤다.

먼저 간단하게 비교하면

구분	GPT-6 Astra	Claude Fable 5.1
출시일	2026년 9월 3일	2026년 9월 1일
특징	업무 수행·자동화	장시간 작업·깊은 분석
코딩	강함	강함
긴 문서	강함	강함
Computer Use	특히 강점	지원
장시간 프로젝트	강함	특히 강조
Context	1.05M	1M
최대 출력	128K	128K
API 입력	$10 / 1M tokens	$10 / 1M tokens
API 출력	$50 / 1M tokens	$50 / 1M tokens
Cached Input / Read	$1 / 1M tokens	$0.25 / 1M tokens

OpenAI GPT-6 Astra(https://developers.openai.com/api/docs/models/gpt-6-astra?utm_source=chatgpt.com)

Anthropic Claude Fable(https://platform.claude.com/docs/en/models/fable-5-1/overview?utm_source=chatgpt.com)

Claude Fable 5.1은 2026년 9월 1일, GPT-6 Astra는 이틀 뒤인 9월 3일 공개됐다.

거의 같은 시기에 등장한 만큼 자연스럽게 비교 대상이 되고 있다.

기본 API 입력·출력 가격만 보면 둘은 같다.

하지만 실제로 사용하는 비용까지 같다고 보기는 어렵다.

GPT-6 Astra는 입력이 272K 토큰을 넘는 긴 요청에 장문맥 할증이 적용된다. OpenAI 공식 문서 기준으로 해당 요청에서는 입력·캐시 가격이 2배, 출력 가격은 1.5배가 된다.

반대로 Claude Fable 5.1은 Cache Read가 100만 토큰당 $0.25로 Astra의 $1보다 저렴하다. 같은 긴 문서나 코드베이스를 반복해서 참고하는 작업이라면 이 차이가 실제 비용에 영향을 줄 수 있다.

즉,

기본 입출력 가격은 같지만 긴 문서를 어떻게 사용하는지에 따라 실제 비용은 달라질 수 있다.

정도로 이해하는 것이 가장 정확하다.

그리고 위 가격은 ChatGPT나 Claude의 월 구독료가 아니라 API 사용 가격이다.

Context가 100만 토큰이라고 해서 일반 구독 서비스에서 항상 100만 토큰을 자유롭게 사용할 수 있다는 의미도 아니다.

스펙만 보면 둘은 생각보다 비슷하다.

그래서 실제 차이는 무엇을 시키느냐에서 더 크게 나타날 가능성이 높다.

1. Astra는 ‘답변’보다 ‘직접 일하기’ 가 눈에 띈다

GPT-6 Astra에서 가장 관심이 가는 부분은 Computer Use다.

웹을 탐색하거나 프로그램을 사용하고, 자료를 조사한 뒤 문서나 표 같은 결과물까지 만드는 방향이 강해졌다.

예를 들어,

최근 자료를 조사해줘.

에서 끝나는 것이 아니라

최근 자료를 조사해서 비교하고 표와 보고서까지 만들어줘.

처럼 하나의 일을 처음부터 끝까지 맡기는 방식이다.

웹, 문서, Excel 등 여러 도구를 연결해서 AI에게 실제 업무를 맡기고 싶다면 Astra가 더 흥미롭게 느껴질 수 있다.

2. Fable 5.1은 오래 붙잡고 하는 일이 눈에 띈다

Claude Fable 5.1은 조금 다른 방향이다.

큰 코드베이스를 분석하거나 여러 문서를 이용해 연구하고, 하나의 문제를 오랫동안 추적하는 작업을 특히 강조한다.

예를 들어,

큰 프로젝트의 코드 분석
장시간 리팩터링
여러 문서를 이용한 조사
복잡한 오류 원인 찾기
기존 결과물의 문제점 검토

같은 작업이다.

AI에게 단순히 답을 받기보다 하나의 프로젝트를 오래 맡겨놓고 계속 개선하는 방식으로 사용한다면 Fable 5.1이 더 관심이 간다.

3. 실제 사용에서는 ‘수정 능력’도 중요하다

개인적으로 AI를 오래 사용하다 보면 첫 답변보다 이 부분이 더 중요해진다.

내용은 유지하고 30%만 줄여줘.

세 번째 부분만 수정해줘.

말투는 그대로 유지해줘.

숫자는 건드리지 말고 결론만 바꿔줘.

실제로 AI를 사용할 때는 이런 요청을 정말 많이 한다.

처음부터 좋은 결과를 만드는 것도 중요하지만 이미 만들어진 내용을 얼마나 정확하게 수정해주는지도 실제 만족도에 상당한 영향을 준다. 그래서 두 모델을 직접 비교한다면 첫 답변 하나만 보고 판단하기보다 같은 문서를 여러 번 수정시켜보는 것이 더 현실적인 테스트라고 생각한다.

4. 코딩도 이제 ‘Claude가 무조건 좋다’고 말하기 어렵다

Claude는 오랫동안 코딩에서 좋은 평가를 받아왔다.

Fable 5.1 역시 코딩과 긴 개발 작업을 주요 영역으로 내세우고 있다.

그런데 Astra도 이번에는 상당히 강해졌다.

일부 터미널이나 실제 코드 작업 평가에서는 Astra가 앞서는 결과도 있고, 복잡한 추론이나 특정 과학 코딩에서는 Fable 5.1이 좋은 결과를 보이는 경우도 있다.

그래서 코딩에서는 단순 벤치마크보다 다음이 더 궁금하다.

기존 코드를 수정할 때 불필요한 부분을 건드리는가?
오류의 원인을 제대로 찾는가?
여러 번 수정해도 기존 기능을 유지하는가?
큰 프로젝트에서도 처음 요구사항을 계속 유지하는가?

결국 개발자가 체감하는 것은 이런 부분일 가능성이 높다.

그래서 어떤 AI를 쓰는 게 좋을까?

현재 공개된 내용을 기준으로 아주 간단하게 나눠보면 이렇다.

GPT-6 Astra가 더 관심 가는 사람

AI에게 여러 단계의 업무를 맡기고 싶다.
웹이나 프로그램을 직접 사용하는 일이 많다.
문서, Excel, 자료조사를 연결해서 사용한다.
AI 업무 자동화에 관심이 많다.
코딩뿐 아니라 다양한 업무를 하나의 AI로 처리한다.

Claude Fable 5.1이 더 관심 가는 사람

코딩 프로젝트를 오래 이어간다.
큰 코드베이스를 자주 다룬다.
긴 자료를 깊게 분석한다.
AI에게 결과물을 검토하게 하는 일이 많다.
하나의 복잡한 문제를 오랫동안 맡기고 싶다.

보고서 작성이나 리서치처럼 두 영역이 섞여 있는 작업이라면 둘 다 직접 사용해보고 판단하는 것이 가장 좋을 것 같다.

이제는 모델을 단순히 벤치마크 점수만 보고 AI를 선택하기는 점점 어려워지고있다.

오히려 앞으로는 "나는 AI에게 어떤 일을 맡기고 싶은가?" 가 더 중요한 기준이 될 것 같다.

AI 보고서 작성법 3편｜상사가 ‘그래서?’ 라고 묻지 않는 So What 질문법

zeucise — Tue, 8 Sep 2026 09:51:10 +0900

상사가 그래서라고 묻지 않는 AI 업무 보고서 작성법

보고서를 작성하다 보면 틀린 내용은 없는데 뭔가 부족한 경우가 있다.

정보는 많이 들어 있다. 그런데 읽고 나면 이런 생각이 든다.

그래서 이게 왜 중요한 거지?

예를 들어,

테스트 일정이 5일 지연됐다.

라는 내용이 있다고 해보자.

사실을 정확하게 적었지만 보고받는 사람 입장에서는 한 가지가 더 궁금하다.

그래서?

한 번 더 생각해본다.

테스트 일정이 5일 지연돼 서비스 오픈 일정에도 영향을 줄 수 있다.

조금 나아졌다.

다시 한 번 묻는다.

그래서?

현재 오픈 일정을 유지하려면 테스트 인력 추가를 검토해야 할 수도 있다. 일정 유지가 어렵다면 오픈 일정 조정이 필요한지 판단해야 한다.

이제 보고받는 사람이 무엇을 판단해야 하는지 보인다.

이런 식으로 한 번 더 “그래서?”라고 질문하는 것을 So What 질문이라고 생각하면 이해하기 쉽다.

다만 여기서 ‘오픈 일정에 영향을 줄 수 있다’는 것은 아직 확인할 사항이다. 테스트와 오픈이 어떻게 연결되는지 살펴보지 않았다면, 영향을 이미 확정된 사실처럼 보고서에 적어서는 안 된다.

사실에서 끝내지 말고 ‘영향’까지 연결한다

보고서의 핵심 내용을 아래 세 단계로 확인하는 편이 이해하기 쉬웠다.

사실 → 영향 → 필요한 판단 또는 행동

테스트 일정 사례에 적용하면 다음과 같다.

단계	확인할 내용
사실	테스트 일정이 기존 계획보다 5일 지연됐다
영향	이 지연이 서비스 오픈 일정에 영향을 주는가?
필요한 판단	일정 유지가 가능하다면 어떤 조치가 필요한가? 어렵다면 오픈 일정을 조정해야 하는가?

영향은 질문으로 먼저 적어두는 편이 안전하다. 예를 들어 테스트 완료가 오픈의 필수 조건인지, 일정에 여유가 있는지에 따라 결론이 달라진다.

여유 일정 안에서 테스트를 마칠 수 있다면 오픈 일정은 유지될 수 있다.
테스트 완료 후에만 오픈할 수 있고 남은 여유가 부족하다면 오픈 일정 조정이 필요할 수 있다.

둘 중 어느 쪽인지 확인하지 않은 상태에서 “서비스 오픈도 5일 지연된다”고 쓰면, 앞선 사실에서 확인되지 않은 결론으로 건너뛰게 된다. 보고서에 정보가 많아도 왜 중요한지와 어떤 판단이 필요한지가 빠져 있다면 보고받는 사람은 다시 질문할 수밖에 없다. 특히 문제점이나 주요 변화처럼 보고받는 사람이 판단해야 할 내용에 한 번씩 “그래서?”라고 물어보는 것이 도움이 된다.

확인된 사실과 남은 질문을 보고서에 적어보자

다음은 설명을 위해 만든 예시다. 테스트 일정이 5일 밀린 것은 확인됐지만, 서비스 오픈 일정에 미치는 영향은 아직 확인 중이라고 가정했다.

수정 전

테스트 일정이 5일 지연됐다.

수정 후

테스트 완료 예정일이 기존 계획보다 5일 늦어졌다. 현재 오픈 일정에 미치는 영향을 확인 중이며, 테스트 완료 후 남은 작업과 일정 여유를 점검한 뒤 일정 유지 또는 조정 여부를 보고할 예정이다.

문장을 길게 만들기 위해 내용을 덧붙인 것이 아니다. 확인된 사실, 아직 확인할 영향, 다음에 필요한 판단을 구분한 것이다.

AI에게도 ‘그래서?’라고 물어보게 한다

보고서를 어느 정도 작성했다면 AI에게 직접 확인시킬 수도 있다.

이 보고서의 핵심 내용을 확인해줘.

각 내용에 대해
보고받는 사람이 "그래서?"라고 질문한다고 생각해줘.

다음 내용이 빠진 부분을 찾아줘.

- 어떤 영향이 있는가?
- 어떤 위험이 있는가?
- 어떤 판단 또는 행동이 필요한가?

영향과 위험은 첨부한 자료에서
근거를 확인할 수 있는 경우에만 단정해줘

근거가 부족하다면 영향을 만들어내지 말고
'확인 필요'라는 표시한 뒤,
무엇을 확인해야 하는지 적어줘.

단순한 참고정보에는
억지로 의미나 행동을 추가하지 말아줘.

기존 요청에 ‘근거가 부족하면 확인 필요로 표시하라’는 조건을 넣었다.

AI가 보고서의 빈틈을 찾는 과정에서 그 빈틈을 임의의 설명으로 채우지 않도록 하기 위해서다.

여기에서 중요한 것은 모든 문장을 길게 만드는 것이 아니다.

참고자료까지 전부 영향과 행동으로 연결하면 오히려 보고서가 복잡해진다.

결론이나 주요 문제처럼 보고받는 사람이 판단해야 할 내용에만 사용하는 것이 좋다.

‘그래서?’ 를 물었는데 근거가 없다면?

한 가지 주의할 점도 있다.

예를 들어,

테스트 일정이 지연됐다.

라는 사실에서

서비스 오픈도 지연될 것이다.

라고 바로 연결하면 안 된다. 실제로 그런 영향을 주는지 근거가 있어야 한다.

이때는 다음 내용을 확인할 수 있다.

테스트 완료가 서비스 오픈의 필수 조건인가?
테스트 이후에도 필요한 작업이 있는가?
현재 일정에 여유가 남아 있는가?
인력이나 작업 순서를 조정하면 영향을 줄일 수 있는가?

아직 답을 모른다면 보고서에는 “오픈 일정에 미치는 영향 확인 중”이라고 적는 편이 정확하다. 확인이 끝난 뒤 영향과 필요한 판단을 구체적으로 쓰면 된다.

그래서 So What을 적용하기 전에 보고서에 들어갈 주장과 근거를 먼저 확인해두는 편이 좋다.

이 부분은 이전 글인 AI 보고서 작성법 2편｜그럴듯한 오류를 잡는 주장-근거 검증법 에서 정리했다.

결국 좋은 보고서는 ‘그래서 무엇을 해야 하는지’ 가 보여야 한다

보고서에서 중요한 것은 정보를 많이 넣는 것이 아닌 것 같다.

보고받는 사람이

무슨 일이 발생했고,
어떤 영향이 확인됐으며,
아직 무엇을 확인해야 하고,
그래서 무엇을 판단해야 하는지

빠르게 이해할 수 있어야 한다.

보고서를 작성하고 나서 뭔가 부족하다고 느껴진다면 문장을 더 전문적으로 바꾸기 전에 먼저 이렇게 물어보는 것도 좋다.

그래서 이 내용이 왜 중요한가?

개인적으로는 이 질문 하나만으로도 보고서에서 빠진 부분이 생각보다 많이 보였다.

다음 글에서는 문제는 찾았는데 해결책이 하나밖에 떠오르지 않을 때 사용할 수 있는 AI 보고서 작성법 4편｜해결책 하나에 갇히지 않는 대안 찾기 정리해보려고 한다.

AI 보고서 작성법 2편｜그럴듯한 오류를 잡는 주장-근거 검증법

zeucise — Mon, 7 Sep 2026 23:01:36 +0900

AI 보고서의 주장과 근거를 검증하는 주장-근거표

AI로 보고서를 작성할 때 가장 조심해야 하는 부분 중 하나는 그럴듯한 오류다.

틀린 내용이나 확인되지 않은 해석도 상당히 자연스럽게 보일 수 있다.

예를 들어 AI가 이런 문장을 작성했다고 해보자.

외부 업체 개발 일정이 지연되면서 전체 프로젝트가 2주 늦어졌다.

문장만 보면 별문제가 없어 보인다. 그런데 원본 자료를 다시 보면, 프로젝트가 2주 늦어진 것과 외부 업체의 개발 일정이 늦어진 것은 각각 확인되더라도 외부 업체 때문에 전체 일정이 늦어졌다는 근거는 없을 수 있다.

AI가 서로 다른 두 사실을 한 문장으로 연결한 것이다.

그래서 중요한 보고서라면 문장을 다듬기 전에, 주장과 근거를 한 번 분리해서 확인하는 과정이 필요하다.

지난 AI 보고서 작성법 1편｜자료를 요약하기 전에 ‘변화’ 부터 찾는 이유 에서는 자료를 비교해 달라진 점을 찾았다.

이번에는 찾아낸 내용을 어디까지 보고서에 쓸 수 있는지 확인해보려고 한다.

보고서의 주장을 근거까지 따라가 본다

방법은 어렵지 않다. 보고서의 핵심 문장을 주장 → 근거 → 출처 순서로 다시 따라가 보는 것이다.

아래는 설명을 위해 만든 가상 프로젝트 자료다.

자료명	기록된 내용
프로젝트 일정표	전체 완료 예정일이 기존보다 2주 뒤로 변경됨
9월 3일 회의록	외부 업체의 개발 일정이 지연됐다고 기록됨
원인 분석 자료	아직 작성되지 않음

이 자료로 앞의 문장을 확인하면 다음과 같다.

보고서에 담긴 주장	근거와 자료 위치	확인 상태
전체 프로젝트가 2주 지연됐다	프로젝트 일정표의 변경 전·후 완료 예정일	확인 가능
외부 업체의 개발 일정이 지연됐다	9월 3일 회의록의 일정 논의 내용	확인 가능
외부 업체의 지연 때문에 전체 프로젝트가 2주 늦어졌다	두 일정의 인과관계를 설명하는 자료 없음	확인 필요

‘프로젝트가 늦어졌다’와 ‘외부 업체 일정이 늦어졌다’는 각각 확인된 사실이다.

하지만 두 사실이 함께 존재한다고 해서 앞의 일이 뒤의 일 때문에 발생했다고 바로 말할 수는 없다.

여기서 내가 확인하고 싶은 것은 단순히 “근거 자료가 있나?”가 아니다.

그 자료가 이 문장의 어느 부분까지 뒷받침하는가?

이 질문을 해야 사실 두 개 사이에 들어간 추측을 발견할 수 있다.

확인되지 않은 문장은 이렇게 고친다. 그렇다면 원인 관계가 확인되지 않은 문장을 보고서에 어떻게 적어야 할까?

수정 전

외부 업체 개발 일정이 지연되면서 전체 프로젝트가 2주 늦어졌다.

수정 후

전체 프로젝트 완료 예정일이 기존보다 2주 늦춰졌다. 외부 업체 개발 일정도 지연된 것으로 확인됐다. 두 일정의 인과관계는 추가 확인이 필요하다.

두 사실은 남기되, 아직 확인되지 않은 원인은 단정하지 않았다. 나중에 일정 변경 사유를 확인했다면 그 근거를 바탕으로 문장을 다시 쓸 수 있다.

AI에게 주장·근거표를 만들어달라고 한다

긴 보고서에서 모든 문장을 하나씩 확인하기는 어렵다. 먼저 AI에게 핵심 주장만 추려 근거표로 정리하게 할 수 있다.

첨부한 보고서 초안과 원본 자료를 비교해줘.

보고서의 핵심 문장을 짧은 주장으로 나누고
다음 항목을 표로 정리해줘.

- 주장
- 사실 / 해석 / 제안 구분
- 근거가 되는 원본 자료
- 자료에서 확인할 위치
- 확인 / 확인 필요

특히 "~때문에", "~로 인해"처럼
원인을 연결하는 표현을 확인해줘.

두 사실이 각각 확인되더라도
그 사이의 원인 관계가 자료에서 확인되지 않으면
'확인 필요'로 표시해줘.

원본에 없는 근거를 만들지 말고,
확인 필요로 표시한 문장은
현재 자료만으로 쓸 수 있는 표현으로 고쳐줘.

AI가 표를 만들었다고 검증이 끝난 것은 아니다.

AI가 적은 ‘자료 위치’를 열어보고, 실제로 그 내용이 적혀 있는지 사람이 확인해야 한다.

이 과정에서 AI는 확인할 문장을 찾고 표로 정리하는 역할을 맡는다. 보고서에 그 주장을 넣어도 되는지 결정하는 것은 원본 자료를 확인한 사람의 몫이다.

사실·해석·제안을 구분한다

주장과 근거를 살펴볼 때는 문장의 성격도 나눠보면 좋다.

예를 들어 이런 문장들이 있다고 해보자.

매출이 전월 대비 10% 감소했다.
→ 사실

경쟁 심화가 원인으로 보인다.
→ 해석

가격정책을 변경해야 한다.
→ 제안

세 문장은 자연스럽게 이어질 수 있지만, 확인된 내용은 아니다.

AI가 작성한 보고서에서는 이 문장들이 매끄럽게 연결되면서 해석이 사실처럼 보일 때가 있다.

여기서의 포인트는 해석이나 제안을 쓰지 말자는 뜻은 아니다. 확인된 사실과 추정한 내용을 구분해서 쓰자는 것이다.

특히 숫자, 원인, 일정처럼 보고받는 사람의 판단에 영향을 주는 문장이라면 한 번 더 확인이 필요하다.

원본 자료에서 직접 확인되는가?
계산이 필요한 내용이라면 계산식이 맞는가?
두 사실 사이의 원인 관계까지 확인되는가?
아직 확인하지 못했다면 보고서에 어떻게 표시할 것인가?

결국 자연스러운 문장보다 확인되는 문장이 필요하다

AI가 작성한 보고서는 문장이 자연스럽기 때문에 처음 읽었을 때는 문제가 없어 보일 수 있다.

하지만 보고서에서는 문장이 멋진 것보다 그 내용을 실제 자료로 설명할 수 있는지가 더 중요하다.

그래서 AI에게 보고서를 바로 작성하게 하기 전에

주장 → 근거 → 출처

를 한 번 연결해보는 방법을 추천한다.

특히 숫자나 원인, 일정처럼 틀렸을 때 문제가 될 수 있는 내용이라면 꽤 유용하다.

그리고 근거가 확인됐다면 다음에는 한 단계 더 넘어가볼 수 있다.

그래서 이 내용이 왜 중요한가?

다음 글에서는 확인한 사실을 영향과 필요한 판단으로 연결하는 AI 보고서 작성법 3편｜상사가 ‘그래서?’ 라고 묻지 않는 So What 질문법을 정리해보려고 한다.

AI 보고서 작성법 1편｜자료를 요약하기 전에 ‘변화’ 부터 찾는 이유

zeucise — Mon, 7 Sep 2026 22:53:36 +0900

AI 보고서 작성 전 자료의 변화와 이상점을 분석하는 방법

AI로 보고서를 작성할 때 가장 먼저 하는 일 중 하나가 자료 요약이다.

회의록이나 실적 자료를 넣고 “이 내용을 요약해줘” 라고 요청하면 금방 읽기 좋은 문장이 나온다.

나도 처음에는 그렇게 사용했다. 그런데 월간 실적 보고서를 작성할 때는 자료를 요약하는 것만으로는 부족했다.

보고서를 읽는 사람은 요약뿐 아니라, 이전과 비교해 무엇이 달라졌는지도 알고 싶어하기 때문이다

지난달과 비교해 무엇이 달라졌고, 그중 무엇을 확인해야 하는지가 보고서에는 더 중요하다.

이번 글에서는 간단한 실적 자료를 가지고, AI에게 요약 대신 변화를 찾아달라고 요청하는 방법을 정리해보려고 한다.

같은 자료도 비교하면 다른 질문이 보인다

아래는 설명을 위해 만든 가상 실적 자료다.

방문자 수는 해당 월에 서비스를 방문한 사람 수, 결제 건수는 완료된 결제 수라고 가정했다.

항목	7월	8월
방문자 수	1,000명	1,200명
결제 건수	100건	90건
결제 전환율	10.0%	7.5%

각 달의 자료를 따로 요약하면 “8월 방문자 수는 1,200명이고 결제 건수는 90건이다”와 같은 결과가 나올 수 있다.

숫자는 맞지만, 이 보고서를 받는 사람은 다시 물어볼 것이다.

그래서 7월과 비교해 좋아진 건가요, 나빠진 건가요?

이번에는 두 달의 숫자를 함께 보자.

방문자 수는 1,000명에서 1,200명으로 20% 증가했다.
결제 건수는 100건에서 90건으로 10% 감소했다.
결제 전환율은 10.0%에서 7.5%로 2.5%p 하락했다.

여기서 눈에 띄는 변화는 방문자는 늘었는데 결제는 줄었다는 점이다.

자료를 월별로 따로 요약했을 때보다, 다음에 확인할 질문이 분명해진다.

AI에게는 ‘요약’ 보다 ‘비교’ 를 요청한다

두 달의 자료를 AI에 제공한다면 이렇게 요청할 수 있다.

아래 7월과 8월 실적 자료를 비교해줘.

[자료]
7월: 방문자 수 1,000명, 결제 건수 100건
8월: 방문자 수 1,200명, 결제 건수 90건

다음 순서로 정리해줘.

1. 항목별 증가·감소와 계산식
2. 두 항목을 함께 봤을 때 확인할 만한 변화
3. 이 자료만으로는 알 수 없는 내용
4. 추가로 확인하면 좋은 자료

결제 전환율은 결제 건수 ÷ 방문자 수 × 100으로 계산해줘.
변화의 원인은 제공한 자료에서 확인되는 경우에만 적고,
확인되지 않으면 추측하지 말아줘.

이 요청에서 중요한 부분은 마지막 문장이다.

AI가 그럴듯한 원인을 만들어내지 않도록, 자료에서 확인되는 사실과 아직 확인하지 못한 이유를 나눠달라고 한 것이다.

이 자료로 정리할 수 있는 결과는 다음과 같다.

구분	확인한 내용
방문자 증가율	예시) (1,200−1,000)÷1,000×100 = 20%
계산으로 확인한 변화	방문자 수 20% 증가, 결제 건수 10% 감소, 결제 전환율 2.5%p 하락
보고서에서 짚을 문제	방문자가 늘었지만 결제로 이어진 비율은 낮아짐
아직 알 수 없는 내용	전환율이 하락한 원인
추가로 볼 자료	방문 경로, 결제 단계별 이탈, 상품·가격 변경 여부

※ 예시에서는 방문자 한 명이 해당 월에 최대 한 건만 결제했다고 가정했다.

이 표는 실제로 AI에 입력해 얻은 답변이 아니라, 위 자료에서 기대할 수 있는 분석 결과의 예시다.

사용하는 도구에 따라 표현은 달라질 수 있으므로 숫자와 해석은 직접 확인해야 한다.

숫자가 맞아도 원인은 따로 확인해야 한다

방문자가 늘고 결제가 줄었다고 해서 곧바로 이렇게 쓰면 곤란하다.

광고로 유입된 방문자의 구매 의사가 낮아져 결제 건수가 감소했다.

현재 표에는 광고 유입 자료가 없다. 구매 의사를 확인한 자료도 없다.

이 문장은 가능한 가설일 수는 있지만, 확인된 원인은 아니다.

지금 자료만으로 보고서에 쓸 수 있는 문장은 이 정도다.

8월 방문자 수는 전월보다 20% 증가했으나 결제 건수는 10% 감소했다. 결제 전환율은 10.0%에서 7.5%로 하락했다.
원인을 파악하기 위해 방문 경로와 결제 단계별 현황을 확인할 필요가 있다.

이렇게 쓰면 확인된 변화와 다음에 할 일이 구분된다.

AI 결과를 받은 뒤 내가 확인할 것

AI가 계산해줬더라도 원본 자료와 한 번 더 대조해야 한다.

7월과 8월의 집계 기준이 같은가?
방문자 수에 중복 방문자가 포함돼 있지 않은가?
결제 취소 건은 두 달에 같은 방식으로 처리했는가?
전환율 계산식이 회사에서 쓰는 기준과 같은가?
‘전월 대비 20% 증가’와 ‘전환율 2.5%p 하락’을 올바르게 구분했는가?

예를 들어 한 달은 결제 완료 건수, 다른 달은 결제 시도 건수를 사용했다면 숫자를 비교해도 올바른 결론을 낼 수 없다.

AI는 달라진 숫자를 빠르게 찾는 데 도움을 줄 수 있다.

그 숫자를 같은 기준으로 비교해도 되는지 확인하는 일은 원본 자료를 가진 사람이 해야 한다.

결국 보고서는 ‘무엇이 달라졌는지’에서 시작한다

자료 요약은 내용을 빠르게 파악할 때 유용하다. 하지만 지난달 실적, 프로젝트 진행 상황, 업무 현황처럼 이전 자료와 비교할 수 있는 보고서라면 나는 변화를 먼저 찾아보는 편이다.

무엇이 달라졌는가?
그중 무엇을 확인해야 하는가?
아직 근거가 없어 말할 수 없는 것은 무엇인가?

이 세 가지를 구분하면 AI가 만든 그럴듯한 문장을 그대로 보고서에 옮길 가능성도 줄어든다.

다만 변화를 발견했다고 해서 그 이유까지 확인된 것은 아니다.

다음 글에서는 보고서의 주장과 원본 자료의 근거를 연결해 확인하는 방법을 살펴보려고 한다.

AI 보고서 작성법 2편｜그럴듯한 오류를 잡는 주장-근거 검증법

옵시디언 Markdown 사용법 — 이것만 알면 글쓰기는 충분하다

zeucise — Wed, 2 Sep 2026 22:54:48 +0900

Obsidian을 설치하고 첫 노트를 만들었다.

그런데 막상 글을 쓰려고 하니 조금 낯설다.

# 제목
**굵은 글씨**
[[다른 노트]]
![[image.png]]

처음 보면 코드를 작성하는 것처럼 보인다.

“이걸 전부 외워야 하나?”

나도 처음에는 그렇게 생각했다.

그런데 실제로 사용해보면 자주 사용하는 Markdown 문법은 생각보다 많지 않다.

이번 글에서는 Obsidian을 처음 설치한 사람이 바로 사용할 만한 Markdown 문법만 정리해보려고 한다.

제목을 만들고, 목록을 작성하고, 다른 노트를 연결하고, 사진을 넣는 것까지 직접 해보자.

Markdown이 뭘까?

Markdown은 글에 간단한 기호를 붙여 문서의 구조를 표현하는 방법이다.

예를 들어 제목을 쓰고 싶다면,

# Obsidian 공부

이렇게 작성한다.

중간 제목은 #을 하나 더 붙인다.

## Markdown 사용법

중요한 부분을 굵게 표시하고 싶다면,

**중요한 내용**

이렇게 하면 된다.

HTML처럼 복잡한 태그를 사용할 필요가 없다.

그래서 마우스로 메뉴를 찾지 않고도 키보드만으로 글의 구조를 만들 수 있다.

처음에는 이것만 알아도 충분하다

Markdown에는 문법이 꽤 많다.

하지만 처음부터 모두 외울 필요는 없다.

Obsidian을 시작할 때는 아래 정도면 충분하다.

하고 싶은 것	Markdown
제목	`# 제목`
소제목	`## 소제목`
굵게	`내용`
기울임	`내용`
하이라이트	`==내용==`
취소선	`~~내용~~`
목록	`- 내용`
번호 목록	`1. 내용`
체크박스	`- [ ] 할 일`
인용	`> 내용`
한 줄 코드	`code`

직접 작성해보면 이런 모습이다.

# 오늘의 공부

## Obsidian

오늘부터 **Obsidian**을 사용해보려고 한다.

중요한 내용은 ==이렇게 표시==해둔다.

오늘 할 일은 다음과 같다.

- Markdown 배우기
- 노트 만들기
- 링크 연결하기

- [x] Obsidian 설치
- [ ] Markdown 공부
- [ ] 플러그인 알아보기

> 처음부터 모든 기능을 배울 필요는 없다.

이 정도만 사용할 수 있어도 꽤 그럴듯한 노트가 만들어진다.

위의 예제를 실제 Obsidian에 입력한 화면을 넣으면 좋다.

Markdown 문법과 실제 표시 결과가 함께 보이도록 캡처하면 처음 사용하는 사람도 이해하기 쉽다.

개발이나 AI 공부를 한다면 코드 블록도 알아두자

개발 관련 자료를 정리하거나 ChatGPT 프롬프트를 저장하다 보면 코드를 넣을 일이 많다.

한 줄짜리 코드는 이렇게 작성한다.

`pip install pandas`

여러 줄을 넣으려면 백틱 세 개를 사용한다.

```python
import pandas as pd

df = pd.read_csv("data.csv")
print(df.head())
```

python 대신 javascript, html, json 등을 넣을 수도 있다.

AI나 개발 내용을 Obsidian에 정리하려고 한다면 꽤 자주 사용하게 되는 문법이다.

Obsidian에서는 `[[링크]]`가 더 중요하다!!

Markdown 문법을 조금 익히고 나면 Obsidian다운 기능이 하나 등장한다.

바로 노트와 노트를 연결하는 기능이다.

예를 들어 내 Vault에 이런 노트가 있다고 해보자.

Obsidian 설치 방법
Markdown 사용법
ChatGPT 활용법

현재 작성 중인 글에서 Obsidian 설치 방법 노트로 이동하고 싶다면 이렇게 작성한다.

[[Obsidian 설치 방법]]

간단하다.기존에 작성한 노트가 검색되기 때문에 파일 이름을 전부 외울 필요도 없다.

입력했을 때 기존 노트가 자동으로 나타나는 화면을 넣어보자.

이 장면 하나만 있어도 Obsidian의 링크 기능을 바로 이해할 수 있다.

노트 안의 특정 제목으로 바로 이동할 수도 있다.

[[Markdown 사용법#이미지 넣기]]

이 기능이 처음에는 별것 아닌 것처럼 보인다.

하지만 노트가 많아지면 이야기가 달라진다.

Obsidian
  ↓
Markdown
  ↓
블로그 작성
  ↓
ChatGPT 활용

관련된 자료를 계속 연결할 수 있기 때문이다.

개인적으로는 Markdown 자체보다 이 링크 기능이 Obsidian을 사용하는 중요한 이유 중 하나라고 생각한다.

인터넷 주소를 넣는 방법

웹사이트 링크도 자주 사용한다.

형식은 간단하다.

[보여줄 이름](웹사이트 주소)

예를 들어,

[Obsidian 공식 도움말](https://help.obsidian.md)

이라고 작성하면 된다.

처음에는 []와 () 순서가 조금 헷갈린다.

나는 그냥 이렇게 기억하는 편이다.

[사람에게 보여줄 이름](실제 주소)

논문이나 공식 문서, 참고자료를 정리할 때 꽤 유용하다.

사진은 어떻게 넣을까?

처음 Obsidian을 사용할 때 궁금했던 부분 중 하나가 이미지였다.

일반적인 Markdown 이미지 문법은 다음과 같다.

![이미지 설명](이미지 주소)

하지만 Obsidian에서는 더 간단한 방법도 사용할 수 있다.

이미지를 노트 안으로 드래그하거나 복사해서 붙여넣으면 된다.

그러면 보통 이런 형태로 들어간다.

![[obsidian-markdown.png]]

앞에서 사용했던 내부 링크와 비교해보자.

문법	기능
`[[Markdown 사용법]]`	다른 노트로 이동
`![[image.png]]`	이미지를 노트 안에 표시

차이는 ! 하나다.

앞에 !가 붙으면 현재 노트 안에 보여준다고 생각하면 쉽다.

이미지가 너무 크다면 크기도 조절할 수 있다.

![[obsidian-markdown.png|500]]

이렇게 하면 이미지의 너비를 조절할 수 있다.

같은 이미지를 기본 크기와 |500을 적용한 상태로 비교해 보여주면 이해하기 쉽다.

표도 Markdown으로 만들 수 있다

정보를 비교할 때는 표가 편하다. Markdown에서는 이렇게 작성한다.

| 프로그램 | 특징 |
|---|---|
| Obsidian | Markdown 기반 |
| Notion | 블록 기반 |
| OneNote | 자유로운 노트 |

결과는 이런 형태가 된다.

프로그램	특징
Obsidian	Markdown 기반
Notion	블록 기반
OneNote	자유로운 노트

처음부터 직접 입력하기에는 조금 귀찮을 수 있다.

그래도 AI나 개발 관련 자료를 비교해서 정리할 때는 꽤 유용하다.

지금까지 배운 것으로 노트 하나를 만들어보자

마지막으로 지금까지 나온 문법을 하나의 노트에 넣어보자.

# 나의 Obsidian 공부

## 오늘 할 일

- [x] Obsidian 설치
- [x] Markdown 배우기
- [ ] 노트 연결하기

## 오늘 배운 내용

**Markdown**은 간단한 기호로
문서의 구조를 만드는 방법이다.

중요한 내용은 ==이렇게 표시==한다.

## 관련 노트

- [[Obsidian 설치 방법]]
- [[ChatGPT 활용법]]

## 참고 자료

[Obsidian 공식 도움말](https://help.obsidian.md)

## 이미지

![프로필|500](file:///C:/프로필.PNG)

## 코드

```python
print("Hello Obsidian")
```

> Markdown을 전부 외울 필요는 없다.

이 노트를 직접 한번 만들어보면 이번 글에서 설명한 내용은 거의 다 사용해본 셈이다.

실제로 모든 내용을 적용하면 아래와 같이 나온다.

Markdown을 전부 외울 필요는 없다

처음 Markdown을 보면 기호가 많아 보인다.

하지만 실제로 사용하다 보면 몇 가지 문법만 계속 사용하게 된다.

# 제목

**굵게**

- 목록

- [ ] 체크박스

[[노트 연결]]

[외부 링크](주소)

![[이미지]]

처음에는 이 정도만 기억해도 충분하다. 모르는 문법은 필요할 때 찾아보면 된다.

오히려 Obsidian에서는 Markdown 문법을 모두 외우는 것보다

[[노트와 노트를 연결하는 방식]] 에 익숙해지는 것이 더 중요하다고 생각한다.

노트를 하나씩 연결하기 시작하면 그때부터 Obsidian이 단순한 메모장과 조금 다르게 느껴지기 시작한다.

다음 글에서는 Markdown으로 만든 노트들을 이용해 Obsidian의 폴더와 링크를 어떻게 구성하면 좋은지 정리해보려고 한다.

윈도우 옵시디언 설치 방법: 다운로드부터 새 보관함 만들기

zeucise — Wed, 2 Sep 2026 22:45:50 +0900

옵시디언의 설치는 대단히 간단하다.

공식 사이트에서 윈도우용 파일을 받고, 프로그램을 실행한 뒤 새 보관함을 만들면 된다. 기본 사용은 무료이고 계정도 필요 없다.

1. 옵시디언 공식 사이트에서 설치 파일 다운로드

옵시디언 공식 다운로드 페이지에 접속한다. 화면 위쪽의 Download for Windows를 누르거나 App 목록에서 Windows의 Universal을 선택하면 된다.

Universal은 윈도우용 설치 파일을 뜻한다. 버전 번호는 업데이트할 때마다 달라질 수 있으니 이미지와 달라도 괜찮다.

2. 윈도우에서 설치 파일 실행

다운로드가 끝나면 다운로드 폴더에서 .exe 파일을 찾아 두 번 클릭한다. 설치 창의 안내를 따르고, 바꿀 항목이 없다면 기본 설정으로 진행한다.

설치가 끝나면 윈도우 시작 메뉴나 바탕 화면에서 옵시디언을 실행한다.

3. 옵시디언 한국어 설정

새 보관함 화면의 언어 메뉴에서 한국어를 선택한다. 영어로 시작했다면 나중에 Settings → General → Language에서 바꿀 수 있다.

4. 새 보관함 만들기

처음에는 ‘보관함(Vault)’이라는 단어가 낯설 수 있다. 어렵게 생각할 필요는 없다. 노트와 설정이 저장되는 일반 폴더다.

처음 시작한다면 새 보관함 만들기(Create new vault)를 선택한다.

다음 두 항목만 정하면 된다.

보관함 이름: 어떤 노트를 모을지 알아보기 쉬운 이름을 입력한다. 예: My Notes
저장 위치: 문서 폴더처럼 나중에 쉽게 찾을 수 있는 위치를 선택한다.

마지막으로 만들기(Create)를 선택한다. 옵시디언 편집 화면이 열리면 설치와 새 보관함 준비가 끝난 것이다.

5. 정리

옵시디언 설치 과정은 아래 네 단계로 정리할 수 있다.

공식 사이트에서 윈도우용 설치 파일을 받는다.
.exe 파일을 실행한다.
표시 언어를 한국어로 바꾼다.
보관함 이름과 저장 위치를 정한다.

여기까지 완료하면 새 노트를 만들어 기록할 수 있다.

참고 자료

AI 프롬프트 작성법｜어디서나 사용하는 기본 템플릿

zeucise — Wed, 2 Sep 2026 17:54:45 +0900

기본 프롬프트 템플릿

[목표] 내가 최종적으로 하고 싶은 일을 작성합니다. 

[상황] 현재 상황과 AI가 알아야 할 배경을 작성합니다. 

[대상] 결과물을 누가 사용할지 작성합니다. 

[원하는 내용] 반드시 포함해야 할 내용을 작성합니다. 
-
-
-

[조건] 지켜야 할 조건이나 제외해야 할 내용을 작성합니다. 
-
-
-

[참고자료] AI가 참고해야 할 자료가 있다면 작성하거나 첨부합니다. 

[원하는 결과] 결과물을 어떤 형태로 받고 싶은지 작성합니다.
 - 형식:
 - 길이:
 - 말투:
 - 구성: 

[확인사항] 
정보가 부족한 부분은 임의로 만들지 말고 알려줘. 
사실 확인이 필요한 내용은 가능한 경우 출처와 기준 날짜를 함께 알려줘.

빠르게 사용하는 Quick 템플릿

[목표] 무엇을 하고 싶은지 

[상황] AI가 알아야 할 배경 

[조건] 반드시 지켜야 할 것 

[결과] 원하는 답변 형태

한 문장으로 질문할 때

나는 [목표]를 하려고 해. 현

재 [상황]이고, [조건]을 지켜서 [원하는 결과] 형태로 만들어줘.

글쓰기에 사용할 때

[목표] ○○에 대한 글을 작성하려고 해. 

[독자] 이 글을 읽을 사람은 ○○이야. 

[핵심 내용] 반드시 다음 내용을 포함해줘.
 -
 -
 - 

[조건]
 - 어려운 표현은 줄여줘.
 - 같은 내용을 반복하지 말아줘.
 - 확인되지 않은 경험이나 사실을 임의로 만들지 말아줘. 

[결과]
 - 글 형태:
 - 글 길이:
 - 말투:
 - 제목 포함 여부:

자료 조사에 사용할 때

[목표] 
○○에 대해 조사하려고 해. 

[알고 싶은 내용]
 -
 -
 - 

[조건]
 - 최신 정보를 우선해서 찾아줘.
 - 공식 자료와 신뢰할 수 있는 출처를 우선해줘.
 - 확인되지 않는 내용은 추측하지 말아줘.
 - 서로 다른 자료의 내용이 다르면 차이를 알려줘. 

[결과] 
핵심 내용을 먼저 요약하고, 근거와 출처를 함께 정리해줘.

최근에 여행을 위해 작성한 프롬프트이다.

2026.08.29 - [AI Research/프롬프트] - ChatGPT로 후쿠오카 3박 4일 여행 계획 짜기 | 일정·숙소·경비 프롬프트

AI 사용법 10가지｜좋은 답을 얻는 프롬프트 작성법과 실전 예시

zeucise — Wed, 2 Sep 2026 15:39:28 +0900

AI를 처음 사용할 때는 꽤 신기하다.

질문 하나를 입력하면 몇 초 만에 그럴듯한 답을 만들어준다.

그런데 조금 사용하다 보면 이런 순간이 생긴다.

“왜 이렇게 뻔한 이야기만 하지?”

“내가 원하는 답은 이게 아닌데?”

“분명히 설명했는데 왜 자꾸 다르게 이해하지?”

처음에는 AI를 잘 쓰려면 특별한 프롬프트나 명령어를 많이 알아야 하는 줄 알았다.

그런데 계속 사용하다 보니 오히려 중요한 것은 단순했다.

내가 원하는 것을 AI가 판단하기 쉽게 알려주는 것.

이번 글에서는 AI를 처음 사용하는 사람들이 자주 겪는 문제 10가지와 해결 방법을 정리해보려고 한다.

AI 사용법, 먼저 한눈에 보면

이런 문제가 있다면?	이렇게 바꿔보자!
답변이 너무 뻔하다	목적과 상황을 알려준다
원하는 답과 다르다	결과 형태를 지정한다
답변이 너무 길다	원하는 길이를 정한다
설명이 너무 어렵다	독자의 수준을 알려준다
자꾸 엉뚱하게 이해한다	예시를 보여준다
복잡한 작업을 놓친다	작업을 단계로 나눈다
첫 답변이 마음에 안 든다	대화를 이어서 수정한다
틀린 내용을 사실처럼 말한다	출처와 검증을 요청한다
제공한 자료를 제대로 안 쓴다	사용할 범위를 지정한다
매번 같은 말을 반복한다	프롬프트를 템플릿으로 만든다

1. 무엇을 원하는지 먼저 알려준다.

가장 흔한 경우다.

예를 들어 이렇게 질문한다고 해보자.

노트북 추천해줘!

틀린 질문은 아니다.

하지만 AI 입장에서는 판단해야 할 것이 너무 많다.

게임용인지, 업무용인지, 예산은 얼마인지 알 수 없다.

조금 바꿔보자.

150만원 이하의 개발용 노트북을 추천해줘.

집과 회사 사이에 가지고 다닐 예정이라 무게도 중요해.

이제 조건이 훨씬 분명해졌다.

처음에는 세 가지만 생각해도 좋다.

무엇을 원하는지 + 어떤 상황인지 + 조건은 무엇인지

이것만 추가해도 답변이 꽤 달라진다.

2. 원하는 결과의 형태를 정한다.

내용은 맞는데 읽기 불편한 답변이 나오는 경우가 있다.

그럴 때는 결과 형태를 직접 지정하면 된다.

예를 들어,

아이폰과 갤럭시의 차이를 알려줘!

보다

아이폰과 갤럭시를 가격, 카메라, 배터리, 편의성 기준으로 표로 비교해줘.

라고 요청하는 편이 훨씬 읽기 쉽다.

AI에는 다음처럼 요청할 수 있다.

표
목록
Markdown
체크리스트
이메일
보고서
블로그 글

무엇을 알려달라고 할지뿐 아니라 어떻게 보여달라고 할지도 중요하다.

3. 답변 길이도 직접 정한다

AI에게 자세하게 설명해달라고 하면 정말 자세하게 설명할 때가 있다.

문제는 내가 그렇게 긴 답변을 원하지 않았다는 것이다.

그럴 때는 그냥 말하면 된다.

핵심 내용만 5줄 이내로 알려줘.

또는 중요한 내용 3가지만 정리해줘.

반대로 자세히 알고 싶다면, 초보자가 이해할 수 있도록 예제를 포함해서 자세히 설명해줘.

라고 하면 된다.

생각보다 답변 길이도 꽤 잘 조절된다.

4. 내가 어느 정도 알고 있는지 알려준다.

같은 내용도 누가 읽느냐에 따라 설명 방식은 달라져야 한다.

예를 들어,

"Python의 Class를 설명해줘." 라고 할 수도 있다.

하지만 초보자라면 이렇게 요청하는 편이 낫다.

Python을 막 배우기 시작했어.
Class가 무엇인지 실생활 예제를 이용해서 쉽게 설명해줘.

다음처럼 독자를 지정해도 된다.

초등학생도 이해할 수 있게 설명해줘.
비전공 직장인을 대상으로 설명해줘.
개발 경력 5년인 사람이 읽는다고 생각하고 설명해줘.

AI에게도 누가 읽을 것인지 알려주는 것이 중요하다.

5. 말로 설명하기 어렵다면 예시를 보여준다.

글쓰기에서 특히 유용한 방법이다.

예를 들어,

"자연스럽게 작성해줘" 라고 요청하면 조금 애매하다.

사람마다 생각하는 '자연스러운 글'이 다르기 때문이다.

이럴 때는 내가 좋아하는 문장을 하나 보여주는 편이 빠르다.

아래 글의 문장 길이와 말투를 참고해서 작성해줘.
내용은 따라 하지 말고 문체만 참고해줘.

말로 조건을 길게 설명하는 것보다 예시 하나가 더 정확할 때가 많다.

6. 복잡한 작업은 한 번에 시키지 않는다.

AI를 사용하다 보면 욕심이 생긴다.

한 번에 이것저것 부탁하게 된다.

예를 들어,

자료를 조사하고 분석한 뒤 블로그 글을 쓰고 SEO까지 적용해줘.

가능한 요청이지만 사실 여러 작업이 섞여 있다.

나눈다면 이런 식이다.

자료를 조사한다.
중요한 내용을 정리한다.
글의 구조를 만든다.
초안을 작성한다.
마지막으로 문장과 SEO를 검토한다.

복잡한 작업일수록 한 번에 완벽한 답을 요구하기보다 단계별로 확인하는 편이 편하다.

특히 보고서, 개발, 블로그처럼 결과물이 긴 작업에서 유용하다.

7. 첫 번째 답변에서 끝내지 않는다.

AI를 검색창처럼 사용하는 경우가 있다.

질문 하나를 던지고 답이 마음에 들지 않으면 처음부터 다시 질문한다.

하지만 AI의 장점은 대화를 이어갈 수 있다는 것이다.

첫 답변이 마음에 들지 않는다면 이렇게 말해보자.

조금 더 쉽게 설명해줘.

2번만 자세히 설명해줘

나는 첫 번째 답변을 완성본보다는 초안이라고 생각하는 편이다.

한두 번 수정하다 보면 원하는 결과에 훨씬 가까워진다.

8. 중요한 정보는 출처를 확인한다.

AI를 사용할 때 가장 조심해야 할 부분이다.

AI가 만든 글은 문장이 자연스럽다.

그래서 틀린 내용도 맞는 것처럼 느껴질 수 있다.

특히 다음과 같은 정보는 한 번 더 확인하는 편이 좋다.

법률
의료
세금
투자
최신 뉴스
제품 가격과 사양
최근 변경된 정책과 제도

이런 내용은 다음처럼 요청할 수 있다.

최신 자료를 확인해서 알려줘.

출러와 기준 날짜도 같이알려줘.

하지만 출처가 붙었다고 무조건 끝나는 것은 아니다.

중요한 의사결정이라면 원문까지 직접 확인하는 습관이 필요하다.

AI는 도움을 주는 도구이지 모든 사실을 대신 검증해주는 도구는 아니다.

9. 사용할 자료의 범위를 정한다

PDF나 논문, 회사 자료를 올려서 요약할 때 유용하다.

자료를 제공했는데 AI가 알고 있던 일반 지식까지 섞어서 설명하면 곤란한 경우가 있다.

이럴 때는 범위를 분명히 지정한다.

첨부한 파일의 내용만 사용해줘.

파일에서 확인되지 않는 내용은 추측하지 말고, '확인할 수 없음' 이라고 표시해줘.

이 한 문장을 넣으면 기준이 훨씬 명확해진다.

특히 논문, 계약서, 회사 문서처럼 사실과 추측을 구분해야 하는 작업에서 유용하다.

10. 질문이 어렵다면 기본 공식부터 사용한다.

매번 같은 설명을 다시 작성할 필요는 없다.

자주 하는 작업이라면 기본 틀을 하나 만들어두는 편이 좋다.

처음에는 조금 번거로워 보인다.

하지만 반복해서 사용하는 작업이라면 매번 처음부터 설명하지 않아도 된다.

업무, 블로그, 공부, 코딩 등 여러 곳에서 사용할 수 있다.

AI를 잘 사용하는 가장 간단한 방법

10가지를 전부 외울 필요는 없다.

처음에는 네 가지만 기억해도 충분하다.

무엇을 원하는지 말한다.

어떤 상황인지 알려준다.

결과를 어떤 형태로 원하는지 정한다.

답변을 보고 다시 수정한다.

AI를 잘 사용하는 데 특별한 주문이 필요한 것은 아니다.

사람에게 일을 부탁하는 것과 생각보다 비슷하다.

“이것 좀 해줘.” 라고 말하는 것보다,

“왜 필요한지, 어떤 결과를 원하는지, 무엇을 조심해야 하는지” 를 알려주는 편이 좋은 결과가 나오는 것과 같다.

처음부터 완벽한 프롬프트를 만들려고 하지 않아도 된다.

질문하고, 답변을 보고, 부족한 부분을 다시 이야기해보자.

이 과정에 익숙해지는 것만으로도 같은 AI에서 꽤 다른 답변을 얻을 수 있다.

기본 템플릿 링크 공유 : 2026.09.02 - [AI Research/프롬프트] - AI 프롬프트 작성법｜어디서나 사용하는 기본 템플릿

프롬프트 엔지니어링은 왜 언어철학과 닮았을까? 오스틴 언어행위론으로 보는 ChatGPT

zeucise — Tue, 1 Sep 2026 15:03:55 +0900

프롬프트 엔지니어링은 단순히 AI에게 명령을 잘 쓰는 기술일까?

J. L. Austin의 언어행위론을 통해 프롬프트와 언어, 맥락, 행동의 관계를 살펴봅니다.

오스틴의 언어행위론으로 보는 ChatGPT

프롬프트 엔지니어링을 처음 접하면 보통 이렇게 생각한다.

“ChatGPT에게 어떻게 말해야 좋은 답을 얻을 수 있을까?”

그런데 조금 다르게 생각해볼 수도 있다.

“언어는 어떻게 상대방의 행동을 만들어낼까?”

흥미롭게도 이 질문을 AI가 등장하기 훨씬 전부터 고민한 철학자가 있다.

영국의 언어철학자 J. L. Austin이다.

말은 정보를 전달하기만 할까?

Austin은 《How to Do Things with Words》에서 언어를 단순한 정보 전달 수단으로 보지 않았다.

대표적인 생각을 간단히 표현하면 이렇다.

“To say something is to do something.”

말하는 것 자체가 하나의 행동이 될 수 있다

예를 들어, “문을 닫아.” 라는 말은 문에 대한 정보를 설명하는 문장이 아니다.

상대방에게 문을 닫도록 요청하는 행동이다.

우리는 말을 통해 설명하기도 하지만, 요청하고, 약속하고, 명령하고, 행동을 유도하기도 한다.

프롬프트도 비슷하다.

ChatGPT에 이렇게 입력한다고 해보자.

이 글을 요약해줘.

두 제품의 차이를 표로 정리해줘.

이 문장들은 정보를 전달하기 위한 말이 아니다.

AI에게 어떤 작업을 하도록 요청하는 언어다.

그래서 프롬프트를 단순한 질문이라기보다

자연어로 작성한 행동 요청 이라고 볼 수도 있다.

Austin의 언어행위론으로 보면

Austin은 언어행위를 여러 층위로 구분했다.

이를 프롬프트에 비유하면 이렇게 볼 수 있다.

언어행위쉽게 말하면프롬프트에 비유하면

발화행위	무엇을 말했는가	입력한 문장
발화수반행위	무엇을 하려는가	요약·비교·설명 등의 요청
발화효과행위	어떤 효과가 생겼는가	AI가 생성한 결과

물론, Austin의 이론을 AI에 그대로 적용할 수 있다는 뜻은 아니다.

하지만 프롬프트를 이해하는 관점으로 보면 꽤 흥미롭다.

중요한 것은 어떤 문장을 썼는가보다 그 문장으로 AI에게 무엇을 하게 만들고 싶은가다.

같은 요청인데 결과가 다른 이유

예를 들어,

회의 내용을 정리해줘.

라고 할 수 있다.

하지만 이렇게 요청하면 결과가 달라진다.

임원 보고용으로
핵심 결정사항과 후속 조치만
표로 정리해줘.

두 문장 모두 '정리'를 요청한다.

하지만 두 번째 프롬프트에는

누구를 위한 결과인지
무엇이 중요한지
어떤 형태로 만들 것인지

가 들어 있다.

즉, 단순히 문장이 길어진 것이 아니다.

AI가 해야 할 행동의 조건이 구체적으로 정해진 것이다.

프롬프트를 보는 질문을 바꿔보자

좋은 프롬프트를 만들기 위해 반드시 복잡한 기법이 필요한 것은 아니다.

먼저 이것부터 생각해보면 된다.

“나는 지금 AI에게 무엇을 하게 만들고 싶은가?”

그 다음 필요한 맥락과 조건을 추가한다.

누구를 위한 결과인지,

무엇이 중요한지,

어떤 형태로 받고 싶은지를 알려주는 것이다.

결국 프롬프트 엔지니어링은 말을 길게 쓰는 기술보다

언어로 행동의 조건을 설계하는 일에 가까운지도 모르겠다.

AI가 등장하면서 오래된 언어철학의 질문이 꽤 실용적인 질문이 된 셈이다.

참고 자료

J. L. Austin, How to Do Things with Words
Stanford Encyclopedia of Philosophy, John Langshaw Austin
OpenAI, Prompt Engineering Best Practices for ChatGPT

ChatGPT 무료 vs 유료 차이 | Plus 월 29,000원 쓸 가치가 있을까?

zeucise — Mon, 31 Aug 2026 13:52:18 +0900

ChatGPT를 처음 사용할 때는 무료 버전만으로도 충분하다고 생각했다.

질문도 할 수 있고, 웹 검색도 된다. 파일을 올려 분석하거나 이미지도 만들 수 있다.

그렇다면 굳이 돈을 내면서까지 사용할 이유가 있을까?

개인적으로는 이 질문을

“유료 AI가 얼마나 더 똑똑한가?”

보다 이렇게 생각하는 편이 더 맞는 것 같다.

“나는 ChatGPT를 얼마나 자주, 중요한 일에 사용하는가?”

무료도 생각보다 충분하다.

2026년 현재 ChatGPT 무료 버전에서도 웹 검색, 파일 업로드, 데이터 분석, 이미지 생성 등을 사용할 수 있다.

다만 파일이나 이미지 같은 도구에는 사용 한도가 있다.

가끔 질문하거나 번역, 요약, 여행 정보 검색, 간단한 문서 작성 정도라면 무료로도 충분한 사람이 많을 것 같다.

처음 사용한다면 바로 결제하기보다 무료부터 써보는 것이 좋다.

Free, Go, Plus 중 고를 수 있다.

Go는 무료보다 파일 업로드, 이미지 생성, 데이터 분석 등의 이용 한도가 높다. Plus는 여기에 고급 추론과 더 넓은 파일·리서치 기능을 제공한다.

Free	0원	가끔 질문·검색
Go	13,000원	파일·이미지를 조금 더 자주 사용
Plus	29,000원	업무·공부·코딩·리서치에 적극 활용

※ 여기서 PRO는 제외했다. 우리는 직장인 또는 대학생이지, 개발자나 AI 관련 종사자가 아니라서 그 정도의 사용량은 필요없다고 생각한다.

유료는 언제 돈값을 할까?

개인적으로는 사용하다가 보면, 한도가 넘어 사용하지 못할 때가 고민하는 것이 더 좋을 것 같다.

직장인이 파일 분석 → 자료 검색 → 보고서 작성 → 수정 을 반복하거나,

대학생이 논문 검색 → PDF 요약 → 내용 비교 → 과제 정리 를 계속한다면 무료 사용 한도가 불편해질 수 있다.

이때부터는 “더 좋은 답을 받기 위해서” 보다 “AI를 계속 작업 도구로 사용하기 위해서” 유료를 쓰는 의미가 커진다.

나는 이렇게 생각한다.

가끔 사용한다 → Free
무료는 좋은데 사용량이 조금 부족하다 → Go
ChatGPT를 거의 매일 업무나 공부에 사용한다 → Plus
무시무시한 사용량을 통해 프로그램을 만든다. → PRO

특히 Plus를 고민한다면 이것만 생각해보면 된다.

"ChatGPT를 못 쓰면 업무나 공부가 불편한가?" 이런 생각이 든다면, 아직 무료도 충분하다.

반대로 파일 분석, 리서치, 코딩처럼 여러 작업을 반복하고 있고 사용 한도 때문에 흐름이 자주 끊긴다면 월 29,000원을 고려해볼 만하다.(ChatGPT뿐 아니라 Claude 같은 AI도 마찬가지다.)

처음부터 여러 AI를 모두 결제하기보다는 무료로 먼저 사용해보고, 가장 많이 사용하는 AI 하나부터 유료로 전환하는 것이 현실적인 방법이라고 생각한다.

결국 가장 합리적인 순서는 이것인 것 같다.

"무료로 시작 → 부족한 점 확인 → 필요하면 유료 결제"

AI도 일단 돈부터 내기보다 내가 얼마나 사용하는지를 먼저 확인하는 것이 중요하다.

ChatGPT로 후쿠오카 3박 4일 여행 계획 짜기 | 일정·숙소·경비 프롬프트

zeucise — Sat, 29 Aug 2026 20:02:38 +0900

이전에 ROPE(Requirement-Oriented Prompt Engineering) 논문을 읽고 가장 기억에 남았던 내용이 하나 있었다.

좋은 프롬프트는 길게 쓰는 것보다 내가 원하는 요구사항을 빠뜨리지 않는 것이 중요하다는 것.

그렇다면 이걸 실제 ChatGPT에서는 어떻게 사용할 수 있을까?

이번에는 후쿠오카 3박 4일 자유여행 계획을 예로 만들어봤다.

여행 계획을 부탁할 때 무엇을 알려줘야 할까?

ChatGPT에 단순히 "후쿠오카 3박 4일 여행 일정 만들어줘." 라고 입력해도 여행 계획은 만들어준다.

문제는 그 일정이 내가 원하는 여행인지다.

나는 이동이 너무 많지 않고, 맛집·카페·쇼핑·관광이 적절하게 섞여 있으면서 실제 여행에서 그대로 따라갈 수 있는 일정을 원할 수 있다. 숙소는 하카타나 텐진 근처를 원할 수도 있고, 렌터카 없이 대중교통만 이용하고 싶을 수도 있다.

이런 조건을 말하지 않으면 AI는 알아서 추측해야 한다.

그래서 프롬프트를 만들 때 다음 정도만 생각해봤다.

목표
↓
요구사항
↓
제약조건
↓
원하는 결과
↓
성공기준
↓
빠진 요구사항 확인

개인적으로 여기서 가장 중요하다고 생각하는 것은 마지막 두 가지다.

어떤 결과가 나오면 만족할 것인가? 그리고 내가 빠뜨린 중요한 조건은 없는가?

여행 프롬프트에서는 '최신 정보 확인' 도 중요하다.

여행 계획에는 일반적인 프롬프트와 조금 다른 문제가 하나 있다.

맛집의 영업시간이 바뀔 수도 있고, 호텔 가격이나 휴무일, 교통편도 여행 시점에 따라 달라질 수 있다.

그래서 여행 프롬프트에는 한 가지 조건을 추가하는 것이 좋다고 생각한다.

최신 정보가 필요한 내용은 현재 정보를 검색해서 확인하도록 하는 것.

특히 맛집, 관광지, 교통편처럼 실제 여행에 영향을 주는 정보라면 가능하면 공식 홈페이지나 공식 관광 정보를 먼저 확인하게 하는 편이 좋다. 확인할 수 없는 정보라면 AI가 임의로 만들어내지 않도록 하는 것도 중요하다.

ChatGPT 후쿠오카 3박 4일 여행 계획 프롬프트

아래는 이런 기준을 적용해서 만든 프롬프트다.

ChatGPT에 그대로 복사해서 사용하고, 여행 날짜나 예산 정도만 바꿔도 된다.

일본 후쿠오카 3박 4일 자유여행 계획을 짜줘. 

[목표] 
성인 2명이 처음 가는 후쿠오카 여행을 무리하지 않고 즐길 수 있는 현실적인 여행 계획을 만들고 싶어. 

[기본 여행 정보]
 - 출발지: 인천
 - 여행 기간: 3박 4일
 - 인원: 성인 2명
 - 이동수단: 대중교통 중심
 - 숙소 위치: 하카타 또는 텐진 근처
 - 숙소 예산: 1박 15만 원 내외
 - 여행 스타일: 너무 빡빡하지 않은 일정 

[원하는 여행]
 - 후쿠오카 대표 관광지를 적절히 포함
 - 맛집, 카페, 쇼핑, 관광을 골고루 구성
 - 하루에 너무 많은 지역을 이동하지 않도록 동선을 구성
 - 같은 지역의 장소는 가능하면 같은 날 묶기
 - 처음 방문하는 사람이 따라가기 쉬운 일정으로 만들기 

[원하는 결과] 
1. 3박 4일 전체 일정을 먼저 한눈에 표로 정리해줘. 
2. 이후 날짜별로 - 오전 - 점심 - 오후 - 저녁 순서로 자세한 일정을 작성해줘. 
3. 각 장소마다
 - 방문 이유
 - 다음 장소까지 이동 방법
 - 예상 이동시간을 알려줘. 
4. 하카타와 텐진 근처 숙소를 각각 비교해서 총 3곳 정도 추천해줘. 
5. 숙소마다 - 위치 - 예상 가격대 - 장점 - 단점 - 주요 관광지 접근성 을 비교해줘. 
6. 맛집과 관광지는 - 영업시간 - 휴무일 - 예약 필요 여부 를 확인해줘. 
7. 마지막에는 2인 기준 예상 여행경비를 - 숙박 - 식비 - 교통 - 관광 - 쇼핑 제외 기타비용으로 나눠 정리해줘. 
8. 항공권은 여행 날짜와 항공편 조건에 따라 가격 차이가 크므로 정확한 날짜 정보가 없다면 임의의 가격을 만들지 말아줘. 

[최신 정보 확인] 
영업시간, 휴무일, 교통정보, 가격처럼 변경될 수 있는 정보는 가능하면 현재 웹에서 다시 확인해줘. 
공식 홈페이지, 공식 관광청, 교통기관 등 신뢰할 수 있는 출처를 우선해서 확인해줘. 확인할 수 없는 내용은 추측해서 작성하지 말고 '확인 필요'라고 표시해줘. 

[성공기준] 
다음 조건을 만족하면 좋은 여행 계획이라고 판단할게.
 - 하루 이동이 지나치게 많지 않을 것
 - 관광·식사·쇼핑이 한쪽에 치우치지 않을 것
 - 동선이 불필요하게 앞뒤로 반복되지 않을 것
 - 실제 영업 중인 장소를 기준으로 할 것
 - 숙소에서 주요 관광지까지 이동하기 편리할 것
 - 3박 4일 동안 현실적으로 실행 가능한 일정일 것
 - 처음 후쿠오카에 가는 사람이 그대로 따라가기 쉬울 것 

[마지막 확인] 
내가 빠뜨린 정보 때문에 여행 계획이 크게 달라질 수 있다면 계획을 만들기 전에 꼭 필요한 질문만 최대 5개 해줘. 
내가 말하지 않은 중요한 조건을 임의로 결정하지 말고, 결과에 큰 영향을 주는 내용만 질문해줘.

프롬프트를 처음부터 완벽하게 만들 필요는 없는 것 같다

이 프롬프트를 만들면서도 모든 여행 조건을 처음부터 작성하지는 않았다.

실제로 여행한다면 출발 날짜와 비행기 시간, 꼭 가고 싶은 장소, 쇼핑 목적 같은 조건이 더 추가될 수 있다.

하지만 그것까지 처음부터 모두 생각해낼 필요는 없다고 생각한다.

중요한 것은 AI에게 바로 일을 시키기 전에 한 번 정도 생각해보는 것이다.

나는 정확히 어떤 여행을 원하는가?

어떤 결과가 나오면 좋은 여행 계획이라고 생각하는가?

그리고 내가 빠뜨린 중요한 정보가 있다면 AI가 먼저 질문하도록 하면 된다.

결국 프롬프트를 잘 쓰는 기술보다 내가 원하는 결과를 명확하게 정의하는 것이 더 중요한 것 같다.

ROPE 논문을 읽고 난 뒤에는 이 방법이 일상에서 가장 쉽게 적용할 수 있는 프롬프트 작성법이라는 생각이 들었다.

후쿠오카 대신 오사카, 도쿄, 제주도처럼 목적지만 바꿔도 거의 그대로 사용할 수 있다.

여행 기간과 예산, 함께 가는 사람 정도만 바꾸면 된다.

결국 좋은 여행 프롬프트도 긴 문장보다 빠뜨리지 않은 요구사항에서 시작하는 것 같다.

ChatGPT 프롬프트, 길이보다 '요구사항' 이 중요한 이유 — ROPE 논문 요약

zeucise — Fri, 28 Aug 2026 12:50:01 +0900

AI에게 좋은 답을 받으려면 프롬프트를 어떻게 작성해야 할까?

역할을 정해야 할까?

프롬프트를 길게 써야 할까?

아니면 특별한 작성 공식이 필요한 걸까?

최근 읽은 What Should We Engineer in Prompts? Training Humans in Requirement-Driven LLM Use ( https://dl.acm.org/doi/10.1145/3731756 ) 라는 논문에서는 조금 다른 이야기를 한다.

사람이 프롬프트에서 가장 집중해서 설계해야 하는 것은 특별한 기법이 아니라 자신이 원하는 결과를 정확하고 빠짐없이 표현한 요구사항(Requirements)이라는 것이다.

논문에서는 이를 ROPE(Requirement-Oriented Prompt Engineering), 즉 요구사항 중심 프롬프트 엔지니어링이라고 부른다.

꽤 흥미로운 실험 결과가 있었다

연구진은 초보자 30명을 대상으로 무작위 대조 실험을 진행했다.

요구사항을 중심으로 프롬프트를 작성하도록 훈련한 ROPE 그룹은 약 20%의 향상을 보인 반면, 기존 프롬프트 엔지니어링 방식으로 훈련한 그룹은 약 1% 향상에 그쳤다.

단순히 프롬프트 문장을 잘 쓰는 것보다 내가 무엇을 원하는지 찾아내고 빠뜨리지 않는 훈련이 중요할 수 있다는 결과다.

이 부분이 상당히 흥미로웠다.

AI를 많이 사용하는 입장에서 AI가 내 의도를 제대로 이해하지 못한다고 느낄 때가 많다.

그런데 생각해보면 AI가 내 의도를 이해하지 못한 것이 아니라, 원하는 내용을 충분히 설명하지 않은 경우도 꽤 많았다.

이 논문에서 특히 놓치면 안 되는 6가지

논문을 읽고 개인적으로 중요하다고 생각한 내용을 여섯 가지로 정리해봤다.

① 프롬프트의 중심을 '기법' 에서 '요구사항' 으로 옮긴다

역할(Role)을 지정하거나 출력 형식을 정하고 문장을 다듬는 것이 필요 없다는 이야기는 아니다.

다만 이런 부분은 AI와 프롬프트 최적화 도구가 발전하면서 점점 더 쉽게 도움받을 수 있다.

반대로

"내가 실제로 무엇을 원하는가?"

라는 질문에 대한 답은 결국 사용자가 정해야 한다.

그래서 사람은 프롬프트 문장을 꾸미는 것보다 요구사항을 발견하는 데 더 집중해야 한다는 것이 이 논문의 핵심 주장이다.

② 좋은 프롬프트란 반드시 긴 프롬프트가 아니다.

프롬프트가 길다고 결과가 좋아지는 것은 아니다.

중요한 것은 길이가 아니라 필요한 요구사항이 빠짐없이 들어 있는가다.

짧더라도 필요한 조건이 모두 들어 있다면 좋은 프롬프트가 될 수 있다.

반대로 아주 긴 프롬프트라도 중요한 조건 하나가 빠져 있다면 원하는 결과가 나오지 않을 수 있다.

③ 잘못 쓴 것보다 ‘말하지 않은 것’ 이 더 큰 문제가 될 수 있다.

논문에서는 필요한 요구사항을 빠뜨리는 Omission Error가 결과 품질에 큰 영향을 줄 수 있다고 설명한다.

예를 들어 AI에게 단순히

"Obsidian 소개 글을 작성해줘."

라고 요청했다고 해보자.

실제로 내가 원하는 것이

초보자를 대상으로 하고
Notion과 차이를 설명하고
너무 길지 않게 쓰고
실제 사용 경험과 정보를 구분하는 글

이라면 이 조건들을 말하지 않은 상태에서는 AI가 정확히 알아낼 방법이 없다.

결과가 마음에 들지 않더라도 AI가 말을 못 알아들은 것이 아니라 처음부터 내가 조건을 말하지 않았던 것일 수 있다.

④ LLM이 좋아져도 요구사항의 중요성은 사라지지 않는다.

AI가 점점 똑똑해지면 프롬프트를 대충 작성해도 될 것 같지만 논문의 결론은 조금 다르다.

모델이 사용자의 지시를 더 잘 이해하고 따를수록 오히려 어떤 지시를 했는지가 결과에 더 직접적으로 반영될 수 있다.

AI가 좋아질수록 요구사항을 작성하는 사람의 역할이 사라진다기보다 형태가 바뀌는 것이다.

⑤ Prompt Optimizer도 내 머릿속까지 알 수는 없다.

AI는 기존 프롬프트를 정리하거나 표현을 개선하는 것은 상당히 잘한다.

하지만 사용자가 머릿속으로만 생각하고 말하지 않은 독특한 조건까지 항상 찾아낼 수 있는 것은 아니다.

결국 무엇을 원하는가?

라는 질문에 대한 최종 답은 사람이 가지고 있다.

AI에게 프롬프트를 개선해달라고 부탁하더라도 그 전에 내가 원하는 결과부터 생각해야 하는 이유다.

⑥ 앞으로 프롬프트 작성은 '글쓰기'보다 '요구사항 설계'에 가까워질 수 있다

개인적으로는 이것이 논문의 가장 중요한 메시지라고 생각한다.

프롬프트를 얼마나 멋있게 작성하는지가 아니라

내가 무엇을 원하는지 발견하고, 조건을 빠뜨리지 않고, 모호하지 않게 정의하는 능력

이 더 중요해질 수 있다는 것이다.

AI가 프롬프트의 표현이나 구조를 점점 더 잘 만들어준다면 사람은 오히려 무엇을 만들어야 하는지 정의하는 역할에 집중하게 될 것 같다.

그렇다면 실제 ChatGPT 프롬프트는 어떻게 작성해야 할까?

위의 논문을 읽으면서 생각해보면, 대략적인 순서는 아래와 같다.

무엇을 시킬까?
↓
내가 실제로 원하는 결과는 무엇인가?
↓
반드시 지켜야 하는 조건은 무엇인가?
↓
빠뜨린 조건은 없는가?
↓
애매하게 해석할 수 있는 부분은 없는가?
↓
예외 상황은 무엇인가?
↓
어떤 결과가 나오면 성공이라고 판단할 것인가?
↓
그 이후의 Role·구조·표현·최적화는 상당 부분 AI에게 맡긴다.

중요한 것은 이것을 또 하나의 프롬프트 공식으로 외우는 것이 아니다.

프롬프트를 작성하면서 "내가 말하지 않은 조건이 없는가?" 를 한 번 더 생각해보는 것이다.

최근 AI를 사용하면서 저도 프롬프트를 점점 길게 작성하고 있었다.

그런데 이 논문을 읽고 나서는 조금 생각이 바뀌었다.

프롬프트를 길게 만드는 것보다 내가 실제로 원하는 것이 무엇인지 먼저 정리하는 것이 더 중요할 수 있다.

어쩌면 앞으로 좋은 프롬프트를 작성하는 능력은 글을 잘 쓰는 능력보다 요구사항을 잘 정의하는 능력에 가까워질지도 모르겠다.

[가이드] AI에게 코딩을 맡겼더니 일이 커진다면? CLAUDE.md의 4가지 원칙

zeucise — Fri, 28 Aug 2026 10:32:27 +0900

AI에게 작은 기능 하나를 만들어달라고 했는데 예상보다 일이 커진 적이 있다.

요청하지 않은 기능까지 만들고, 버그 하나를 고쳐달라고 했는데 주변 코드까지 수정한다.

수정을 끝냈다고 해서 확인해보면 제대로 검증하지 않은 경우도 있다.

Claude Code나 다른 AI 코딩 도구를 사용해봤다면 한 번쯤 경험했을 만한 문제다.

최근 이런 문제를 아주 간단한 네 가지 원칙으로 정리한 CLAUDE.md가 화제가 됐다.

1. 흔히 말하는 'Karpathy CLAUDE.md'는 무엇일까?

이 문서는 흔히 Karpathy의 CLAUDE.md라고 불린다.

하지만 정확히 말하면 Andrej Karpathy가 직접 만든 파일은 아니다.

2026년 1월 Karpathy가 AI 코딩 에이전트를 사용하면서 느낀 여러 문제를 공개했고, 개발자 Forrest Chang이 이를 약 65줄짜리 행동 지침으로 정리했다.

내용을 읽어보면 복잡한 프롬프트 기술은 거의 없다.

핵심은 네 가지다.

코딩하기 전에 생각한다.
가장 단순한 방법을 선택한다.
요청받은 부분만 수정한다.
작업이 아니라 성공 조건을 정의한다.

당연한 이야기처럼 보이는데 AI에게 일을 맡겨보면 이 네 가지가 생각보다 중요하다.

2. "CLAUDE.md" 왜 필요한가?

Claude Code에서 CLAUDE.md는 프로젝트에서 Claude가 따라야 할 규칙과 작업 방식을 적어두는 지침 파일이다.

예를 들어 이런 내용을 넣을 수 있다.

어떤 코딩 스타일을 사용할지
어떤 명령으로 테스트할지
어느 범위까지 수정할지
반드시 확인해야 하는 사항은 무엇인지

매번 같은 내용을 프롬프트에 다시 적지 않아도 프로젝트의 기본 규칙으로 사용할 수 있다.

그리고 지침이 길고 복잡하다고 반드시 좋은 것도 아니다.

중요한 것은 AI가 어떤 방식으로 행동해야 하는지 명확하게 알려주는 것이다.

또한, AI의 과잉 행동을 줄여, 토큰을 아낄 수 있다.(돈을 아낌!!!!)

3. 핵심 4가지

① Think Before Coding — 코딩하기 전에 먼저 생각하라

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

AI는 요구사항이 조금 애매해도 알아서 해석하고 작업을 시작하는 경우가 많다.

문제는 그 해석이 틀렸을 때다.

잘못된 가정을 바탕으로 코드를 많이 작성하고 나면 다시 수정해야 할 범위도 커진다.

그래서 첫 번째 원칙은 단순하다.

모호한 것은 추측하지 말고 먼저 확인한다.

프롬프트로 바꾸면 이런 식이다.

요구사항을 임의로 추측하지 말고, 모호하면 질문해. 여러 해석이 가능하면 선택지를 먼저 알려줘.

AI가 마음대로 해석하고 일을 시작하는 것을 막는 것이 핵심이다.

② Simplicity First : 가장 단순한 해결책을 사용해라.

Minimum code that solves the problem. Nothing speculative.

- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.

Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.

AI에게 코드를 맡기다 보면 예상보다 복잡한 결과가 나올 때가 있다.

몇 줄이면 될 기능에 새로운 구조를 만들거나 필요하지 않은 확장성까지 고려한다.

간단한 기능을 부탁했는데 생각보다 훨씬 긴 코드가 나오는 경우를 종종 봤다.

물론 코드를 구조화하면서 읽기 쉬워지는 경우도 있다.

하지만 지금 필요하지 않은 기능까지 미리 만드는 것은 다른 문제다.

그래서 두 번째 원칙은 다음 한 문장으로 정리할 수 있다.

요청한 문제를 해결하는 가장 단순한 방법부터 사용한다.

필요하지 않은 추상화나 미래 기능은 나중에 필요할 때 만들어도 된다.

③ Surgical Changes : 필요한 곳만 수정하라.

Touch only what you must. Clean up only your own mess.

When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it - don't delete it.

When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

The test: Every changed line should trace directly to the user's request.

개인적으로 가장 공감했던 부분이다.

버그 하나를 수정해달라고 했는데 AI가 주변 코드까지 같이 정리해버리는 경우가 있다.

사용하지 않는 코드가 보인다며 삭제하거나, 요청하지 않은 리팩터링까지 하는 경우도 있다.

요즘 말하는 바이브 코딩처럼 AI에게 많은 작업을 맡길수록 이런 변경이 쌓이면 어떤 부분이 왜 바뀌었는지 확인하기도 어려워진다.

그래서 세 번째 원칙은 명확하다.

사용자가 요청한 부분만 수정한다.

주변 코드에서 다른 문제가 보이면 직접 고치기보다 먼저 알려주는 편이 낫다.

수정 범위가 작아지면 검토해야 하는 코드도 줄어들고, 잘못 수정해서 다시 작업하는 경우도 줄일 수 있다.

④ Goal-Driven Execution : 작업보다는 성공조건을 정의해야 한다.

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"

For multi-step tasks, state a brief plan:
```
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]
```

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

AI에게 "버그를 수정해." 라고 말하는 것보다

"버그를 재현하는 테스트를 만들고 → 수정하고 → 테스트가 통과하는지 확인해."

라고 요청하는 것이 훨씬 명확하다.

앞의 요청은 해야 할 작업만 있다.

뒤의 요청에는 언제 작업이 끝났다고 판단할 수 있는지가 들어 있다.

AI에게 단순히 무엇을 할지 알려주는 것보다 어떤 상태가 되면 성공인지 알려주는 것이다.

이런 방식으로 요청해보니 결과를 확인하기가 훨씬 편했다.

4. 실제로는 어떻게 사용할까?

Claude Code에서는 CLAUDE.md라는 파일이 실제로 특별한 역할을 한다.

따라서 Claude Code를 사용할 때는 파일 이름도 중요하다.

반면 ChatGPT, Codex, Cursor 등 다른 AI 코딩 도구를 사용한다면 각 도구가 제공하는 프로젝트 지침이나 규칙 기능에 같은 네 가지 원칙을 적용할 수 있다. 결국 중요한 것은 파일 이름 자체보다 내용이다.

project/
├─ CLAUDE.md
├─ src/
├─ tests/
└─ package.json

5. 결국 AI 코딩도 요구사항의 문제인 것 같다

AI 코딩 에이전트가 발전하면서 중요한 것은 이제 단순히 "AI가 코드를 작성할 수 있는가?" 만은 아닌 것 같다.

어느 범위까지 수정할지, 얼마나 단순하게 만들지, 무엇을 확인해야 하는지, 어떤 결과가 나오면 완료인지 정의하는 것이 점점 더 중요해지고 있다.

65줄짜리 CLAUDE.md가 화제가 된 것도 완전히 새로운 방법을 제시했기 때문이라기보다는 AI와 코딩하면서 반복해서 겪었던 문제를 네 가지 원칙으로 아주 간단하게 정리했기 때문인 것 같다.

그리고 이 이야기는 코딩에만 해당하지 않는다.

결국 AI에게 일을 시킬 때 가장 중요한 것은 내가 무엇을 원하는지 얼마나 정확하게 설명하는가라는 생각이 든다.

이와 비슷한 내용을 연구한 논문도 있다.

다음 글에서는 프롬프트의 핵심을 '기법'이 아니라 요구사항(Requirements)에서 찾은 ROPE 논문을 정리해봤다.

직장인 업무 메모에 Obsidian을 써보면 좋은 3가지 이유

zeucise — Thu, 27 Aug 2026 21:09:51 +0900

회의록, 참고 자료, 기안문, 프로젝트 메모.

업무를 하다 보면 기록은 계속 쌓이는데 정작 필요할 때 찾기 어려운 경우가 많다.

나도 이런 불편 때문에 Obsidian을 사용해보기 시작했다.

아직 모든 기능을 사용하는 단계는 아니지만, 직장인의 업무 메모와 기록 관리라는 관점에서는 세 가지 장점이 특히 눈에 들어왔다.

1. 관련된 업무 기록을 서로 연결할 수 있다.

폴더만으로 메모를 정리하다 보면 하나의 기록을 어디에 넣어야 할지 애매할 때가 있다.

하나의 회의록이 프로젝트와 관련될 수도 있고, 기안문이나 참고 자료와 관련될 수도 있기 때문이다.

어느 폴더에 저장했는지 잊어버리는 경우도 있다.

Obsidian에서는 노트 안에

[[프로젝트 이름]]

처럼 입력해 다른 노트를 연결할 수 있다.

회의록에 프로젝트와 기안문을 연결해두면 회의 기록에서도 관련 자료를 찾아갈 수 있고, 반대로 프로젝트 노트에서도 관련 회의 기록을 확인할 수 있다. 이런 연결 관계를 확인할 수 있다는 것이 Obsidian의 큰 특징이다.

폴더 안에 메모를 넣는 것에서 끝나는 것이 아니라 메모와 메모 사이의 관계를 만들 수 있다.

2. 메모가 쌓일수록 다시 활용하기 쉬워진다.

메모 앱에서 중요한 것은 기록하는 것만이 아니다.

나중에 다시 찾을 수 있어야 한다.

Obsidian에서는 전체 노트를 검색할 수 있고 내부 링크와 백링크를 따라가면서 관련 기록을 확인할 수 있다.

예를 들어 프로젝트 노트에 회의록, 결정 사항, 참고 자료를 연결해두면 몇 달 뒤에도 당시 왜 그런 결정을 했는지 찾아보기 쉬워진다.

단순히 메모를 보관하는 것이 아니라 다음 업무에서 다시 사용할 수 있는 기록으로 바뀌는 셈이다.

메모가 많아질수록 오히려 이 장점이 더 커지는 것 같다.

3. 내 메모를 파일로 직접 보관할 수 있다

Obsidian의 노트는 기본적으로 내 기기의 폴더에 Markdown 파일로 저장된다.

특정 서비스 안에서만 볼 수 있는 형태가 아니라 실제 파일로 가지고 있다는 점이 마음에 들었다.

Obsidian의 저장 공간인 Vault 폴더를 다른 컴퓨터로 옮기고 다시 열 수도 있기 때문에 백업이나 이동도 비교적 단순하다.

물론 로컬에 저장된다고 무조건 안전한 것은 아니다.

특히 회사 업무에 사용할 생각이라면 고객 정보나 기밀 정보를 기록하기 전에 사내 보안 정책을 반드시 확인해야 한다.

현재 다니는 회사에서는 보안 문제 때문에 Obsidian을 직접 사용할 수 없다.

기존 메모를 모두 버리고 새로 시작해야 할까?

나도 이 부분이 고민이었다. 구글 킵에 이미 상당히 많은 자료를 적어놓았기 때문이다.

Obsidian은 Notion, OneNote, Evernote, Apple Notes, Google Keep 등 여러 서비스의 자료를 가져올 수 있는 방법을 제공한다.

그렇다고 처음부터 모든 메모를 옮길 필요는 없을 것 같다.

나도 구글 킵에 있는 자료를 한 번에 옮기지 않고 조금씩 정리하고 있다.

우선 현재 사용하고 있는 메모 몇 개만 가져와 서로 연결해보고 기존 방식보다 편한지 확인하는 중이다.

자료를 옮길 때는 원본을 먼저 백업하고 소량으로 테스트해보는 것이 좋을 것 같다.

다음 글에서는 Obsidian을 직접 설치하고 첫 번째 Vault와 노트를 만드는 과정을 정리해보려고 한다.

마침 이번에 행안부장관님(아내)의 허락을 받아 PC도 바꾸게 됐다.(기분이 매우 좋은 상태다. ㅋㅋ)

복잡한 설정이나 플러그인은 일단 미뤄두고, 처음 사용하는 사람도 따라 할 수 있도록 설치 → Vault 만들기 → 첫 노트 작성하기 정도부터 시작해보려고 한다.

Obsidian(옵시디언)이란? Notion과 다른 점, 그리고 직접 써본 이유

zeucise — Thu, 27 Aug 2026 20:42:36 +0900

기획 업무를 하다 보면 자료가 여기저기 흩어진다.

회의 내용은 회사 메신저에,
떠오른 아이디어는 노트에,
회의 일정은 달력에,
참고할 자료는 브라우저 북마크에 저장한다.

기록할 때는 편하다.

문제는 나중이다.

분명 어딘가에 적어뒀는데 어디에 있는지 기억이 안 난다.

직장인이라면 한 번쯤 겪어봤을 불편일 것 같다.

그래서 찾아보기 시작한 프로그램이 Obsidian(옵시디언)이다.

옵시디언 로고

Obsidian은 어떤 프로그램일까?

Obsidian은 쉽게 말하면 Markdown 파일로 메모를 저장하고, 각각의 메모를 서로 연결할 수 있는 노트 앱이다.

처음 이름을 들었을 때는 상당히 생소했다.

그런데 몇 달 동안 직접 사용해보니 생각보다 거창한 프로그램은 아니었다.

결국은 내가 작성한 메모를 저장하고, 필요할 때 다시 찾기 쉽게 만들어주는 프로그램이다.

다만 일반적인 메모 앱과 조금 다른 점이 있다.

내가 작성한 글이 Markdown(.md) 파일 형태로 내 폴더에 남고, 각각의 메모를 링크로 연결할 수 있다.

Notion과는 뭐가 다를까?

Obsidian을 찾아보면 Notion과 비교하는 이야기가 많이 나온다.

둘은 비슷해 보이지만 사용 방식에는 차이가 있다.

Notion은 문서를 만들고 다른 사람과 공유하거나 협업하는 데 편리한 반면,

Obsidian은 내가 가지고 있는 메모와 지식을 오랫동안 쌓고 서로 연결하는 방식에 더 초점이 맞춰져 있다.

어느 것이 더 좋다기보다는 사용하는 목적이 다른 것 같다.

나는 협업 도구보다는 개인적인 기록을 모으는 용도가 필요했다.

아이도 태어나면서 일기처럼 글을 쓰기 시작했고, 프로그램을 만들다가 정리한 내용도 저장할 곳이 필요했다.

이것저것 기록하다 보니 자료를 한곳에서 관리할 방법이 없을까 찾게 됐고, 그때 Obsidian을 알게 됐다.

물론 회사에서는 보안 정책 때문에 Obsidian을 업무에 직접 사용할 수는 없다.

그래서 우선 개인적인 기록과 공부한 내용을 정리하는 용도로 사용하고 있다.

내가 본 Obsidian의 장점은 딱 두 가지다

아직 나도 Obsidian을 알아가는 중이다.

그래서 플러그인이나 복잡한 기능까지 이야기하기보다는 지금까지 사용하면서 가장 마음에 들었던 것만 꼽으면 두 가지다.

첫 번째는 메모끼리 연결할 수 있다는 것.

하나의 글을 작성하면서 다른 글을 링크하면 이전에 작성한 기록과 자연스럽게 연결된다.

메모가 많아질수록 이 기능이 꽤 유용하다.

두 번째는 Markdown 파일로 저장된다는 것.

특정 서비스 안에만 글이 존재하는 것이 아니라 .md 파일로 남기 때문에 다른 프로그램으로 옮기거나 다시 활용하기 편하다.

나에겐 지금 이 두 가지면 충분하다.

처음부터 Obsidian의 모든 기능을 사용할 생각도 없다.

우선 글을 쓰고, 관련된 기록끼리 연결해보면서 정말 기존의 메모 방식보다 편한지 하나씩 확인해볼 생각이다.

다음에는 직장인의 업무 기록이라는 관점에서 Obsidian을 사용하면 어떤 점이 좋은지도 정리해보려고 한다.