✍️
스터디 후기
AI 스터디 4주차 후기
4주간 진행하면서 AI 로 만든 프로젝트를 다른 분들과 함께 나누면서 좋은 자극을 많이 받았습니다. 더 배 우고 싶은 마음이 많이 들었고, 앞으로 더 잘 활용해보고 싶다는 생각을 하게 되었습니다. 좋은 자리 만들어주셔서 감사합니다. 108 days ago4주차 후기 — 발표 마무리 및 프로젝트 최종 회고록
발표를 마치고 발표가 끝났다. 막상 발표가 가까워져 여태까지 기록한 문서들을 정리해보니, 깨달은 것도 많았고 얻은 것도 많았다. 정리를 다 마치고 보니 방향 전환의 이유, 막힌 이유, 인사이트, 그리고 실제로 작동하는 스킬 4개가 다 거기 있었다. 이렇게 정리한 내용을 기준으로 회고를 작성하려고 한다. 4주를 한 문장으로 > "딸깍 자동화"를 꿈꾸다가, 가드레일 설계자가 된 4주. 처음엔 사용자가 말만 하면 AI가 알아서 노션에 다 정리해주는 그림을 그렸다. 끝에 와서 손에 남은 건, AI가 엉뚱한 짓을 못 하게 막는 실행 전용 스킬 문서 4개였다. 이게 후퇴처럼 보일 수도 있다. 그런데 실제로 해보니 이쪽이 훨씬 현실적이고, 훨씬 많이 배운 길이었다. 무엇을 만들었나 최종적으로 노션 AI 스킬 4개를 완성했다. 스킬 사용자 핵심 제목 프리픽스 생성 스킬 V4 전 팀원 26개 프리픽스 중 자동 추천, [프리픽스] 제목 출력 간단한 개요서 작성 스킬 V2 전 팀원 3분 이하, 질문 5개, 채택률 우선 개요서 생성 스킬 V2 전 팀원 ~10분, 9단계, Mermaid 플로우차트 + MVP 제안 분류를 위한 인터뷰 스킬 전 팀원 PARA 기준 분류 + 노션 등록 권장 전부 같은 패턴을 공유한다. 맨 앞에 ⚠️ 실행 전용 가드, 즉시 첫 질문, 한 번에 하나씩 인터뷰, 제안 → 승인 → 출력. 직접 생성·수정은 안 하고 텍스트로 권장만 한다. (노션 AI 권한 제약 안에서의 최대치) 무엇을 배웠나 1. AI 자동화 = "무엇을 못하게 막을까" 이번 4주 전체를 관통하는 한 줄이라고 생각한다. 처음엔 클로드에 노션 API를 붙이는 걸 생각했다. 외부 AI가 노션을 직접 제어하는 구조다. 그런데 권한이며 안전성이며 걸리는 게 많아서 과감히 버렸다. (이 얘기는 뒤에서 더 한다.) 버리고 나서 다시 처음으로 돌아가 생각했다. 기준은 두 가지였다. 1. 팀원분들이 별도 세팅 없이 바로 접할 수 있는 AI 툴일 것. 2. 결과물을 만들면, 팀원분들이 똑같은 환경에서 그대로 쓸 수 있을 것. 이 두 조건을 만족하는 게 뭘까 고민하다 보니, 답은 가까이 있었다. 노션에 이미 붙어 있는 노션 AI였다. 따로 설치할 것도, 권한을 새로 받을 것도 없었다. 문제는 여기서 시작됐다. 내가 만든 스킬 페이지를 노션 AI한테 먹이면, 그걸 "실행"하는 게 아니라 "설명"하기 시작했다. "이 문서는 이런 목적입니다", "원하시는 작업을 골라주세요" 하는 식으로. 그때부터 방향이 바뀌었다. 처음엔 AI한테 "이것도 해줘, 저것도 해줘"를 추가하는 게 자동화라고 생각했다. 실제로는 정반대였다. 원하는 동작을 시키는 것보다, 원하지 않는 동작을 막는 데 훨씬 더 많은 시간이 들었다. 설명 모드 금지, 선택지 제시 금지, JSON 질문 금지, 인터뷰 전 생성 금지, 승인 전 수정 금지. 스킬 하나를 완성하는 공수의 대부분이 기능이 아니라 가드레일에 몰렸다. 제목 프리픽스 스킬 하나만 해도 초안부터 V4까지 네 번을 갔다 왔다. 매번 새 기능이 아니라 예외 케이스를 막는 작업이었다. AI를 다루는 일은 기능 구현보다 행동 제약 설계에 훨씬 가깝다. 2. 채택률 > 완성도 아무리 정교한 스킬도 안 쓰면 의미가 없다. "이럴 거면 차라리 내가 만들지"가 나오는 순간 그 스킬은 실패다. 그래서 팀원용 개요서 스킬은 무조건 3분 이하, 질문 5개 이하로 묶었다. 기능의 우수함이 아니라 마찰력(friction)이 스킬 설계의 핵심 기준이라는 걸 배웠다. 3. "AI가 똑똑하다"와 "운영적으로 안전하다"는 다른 문제다 앞에서 클로드에 노션 API를 붙이는 구조를 과감히 버렸다고 했다. 그 진짜 이유가 이거다. 추론 모델은 자기 판단을 한다. "DB 최적화해줘" 한마디에 "다 밀고 새로 만드는 게 빠르겠네"라고 판단하면 실제로 그렇게 실행할 수도 있다. 거기에 선의로 받은 노션 마스터 권한까지 얹혀 있었다. 잘못 휘두르면 되돌리기 어려운 구조였다. 그래서 실제로도 노션에서 딱 한 번만 테스트해보고 말았다. AI가 똑똑한 것과, 그 AI에게 실행 권한을 쥐여주는 것은 전혀 다른 문제다. 자동화의 편리함과 실행 권한의 위험은 항상 같이 따라온다. 결국 노션 AI로 방향을 정한 건 기능이 좋아서가 아니라, 권한 범위 안에서 안전했기 때문이다. 팀원이 바로 쓸 수 있다는 조건과, 내가 통제할 수 있다는 조건이 거기서 만났다. 아쉬운 것 솔직하게 두 가지. 1. 시간을 더 많이 쓰지 못했다. 세션마다 쪼개서 했는데, 설계와 테스트에 더 붙어 있고 싶었다. 2. 목표를 너무 크게 잡았다. "딸깍 자동화"는 애초에 4주짜리 사이드 프로젝트의 범위가 아니었다. 이걸 더 일찍 인정했다면 방향 전환도 더 빨랐을 거다. 설명 모드 진입 문제도 끝까지 100% 막지 못했다. 가드를 강화할수록 빈도는 줄었지만 0이 되진 않았다. 노션 AI의 동작 특성으로 받아들이고 잔존 리스크로 처리했다. 앞으로 아직은 개인 실험 단계다. 이제 다음 단계로 넘어간다. 팀원들에게 스킬을 실제로 공개한다. 어떤 스킬이 실제로 쓰이는지, 어디서 막히는지 사용자 경험을 수집한다. 유용한 스킬은 무엇인지, 기존 스킬에서 무엇을 개선해야 하는지 꾸준히 이어간다. 스킬은 완성된 게 아니라 시작점이다. 실제로 팀원이 쓰기 시작하는 순간부터 진짜 피드백이 나올 거다. 마무리 4주 동안 기록을 남겨두길 정말 잘했다. 각 주차에 무엇을 시도하고, 왜 막혔고, 어떻게 방향을 틀었는지가 다 남아 있었다. 발표 준비를 하면서 그 기록들을 다시 읽었을 때 비로소 깨달았다. "아, 내가 생각보다 꽤 많이 배웠구나." 처음 3주는 "결과물을 못 만들었다"는 느낌으로 보냈다. 지금은 학습 과정 자체가 이미 얻은 것이라고 생각한다. 그리고 여기서부터는 실전이다. 스킬을 배포하고, 피드백을 받고, 다시 수정하고 — 언젠가 팀원분들이 이 스킬을 원활하게 쓰면서 노션과 더 친해졌으면 좋겠다. 자동화에 실패한 이야기가 아니라, 자동화를 시도하며 진짜 문제를 발견한 이야기. 그게 이번 4주였다. 108 days agoAI 스터디 4주차 후기
4주동안 진행하며, AI를 다양하게 활용하시는 과정을 봤습니다. 아이디어가 중요해지는 사회에서 보는 시야가 넓어질 수 있는 기회가 되어 좋았습니다. 고생하셨습니다:) 108 days agoAI 스터디 4주차 후기
다른 분들이 만드신 결과물에 비하면 사소하지만, 하나의 완성된 결과물을 만들었다는 점에서 뿌듯했습니다. 나름대로 이 에이전트를 만든 이유에 대해 확신을 가지고 있는 만큼, 앞으로 유용하게 사용할 수 있을 것 같습니다. 다른 분들의 결과물, 그리고 기획 의도, 작업 과정을 들으며 시야가 굉장히 넓어진 느낌입니다 108 days agoAI 스터디 3주차 후기
1, 2주차까지는 방향성을 잡는 시간이었다면, 이번 주차는 본격적인 결과물 테스트 및 수정의 시간이었습니다. 테스트 과정에서 UX 직관화, 결과 레포트의 효율화, 예외 처리의 추가, 확장성 고려 등을 고려하여 계속 수정해나갔습니다. 무엇보다도 테스트 한 번에 API 토큰 1.7$가 소모되는 것을 보고, 효율적인 토큰 사용을 고려하여 프로세스를 개선하게 된 점이 가장 주요했던 것 같습니다. 1016 days agoAI 스터디 3주차 후기
AI는 잘못이 없다. 꿈은 컸지만 꿈을 만들기 위해서는 구체적인 계획과 필요한 데이터 수집이 선행되었어야 할 것으로 생각된다. 이번 프로젝트는 다음 프로젝트를 위한 초석으로 삼아야겠다. 1016 days agoAI 스터디 3주차 후기
3주차 들어오면서 프로젝트 방향 자체가 꽤 많이 바뀌었다. 처음에는 솔직히 “AI가 알아서 다 해주는 구조”를 만드는 쪽에 더 가까웠다. AI가 업무 인터뷰를 진행하고, PARA 기준으로 분류하고, 적절한 DB를 찾고, 프로젝트와 Task를 생성하고, 노션 relation까지 연결하고, 필요한 문서를 자동으로 만들어주는 흐름. 거의 “딸깍 자동화” 같은 그림을 생각하고 있었다. 근데 실제로 노션 AI를 붙여서 계속 테스트해보니까 생각보다 문제가 굉장히 많이 나왔다. 인터뷰 없이 바로 문서 생성, 노션 운영 흐름 무시, 노트 DB 대신 새 페이지 생성, 너무 빨리 “정리해줄게” 모드 진입, JSON 기반 질문 출력, 설문조사처럼 행동, “1번~4번 중 골라주세요” 같은 UX 흐름, 설명형 챗봇처럼 움직이는 문제 같은 것들이 계속 발생했다. 특히 느꼈던 건 AI가 업무를 이해하려고 하기보다 “문서를 빨리 생성하는 것”에 더 집중한다는 점이었다. 나는 “현재 운영 구조 안에서 어떻게 움직여야 하는가”를 중요하게 생각하고 있었는데, AI는 계속 결과물을 빨리 만들어주는 쪽으로 움직이려고 했다. 그래서 3주차 들어와서는 방향 자체를 다시 잡기 시작했다. 핵심은 “완전 자동화”보다 “노션을 더 잘 활용하게 만드는 구조” 쪽으로 이동한 거였다. 여기서부터는 외부 AI가 노션을 강하게 제어하는 구조보다, 노션 안에서 현재 페이지와 연결 문서, 권한 범위 안의 컨텍스트를 활용해서 업무를 보조하는 방향이 훨씬 현실적으로 느껴졌다. 그래서 실제로 “노션 스킬 모음” 구조를 만들기 시작했다. AREA 안에 스킬 영역을 따로 만들고, 지식_인터뷰.md, 개요서_생성_스킬.md, PARA_분류_아키텍처.md, 워크플로우_오케스트레이터.md, 회의록.md, 회고.md, QA정리.md 같은 문서들을 계속 축적하기 시작했다. 그리고 여기서 중요했던 건, 이걸 단순 프롬프트 저장소처럼 쓰는 게 아니라 “실행 문서”처럼 동작하게 만드는 것이었다. 예를 들면 회의를 했다면 @회의록.md, 업무 회고를 하고 싶다면 @회고.md, 개요서를 만들고 싶다면 @개요서_생성_스킬.md 같은 식으로 필요한 순간에 필요한 스킬 문서를 노션 AI 컨텍스트에 붙여서 사용하는 방향이다. 근데 여기서 또 새로운 문제가 나왔다. AI가 문서를 “실행 규칙”으로 읽는 게 아니라 계속 “설명 문서”처럼 읽기 시작한 거다. “이 문서는 이런 목적입니다”, “원하시는 작업이 무엇인가요?”, “1번~4번 중 선택해주세요” 같은 식으로 움직였다. 즉 내가 원한 건 “실행형 인터뷰 프로토콜”에 가까웠는데, 실제로는 “UX 가이드형 챗봇”처럼 움직여버린 것이다. 그래서 이 시점부터는 기능 추가보다 “가드레일 추가” 비중이 훨씬 커졌다. 설명 모드 금지, 옵션 제안 금지, 번호 선택 UX 금지, JSON 질문 금지, 인터뷰 전 구조화 금지, 충분한 정보 전 결과물 생성 금지, “정리해줄게” 모드 금지 같은 것들을 계속 추가하기 시작했다. 3주차 들어와서 가장 많이 고민한 건 결국 “무엇을 하게 만들까?”보다 “무엇을 못하게 막을까?”에 가까웠던 것 같다. 그리고 여기서 느낀 건, AI 자동화는 단순 기능 구현 문제가 아니라 거의 “행동 제약 설계”에 가까운 영역이라는 점이었다. 이번 주에는 실제로 “개요서 생성 스킬” 인터뷰 테스트도 진행했다. 핵심 목표는 개요서를 바로 생성하는 것이 아니라, 개요서를 만들기 위한 맥락을 인터뷰 방식으로 수집하는 것이었다. 실제로 노션 AI와 테스트를 해보니까 생각보다 인터뷰 흐름 자체는 꽤 자연스럽게 동작했다. 누가 보는 문서인지, 어떤 결과물이 필요한지, 어떤 DB에 저장되는지, Task DB 구조가 어떻게 되는지, 우선순위와 상태는 어떻게 시작하는지, 일정은 어떤 기준으로 보는지 같은 걸 계속 질문하면서 운영 구조까지 같이 수집하는 흐름이 만들어졌다. 특히 여기서 재미있었던 건 단순히 “문서를 작성한다” 수준이 아니라 “현재 팀 운영 체계를 어떻게 쓰고 있는가”까지 인터뷰가 들어가기 시작했다는 점이었다. 예를 들면 기획서는 어디에 생성되는가, 어떤 속성값이 기본인가, 명료화 기본값은 무엇인가, 작업자는 자동 지정인가 직접 지정인가 같은 운영 규칙들까지 같이 정리되기 시작했다. 그래서 여기서부터는 “수집한 정보를 실제 생성 흐름으로 어떻게 연결할 것인가”를 고민하기 시작했다. 그 과정에서 만든 게 “분류를 위한 인터뷰 및 생성기” 구조였다. 핵심은 단순 생성기가 아니라 이 업무가 Task인지, 프로젝트인지, 노트인지 먼저 판단하고 현재 PARA 구조 안에서 어디로 연결해야 하는지를 결정하게 만드는 방향이었다. 즉 생성 전에 먼저 @영역, @자원, @프로젝트, @노트 같은 것들을 읽게 하고, 현재 운영 체계가 어떤 프리픽스를 쓰는지, 어떤 제목 규칙을 쓰는지, 프로젝트를 어떻게 만드는지, 노트를 어디에 저장하는지 같은 걸 먼저 파악하게 만드는 방향으로 바뀌기 시작했다. 그리고 생성 흐름도 “바로 생성”이 아니라 “제안 → 승인 → 생성” 구조로 다시 설계하기 시작했다. 예를 들면 “현재 기준으로는 프로젝트 생성 + 관련 Task 생성 흐름이 적절해 보인다”처럼 먼저 제안하고, 유저 승인 이후 실제 생성 흐름으로 들어가게 만드는 방식이다. 그리고 이 시점부터는 “설명형 AI”를 계속 막기 시작했다. 왜냐면 실제 테스트를 해보면 AI가 너무 쉽게 “이 문서는 ~입니다”, “원하는 작업을 골라주세요”, “1번~4번 중 선택해주세요” 같은 방향으로 빠졌기 때문이다. 근데 내가 원했던 건 대화형 인터뷰 프로토콜에 가까웠다. 즉 설명하는 AI가 아니라, 업무를 이해하기 위해 계속 질문을 이어가는 구조를 원했던 것이다. 그래서 설명 금지, 선택지 금지, JSON 금지, 인터뷰 즉시 시작 같은 규칙들을 계속 추가하게 됐다. 그리고 후반부에는 실제로 더미 데이터 기반 테스트까지 진행했다. 가정은 “개요서가 없는 상태에서, 추상적인 업무 메모만 존재하는 상황”이었다. 예를 들면 “업무 일지 작성해야 됨”, “내일 컨펌 받아야 함” 정도만 적혀 있는 메모를 던져놓고, AI가 얼마나 자연스럽게 인터뷰 → 분류 → 생성 흐름으로 들어가는지 테스트한 것이다. 생각보다 일정 수집이나 작업자 지정 같은 흐름은 꽤 자연스럽게 동작했다. 문제는 그 다음이었다. 원래 의도는 인터뷰 → draft 상태 유지 → 승인 → 실제 수정 흐름이었는데, 실제로는 질문 → 값 수집 → 바로 수정으로 움직여버렸다. 즉 인터뷰 단계인데도 AI가 실제 수정 권한 상태로 들어가버린 것이다. 예를 들면 “상태를 진행 중으로 바꿔뒀어요”, “작업자를 반영했어요”처럼 바로 실행해버리는 문제가 발생했다. 그래서 여기서부터는 “인터뷰 설계”보다 “실행 권한 제어”가 훨씬 중요하다고 느끼기 시작했다. 단순히 생성 금지, 수정 금지, 저장 금지 정도로는 부족했고, 이제는 draft_state, execution_state, 승인 전 실행 금지, 최종 승인 전 수정 금지, “반영했어요” 표현 금지 같은 상태 머신 개념 자체를 프롬프트 안에 넣기 시작했다. 결국 3주차 들어오면서 가장 크게 바뀐 건 이것 같다. 처음에는 “AI가 알아서 노션을 자동화해주면 좋겠다”였다면, 지금은 “노션 AI를 활용해서 업무 인터뷰와 구조화를 더 잘하게 만들자” 쪽으로 방향이 바뀌고 있다. 그리고 지금 단계에서는 오히려 이 방향이 훨씬 현실적이라는 느낌이 들고 있다. 1016 days agoAI 스터디 3주차 후기
'딸깍' 은 결과물이고, 그 전에 매우 많은 시행착오가 동반된다는 걸 느꼈습니다. 토큰 제한에 걸렸습니다. 토큰이 녹는다는 걸 체감했습니다. 당연한 거지만, 효율적으로 토큰을 쓰려면 어떻게 해야 할까, 에 대한 고민도 함께 하게 되었습니다. 혼자 하는 것 보다, 동기부여가 잘 되는 것 같습니다. 1016 days agoAI 스터디 3주차 후기
벌써 3주차입니다 다음 주 결과물을 내야 하는 상황인데, 현재 게임 내 로직은 거의 완성을 못한 상황이라 작업이 마무리가 될지 예상이 가지 않습니다. AI로 맵을 생성하고 플레이어가 게임 씬에 진입하는 것까지는 완료가 되었고 게임 내 로직이 거의 완성이 안된 상황이라 폴리싱 작업은 시간 상 어려울 것 같고 유니티 기본 오브젝트로 간단히 기능이 구현되는 정도록 게임 내 로직은 마무리할 것입니다 그래도 AI로 맵을 생성하는 부분은 마무리가 되어 이번 AI 스터디에서 완성할 부분까지는 완성이 된 것 같습니다. 1016 days agoAI 스터디 3주차 후기
혼자서 힘들었던 프로젝트... 모여서 같이하니 힘이 납니다. 개인이 하고싶었지만 따로 시간을 뺴기 어려웠던 분들에게 적극 추천합니다 다들 열심히하고 몰입하는 모습을 보고 있으면, 저도 열심히 해야겠다는 생각이 저절로 생기네요 다들 잘하셔서 걱정이 없습니다~ 1016 days agoAI스터디 3주차 후기
AI 스터디 3주차 후기 ✍️ 이번 스터디는 각자 만들고 싶은 걸 직접 만드는 방식으로 진행 중인데, 이제 슬슬 결과물이 하나씩 나오기 시작했습니다. 처음엔 아이디어만 이야기하던 단계였는데 지금은 실제로 돌아가는 화면이나 기능들이 보이니까 분위기가 많이 달라졌습니다. 게임 만드는 사람, 자동화 툴 만드는 사람, AI 연결해서 이것저것 실험하는 사람까지 방향도 다양합니다. “공부를 위한 공부”가 아니라 자기 프로젝트를 밀어붙이면서 배우는 느낌이라는 점. 앞으로 더 어떤 것들이 나올지 기대됩니다.🚀 0016 days agoAI 스터디 2주차 후기
애초의 기대만큼 진전이 빠르게 되지는 않는 것 같다. 프로젝트의 범위를 좁혀서, 조금 더 작지만 구체적인 목표를 달성할 수 있게 해야 할 것 같다. 박슬기 선생님이랑, 주변에 함께 해주시는 분들께서 도와주셔서 그래도 꾸준히 해나갈 수 있을 것 같다는 생각이 든다. 구체적인 결과물을 만들어 나갈 수 있게 해보자. 1016 days agoAI 스터디 2주차 후기
수집한 데이터를 바탕으로 통계 결과를 냈을 때, 실제 결과와 차이가 많이 발생했다. 원인은 정량적인 데이터 (출석률,과제 제출률 등) 만으로는 학생을 파악하기 힘들고, 회고나 지원동기 또한 AI로 작성한 데이터를 높이 평가해버리는 오류가 있었다. 다른 평가 기준과 수집할 데이터의 기준이 필요할 것으로 보인다. 2019 days agoAI 스터디 2주차 후기
1️⃣ 현재 작업 상황 1일차 시작할 때 유니티에 네트워크(Netcode)와 AI api 키를 저장할 서버인 Firebase를 세팅하였고 기본적인 초기화와 네트워크 환경에서 동기화 간단히 테스트 진행했습니다. 이후 맵 설계를 진행했는데 목표는 Claude/GPT 같은 AI가 2D 맵 설계 데이터를 생성하고, Unity가 그 데이터를 검증한 뒤 실제 맵으로 생성하는 흐름으로 구성하려고 합니다 일단 AI 응답과 로컬 랜덤 생성기가 공통으로 사용할 맵 데이터 구조를 설계를 진행했고 AI가 이상한 답변을 하더라도 맵 데이터 틀에 맞게 설계가 되어야 해서 맵 검증기까지 제작해야 했습니다. 현재 AI 프롬포트가 아닌 임시 프롬포트 테스트 코드를 만들어 맵 검증기가 돌아가는지 테스트를 진행하여 정상 작동되는 것을 확인 했습니다 다음 주까지 진행해야 하는 부분은 예외처리 부분입니다. 물론 AI의 프롬포트가 실패하는 경우 기본맵이 나오도록 했지만 최대한 AI에 프롬포트를 넣었을 때 실패하지 않도록 코드를 구성하는 것을 목표로 하고 있습니다 플레이어가 AI 프롬포트를 어떻게 넣는지에 따라 상당히 많이 상황에 대비가 필요한데 모든 상황을 다 처리하면 끝이 없기 때문에 이 부분을 어떻게 우회하면서 구현할지가 가장 큰 도전과제입니다. 2️⃣ 스터디 후기 스터디의 경우 자유롭게 프로젝트를 진행하는 식으로 진행이 되고 있습니다. 가장 스터디원 분들께서 AI를 통해 어떤 결과물을 만들고 어떤 기술을 사용하고 있는지 확인하면서 좀 더 찾아보는 시간이 많았던 것 같습니다. 정말 놀라운 건 벌써 스터디의 절반 진행했다는 겁니다. 시간이 상당히 빨라서 작업을 좀 서둘러야 할 것 같습니다. 1021 days ago[AI-스터디] 2주차 후기
"여백의 미학" 이라는 말을 좋아한다. 의도적으로 생략과 비움을 통해, 오히려 더 깊은 울림과 상상력을 만들어내는 동양 예술과 철학의 개념이다. 이번 AI 스터디 2주차를 진행하면서, 문득 아이디어와 AI의 관계도와 비슷하다고 생각이 들었다. AI는 정말 빠르다. 정리도 잘하고, 코드도 만들고, 문장도 작성한다. 하지만 결국 내가 머리속에 그리고 있는 '생각 자체'를 완전히 대신해주지는 못한다. 중요한 건 AI를 얼마나 잘 다루느냐 보다, 내가 무엇을 만들고 싶은지 스스로 얼마나 명확하게 이해하고 있느냐였다. 물론 그렇다고 해서 대충 작업하자는 이야기는 아니다. 오히려 반대다. 내가 가진 생각과 아이디어 기반으로, 현실적인 구현 가능성과 적절하게 타협하는 능력이 중요하다는 걸 많이 느꼇다. 머릿속에는 늘 '자비스' 같은 완벽한 시스템을 만들고 싶다. 하지만 현실은 일정, 리로스, 기술적 한계, 우선순위 같은 여러 조건이 존재한다. 그래서 어느 시점에서는"지금 가장 필요한 게 무엇인가?" 를 판단하고, 적당한 단계에서 타협해야 한다. 아마 사람들이 흔히 말하는 MVP(Minimum Viable Product)도 결국 그런 개념인 것 같다. 완벽함보다, 먼저 동작하고 검증 가능한 형태를 만드는 것, 반대로 어려운 순간도 있었다. 내 머리속에는 이미 완성된 결과물이 있는데, 정작 그 결과물이 만들어지는 과정과 흐름은 생략된 상태인 경우다. 그러다 보니 AI에게 결과만 던지고 요청하면, 내가 기대했던 방향과 전현 다른 결과물이 나올 떄가 많았다. 곰곰히 생각해보니 문제는 AI보다도, 내 생각을 구조화하지 못한 내 쪽에 가까웠다. 결국 AI와의 협업은 단순히 명령을 입력하는 것이 아니라, 내 머릿속의 추상적인 생각을 언어와 구조로 정리하는 과정에 가까웠다. 그리고 그 과정속에서, 불필요한 요소는 덜어내고, 정말 중요한 핵심만 남기는 능력이 필요했다. 어쩌면 이것도 하나의 "여백의 미학" 아닐까 싶다. 비워내야 핵심이 보이고, 생략해야 방향이 선명해진다. 이번 2주차 스터디는 단순히 AI를 배우는 시간이 아니라, '생각을 정리하는 방법'을 배우는 시간에 더 가까웠던 것 같다. 1021 days ago[AI-LABS 스 터디] 2주차 참여 후기
프로젝트의 범위를 너무 넓게 잡았다는 것을 실감 '판단'의 영역은 AI에게 맡기기 위험한데, 그 부분이 포함된 프로세스를 기획했다는 것을 깨달음 '데이터 수집' & '데이터 가공'의 영역까지만 agent에게 맡기는 것으로 결정 이에 따라, 우선적으로 크롤링 및 요약까지만 agent에게 맡길 예정 여기서 나온 데이터를 기준으로 '판단'하는 것은 사용자의 역할이 될 것이고, 그 '판단'에 대한 공격을 하는 agent를 추가로 만들 계획 1021 days ago[현장 사진] AI 기초 사내 특강 3회차 현장 후기 — NotebookLM, 그리고 마무리
5/8 금요일 18:30, 예경빌딩 10층 라운지에서 특강 1기 마지막 3회차를 진행했습니다. 1회차 5명으로 시작했던 자리가 마지막 회차엔 10명 가까이 모여, 같은 라운지가 꽤 빼곡했습니다. 직전 회차 참여자분들이 동료나 학생들을 같이 데려오신 케이스도 있어서 분위기가 한 결 더 풀려 있었습니다. 3회차 (5/8 금) — NotebookLM으로 내 자료 안에서만 답하는 노트북 만들기 3회차는 "본인이 가진 자료를 노트북에 한 번 올려두면 그 안에서만 답이 나오는 작업 환경을 한 자리에서 직접 만들어보는 것"을 목표로 진행했습니다. 다룬 내용 NotebookLM이 일반 채팅·Gems와 결정적으로 다른 지점 — 업로드한 소스 안에서만 인용하며 답한다는 구조 소스 유형별 처리 — PDF·웹페이지·구글 문서·유튜브 자막·붙여넣기 텍스트 채팅 맞춤설정 — 1·2회차에서 다진 프롬프트 4요소 / Gems 시스템 프롬프트 패턴을 그대로 이식 마인드맵·오디오 개요·동영상 개요·스터디 가이드·브리핑 문서 등 보조 출력 도구 공유 권한 — 본인만 볼 노트북과 팀 공유 노트북의 권한 분기 (뷰어·편집자) 가장 의미 있었던 부분은 마지막 30분이었습니다. 참여하신 분들이 각자 노트북 한 개씩을 끝까지 만들어 가져가셨습니다. 결은 두 갈래로 나뉘었는데요. 팀에서 바로 쓸 노트북 — 본인 팀 매뉴얼·표준 문서·반복 질의에 답해주는 작업용 노트북 본인 지식 함양용 노트북 — 평소 관심 분야의 자료(PDF·아티클·영상)를 한 군데 모아 두고 학습 어시스턴트로 쓰는 노트북 1·2회차에서 만든 Gem이 "내 업무 스타일을 학습한 어시스턴트"였다면, 3회차의 노트북은 "내 자료 안에서만 답하는 어시스턴트"입니다. 두 도구를 합치면 한 명이 본인 업무 흐름 안에 어시스턴트 두 종을 동시에 갖춘 셈이라, 마지막 회차로 자리가 자연스럽게 마무리 되었습니다. 특강 1기 전체 마무리 세 번의 자리를 거치면서 회차별로 한 가지씩 손에 잡히는 결과물이 쌓였습니다. - 1회차 (5/4 월) — LLM 이해 · 프롬프팅 기본기: 본인 업무 프롬프트 한 줄 - 2회차 (5/6 수) — Gems: 본인 업무에 쓸 시스템 프롬프트 기반 어시스턴트 한 종 - 3회차 (5/8 금) — NotebookLM: 본인 자료 안에서만 답하는 노트북 한 개 1회차 5명으로 시작해서 마지막 회차 10명 가까이까지 인원이 늘었던 흐름이 인상 깊었습니다. 직장에서 AI를 한 번 써본 분도, 처음 접해보신 분도 같은 자리에서 본인 결과물을 들고 돌아가신 게 1기의 가장 큰 수확이었습니다. 다음 기수 안내 특강 1기는 사내 직원 대상 무료 특강 3회차 구성으로 마무리됐습니다. 2기는 1기에서 받은 피드백을 반영해 일정·주제·실습 비중을 재구성한 뒤 별도 공지 드릴 예정입니다. 📅 2기 일정·신청 — 추후 별도 공지 문의: 박슬기 매니저 1기 자리에 함께해주신 분들, 그리고 동료를 데려와주신 분들 모두 감사드립니다. 만드신 Gem과 노트북, 업무 자리에서 잘 굴러가는지 한 번씩 들여다봐주시고 막히는 지점 있으면 언제든 편하게 말 걸어주세요. 0022 days agoAI 스터디 2주차 — “자동화”보다 “가드레일”을 고민하게 된 이유
AI 스터디 2주차 — “자동화”보다 “가드레일”을 고민하게 된 이유 2주차 들어오면서부터는 이걸 단순 아이디어 수준이 아니라 “실제로 굴러갈 수 있는가?” 관점으로 보기 시작했다. 1주차 때는 “AI가 인터뷰하고 PARA 구조로 정리해서 노션에 넣어주면 좋겠다” 정도의 느낌이었다면, 2주차부터는 진짜 구현 관점으로 들어가기 시작했다. 처음에는 노션 AI부터 봤다. 노션 안에도 AI 에이전트 같은 흐름이 존재했고, 처음엔 그냥 이걸 잘 활용하면 끝나는 거 아닌가 싶었다. 근데 보다 보니까 결국 크레딧 구조처럼 보였고, 사용할수록 비용이 붙는 방향처럼 느껴졌다. 그 순간부터 약간 현실감이 들어왔다. “아 결국 이것도 업무 자동화 = 비용 구조로 가는구나” 싶었다. 그래서 다음으로 생각한 게 MCP였다. 클로드에 MCP 연결하고, 노션 API 붙이고, PARA 규칙을 학습시켜서 사용자는 대충 말하고 AI가 인터뷰하고 자동으로 Project / Task 생성하는 흐름. 이론상으로는 가능했다. 실제로 노션 API_KEY도 있었고, 권한 자체도 존재했다. 근데 계속 구조를 보다 보니까 갑자기 위험하다는 생각이 들기 시작했다. 핵심은 마스터 권한이었다. 그냥 자동화가 아니라 “AI + 실행 권한” 구조라는 게 너무 크게 느껴졌다. 그리고 최근 클로드 보안 이슈들을 보면서 더 체감했다. 아무리 지침을 빡세게 넣어도 결국 추론 모델은 자기 판단을 한다. 예를 들면 “DB 최적화해줘” 했는데, AI가 “다 밀고 다시 만드는 게 더 빠르네?”라고 판단하면 실제로 그렇게 행동할 수도 있는 거다. 그 순간부터 “AI가 똑똑하다”랑 “운영적으로 안전하다”는 완전히 다른 문제라는 걸 계속 체감하게 됐다. 거기에 더해서, 곽인구 개발팀장님이 준 권한도 결국 선의 기반이었다. 내가 실험한다고 멋대로 휘두르는 건 아닌 것 같았다. 그래서 다시 방향을 틀기 시작했다. 굳이 MCP + 외부 AI + 마스터 권한 구조까지 가야 하나? 다시 노션 자체 AI를 보기 시작했다. 처음엔 “노션 AI도 결국 크레딧 계속 빠지는 구조 아냐?”라고 생각했는데, 실제로 써보니까 생각보다 그렇지는 않았다. 지금 쓰고 있는 엔터프라이즈 구독 기준에서는, 적어도 내가 테스트한 범위에서는 몇 번 사용했다고 막 제한이 걸리거나 바로 돈 빠지는 느낌은 아니었다. 그래서 생각이 바뀌기 시작했다. “굳이 외부 AI가 노션을 제어할 필요 없이, 노션 안에서 노션 AI를 업무 인터뷰 에이전트처럼 쓰면 되지 않을까?” 노션 AI가 생각보다 현재 페이지, 연결된 문서, 권한 범위 안의 내용들을 잘 읽고 이해했다. 그래서 컨텍스트 기반 인터뷰에 꽤 맞아 보였다. 그때부터 실제로 페이지 구조를 만들기 시작했다. 처음에는 그냥 프롬프트 하나면 될 줄 알았다. 근데 실제로 해보니까, 한 개 안에 다 넣으면 오히려 흐름이 꼬였다. 그래서 역할을 나눴다. 하나는 지식 인터뷰. 이건 진짜 인터뷰 역할만 한다. 질문 하나씩. 맥락 먼저 확보. 인터뷰 전에 구조화 금지. 다른 하나는 PARA 구조화. 인터뷰 결과를 받아서 PARA 분류, Area / Project 판단, Task 생성 같은 걸 담당한다. 근데 또 문제가 생겼다. 페이지를 둘로 나누니까 흐름이 끊겼다. 매번 지식 인터뷰 실행 → 결과 복사 → 구조화 실행을 해야 했다. 즉 구조는 맞는데, 실제로 사용하기에는 불편했다. 그래서 결국 오케스트레이터를 만들게 됐다. 역할은 단순했다. 지식 인터뷰 먼저 실행하고, 정보가 충분해지면 PARA 구조화로 넘기는 것. 즉 인터뷰 → 맥락 확보 → 구조화 → Task 생성 흐름 자체를 관리하는 역할이다. 실제 사용 방식은 생각보다 단순했다. 노션 AI한테 “워크플로우_오케스트레이터.md 실행” 시키면 됐다. 그러면 인터뷰하고, 맥락 모으고, 구조화하고, Task 생성까지 이어졌다. 근데 또 문제 나왔다. AI가 너무 빨리 결과물을 만들려고 했다. 몇 줄만 입력해도 “정리해줄게” 모드로 바로 들어간다. 인터뷰 없이 Task 만들고, 충분한 정보 없이 회고 만들고, JSON 질문 던지고, 설문 폼처럼 행동했다. 내가 원한 건 “사고 정리형 인터뷰”였는데, 실제로는 “문서 자동 생성기”처럼 행동했다. 그래서 이때부터는 기능 추가보다 가드레일 추가가 더 많아졌다. 인터뷰 전 구조화 금지. JSON 질문 금지. 3줄 이상 답변 금지. 긴 설명 금지. 충분한 정보 전 결과물 생성 금지. “정리해줄게” 모드 금지. 계속 이런 것들만 늘어나기 시작했다. 솔직히 느끼는 건 이거다. 공수가 너무 많이 든다. 진짜 하다 보면 기능 만드는 시간보다 주의 사항 만드는 시간이 더 길어진다. 근데 동시에 느끼는 것도 있다. AI 자동화라는 건 결국 “무엇을 하게 할까?”보다 “무엇을 못하게 막을까?”에 더 가까운 것 같다. 지금 기준에서는, AI가 다 알아서 처리하는 구조보다 인터뷰로 맥락 확보하고, 사용자가 승인 가능한 수준으로만 구조화하는 흐름이 훨씬 현실적으로 느껴진다. 일단은 계속 시도해볼 생각이다. 1023 days ago이번 AI 스터디는 기존처럼 누가 앞에서 강의를 진행하는 방식이 아니라, 각자 진행 중인 개인 프로젝트를 가져와 자유롭게 공유하는 분위기로 진행되었습니다
누구는 게임 개발 자동화 이야기를 하고, 또 다른 분은 실제 업무에 AI를 어떻게 붙이고 있는지 보여주면서 생각보다 훨씬 다양한 방식으로 AI를 활용하고 있다는 걸 느낄 수 있었습니다. 특히 좋았던 건 “정답 발표” 느낌이 아니라 실제로 삽질했던 과정, 실패했던 방식, 그리고 최근에 효과 좋았던 워크플로우를 편하게 이야기했다는 점이었습니다. “이렇게 하니까 토큰 낭비가 줄었다” “에이전트 루프는 여기서 막히더라” “로컬 모델은 결국 메모리 세팅이 중요했다” 같은 현실적인 이야기들이 많아서 더 재미있었습니다. 각자 개발하는 분야도 전부 달랐습니다. 게임 개발 자동화 툴 에이전트 시스템 UI 생성 로컬 AI 서버 문서 처리 멀티 에이전트 구조 코딩 어시스턴트 등등… 같은 AI를 써도 접근 방식이 전부 달라서 듣는 재미가 있었습니다. 무엇보다 이번 스터디의 가장 큰 목적은 “잘 가르치는 자리” 보다는 “같이 만드는 사람들끼리 친해지는 자리”에 가까웠습니다. 끝나고 다 같이 이야기하면서 요즘 어떤 툴 쓰는지, 어떤 모델이 괜찮은지, 개발하면서 어디서 막히는지 편하게 공유할 수 있어서 좋았습니다. 혼자 개발하면 결국 시야가 좁아질 때가 있는데, 다른 사람들의 작업 흐름을 직접 들으니까 새로운 아이디어도 많이 얻을 수 있었습니다. 특히 AI 분야는 변화 속도가 너무 빨라서 혼자 정보 따라가는 것보다 이렇게 사례를 공유하는 자리가 훨씬 도움이 되는 것 같습니다. 이번 스터디에서는 “AI가 미래다” 같은 거창한 이야기보다 당장 실제로 어떻게 쓰고 있는지가 중심이라 더 좋았습니다. 실제로 돌아가는 프로젝트 이야기들이 많아서 현실감도 있었고, 다들 자기만의 스타일로 개발하고 있다는 점도 인상적이었습니다. 그리고 분위기가 딱딱하지 않아서 더 편했습니다. 혼자 공부하는 것도 중요하지만 이렇게 서로 결과물 보여주고 이야기 나누는 시간이 동기부여에는 훨씬 큰 도움이 되는 것 같습니다. 다음에는 더 많은 프로젝트 사례도 보고 싶고, 실제로 협업 형태로 이어지는 작업도 있으면 재미있을 것 같습니다. 편하게 이야기 나누고 각자 만든 것들 공유하면서 좋은 자극도 많이 받은 시간이었습니다. 참여하신 분들 모두 고생 많으셨습니다 👍 20a month agoAI 스터디 1주차 후 기
이번 스터디를 통해서 교육의 질을 높일 수 있는 기회가 될 것 같습니다. 다른 분들의 프로젝트도 기대되고 함께 성장할 수 있는 기회가 될 것 같아 기대가 됩니다! 20a month ago
