AI가 답을 만드는 시대, 기획자는 무엇을 설계하는가

아 근데... 와주셨는데

내가 또 점심시간을 또

박수 한번 해볼까요?

졸업하고 졸업 시즌부터 스튜디오 드래퍼닉 컨셉아트 작가를 하다가 네이버를 가야겠다고 생각을 해서 네이버에 들어오게 됐고 네이버에서는 클립이랑 홈피드라는 지면을 다 오다가 네이버 앱 전반이랑 PC 메인을 담당하고 있는 서입준입니다.

9월은 네이버 클라우드에서 AI 조직으로 이동해서 AI 카드스 엔지니어링 모델, 프리비트 모델, 스킬 이런 것들을 다루기 위해서입니다. 부탁드리겠습니다. 오늘 말씀드릴 내용은 AI가 답을 만드는 시대, 기획자는 무엇을 설계하는지 하는 내용이고요.

그리고 개인의 프로포트에서 팀의 ground 룰로 라는 주제를 얘기해보려고 합니다. 이 질문 자체가 강연을 시작하기에 앞서 먼저 스스로에게 질문을 던져보면서 시작해보려고 합니다. 그래서 AI가 답을 만든 시대에 기획자는 무엇을 설계한가? 라고 많은 답들이 머릿속에서 지나가기도 하고

일단 이 질문을 어떻게 풀어갈지 오늘 설명을 드리도록 하겠습니다. 일단 저는 AI를 실제 업무에 적용하는 초기 도입과 확산을 막아 여러 시도를 해왔었는데요. 오늘 할 이야기는 AI 전문가의 기술 소개나 프로그램을 어떻게 작성해야겠나, 또는 어떻게 해야 AI가 더 말을 잘 듣는다,

이런 이야기라기보다는 기획자가 팀과 함께 AI를 사용하면서 병원들을 보고 그래서 AI를 쓰면서 발생하는 문제가 개인이 아니라 발생하면 어떤 일이 벌어지는지 그때 기획자 포션에서는 어떤 것을 나 그냥 이것만 얘기해

여러분들 샀죠? 네. 잠시 이제 서프라이즈가 있었고요. 아무 일도 없었습니다. 네. 잠시 불안정했고요. 입증을 계속 해주시면 됩니다. 공연적인 이야기에 들어가기 앞서 가지고 아이스팅을 해보려고 합니다. 소정의 선물 두 개를 준비를 했고요.

주신 두 분한테 선보를 드리도록 하겠습니다. 선보로는 아마 세기님이 전달해 주실 거예요. 일단 첫 번째로는 지금 코덱스라는 이름을 들으시면 어떤 모습이 떠오르시나요? 아마 이제 지금은 코덱스 앱을 많이 데스크톱 앱을 많이 생각하실 것 같고 검은 화면의 코드가 약간 터미널을 떠올릴 수도 있을 것 같습니다. 근데 요게 이제 실제로는 개발자를 위한 코딩 에이전트로 시작을 했었잖아요. 근데 지금은 조금 다른 일이 벌어지고 있는 것 같습니다.

기획서 작성이나 자료조사, 데이터 분석, 슬라이드 제작 이런 것들을 하고 있는데요. 이제 퀴즈가 나갈 건데요. 보시고 손을 딱 들어주시면 선생님이 지적해 주시면 될 것 같습니다. 그래서 지금 코덱스를 개발 후에 업무하는 사람의 이용자 수는 얼마나 될까? 1번 10만명 이상, 2번 50만명 이상, 3번 100만명 이상입니다.

- 지금 현장에서 손을 되게 많이 들어주셨는데 - 위 위 지정해주시면 됩니다 한 번 빠르게 제가 해볼게요 3, 2, 1 되게 너무 빠르다 자, 앤디 3번이요 - 3번이라고? - 네 바로 맞추셨습니다

100만 명 이상 쓰고 있어요. 현재 6월 기준에 놓고들여서 지금은 사용자 수가 더 많이 늘었다고 보고를 받았는데 현재 매주 코덱스 사용자 수는 500만 명 이상이라고 하고요. 그중에 코닝을 사용하는 개발 웨어 업무 사용자가 100만 명이라고 합니다. AI 에이전트는 특정 직무의 도구를 넣어서 모두의 업무 도구가 되고 있는 것 같고

최근 들어 워크라는 것들이 편입되기도 했고, 엔트로픽은 코드, 챗, 그리고 PPT 같은 걸 만드는 것도 도입을 하기도 했잖아요. 그래서 AI는 코딩만 한 게 전혀 아니라는 새롭지 않지만 새로운 내용들이 최근에 많이 들리는 것 같습니다.

그리고 이제 두 번째 문제이요. 아직 문제는 아닙니다. 조금 더 딥한 이야기를 하려고 합니다. AI 모델을 쓰시라고 하면은 이 소츠라고 어떤 그런 추론감도를 정할 수가 있잖아요. 기본적으로는 높아지, 라이트에서 맥스로 가면 할수록 모델의 더 많은 추론 시간을 주의합니다. 이때는 대안을 탐색하게 하고 검증을 하게 하고 수정을 하게 하고 잘못했다면 다시 처음 시작을 하게 하는데요. 이제 5.6, GPT 5.6 울트라는 시간을 주는 것에서 상당히 더 기본 구성을 바꿨다고 합니다.

여기에 워커버인지, 이제 준비 나가도록 하겠습니다. 아직 손짓이 많으시면 세빈이 님이 첫 번째 여러분들을 더 많은 초론인 기간에 사용하게 할지 아니면 에이전트를 병렬로 조율하게 할지 아니면 더 똑한 모델을 표지 번쓰게 할지 여기에 이제 담이 있습니다. 세빈이 님, 풀어주시면 될 것 같습니다. - 준비 되셨나요? - 네. 오케이. 3.

2, 1 제가 못 보는 거 알지 아 지금 저 끝에 되게 빵이 뜨시는 분이 계시거든요? 이번 에이전트를 겸결로 들리란다 오 맞습니다 역시 아카데미

퀄리티가 너무 높거든요. 저는 한 분이 여기에서 틀을 거라고 예상을 했는데 일단 기본으로 4개의 에이전트를 병렬로 조율한다고 합니다. 그래서 더 많은 오픈이 쓰는 대신 더 강한 결과와 더 짧은 완료 시간 저는 짧은 완료 시간은 아닌 것 같은데 오픈 AI는 그렇다고 싶습니다. 보겠습니다.

그래서 요새 이제 여기까지가 가벼운 아이스브레이킹이었고요. 본론으로 넘어가려고 합니다. 이 두 키즈로써 조금 다정할 수 있는 생각은 어떤 거냐면 개발의 도구로서 AI가 개발이 아닌 기획자, 디자이너나 나아가서 비즈니스를 하시는 분들께도 사용하고 있고 그리고 하물며 울트라라는 추론 강도를 쓰면 에이전트를 알아서 모델이 쓰는 그런 어떤 특이적

그 상황 속에서 저는 오늘 얘기할 주제는 팀에서 어떻게 잘 쓸 수 있을까? 모든 직군에서 함께 어떻게 협업을 할 수 있을까? 이 이야기를 활용해야 되는가? 일단 이야기를 해보려고 합니다. 우선 간단한 사례부터 조금 들어보려고 하는데요. 모두가 정답을 제시하는 팀은 팀을 다 알아야 하는 것 같아요.

주제를 가져와 보려고 합니다. 예시를 들려 보려고 하는데요. 대학생의 점심 메뉴 추천 서비스를 만들어라 라는 업무가 팀에 떨어지게 됩니다. 팀은 연령일 수도 있고 총명일 수도 있을 것 같습니다. 오늘은 4명으로 가져가고 있습니다. 첫 번째 팀원은 가까운 식당에 비교하는 서비스를 만들자고 했고 두 번째 팀원은 취향기만 추천, 세 번째는 리뷰를 탐색하고 네 번째는 함께 축병하는 경험을 만들려고 합니다. 근데 이 네 가지는 저는 모두가 정답이라고 생각을 하는데 이 네 가지를 모두 다 하려면 팀으로서는 그 잘못된 방향이 아닐까 생각이 듭니다. 이렇게 되면 정말 우리의 팀체가 무엇인지 하면 이것들을 개발자분들에게 해달라고 하면 이야기해야 할 것 같아요.

업무의 위계가 너무 무거워지잖아요. 이런 이야기들이 AI와 함께 하다 보면 그래서 우리는 어떤 누구의 문제를 풀고 있었지? 라는 질문들이 떠오르게 되고 결론적으로 모두가 삽질을 하게 되는 경험을 하게 되는 것 같습니다. 이러한 이야기들은 AI가 없던 데에는 결과물 하나를 만드는데 시간이 좀 오래 걸릴 것 같습니다. 다만 그렇기 때문에 그 과정에서 자연스럽게 대화를 주고받으면 우리가 주고받으면 우리가 말하는 학생이 좋지

핵심이 추천인가, 시간을 줄이는 건가, 의사결정을 빠르게 하는 건가 같은 이야기를 나눌 시간이 많았던 것 같습니다. 근데 이제 속도가 너무 빨라지다 보니까 빠르게 분산되는 것도 늘어났던 것 같습니다. 지금은 이제 예전에는 한 종이 기획서를 작성해서 리뷰를 하고 수정하고 다시 부품품과 얘기를 하고 나갔던 반면에 지금은 딱딱하는 기획서가 한 두 시간 만에 나오고 그것들도 또 내가 아이디어를 넣다 보면 산으로 가보고 엄청 비대해지고 하잖아요. 심지어 소규모 3명, 4명 팀 혹은 사업체에서는

조금만 내가 힘을 벗으면 개발과 평범까지 한 번에 들이 받아보니까 이런 작은 해석의 차이가 아주 빠르게 결과를 되어버리고 어긋남들이 더 크게 되는 것 같습니다. 그래서 저는 이런 AI가 어긋남를 해결해주지 않는다는 점을 좀 많이 질문을 하는 경험을 받았습니다. 그래서 AI는 답을 조금 빠르게 받고 결과류도 빠르게 만들어주는데 팀과 함께 이번 일대에 일어났을 때 문제점이 생기는 것을 경험을 해서 그 얘기를 본적적으로 드려보려고 합니다. 일단 제가

처음으로 AI를 클로드콘을 네이버에서 사용할 수 있게 된 공식적인 기간은 5월부터인데요. 그때는 저는 너무 신나가지고 저는 그 전부터 그냥 오픈클로로 잼마도 덜 돌려보고 핸드폰에서도 에이전트를 돌려보고 이상한 주식 관련 것도 만들어서 주식도 한국 투자직권에서 베스트 API로

구매를 했다 팔게 했다 했다가 너무 쫄려가지고 그런 식으로 했었기 때문에 AI가 들어오고 있던 게 너무 친히 났었는데요. 그래서 5월 말에는 개인 프로듀트로 반복 업무를 엄청 빠르게 만들어냈습니다. 숫자로 환산하기 어렵지만 업무 시간의 한 퍼센트는 많이 줄이고 대부분의 일을 혼자서 개인 프로듀스에

그런 파트로 클로즈 코드와 이렇게 작업을 했던 것 같습니다. 그러다 보니까 조금 이것저것 스킬도 만들게 됐고 에이전트나 워크플로우 같은 것을 스스로 조금 구축을 해가지고 팀원들에게 이런 거 쓰면 좋을 것 같은데 한번 써보시면 어떨까요? 제가 지금 우리 비주일 만에 뭔가를 만들어 봤는데 한번 써보세요 라고 스킬들을 공개 주렸던 것 같습니다.

결론적으로는 스킬을 공유했는데, 계속 후속으로 스킬 수정이 들어오고 있습니다. "어, 이 2d 문서를 써봤는데?""어, 안 되나 안 돼요?" 아니면"이 문서에 자꾸 이상한 이야기가 끼겨 들어와요?"와 같은 내용들이 있더라고요. 이게 왜 그런가 생각을 해보니까, 사람마다 입력하게 된 프롭트의 용어나, 아니면 플로어 같은 게 조금씩 다르기도 했고, 아니면 개인마다 주어진 문서 권한들이 있잖아요.

그것들이 다르기 때문에 AI가 문서를 보지 못했던 경우도 있었고 더 나아가서는 저희가'블랙박스'라는 표현을 막 쓰잖아요. AI가 어떤 문서를 어떤 기준으로 받는지에 대한 공용룰이 없다 보니까 자기 멋대로 쓰는 사람마다 다른 결과물들이 나오게 된 것 같고 그래서 이런 문제점들을 파악해서 아, 그러면 팀그라운드를 팀환경, 팀A에 대한 환경을 통한

좋은 판단을 팀만에서 반복시키면서 우리 팀만의 AI 셋을 만들어 갖고 싶다 라는 것을 생각해서 오늘 얘기들의 핵심 내용이 팀 그라운드 룰 팀에 성료를 구축했었습니다. 이제 총 3가지 단계를 통해서 구축을 했는데요. 세부 내용들은 수술하도록 하겠습니다. 일단 첫 번째는 그라운드 룰 공통 규칙입니다. 어떤 일을 하든 항상 지켜야 하는 팀의 기본 원칙,

If you understand it, you can think of a cloud markdown. The basic rule, the direction of the team, the role of the team, the team and the team are related to the team. The team is a lot of different teams, and the main team is a different team.

그런 내용들을 기재를 하거나, 응시해드리겠습니다. 두번째는 팀 스킬입니다. 팀 스킬을 처음에는 각자 만들기 시작했습니다. 상체 설계를 치는 거나 데이터를 조회하는 거나, 아니면 이슈 대응하는 것들에 대한 스킬들을 각자 만들었었는데, 그러다 보면 개인은 편할 수 있는데, 누군가 그걸 받아보는 사람이나 협업하는 사람들은

결국에는 통일화되지 않고 어중이 떠준다고 이야기 드리고 바닷가 그런 것들을 함께 구심점을 만들어 스킬을 만들 수 있도록 하겠습니다. 이때는 팀원들을 주고받으면서 회의록 작성하는 양식이라던가 스펙 검수나 반복되는 업무에서 동일한 양식과 문서를 참여할 수 있도록 스킬을 만들었습니다.

마지막으로는 제 핵심이라고 볼 수 있는 쉐어 할 수 있는 워크스페이스를 만들었는데요. 네이버는 github을 네이버 만의 서버에서 돌리는 OSS라는 공간이 있습니다. 그래서 github에다가 팀 공용 공간을 만들고, 여기에서 규칙, 스케일, 업데이트 내역 같은 것들을 계속 업데이트를 하고, 기간이나 특정 업데이트를 마치고 나면 github에다가 이런 것들을 해주세요. 라는 걸로 업데이트를 한 번에 공통되게 진행을 하도록 하겠습니다.

그래서 세 분의 용들을 하나씩 뽑아보도록 하겠습니다. 첫 번째는'그라운드 룰'입니다. '그라운드 룰'을 할 때는 꼭 다섯 가지를 적어놓고 다섯 가지를 기준할 수 있도록 하겠습니다. 첫 번째는 용어입니다. 같은 단어를 작전 의미로 쓰게 했는데요. 예를 들면'PV'라는 것들이

주거 받고 사람들이 얘기를 할 때 저희 네이버만의 PV 기준이 있습니다. 시간이나 유저의 정보 같은 것들을 기준으로 PV를 하는데요. 이게 저희 팀이랑 저 옆 팀이랑 저 옆 팀이랑 조금씩 다르기도 하고 혹은 그 데이터를 보는 C보들마다 조금 다르기도 합니다. 그래서 그런 세문디테일이나 용어들이 같이 홀리모품이 제외하지 않도록 기입을 해줬고요. 이거는 크로드마크다운의 전문화가 오면

다 얘기할 때마다 큰이 너무 많이 준비 되잖아요. 그래서 인덱싱을 할 수 있도록 특정 문서에 그런 정확한 용어들을 엑셀 파일로 넣어두고 만약에 너가 무언가를 구애할 때 이런 내용들이 필요하다고 판단되면 그 엑셀을 가져와 그래서 그 엑셀을 표기되어 있는 기준으로만 해 라는 인덱싱. 어찌 보면은 레그 같은 것들 조기 RH를 만들었다고 보시면 될 것 같습니다. RH 얘기하는 건 두 번째 기준 문서를 얘기 안 할 수 없을 것 같은데요. 두 번째는 기존 문서를 작성합니다.

네이버는 컴플루언스라는 툴로 위기와 지라 같은 것을 통해서 문서를 클라우드에서 같이 논의를 하는데요. 문서가 너무 많습니다. 저희 팀만의 또 뭐 시리십 명이고 개발 뭐 역업 호감은 훨씬 많아지는 상황인데 그 상황 속에서 각자가 쓴 또 초안들도 거기에 포함이 되었고.

어떤 스펙을 봐주는데 총 1번을 볼 수 있고 2번을 볼 수 있고 3번을 볼 수 있고 버전 1, 2번을 다 볼 수 있잖아요. 그래서 그런 것들이 아니라 어떤 기준 조서를 봐야 할지 먼저 정의를 해주셨습니다. 그리고 이제 세 번째는 표현인데요. 이건 모두가 모르드하게 알 수 있는 내용이겠지만 사실이랑 과정이랑

제한 부분을 알리겠습니까? 예를 들면 저희가 오늘 100명의 유저가 쓴 것으로 파악됩니다. 이게 유언스가 다양하잖아요. 파악됐다? 확인을 했다는 건가? 아니면 예상을 했다는 건가? 이런 가정이나 사실 내용들이 AI가 쓰다보면 조금 이렇게 잘못된 이야기로 흘러가는 내용들이 많습니다.

그래서 이게 정확히'응명이었다'와'응명으로 하겠다'와 같은 내용의 표현들을 명시를 해달라고 얘기를 했습니다. 그리고 이제 마지막에, 네 번째로는'보안'이었는데요. 여기 입력하면 안 되는 정보들을 명시했습니다. 간단하게 개인정보, 그리고 A, T, K, T, B, E, B, H, U, 이런 것들을 명시하는다고 했고요.

요거는 생각보다 중요하게 작동을 해야 될 것 같아서 여러분들도 이미 다 해보셨겠지만 저런 내용들을 명치 않으면 내가 갑자기 API 키를 채팅에 입력해주세요 그래서 입력하면 API 키는 이겁니다 라고 얘기를 하는데 그것들이 쌓이고 쌓이고 메모리 쌓이다 보면 갑자기 어느샌가 내 OS에 그 기톡을 올라오거나 하기 때문에 그런 것들을 명시를 했고요 마지막으로는 완료 단계입니다 결과가 어디에 남기고 누가 승리할지를 정의를 했습니다

예를 들면 이 단계를 입력하지 않으면, 그냥 갑자기 본문에 첨부를 해버리거나 본문을 수정해버리는 불상사가 만들어지만 합니다. 그런데 저희가 스펙 문서나 중요한 문서들을 쓸 때 그것들을 단순히 저하고 팀원만 보는 게 아니라 완전 타 팀에서도 들어와서 보고 참고하고

메인의 스페이스에만 초안을 등록할 수 있게 만들었고, 꼭 거기에 업로드하기 전에는 인간의 승인을 더해야 된다. 이런 그라운드 룰을 잡았다고 봐주시면 되겠습니다. 그리고 두번째는 팀 스킬 룰. 팀 스킬은 공동된 행동 양식.

그 규칙을 적는 데서 끝나지 않고 각 실제 업무마다 세분화해서 각 스팩마다 어떻게 작동하는지 만드는 겁니다. 요새 에이전트라는 용어들이 많이 낭발되고 있다 보니까 워크플로우라는 중요한 요소들을 많이 미치곤 하는 것 같은데 워크플로우로 구성을 하려고 노력을 했다고 합니다. 에이전트는 조금 다시 말해 앞단에 요새 에이전트는

요청사항 그리고 툴을 쓸 수 있는 권한들을 주고 이것들을'완수해왔라'라고 했을 때 그 친구가 정말 에이전트처럼 '어따다' 태우는 반면에'워크플로우'는 우리가 어떻게 어떤 특정 업무에서 어떤 절차로 진행을 해야 되는지와 같은 것들이 명시되어 있잖아요. 그런 식으로 팀 스킬을 구성하였습니다. 예를 들면'페이로크 정리다' 기획서 초안, 스펙 검수, 출시 정보, 데이터 확인 같은 스킬들을 만들었습니다.

The"Ground" can be similar to the"Scale Mark" in the bottom of the screen. The"Scale Mark" can be used to see the values of the"Excel" in the bottom of the screen. The"Telix" can be used to the"GP" in the bottom of the screen. The"GP" can be used to the"One Page" in the bottom of the screen. The"Long Innsure" can be used to the"Long Innsure" in the bottom of the screen. Is one of the хочешь to treat a new solution?

그리고 마지막으로 가장 중요하다고 생각하는 시스템인데요. 이제 이런 스킬들을 만들거나 아니면 환경 같은 것을 구축하거나 아니면 어떤 메모리 같은 프로필을 쓰다보면은 이제 조금만 실시간이 지나도 정말 각자 개인화되고 나만의 프로필, 나만의 노하우가 생기기 마련입니다. 그런데 그러다 보면 결국에는 이런 공통화된 요소들이 필요 없고 내가 알아서 하면 되지. 왜 너한테 그거 보고해야 돼? 불타는 상황들이 만들어지기로 하잖아요. 그래서 기타 오프를 통해서 이슈에서 어떤 스케줄을 고쳐주세요. 스케줄 해주세요.

그 코드패스 수정을 할 때마다 스멱방에 혹은 저희 메신저 방에 업데이트를 했습니다. 업데이트 해주시면 새로운 거 쓰실 수 있고요. 아니면 예를 들면 페이블이 나오자마자 일반인들에게도 못 쓰게 되면 저희 팀은 쓸 수 있었거든요. 그러려면 터미널 업데이트를 했어야 했는데

업데이트를 해야 된다와 같은 이야기들을 공유할 팀에 반영할 수 있는 시스템을 만들어놓겠습니다. 당연히 요새 루프라고 하겠지만 사람들이 하는 엄청 컨범한 일이잖아요. 그런 것들을 AI에 잘 적용될 수 있도록 하나 세팅했다고 봐주시면 좋을 것 같습니다. 그래서 이게 진짜 내가 한 일이 맞는가에 대한 체크플레이드에 대한 고민이 많았던 것 같아요. 그래서 내가 너무 나 혼자 알아서 이렇게

하고 팀원들은 사실 이것들이 필요 없는 거지 않았을까 라고 해서 많이 찾아보고 공부했었는데요. 마이크로소프트의 2026년 워크 트렌드 인덱스에서 이런 정답이다 라는 내용들을 파악할 수 있었습니다. 다행히. 이때 한 조사는 AI 업무가 자기 업무에서 얼마나 영향이 있을까 했을때 여러가지 항목 중에

개인 요인과 조직 요인을 나눠서 평가 점수를 매겨뒀더라고요. 그랬을 때 개인 요인에 대한 점수가 32점이었는데 이게 32%라기보다는 32점에 득점을 했는데 조직 요인이 67점으로 더 많은 영향을 끼치더라는 내용이 있었습니다. 그때 조직 요인은 문화, 다시 말해서 환경, 그리고 관리자의 지원이라보다 인재 운영도 많을 것 같긴 하지만

내가 AI를 쓸 때 조금 더 도움이 되더라 라는 내용이었고 개인 요인은 태도, 협업하실 행동과 같은 내용들이 있었습니다. 그래서 이런 어떤 글로벌 트렌드를 봤을 때도 충분히 3명 이상의 팀일 때 어떤 식으로 환경을 구축해야지 AI가 에이선트로서 팀에 잘 들어갔고

그것들이 잘, 팀원들이 함께 문제없이 방향이 틀리지 않고 앞으로 나아갈 수 있는지에 대한 내용을 확인할 수 있었습니다. 그랬을 때 이제, 그런 룰을 어떻게 시작할 수 있을까? 단순히 오늘 제 예시에서 제가 앞에 말씀 못 드린대요. 하나 말씀드리면

제가 오늘 개인으로 나오는 거다 보니까 제가 말씀드리는 게 네이버를 대표하거나 네이버의 공식 발언이 아니라는 점을 명실해달라고 하더라고요. 회사에서 제가 미리 말씀드립니다. 그랬을 때 오늘 이 네 가지, 그럼 저 네 가지 다섯 가지에서 너와 그렇게 했어. 그럼 나 어떻게 해야 돼? 너 이 얘기하면 끝이야?

So I think we can talk about it once a while. First of all, I wanted to make ground when I made it, and how to make it, and how to make it, and how to make it. So I wanted to share my own goals. The first was the goal. Why do we need to do this? We need to do this.

파팀과의 커뮤니케이션 기업을 줄이기 위해서 하는가, 근본적으로 개인이 이 환경을 왜 구축해야 하는가 하는 목적을 명확히 셋업을 해봤습니다. 지금 제가 듣기로 여러분들께서도 그런 프로듀크를 만들고 계시고 개인으로서 하고 계신다고 들었고 앞으로는 팀원으로 모여서 하시는 프로세스도 있다고 들었는데요.

그랬을 때 이 환경을 만약에 만들어야 한다면 왜 만들어야 되는가를 조금 곰곰이 생각해보시면 좋을 것 같습니다. 당연히 네이버에서 했다니 저사랑 했다니 아니면 마이크로소프트에서 그런 조직 환경이 중요해서 그렇다 라고 하기보다는 우리가 어떤 명확히 하나의 명제를 풀어보기

위해서 이런 환경을 만들려고 했던 것인지, 아니면 각자의 역할이 너무 다르기 때문에 혼동이 없이 우리가 하나의 목표를 정확히 보고하고 싶어서인지, 아니면 우리가 시간을 줄이기 위해서 빠르게 해야 되니 우리 기주문서는 어디에 셋업을 해놓고 이런 목적을 만들어야 되는지, 뭐 하여튼 왜 이 환경을 만들었는가에 대한 이야기를 꼭 스스로

스스로 꼭 팀원 계획이 동일해보시고 브라운드를 만드시면 좋을 것 같고요. 두 번째는 기준 조사입니다. 이거는 저도 개인 프로젝트를 이것저것 하고 친구들이랑도 장난스레 이것저것 만들어보고 하는데요. 그때 가자라 안하는 게 기준 조사예요. 나 혼자 생각하고 나 혼자 만들어서 나 혼자 공유하고 어? 야 이거 왜이래?

제가 혼자 저 메모장에 쓰고 FL 메모장 안에서만 보고 하는데 그런 것이 아니라 기준 분서를 어디에 줄 것인지 기준 분서의 트리를 P트리로 둘 것인지 아니면 무슨 트리로 줄 것인지 이런 기준 분서를 어떤 양식으로 둘 것인지에 대한 고민도 해보시면 좋을 것 같습니다. 요새는 Notion 같은 것들도 흔히 쓸 수 있고 그런 것들이 AB, GPT에서도 많이 활용할 수 있잖아요.

기준분서를 잘 확립하시고, 특이 같은 것도 잘 만들어 보시면, 에이전트가, 코드가 잘 인덱싱해서 찾아볼 수 있도록 하면 좋을 것 같습니다. 그리고 기준분서에서도 또 한가지 말씀드리고 싶었던 내용은 기준분서의 용어 소질이나 우리가 이야기하려고 하는

정의 같은 것들을 좀 정리해 두시면 좋을 것 같습니다. 예를 들면 서비스를 출시를 했을 때 '유저 수를 보고 싶다' 라고 했을 때 '우리 유저 수가 얼마예요?' 라고 말하면 저희는 항상 머릿속에 궁금증이 뜹니다. 이런 대상 있으면 일평균인가 월평균인가 아니면 일 단인가 이런 이야기들이 놓치게 되면 될수록 사람들과 내는 미스 커뮤니케이션과 큰 비용이 정말 커지거든요. 그래서 우리는 월부터 정말 빠르게 움직이 빈하게 움직이는 서비스다.

일평균으로 보겠다, 아니면은 주간 평균으로 보겠다 뭐 같은 내용들 기존문제 작성해주시고 그런 것들을 그라운드 룰에 꼭 파우치해주시면 좋을 것 같습니다. 그리고 세 번째는 절차입니다. 이거는 제가 아무래도 개발자분들이랑 디자이너 분들이랑 같이 일을 하다보니까 그 절차는 조금 중요한 것 같은데요. 저는 기획자이다 보니까 기획분을 업로드 정리를 하고 이걸 디자이너 분들과 논의를 하고 그런 시안에

and then the developers and developers are working on this. That's not that. It's a problem that suddenly comes out of the development code. Of course, we can understand it, but we haven't done design, but we don't have the interaction with each other. Or if I'm writing a code and team members have to do a code, then we're making a code.

누군가는 당황을 하게 됩니다. 그래서 에이전트와 일을 할 때 '지금 어느 절차까지, 어느 단계까지 했으면 좋겠어'를 명시라던가 아니면'그라운드 룰을 넣었다' 이런 초안을 썼을 때는 완벽한 상태 설계가 아니라 초안으로 배경과 개요, 우리가 찾고자 하는 목적 위주로 써줘 와 같은 룰을 잡았고 싶죠. 마지막으로는 완료입니다.

아까 쉽게 말씀드렸던 것처럼 완료를 그 body space에다가 작성할지 있고 있지만 AI가 하는 것과 인간이 하는 완료, 그리고 팀이 하는 완료가 다를 것 같습니다. AI가 하는 완료는 당연히 문서를 초안에 써주는 것일 것 같고요. 저는 지금 단계에서는 아직 인간이 거기를 검수를 해야 된다고 생각합니다. 그랬을 때 인간이 하는 완료까지도 파악을 했다면 다음으로 팀이 하는 완료입니다.

예를 들면 많이 해보신 적 있으시겠지만 AI를 만들다 보면은 만들었는데 갑자기 내가 이게 다른거 하자 했는데 기존 거 다시 뜯어붙이고 있다고 하잖아요. 그때는 이 업무를 우리가 완료하고 했으니 다음 프로세스를 진행할거야. 같은 완료의 지점으로 명시해주시면 좋을 것 같습니다.

Q&A를 많이 가져 보려고 제가 이 말을 엄청 빨리 해왔는데요. 몇 장 안 남았습니다. 그래서 1분 동안 먼저 만들어 보는 시간을 잠깐 가져 보자고 랩업 시간에 가지고 와 봤는데요. 여러분들께서 지금 하시고 계신 프로젝트에서 혼자 하시고 계시다고 들었지만 만약에 여기서 두세 명이 또 있겠다. 내가 CEO여서 두세 명이 또 있겠다.

If you want to make a brand new product, you can see what you can do. I think it's good for the purpose of the purpose. If you have a product, you can set your product, and you can set your product to make a brand new product. Or if you want to make a convenient way to make a brand new product, or if you want to make a brand new product, or if you want to make a brand new product, you can set your product to make a brand new product.

커운 비용을 줄이기 위해서 어떤지, 아니면 더 정확히 코드를 혹은 기획서를 더 잘 쓰고 싶은 팀인지 이런 목적을 한번 생각해 보시면 좋을 것 같습니다. 두 번째는 기준 분서를 어디에 못하시고 어떤 자료를 찾아보게 해야 된다 살펴보시면 좋을 것 같습니다. 최근 들어서 클로드 코드나

I would like to search for a agent to search for the search results. The search results are not the only one in 2024, or the latest, but the only one in the past. Our team is well-reaching. Our team will check the information in which we are looking for. We will see the information in the end of the month. We will see the information in the end of the month. If you have a question, please consider it. I'm currently working on the project and the design.

그러니까 어디까지 마무리를 하고 개발자에게 넘겼을 때 개발자가 보기 편할까? 그래서 끊금없이 여기에 개발 코드를 갑자기 넣어주면 저 개발자는 경험하지 않을까? 그러면 내 나의 절차는 어디까지인가? 그럼 에이전트화 할 때 디자인까지 만들었다는 개발 아이디어로

'이디에이션 절차까지는 안줄 수 있는가?' '또 같은 내가 개발하는 사람이라면' '단순히 html 만들어서 하다 해피해주세요'라고 하면 분명히 디지되는 분들은 가과하셨고 그게 당연히 잘 만들기 어려운 상태일 거고 협의가 되지 않았습니까?

이럴 때 html도 어느 정도의 피드레이지로 만들 것인가 그런 절차들을 한번 고민해보시면 좋을 것 같고요. 마지막으로는 아까 말씀드린 것처럼 A&M은 거짓가 되었고 최종 반영이나 대포 전에는 내가 무엇을 꼭 확인할 것인가에 대한 대안을 스스로 검색해보시면 좋을 것 같습니다.

어떤 칩을 넣을 수가 있어요. 그래서 이 보기에 빨간색으로 검포 비디오 깎고 넣을 때까지 그럼 이게 자연스럽게 문서를 쓱 내리다가 대충 보고'오케이, 던지자' 아니라'아, 얘가 이건 진짜 봐야 된다고 판단을 하는구나' 라는 것들을 표현하게 해놨어요. 그런 것들을 매니아에게 줄 수 있는 것과 같은 내용들을 이제 한번 생각해보시면 좋을 것 같습니다. 이제 마지막 장인데요.

맨 앞에 제가'AI 시대의 기획자는 무엇을 설계하는가?' 라는 질문을 던져봤잖아요. 그랬을 때 AI 시대의 기획자의 개인 프론트는 한 사람을 빠르게 할 수 있는 것 같습니다. 그런데 지금 얘기했던 것처럼 팀원들과 함께 이야기할 때는 결국에 한 사람만 빠르지 우리 팀 자체가 빠르게 진행가야 되는 부분이 있는 것 같습니다. 그래서 기획자는 팀의 편드주를 만들어서 모두를 같은 방에 빠르게 만드는 다시 말해서 좋은 판단이 반복되는 구조를 만드는 사람이라고 저는 생각을 못했습니다. 원래 한 40.

최근에 45분 정도, 조금 말을 빨리해서 35분까지 온 것 같습니다. 그래서 지금부터 Q&A를 빠르게 하면서 제가 10분, 20분 정도 시간을 보낼 수 있을 것 같거든요. 그래서 한 번. 그때까지 질문이 없을 수도 있지만, 한 번 질문을 소화해보도록 하겠습니다. 제가 띄게요.

먼저 세션 준비해주신 기준님께 저희 강차의 박수를 한 번. 저희가 공지사항 채널에 슬라이더 링크를 올려드렸어요. 그거랑 접속이 혹시 어려우신 분들은 저희 현장에서 마이크로 질문을 받고 있으니까 여기 질문이 먼저 올라온 걸 한번 보도록 하겠습니다.

익준님이 먼저 해주고 싶은 질문을 골라주실 수 있어요? 아 그러면은 최신순으로 빠르게 하나하나 치고 가겠습니다. 시간이 제가 한 20분을 뽑아서 왔는데 맞아요. 지금 창출 분인데 한 15분 정도 시간이 있을 것 같습니다. 네. 일단 첫 번째 질문이 요즘 같은 시대에 PM, PO 직무로 입사하고 싶은 주니어 신입분들은 무엇을 준비하고 어떤 영향을 쌓아가야 할까요? 네, 정말 어려운 질문인 것 같은데

우선은 제가 사실 최근 입사자가 다녀서 LEI가 없을 때 입사를 해서 최근에 어떤 것을 많이 보신지 모르겠어요. 근데 제가 최근에 팀을 옮기려고 면접을 보고 합격을 해서 네이버 안에서 팀을 옮기게 되었거든요. 조금 행복하게도. 그때 많이 이야기를 남아온 건 게 방금 말씀드렸던 저 강연에 대한 골자들이었던 것 같아요.

그래서 너가 기획자로서, 아니면 PM으로서 어떤 걸 노력했어? 그때 AI를 어떻게 활용했어? 저는 팀에 어떤 문서를 작성하게 할 때 어떤 문서를 인덱싱하게 했고 그 문서에서 필요한 양식들은 따로 제가 정리해서 그 스킬을 녹이려고 했습니다. 그 문서를 통해서, AI를 통해서 잘하게 하려고 했는가? 그냥 단순히 AI로 뭐 해줘, 백각해서'저거 만들었어요' 뭐와 같이 겉만 하는 게 아니라 진짜 뼈대를 만들어 볼 수 있는 사람인가? 에 대한 이야기를 많이 했고,

합격하면 왜 합격했는지 써주시거든요. 그런 내용이 되셨겠던 것 같습니다. 두 번째로는 AI를 활용하며 기획과정에서 달라진 점 중 가장 인상깊었던 과정이 있을까요? 있습니다. 뭐냐면 저는 아까 말씀드렸지만 원래 제 직업이 드라마에서 컨셉아트하는 작가였습니다.

화분이랑 경이로운 소문을 보셨는지 모르겠지만 거기에 나오는 씬을 제가 디자인해서 그런 어떤 색감이나 포징이나 카메라 컷 같은 걸 제가 잡았었는데요. 그런 곳에서 네이버에 들어오다 보니까 IT, 개발 지식, 테크 지식이 단 하나는 없는 거예요. IT가 아니라'I'인 거예요.

그래서 너무 힘들었고 1년, 2년 동안 너무 고통스럽습니다. 심지어 어느 수준이었냐면 API가 뭔지 몰라서 검색해봤는데 인터베이스더라고요. 디자이너 분은 계신지 모르겠지만 디자이너에게 인터베이스란 화면이에요. 그래서 이거를 개발자로 어쩌라는 건지 그런 거고 주문서라는 거예요.

뭘 주문한다는 것이 할 정도였었는데 AI가 클로드코드가 들어오다 보니까 그런 개발적인 문제를 해소하기가 너무 좋더라고요. 예를 들면 이 화면이 어떤 로직으로 노출되지? 아~ 해서 물어보고 이때 개발 코드를 찾아볼 수 있으면 꼭 찾아봐서

왜 노출할지 알려줘. 거기에 파라미터 값들이 쫙 있을 거에요. 아 그러면 이 상황에서 노출이 되고 이 상황에서 미노출이 되구나. 같이 개발 회자분들이 코드로스 마크들을 자연으로 익히면서 기획 쓰고 소통을 할 수 있는게 좀 많이 달라지죠. 엄청난. 이렇게 되면 장점이 제가 스펙을 쓸 때도 좀 더 자세하게 쓸 수 있구요.

디자이너 분들에게도 구체적으로 요청할 수 있고요. 개발자분들도 문제점을 덜 물어보시는 상황이 됩니다. 세 번째입니다. 질문이 많으세요. 빨리 하겠습니다. PMPO는 심리치료는 잘하지 않는 것을 알고 있습니다. 많은 경험이 여인 때문이라고 생각하는데요.

채용과정이 달라진 점이 어떤 것인가요? 근데 이거는 제가 이해하기로는 뽑는 곳은 토스밖에 없는 것 같습니다. 왜냐면 저도 이것저것을 많이 알아봤지만 이 직군에 뽑는 것은 신입을 뽑는 곳은 토스밖에 없던 것 같은데 제가 회사에 있어보면 왜 그럴 수밖에 없는가 하면 그 핸들링에는 너무 많습니다. 일단 일정도 일정이고 각 팀의 어떤 정도의 역량이 있는지

어떤 정도의 팀이 버튼이 되는지, 핸들링을 할 수 있는지, 이런 것들을 모두 인지를 하고 있을 거야. 그 팀 전체를 스펙을 만들 수 있는 거에요. 그러다 보니까 PMPO 신입을 채용하지 않는 거, 못하는 거 같아요. 조금 끊어지는 여기에 다른 질문인 거 같은데, 그래서 PMPO로 입수하면

대결 뿐만 아니라 큰 규모가 있는 팀이기 전에 자기가 작은 소규모 팀이든 동아리 활동이든 캠프 활동이든 해서 내가 이런 것들을 핸들리를 해봤다. 일정관리나 팀의 역량관리나 스펙들에 대해서 방향성을 잘 조율할 수 있다.

경험들을 인정받을 수 있을 것 같습니다. 요거는 아까부터 말씀드린 것 같아서 채용과정까지는 그렇게 밝게 하실 것이라서 패스하겠습니다. 다음은 DL 단계에서 AI를 가장 많이 활용하는 단계가 있을까요? 일단 생각보다

최초 아이디에이션 때는 활용하지 못하는 것 같습니다. 활용을 하려고 해도, 오토 아시겠지만 그럴싸한 단어를 조합해서 말해주셨잖아요. 그럴싸한 단어는 가장 패키적이지 않습니다. 가장 그럴싸하고 누구나 생각할 수 있고 내가 지금 몰라서 그걸 너한테 월마다 얼마씩 주고 물어보는 거야? 라고 생각하는 수준이기 때문에 그래서 초안 단계에서는 정확히 명확히 짚어줍니다. 어떤 목적이 있고 배경이 있으니 이러한 방향성과 이러한 의도를 담아서 해줘 라고 생각하고 가장 많이 활용하는 단계는 정리하는 단계입니다. 어느 수준이이냐면 진짜 알아보게 말해야 되지 모르겠지만 일하기 싫을 때 위험한 거 뽑아놓고, 음성품을 넣어놓고, 바닷어 좀 하고 눈 감고 이렇게

기대가지고 계속 말을 하거든요. 이 스택을 표로 정리해줘. 하면 해줍니다. 그거를 지금 들어가서 볼 수 있습니다. 그리고 이제 클로드 코드가 코덱스가 라이브 대화를 데스크톱에서 지원을 하거든요. 그래서 데스크톱에 켜놓고 혼자 AI라는 기획 스펙 사항을 하는 여기서 너가 엣지게이지라고 생각하는 법을 더 봐.

이제'어? 이준님 이런 것들이 고려가 안 돼 있는다' 그렇게 고려하시나요? '그거는 고려한 게 아니야' 아니면'이렇게 고려해 놨으니까 업데이트해줘' 그런 식으로 요새는 좀 쉬운데요. 열심히 일하고 있어요. 이 사회에서는 어떤 식으로 AI를 살려 하고 있나요?

현재는 코덱스랑 클로즈 코드를 활용하고 있고요. 그 외에도 전반적으로 여러 팀들에서 너무 다양하게 활용하고 있어서 제가 대표적으로 말씀드리기는 어려운 것 같고 여러분들이 하시고 싶은 것들을 다 하고 있다. 좋은 업무 환경이다. 그렇게 생각하시면 좋을 것 같습니다. 기준님께서는 어떤 동료와 주니어와 함께 일하고 싶으신가요? 옆 팀에 제가 지금 4년차 시작했거든요. 마지막 3년차. 옆 팀에 2년차 1년차 모두 계세요.

그분이 저보다 일을 더 잘 하시거든요. 근데 왜 잘한다고 생각하고 그분을 말씀을 드리냐면 정말 로깅이나 뭔가 공부한 게 있으면 사내의 위키리에 자기의 틀이가 나타나지겠습니다. 그러면 저도 보면서 배웠고 또 그렇게 해놔야 이제 모두가 아시겠지만 AI에 대한 데이터가 있어요.

제가 머릿속으로'아 그럴거야''내 책이 친구 그러겠지''OK''이게 아니고''이게 아니고' 그래서 그렇게 잘 로깅을 하고 기록을 남기고 문서화를 잘 하시는 분들과 일하고 싶다. 그래서 그분들이랑 일하는 피난지가 있고 그분이 안 계셔도 크로스코드한테 물어봐서 그분의 문을 내다 빨리 스틱크할 수 있습니다.

그 이야기 본질이었던 것 같은데 저는 점차 개발자분들도 실직을 하시고 저도 실직을 하고 디자인은 좀 실직을 할 거라고 생각을 합니다. 그런 그 사이에서 남는 거는 그 사람들을 실직하지 않은 주요 인물들을 연결해주는 이런 그물만들을 잘 만드는 게 PMPO 기획자의 업무라고 생각을 하거든요. 그래서 요새 불나나 아니면 직접 커뮤니티나 이곳저곳에 돌아다니면서 이런 AI나 이런 이야기들을 보면서

We have a lot of struggle with the development of design and design. It's a lot of difficult situations. It's a lot of difficult situations. It's a lot of difficult situations. It's a lot of difficult situations. I've always had a lot of difficult situations.

I thought about it and thought about it. Product Designer's task. Now, we have a product designer and a place designer. Product designer is a product designer. The product designer is a product designer.

설계라고 하면 디자인이 있고요. 네이버에서는 디자인을 설계라는 거예요. 그리고 최근 들어서는 크로즈 코드나 기회 같은 것도 많이 쉬워지니까 크로즈 디자이너 분들께서 초기 스펙을 구상해서 디자인을 해서 저희에게 주시는 세부 스펙을 나누기도 합니다.

이렇게 된 이유는요. 디자이너분들이 모든 스펙의 정책이나 개발 현황이나 코드 같은 것들을 알 수 있는 어려운 사람들이 많았고요. 그래서 그런 것들을 동의한 기획자가 있고 디자이너는 디자인을 하는 그런 룰을 분담해서 맡아졌고 최근 들어서는 조금씩 조금씩 서로의 영역들을

침범하고 있지만 그래도 각자의 역할입니다.