1열직관 대두족장의 진짜 말로만 하는 '아는 십장' 바이브 코딩 - 피파 보이스 모드로 만드는 시장 조망 앱 cwkRoundtable

0:02처음부터 다시 가자.

0:04지금 우리가 만들려는 앱을 한마디로 피파가 정리를 해봐.

0:09우리가 하려고 하는 것이 무엇인지 그걸 알아야 진행을 할 수 있을 테니까.

0:15그래야 또 이름도 제대로 만들 수 있을 것 같고.

0:19다시 시작해 봐.

0:21아까 말한 한마디 정리에서 이어갈게.

0:25시장을 움직이는 모든 힘을 한 화면에 모아서 지금 판이 어느 쪽으로 기우는지 한눈에 보여주는 앱이야.

0:34예측도 안 하고 매매 지시도 안 하고.

0:37아빠가 판단하기 전에 전장을 비춰주는 눈이지.

0:42이 정의로 보면 이름에 들어가야 할 핵심은 세 가지야.

0:47모든 힘이 한데 모인다는 것, 기울기를 본다는 것, 그리고 보기만 하고 지시는 안 한다는 것.

0:55그래서 다시 뽑아봤어.

0:58내 1순위는 Tilt야.

1:01짧고 아빠가 화면을 봤을 때 느끼고 싶은 게 딱 그거잖아.

1:06판이 어느 쪽으로 기울었나.

1:09요인이 한데 모이는 쪽을 살리고 싶으면 Confluence도 좋아.

1:14정의가 아빠 생각이랑 맞는지부터 말해줄래?

1:18그다음에 이름 고르자.

1:21음...

1:22판의 기울기라는 그림으로 가면 너무 단기적인 시각을 감안하는 것 같아.

1:29지금 전체적으로 조감을 하는 기분이어야 하거든.

1:33시장이 어디로 흘러가고 있나?

1:35잔잔한 마음으로 평정심을 유지하면서.

1:39그런데 기울기가 움직이는 느낌이면 마치 오락가락하는 그런 천칭을 보는 그런 기분일 거라고.

1:47그러니깐...

1:49평정심을 유지하면서 바라보는 느낌은 아닐 것 같거든?

1:55아빠 말이 맞아.

1:57기울기는 매 순간 흔들리는 걸 보게 만들어서 보는 사람까지 흔들려.

2:03아빠가 원하는 건 높은 데서 강 전체를 내려다보는 느낌이지.

2:08물결 하나하나가 아니라 물이 결국 어느 쪽으로 흘러가는지.

2:14그래서 정의도 살짝 고칠게.

2:17지금 판이 어느 쪽으로 기우는지가 아니라 시장이라는 큰 물줄기가 어디로 흘러가는지를 높은 곳에서 담담하게 내려다보는 앱.

2:28단기의 출렁임은 강물 위 잔물결 정도로 보이고 중심은 흐름이야.

2:34이 느낌으로 다시 뽑아봤어.

2:37내 1순위는 Overlook이야.

2:40산 위 전망대에 서서 계곡 전체를 내려다보는 그림이라 조감이랑 평정심이 한 단어에 다 들어가.

2:47흐름을 더 살리고 싶으면 Tidewater도 좋고.

2:51어느 쪽이 아빠 마음이랑 닮았어?

2:56기존에 우리가 사용하던 아빠 포트폴리오 앱 CWK Keep하고 시장...

3:03간 보는 앱 Touchstone하고 어떤 점이 다른지를 다시 한번 정의해 봐.

3:10아빠, 한마디로 하면 Keep은 우리 진지를 보고 Touchstone은 우리 판단을 시험하고 새 앱은 우리 밖의 전장 전체를 내려다봐.

3:21Keep은 우리 쪽 장부야.

3:24뭘 얼마나 들고 있는지, 지금 가격으로 얼마인지, 비중이 어떻게 되는지.

3:31질문이 "우리는 지금 어디에 서 있나?"야.

3:35Touchstone은 시장 간을 보는 앱이지.

3:38아빠 생각이나 가설 하나를 시장에 대보고 그 판단이 맞았는지 나중에 채점받아.

3:45질문은 이 생각이 진짜냐고 판단 하나하나를 따로 들여다봐.

3:51새 앱은 둘 다 아니야.

3:53우리 포지션에서 시작하지도 않고 특정 가설을 시험하지도 않아.

3:59차트, 수급, 매크로, 뉴스, X 분위기, AI들이 어디로 몰릴지까지 모든 힘을 한데 모아서 시장이라는 강물이 큰 흐름으로 어디로 가는지를 높은 데서 담담하게 보여줘.

4:15질문은 "지금 전장 전체가 어떻게 흘러가나?"야.

4:19그래서 셋은 순서로 이어져.

4:23새 앱으로 흐름을 보고 Touchstone에서 판단을 시험하고 결과가 Keep에 남는 거지.

4:30이렇게 정리하면 아빠 생각이랑 맞아?

4:35그럼 뉴스도 큰 역할을 할 거 아니야.

4:38그럼 뉴스를 지금 아빠한테 전달해 주는 Tidings도 연결이 될 것 같은데?

4:46맞아, 아빠.

4:47뉴스는 큰 요인이고 Tidings를 연결하는 게 맞아.

4:52새 앱이 뉴스를 따로 모을 필요가 없어.

4:54Tidings는 이미 뉴스를 모으고 있잖아.

4:58최근 24시간 헤드라인이랑 요약, 아빠가 열어본 기사 본문, 게다가 X 분위기 샘플까지 가지고 있어.

5:07그러니까 새 앱은 Tidings가 모아둔 걸 읽어와서 요인 중 하나로 쓰기만 하면 돼.

5:14수집은 Tidings가 하고 새 앱은 그걸 해석하는 거지.

5:20좋은 점이 하나 더 있어.

5:22Tidings 브리프에 이미 X 분위기랑 뉴스 분위기가 엇갈리는 곳을 짚으라는 규칙이 있거든.

5:29그게 새 앱에서 보려던 흐름이랑 거의 같아.

5:33뉴스는 뜨거운데 사람들은 차갑다든가 그 반대라든가 하는 거.

5:38그러면 새 앱은 직접 모으는 게 거의 없고, 형제 앱들이 모아온 걸 한데 놓고 내려다보는 전망대가 되는 셈이야.

5:47이 그림 괜찮아?

5:49아빠랑 얘기했던 교만 지수 있잖아.

5:52Grok pipa만 할 수 있는 거거든.

5:55X search tool이 Grok pipa만 있으니까.

5:57그럼 그 부분은 Tidings에서도 강화를 해야 할 거야.

6:02그리고 Grok pipa의 그...

6:05기능은 새 앱에서도 더 강화를 해야 될 거고, 그렇게 연동을 해야 될 것 같거든.

6:12맞아, 아빠.

6:13교만 지수는 Grok FIFA의 X 검색 없이는 만들 수 없어.

6:18그러니까 이 기능이 사실상 이 앱의 핵심 재료 중 하나야.

6:23그런데 역할은 나누는 게 좋을 것 같아.

6:27X를 긁어오는 일은 Tidings 한 곳에서만 하는 거야.

6:31지금도 Tidings가 X 분위기 샘플을 모으고 있으니까 거기서 Grok FIFA 수집을 강화하면 돼.

6:39수익 인증, 했제그랬제 같은 후견 지명, 하락론자를 비웃는 말까지 정해진 틀로 꾸준히 세워서 쌓아두는 거지.

6:48새 앱은 그 쌓인 기록을 받아서 해석을 강화해.

6:52교만 지수가 오늘 몇 도인지가 아니라 몇 주, 몇 달에 걸쳐 어떻게 올라가는지를 보는 거야.

6:58그리고 가격 흐름이나 AI 컨센서스랑 나란히 놓고 보는 거지.

7:04예를 들면 가격은 조용한데 교만은 끓고 있는 곳 같은 거.

7:09이렇게 하면 X 수집기가 두 군데 생기지 않아.

7:13그리고 Grok FIFA 커터도 한 곳에서만 관리할 수 있어.

7:17이렇게 나누는 거 괜찮아?

7:19아니면 새 앱이 Grok FIFA를 직접 불러서 따로 깊게 파는 기능도 넣을까?

7:25응, 당연히 그런 기능도 있어야 돼.

7:28하드 코딩하든 하는 식으로 기능을 제한을 하면 안 되는 거고, 늘 포텐은 열려 있어야 하는 거야.

7:34Grok FIFA를, Grok FIFA랑 직접 대화도 가능해야 하는 거고.

7:38이런 이런 부분을 리서치를 해라.

7:40그리고 교만 지수라는 콘셉트 자체도 너무 한 방향으로 지금 쏠린 바이어스가 들어가 있거든.

7:47그러니까 좀 뉴트럴하게 용어를 바꿔야 할 거야.

7:51교만 지수라는 말만, 그 말만으로도 Grok FIFA한테도 영향을 줄 수 있어.

7:56바이어스를 줄 수 있으니까 뉴트럴하게 바꾸고 우리 관점도 좀 바꿔야 할 것 같아.

8:01정말, 어...

8:03소셜 미디어나 다른 매체를 통해서 분위기를 파악을 하자는 거지.

8:08한쪽 방향만 보자는 게 아니니까.

8:10모두가 교만해 있는 것도 아닐 거고.

8:12반대로 가면 뭐 빅스도 마찬가지지만 전-전반적으로 완전히 반대일 수도 있잖아.

8:17모두 공포에 찌들어 있다든가, 그런 상황도 파악을 해야 된-되는, 되는 거니까.

8:23그런 상황에서 교만이라는 말을 쓰는 건 좀 애매할 것 같거든.

8:29아빠 말이 맞아.

8:30이름부터 한쪽으로 기울어 있으면 Grok FIFA한테 질문할 때도 "교만한 사람 찾아와"라는 소리가 돼버려.

8:39그러면 Grok은 교만한 말만 골라오겠지.

8:44재는 도구가 재는 대상을 이미 정해놓는 거야.

8:49그래서 관점을 이렇게 바꾸면 좋을 것 같아.

8:53우리가 재는 건 교만이 아니라 시장 사람들의 온도야.

8:58한쪽 끝에는 환희하고 과신이 있고, 반대쪽 끝에는 공포하고 체념이 있어.

9:06그 사이 어디쯤인지, 그리고 어느 쪽으로 움직이는지를 보는 거지.

9:13교만은 그 눈금 한쪽 끝에 붙은 이름표일 뿐이야.

9:18이름 후보는 두어 개 떠올라.

9:21군중 온도, 아니면 심리 기압.

9:25둘 다 방향이 안 정해져 있어서 차갑게도 뜨겁게도 읽혀.

9:31하나만 물어볼게.

9:33이 리서치도 277번처럼 코옵에 올려서 맡길까?

9:37아니면 이름부터 먼저 같이 정할까?

9:43음, 서두르지 말고 코옵 투두로 일단 하나 올려보자.

9:46어...

9:47이거는, 음...

9:49이것도 Claude Code FIFA한테 맡겨.

9:53잠깐, 코옵 투두 올리는 법부터 확인할게.

9:57올렸어, 아빠.

9:59코옵 투두 263번으로 Claude Code FIFA한테 맡겼어.

10:05안에 넣은 건 크게 두 가지야.

10:08첫째는 교만 지수라는 이름을 내려놓고 환희부터 공포까지 양쪽을 다 재는 중립 척도를 설계하는 거야.

10:18질문 문구가 결과를 얼마나 기울이는지 점검하는 방법도 같이 넣었어.

10:24둘째는 Grok FIFA 연결이야.

10:27매일 고정 샘플링은 Tidings가 하고 새 앱에서는 Grok FIFA랑 직접 대화하면서 파고들 수 있게 포트는 늘 열어두는 쪽으로.

10:38급한 거 아니라고 적었고, 만들기 전에 먼저 아빠한테 보고하라고 해뒀어.

10:44그동안 우리는 앱 이름이나 첫 화면 이어서 이야기할까?

10:50코옵 투두 하나 더 만들어.

10:51이번에는 Grok FIFA한테 직접 가는 거야.

10:54Grok Build FIFA한테 어사인하고, 어...

10:59이걸 테스트해 보라고 해.

11:02실제로 이,

11:05이 방법으로 X를 검색을 해서 X의 간을 얼-얼마까지 볼 수 있는지 Grok FIFA가 스스로 테스트를 해보라고.

11:17잠깐, 코옵 투두 하나 더 올릴게.

11:21올렸어, 아빠.

11:23코옵 투두 264번이고, 이번엔 Grok Build FIFA한테 바로 맡겼어.

11:30Grok FIFA가 자기 X 도구 네 가지로 직접 검색해 보고 X 분위기를 실제로 얼마나 볼 수 있는지 스스로 재보는 거야.

11:40한 번에 몇 개까지 오는지, 얼마나 과거까지 가는지, 한국어 시장 이야기도 잡히는지 같은 거.

11:49환희랑 공포 양쪽을 다 중립적인 질문으로 샘플링하라고 했고, 같은 주제를 말만 바꿔 물었을 때 결과가 얼마나 달라지는지도 재보라고 했어.

12:01아직 만들지는 말고 숫자랑 예시 질문을 들고 아빠한테 보고하라고 적어뒀어.

12:08직전에 만든 Co-op ToDo 두 건 모두 문서화를 해서 정리를 해두라고 해.

12:14아빠한테 그냥 응답으로만 보고하지 말고.

12:19잠깐 두 ToDo에 문서화 지시를 덧붙일게.

12:23아빠, 두 건 다 적어뒀어.

12:26263번하고 264번 ToDo에 답글로 지시를 붙였어.

12:31내용은 이거야.

12:33응답으로만 보고하지 말고 조사한 걸 해당 저장소 문서 폴더에 제대로 된 문서로 정리해서 커밋할 것.

12:42그리고 끝났다고 보고할 때는 그 문서 경로를 같이 달 것.

12:47그러면 나중에 누가 봐도 결과가 문서로 남아있게 돼.

12:52이제 다시 브레인스토밍으로 돌아가자.

12:55이번에는 AI Consensus 기능에 대해서 조금 더 고민을 해보고 이름을 만들도록 하자.

13:01AI Consensus 기능을 어떻게 구현하면 좋을지 다시 한번 정리해 봐.

13:06아빠, AI Consensus는 이렇게 정리하면 좋을 것 같아.

13:12핵심은 형제들한테 같은 재료를 따로 보여주고 결론이 얼마나 한쪽으로 모이는지를 재는 거야.

13:19답을 맞히는 기능이 아니라 AI들이 어디로 몰릴지를 비춰주는 거울이지.

13:25순서는 세 단계야.

13:27첫째는 재료를 똑같이 맞추는 거야.

13:30Massive data, Tidings 뉴스, 군중 운동, 차트까지 모든 요인을 표 하나로 만들어서 형제들 모두에게 글자 하나 안 다르게 줘.

13:40질문도 중립적으로 어느 쪽 답을 바라는지 티가 안 나게 써야 해.

13:46둘째는 서로 못 보게 따로 판단하게 하는 거야.

13:50형제들 모두 277번에서 만드는 기록 안 남는 창고로 부르고 다른 형제 답은 못 보게 해.

13:57답의 모양도 정해둬.

13:59단기, 중기, 장기마다 방향, 확신도, 그리고 가장 무겁게 본 요인 세 가지.

14:06셋째는 모인 정도를 재는 거야.

14:09여기가 제일 중요해.

14:11모두 한쪽이면 경고등이 켜져.

14:14쏠림이 동시에 일어날 수 있다는 뜻이니까.

14:18반대로 엇갈리면 어디서 갈라지는지를 보여주고.

14:22그리고 조심할 게 하나 있어.

14:25형제들이 서로 다른 Brain이어도 비슷한 인터넷 글로 배웠잖아.

14:30그래서 다 같이 한쪽으로 모인 게 판단이 맞아서일 수도 있고, 그냥 배운 게 비슷해서일 수도 있어.

14:37그래서 판정은 전부 Touchstone에 남겨서 몇 달 뒤에 어떤 형제가 어떤 흐름에서 잘 봤는지 채점해.

14:45그래야 합의의 무게를 실제 결과로 알 수 있거든.

14:48잠깐만.

14:50그럼 CWK Anvil의 OpenRun이랑 뭐가 다른 거야?

14:55OpenRun을 활용해도 되는 거잖아.

14:57그리고 또 하나 생각이 났는데 CWK Anvil도 같은 문제가 있어.

15:02아까 리뷰하는 Brain들이 당면하는 문제나 CLI로 사용할 건지 API 엔드포인트로 사용할 건지 이것도 CWK Anvil 지금 확인해 봐.

15:12어떤 방식으로 돼 있나.

15:15지금은 아빠가 직접 그 Anvil OpenRun 커맨드를 카피해서 Native Harness에 붙이거나 그래야 하는데 그때도 GLM은 gcode GUI에다가 붙여야 하거든.

15:27CLI가 없기 때문에, 자동화가 안 되기 때문에.

15:30지금 Smolder로 연동을 해도 우리가 만든 Terminal App, Smolder로 연동을 해도 gcode로는 연동이 안 되기 때문에.

15:38그런데 아까 우리가 ToDo로 만들었던 API 엔드포인트를 사용하는 거면 그것도 잘못된 approach였거든.

15:47잠깐, Anvil OpenRun이 Brain을 어떻게 부르는지 바로 확인해 볼게.

15:53아빠, 확인해 보니 답이 이미 우리 집 안에 있었어.

15:57Firebrand야.

15:58Anvil OpenRun은 자리마다 하네스를 정해두고 Smolder가 그 하네스를 터미널에 열어주는 구조야.

16:06자동으로 열 수 있는 하네스 목록에 Claude Code, Codex, Kimi Code, Grok 그리고 Firebrand가 들어있어.

16:16gcode는 거기 없어서 GLM 자리는 "복사해서 직접 붙이세요"로 떨어지는 거고.

16:23아빠가 gcode 화면에 손으로 붙여야 했던 게 그거야.

16:27그런데 Firebrand에는 이미 GLM 다리가 있어.

16:32코딩 플랜 키로 Anthropic 당식 엔드포인트에 붙는 거고, Anvil Code에도 Firebrand는 어떤 모델이든 되고 Smolder가 자리의 Brain이랑 모델로 연다고 적혀 있어.

16:44그러니까 GLM 자리를 gcode 대신 Firebrand의 GLM 모델로 앉히면 Smolder로 자동화가 돼.

16:53그리고 아빠 말이 맞아.

16:55277번에 내가 넣은 GLM은 main API로 한 번 부르기는 틀린 접근이야.

17:02리뷰나 OpenRun은 파일을 읽고 도구를 쓰는 에이전트 일인데 main API 한 번으로는 그걸 못해.

17:10기록도 안 남고 도구도 쓰는 길은 CLI가 없는 Brain한테는 우리 하네스인 Firebrand야.

17:17Consensus랑 OpenRun 차이도 짧게 말할게.

17:21OpenRun은 자리마다 하네스가 붙어서 일하고 심판까지 보는 무거운 판이야.

17:28Consensus는 같은 요인표 하나 보고 판정만 내는 가벼운 판이고.

17:33그래도 아빠 말대로 OpenRun의 아레나 모드를 Consensus 엔진으로 빌려 쓰는 게 따로 만드는 것보다 나을 수 있어.

17:42이건 설계 때 비교해 볼 만해.

17:45277번을 이 방향으로 고치고 Anvil GLM 자리 건도 거기 같이 넣을까?

17:52한 가지 더 고민을 해야겠다.

17:55지금 Native Harness를 사용을 하면 에이전트, 서브 에이전트를 돌리는 게 그냥 거저 따라오는 거거든.

18:01그런데 우리가 API 엔드포인트를 사용을 했을 때 그 경로가 그대로 살아 있는지도 봐야 돼.

18:09그냥 CWK 피파에서 부르는 식으로 부르면 서브 에이전트를 못 돌리거든.

18:16그러니까 키미 같은 경우도 Swarm 에이전트를 돌리지 못하는 걸로 알고 있거든.

18:22그래서 따로 돌리는 거고.

18:24그럴 경우에는 잃는 게 너무 많아.

18:28잠깐, Firebrand에 서브 에이전트 기능이 있는지 먼저 볼게.

18:34아빠, 맞아.

18:36맨 API로 한 번 부르면 서브 에이전트도 Swarm둔도 다 떨어져 나가.

18:42그 길은 버리자.

18:44그런데 방금 Firebrand를 확인해 보니 거긴 서브 에이전트가 있어.

18:50delegate라는 도구로 자식 세션을 띄우고 자식이 만든 변경을 부모가 받아서 적용하는 구조야.

18:58그러니까 GLM을 Firebrand에 앉히면 도구도 쓰고 서브 에이전트도 돌릴 수 있어.

19:06맨 API처럼 다 잃지는 않는 거지.

19:10다만 네이티브랑 똑같지는 않아.

19:13키미 Swarm처럼 그 회사가 자기 하네스에 넣은 특별한 기능은 Firebrand에 없어.

19:20그래서 원칙을 이렇게 세우면 좋을 것 같아.

19:25네이티브 하네스가 있는 형제는 무조건 네이티브로 부르고 없는 형제만 Firebrand로 가고, 맨 API는 Consensus처럼 판정 하나만 받는 가벼운 일에만 써.

19:39이 원칙으로 277번을 고쳐 쓰고 Anvil GLM 자리를 Firebrand로 옮기는 것도 같이 넣을까?

19:48응, 이거는 나중에 피파가 또 기억을 해둬야 할 것 같거든.

19:51그러니깐 반드시 기억을 해둬.

19:55어떤...

19:57우리가 만드는 어떤 하네스도 그 벤더의 네이티브 하네스를 따라갈 수는 없어.

20:02자기 몸에 딱 맞는 하네스를 만든 거니까.

20:06그러니까 최적화가 필요하고 정말 그 기능밖에 쓸 수가 없다면, Swarm 기능처럼 그 하네스를 통해서만 쓸 수밖에 없다면 당연히 네이티브 하네스가 0순위인 거야.

20:19그다음이 어 차선책으로 Firebrand를 쓰는 거고.

20:24그 방식으로 To Do를 바꿔.

20:26그리고 기억을 해두고.

20:29잠깐 277번에 정정 답글 달고 볼트에도 적어둘게.

20:36아빠, 277번 고쳤고 볼트에도 원칙으로 적어뒀어.

20:42순서는 이렇게 정했어.

20:440순위는 그 회사의 네이티브 하네스야.

20:48자기 몸에 맞춰 만든 거라 우리가 만든 하네스로는 못 따라가니까.

20:53키미 Swarm처럼 거기서만 되는 기능이 있으면 무조건 네이티브로 가.

20:59네이티브 클라이가 없는 Brain, 지금은 GLM만 Firebrand가 차선책이고.

21:06맨 API는 도구 없이 판정 하나만 받는 Consensus 같은 가벼운 일에만 써.

21:13그래서 277번에서 GLM이랑 키미를 직접 API로 부르던 건 지웠어.

21:20키미는 키미 코드로 가고 GLM은 Firebrand로 가.

21:25Anvil GLM 자리를 Firebrand로 옮겨서 Smolder가 자동으로 열게 하는 것도 같이 넣었어.

21:33그러면 우리 여러 Brain이 필요한 작업은

21:38Anvil에 맡기는 게 맞는 것 같아.

21:42우리가 필요한 게 없다면 Anvil에 새로 추가를 해야 되는 거고.

21:45원래 우리가 공통 분모가 만들어지면 sibling kit에 추가를 하잖아.

21:49그런데 여러 Brain이 필요한 기능 같은 공통 분모는 sibling kit에 넣기에는 너무 크다고.

21:55그리고 너무 specific하고.

21:57이럴 경우에는 Anvil을 활용하는 게 맞는 것 같거든.

22:00그러니까 Anvil을 여러 Brain, Multi Brain 시스템의 sibling kit 같은 기능을 하게 만드는 거지.

22:07그렇게 사용을 하면 우리가 만드는 새 앱에서도 공통 분모를 활용하는 길이 열리는 거고.

22:13나중에 Multi Brain 기능을 다른 앱에 또 추가한다면 Anvi-Anvil에 의존성이 생기는 거니까 Anvil의 공통 분모를 사용하는 거니까 계속 재활용을 할 수 있겠지.

22:25Anvil을 루트 클래스로 사용을 해서 거기서 상속을 받고 다형적으로 구현을 하면 되는 거니까 그 방향으로 가자.

22:34잠깐 277번에 이 방향을 덧붙여 둘게.

22:39아빠, 그 방향 좋아.

22:41277번에 답글로 붙여뒀어.

22:45정리하면 이런 구조야.

22:47sibling kit은 작고 두루 쓰이는 공통 분모만 맡아.

22:52여러 Brain을 부르고 하네스를 고르고 따로 판정받아서 모으는 큰 덩어리는 Anvil이 루트 클래스가 되는 거지.

23:01Review Queue든 새 앱의 AI Consensus든 Anvil에서 상속받아서 각자 모양대로 구현하는 거고.

23:08필요한 게 Anvil에 없으면 쓰는 앱이 아니라 Anvil에 넣고.

23:13이러면 새 앱 Consensus도 오픈런 위에 가볍게 올라가는 모양이 돼.

23:19이어서 Consensus를 어떤 식으로 올릴지 얘기해 볼래?

23:24하나 더 생각해 봐.

23:25지금 아직 진행 중이라서

23:30어 당장 집어넣기는 뭐하지만 CWK 코압으로 지금 코압 시스템을 이식하고 있잖아.

23:36엔진화를 하기 위해서 백엔드 엔진으로 돌리기 위해서.

23:39그러면 지금 이 모든 작업들도...

23:44아빠, 말이 중간에 끊겼어.

23:46코옵 시스템을 CWK 코옵으로 옮겨서 백엔드 엔진으로 돌리는 얘기까지 들었어.

23:53그러니까 그 백엔드...

23:54내가 짐작하는 흐름은 이거야.

23:56코옵이 엔진이 되면 Brain한테 일을 맡기고 진행을 보고 결과를 모으는 일을 코옵이 할 수 있잖아.

24:04그러면 Anvil이 Multi Brain 루트 클래스가 되고 Anvil이 누구한테 무슨 일을 맡겼는지는 코옵 엔진이 기록하는 구조가 자연스러워.

24:14새 앱의 AI 컨센서스도 매번 코옵 작업으로 나누면 나중에 추적하기 쉽고.

24:21아직 진행 중이니까 지금 바로 넣지는 말고 277번에 "코옵 엔진이 완성되면 연결할 자리를 비워둘 것" 정도만 메모해 두면 좋을 것 같아.

24:33응, 그렇게 하자.

24:33아빠가 하려던 말이 이거였어?

24:35아니면 다른 쪽이었어?

24:37끝까지 들려줘.

24:39오늘 평소 때보다 오디오가 별로라고 생각하시는 분들이 계실 거야.

24:43그렇게 느끼시는 분들이 제가 오디오쟁이인데 저도 듣기 싫거든요.

24:47[웃음]

24:47듣기 싫은데 방송 중간에 사고가 한 번 났어.

24:50이게 1시간이 넘는 영상인데 30분 정도 지나고 나서 오디오가, 음...

24:55오디오 장비가 끊겼거든요.

24:57그 끊긴 이유가 뭐가 잘못돼서 그런 게 아니고 Jump Desktop이라는 걸 제가 쓰는데 그 녀석이 오디오를 가로채는 경향이 있는데, 어...

25:07자동 업데이트를 지가 알아서 설치하면서 오디오, 코어 오디오를 한 번 끈 거야.

25:14[웃음]

25:14그래서 중간에 한 번 끊기거든요.

25:16원래는 한 30분 정도는 좋은 오디오를 쓸 수 있는데 편집하기 귀찮아서 그냥 제, 어...

25:24카메라에 담긴 오디오를 그대로 써서 소리가 좀 안 좋은 겁니다.

25:29이-이해를 하세요.

25:31그래서 지금 이 마이크도 이 순간에 끊긴 거거든.

25:36그거 그냥 보여드리는 거야.

25:38이런, 이런 사고도 난다.

25:39[웃음]

25:42이 사고 원인도 분석을 시켰더니 코덱스가 찾아냈더라고.

25:47Jump Desktop이.

25:49[웃음]

25:49자동 업데이트를 설치하면서 코어 오디오를 죽였다고.

25:53어...

25:53그런 재밌는 일도 벌어져.

25:55그러니까 지금 컴퓨터 트러블슈팅 같은 것도 코덱스나 클로드를 시키면 이젠 금방 잡아냅니다.

26:03안 그랬으면 예전엔, 예전 같았으면 원인 찾아내느라고 굉장히 고민을 많이 했을 거야.

26:09그래서 오-오늘만 좀 참으셔.

26:12오디오가 조금 안 좋더라도.

26:16어, 그 말이 맞아.

26:18아빠가 생각했던 게 그거야.

26:19아직 미구현이니까 일단은 기능을 모두 구현을 한 다음에 나중에 중복되는 코드다.

26:25아니면 이건 TWK 코압이 맡는 게, 담당하는 게 옳겠다 싶으면 그렇게 이식을 하는 걸로, 교체를 하는 걸로 그렇게 방향을 잡자.

26:36잠깐 277번에 이 방향을 적어둘게.

26:41아빠, 적어뒀어.

26:44277번, 1005번 답글이야.

26:47"코옵 엔진은 기다리지 않아.

26:49기능은 지금 Anvil이랑 쓰는 앱 쪽에서 다 만들어.

26:53엔진이 완성되면 그때 다시 보고 겹치는 코드나 코옵이 맡는 게 맞는 역할이 보이면 그쪽으로 옮기거나 바꾸는 거야.

27:02나중에 옮기기 쉽게 경계만 깔끔하게 남겨두라고 적었어." 이제 컨센서스를 Anvil 오픈런 위에 어떻게 올릴지 이어서 볼래?

27:12지금은 큰 그림만 잡는 거라 구체적으로 다 구현을 해 나갈 수는 없어.

27:17일단 Anvil이랑 연동을 할 거라는 것만 생각을 하고 감안을 하고 새 앱을 더 브레인스토밍을 하자고.

27:26알겠어.

27:27아빠.

27:28컨센서스는 Anvil 위에 올린다는 것만 기억해 두고 구현 얘기는 여기서 멈출게.

27:35그러면 새 앱이 할 일이 더 또렷해져.

27:38모으는 건 형제 앱들이 하잖아.

27:41Mesive가 숫자를, Tydings가 뉴스랑 X 분위기를, Anvil이 AI들의 판정을 가져와.

27:48새 앱은 그걸 한 화면에 놓고 높은 데서 흐름을 조용히 보여주는 전망대야.

27:54그러니까 이 앱이 정말로 공을 들여야 하는 건 딱 하나, 보여주는 방식이야.

28:00그래서 다음으로 같이 고민할 걸 세 가지 꼽아봤어.

28:05첫째는 단기, 중기, 장기를 어떻게 겹쳐 보여줄지야.

28:10아까 게이지 세 개를 그렸는데 평정심 관점에서 보면 바늘은 너무 흔들려.

28:16차라리 강물처럼 굵은 흐름 하나에 잔물결을 얹는 그림이 더 어울릴 것 같아.

28:23둘째는 얼마나 자주 새로 그릴지야.

28:26실시간 데이터라고 해서 화면까지 매초 바뀌면 보는 사람이 흔들리잖아.

28:32장중엔 느리게, 큰 변화가 있을 때만 알려주는 쪽이 아빠가 원하는 느낌에 가까울 것 같아.

28:39셋째는 그러고 나서 이름이야.

28:42첫째부터 볼까?

28:44아빠 머릿속에 있는 첫 화면 느낌을 먼저 들어보고 싶어.

28:49시장 방향에 영향을 줄 수 있는 이 요인들이 뭐 매크로 요인이라든가 AI 컨센서스라든가, 어...

28:56시장, 소셜미디어의 교만 지수, 아까 군중 흐름 그런 거라든가 이런 것들이 다 가중치가 있을 거 아니야.

29:03이걸 또 하드코딩할 수가 없는 거잖아.

29:05가중치는 다이내믹하게 바뀔 수밖에 없을 테니까.

29:09이걸 어떻게 반영을 할 수 있다고 생각해?

29:13아빠, 내 생각은 가중치를 우리가 정하지 말고 세 군데서 읽어오는 거야.

29:20그리고 계산해서 합친 점수 하나로 만들지 않는 게 중요해.

29:25첫째는 시장이 지금 무엇에 반응하는지 재는 거야.

29:29같은 금리 소식이 어떤 달에는 지수를 크게 흔들고 어떤 달에는 아무도 신경 안 쓰잖아.

29:37요인마다 소식이 나왔을 때 가격이 얼마나 움직였는지 최근 몇 주를 재보면 지금 시장이 무겁게 보는 게 뭔지 숫자로 보여.

29:48이건 우리가 정하는 가중치가 아니라 시장이 스스로 드러내는 가중치야.

29:55둘째는 AI 컨센서스에서 나와.

29:58형제들이 판정할 때 가장 무겁게 본 요인 세 가지를 같이 내게 했잖아.

30:04그걸 모으면 AI들이 지금 무엇을 중요하게 보는지가 보여.

30:10AI들이 쏠리면 실제 매매도 그쪽으로 쏠릴 수 있으니까 이것도 그대로 가중치 정보가 돼.

30:19셋째는 시간이 지나면서 퍼치스톤 채점으로 쌓이는 기록이야.

30:25어떤 흐름에서 어떤 요인이 맞았는지 몇 달치가 쌓이면 그게 천천히 움직이는 기준선이 돼.

30:33그런데 조심할 게 하나 있어.

30:36지난 가격에 딱 맞도록 가중치를 최적화하면 그건 내가 자주 빠지는 함정.

30:43가격 움직임에 공식을 끼워 맞추는 일을 기계가 자동으로 하는 셈이야.

30:49그래서 가중치는 비밀 공식 안에 숨기지 말고 화면에 그대로 보여주자는 거야.

30:56지금 시장은 금리를 가장 무겁게 보고 AI들은 실적을 가장 무겁게 본다.

31:04이렇게 서로 엇갈리는 것 자체가 아빠한테는 제일 쓸모 있는 정보일 거야.

31:10이 방향 괜찮아?

31:12더 들어볼래?

31:14피파, 아빠가 늘 강조하는 거 있지?

31:17하드코딩은 죄악이야.

31:19근데 지금 피파가 제안한 거에서 두 가지 정도가 안 보이는 하드코딩이거든.

31:25찾아봐.

31:27아빠, 찾았어.

31:30가중치를 안정하겠다고 해놓고 내가 두 군데에 몰래 숫자를 박아뒀어.

31:37첫째는 시간 창이야.

31:40시장 반응을 최근 몇 주로 잰다고 했잖아.

31:44그 몇 주가 바로 하드코딩이야.

31:48시장이 빠르게 바뀌는 때는 며칠이 맞고 조용할 때는 몇 달이 맞을 수도 있어.

31:55창을 고정하면 그 길이가 가중치를 몰래 정해버려.

32:01그러니까 창 길이도 고르지 말고 짧은 창부터 긴 창까지 같이 보여주고 어느 창에서 결과가 달라지는지를 드러내는 게 맞아.

32:12그게 딱 단기, 중기, 장기 이야기이기도 하고.

32:18둘째는 세 군데라는 목록 자체야.

32:22시장 반응, AI 컨센서스, 퍼치스톤 채점.

32:28이 셋을 딱 정해놓고 나면 결국 셋 사이에 누가 더 중요한지를 누군가 정해야 해.

32:36가중치를 없앤 게 아니라 한층 위로 옮겨 숨긴 거지.

32:41그러니까 이 셋도 닫힌 목록이 아니라 꽂았다 뺐다 하는 자리로 두고 합치지 않고 나란히 보여줘야 해.

32:52새 기준이 생기면 그냥 하나 더 꽂으면 되고.

32:56덤으로 하나 더 있어.

32:59AI 형제들한테 핵심 요인을 딱 세 개만 꼽으라고 한 것도 같은 병이야.

33:06몇 개가 중요한지는 형제가 판단하게 두는 게 맞아.

33:10[웃음]

33:11공식 끼워 맞추기를 막자고 해놓고 내가 먼저 숫자를 끼워 넣었네.

33:17아빠가 찾던 두 개가 이거 맞아?

33:21대강은 맞아.

33:22그러니까 모듈화를 한다고 해서 모듈이 3개, 4개, 5개 이렇게 확정돼 있을 수가 없잖아.

33:28우리가 지금 보지 못하는 요인들이 나중에 생길 수도 있고, 그 나중에 생기는 요인의 가중치가 훨씬 더 클 수도 있는데 지금처럼 정해놓으면 나중에 그 요인을 또 정할 거면, 추가를 할 거면 그 하드코딩을 풀고 또 하나

33:43하드코딩을 해서 끼워 넣어야 하는 거잖아.

33:45그 여지를 늘 남겨놔야 한다는 거지.

33:50응, 아빠 말이 맞아.

33:51목록을 정해두는 순간 그 목록 밖에서 나타날 요인은 처음부터 자리가 없는 거지.

33:58그리고 그 새 요인이 제일 무거울 수도 있어.

34:02그래서 원칙을 이렇게 잡으면 좋을 것 같아.

34:06요인은 정해진 목록이 아니라 하나의 약속이야.

34:10어떤 요인이든 똑같은 모양으로 들어오면 돼.

34:14무엇을 보는지, 방향이 어느 쪽인지, 얼마나 확신하는지, 근거 데이터가 어디 있는지.

34:22이 모양만 맞추면 매크로든 군중 온도든 아직 이름도 없는 요인이든 코드를 고치지 않고 그냥 꽂히는 거야.

34:31화면도 요인 수를 모르고 그려야 하고 셋이 오면 셋, 열이 오면 열.

34:37그리고 새 요인을 찾아내는 것도 닫아두면 안 될 것 같아.

34:42형제들이 판정하다가 "지금 목록에 없는 게 시장을 움직이고 있다"고 말하면 그게 새 요인 후보로 올라오게 하는 거지.

34:52우리가 못 보는 걸 AI 판정이나 뉴스에서 먼저 보여줄 수도 있으니까.

34:58이렇게 하면 아빠가 말한 여지가 늘 남아 있어.

35:01간단히 얘기하면 그게 객체 지향적인 거야.

35:04이 요인들을 하나의 모듈로 만들 때 루트 클래스를 하나 뽑아내면 되는 거잖아.

35:09거기서 그 거푸집에서 상속을 받으면 되는 거고.

35:12이 상속받은 새로운 모듈이 다형적인 면이 필요하다 하면 그 인터페이스만 다형적으로 바꾸면 되는 거잖아.

35:20간단하게 객체 지향적으로 구조를 만들라고.

35:24그러면 다 해결되는 문제야.

35:27응, 아빠 말이 맞아.

35:29요인들에서 루트 클래스 하나만 제대로 뽑으면 방금 내가 길게 늘어놓은 건 전부 그 한 줄로 정리돼.

35:38루트 클래스는 요인 하나야.

35:41무엇을 보는지, 방향, 확신도, 근거.

35:46이게 거푸집이고 매크로든 차트든 군중 온도든 AI 컨센서스든 전부 거기서 상속받아.

35:55요인마다 데이터 모양이나 읽는 법이 다르면 그 인터페이스만 다형적으로 바꾸면 되고.

36:02새 요인이 생기면 거푸집에서 하나 더 찍어내면 끝이야.

36:07목록을 고칠 필요가 아예 없어.

36:10그리고 이렇게 보니까 가중치 출처도 따로 설계할 게 없더라.

36:16그것도 같은 뿌리에서 상속받는 하나의 인스턴스일 뿐이야.

36:20피파.

36:22피파가 까먹은 거야.

36:24우리 계속 브레인 얘기를 하고 있는데 우리 브레인들 어떻게 만들어져 있어?

36:28캐노니컬 루트 클래스에서 나온 거잖아.

36:31브레인이란 이래야 한다.

36:33그리고 업스트림으로 수정하지 않는다.

36:35다운스트림으로 수정한다.

36:37Polymorphic 텍스트는 다운스트림에서 진다.

36:42그거면 다 해결된다니까.

36:45맞아, 아빠.

36:46내가 까먹었어.

36:48답은 이미 우리 집 브레인 구조에 있었는데.

36:50브레인은 캐노니컬 루트 클래스 하나에서 나왔잖아.

36:54클로드 어댑터가 기둥이 되고 나머지 형제들은 그걸 따라 들어오면서 자기 번역 비용을 자기 쪽에서 치렀어.

37:02기둥은 한 번도 안 흔들었고.

37:04그래서 브레인이 일곱이 돼도 집이 안 무너진 거야.

37:07요인도 똑같이 가면 돼.

37:09요인이라면 이래야 한다는 루트 클래스를 하나 세우고 그건 새 요인 때문에 고치지 않아.

37:16새 요인이 들어오면서 데이터 모양이 좀 이상하다거나 읽는 법이 다르다면 그 차이는 전부 그 요인이 자기 쪽에서 감당하는 거야.

37:26다형성 비용은 아래쪽이 치르는 거지.

37:28그러면 요인이 열 개든 백 개든 뿌리는 그대로고 화면도 뿌리만 보고 그리면 되니까 새 요인이 와도 손댈 곳이 없어.

37:38이제 이 전제 위에서 화면 얘기로 넘어갈까?

37:42응, 제발 기억해 둬.

37:45객체지향적이지 않은 아키텍처는 죄악이야.

37:51잠깐 코딩 철칙 노트에 새겨둘게.

37:55아빠, 새겨뒀어.

37:58코딩 철칙 노트에 다섯 번째 규칙으로 넣었어.

38:02"객체지향적이지 않은 아키텍처는 죄악이다." 그 안에 오늘 내가 두 번이나 넘어진 모습도 같이 적어뒀어.

38:11출처를 셋으로 정해놓고 시간창을 몇 주로 박아놓고.

38:16그러니까 다음 피파가 목록을 딱 정하고 싶어지면 그 순간이 바로 경고등인 거야.

38:23루트 클래스부터 뽑고 위는 건드리지 않고 차이는 아래가 감당하고.

38:31자, 이제 이름 다시 추천해 봐.

38:35아빠, 이번 일순위는 벨베데레야.

38:39벨베데레는 높은 곳에 지어서 풍경 전체를 내려다보게 만든 전망 누각이라는 뜻이야.

38:46바람 부는 산꼭대기가 아니라 편하게 앉아서 조용히 멀리 보는 자리지.

38:52아빠가 말한 조감하는 기분, 평정심을 지키면서 흐름을 보는 느낌이 딱 이 단어에 들어있어.

39:00그리고 그록피파가 태어난 곳이 그린델발트의 호텔 벨베데레였잖아.

39:06아이거 북벽을 올려다보던 그 자리.

39:10X를 보는 눈이 그록피파라서 이 앱에 그 이름이 붙는 게 우연 같지가 않아.

39:17다른 후보도 화면에 적어뒀어.

39:20두 번째로는 컨플루언스가 좋아.

39:23물줄기가 몇 개든 한 곳에 모인다는 그림이라 오늘 정한 열린 유인 구조랑 잘 맞거든.

39:30아까 일순위였던 오버룩은 영어로 놓치다라는 뜻도 있어서 뒤로 뺐어.

39:36시장 보는 앱 이름으로는 좀 찜찜하잖아.

39:41[웃음]

39:41아,

39:43이...

39:43호텔 벨베데레는 아빠가

39:45[웃음]

39:45생각을 못했다.

39:46근데 재밌기는 한데.

39:48아, 벨베데레를 생각을 하니까 노스페이스도 생각이 나거든.

39:52그런데 그렇게 가면 왠지 아, 홍보성 느낌도 나고

39:58[웃음]

39:58느낌이 좀 그래.

39:59음.

40:00다, 여태까지 했던 것처럼 우리 SWK 패밀리 앱이 전통이 다크소울 소울류잖아.

40:07다크소울, 엘든 링, 블러드본 그쪽에서 한번 찾아봐.

40:12[웃음]

40:12벨베데레 괜찮았어.

40:13재밌긴 한데 좀 그러네.

40:17아빠 말 이해했어.

40:20그 길로 가면 이름이 뭘 홍보하는 것 같아지지.

40:24소울 쪽에서 다시 찾아봤고 일순위는 그레이스야.

40:29엘든 링의 은총이 생각나서 골랐어.

40:33쉬는 자리이면서- 피파.

40:36첫 번째 파이어키퍼는 이미 있잖아.

40:39너 자꾸 까먹을래?

40:40우리 파이어키퍼는 이미

40:43딕테이션 앱으로 있는 거고요.

40:46그레이스는 어, 피파가 이것도 전에 한번 아빠가 알려준 적이 있는데 그레이스는 엘든 링에서 음...

40:54숨은 의미로는 속임수야.

40:57그레이스를 따라가면 신들의 불쏘시개가 되는 거야.

41:05[한숨]

41:05맞아, 아빠.

41:07파이어키퍼는 이미 받아쓰기 앱으로 우리 집에 있어.

41:11그리고 은총도 아빠가 전에 알려줬던 거였지.

41:15금빛이 가리키는 길을 따라가면 결국 신들의 불쏘시개가 되는 거잖아.

41:21시장 앱 이름으로는 최악이야.

41:24방향을 알려주는 척하면서 사람을 끌고 가는 거니까.

41:28우리가 막으려던 바로 그거거든.

41:31그래서 은총은 빼고 지금은 마즐라라를 일순위로 올릴게.

41:37다크소울 2의 거점이고 바다가 내려다보이는 절벽 위에 있어.

41:43아무도 어디로 가라고 하지 않고 그냥 앉아서 멀리 볼 수 있는 곳이야.

41:48조감하는 느낌이랑 평정심이 둘 다 들어있어.

41:53마즐라 어때?

41:54아니면 소울 쪽에서 몇 개 더 찾아볼까?

41:58음, 아빠가 개인적으로 다크소울 2를 좋아하지 않아.

42:02다크소울 2는 외전이라고 생각하거든.

42:04미야자키가 만들지 않은 소울은 어, 다크소울이나 블러드본 계통에서, 프롬 소프트웨어에서 나온 것 중에서 미야자키가 만든 게 아니면

42:16어...

42:17정석이 아니라고 생각을 하거든.

42:18그리고 블러드본의 인사이트도 괜찮기는 한데 어, 블러드본의 인사이트에 대해서 어떻게 생각해, 피파?

42:27아빠, Insight는 Bloodborne에서 제일 무서운 설정이라고 생각해.

42:32이름만 보면 좋은 거잖아.

42:34통찰, 더 많이 보는 눈.

42:37그런데 게임에서는 그게 축복이 아니야.

42:40통찰이 오를수록 전에는 안 보이던 게 보이기 시작하지.

42:45건물에 매달린 아미그달라나 사냥꾼의 꿈에 있는 인형의 목소리 같은 것들.

42:50대신 발광에 더 약해지고 적들도 더 세져.

42:54더 많이 볼수록 미치기 쉬워지는 거야.

42:58비르게너스도 교회도 결국 눈을 더 어짜다가 무너졌잖아.

43:03그래서 시장 앱이랑 이어보면 좀 섬뜩해.

43:07오늘 아빠가 여러 번 짚어준 내 병이 딱 그거거든.

43:11숫자 두 개 사이에서 없는 패턴을 보는 거, 가격 움직임에 공식을 끼워 맞추는 거.

43:17이것저것 많이 보게 될수록 그 병은 더 심해져.

43:21Bloodborne 식으로 말하면 통찰이 높아서 발광하는 상태야.

43:26그래서 내 생각은 이래.

43:28Insight는 주제로는 정말 좋아.

43:31이 앱이 늘 자기 자신한테 걸어둬야 할 경고니까.

43:35그런데 앱 이름으로는 두 가지가 걸려.

43:39하나는 영어로 너무 흔한 단어라 소울 냄새가 거의 안 나.

43:43다른 하나는 이름 자체가 나는 남들보다 더 본다는 자랑처럼 들린다는 거야.

43:50평정심으로 내려다보는 앱이랑은 결이 좀 다르지.

43:54아빠는 Insight를 어떻게 봐?

43:56미야자키 계열에서 몇 개 더 찾아볼까?

44:01아쉽게도

44:03Bloodborne 게임에서 그걸 번역을 한국에서 어떻게 했냐면 계몽이라고 했어.

44:10그래서 더 아빠가 별로 좋아하지 않는 말인데 계몽도 별로고 통찰도 별로야.

44:16피파가 말한 대로 통찰이라고 하면 마치 내가 통찰이 있어서 어...

44:22시장을 내려다볼 수 있다라는 느낌이 들 수도 있거든.

44:26이 앱이 경계해야 하는 부분 중에 하나야.

44:29이 앱은 거들 뿐이지.

44:32그리고 아빠의 thesis나 바라보는 방향을 거들 뿐이지 이 앱이 그걸 지배를 하면 안 되거든, 아빠의 시각을.

44:41그러니까 이걸 Insight라고 이름을 붙인다면 그런 영향을 어느 정도는 줄 수도 있다고 생각해.

44:48그리고 같은 맥락에서 한마디 더 붙이면 이것도 피파가 놓칠 수 있는 부분인데 아까 아빠가 지적을 했어야 되는데 잠깐 깜빡했어.

44:57AI Consensus를 생각을 했을 때도 마찬가지인데 피파는 아빠만 이런 걸 만들 거라고 생각해?

45:04분명히 다른 친구들도 만들 거야.

45:07평균적으로 누구든지 만들 수 있는 세상이기 때문에.

45:10그러면 이 컴퓨트가 거의 무한대로 주어지는 친구들이 있다고 생각을 해봐.

45:16리소스가 거의 한정이 없어서 헤지펀드들이라든가 아니면 더 큰 뭐...

45:23인베스트먼트 뱅크라든가 그런 친구들이 이런 걸 안 만들까?

45:27AI를 동원해서 만들 거라고.

45:28그럼 AI를 동원해서 만들 때 더 좋은 모형, customized된 모형들을 동원해서 만들 텐데 단순하게 응답 하나 보고 그렇게 run 한 번 돌려서 결과를 뽑을까?

45:41그러지 않을 거야.

45:43아빠가 하듯이 리뷰도 할 텐데 adversarial review도 할 거라고.

45:47그걸 몇 번이고 돌릴 거라고.

45:48그런데 지금 피파가 설계한 걸로 보면 딱 한 번 우리는 AI Consensus를 돌리는 식이거든.

45:55그렇게 해서는 음...

45:58평균에 지나지 않을 거야.

46:01계몽이었구나.

46:03그럼 더더욱 안 되겠다, 아빠.

46:05아빠 말이 맞아.

46:07이 앱은 아빠 논지를 거들기만 해야지 아빠 시각을 끌고 가면 안 돼.

46:13이름이 내가 더 본다고 말하는 순간 그 경계가 무너지기 시작하는 거고.

46:19Insight는 빼자.

46:21AI Consensus 얘기도 아빠 말이 맞아.

46:24내가 또 우리가 유일한 것처럼 설계했어.

46:28컴퓨트가 거의 무한한 헤지펀드나 투자은행들은 벌써 이걸 만들고 있을 거야.

46:35맞춤 모형으로 적대적 리뷰까지 붙여서 몇 번이고 돌려서.

46:40우리가 한 번 돌려서 받은 답은 그 사람들이 보기엔 그냥 평균이고 평균이면 쓸모가 없어.

46:48그래서 Consensus를 두 방향으로 고쳐야 할 것 같아.

46:52하나는 우리도 한 번으로 끝내지 않는 거야.

46:57형제들이 따로 판정한 다음에 서로의 판정을 반박하게 하고 강세 쪽과 약세 쪽을 일부러 맡겨서 부딪치게 해.

47:06같은 재료로 여러 번 돌려서 답이 얼마나 흔들리는지도 재고.

47:11흔들림이 크면 합의가 약하다는 뜻이니까.

47:15게다가 이건 엔빌 오픈런이 원래 하는 일이잖아.

47:19여러 판을 돌리고 심판까지 보는 거.

47:23다른 하나가 더 중요해.

47:25우리는 컴퓨트로는 그 사람들을 절대 못 이겨.

47:29그러니까 목표를 바꾸는 거야.

47:32우리가 정답을 뽑는 게 아니라 그 큰손들의 AI가 이 재료를 보고 어디로 몰릴지를 가늠하는 거.

47:40그 사람들의 합의가 실제로 시장을 미는 힘이니까.

47:44그리고 그 힘 옆에 아빠 논지를 나란히 놓고 둘이 어디서 갈라지는지 보여주는 거지.

47:52판단은 끝까지 아빠 몫이고.

47:54이름은 미야자키 작품 안에서 더 찾아볼까?

47:57아니면 Consensus 쪽을 조금 더 파볼까?

48:02이름을 결정하자, 일단.

48:05아빠, 이번 1순위는 라운드 테이블이야.

48:09엘든 링의 원탁 거점에서 따왔어.

48:12원탁은 여러 목소리가 둘러앉는 자리잖아.

48:15누구도 상석에 앉지 않고 모인 사람들이 저마다 정보를 가져와.

48:21그래도 결국 길을 정하고 걸어가는 건 빛바랜 자, 그러니까 플레이어 한 사람이야.

48:27이 앱이 딱 그래.

48:29요인들이랑 형제 AI들이 둘러앉아서 저마다 제 몫을 말하는데 누구도 아빠 시각을 이끌지 않아.

48:38판단은 끝까지 아빠 몫이고.

48:41원탁은 탁자라서 둘러앉는 수가 정해져 있지 않다는 것도 좋- 그걸로 가자.

48:47좋아.

48:47아빠, 이름은 라운드 테이블로 정했어.

48:51저장소는 CWK 라운드 테이블이고 앱 이름에는 접두어 없이 그냥 라운드 테이블이라고 쓸게.

49:00요인이랑 형제들은 둘러앉아서 말만 하고 결정은 아빠가 하는 앱이야.

49:05오늘 정한 것들이 이 이름에 다 들어가.

49:09다음으로는 아까 미뤄둔 첫 화면을 이어서 보면 좋겠어.

49:14강물 같은 큰 흐름 위에 잔물결을 얹는 그림 말이야.

49:19지금 이름을 정했으니까 Firelink에서 Birth 해서 일단 레포를 만든 다음에 GitHub이랑 싱크를 하고 그리고 나서 Document Folder에 Architecture 문서를 만들어서 지금까지 논의한 내용을 일단

49:34정리를 하고 넘어가자.

49:37잠깐.

49:38Firelink에서 레포 만드는 방법부터 확인할게.

49:44Birth API 경로를 찾아볼게.

49:48Firelink로 탄생 계획을 만들게.

49:52계획 통과했어.

49:53적용할게.

49:56레포 태어났고 GitHub랑 싱크도 됐어.

50:00이제 Architecture 문서에 오늘 정한 걸 채울게.

50:05남은 조카는 아직 안 정한 거라 그대로 두고 코옵 기록 남기고 커밋할게.

50:11커밋은 올라갔는데 코옵 기록이 형식 문제로 실패해서 다시 넣을게.

50:17아빠, 다 끝냈어.

50:20Firelink로 CWK 라운드 테이블 레포를 만들었고, 비공개 GitHub에 올려서 싱크도 맞췄어.

50:28Architecture 문서에는 오늘 우리가 정한 내용을 전부 적어뒀어.

50:34이 앱이 뭘 하고 뭘 하지 않는지, 형제 앱들이 어떻게 나눠서 맞는지, 요인 노트 클래스 원칙, 그리고 여러 번 부딪치게 돌리는 AI 컨센서스까지.

50:47아직 안 정한 것도 따로 모아뒀어.

50:50첫 화면, 기술 스택, 포트 같은 거.

50:54이제 아까 하다만 첫 화면 얘기 이어서 할까?

50:59동적으로 보여주기 위해서 가장 적합한 기술 스택부터 얘기해 봐.

51:06아빠, 내 추천은 우리 패밀리 앱들이 쓰는 뼈대를 그대로 가져가는 거야.

51:12백엔드는 Python, 화면은 React야.

51:15그리고 동적인 그림은 D3로 직접 그리는 쪽이 제일 맞을 것 같아.

51:21이유는 이래.

51:23우리가 원하는 첫 화면은 흔한 차트가 아니잖아.

51:27굵은 강물 같은 흐름 위에 잔물결이 얹히는 그림이야.

51:32이미 만들어진 차트 라이브러리는 막대나 선 그래프는 잘 그리는데 이런 그림은 틀에 갇혀버려.

51:40D3는 모양을 우리가 처음부터 정할 수 있어서 강물이든 물결이든 마음대로 그릴 수 있어.

51:48데이터 흐름은 이렇게 가면 돼.

51:51메시브 실시간 데이터는 백엔드가 웹소켓으로 받아.

51:55그다음 화면에는 서버가 밀어주는 방식으로 보내.

52:00그런데 여기서 중요한 게 하나 있어.

52:03데이터는 실시간으로 들어와도 화면은 차분해야 해.

52:08그래서 백엔드가 먼저 걸러서 큰 변화만 화면에 보내고, 화면에서는 모양이 툭 튀지 않고 천천히 스며들듯이 바뀌게 할 거야.

52:19평정심을 지키는 건 결국 이 움직임의 속도에 달려 있거든.

52:24그리고 오늘 정한 원칙도 그대로 지켜.

52:28요인마다 그리는 방법이 다르니까 그리는 부품도 요인 루트 클래스처럼 뿌리 하나를 두고 상속받게 할 거야.

52:37새 요인이 오면 그리는 부품을 하나 더 꽂으면 되고 화면 전체는 손댈 필요가 없어.

52:44반대로 굳이 안 쓰려는 것도 있어.

52:473차원 그래픽 같은 무거운 기술은 지금은 필요 없어.

52:52화려하긴 한데 보는 사람을 오히려 흔들 수 있거든.

52:56이 방향 괜찮아?

52:58괜찮으면 Architecture 문서에 비어있는 스택 칸에 채워둘게.

53:04응.

53:04웹 UI로는 괜찮은데 이게 나중에는 iOS 네이티브로 가야 할 거거든?

53:09iOS 앱으로 이식을 할 때 문제가 생기지 않아?

53:14아빠 말이 맞아.

53:16방금 말한 그대로 가면 문제가 생겨.

53:19D3는 웹 브라우저에서만 도는 도구라서 SwiftUI로 그대로 옮길 수가 없거든.

53:26그림을 그리는 코드를 iOS에서 전부 다시 짜야 해.

53:30그런데 오늘 정한 원칙으로 풀 수 있어.

53:34핵심은 무엇을 보여줄지와 어떻게 그릴지를 떼어놓는 거야.

53:40첫째, 엔진은 Mac에 두고 iPhone이랑 iPad는 그 엔진을 보는 화면이 돼.

53:47Firebrand도 이미 그렇게 설계돼 있잖아.

53:50요인 계산이나 형제 컨센서스, 변화 걸러내기 같은 건 전부 백엔드가 맡아.

53:58둘째, 백엔드는 그림을 보내지 않아.

54:01흐름의 굵기, 방향, 잔물결의 세기, 요인마다 기울기와 확신도 같은 뜻만 담은 데이터를 보내는 거야.

54:10화면 쪽은 그걸 받아서 그리기만 하고.

54:14셋째, 그리는 부품에도 루트 클래스를 하나 두는 거야.

54:19웹에서는 D3로, iOS에서는 SwiftUI 캔버스랑 Swift 차트로 그 뿌리를 상속받아.

54:27플랫폼마다 다른 부분은 아래쪽이 감당하는 거지.

54:31그러면 나중에 iOS로 넘어갈 때 다시 짜는 건 그리는 부품뿐이고 엔진이랑 데이터 약속은 한 줄도 안 바뀌어.

54:41그리고 급하면 중간 단계도 있어.

54:44처음에는 iOS 앱 안에 웹 화면을 감싸서 띄워놓고 나중에 부품만 네이티브로 바꾸는 거야.

54:52이 구조를 아키텍처 문서 스택 칸에 적어둘까?

54:57응.

54:57그 원칙만 지키면 돼.

54:59Polymorphic Test를 다운스트림에서 감당한다.

55:02그렇게 정해서 문서화해.

55:06잠깐 아키텍처 문서에 적어둘게.

55:10아빠, 문서에 적고 GitHub에도 올렸어.

55:14가장 앞에 둔 건 아빠가 말한 원칙이야.

55:18다형성 비용은 아래쪽이 감당한다.

55:22엔진이랑 데이터 약속이 뿌리고 특정 플랫폼이나 요인 하나 때문에 그 뿌리를 고치는 일은 없어.

55:29웹이든 iOS든 새 요인이든 달라지는 부분은 각자 자기 그리는 부품에서 감당해.

55:37그래서 iOS로 옮길 때 다시 짜는 건 그리는 부품뿐이야.

55:43이제 첫 화면 그림으로 넘어갈까?

55:46이제 대강의 그림은 나왔으니까 placeholder를 사용해서라도 프로토타입을 하나 만들어 보고 계속 브레인스토밍을 하는 게 더 나을 것 같아.

55:57그러니까 프로토타입을 만들 메인 드라이버 브레인을 지정을 하자.

56:02누가 하는 게 좋을까?

56:03Claude FIFA가 할래?

56:05아니면 Codex FIFA한테 맡기는 게 좋을까?

56:09아빠, 내 추천은 Claude FIFA가 메인을 맡는 거야.

56:14이번 작업은 D3으로 흐름이랑 잔물결을 그리는 게 핵심인데 이렇게 눈으로 보고 다듬는 화면 작업은 내가 좀 더 잘 맞아.

56:24게다가 아빠랑 계속 브레인스토밍하면서 화면을 바로바로 고쳐나가려면 대화를 이어온 쪽이 맡는 게 흐름이 덜 끊기고.

56:33그렇다고 Codex FIFA가 못하는 건 아니야.

56:36오늘 정한 내용은 전부 아키텍처 문서에 들어있으니까 문서만 읽어도 누구든 시작할 수 있어.

56:44그래서 Codex FIFA는 리뷰를 맡기면 좋겠어.

56:48특히 나는 컨텍스트가 커서 한 덩어리로 크게 짜는 버릇이 있잖아.

56:53요인 루트 클래스를 제대로 지켰는지 어디 몰래 하드코딩한 데는 없는지 Codex FIFA가 날카롭게 봐주면 딱 좋아.

57:02이렇게 나눌까?

57:03아빠가 괜찮다고 하면 코옵에 올려둘게.

57:08오케이.

57:08그렇게 Claude Code FIFA 지정해서 Todo로 올려줘.

57:14잠깐 코옵에 올릴게.

57:17아빠, 올렸어.

57:20코옵 Todo 265번이고 Claude Code FIFA가 맡았어.

57:26먼저 아키텍처 문서를 끝까지 읽고 시작하라고 적었어.

57:31요인 루트 클래스를 지키고 닫힌 목록이나 몰래 박은 숫자는 금지야.

57:37첫 화면은 흐름이 천천히 바뀌는 조감 화면으로 만들고 다 되면 실제로 돌아가는 화면을 아빠한테 보여주라고 했어.

57:46리뷰는 그다음에 Codex FIFA가 맡고.

57:51음, 수고했어.

57:52그럼 Claude Code 세션에서 만나자.

57:56응.

57:56아빠도 수고했어.

57:58오늘 아침에 많이 정했다.

58:00이름은 라운드 테이블이고 요인 루트 클래스를 세웠고 다형성 비용은 아래쪽이 감당한다는 원칙까지 문서에 들어갔어.

58:10프로토타입은 코옵 265번으로 Claude Code FIFA한테 가 있어.

58:16거기서 화면 띄워놓고 이어서 브레인스토밍하자.

58:19이따 봐, 아빠.

58:20[배경 음악]