AI로 콘텐츠·강의·제품 개발 동시에 하는 법

지난 일요일 제가 이좡(亦庄) 모듈러 OPC(WaytoAGI 커뮤니티 운영)에서 했던 오프라인 공유입니다. 현장에서 꽤 좋은 반응을 받았습니다. 돌아와서 글로 정리해 여러분과 나누려 합니다.

도구는 점점 많아지고 모델은 점점 강력해지지만, 사용법이 그대로라면 사람은 오히려 점점 더 바빠질 수 있습니다.

한 창에서는 글을 쓰고, 한 창에서는 이미지를 만들고, 한 창에서는 코드를 고칩니다. 보기에는 AI 팀을 꾸린 것 같지만, 실은 모든 창이 당신의 대답을 기다리고 있습니다. 자료를 옮기고, 배경을 보충하고, 다음에 무엇을 할지 알려주고, 잘못된 걸 발견하면 다시 돌아와 고쳐야 합니다.

AI가 확실히 일을 많이 했지만, 당신도 놀고 있지는 않았습니다. 다만 직접 일하던 것에서, 사방으로 말을 전하는 것으로 바뀌었을 뿐입니다.

저는 지금은 이렇게 쓰고 싶지 않습니다.

저는 라오진(老金)입니다. 자기 매체 외에도 지금 덕다오(得到)와 사역(私域) 강의를 하고 있고, 동시에 여러 개인 프로젝트를 진행하고 있습니다. 멀티미디어 어시스턴트, 금융 퀀트 어시스턴트, Meta_Kim, 워크벤치, 그리고 개인 어시스턴트입니다. 이 프로젝트들은 대부분 아직 개발 중이고, 성숙하다고 할 수도 없고, 누워서 돈을 버는 단계는 더더욱 아닙니다.

하지만 확실히 변한 것이 하나 있습니다. 점점 더 많은 일이, 제가 앞의 일을 직접 끝내기를 기다리지 않고도 다음 일을 시작할 수 있게 되었습니다.

갑자기 코드를 쓰게 되어서도 아니고, 모든 업계를 다 공부해서도 아닙니다. 다만 저만의 AI 활용 방식을 서서히 터득해 나가고 있기 때문입니다.

먼저 리서치를 해서 일을 명확히 이해하고, 그다음 제가 진짜로 원하는 게 무엇인지 판단합니다. 그리고 목표와 기준을 AI와 정렬하고, 적합한 도구를 고르고, 과제를 나누고, 오케스트레이션하고, 실행해 나가며, 마지막에는 실제 결과로 검수합니다.

이 흐름은 지금 제가 콘텐츠를 쓰고, 강의를 만들고, 제품을 개발하는 상당 부분의 업무를 관통하고 있습니다.

먼저 낯선 일을 연구해 파악한 뒤, 어떻게 할지 결정한다

낯선 주제에 들어갈 때, 제 첫 단계는 보통 심층 리서치(Deep Research)를 하는 것입니다.

제 사용 경험만 말하자면, 이 부분에서 제가 가장 인정하는 것은 ChatGPT 웹 버전이고, 그 다음이 Gemini입니다. 국내에서는 저는 더우바오(豆包)를 씁니다. 이건 제 사용 판단입니다.

제가 중요하게 보는 것은, 제가 질문과 요구를 명확히 전달한 뒤, 그것이 그 문제를 중심으로 한 분야의 중요한 정보를 펼쳐줄 수 있는지입니다.

이 분야는 어떤 상황인지, 어떤 핵심 개념이 있는지, 사람들이 무엇을 두고 논쟁하는지, 어떤 전형적 사례가 있는지, 어떤 주장에는 근거가 있고 어떤 것에는 아직 이견이 있는지.

때로는 제가 처음에는 전혀 생각하지 못했던 문제까지 끌어내 주기도 합니다.

이 능력은 저에게 특히 중요합니다. 예전에 낯선 분야에 들어갈 때 가장 곤란한 것은 자료가 적은 게 아니라, 오히려 자료가 너무 많은 것이었습니다. 검색하면 수십 편의 글이 나오고, 또 검색하면 수십 개의 관점이 나옵니다. 무엇이 중요한지, 무엇이 그저 소음인지, 심지어 제가 무엇을 빠뜨렸는지도 모릅니다.

심층 리서치가 먼저 주는 것은 최종 답이 아니라 하나의 지도입니다.

그것은 이 분야가 대략 어떻게 생겼는지, 중요한 문제가 어디에 있는지, 어디를 더 파볼 가치가 있는지 알게 해줍니다. 어느 길로 갈지는 제가 하려는 일과 결합해 판단해야 합니다.

물론 심층 리서치를 한 번 한다고 한 분야의 자료를 다 모을 수 있다고는 생각하지 않습니다. 어디까지 연구할 수 있는지는 처음부터 주제, 목표, 질문 범위와 관련이 있습니다.

하지만 원래 잘 모르던 사람에게는 중요한 문제를 한 번 훑고, 비교적 완전한 인식을 세운 뒤, 핵심 문제를 따라 계속 질문해 나가는 것만으로도 이미 충분히 가치가 있습니다.

과거에 가장 괴로웠던 것은, 자기 자신이 무엇을 모르는지조차 모른다는 점이었습니다. 지금은 적어도 이 지도에서 출발해 한 걸음씩 대조하고, 이해하고, 검증할 수 있습니다.

저는 특히 반증을 찾으라고 요구하기도 합니다. 제 판단이 어디서 틀릴 수 있는지, 반대 사례가 있는지, 어디의 증거가 아직 부족한지. 만약 AI가 제가 원래 믿고 있던 것을 점점 더 그럴듯하게 말해줄 뿐이라면, 그건 연구가 아니라 스스로에게 용기를 불어넣는 것입니다.

먼저 연구하는 것은 일 시작을 미루기 위해서가 아니라, 잘못된 방향에서 헛수고를 덜기 위해서입니다. 공식 계정 글을 쓸 때는, 일반인이 왜 주목할 가치가 있는지, 이번 변화가 대체 어디가 대단한지, 홍보와 실제 사용 사이에 괴리가 있는지, 어떻게 이야기해야 독자가 이해할 수 있는지를 고민합니다.

강의를 만들 때는 어떤 능력이 안정적이고, 어떤 조작이 재현 가능한지, 수강생이 가장 많이 막히는 곳이 어디인지, 어떻게 배울 수 있는 과정으로 쪼갤지, 마지막에 실제로 무엇을 내놓을 수 있는지를 살펴봅니다.

제품을 개발할 때는 다시 사용자 요구, 기존 경쟁 제품, 대체 방안, 기술 경계, 구현 비용을 봅니다. 만들 수 있느냐는 한 가지 문제이고, 제가 계속 투자할 가치가 있느냐는 또 다른 문제입니다.

그래서 저는 연구가 끝나자마자 보고서 전체를 그대로 또 다른 AI에 던져 '글 하나 써줘'라고 하는 걸 별로 좋아하지 않습니다. 이렇게 해도 물론 쓸 수 있지만, 자료 요약문이 되기 쉽습니다. 정보는 많고 판단은 적습니다.

제 방식은 먼저 취사선택하는 것입니다. 무엇이 진짜로 제 판단을 바꿨는지, 독자나 사용자가 가장 알아야 할 것은 무엇인지, 어떤 내용은 흥미롭긴 하지만 이번에 해결할 문제와는 관계가 없는지.

삭제할 것은 삭제하고, 더 찾아야 할 것은 더 찾아서, 마지막에 남은 것만 제작 단계로 들어갑니다.

주제가 연구 범위를 결정하고, 목적이 정보의 취사선택을 결정합니다. 연구에서 열 가지 기회가 나왔다고 해서 제가 열 가지를 다 해야 하는 것은 아닙니다.

제작 단계에 들어가면, 도구는 상황에 맞게 고른다

자기 매체와 강의 창작에서 저는 지금 주로 Codex를 씁니다. 글, 강의 원고, 흐름도, 마인드맵, 커버와 삽화, 그리고 일부 HTML 시연 페이지까지, 모두 같은 프로젝트 환경 안에서 밀어붙입니다.

다른 상황에서는 Claude Code, ZCode, DSH(즉 DeepSeek Harness), WorkBuddy, 그리고 더우바오 워크(豆包工作)도 씁니다.

구체적으로 무엇을 쓸지는 과제에 따라 다릅니다. 어떤 방식이 이미 어느 환경에서 매끄럽게 돌아가고 있다면 계속 거기서 쓰고, 도구가 다 갖춰져 보이게 하려고 매번 모든 소프트웨어를 다 열지는 않습니다.

게다가 저는 요즘 생태계를 점점 더 중요하게 여깁니다.

더우바오 워크를 좀 더 쓰는 중요한 이유 하나는 페이수(飛書) 생태계입니다. 자료도 페이수에 있고, 협업도 페이수에서 하며, 결과물도 결국 페이수로 돌아와야 합니다. 기존 업무 환경에 접속할 수 있느냐가 경험에 직접 영향을 줍니다. 구체적으로 어디까지 읽고 쓸 수 있는지는 실제 연동과 권한 범위에 따라 다릅니다.

제가 도구가 쓸 만한지 판단하는 기준은, 그 도구가 어느 구간을 대신 완성해 주는지, 그리고 그 결과가 바로 다음 구간으로 이어질 수 있는지입니다.

개별 답변이 얼마나 멋진지는 이제 그렇게 신경 쓰지 않습니다. 왕복해서 자료를 옮기는 횟수를 줄여주는 것이 진짜 편한 것입니다.

저는 휴대폰으로 그림 한 장을 보면서, 정렬되지 않은 곳을 많이 발견한다

강의를 만들 때 저는 복잡한 관계를 흐름도, 마인드맵으로 자주 그립니다. 어느 단계를 먼저 하는지, 어떤 조건이 충족돼야 다음으로 갈 수 있는지를 그림에 넣으면, 긴 설명보다 훨씬 쉽게 파악됩니다.

제품을 만들 때도 저는 먼저 프로토타입을 봅니다.

워크벤치를 예로 들면, 제가 원하는 것은 과제가 어디까지 됐는지, 누가 담당하는지, 어디서 막혔는지를 명확히 보는 것입니다. 이 페이지를 먼저 그려보면, 그것이 핵심을 잡았는지 점검할 수 있습니다. 가장 나와야 할 과제 진입점조차 찾을 수 없다면, 인터페이스가 아무리 정교해도 고쳐야 합니다.

이때 휴대폰으로 문제를 지적하고 AI에게 프로토타입을 조정하게 하는 것이, 코드를 다 쓴 뒤에 다시 손보는 것보다 훨씬 적은 비용이 듭니다.

저는 휴대폰으로 모든 버튼을 그리는 게 아니라, 휴대폰으로 그것이 제대로 됐는지 판단하는 것입니다.

문자로 규칙을 명확히 하고, 그림으로 구조를 눈앞에 펼치고, 상호작용과 예외 상태는 실제 페이지에 넣어 검증합니다. 이 세 단계가 이어져야 저는 이후 제작을 계속하게 합니다.

또 저는 AI가 하는 일을 페이수와도 모두 연결합니다. 매일 아침 제 AI 어시스턴트가 우선순위에 따라 사항을 정리해 주고, 무엇이 끝났는지 바로 음성으로 알리면, 관련된 모든 상태가 함께 바뀝니다.

예전에 게임 기획을 하던 습관이, 지금 오히려 더 유용하다

저는 예전에 게임 연구개발을 여러 해 했습니다. 지금 돌아보면, 이 경험이 제 AI 활용에 미친 영향이 꽤 큽니다.

게임 기획서 자체가 하나의 복잡한 체계입니다. 기능 몇 개를 나열하면 끝나는 게 아닙니다. 제 손에는 원래 기획서를 쓰던 Skill도 하나 있는데, 목표, 제작 원칙, 사용자 경험에서 시작해 모듈, 기능, 흐름, 프로토타입까지, 마지막에는 필드 정의에 이르기까지 세세하게 씁니다.

예를 들어 저는 제가 만든 이 워크벤치로 워크플로를 엮습니다. 이 내용들은 반드시 하나의 선이 되어야 합니다.

왜 이걸 만드는지, 어떤 원칙은 깨뜨려서는 안 되는지, 사용자가 어떤 느낌을 받았으면 하는지, 그다음에야 구체적으로 무엇을 하고, 어떻게 표현하고, 어떤 데이터를 기록해야 하는지입니다.

앞에서는 사용자 이해 비용을 낮춘다고 말해놓고, 뒤에서는 5단계 메뉴에 버튼 십여 개와 복잡한 상태를 잔뜩 설계해서는 안 됩니다. 그러면 앞부분을 아무리 잘 써도 의미가 없습니다.

어떤 상태가 규칙에는 있는데 프로토타입에는 없고, 데이터 정의에 이르러서는 또 다른 이름으로 바뀐다면, 뒤에 있는 사람은 하면서 추측할 수밖에 없고, 재작업도 계속 이어집니다.

그래서 지금 제품을 만들고, 강의를 만들고, 심지어 콘텐츠를 쓸 때도 저는 계속 앞으로 거슬러 추적합니다. 이 물건은 왜 존재하는가, 그것은 어느 목표를 위해 봉사하는가, 이 기능, 이 그림, 이 문장은 정말 그 목표를 위해 봉사하고 있는가?

봉사하지 않는다면 삭제를 고려합니다. 이미 만들어 놓았다는 이유로 아까워하지 않습니다.

이 Skill에서 진짜 남길 가치가 있는 것은 완벽해 보이는 문서 한 부가 아니라, 매 단계에서 그 이유를 앞으로 거슬러 찾을 수 있는 방법 한 세트입니다.

혼자서 왜 더 빠른가? 많은 대기가 사라졌기 때문이다

저는 프로젝트를 해봤기 때문에 한 가지를 잘 압니다. 어떤 일이 제기되어 끝날 때까지, 그 사이에 드는 시간이 전부 제작은 아닙니다.

일정을 조율해야 하고, 인수인계해야 하고, 다시 설명해야 합니다. 때로는 모두가 바빠서, 한 가지가 이미 완성됐는데도 다음 사람이 시간이 날 때까지 기다려야 계속할 수 있습니다. 각자를 따로 보면 아무 문제가 없는데도, 프로젝트는 여전히 느리게 갑니다.

저는 지금 subagent를 자주 써서 여러 일을 나눕니다. 어떤 것은 콘텐츠를 맡고, 어떤 것은 디자인을 맡고, 어떤 것은 개발을 맡고, 또 검사를 전담하는 것도 있으며, 마지막에는 메인 Agent가 총괄합니다.

듣기에는 아주 좋지만, 여기에는 아주 큰 함정이 하나 있습니다. 사람이 많다고 효율이 높은 게 아니고, AI도 마찬가지입니다.

만약 여러 Agent가 이해하는 목표가 다르다면, 그것들이 빠르게 할수록 마지막에 합칠 때 더 골치 아파집니다.

예를 들어 강의 하나를 만들 때, 학습 목표가 아직 정해지지도 않았는데 한 Agent는 원고를 쓰고, 하나는 그림을 만들고, 하나는 연습 문제를 내게 합니다. 모두 동시에 작업을 시작하니 효율이 극대화된 것처럼 보이지만, 마지막에 보면 세 개의 강의를 만든 것입니다.

이건 병렬이 아니라, 병렬로 재작업을 만들어내는 것입니다.

그래서 분업 전에 저는 먼저 목표, 성공 기준, 공통 근거를 정합니다. 무엇이 이미 정해졌는지, 무엇은 스스로 결정하면 안 되는지, 다음 단계로 넘길 결과물은 어떤 모습이어야 하는지를 모두 명확히 해야 합니다.

독립적으로 완성할 수 있는 것은 병렬로 합니다. 앞뒤 의존이 있는 것은 기다립니다. 앞의 결론이 나오지 않았으면, 뒤에서 추측으로 계속 진행하지 않습니다.

정말로 여러 멤버가 과제를 공유하고 직접 소통해야 할 때만, 저는 Agent Teams 같은 협업 방식을 씁니다. 직렬이냐 병렬이냐는 과제 간 의존성을 보는 것이지, 팀 이름이 무엇인지를 보는 게 아닙니다.

저에게 진짜 볼 가치가 있는 것은 동시에 몇 개의 Agent를 열었느냐가 아니라, 그 결과들을 이어붙일 수 있느냐, 문제가 생겼을 때 해당하는 사람과 구간을 찾아낼 수 있느냐입니다.

Meta_Kim: 조직이라는 층을 채우다

저는 GitHub 오픈소스 프로젝트가 하나 있는데, 이름은 Meta_Kim이고 중국어 이름은 위안자거우(元架构)입니다.

제가 이걸 만든 이유는 아주 직접적입니다. 모델이 점점 더 일을 잘하게 되면서, 진짜 어려워지기 시작한 것은 이 일 잘하는 능력들을 누가 조직하느냐입니다.

그것이 채워야 하는 것은 요구 정렬, 능력 선택, 과제 오케스트레이션, 검토와 검증이라는 층이지, 코드를 쓰는 손 하나를 또 만드는 게 아닙니다.

먼저 요구 정렬입니다. 제가 한마디 하면, AI는 제가 진짜로 무엇을 바꾸고 싶은지부터 이해해야 하고, 즉시 뛰쳐나가 일을 시작해서는 안 됩니다.

최근에는 시각화 인터페이스를 하나 추가했는데, 대략 이런 모습이고 아직 다 끝나지 않았습니다. 만약 두 선택이 프로젝트를 다른 방향으로 이끌 수 있다면, 그것은 저에게 물어야 합니다. 예를 들어 같은 도구를 만들더라도, 먼저 자기 자신이 쓰려는 것인지, 아니면 외부용 제품으로 만들 준비인지에 따라 이후의 권한, 데이터, 배포, 전달과 유지보수가 모두 달라집니다.

이런 선택은 AI가 몰래 저를 대신해 결정해서는 안 됩니다. 하지만 스타일이 이미 확정됐고 단지 어떤 간격만 조정하면 되거나, 명백한 오류 하나를 고치는 것이라면, 매번 돌아와 회의를 열 필요는 없습니다.

제가 유지하고 싶은 것은 방향을 결정하는 권한이지, AI의 모든 마우스 움직임을 직접 승인하는 것이 아닙니다.

방향이 정렬된 뒤에는, 현재 환경에서 실제로 쓸 수 있는 능력을 다시 점검합니다. 어떤 Agent, Skill, MCP와 도구가 있는지, 권한은 충분한지, 입력과 출력은 무엇인지, 최종 결과물을 다음 단계가 받아낼 수 있는지.

컴퓨터에 설치해 본 적 있는 도구 이름을 나열하면, 그 능력을 가진 셈이 되는 게 아닙니다.

그다음에야 오케스트레이션에 들어갑니다. 누가 무엇을 하고, 무엇을 먼저 하고, 무엇을 나중에 하고, 어디서 병렬로 하고, 어디서 기다리는지. 어느 단계가 통과하지 못하면 어디로 돌아가고, 어떤 조건이 충족된 뒤에 전달로 넘어가는지.

오케스트레이터가 반드시 모든 일을 직접 다 하는 것은 아니지만, 이 능력들이 서로 부딪히지 않게 하는 책임은 집니다.

예전에 게임 프로젝트를 할 때도 마찬가지였습니다. 프로그램, 아트, 기획, 테스트가 모두 뛰어나다고 해서 프로젝트가 자연스럽게 좋아지는 것은 아닙니다. 목표, 순서, 인수인계와 검수를 조직하는 사람이 있어야 합니다. AI 팀도 이 문제를 우회하지 못했습니다.

Goal을 잘 설정해서, 일이 계속 앞으로 나아가게 한다

만약 한 단계를 완료할 때마다 AI가 멈춰 서서 저에게 '다음은요?'라고 묻는다면, 저는 실행에서 진짜로 벗어난 게 아니라, 계속 '계속'이라고 답하는 프로젝트 매니저가 된 것입니다.

그래서 저는 먼저 GoalPro로 목표를 명확히 합니다. 진짜 의도가 무엇인지, 끝난 뒤 무엇이 바뀌어야 하는지, 무엇이 성공인지, 이번 라운드에서 하지 않을 일은 무엇인지, 어떤 증거를 남겨야 하는지, 어떤 상황에서는 반드시 멈춰야 하는지.

맞습니다, 이것도 제 GitHub 오픈소스 프로젝트에 있습니다.

그것은 Goal Prompt와 Loop Prompt를 정리하는 일을 맡고, 스스로 과제를 실행하지는 않습니다. 프롬프트에 '매일 계속'이라고 한 줄 쓴다고 해서 백그라운드 자동화가 생기는 것도 아닙니다. 실제로 일하는 것은 여전히 Codex, Claude Code 같은 실행 도구입니다.

이런 약속을 해둔 뒤에 실행 도구를 계속 진행시킵니다. 끝난 뒤에도 저는 그것이 완료했다고 말하는 것만 보지 않습니다.

저는 요즘 이 세 글자를 점점 믿지 않습니다. 저는 증거를 보고 싶습니다.

글이 설명해야 할 문제를 명확히 설명했는지, 페이지가 목표 조작을 완수할 수 있는지, 테스트가 실제로 돌아갔는지, 수정이 원래의 고장을 해결했는지, 또 다른 곳을 망가뜨리지는 않았는지.

통과하지 못하면 해당 단계로 돌아가 고칩니다. 통과하면 다음으로 넘어갑니다. 일이 끝난 뒤에 임시로 통과하기 쉬운 검사 몇 개를 골라 스스로에게 보고하는 식이어서는 안 됩니다.

그래서 제가 원하는 것은 AI가 영원히 멈추지 않는 것이 아니라, 목표와 권한과 약속 범위가 모두 변하지 않았을 때 스스로 계속 밀고 나가는 것입니다. 결과를 진짜로 바꾸거나 권한 범위를 넘어설 필요가 있을 때만 다시 저를 찾아오면 됩니다.

여러 차례 계속 씨름해도 새로운 것을 내놓지 못한다면, 그것도 멈춰야 합니다. 그것은 그저 말을 바꿔가며 자신을 반복하는 것일 뿐, 계속 돌려도 의미가 없습니다.

저에게 필요한 것은 영원히 바쁜 컴퓨터가 아니라, 점점 완성에 가까워지는 일입니다. 이때 해바라기(向日葵) 같은 원격 제어 도구를 연결하면, 저는 휴대폰으로 컴퓨터를 보고 인터페이스를 조작하며, 사람이 이어받아야 하는 부분을 처리할 수 있습니다.

제가 해야 하는 것은 이번 라운드에 무엇을 넘겼는지, 어디가 불만족스러운지, 어느 노선을 바꿔야 하는지를 보는 것입니다. 구체적인 일은 여전히 컴퓨터의 실행 환경에서 돌아가고, 저는 휴대폰으로 한 글자씩 글을 쓰거나 한 줄씩 코드를 고칠 필요가 없습니다. 컴퓨터를 켜둔 채로, 진행 상황만 잘 저장되면 됩니다.

물론 이렇게 돌리면 할당량을 많이 먹습니다. 구체적으로 얼마나 드는지는 나중에 따로 말하겠습니다.

그런데 말이죠, 예전에 같은 일이 한꺼번에 밀려왔다면 먼저 사람을 찾고, 분업하고, 시간을 짜야 했습니다. 많은 아이디어는 첫 버전에 끼지도 못했습니다.

이 두 가지 고민 중에서 나는 지금의 이런 고민을 처리하는 쪽을 더 선호한다.

지금 나를 자주 막아서는 것은 오히려 할당량이다

이 작업 방식에는 아주 현실적인 문제가 하나 있다. 바로 할당량을 잡아먹는다는 점이다.

지금의 내 강도대로라면, 글과 이미지, 강의에 몇 개 프로젝트까지 함께 밀어붙이면 Codex의 양은 하루도 못 버틸 때가 있다. GPT-6의 라이트 모드를 써도 매우 빠르게 소모된다. 물론 이건 어디까지나 나의 실제 체감일 뿐, 모든 사람이 그렇다는 뜻은 아니다.

그래서 나는 지금 이번 한 번의 생성에 얼마가 들었는지만 보는 것을 별로 좋아하지 않고, 실제로 쓸 수 있는 성과물 하나를 내놓기까지 총 얼마의 시간과 사용량, 그리고 사람의 마무리 작업이 들었는지를 본다.

구조가 정해지지 않았는데 이미지를 대량으로 뽑아내면, 방향이 바뀌는 순간 전부 다시 만들어야 한다. 몇 개의 Agent가 같은 무관한 자료를 반복해서 읽으면, 겉보기에는 모두 연구하는 것처럼 보이지만 실제로는 돈을 반복해서 쓰고 있는 것이다. 국소적인 오류 때문에 전체 작업을 처음부터 다시 하는 것도 비용이다.

가장 저렴한 한 번의 생성이, 반드시 가장 저렴한 한 번의 납품으로 이어지지는 않는다.

이것이 바로 앞선 연구와 정렬을 생략할 수 없는 이유이기도 하다. 방향을 명확히 생각하지 않았을 때에는, 실행을 적극적으로 할수록 낭비가 더 커질 수 있다.

만약 한 차례 작업을 돌리고 나서 더 명확한 판단도 없고, 더 쓸 만한 성과물도 없고, 새로운 근거도 없다면, 멈추고 살펴봐야 한다. 과연 나아가고 있는 것인지, 아니면 그저 소모하고 있는 것인지를.

마지막으로

내가 지금 콘텐츠와 강의, 그리고 몇 개 프로젝트를 병행할 수 있는 것은 이 일들이 나를 필요로 하지 않아서가 아니라, 이들이 서로 다른 단계에 있을 수 있기 때문이다.

아 맞다, 덧붙여 말하자면 내 Github는 KimYx0207이고, 꽤 많이 오픈소스로 공개했다. 너에게 도움이 되기를 바란다. 어떤 것은 아직 연구 중이고, 어떤 것은 이미 제작에 들어갔고, 어떤 것은 테스트 중이다. 스스로 밀어붙일 수 있는 부분은 먼저 앞으로 나아가게 하고, 정말로 내가 결단을 내려야 하는 문제는 다시 한데 모아 돌아온다.

하지만 같은 프로젝트 내부에는 여전히 의존 관계가 존재한다. 목표가 확정되지 않았으면 성급하게 대규모 개발을 해서는 안 되고, 핵심 규칙이 정해지지 않았으면 한 무리의 Agent가 각자 다른 세트를 쓰게 해서도 안 된다.

여러 프로젝트를 병행한다고 해서 각 프로젝트 안의 모든 단계를 병행해야 한다는 뜻은 아니고, 더더욱 기회 하나를 발견했다고 해서 즉시 프로젝트를 하나 더 시작해야 한다는 뜻도 아니다.

한 사람에게 AI는 실행할 수 있는 일을 많아지게 했지만, 내 주의력은 그에 따라 무한히 늘어나지 않았다. 무엇을 먼저 하고, 무엇을 나중에 하고, 무엇은 아예 하지 않을지는 오히려 내가 결정해야 할 일이 더 많아졌다.

무엇을 먼저 하지 않을지 아는 것도 생산성이다.

나는 팀 프로젝트를 해본 적이 있어서, 연구와 콘텐츠, 디자인, 개발, 테스트를 한데 모으려면 얼마나 많은 준비가 필요한지 안다.

막 일을 시작한 사람에게는, 아직 아이디어를 검증하기도 전에 누가 할지, 어떻게 협업할지, 비용을 감당할 수 있을지를 먼저 해결해야 한다. 이 단계에서 많은 일이 막힌다.

지금 나는 휴대폰 하나로, 로컬 컴퓨터 위의 AI를 조직해 글과 강의 자료를 완성하고, 제품 개발을 밀어붙이고, 다시 실제 결과에 따라 앞으로 나아갈 수 있다.

모든 프로젝트가 성공하는 것도 아니고, 모든 문제를 AI에게 맡길 수 있는 것도 아니다. 하지만 한 사람이 과거에는 작은 팀이 있어야 받아낼 수 있었던 일을 받아낼 기회를 이미 갖게 되었다.

이 일이 내게 준 자신감은, 새로운 도구 하나를 또 배우는 것보다 훨씬 크다.

예전에는 먼저 사람을 다 모아야 아이디어 하나를 검증할 엄두를 낼 수 있었다.

지금은, 먼저 물건을 만들어낼 수 있다.

그것이 계속할 가치가 있는지는, 결과가 내게 알려주게 하면 된다.

내 글을 읽어줘서 고맙다.

괜찮다고 생각하면, 가볍게 좋아요, 보고가기, 공유 삼연을 눌러줘🙂

가장 먼저 푸시를 받고 싶다면, 별표⭐를 눌러줘도 좋아～ 내 글을 봐줘서 고마워.

오픈소스 지식베이스 주소(실시간 업데이트 교류 그룹):

tffyvtlai4.feishu.cn/wiki/OhQ8wq…

라오진이 AI를 데리고 놀아요

139

글

57k

읽음

44

팔로워