chore(wiki): Topics/Thinking 신설 (Reasoning ADR 3건) + 회의록 a/b/e wiki화 + YouTube 1건
- 10_Wiki/Topics/Thinking/ — ASTRA 추론·메모리·검색 강화 논의 3개 ADR (제2뇌 추론 단계, 기억 관리 시스템화, 지식 발굴 의미 연결성) - 10_Wiki/Topics_meeting/ — 회의록 a (롯데월드 이머시브) / b (스포티앤리치 개선) / e (Net 이슈대응) - 00_Raw/_youtube/ — "AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀" 분석 + transcript - 00_Raw/ — 회의록 e 원본 - chronicle 자동 갱신 (architecture, scan-cache, timeline)
This commit is contained in:
File diff suppressed because one or more lines are too long
@@ -0,0 +1,744 @@
|
||||
제목: AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀
|
||||
영상: https://www.youtube.com/watch?v=Qu4X0auqnqA
|
||||
비디오 ID: Qu4X0auqnqA
|
||||
언어 우선순위: ko, en
|
||||
세그먼트: 737개
|
||||
------------------------------------------------------------
|
||||
|
||||
회사 팀 차원에서 AI를 활용하는
|
||||
가장 좋은 방법은 뭘까요? 왜 기존
|
||||
회사들은 AI 시대에 뒤쳐질 수밖에
|
||||
없을까요? 그리고 왜 지금이 작은
|
||||
스타트업이 거대 기업을 이길 수 있는
|
||||
역사적 기회일까요? 다이에나 후는
|
||||
세계 최고의 스타트업 엑셀러레이터,
|
||||
와이 콤비네이터의 파트너입니다.
|
||||
그녀가 지금 몇 달 사이에 목격한
|
||||
아주 놀라운 현상에 대해 이야기하려고
|
||||
나섰습니다. 만약 당신이 창업자거나
|
||||
팀을 이끄는 사람이거나 혹은 조금 전
|
||||
질문의 답이 궁금하시다면 꼭 끝까지
|
||||
들어보세요. 저는 보충 설명과 내용
|
||||
정리로 여러분의 이해를 도와드릴게요.
|
||||
Hi, I'm Diana and
|
||||
I'm a partner at YC.
|
||||
Over the past few
|
||||
months, it's become
|
||||
clear to me that AI
|
||||
is not just going to
|
||||
change how quickly
|
||||
software gets built
|
||||
or what workflows
|
||||
get automated. It's
|
||||
going to
|
||||
fundamentally change
|
||||
the way startup
|
||||
should be run from
|
||||
what rules will
|
||||
exist to what
|
||||
products are
|
||||
possible to build.
|
||||
In this episode, I'm
|
||||
going to discuss how
|
||||
founders should
|
||||
think about building
|
||||
an AI native
|
||||
company, what roles
|
||||
their team should
|
||||
have, and what
|
||||
concrete internal
|
||||
practices they can
|
||||
adopt right now to
|
||||
move much faster.
|
||||
Currently, most
|
||||
people talk about AI
|
||||
in terms of
|
||||
productivity.
|
||||
They'll talk at
|
||||
length about how it
|
||||
can make engineers
|
||||
more productive or
|
||||
say we need to add
|
||||
copilot to existing
|
||||
workflows and ship
|
||||
more features. This
|
||||
framing misses the
|
||||
shift we're
|
||||
currently seeing
|
||||
which is less about
|
||||
productivity booths
|
||||
than entirely a new
|
||||
capabilities. The
|
||||
right person with AI
|
||||
tools can now build
|
||||
features that used
|
||||
to require an entire
|
||||
team or were just
|
||||
impossible. Thinking
|
||||
about AI in terms of
|
||||
new capabilities has
|
||||
several implications
|
||||
for how founders
|
||||
should run their
|
||||
companies. At a high
|
||||
level, the way to
|
||||
think about AI is
|
||||
that should not be a
|
||||
tool your company
|
||||
just uses. It should
|
||||
be the operating
|
||||
company runs on.
|
||||
Yor은 유수의 회사들을 초기에
|
||||
키워낸 세계에서 가장 영향력 있는
|
||||
벤처 캐피털이에요. 2005년 폴
|
||||
그레이엄이 설립했고 오픈 AI의
|
||||
샘트먼이 약 5년 정도 사장직을
|
||||
여임했죠. YC 파트너라는 자리는
|
||||
매년 수백개 회사가 어떻게 성공하고
|
||||
실패하는지를 가장 가까이 있어
|
||||
지켜보는 위치입니다. 따라서 AI는
|
||||
도구가 아니라 운영 체제가 되어야
|
||||
한다는이에나의 주장은 최근 실제로
|
||||
빠르게 성장하는 회사들에서 공통적으로
|
||||
관찰된 패턴이라는 점에서 무게가
|
||||
실리죠. 참고로 다이에나 본인도
|
||||
엔지니어 출신이고요. 포켓몬 고를
|
||||
만든 회사 나이엔틱에서 AIAR AR
|
||||
분야를 이끈 경력이 있습니다. 어떤
|
||||
이야기를 하는지 더 들어보시죠.
|
||||
workfow, every
|
||||
decision and every
|
||||
process should flow
|
||||
through an
|
||||
intelligent layer
|
||||
that is constantly
|
||||
learning and
|
||||
improving. What this
|
||||
means concretely is
|
||||
every important
|
||||
process in your
|
||||
company should be
|
||||
captured by an
|
||||
intelligent close
|
||||
loop. A close loop
|
||||
captures
|
||||
inflammation, feeds
|
||||
it back into an
|
||||
intelligence
|
||||
systems, and improve
|
||||
the process over
|
||||
time. If you've ever
|
||||
studied control
|
||||
systems, you will be
|
||||
familiar with the
|
||||
difference between
|
||||
an open loop and a
|
||||
close loop system.
|
||||
Open loops are
|
||||
control systems
|
||||
without feedback
|
||||
loops. In the old
|
||||
world, companies
|
||||
basically ran as
|
||||
open loops. You made
|
||||
a decision, executed
|
||||
it, and didn't
|
||||
always
|
||||
systematically
|
||||
measure the outcome
|
||||
and adjust the
|
||||
process. Open loops
|
||||
are inherently
|
||||
lossy. A close loop,
|
||||
on the other hand,
|
||||
is self-regulating.
|
||||
It continuously
|
||||
monitors its output
|
||||
and adjusts its
|
||||
process to better
|
||||
meet the stated
|
||||
goal. Close loops
|
||||
are extremely
|
||||
powerful for
|
||||
correctness and
|
||||
stability with ag
|
||||
개방 폐쇄루프에 대한 이야기가
|
||||
나왔는데요. 이걸 이해하는 가장 쉬운
|
||||
비유는 요리인 것 같습니다. 개방
|
||||
루프는 레시피만 보고 요리하는
|
||||
방식이에요. 물m, 뭐 간장 두
|
||||
스푼, 10분 끓이기 적힌 대로만
|
||||
요리하고 중간에 맛을 보지 않습니다.
|
||||
음식이 짠지 싱거운지 미리 알 수
|
||||
없죠. 반면 폐쇄 루프는 중간중간
|
||||
간을 보면서 요리하는 방식이에요.
|
||||
끓이다가 한번 맛보고 싱거우면 소금을
|
||||
더 넣고 다시 맛보고 이렇게 결과를
|
||||
측정하고 조정하는 행위를 반복합니다.
|
||||
에어컨도 그렇죠. 설정 온도에
|
||||
도달했는지 계속 측정하면서 에어컨
|
||||
스스로 더우면 더 강하게 그리고
|
||||
시원해지면 약하게 자동 조절하죠.
|
||||
이런게 폐쇄 루프입니다. 다이에나가
|
||||
말하는 핵심은 이겁니다. 기존
|
||||
회사들은 회의, 결정, 실행으로
|
||||
끝나고 그 결과가 좋았는지 나빴는지
|
||||
체계적으로 확인하지 않습니다.
|
||||
체계적으로라는 말이 중요한데 결과를
|
||||
확인하고 반영하고자 하는 의지가
|
||||
있다고 해도 기존의 운영 체제가 이걸
|
||||
받쳐 주지 못합니다. 반면 AI
|
||||
네이티브 회사는 실행부터 결과 분석
|
||||
그다음 결정까지 체계적이고 근본적으로
|
||||
가능합니다. 속도도 빠르고 정확도도
|
||||
높죠. these close
|
||||
loops you will need
|
||||
to make your entire
|
||||
company queryable in
|
||||
other words the
|
||||
whole organization
|
||||
should be legible to
|
||||
AI every important
|
||||
action should
|
||||
produce an artifact
|
||||
that the
|
||||
intelligence at the
|
||||
center of the
|
||||
company can learn
|
||||
from and use to
|
||||
self-improve this
|
||||
means recording your
|
||||
meetings with a AI
|
||||
notaker, minimizing
|
||||
DMs and emails, and
|
||||
embedding agents
|
||||
throughout
|
||||
communication of all
|
||||
channels. It also
|
||||
means building
|
||||
custom dash with
|
||||
everything in the
|
||||
company. revenue,
|
||||
sales, engineering,
|
||||
hiring, ops,
|
||||
everything. Here's a
|
||||
concrete example of
|
||||
how it could work.
|
||||
Take engineering,
|
||||
management, and
|
||||
sprint planning. If
|
||||
you have an agent
|
||||
that has access to
|
||||
your linear tickets,
|
||||
all your Slack
|
||||
engineering
|
||||
channels, all
|
||||
customer feedback
|
||||
from emails or tools
|
||||
like PIN and GitHub,
|
||||
highlevel plans in a
|
||||
notion or Google
|
||||
doc, sales calls and
|
||||
recordings from
|
||||
daily standups, then
|
||||
the agent can
|
||||
analyze what was
|
||||
actually shipped in
|
||||
your previous print
|
||||
and how well they
|
||||
met customers needs
|
||||
for real. From
|
||||
there, you can go a
|
||||
step further with
|
||||
full visibility into
|
||||
what shipped, what
|
||||
worked and what
|
||||
didn't. Agents can
|
||||
start looking ahead.
|
||||
They can propose
|
||||
sprint plans for
|
||||
engineers that are
|
||||
way more predictable
|
||||
and accurate and on
|
||||
track. The days of
|
||||
manager status
|
||||
rollups that are
|
||||
super lossy are
|
||||
gone. Having managed
|
||||
engineering teas
|
||||
myself and now
|
||||
seeing this across
|
||||
multiple YC
|
||||
companies, this is a
|
||||
game changer. What
|
||||
used to require
|
||||
constant
|
||||
coordination becomes
|
||||
legible and querable
|
||||
by default. I've
|
||||
seen teams that do
|
||||
this cut their
|
||||
engineering sprint
|
||||
time in half and get
|
||||
close to 10x more
|
||||
than in that time.
|
||||
The overarching
|
||||
principle here is
|
||||
that to get their
|
||||
full capabilities,
|
||||
you need to provide
|
||||
models with as much
|
||||
context as you would
|
||||
provide an employee.
|
||||
When you do this,
|
||||
your company stops
|
||||
operating as a open
|
||||
loop where
|
||||
information is
|
||||
fragmented and
|
||||
manually
|
||||
interpreted. It
|
||||
becomes instead a
|
||||
close loop system.
|
||||
Status, decisions
|
||||
and outcomes are
|
||||
continuously
|
||||
captured and fed
|
||||
back into this
|
||||
intelligence layer.
|
||||
The result is a
|
||||
system that has an
|
||||
update view of리는
|
||||
데이터베이스에 질문한다라는 뜻인데요.
|
||||
다이에나가 말한 AI 네이티브 운영
|
||||
체제가 작동한다면 데이터베이스가
|
||||
아니라 AI에게 질문함으로써 서비스에
|
||||
대한 모든 답이 나오는 상태가 되는
|
||||
거겠죠. 뭐 예를 들어 지난달 우리
|
||||
고객들이 가장 많이 불평한 문제 세
|
||||
가지가 뭔가? 이번 분기에 영업 팀이
|
||||
어떤 기능을 가장 많이 요청받았는가?
|
||||
지난 6개월간 우리 회사가 내린 결정
|
||||
중에 실패한 것의 공통점은 무엇인가?
|
||||
다음 업데이트 때 반드시 넣어야 하는
|
||||
기능은 이런 질문을 누구나 할 수
|
||||
있고 누구에게나 정확도가 높은 응답이
|
||||
돌아옵니다. 현재 이런 시스템이 잘
|
||||
거쳐지지 않는 이유는 회사의 정보가
|
||||
여기저기 흩어져 있기 때문이고요.이를
|
||||
사람이 이어주고 전달해 주는 방식은
|
||||
정보 전달에 누수가 생길 수밖에
|
||||
없어요. 주요 정보가 오가하는 회의는
|
||||
반드시 전부 데이터화해야 한다고
|
||||
말하고 중요한 정보가 오가지만 정보가
|
||||
공유되지도 않고 쌓이지도 않는
|
||||
다이렉트 메시지나 산의 이메일은
|
||||
최소한으로 사용하라는 팁도 중요한 것
|
||||
같습니다. 메신저 메시지나 구두로
|
||||
중요 정보가 오가는 바람에 특정
|
||||
관리자와 친하지 않으면 정보와
|
||||
멀어지는 상황. 회사를 다녀본 분들은
|
||||
한 번쯤 경험하시거나 목격하셨을
|
||||
거예요. DM으로 업무 지시를 받고
|
||||
구두로 회의 결론을 내고 결정 과정을
|
||||
문서로 남기지 않는 문화. 저는
|
||||
스타트업에서도 많이 보고 들었습니다.
|
||||
이런 관행은 AI 시대에는 큰 약점이
|
||||
됩니다. AI가 학습할 수 있는
|
||||
데이터가 남지 않기 때문이죠.
|
||||
product AI software
|
||||
factories. If you're
|
||||
familiar with the
|
||||
test driven
|
||||
development or TDD,
|
||||
this is the next
|
||||
evolution of that.
|
||||
With software
|
||||
factories, humans
|
||||
right aspect and a
|
||||
set of tests that
|
||||
define success. And
|
||||
then AI agents
|
||||
generate the
|
||||
implementation
|
||||
and code and iterate
|
||||
until the test pass.
|
||||
The human defines
|
||||
what to build and
|
||||
judges the output.
|
||||
The actual code is
|
||||
the agent job. Some
|
||||
companies have
|
||||
already pushed this
|
||||
to the point where
|
||||
the repost contain
|
||||
no handwritten code,
|
||||
just specs and test
|
||||
hardnesses. Strong
|
||||
DMs AI team is an
|
||||
example of how to do
|
||||
this. Their end goal
|
||||
was a system that
|
||||
essentially
|
||||
eliminated the need
|
||||
for a human to write
|
||||
or review code. And
|
||||
so they build their
|
||||
own software factory
|
||||
where specs and
|
||||
scenario based
|
||||
validations drive
|
||||
agents to write test
|
||||
and iterate and code
|
||||
until it meets a
|
||||
probabilistic
|
||||
satisfaction
|
||||
thresold and it
|
||||
works. This is how
|
||||
you achieve thex
|
||||
engineer that Steve
|
||||
talked about by
|
||||
surrounding a single
|
||||
engineer with a
|
||||
system of agents
|
||||
that enable them to
|
||||
build things they
|
||||
would have never
|
||||
been able to build
|
||||
before. The era of
|
||||
10,000 X engineer is
|
||||
here.
|
||||
>> AI 소프트웨어 팩토리와 기존 회사의
|
||||
차이를 좀 더 쉽게 이야기해 보면요.
|
||||
기존 방식은 건축가가 설계도를 그리고
|
||||
인부들이 직접 벽돌를 쌓아서 집을
|
||||
짓는 방식이라면 AI 소프트웨어
|
||||
팩토리에서는
|
||||
건축가가이 집은 침실 세 개, 화장실
|
||||
두 개 무너지지 않아야 하고 단열이
|
||||
잘 되어야 한다. 이런 요구 사항과
|
||||
어 합격 기준만 작성합니다. 그러면
|
||||
로봇 인부들이 알아서 집을 짓고 또
|
||||
테스트도 하고 통과할 때까지
|
||||
자기들끼리 고치고 짓는 걸 반복하죠.
|
||||
중간 피드백, 최종 검수 이런
|
||||
절차까지도 사라지겠죠. td라는 말은
|
||||
간단히 말씀을 드리면 코드를 짜기
|
||||
전에 합격 기준을 먼저 정하는
|
||||
방식인데요. 시험 문제를 먼저 만들어
|
||||
놓고 그 시험을 통과하는 답안을
|
||||
나중에 작성하는 것과 비슷합니다.
|
||||
단, td에서는 그 답안을 사람이
|
||||
쓰는데 AI 소프트웨어 팩토리는
|
||||
사람은 시어 문제, 즉 스펙과
|
||||
테스트까지만 만들고 답안을 쓰는 건
|
||||
AI 에이전트가 맞습니다. 요약하면
|
||||
소프트웨어 팩토리는 사람은 무엇을
|
||||
만들지만 결정하고 AI는 어떻게
|
||||
만들지를 알아서 처리하는 분업입니다.
|
||||
심지어 사람이 다음에 무엇을 만들지
|
||||
결정할 때 도움이 될 만한 분석
|
||||
자료와 정보들까지 제공해 주겠죠.
|
||||
꿈만 같은 일처럼 들리지만 이미
|
||||
도입되고 있고 가능한 일입니다.
|
||||
In the new world,
|
||||
the intelligence
|
||||
layer serves that
|
||||
purpose. If your
|
||||
company is
|
||||
queryable, artifact
|
||||
rich and legible to
|
||||
an AI, you should
|
||||
have almost no human
|
||||
middleware. This
|
||||
matters because your
|
||||
company's velocities
|
||||
is only as fast as
|
||||
its information
|
||||
flow. Every layer of
|
||||
human routing you
|
||||
can remove is a
|
||||
direct speed gain. A
|
||||
great example is
|
||||
what Jack Dory is
|
||||
doing over at block.
|
||||
After going deep on
|
||||
the tools, he's come
|
||||
to the same
|
||||
conclusion many
|
||||
half. This is about
|
||||
more than just
|
||||
incremental
|
||||
productivity gains.
|
||||
His view is that if
|
||||
you keep the same
|
||||
org chart and
|
||||
management
|
||||
structure, you miss
|
||||
the shift entirely.
|
||||
The company itself
|
||||
has to be rebuilt as
|
||||
an intelligence
|
||||
layer with humans at
|
||||
the edge guiding it
|
||||
rather than routing
|
||||
information through
|
||||
it. Going forward,
|
||||
Jack suggests every
|
||||
company will have
|
||||
three employee
|
||||
archetypes. The
|
||||
first is the
|
||||
individual
|
||||
contributor or IC.
|
||||
Basically the
|
||||
builder operator.
|
||||
This is someone who
|
||||
directly makes and
|
||||
runs things. In an
|
||||
AI native company
|
||||
this is not limited
|
||||
to engineers.
|
||||
Everyone builts,
|
||||
ops, support sales.
|
||||
Everyone comes to
|
||||
meetings with
|
||||
working prototypes,
|
||||
not pitch. Second is
|
||||
the DRI, the
|
||||
directly responsible
|
||||
individual. Focus on
|
||||
strategy and
|
||||
customer outcomes.
|
||||
This is not a
|
||||
classic manager is
|
||||
the person with a
|
||||
clear responsibility
|
||||
for the result. One
|
||||
person, one outcome,
|
||||
no hiding. The third
|
||||
is the AI founder
|
||||
type. This person
|
||||
still builds, still
|
||||
coaches and leads by
|
||||
example. If you're
|
||||
the founder, this
|
||||
needs to be you at
|
||||
the forefront.
|
||||
showing your team
|
||||
what massive
|
||||
capability gains
|
||||
look like. Not
|
||||
delicating your AI
|
||||
strategy to someone
|
||||
else. With this
|
||||
structure, companies
|
||||
will be able to get
|
||||
outsized results
|
||||
with much smaller
|
||||
teams. Maximizing
|
||||
token usage not head
|
||||
count will be the
|
||||
critical shift. The
|
||||
best companies will
|
||||
be the ones that are
|
||||
maxing. 잭도시가 누구냐면요
|
||||
지금은 X죠. 트위터의 공동
|
||||
창업자이자 결제회사 블록의
|
||||
CEO인데요. 실리콘 밸리에서 가장
|
||||
영향력이 있는 창업자 중에 한
|
||||
명입니다. 블록은 미국의 카드 결제
|
||||
서비스, 송금앱 등을 운영하고
|
||||
있어요. 즉 도시는 2024년
|
||||
경부터이 블록의 조직 구조를 과감하게
|
||||
뜯어친 것으로 화자가 됐습니다. 중간
|
||||
관리자가 너무 많다면서 매니저 직급을
|
||||
대거 주렸고 직접 만들고 실행하는
|
||||
사람들 중심으로 팀을 재편한 거죠.
|
||||
어, 다시 보니까이 세 가지 유형
|
||||
중에 하나에 속한다는 개념이라기보다
|
||||
복수의 유형을 한 사람이 겸할 수
|
||||
있는 속성의 개념인 것 같습니다.
|
||||
내가 100% 책임을 져야 하는 담당
|
||||
지표, 업무 이런게 있고요.이를 위해
|
||||
AI 도구를 능통하게 쓰면서 필요할
|
||||
땐 직접 제품이나 도구를 만드는
|
||||
사람, 포지션을 불문하고 최고의
|
||||
직원이 되겠죠. 이런 직원을 원한다면
|
||||
AI 운영 체제를 세팅하는 것은
|
||||
기본이고 정보를 전달하는 중간
|
||||
관리자를 없애거나 최소화하는 것도
|
||||
필수적으로 동반되어야 될 것 같아요.
|
||||
중간 관리자의 존재는 책임이 분산되는
|
||||
체계이자 작업자가 자기 미션을
|
||||
달성하기 위한 정보를 100% 얻기
|
||||
어려운 체계의 방증입니다. 참고로
|
||||
크랙 팀에서는 팀 내에서 필요한 여러
|
||||
가지 도구들을 AI로 그때그때 빠르게
|
||||
만들어 주는 전단 포지션이 있다고
|
||||
합니다. 예전에는 개발자한테 어떤
|
||||
고객 데이터를 모아서 달라고 요청하면
|
||||
뭐 하루 이틀 뒤에 엑셀 파일로 주는
|
||||
방식이었죠. 대부분. 그런데 이제는
|
||||
개발자가 아니어도 궁금한 고객
|
||||
데이터를 마음껏 물어볼 수 있는
|
||||
간단한 프로그램을 하루 이틀 기다리지
|
||||
않아도 이용할 수 있다는 겁니다. 잭
|
||||
도시가 말한 세 가지 유형의 팀원들만
|
||||
남도록 체질 개선을 하는 것이 너무
|
||||
무리인 것 같다면 중간 단계로 시도해
|
||||
볼 만한 방법인 것 같습니다.
|
||||
Think of the tradeof
|
||||
this way. One person
|
||||
with AI tools can be
|
||||
the equivalent of
|
||||
what used to take a
|
||||
large engineering
|
||||
team at a pre
|
||||
company. That means
|
||||
grammatically
|
||||
engineering, design,
|
||||
HR and admin teams.
|
||||
And so you should be
|
||||
willing to run an
|
||||
uncomfortably high
|
||||
API bill because
|
||||
it's replacing what
|
||||
would have taken a
|
||||
far more expensive
|
||||
and inflated head
|
||||
count. But don't
|
||||
just take my word
|
||||
for any of this. You
|
||||
cannot outsource
|
||||
your conviction on
|
||||
the power of these
|
||||
tools. You need to
|
||||
develop it yourself
|
||||
by actually sitting
|
||||
with coding agents
|
||||
and using them until
|
||||
you start to break
|
||||
your own priors
|
||||
about what is now
|
||||
possible to build.
|
||||
If you are an early
|
||||
stage founder, you
|
||||
have a huge
|
||||
advantage in getting
|
||||
ahead on this. You
|
||||
don't have legacy
|
||||
systems, interest or
|
||||
charts or thousands
|
||||
of people to
|
||||
retrain. You are
|
||||
small enough to
|
||||
build your company
|
||||
right from day one.
|
||||
The opposite is the
|
||||
case for existing
|
||||
companies. They have
|
||||
to maintain and grow
|
||||
a live product while
|
||||
unwinding years of
|
||||
standard operating
|
||||
procedures and core
|
||||
assumptions about
|
||||
how software gets
|
||||
built. Some
|
||||
companies can
|
||||
achieve this by
|
||||
spinning up small
|
||||
internal scunkw
|
||||
teams that can build
|
||||
AI native systems
|
||||
from scratch
|
||||
separate from the
|
||||
core business.
|
||||
Mutney is a great
|
||||
example of this but
|
||||
for most every
|
||||
change to their core
|
||||
processes risk
|
||||
breaking something
|
||||
that already works.
|
||||
So by their nature
|
||||
these large
|
||||
companies will have
|
||||
a much harder time
|
||||
going AI native.
|
||||
Startups don't have
|
||||
that constraint and
|
||||
that's a major edge
|
||||
to take advantage
|
||||
of. You can design
|
||||
your system workfows
|
||||
and culture around
|
||||
AI from the start
|
||||
and as a result
|
||||
operate
|
||||
다이에나는 제로베이스에서 AI
|
||||
네이티브 운영 체제를 세팅할 수 있는
|
||||
스타트업에게 유리한 판이라는 것을
|
||||
강조하면서도 기존 회사에게도
|
||||
아이디어를 주고 있어요. 먼저 스크
|
||||
웍스란 말이 나왔는데요. 회사 본부의
|
||||
복잡한 절차와 보고 라인에서 떨어져
|
||||
나와서 소수의 정애 멤버가 자유롭게
|
||||
새로운 것을 실험하는 작은 팀을
|
||||
의미합니다. 별동대라는 개념과 비슷할
|
||||
것 같은데요. 기존 회사가 AI
|
||||
리이티브 운영 체제를 도입하고 싶다면
|
||||
핵심 비즈니스와 아무런 관계가 없는
|
||||
작은 AI 네이티브 팀이 스краਅ크
|
||||
웍스 팀을 만들어서 그 팀이 완전히
|
||||
새로운 방식으로 일하면서 실험해 보는
|
||||
겁니다. 영상에 언급된 뮤티니는
|
||||
Y콤비네이터 출신 스타트업으로
|
||||
영업팀, 마케팅 팀이 필요한 고객
|
||||
대면 자료를 AI로 만들어 주는
|
||||
서비스인데요. 2018년에 설립되어서
|
||||
AI 네이티브 조직은 아니었어요.이
|
||||
레거시 팀이 AI 네이티 운영 체제와
|
||||
조직으로 아주 잘 변모한 듯합니다.이
|
||||
영상의 핵심을 간단하게 요약하면요.
|
||||
가장 중요한 메시지는 이겁니다.
|
||||
여러분은 AI가 일을 더 빨리 하게
|
||||
해 주는 도구가 아니라 팀의 체질를
|
||||
바꾸는 새로운 운영 방식으로
|
||||
이해하셔야 합니다. 뭐 지금까지 업무
|
||||
보조 도구로 생각하면서 직원들에게 뭐
|
||||
보조금, 지원금 정도만 주고 있다면
|
||||
생각을 크게 바꾸시는게 좋겠습니다.
|
||||
세 가지 핵심 개념이 나왔는데요. 첫
|
||||
번째는 폐쇄 루프 회사. 스스로
|
||||
학습하는 회사 시스템이죠. 모든 의사
|
||||
결정과 그 결과를 AI가 추적하고
|
||||
분석할 수 있게 만들어야 하고요. 두
|
||||
번째는 AI 소프트웨어 팩토리죠.
|
||||
사람은 무엇을 만들지 스펙만 정하고
|
||||
AI가 어떻게 만들지를 담당하는
|
||||
구조죠. 이게 잘 작동하면 엔지니어
|
||||
한 명이 과거 천명이 하던 일을 할
|
||||
수 있게 됩니다. 세 번째는 새로운
|
||||
조직 구조예요. 중간 관리자가 없는
|
||||
평평한 조직이 필요합니다. 정보를
|
||||
위아래로 전달하는 중간 관리자는 더
|
||||
이상 필요가 없습니다. 모든 직원이
|
||||
직접 만들고 명확한 책임을지면서
|
||||
창업자는 AI 활용에 선두에서야
|
||||
합니다. 우리에게 가장 힘이 되는
|
||||
대목은 마지막에 나온 것 같은데요.
|
||||
지금이 스타트업이 강좌를 앞지를 수
|
||||
있는 저로의 기회입니다. 기존
|
||||
시스템, 업조, 직원수, 소수
|
||||
정애입니다. 의사 결정 속도는
|
||||
기본적으로 빠르고요. AI 네이티브
|
||||
전환은 처음부터 [음악] 기초부터
|
||||
가능합니다. 작고 빠른 AI 네이티브
|
||||
스타트업은 기존 기업을 압도할
|
||||
[음악] 수 있는 역사적인 기회를
|
||||
거어줄 수 습니다.
|
||||
[음악]
|
||||
[음악]
|
||||
[음악]
|
||||
@@ -0,0 +1,155 @@
|
||||
# 유튜브분석 AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀 (정보) 2026-05-27
|
||||
|
||||
- **영상 URL**: https://www.youtube.com/watch?v=Qu4X0auqnqA
|
||||
- **분석 시각**: 2026-05-27T03:18:22.952Z
|
||||
- **분석 모드**: info
|
||||
- **생성**: Astra /youtube · Datacollect youtube insight
|
||||
|
||||
## 📜 전체 스크립트 (Full Script)
|
||||
|
||||
**[00:00]** 회사 팀 차원에서 AI를 활용하는 가장 좋은 방법은 뭘까요? 왜 기존 회사들은 AI 시대에 뒤쳐질 수밖에 없을까요? 그리고 왜 지금이 작은 스타트업이 거대 기업을 이길 수 있는 역사적 기회일까요? 다이에나 후는 세계 최고의 스타트업 엑셀러레이터, 와이 콤비네이터의 파트너입니다. 그녀가 지금 몇 달 사이에 목격한 아주 놀라운 현상에 대해 이야기하려고 나섰습니다. 만약 당신이 창업자거나 팀을 이끄는 사람이거나 혹은 조금 전 질문의 답이 궁금하시다면 꼭 끝까지
|
||||
|
||||
**[0:30]** 들어보세요. 저는 보충 설명과 내용 정리로 여러분의 이해를 도와드릴게요. Hi, I'm Diana and I'm a partner at YC. Over the past few months, it's become clear to me that AI is not just going to change how quickly software gets built or what workflows get automated. It's going to fundamentally change the way startup should be run from what rules will exist to what products are possible to build. In this episode, I'm going to discuss how
|
||||
|
||||
**[1:00]** founders should think about building an AI native company, what roles their team should have, and what concrete internal practices they can adopt right now to move much faster. Currently, most people talk about AI in terms of productivity. They'll talk at length about how it can make engineers more productive or say we need to add copilot to existing workflows and ship more features. This framing misses the shift we're currently seeing which is less about productivity booths than entirely a new
|
||||
|
||||
**[1:30]** capabilities. The right person with AI tools can now build features that used to require an entire team or were just impossible. Thinking about AI in terms of new capabilities has several implications for how founders should run their companies. At a high level, the way to think about AI is that should not be a tool your company just uses. It should be the operating company runs on. Yor은 유수의 회사들을 초기에 키워낸 세계에서 가장 영향력 있는
|
||||
|
||||
**[2:00]** 벤처 캐피털이에요. 2005년 폴 그레이엄이 설립했고 오픈 AI의 샘트먼이 약 5년 정도 사장직을 여임했죠. YC 파트너라는 자리는 매년 수백개 회사가 어떻게 성공하고 실패하는지를 가장 가까이 있어 지켜보는 위치입니다. 따라서 AI는 도구가 아니라 운영 체제가 되어야 한다는이에나의 주장은 최근 실제로 빠르게 성장하는 회사들에서 공통적으로 관찰된 패턴이라는 점에서 무게가 실리죠. 참고로 다이에나 본인도 엔지니어 출신이고요. 포켓몬 고를
|
||||
|
||||
**[2:30]** 만든 회사 나이엔틱에서 AIAR AR 분야를 이끈 경력이 있습니다. 어떤 이야기를 하는지 더 들어보시죠. workfow, every decision and every process should flow through an intelligent layer that is constantly learning and improving. What this means concretely is every important process in your company should be captured by an intelligent close loop. A close loop captures inflammation, feeds it back into an intelligence systems, and improve the process over time. If you've ever studied control
|
||||
|
||||
**[3:00]** systems, you will be familiar with the difference between an open loop and a close loop system. Open loops are control systems without feedback loops. In the old world, companies basically ran as open loops. You made a decision, executed it, and didn't always systematically measure the outcome and adjust the process. Open loops are inherently lossy. A close loop, on the other hand, is self-regulating. It continuously monitors its output and adjusts its process to better meet the stated
|
||||
|
||||
**[3:30]** goal. Close loops are extremely powerful for correctness and stability with ag 개방 폐쇄루프에 대한 이야기가 나왔는데요. 이걸 이해하는 가장 쉬운 비유는 요리인 것 같습니다. 개방 루프는 레시피만 보고 요리하는 방식이에요. 물m, 뭐 간장 두 스푼, 10분 끓이기 적힌 대로만 요리하고 중간에 맛을 보지 않습니다. 음식이 짠지 싱거운지 미리 알 수 없죠. 반면 폐쇄 루프는 중간중간
|
||||
|
||||
**[4:00]** 간을 보면서 요리하는 방식이에요. 끓이다가 한번 맛보고 싱거우면 소금을 더 넣고 다시 맛보고 이렇게 결과를 측정하고 조정하는 행위를 반복합니다. 에어컨도 그렇죠. 설정 온도에 도달했는지 계속 측정하면서 에어컨 스스로 더우면 더 강하게 그리고 시원해지면 약하게 자동 조절하죠. 이런게 폐쇄 루프입니다. 다이에나가 말하는 핵심은 이겁니다. 기존 회사들은 회의, 결정, 실행으로 끝나고 그 결과가 좋았는지 나빴는지 체계적으로 확인하지 않습니다.
|
||||
|
||||
**[4:30]** 체계적으로라는 말이 중요한데 결과를 확인하고 반영하고자 하는 의지가 있다고 해도 기존의 운영 체제가 이걸 받쳐 주지 못합니다. 반면 AI 네이티브 회사는 실행부터 결과 분석 그다음 결정까지 체계적이고 근본적으로 가능합니다. 속도도 빠르고 정확도도 높죠. these close loops you will need to make your entire company queryable in other words the whole organization should be legible to AI every important action should produce an artifact
|
||||
|
||||
**[5:00]** that the intelligence at the center of the company can learn from and use to self-improve this means recording your meetings with a AI notaker, minimizing DMs and emails, and embedding agents throughout communication of all channels. It also means building custom dash with everything in the company. revenue, sales, engineering, hiring, ops, everything. Here's a concrete example of how it could work. Take engineering, management, and sprint planning. If you have an agent that has access to your linear tickets,
|
||||
|
||||
**[5:30]** all your Slack engineering channels, all customer feedback from emails or tools like PIN and GitHub, highlevel plans in a notion or Google doc, sales calls and recordings from daily standups, then the agent can analyze what was actually shipped in your previous print and how well they met customers needs for real. From there, you can go a step further with full visibility into what shipped, what worked and what didn't. Agents can start looking ahead.
|
||||
|
||||
**[6:00]** They can propose sprint plans for engineers that are way more predictable and accurate and on track. The days of manager status rollups that are super lossy are gone. Having managed engineering teas myself and now seeing this across multiple YC companies, this is a game changer. What used to require constant coordination becomes legible and querable by default. I've seen teams that do this cut their engineering sprint time in half and get close to 10x more than in that time.
|
||||
|
||||
**[6:30]** The overarching principle here is that to get their full capabilities, you need to provide models with as much context as you would provide an employee. When you do this, your company stops operating as a open loop where information is fragmented and manually interpreted. It becomes instead a close loop system. Status, decisions and outcomes are continuously captured and fed back into this intelligence layer. The result is a system that has an update view of리는
|
||||
|
||||
**[7:00]** 데이터베이스에 질문한다라는 뜻인데요. 다이에나가 말한 AI 네이티브 운영 체제가 작동한다면 데이터베이스가 아니라 AI에게 질문함으로써 서비스에 대한 모든 답이 나오는 상태가 되는 거겠죠. 뭐 예를 들어 지난달 우리 고객들이 가장 많이 불평한 문제 세 가지가 뭔가? 이번 분기에 영업 팀이 어떤 기능을 가장 많이 요청받았는가? 지난 6개월간 우리 회사가 내린 결정 중에 실패한 것의 공통점은 무엇인가? 다음 업데이트 때 반드시 넣어야 하는
|
||||
|
||||
**[7:30]** 기능은 이런 질문을 누구나 할 수 있고 누구에게나 정확도가 높은 응답이 돌아옵니다. 현재 이런 시스템이 잘 거쳐지지 않는 이유는 회사의 정보가 여기저기 흩어져 있기 때문이고요.이를 사람이 이어주고 전달해 주는 방식은 정보 전달에 누수가 생길 수밖에 없어요. 주요 정보가 오가하는 회의는 반드시 전부 데이터화해야 한다고 말하고 중요한 정보가 오가지만 정보가 공유되지도 않고 쌓이지도 않는 다이렉트 메시지나 산의 이메일은
|
||||
|
||||
**[8:00]** 최소한으로 사용하라는 팁도 중요한 것 같습니다. 메신저 메시지나 구두로 중요 정보가 오가는 바람에 특정 관리자와 친하지 않으면 정보와 멀어지는 상황. 회사를 다녀본 분들은 한 번쯤 경험하시거나 목격하셨을 거예요. DM으로 업무 지시를 받고 구두로 회의 결론을 내고 결정 과정을 문서로 남기지 않는 문화. 저는 스타트업에서도 많이 보고 들었습니다. 이런 관행은 AI 시대에는 큰 약점이 됩니다. AI가 학습할 수 있는 데이터가 남지 않기 때문이죠.
|
||||
|
||||
**[8:30]** product AI software factories. If you're familiar with the test driven development or TDD, this is the next evolution of that. With software factories, humans right aspect and a set of tests that define success. And then AI agents generate the implementation and code and iterate until the test pass. The human defines what to build and
|
||||
|
||||
**[9:00]** judges the output. The actual code is the agent job. Some companies have already pushed this to the point where the repost contain no handwritten code, just specs and test hardnesses. Strong DMs AI team is an example of how to do this. Their end goal was a system that essentially eliminated the need for a human to write or review code. And so they build their own software factory where specs and scenario based validations drive
|
||||
|
||||
**[9:30]** agents to write test and iterate and code until it meets a probabilistic satisfaction thresold and it works. This is how you achieve thex engineer that Steve talked about by surrounding a single engineer with a system of agents that enable them to build things they would have never been able to build before. The era of 10,000 X engineer is here. >> AI 소프트웨어 팩토리와 기존 회사의 차이를 좀 더 쉽게 이야기해 보면요.
|
||||
|
||||
**[10:00]** 기존 방식은 건축가가 설계도를 그리고 인부들이 직접 벽돌를 쌓아서 집을 짓는 방식이라면 AI 소프트웨어 팩토리에서는 건축가가이 집은 침실 세 개, 화장실 두 개 무너지지 않아야 하고 단열이 잘 되어야 한다. 이런 요구 사항과 어 합격 기준만 작성합니다. 그러면 로봇 인부들이 알아서 집을 짓고 또 테스트도 하고 통과할 때까지 자기들끼리 고치고 짓는 걸 반복하죠.
|
||||
|
||||
**[10:30]** 중간 피드백, 최종 검수 이런 절차까지도 사라지겠죠. td라는 말은 간단히 말씀을 드리면 코드를 짜기 전에 합격 기준을 먼저 정하는 방식인데요. 시험 문제를 먼저 만들어 놓고 그 시험을 통과하는 답안을 나중에 작성하는 것과 비슷합니다. 단, td에서는 그 답안을 사람이 쓰는데 AI 소프트웨어 팩토리는 사람은 시어 문제, 즉 스펙과 테스트까지만 만들고 답안을 쓰는 건 AI 에이전트가 맞습니다. 요약하면 소프트웨어 팩토리는 사람은 무엇을
|
||||
|
||||
**[11:00]** 만들지만 결정하고 AI는 어떻게 만들지를 알아서 처리하는 분업입니다. 심지어 사람이 다음에 무엇을 만들지 결정할 때 도움이 될 만한 분석 자료와 정보들까지 제공해 주겠죠. 꿈만 같은 일처럼 들리지만 이미 도입되고 있고 가능한 일입니다.
|
||||
|
||||
**[11:30]** In the new world, the intelligence layer serves that purpose. If your company is queryable, artifact rich and legible to an AI, you should have almost no human middleware. This matters because your company's velocities is only as fast as its information flow. Every layer of human routing you can remove is a
|
||||
|
||||
**[12:00]** direct speed gain. A great example is what Jack Dory is doing over at block. After going deep on the tools, he's come to the same conclusion many half. This is about more than just incremental productivity gains. His view is that if you keep the same org chart and management structure, you miss the shift entirely. The company itself has to be rebuilt as an intelligence layer with humans at the edge guiding it rather than routing information through
|
||||
|
||||
**[12:30]** it. Going forward, Jack suggests every company will have three employee archetypes. The first is the individual contributor or IC. Basically the builder operator. This is someone who directly makes and runs things. In an AI native company this is not limited to engineers. Everyone builts, ops, support sales. Everyone comes to meetings with working prototypes, not pitch. Second is the DRI, the directly responsible individual. Focus on
|
||||
|
||||
**[13:00]** strategy and customer outcomes. This is not a classic manager is the person with a clear responsibility for the result. One person, one outcome, no hiding. The third is the AI founder type. This person still builds, still coaches and leads by example. If you're the founder, this needs to be you at the forefront. showing your team what massive capability gains look like. Not delicating your AI strategy to someone else. With this structure, companies
|
||||
|
||||
**[13:30]** will be able to get outsized results with much smaller teams. Maximizing token usage not head count will be the critical shift. The best companies will be the ones that are maxing. 잭도시가 누구냐면요 지금은 X죠. 트위터의 공동 창업자이자 결제회사 블록의 CEO인데요. 실리콘 밸리에서 가장 영향력이 있는 창업자 중에 한 명입니다. 블록은 미국의 카드 결제 서비스, 송금앱 등을 운영하고 있어요. 즉 도시는 2024년 경부터이 블록의 조직 구조를 과감하게
|
||||
|
||||
**[14:00]** 뜯어친 것으로 화자가 됐습니다. 중간 관리자가 너무 많다면서 매니저 직급을 대거 주렸고 직접 만들고 실행하는 사람들 중심으로 팀을 재편한 거죠. 어, 다시 보니까이 세 가지 유형 중에 하나에 속한다는 개념이라기보다 복수의 유형을 한 사람이 겸할 수 있는 속성의 개념인 것 같습니다. 내가 100% 책임을 져야 하는 담당 지표, 업무 이런게 있고요.이를 위해 AI 도구를 능통하게 쓰면서 필요할 땐 직접 제품이나 도구를 만드는
|
||||
|
||||
**[14:30]** 사람, 포지션을 불문하고 최고의 직원이 되겠죠. 이런 직원을 원한다면 AI 운영 체제를 세팅하는 것은 기본이고 정보를 전달하는 중간 관리자를 없애거나 최소화하는 것도 필수적으로 동반되어야 될 것 같아요. 중간 관리자의 존재는 책임이 분산되는 체계이자 작업자가 자기 미션을 달성하기 위한 정보를 100% 얻기 어려운 체계의 방증입니다. 참고로 크랙 팀에서는 팀 내에서 필요한 여러 가지 도구들을 AI로 그때그때 빠르게
|
||||
|
||||
**[15:00]** 만들어 주는 전단 포지션이 있다고 합니다. 예전에는 개발자한테 어떤 고객 데이터를 모아서 달라고 요청하면 뭐 하루 이틀 뒤에 엑셀 파일로 주는 방식이었죠. 대부분. 그런데 이제는 개발자가 아니어도 궁금한 고객 데이터를 마음껏 물어볼 수 있는 간단한 프로그램을 하루 이틀 기다리지 않아도 이용할 수 있다는 겁니다. 잭 도시가 말한 세 가지 유형의 팀원들만 남도록 체질 개선을 하는 것이 너무 무리인 것 같다면 중간 단계로 시도해 볼 만한 방법인 것 같습니다. Think of the tradeof
|
||||
|
||||
**[15:30]** this way. One person with AI tools can be the equivalent of what used to take a large engineering team at a pre company. That means grammatically engineering, design, HR and admin teams. And so you should be willing to run an uncomfortably high API bill because it's replacing what would have taken a far more expensive and inflated head count. But don't just take my word for any of this. You cannot outsource your conviction on
|
||||
|
||||
**[16:00]** the power of these tools. You need to develop it yourself by actually sitting with coding agents and using them until you start to break your own priors about what is now possible to build. If you are an early stage founder, you have a huge advantage in getting ahead on this. You don't have legacy systems, interest or charts or thousands of people to retrain. You are small enough to build your company right from day one. The opposite is the case for existing companies. They have to maintain and grow a live product while
|
||||
|
||||
**[16:30]** unwinding years of standard operating procedures and core assumptions about how software gets built. Some companies can achieve this by spinning up small internal scunkw teams that can build AI native systems from scratch separate from the core business. Mutney is a great example of this but for most every change to their core processes risk breaking something that already works. So by their nature these large companies will have a much harder time going AI native.
|
||||
|
||||
**[17:00]** Startups don't have that constraint and that's a major edge to take advantage of. You can design your system workfows and culture around AI from the start and as a result operate 다이에나는 제로베이스에서 AI 네이티브 운영 체제를 세팅할 수 있는 스타트업에게 유리한 판이라는 것을 강조하면서도 기존 회사에게도 아이디어를 주고 있어요. 먼저 스크 웍스란 말이 나왔는데요. 회사 본부의 복잡한 절차와 보고 라인에서 떨어져
|
||||
|
||||
**[17:30]** 나와서 소수의 정애 멤버가 자유롭게 새로운 것을 실험하는 작은 팀을 의미합니다. 별동대라는 개념과 비슷할 것 같은데요. 기존 회사가 AI 리이티브 운영 체제를 도입하고 싶다면 핵심 비즈니스와 아무런 관계가 없는 작은 AI 네이티브 팀이 스краਅ크 웍스 팀을 만들어서 그 팀이 완전히 새로운 방식으로 일하면서 실험해 보는 겁니다. 영상에 언급된 뮤티니는 Y콤비네이터 출신 스타트업으로 영업팀, 마케팅 팀이 필요한 고객
|
||||
|
||||
**[18:00]** 대면 자료를 AI로 만들어 주는 서비스인데요. 2018년에 설립되어서 AI 네이티브 조직은 아니었어요.이 레거시 팀이 AI 네이티 운영 체제와 조직으로 아주 잘 변모한 듯합니다.이 영상의 핵심을 간단하게 요약하면요. 가장 중요한 메시지는 이겁니다. 여러분은 AI가 일을 더 빨리 하게 해 주는 도구가 아니라 팀의 체질를 바꾸는 새로운 운영 방식으로 이해하셔야 합니다. 뭐 지금까지 업무 보조 도구로 생각하면서 직원들에게 뭐
|
||||
|
||||
**[18:30]** 보조금, 지원금 정도만 주고 있다면 생각을 크게 바꾸시는게 좋겠습니다. 세 가지 핵심 개념이 나왔는데요. 첫 번째는 폐쇄 루프 회사. 스스로 학습하는 회사 시스템이죠. 모든 의사 결정과 그 결과를 AI가 추적하고 분석할 수 있게 만들어야 하고요. 두 번째는 AI 소프트웨어 팩토리죠. 사람은 무엇을 만들지 스펙만 정하고 AI가 어떻게 만들지를 담당하는 구조죠. 이게 잘 작동하면 엔지니어 한 명이 과거 천명이 하던 일을 할 수 있게 됩니다. 세 번째는 새로운
|
||||
|
||||
**[19:00]** 조직 구조예요. 중간 관리자가 없는 평평한 조직이 필요합니다. 정보를 위아래로 전달하는 중간 관리자는 더 이상 필요가 없습니다. 모든 직원이 직접 만들고 명확한 책임을지면서 창업자는 AI 활용에 선두에서야 합니다. 우리에게 가장 힘이 되는 대목은 마지막에 나온 것 같은데요. 지금이 스타트업이 강좌를 앞지를 수 있는 저로의 기회입니다. 기존 시스템, 업조, 직원수, 소수 정애입니다. 의사 결정 속도는
|
||||
|
||||
**[19:30]** 기본적으로 빠르고요. AI 네이티브 전환은 처음부터 [음악] 기초부터 가능합니다. 작고 빠른 AI 네이티브 스타트업은 기존 기업을 압도할 [음악] 수 있는 역사적인 기회를 거어줄 수 습니다. [음악] [음악] [음악]
|
||||
|
||||
---
|
||||
|
||||
# AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀 — 정보 추출 카드
|
||||
|
||||
> **영상 URL**: https://www.youtube.com/watch?v=Qu4X0auqnqA · **분석 일자**: 2026-05-27 · **길이**: 20:01 · **채널**: Ladder Game
|
||||
|
||||
## 📋 구조화된 요약 (Structured Overview)
|
||||
*상단 대시보드 — 영상을 안 다시 보고도 핵심을 잡을 수 있게 압축. 아래 상세 섹션은 같은 내용의 깊이 버전.*
|
||||
|
||||
### 🎯 핵심 3요소
|
||||
- **주제**: AI 시대에 기업이 단순한 도구 활용을 넘어 'AI 네이티브 운영 체제'로 전환해야 하는 이유와 방법
|
||||
- **핵심 주장**: AI는 단순히 생산성을 높이는 도구가 아니라, 회사가 돌아가는 방식 자체를 바꾸는 운영 체제(OS)가 되어야 함
|
||||
- **근거/사례**:
|
||||
- '폐쇄 루프(Closed Loop)' 시스템을 통한 데이터 피드백과 자동 조정의 중요성
|
||||
- AI 소프트웨어 팩토리를 통한 개발 프로세스의 혁신 (인간은 스펙 결정, AI는 구현)
|
||||
|
||||
### ⏱️ 타임라인 기반 요약
|
||||
*영상이 짧아 생략 (아래 🧭 구조 요약 참조)*
|
||||
|
||||
### 📝 한 줄 요약 + 기억할 포인트
|
||||
- **한 줄**: 기업의 모든 프로세스를 AI가 학습하고 개선할 수 있는 '지능형 레이어'로 구축하여, 정보의 누락 없는 폐쇄 루프 시스템을 만들어야 함
|
||||
- **기억할 포인트 3~5개**:
|
||||
1. AI는 도구가 아닌 회사의 운영 체제(Operating System)여야 함
|
||||
2. 결과값을 측정하고 반영하는 '폐쇄 루프(Closed Loop)' 구조 구축이 핵심임
|
||||
3. 모든 회의와 결정 과정은 AI가 학습할 수 있도록 데이터화되어야 함 (DM, 이메일 최소화)
|
||||
4. 인간은 무엇을 만들지 결정하고, AI는 어떻게 만들지를 처리하는 '소프트웨어 팩토리'로 진화해야 함
|
||||
|
||||
## 🎯 한 줄 요약 (TL;DR)
|
||||
AI 시대의 기업은 단순한 생산성 향상을 넘어, 모든 비즈니스 프로세스가 AI에 의해 읽히고(legible) 질문 가능한(queryable) 상태인 'AI 네이티브 운영 체제'를 구축함으로써 거대한 규모의 인력을 대체하는 강력한 효율성을 확보해야 합니다.
|
||||
|
||||
## 💡 화자 한 줄 비유 (Anchor Metaphor)
|
||||
"개방 루프는 레시피만 보고 요리하는 방식(맛을 보지 않음)인 반면, 폐쇄 루프는 중간중엇간 간을 보면서 요리하는 방식입니다." (04:15)
|
||||
|
||||
## 📌 핵심 주장 3~5개
|
||||
- **[화자 주장]** "AI는 회사가 단순히 사용하는 도구가 아니라, 회사가 운영되는 운영 체제(Operating System)여야 합니다." — (01:28)
|
||||
- **[근거 명시]** "기존 회사들은 결정하고 실행한 뒤 결과를 체계적으로 측정하지 않는 '개방 루프' 방식이지만, AI 네이티브 회사는 실행부터 결과 분석까지 가능한 '폐쇄 루프'를 구축할 수 있습니다." — (04:35)
|
||||
- **[화자 주장]** "AI 소프트웨어 팩토리에서 사람은 무엇을 만들지 결정하고, 실제 코드를 작성하는 것은 AI 에이전트의 몫입니다." — (08:50)
|
||||
- **[근거 명시]** "잭 도시(Block CEO)는 중간 관리자를 줄이고 직접 실행하는 사람 중심으로 조직을 재편하며 새로운 직원 유형을 제시했습니다." — (10:20)
|
||||
|
||||
## 📊 사실·데이터·인용
|
||||
| 항목 | 값 / 정의 | 출처 (영상 내) | 타임스탬프 |
|
||||
| --- | --- | --- | --- |
|
||||
| AI 네이티브 운영 체제 핵심 원칙 | 모든 프로세스가 지능형 레이어를 통해 흐르고 학습되어야 함 | 다이애나 후 (YC 파트너) | 01:28 |
|
||||
| 잭 도시의 3가지 직원 유형 | IC(Builder), DRI(Strategy/Outcome), AI Founder Type | 잭 도시 (Block CEO) | 10:25 |
|
||||
way | 인간은 스펙과 테스트를 만들고, 에이전트는 구현을 담당함 | AI 소프트웨어 팩토리 개념 | 08:30 |
|
||||
|
||||
## 🧭 구조 요약 (Sectioned Summary)
|
||||
- **[00:00–01:27]** 도입부: AI 시대, 스타트업이 거대 기업을 이길 수 있는 이유와 다이애나 후의 관점 소개 (00:00–01:27)
|
||||
- **[01:28–04:30]** AI 네이티브 운영 체제: 도구를 넘어선 OS로서의 AI, 그리고 개방 루프 vs 폐쇄 루프(요리 비유) (01:28–04:30)
|
||||
- **[04:31–07:00]** 데이터 가용성: 회사의 모든 것을 AI가 질문 가능한 상태로 만들기 (모든 프로세스의 데이터화) (04:31–07:00)
|
||||
- **[07:01–08:59]** 소프트웨어 팩토리: 인간의 코딩 없이 스펙과 테스트만으로 작동하는 에이전트 기반 개발 방식 (07:01–08:59)
|
||||
- **[09:00–11:30]** 조직의 미래: 잭 도시가 제시한 세 가지 직원 유형과 중간 관리자 최소화 전략 (09:00–11:30)
|
||||
- **[11:31–끝]** 결론 및 제언: 초기 창업자의 이점과 AI 도구 활용을 통한 개인의 역량 확장 (11:31–끝)
|
||||
|
||||
## 🔗 인용용 한 줄 카드 (Citation Sniability)
|
||||
- "AI는 단순히 생산성을 높이는 것에 대한 논의가 아니라, 완전히 새로운 능력을 만드는 것에 대한 것입니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (01:05)
|
||||
- "모든 중요한 프로세스는 지능형 폐쇄 루프(intelligent closed loop)에 의해 캡처되어야 합니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (02:15)
|
||||
- "사람은 무엇을 만들지 결정하고, AI는 어떻게 만들지를 알아서 처리하는 분업이 이루어집니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재화한 팀, Ladder Game (09:15)
|
||||
- "회사의 속도는 정보가 흐르는 속도와 같습니다. 제거할 수 있는 모든 인간의 중개 단계는 직접적인 속도 향상을 의미합니다." — AI를 팀원 각자 쓰는 팀 vs 뼛속까지 내재한 팀, Ladder Game (09:45)
|
||||
|
||||
## ❓ 더 파고들 질문 (Open Questions)
|
||||
- "본문에서 언급된 'AI 소프트웨어 팩토리'를 실제 엔지니어링 워크플로우에 적용하기 위한 구체적인 도구(Agentic Workflow 도구 등) 리스트는 무엇인가?"
|
||||
- "중간 관리자를 최소화하는 조직 구조가 기업의 장기적인 문화적 응집력이나 인재 유지(Retention)에 미칠 수 있는 부정적 영향은 없는가?"
|
||||
|
||||
## 🧩 정리자 노트 (원본 보강) — 선택
|
||||
*정리자 추가 노트 없음 — 본문 그대로가 명확함*
|
||||
@@ -0,0 +1,48 @@
|
||||
# [.Net 이슈 관련 업데이트 및 운영 프로세스 점검 회의]
|
||||
|
||||
- **날짜**: 2026년 5월 27일 | 오전 11시
|
||||
- **참석자**: 김원일 이사, 김상엽, 박준범, 최성연, 한예성
|
||||
- **주제 요약**: .Net 이슈 해결을 위한 라이브 빌드 QA 진행 현황 점검 및 운영 툴 관리/패치 노트 작성 프로세스 확립
|
||||
|
||||
## 🔹 요약 보고
|
||||
* **라이브 빌드 QA 및 업데이트**: 현재 전달받은 라이브 빌드에 대해 오늘 중 QA를 완료하고, 문제 없을 시 내일 중 업데이트 반영을 목표로 함.
|
||||
* **일본 법인 대응**: 로그인 후 칼리브레이션 오류 이슈 해결을 위해 일본 측(홍 실장)에 테스트 플라이트 등록 및 확인 요청 예정.
|
||||
* **운영 프로세스 정립**: 운영 툴 관리 및 강제 업데이트 판단 주체를 기획 담당자(성혜)로 지정하고, 패치 노트 작성 시 개발팀의 기술적 지원을 포함하기로 함.
|
||||
* **보안 및 기타**: 운영 툴 사용 권한 및 비밀번호 보안 관리 필요성 언급과 함께, 테스트용 단말기(S25 등) 활용 계획 논의.
|
||||
|
||||
## 1. 주요 논의 사항
|
||||
### [.Net 이슈 대응 및 업데이트 계획]
|
||||
- **현황**: .Net 적용 건은 라이브 확인을 마쳤으나, 현재 최신 라이브 빌드를 전달받기 위해 대기 중임. 일본 지역에서 발생하는 로그인 후 칼리브레이션 미인식 이슈를 해결하기 위한 코드 수정이 진행됨.
|
||||
- **핵심 논의**:
|
||||
- 오늘 중 QA를 마무리하고 문제없으면 즉시 업데이트 요청을 진행할 것.
|
||||
- 내일 중 업데이트 반영을 목표로 함.
|
||||
- **결론**: 결정됨
|
||||
|
||||
### [운영 툴 관리 및 패치 노트 작성 프로세스]
|
||||
- **현황**: 강제 업데이트 버전 설정 및 운영 툴 관리에 대한 책임 소재가 불분명함.
|
||||
- **핵심 논의**:
|
||||
- 운영 툴 관리는 기획 담당자(성혜)가 수행하며, 일본 법인장 확인 결과에 따라 강제 전환 여부를 판단함.
|
||||
- 패치 노트는 개발 측에서 1차 정리(서버/클라 개발자)하여 예성이 및 성혜에게 전달하고, 이를 바탕으로 유저용 언어로 수정함.
|
||||
- **결론**: 결정됨
|
||||
|
||||
## 2. 리스크 및 이슈
|
||||
* **일본 지역 이슈**: 일본 법인장 및 홍 실장이 겪고 있는 로그인/칼리브레이션 오류가 지속적으로 발생하고 있어, 코드 수정 후 재검증이 필요함.
|
||||
* **보안 위험**: 서버 팀장의 비밀번호 관리 방식(주기적 교체 등)에 대한 보안 취약점 우려 및 AI 해킹 시대의 보안 강화 필요성 제기.
|
||||
|
||||
## 3. 결정 사항
|
||||
* **운영 툴 관리 주체**: 기획 담당자(성혜)로 지정.
|
||||
* **패치 노트 작성 절차**: 개발자(1차 정리) $\rightarrow$ 예성이/성혜(2차 정리 및 유저용 언어 변환).
|
||||
* **업데이트 방식**: 일본 법인장이 확인한 후, 문제가 해결된 시점에 강제 업데이트 전환 여부를 결정함.
|
||||
|
||||
## 4. 오픈 이슈
|
||||
* **테스트 플라이트 등록**: 홍 실장에게 테스트 플라이트를 등록하여 QA를 동시에 진행할 수 있는 환경 구축 필요.
|
||||
* **단말기 테스트**: S25 등 최신 단말기를 활용한 퀄리티 체크 및 카메라 위치에 따른 필름형 테스트 버전 검증.
|
||||
|
||||
## 5. 액션 아이템
|
||||
| 담당 | 작업 내용 | 기한 |
|
||||
| --- | --- | --- |
|
||||
| 개발팀 | 라이브 빌드 QA 완료 및 업데이트 요청 | 오늘 중 |
|
||||
| 개발팀 | 패치 노트 초안 작성 (서버/클라 개발자) | 업데이트 전 |
|
||||
| 김원일 이사 | 홍 실장에게 테스트 플라이트 등록 지원 및 안내 | 완료 시 즉시 |
|
||||
| 성혜 | 운영 툴 관리 및 강제 업데이트 여부 판단 | 상시 |
|
||||
| 개발팀 | QA 결과값 정리 및 전달 (24 버전 관련) | 확인 후 즉시 |
|
||||
@@ -8,12 +8,12 @@
|
||||
## Snapshot
|
||||
- **Workspace**: `00_Raw` _(absolute path varies by environment; resolved from the active VS Code workspace)_
|
||||
- **Stack**: _(unknown)_
|
||||
- **Stats**: 5 source files, ~83 lines across 1 top-level modules.
|
||||
- **Stats**: 6 source files, ~110 lines across 1 top-level modules.
|
||||
|
||||
## Last Refresh
|
||||
- **Time**: 2026-05-13T14:14:16.214Z
|
||||
- **Files newly analysed**: 5
|
||||
- **Files reused from cache**: 0
|
||||
- **Time**: 2026-05-27T10:07:53.609Z
|
||||
- **Files newly analysed**: 0
|
||||
- **Files reused from cache**: 6
|
||||
|
||||
## Directory Map
|
||||
```mermaid
|
||||
@@ -25,19 +25,20 @@ mindmap
|
||||
|
||||
## Modules
|
||||
|
||||
### `docs/` — 5 files, ~83 lines
|
||||
### `docs/` — 6 files, ~110 lines
|
||||
|
||||
**Sub-directories**
|
||||
- `docs/records/` (5) — 00Raw Chronicle Records
|
||||
- `docs/records/` (6) — JSON configuration
|
||||
|
||||
**Key files**
|
||||
- `docs/records/00_Raw/README.md` (18 lines) — 00Raw Chronicle Records
|
||||
- `docs/records/00_Raw/chronicle.config.json` (11 lines) — JSON configuration
|
||||
- `docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md` (16 lines) — Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...
|
||||
- `docs/records/00_Raw/development/2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md` (24 lines) — Development Log: E:\Wiki\2nd\00Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\Wiki\2nd\10Wiki\Topicsme...
|
||||
- `docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md` (16 lines) — Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...
|
||||
- `docs/records/00_Raw/project-profile.md` (31 lines) — Project Profile
|
||||
- `docs/records/00_Raw/timeline.md` (7 lines) — Project Timeline
|
||||
- `docs/records/00_Raw/README.md` (18 lines) — 00Raw Chronicle Records
|
||||
- `docs/records/00_Raw/timeline.md` (10 lines) — Project Timeline
|
||||
|
||||
_Last auto-scan: 2026-05-13T14:14:16.214Z · signature `230d82a4`_
|
||||
_Last auto-scan: 2026-05-27T10:07:53.609Z · signature `1c09705`_
|
||||
<!-- ASTRA:AUTO-END -->
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -1,39 +1,46 @@
|
||||
{
|
||||
"version": 1,
|
||||
"generatedAt": "2026-05-13T14:14:16.215Z",
|
||||
"generatedAt": "2026-05-27T10:07:53.617Z",
|
||||
"files": {
|
||||
"docs/records/00_Raw/README.md": {
|
||||
"mtimeMs": 1778681649000,
|
||||
"size": 394,
|
||||
"lines": 18,
|
||||
"role": "00Raw Chronicle Records",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/chronicle.config.json": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 427,
|
||||
"mtimeMs": 1779876330777.5742,
|
||||
"size": 372,
|
||||
"lines": 11,
|
||||
"role": "JSON configuration",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 1039,
|
||||
"docs/records/00_Raw/development/2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md": {
|
||||
"mtimeMs": 1779876330769.102,
|
||||
"size": 1560,
|
||||
"lines": 24,
|
||||
"role": "Development Log: E:\\Wiki\\2nd\\00Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\\Wiki\\2nd\\10Wiki\\Topicsme...",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md": {
|
||||
"mtimeMs": 1778720006542.9683,
|
||||
"size": 1055,
|
||||
"lines": 16,
|
||||
"role": "Discussion: /Volumes/Data/project/Antigravity/Wiki/10Wiki/00Raw 여기 아래에 저장된거 같은데? topics폴더가...",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/project-profile.md": {
|
||||
"mtimeMs": 1778681649000,
|
||||
"size": 484,
|
||||
"mtimeMs": 1778720006542.9683,
|
||||
"size": 515,
|
||||
"lines": 31,
|
||||
"role": "Project Profile",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/README.md": {
|
||||
"mtimeMs": 1778720006541.4622,
|
||||
"size": 412,
|
||||
"lines": 18,
|
||||
"role": "00Raw Chronicle Records",
|
||||
"imports": []
|
||||
},
|
||||
"docs/records/00_Raw/timeline.md": {
|
||||
"mtimeMs": 1778681650000,
|
||||
"size": 238,
|
||||
"lines": 7,
|
||||
"mtimeMs": 1779876330771.1025,
|
||||
"size": 429,
|
||||
"lines": 10,
|
||||
"role": "Project Timeline",
|
||||
"imports": []
|
||||
}
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
{
|
||||
"projectId": "00-raw",
|
||||
"projectName": "00_Raw",
|
||||
"projectRoot": "/Volumes/Data/project/Antigravity/Wiki/10_Wiki/00_Raw",
|
||||
"recordRoot": "/Volumes/Data/project/Antigravity/Wiki/10_Wiki/00_Raw/docs/records/00_Raw",
|
||||
"description": "Auto-created by Project Architecture activation.",
|
||||
"projectRoot": "e:\\Wiki\\2nd\\10_Wiki\\00_Raw",
|
||||
"recordRoot": "e:\\Wiki\\2nd\\10_Wiki\\00_Raw\\docs\\records\\00_Raw",
|
||||
"description": "Auto-detected from workspace folder.",
|
||||
"corePurpose": "",
|
||||
"detailLevel": "standard",
|
||||
"createdAt": "2026-05-13T14:13:57.873Z",
|
||||
"updatedAt": "2026-05-13T14:22:59.615Z"
|
||||
"createdAt": "2026-05-27T10:00:54.426Z",
|
||||
"updatedAt": "2026-05-27T10:05:30.777Z"
|
||||
}
|
||||
|
||||
+24
@@ -0,0 +1,24 @@
|
||||
# Development Log: E:\Wiki\2nd\00_Raw 폴더에 있는 회의록 a,b,e를 wiki화 해주고 저장은 E:\Wiki\2nd\10_Wiki\Topics_me...
|
||||
|
||||
## Purpose
|
||||
Record the implementation or verification outcome from the current conversation.
|
||||
|
||||
## Implementation Summary
|
||||
결론: 세 개의 회의록 파일을 읽어 위키 문서로 재구성한 뒤, 지정하신 `E:\Wiki\2nd\10_Wiki\Topics_meeting` 경로에 각각 저장하겠습니다. 진행 상황: - [v] `회의록 a 2026-05-21.md` 분석 및 위키화 준비 완료 - [v] `회의록 b 2026-05-21.md` 분석 및 위키화 준비 완료 - [v] `회의록 e 2026-05-27.md` 분석 및 위키화 준비 완료 <create_file path="E:\Wiki\2nd\10_Wiki\Topics_meeting\회의록_a_2026-05-21.md"> [위키] 롯데월드 신규 어트랙션 홍보 이머시브 커머스 제안 검토 🔹 핵심 요약 - 날짜: 2026년 05월 08일 - 주제: 3D 파노라마 기반 이머시브 콘텐츠 기획 및 개발 방안 - 핵심 결정: 모바일 우선(Mobile First) 원칙 준수, 미니 게임을 포함한 경험 중심 가치 전달 1. 주요 논의 사항 [콘텐츠 기획] - 3D 파노라마 탐험...
|
||||
|
||||
## Architecture
|
||||
Captured automatically from the assistant response and active project context.
|
||||
|
||||
## Changed Files
|
||||
- 회의록 a 2026-05-21.md
|
||||
- 회의록 b 2026-05-21.md
|
||||
- 회의록 e 2026-05-27.md
|
||||
|
||||
## Dependency Notes
|
||||
No new dependency note was captured automatically.
|
||||
|
||||
## Bugs
|
||||
No bugs recorded.
|
||||
|
||||
## Lessons
|
||||
- Automatic project records should be generated in the background when the turn contains durable project knowledge.
|
||||
@@ -5,3 +5,6 @@
|
||||
|
||||
## 2026-05-13
|
||||
- Auto discussion record created: discussions/2026-05-13_volumes-data-project-antigravity-wiki-10-wiki-00-raw-여기-아래에-.md
|
||||
|
||||
## 2026-05-27
|
||||
- Auto development record created: development\2026-05-27_e-wiki-2nd-00-raw-폴더에-있는-회의록-a-b-e를-wiki화-해주고-저장은-e-wiki-2nd_implementation.md
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# Thinking Chronicle Records
|
||||
|
||||
## Project
|
||||
- ID: thinking
|
||||
- Root: E:\Wiki\2nd\10_Wiki\Topics\Thinking
|
||||
- Record root: E:\Wiki\2nd\10_Wiki\Topics\Thinking\docs\records\Thinking
|
||||
- Detail level: standard
|
||||
|
||||
## Purpose
|
||||
Auto-created by Project Architecture activation.
|
||||
|
||||
## Folders
|
||||
- `planning/`
|
||||
- `discussions/`
|
||||
- `decisions/`
|
||||
- `development/`
|
||||
- `bugs/`
|
||||
- `retrospectives/`
|
||||
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"projectId": "thinking",
|
||||
"projectName": "Thinking",
|
||||
"projectRoot": "E:\\Wiki\\2nd\\10_Wiki\\Topics\\Thinking",
|
||||
"recordRoot": "E:\\Wiki\\2nd\\10_Wiki\\Topics\\Thinking\\docs\\records\\Thinking",
|
||||
"description": "Auto-created by Project Architecture activation.",
|
||||
"corePurpose": "",
|
||||
"detailLevel": "standard",
|
||||
"createdAt": "2026-05-27T10:11:46.765Z",
|
||||
"updatedAt": "2026-05-29T05:15:50.153Z"
|
||||
}
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# ADR: 나 질문이 있어. 지금 우리 아스트라는 제2뇌 정보를 갖고 추론을 하자나. 제2뇌 정보와 추론 단계 사이에 어떠한 로직을 추가를 하면 성능적으로...
|
||||
|
||||
## Status
|
||||
accepted
|
||||
|
||||
## Context
|
||||
나 질문이 있어. 지금 우리 아스트라는 제2뇌 정보를 갖고 추론을 하자나. 제2뇌 정보와 추론 단계 사이에 어떠한 로직을 추가를 하면 성능적으로 개선이 되거나 퀄리티업이 될 수 있는 부분이 있을까?
|
||||
|
||||
## Decision
|
||||
결론: 제2뇌(지식)와 추론 단계 사이에 '맥락적 가중치 부여(Contextual Weighting)'와 '논리적 검증 루프(Verification Loop)' 로직을 추가하면, 단순한 정보 검색을 넘어 지식 간의 연결성을 강화하고 추론의 정확도를 높일 수 있습니다. 현재 아스트라는 저장된 정보를 읽어오는 데는 성공했지만, 그 정보가 '지금 이 질문'과 얼마나 밀접한지, 그리고 그 정보로부터 도출된 결론이 논리적으로 타당한지를 검증하는 단계가 부족할 수 있습니다. 이를 개선하기 위한 3가지 핵심 로직 제안입니다. 1. 맥락적 가중치 로직 (Contextual Relevance Scoring) - 내용: 검색된 지식(Retrieved Knowledge)과 현재 질문(Query) 사이의 '의미적 유사도'뿐만 아니라, '실행 가능성(Actionability)'을 기준으로 점수를 재계산하는 로직입니다. - 효과: 단순히 키м워드가 겹치는 정보가 아니라, 현재 작업(예: 프로젝트 진행 중, ...
|
||||
|
||||
## Reason
|
||||
Captured automatically because the conversation contained decision-oriented language.
|
||||
|
||||
## Alternatives
|
||||
Not captured yet.
|
||||
|
||||
## Consequences
|
||||
- Future prompts should treat this as project context unless the user changes direction.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# ADR: astra의 기억 관리 로직을 어떻게 하면 더 systeatic 하고 효율적으로 관리 할 수 있을지 의견 주면 좋겠어.
|
||||
|
||||
## Status
|
||||
accepted
|
||||
|
||||
## Context
|
||||
astra의 기억 관리 로직을 어떻게 하면 더 systeatic 하고 효율적으로 관리 할 수 있을지 의견 주면 좋겠어.
|
||||
|
||||
## Decision
|
||||
결론: 아스트라의 기억 관리를 체계적(Systematic)이고 효율적으로 만들기 위해서는, 단순히 정보를 저장하는 단계를 넘어 '정보의 계층화(Layering)'와 '생성 주기 관리(Lifecycle Management)'가 결합된 구조를 갖추어야 합니다. 현재 아스트라는 제2뇌(지식)를 읽어와 추론에 활용하고 있지만, 정보가 쌓일수록 '검색 노이즈'가 발생하거나 '과거의 잘못된 정보'가 최신 정보로 업데이트되지 않는 문제가 생길 수 있습니다. 이를 해결하기 위한 3단계 전략을 제안합니다 1. 기억의 계층화 (Memory Layering Strategy) 모든 정보를 동일한 가중치로 관리하지 말고, 중요도와 휘발성에 따라 세 가지 레이어로 분리해야 합니다. - L1: Working Memory (단기/작업 메모리) - 현재 진행 중인 대화, 방금 수행한 `/task`, 지금 읽고 있는 파일의 컨텍스트. - 특징: 매우 빠르고 가벼우며, 세션이 끝나면 휘발되거나 아카이브 대상이 됨. ...
|
||||
|
||||
## Reason
|
||||
Captured automatically because the conversation contained decision-oriented language.
|
||||
|
||||
## Alternatives
|
||||
Not captured yet.
|
||||
|
||||
## Consequences
|
||||
- Future prompts should treat this as project context unless the user changes direction.
|
||||
+19
@@ -0,0 +1,19 @@
|
||||
# ADR: 그러면 아스트라가 제2뇌의 지식을 사용하는데 그 많은 지식을 가져올때 어떻게 하면 더 연관성이 깊고 의미있는 지식들을 발굴해서 사용 할 수 있게...
|
||||
|
||||
## Status
|
||||
accepted
|
||||
|
||||
## Context
|
||||
그러면 아스트라가 제2뇌의 지식을 사용하는데 그 많은 지식을 가져올때 어떻게 하면 더 연관성이 깊고 의미있는 지식들을 발굴해서 사용 할 수 있게 할 수 있을까?
|
||||
|
||||
## Decision
|
||||
결론: 방대한 제2뇌 지식 중에서 현재 맥락과 가장 밀접하고 가치 있는 정보를 찾아내기 위해서는, 단순한 '키워드 검색'을 넘어 '의미적 연결성(Semantic Linkage)'과 '맥락적 중요도(Contextual Importance)'를 계산하는 로직이 핵심입니다. 단순히 많은 양의 지식을 가져오는 것이 아니라, "지금 이 순간 가장 의미 있는" 정보를 발굴하기 위한 3가지 기술적 전략을 제안합니다. 1. 그래프 기반의 관계형 검색 (Graph-based Retrieval) 지식과 지식 사이의 '관계'를 정의하는 것입니다. - 개념: 지식을 단순한 문서 단위가 아니라, `Entity(주체)`와 `Relation(관계)`을 가진 노드(Node)로 취급합니다. 예를 들어, "A 프로젝트"라는 노드와 "배포 이슈"라는 노드를 `has_issue`라는 관계로 연결하는 것입니다. - 효리: 질문이 들어왔을 때, 질문에 포함된 키키워드뿐만 아니라 그 키워드와 연결된 '주변 노드(Neighb...
|
||||
|
||||
## Reason
|
||||
Captured automatically because the conversation contained decision-oriented language.
|
||||
|
||||
## Alternatives
|
||||
Not captured yet.
|
||||
|
||||
## Consequences
|
||||
- Future prompts should treat this as project context unless the user changes direction.
|
||||
+22
@@ -0,0 +1,22 @@
|
||||
# Development Log: 아.. 참조해야할 레퍼 문서를 다시 줄께. E:\Wiki\2nd\10_Wiki\Topics\Thinking & Reasoning\3C 분석.md
|
||||
|
||||
## Purpose
|
||||
Record the implementation or verification outcome from the current conversation.
|
||||
|
||||
## Implementation Summary
|
||||
직전 답변에서 제가 `p-reinforce`의 핵심인 '추론 가능한 인사이트 추출'이라는 내용적 규칙은 별도의 Skill 문서나 시스템 프롬프트에 정의된 원칙을 따른다고 말씀드렸지만, 이제 주신 `3C 분석.md` 문서를 통해 `p-reinforce`가 지향해야 할 구조적 분석 도구(Framework)를 명확히 인지했습니다. 결론 수정: `p-reinforce` 규칙의 적용 범위가 '단순 추론'에서 `3C 분석(Customer, Competitor, Company)`이라는 '구조화된 전략 분석'으로 확장되었습니다. 따라서 앞으로의 위키화 작업은 단순한 인사이트 도출을 넘어, 회의 내용이 3C 프레임워크 내에서 어떤 위치(고객 요구사항, 경쟁 우위 확보, 자사 역량 등)에 있는지 명확히 분류하여 작성하겠습니다. 이 정보가 기존 작업에 미치는 영향: - 기존 작업 유지: 이미 완료된 위키화 문서들은 `3C` 관점의 분석 요소(예: 롯데온 피드백 = Customer, iOS 최적화 = C...
|
||||
|
||||
## Architecture
|
||||
Captured automatically from the assistant response and active project context.
|
||||
|
||||
## Changed Files
|
||||
- 3C 분석.md
|
||||
|
||||
## Dependency Notes
|
||||
No new dependency note was captured automatically.
|
||||
|
||||
## Bugs
|
||||
No bugs recorded.
|
||||
|
||||
## Lessons
|
||||
- Automatic project records should be generated in the background when the turn contains durable project knowledge.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Project Profile
|
||||
|
||||
## Project Name
|
||||
Thinking
|
||||
|
||||
## Description
|
||||
Auto-created by Project Architecture activation.
|
||||
|
||||
## Project Root
|
||||
E:\Wiki\2nd\10_Wiki\Topics\Thinking
|
||||
|
||||
## Record Root
|
||||
E:\Wiki\2nd\10_Wiki\Topics\Thinking\docs\records\Thinking
|
||||
|
||||
## Core Purpose
|
||||
Not captured yet.
|
||||
|
||||
## Target Users
|
||||
Not captured yet.
|
||||
|
||||
## Avoid Directions
|
||||
Not captured yet.
|
||||
|
||||
## Record Detail Level
|
||||
standard
|
||||
|
||||
## Created
|
||||
2026-05-27T10:11:46.765Z
|
||||
|
||||
## Updated
|
||||
2026-05-27T10:11:46.785Z
|
||||
@@ -0,0 +1,16 @@
|
||||
# Project Timeline
|
||||
|
||||
## 2026-05-27
|
||||
- Project Chronicle record folder initialized for Thinking.
|
||||
|
||||
## 2026-05-27
|
||||
- Auto development record created: development\2026-05-27_아-참조해야할-레퍼-문서를-다시-줄께-e-wiki-2nd-10-wiki-topics-thinking-reas_implementation.md
|
||||
|
||||
## 2026-05-29
|
||||
- Auto decision record created: decisions\ADR-0001-나-질문이-있어-지금-우리-아스트라는-제2뇌-정보를-갖고-추론을-하자나-제2뇌-정보와-추론-단계-사이에-어떠.md
|
||||
|
||||
## 2026-05-29
|
||||
- Auto decision record created: decisions\ADR-0002-astra의-기억-관리-로직을-어떻게-하면-더-systeatic-하고-효율적으로-관리-할-수-있을지-의견-주.md
|
||||
|
||||
## 2026-05-29
|
||||
- Auto decision record created: decisions\ADR-0003-그러면-아스트라가-제2뇌의-지식을-사용하는데-그-많은-지식을-가져올때-어떻게-하면-더-연관성이-깊고-의미있는.md
|
||||
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"id": "72340e7d-8c57-4528-9c83-6c000a67210e",
|
||||
"sessionId": "task_1779857095907",
|
||||
"title": "/meet D:\\Meet\\e.txt",
|
||||
"summary": "/meet D:\\Meet\\e.txt /meet D:\\Meet\\e.txt",
|
||||
"keyDecisions": [],
|
||||
"topics": [
|
||||
"meet",
|
||||
"txt"
|
||||
],
|
||||
"projectContext": "e:\\Wiki",
|
||||
"timestamp": 1779872373189,
|
||||
"duration": 0,
|
||||
"messageCount": 4
|
||||
}
|
||||
+18
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"id": "9ae86e98-1adc-4c2d-8303-839d8586eeca",
|
||||
"sessionId": "task_1779857095907",
|
||||
"title": "/youtube https://youtu.be/Qu4X0auqnqA?si=S7DCk09dRGNg4I0k...",
|
||||
"summary": "/youtube https://youtu.be/Qu4X0auqnqA?si=S7DCk09dRGNg4I0k info /meet D:\\Meet\\e.txt /meet D:\\Meet\\e.txt",
|
||||
"keyDecisions": [
|
||||
"중에 실패한 것의 공통점은 무엇인가? 다음 업데이트 때 반드시 넣어야 하는",
|
||||
"과정을 문서로 남기지 않는 문화. 저는 스타트업에서도 많이 보고 들었습니다. 이런 관행은 AI 시대에는 큰 약점이 됩니다. AI가 학습할 수 있는 데이터가 남지 않기 때문이죠."
|
||||
],
|
||||
"topics": [
|
||||
"meet",
|
||||
"txt"
|
||||
],
|
||||
"projectContext": "e:\\Wiki",
|
||||
"timestamp": 1779871266198,
|
||||
"duration": 0,
|
||||
"messageCount": 6
|
||||
}
|
||||
@@ -0,0 +1,33 @@
|
||||
[위키] 롯데월드 신규 어트랙션 이머시브 커머스 제안 검토
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 2026년 05월 08일
|
||||
- 주제: 3D 파노라마 기반 콘텐츠 기획 및 개발 구현 방안 논의
|
||||
- 핵심 키워드: #이머시브_커머스 #모바일_First #유니티_웹포팅
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
본 회의는 단순한 기능 구현을 넘어, 사용자의 '경험'을 어떻게 비즈니스(예매)로 연결할 것인가에 대한 전략적 결정을 포함함. 3D 파노라마라는 고사양 콘텐츠를 웹 환경에서 얼마나 가볍고 안정적으로 구동하느냐가 프로젝트 성패의 핵심임.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. 콘텐츠 전략: 체험에서 전환으로
|
||||
|
||||
- 현황: 3D 탐험(70%)과 미니 게임(20%)의 결합 구조.
|
||||
- 추론: 단순 정보 전달형 페이지는 이탈률이 높을 것으로 예상됨. 따라서 '미션 수행 $\rightarrow$ 보상 $\rightarrow$ 예매 페이지 랜동'으로 이어지는 유기적 플로우 설계가 필수적임.
|
||||
|
||||
2. 기술적 제약과 대응
|
||||
|
||||
- 환경: 모바일 접속 비중(95%)이 압도적이므로, 저사양 기기에서도 끊김 없는 웹 렌더링 성능 확보가 최우선 과제임.
|
||||
- 리스크: 유니티 웹 포팅 시 발생하는 로딩 속도 및 메모리 점유율 이슈에 대한 사전 테스트 필요.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 리소스 공급망 리스크: 롯데월드 측의 영상/이미지 리소스 제공 지연 시 개발 일정 차질 불가피 $\rightarrow$ 대응: 샘플 에셋을 활용한 선행 개발 진행.
|
||||
- 보안 및 유출: 신규 어트랙션 정보 사전 노출 우려 $\rightarrow$ 대응: 런칭 전까지 보안 가이드라인 준수.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 스포티 니치 성능 테스트 및 피드백 (즉시)
|
||||
- [ ] 제안팀: 롯데월드 측 상세 요구사항 확정 (차기 미팅)
|
||||
@@ -0,0 +1,33 @@
|
||||
[위키] 스포티앤리치 서비스 개선 및 롯데온 피드백 대응
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 확인 불가 (피드백 대응 회의)
|
||||
- 주제: 롯데온 요구사항 반영 및 UI/UX 최적화
|
||||
- 핵심 키워드: #UI_개선 #iOS_최적화 #데이터_정합성
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
기존 서비스의 안정성을 유지하면서, 외부 플랫폼(롯데온)의 요구사항을 어떻게 기술적으로 수용할 것인가에 대한 논의임. 특히 사용자 경험(UX)의 파편화를 막기 위한 데이터 유지 전략이 중요함.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. UI/UX 최적화: 가시성 확보
|
||||
|
||||
- 현황: 가격 표기 방식 변경 및 버튼 위치 조정.
|
||||
- 추론: 구매하기 버튼을 상단으로 이동시키는 것은 텍스트 겹침 방지뿐만 아니라, 모바일 사용자의 '한 손 조작' 편의성을 극대화하려는 의도임.
|
||||
|
||||
2. 기술적 가이드라인: 성능 한계 명시
|
||||
|
||||
- 현황: 특정 iOS 기기에서의 속도 저하 이슈 대응.
|
||||
- 추론: 무조건적인 최적화는 개발 공수를 폭증시키므로, '최소 사양 가이드'를 통해 기술적 책임 범위를 명확히 설정하는 전략이 필요함.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 데이터 휘발성: 뒤로가기 시 스타일링 숍 세팅값 초기화 문제 $\rightarrow$ 대응: 쿠키 또는 LocalStorage를 활용한 상태 유지 로직 검토.
|
||||
- 개발 부하: 360도 회전 등 고사양 기능 도입 시 비용 상승 $\rightarrow$ 대응: 현재는 AI 이미지 샷 기반의 가벼운 방식으로 대응 범위를 제한함.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 구매하기 버튼 위치 및 문구 수정 (차주 초)
|
||||
- [ ] 개발팀: 채널 코드 확보 및 QA 진행 (다음 주 중)
|
||||
@@ -0,0 +1,34 @@
|
||||
[위키] .Net 이슈 대응 및 운영 프로세스 점검
|
||||
|
||||
📋 개요
|
||||
|
||||
- 날짜: 2026년 05월 27일
|
||||
- 주제: 라이브 빌드 QA 현황 및 패치 노트 관리 체계 수립
|
||||
- 핵심 키워드: #라이브_QA #패치노트 #운영_프로세스
|
||||
|
||||
🚀 핵심 요약 (P-Reinforce Insight)
|
||||
|
||||
단순한 버그 수정을 넘어, 개발팀의 기술적 성과를 어떻게 '유저가 이해할 수 있는 언어'로 변환하여 전달할 것인가에 대한 운영 체계(Governance) 확립이 목적임.
|
||||
|
||||
🔍 주요 논의 및 추론
|
||||
|
||||
1. 라이브 업데이트 전략
|
||||
|
||||
- 현황: 일본 지역 로그인/칼리브레이션 오류 해결을 위한 코드 수정 중.
|
||||
- 추론: '오늘 QA 완료 $\rightarrow$ 내일 반영'이라는 타이트한 일정을 유지하기 위해서는, 개발팀의 검증 데이터가 즉시 기획팀으로 공유되는 파이프라인이 필수적임.
|
||||
|
||||
2. 운영 프로세스 정립: 정보의 재구성
|
||||
|
||||
- 현황: 패치 노트 작성 시 '개발자 초안 $\rightarrow$ 기획자 수정' 절차 도입.
|
||||
- 추론: 기술적인 용어(Technical terms)를 유저 친화적인 언어로 변환함으로써, 업데이트에 대한 사용자의 심리적 저항을 줄이고 서비스 신뢰도를 높일 수 있음.
|
||||
|
||||
⚠️ 리스크 및 대응 방안
|
||||
|
||||
- 보안 취약점: 서버 팀장의 비밀번호 관리 방식 등 보안 이슈 $\rightarrow$ 대응: 주기적인 정책 변경 및 AI 기반 해킹 대응 체계 고려.
|
||||
- 글로벌 이슈: 일본 법인 내 특정 오류 지속 발생 $\rightarrow$ 대응: 테스트 플라이트 등록을 통한 신속한 재검증.
|
||||
|
||||
✅ 액션 아이템
|
||||
|
||||
- [ ] 개발팀: 라이브 빌드 QA 완료 및 업데이트 요청 (오늘 중)
|
||||
- [ ] 김원일 이사: 홍 실장 대상 테스트 플라이트 지원 (즉시)
|
||||
- [ ] 성혜(기획): 운영 툴 관리 및 강제 업데이트 여부 판단 (상시)
|
||||
Reference in New Issue
Block a user