나만을 위한 AI 조언

만든 것과 알려진 것은 다릅니다

 

오늘은 정체성 이야기를 해보려 합니다. 빌더로 쌓아온 것들이 세상에 닿으려면, 쓰는 사람·알리는 사람이라는 역할이 하나 더 필요합니다.

 

● 오늘의 한 줄 — 오늘 하나만 하신다면 — 오늘 겪은 문제든 해결이든 배운 것 하나를 세 문장으로 요약해서 어디에든 적어보세요.

 

Part 1 · 도구 쓰는 법 · 권한과 안전

 

클로드 코드, 오늘은 이것

 

오늘은 클로드 코드의 '권한과 안전' 쪽만 모아봤습니다. 되돌리기 어려운 작업 앞에서 제대로 확인받는 법과, 자동 모드를 안전하게 쓰는 습관 일곱 가지입니다.

 

01 승인 버튼, 열 번째부터는 안 읽고 누르게 됩니다

 

클로드가 뭔가 하려고 할 때마다 '허용하시겠습니까'라고 물어보면, 처음 두세 번은 꼼꼼히 읽지만 열 번쯤 넘어가면 손이 먼저 움직입니다. 마치 회의 중 울리는 알림을 처음엔 확인하다가 나중엔 반사적으로 끄는 것과 같은 심리입니다. 이 피로가 쌓이면 정말 위험한 요청이 섞여 들어와도 똑같이 눌러버릴 수 있습니다. 그래서 되돌릴 게 없는 안전한 작업(파일 읽기, 검색)만 미리 허용 목록에 올려두고, 나머지는 끝까지 묻게 남겨두는 게 낫습니다. 이렇게 하면 버튼을 누르는 횟수 자체가 줄어서, 정말 중요한 순간에 집중력이 남아 있습니다. 허용 목록을 한 번 정리해두면 매번 다시 고민할 필요도 없습니다.

 

자주 쓰는 안전한 명령만 모아서 자동 허용 목록에 넣어줘, 나머지는 계속 물어봐 줘

 

02 거부만 누르지 말고 왜 안 되는지 한 줄 적어주세요

 

클로드가 제안한 작업을 그냥 거부하면, 클로드는 '이 방법이 안 된다'는 것만 알 뿐 '왜' 안 되는지는 모릅니다. 그러면 비슷한 상황에서 또 같은 방식으로 다시 시도할 가능성이 있습니다. 삭제 명령을 거부했다면 '이 폴더는 백업이 없어서 안 돼'라고 한 줄만 덧붙여주면, 다음번엔 백업부터 챙기거나 다른 방법을 찾아옵니다. 부하 직원 서류를 반려만 하고 이유를 안 알려주면, 다음에도 똑같은 서류를 다시 들고 오는 것과 비슷합니다. 이유를 적는 데 긴 문장이 필요하지 않습니다. '이건 되돌리기 어려워서', '이 데이터는 실제 운영 데이터라서' 정도면 충분합니다. 거부와 이유를 같이 주는 습관이 쌓이면, 점점 덜 거부하게 됩니다.

 

이 삭제는 거부할게, 이유는 이 폴더에 백업이 없어서야

 

03 긴 작업 맡기고 자리 비우실 땐 자동 모드를 꺼두세요

 

클로드에게 오래 걸리는 작업을 맡기고 커피 한 잔 하러 자리를 비우는 경우가 있습니다. 이때 자동 승인 모드가 켜져 있으면, 작업 중간에 예상 못한 선택(다른 파일을 지우거나 외부로 메시지를 보내는 일)이 나와도 아무도 막을 사람이 없습니다. 집에 아무도 없을 때 가스불을 켜놓고 외출하는 것과 비슷한 위험입니다 — 평소엔 괜찮지만 그 한 번이 사고로 이어집니다. 짧은 작업은 옆에서 지켜보면서 자동 모드를 써도 괜찮지만, 자리를 비울 만큼 긴 작업이라면 삭제·전송·발행처럼 되돌리기 어려운 명령만큼은 여전히 물어보게 설정을 바꿔두는 게 안전합니다. 작업 범위를 좁은 폴더로 한정해두면 위험이 더 줄어듭니다. 자리를 비울 계획이면 그 전에 꼭 권한 설정을 한 번 점검해보세요.

 

이 작업은 내가 자리를 비울 거니까, 삭제나 외부 전송은 꼭 물어보게 설정해줘

 

04 자동 모드라고 전부 다 자동으로 넘어가는 건 아닙니다

 

초보자들이 흔히 하는 오해 중 하나가 '자동 수락 모드를 켜면 클로드가 뭐든지 알아서 다 한다'는 생각입니다. 실제로는 그렇지 않습니다. 파일을 읽거나 코드를 수정하는 것처럼 비교적 가벼운 작업은 자동으로 넘어가지만, 터미널에서 실행하는 위험한 명령이나 외부로 나가는 요청은 자동 모드에서도 따로 물어보는 경우가 많습니다. 자율주행차가 '자율'이라고 해서 모든 상황에서 운전자 개입 없이 움직이는 게 아니라, 특정 조건에서만 알아서 하고 위험 상황은 여전히 경고를 띄우는 것과 같습니다. 그러니 자동 모드를 켰다고 안심하고 눈을 떼지 말고, 어떤 상황에서 여전히 물어보는지 한 번은 직접 확인해보는 게 좋습니다. 그래야 '이건 당연히 물어볼 줄 알았는데' 하는 뒤늦은 당황을 피할 수 있습니다.

 

자동 모드에서 어떤 종류의 작업은 그래도 나한테 물어보는지 알려줘

 

05 허용 버튼에도 '이번만'과 '앞으로 계속'이 따로 있습니다

 

클로드가 확인을 요청할 때 뜨는 선택지를 자세히 보면, 단순히 허용·거부 두 가지가 아니라 '이번 한 번만 허용'과 '이 종류는 앞으로 계속 허용'이 나뉘어 있는 경우가 많습니다. 급한 마음에 아무 버튼이나 누르면, 한 번만 허용하려던 게 영구 허용으로 바뀌어 있을 수 있습니다. 스마트폰 앱이 위치 정보 접근을 물을 때 '이번만'과 '항상 허용'을 헷갈려서 누르는 것과 똑같은 함정입니다. 지금 하는 작업이 일회성 실험이라면 '이번만'을 고르고, 앞으로도 자주 쓸 안전한 작업이라면 '계속 허용'을 고르는 식으로 구분해서 눌러야 나중에 권한이 어디까지 열려 있는지 헷갈리지 않습니다. 한 번 영구 허용으로 눌러놓은 걸 기억 못 해서 방치하는 경우가 제일 흔한 실수입니다.

 

06 작업이 끝났으면 넓혀둔 권한도 다시 좁혀두세요

 

복잡한 작업을 하다 보면 중간에 권한을 넓게 열어준 채로 끝내버리는 경우가 많습니다. 특정 폴더 전체에 쓰기 권한을 열어줬는데, 작업이 끝난 뒤에도 그 설정을 그대로 두면 다음번 다른 작업에서도 똑같이 넓은 권한이 적용됩니다. 수리 기사를 불러서 현관문을 열어둔 채로 작업을 끝내고 나서, 수리가 끝났는데도 문을 계속 열어두는 것과 비슷합니다. 당장은 아무 일이 없어도 그 열린 문이 나중에 문제를 만들 수 있습니다. 작업이 끝날 때마다 '이번에 넓혀준 권한이 뭐였지'를 한 번 떠올려보고, 더 이상 필요 없다면 원래대로 좁혀두는 습관을 들이면 좋습니다. 특히 중요한 폴더나 반복해서 쓰는 설정 파일일수록 이 점검을 잊지 않는 게 안전합니다.

 

이번 작업에서 넓혀준 권한이 어떤 거였는지 정리해서 알려줘, 다시 좁혀두고 싶어

 

07 연습용 데이터와 실제 데이터는 다른 폴더에 두세요

 

클로드와 함께 뭔가를 시험해볼 때, 연습용 가짜 데이터와 실제로 쓰는 데이터를 같은 폴더에 섞어두면 권한을 어디까지 열어줄지 판단하기 어려워집니다. 연습용 폴더라면 마음 편히 넓은 권한을 줘도 되지만, 실제 운영 자료가 섞여 있으면 매번 조심스럽게 확인해야 하니 작업 속도도 느려집니다. 요리 연습할 때 쓰는 재료와 손님상에 낼 재료를 같은 그릇에 담아두면, 실수로 연습용 재료를 손님상에 올릴 위험이 생기는 것과 같은 이치입니다. 처음부터 '연습 폴더'와 '실제 폴더'를 분리해두면, 연습 폴더 안에서는 자동 모드를 마음껏 켜서 빠르게 시도해보고, 실제 폴더에서는 여전히 꼼꼼하게 확인받는 식으로 나눠 쓸 수 있습니다. 폴더만 나눠도 매번 긴장할 필요가 줄어듭니다.

 

연습용 폴더를 하나 만들어서 거기선 자동 모드로 마음껏 시도해보고 싶어

 

Part 2 · 방향 이야기 · 정체성

 

빌더 다음, 쓰는 사람·알리는 사람

 

만드는 건 이미 익숙한 일입니다. 오늘은 그 옆에 쓰는 사람·알리는 사람이라는 역할 하나를 더 놓아보는 이야기입니다.

 

쌓인 재고는 세상에 없는 것과 같습니다

 

컴퓨터 안에는 이미 완성된 것들이 여러 개 쌓여 있습니다. 창고 정리하듯 폴더를 열어보면, 꽤 괜찮은 결과물인데도 아무에게도 안 보여준 것들이 나옵니다. 이건 냉장고 안쪽에 넣어둔 반찬 같아서, 분명히 있는데 아무도 먹지 않으면 그냥 상해서 버려지는 것과 같습니다. 세상 입장에서는 만들었다는 사실보다 알았다는 사실이 더 중요합니다. 누가 봐야 '이런 게 있구나' 하고 반응이라도 오고, 그 반응이 다음에 뭘 고칠지 알려주는 신호가 됩니다. 반대로 혼자만 아는 결과물은 아무리 잘 만들었어도 세상 기준으로는 존재하지 않는 것과 똑같습니다. 이게 특히 문제가 되는 때는 '나중에 더 다듬어서 공개하자'고 계속 미루는 순간입니다. 다듬는 동안에도 피드백은 하나도 들어오지 않기 때문에, 완성도는 오르는데 세상과의 거리는 전혀 좁혀지지 않습니다. 그래서 빌더라는 정체성에 쓰는 사람이 하나 더 필요한 겁니다 — 만드는 것과 알리는 것은 완전히 다른 두 번째 단계이기 때문입니다. 당장 완벽한 소개글을 쓸 필요는 없습니다. 그냥 '이런 걸 만들어봤다'는 한 문장이면 재고가 세상 밖으로 한 걸음 나옵니다. 오늘 할 일은 거창한 발표가 아니라, 폴더 중에서 가장 오래전에 만들고 가장 오래 묵혀둔 것 하나를 골라 한 줄로라도 어딘가에 적어보는 겁니다.

 

쓰는 목적은 과시가 아니라 기록입니다

 

글을 쓴다고 하면 보통 멋있게 써야 한다는 부담부터 듭니다. 하지만 알리는 사람이 된다는 건 작가가 된다는 뜻이 아니라, 오늘 한 일을 남겨두는 사람이 된다는 뜻에 더 가깝습니다. 예를 들어 업무일지를 쓸 때도 문장이 화려할 필요는 없고, 언제 무슨 일이 있었는지 나중에 찾아볼 수 있으면 그걸로 충분합니다. 쓰는 글도 똑같습니다. 오늘 뭘 만들었고 왜 막혔고 어떻게 풀었는지, 딱 그 정도만 적어도 기록으로서는 완성입니다. 과시하려고 쓰면 완벽해야 한다는 압박 때문에 결국 안 쓰게 되고, 기록하려고 쓰면 못생긴 문장도 그냥 올릴 수 있습니다. 못생겨도 출시가 낫다는 말처럼, 글도 못생겨도 남겨두는 게 다듬느라 영영 안 남기는 것보다 낫습니다. 이 구분이 중요한 이유는, 과시형 글쓰기는 쓸 때마다 '이 정도면 괜찮나'를 남에게 묻는 평가의 영역이라 뇌가 피하려 들지만, 기록형 글쓰기는 혼자 끝낼 수 있는 통제 가능한 영역이라 훨씬 덜 부담스럽기 때문입니다. 나중에 지휘관님이 반년 전 글을 다시 읽으면, 그때 뭘 몰랐고 지금은 뭘 아는지가 보일 겁니다. 그게 과시보다 훨씬 쓸모 있는 기록입니다. 목적을 잘 쓰기에서 남겨두기로 바꾸면 쓰는 사람이 되는 문턱이 눈에 띄게 낮아집니다. 오늘 당장 해볼 수 있는 건, 업무일지 쓰듯 오늘 만든 것에 대해 날짜·무슨 일·어떻게 됐는지만 세 줄로 적어두는 겁니다.

 

알리기의 첫 문장은 배운 것 하나면 됩니다

 

제품을 소개하려면 뭔가 완성돼 있어야 할 것 같지만, 알리는 사람으로 가는 가장 쉬운 입구는 제품이 아니라 배움입니다. 오늘 코드를 고치다가 뭔가 하나 새로 알게 됐다면, 그 자체가 이미 쓸 만한 글감입니다. 오늘 이런 문제가 있었고 이렇게 해결했다는 세 문장짜리 글은 홍보가 아니라서 부담이 거의 없습니다. 민원인에게 뭔가를 설명하듯, 모르는 사람도 알아들을 수 있게 쉽게 풀어 적으면 됩니다. 이런 글은 파는 글이 아니라 돕는 글이라서, 판매·대면 영업을 꺼리는 성향과도 잘 맞습니다. 왜 이게 효과가 있는지 보면, 배움을 적는 글은 상대에게 뭔가를 사라고 요구하지 않기 때문에 읽는 사람도 경계 없이 받아들이고, 쓰는 사람도 거절당할 위험이 없어서 훨씬 자주 쓰게 됩니다. 그리고 이게 쌓이면 자연스럽게 이 사람은 뭔가 계속 만들고 배우는 사람이구나 하는 인상이 생기는데, 이게 바로 알리는 사람의 정체성입니다. 제품을 내세우지 않아도 배움의 기록만으로 그 역할을 할 수 있습니다. 완성품을 자랑하는 글보다 과정에서 배운 것 하나를 적는 글이 훨씬 자주, 훨씬 쉽게 나옵니다. 특히 뭔가 막혔다가 풀린 날, 그 해결 과정을 바로 적어두면 기억이 생생할 때라 글이 훨씬 쉽게 나옵니다. 오늘 겪은 작은 배움 하나를 찾아서 세 문장으로 적어보는 것부터 시작해도 충분합니다.

 

쌓아두기만 한 것은 아직 세상에 없는 것과 같습니다.

 

글쓰기도 연습하면 느는 기술입니다

 

코드 실력이 타고난 재능이 아니라 써본 시간만큼 느는 것처럼, 글쓰기도 똑같습니다. 처음 짠 코드가 어설픈 건 당연하고 그걸 부끄러워하지 않는 것처럼, 처음 쓴 글이 어색한 것도 당연한 과정입니다. 글을 재능 있는 사람만 할 수 있는 일로 여기면 시작조차 안 하게 되지만, 연습하면 느는 기술로 여기면 일단 써보고 고치면 된다는 게 분명해집니다. 코드를 초안으로 짜고 리팩토링하듯, 글도 초안을 쓰고 다음에 다시 읽으면서 다듬으면 됩니다. 처음부터 완성형을 노리지 말고, 일단 돌아가는 버전부터 내놓는다는 개발 습관을 글쓰기에도 그대로 가져오면 됩니다. 매일 쓸 필요도 없습니다. 중요한 건 빈도가 아니라 나는 쓰는 사람이다 라는 자기 인식이 생기는 것이고, 그건 한 번 두 번 써보면서 쌓입니다. 이게 왜 중요한지 보면, 재능으로 여기는 순간 못 쓴 글 한 편이 '역시 나는 아니구나'라는 증거가 되어버리지만, 기술로 여기면 못 쓴 글은 그냥 아직 연습이 부족한 단계일 뿐이라서 다음 글로 넘어가기가 훨씬 쉬워집니다. 빌더로서 이미 갖고 있는 일단 돌려보고 고친다는 감각을 그대로 글쓰기에 옮기면, 알리는 사람이 되는 길이 생각보다 낯설지 않습니다. 코드 리뷰 받듯 글도 누군가에게 보여주고 반응을 받으면 다음 글이 더 쉬워집니다. 처음 몇 편은 아무도 안 봐도 괜찮습니다. 그저 쓰는 근육이 붙는 시간이라고 생각하면 됩니다.

 

알리는 사람은 성과가 아니라 과정의 증인이 됩니다

 

알리는 사람이라고 하면 보통 완성된 성과를 떠벌리는 모습을 떠올리기 쉽습니다. 하지만 실제로 알리는 사람이 하는 일은 그보다 훨씬 수수합니다. 오늘 뭘 시도했고 뭐가 안 됐고 왜 안 됐는지, 그 과정을 그냥 지켜본 사람으로서 적어두는 역할에 더 가깝습니다. 현장 기록을 남기듯, 성공 여부와 상관없이 무슨 일이 있었는지 남기는 게 먼저입니다. 이렇게 생각하면 아직 자랑할 성과가 없다는 이유로 알리기를 미룰 필요가 없어집니다. 성과가 나기 전부터도 과정을 기록할 수 있고, 오히려 그 과정 기록이 나중에 성과보다 더 많은 공감을 받는 경우도 흔합니다. 지휘관님이 자산 하나를 길게 복리로 굴리기로 한 것도, 매주 완성된 성과를 내려는 게 아니라 과정을 꾸준히 보여주는 게 핵심이었습니다. 증인이라는 역할은 평가받는 부담이 성과를 자랑하는 것보다 훨씬 가볍습니다. 이번 주엔 이런 걸 시도했다 정도의 문장이면 증인 역할로 충분합니다. 알리는 사람이 된다는 건 매번 성공을 보고하는 게 아니라, 꾸준히 과정을 지켜보고 전하는 사람이 되는 것입니다.

 

내가 친 울타리를 한번 의심해보세요

 

나는 만드는 사람이지 쓰는 사람은 아니다 라는 생각은 사실이 아니라 스스로 쳐놓은 울타리일 수 있습니다. 어릴 때 나는 수학을 못해 라고 믿으면 정말 수학 문제를 안 풀게 되고, 안 풀다 보니 더 못하게 되는 것과 같은 구조입니다. 빌더라는 정체성은 지금까지 해온 일을 설명하는 데는 유용하지만, 앞으로 할 수 있는 일을 가두는 울타리가 되면 손해입니다. 정체성은 원래 하나로 고정된 게 아니라, 상황에 따라 여러 역할을 겹쳐 쓸 수 있는 옷장에 가깝습니다. 공무원이면서 동시에 필명 작가일 수 있고, 만드는 사람이면서 동시에 기록하는 사람일 수 있습니다. 이 두 역할이 서로 충돌하지 않는다는 걸 이미 익명 활동으로 증명하고 있습니다. 이 울타리가 특히 잘 작동하는 순간은 바쁘거나 피곤할 때입니다. 그럴 때는 '나는 원래 그런 사람이 아니야'라는 말이 아주 편한 핑계가 되어주기 때문입니다. 하지만 핑계가 편하다는 것과 그게 사실이라는 것은 다른 이야기입니다. 울타리를 치는 건 대개 능력 부족이 아니라, 안 해본 일에 대한 막연한 거부감입니다. 그 거부감은 한 번 해보면 거의 항상 생각보다 별거 아니라는 걸 알게 됩니다. 오늘은 나는 그런 거 못 해 라는 문장을 한 번 의심해보는 것만으로도 충분한 시작입니다.