안녕하세요 여러분.00:08

컨퍼런스는 지금까지 잘 진행되고 있나요? 컨퍼런스는 지금까지 잘 진행되고 있나요?00:15

좋습니다. 멋지네요.00:19

제가 여러분께 전하고 싶은 메시지가 있어요. 이 메시지가 ~라고 생각하는 분들에게 위로가 되었으면 좋겠어요.00:21

자신들의 기술이 이 새로운 시대에는 아무 가치가 없다는 것이 바로 소프트웨어의 기초가00:28

예전보다 훨씬 더 중요하게 여겨진다고 생각합니다.00:35

그리고 저는 선생님인데, 최근에 '클로드 엔지니어를 위한 코딩'이라는 과정을 가르치고 있어요.00:39

꽤 도발적인 이름이죠. 그리고 그 과정에서 약간의00:45

이 강좌를 만들면서, AI 코딩에 대한 커리큘럼을 구상해야 했는데, 그게 좀00:50

악몽 같아요. 모든 게 계속 변하잖아요? AI는 완전히 새로운 패러다임이에요.00:57

우리가 새로운 것을 도입하려면 기존의 모든 규칙들을 버려야 할 것 같아요.01:02

그러한01:08

이와 관련해서 나온 움직임 중 하나가 바로 스펙을 코드로 전환하는 움직임입니다. 스펙을 코드로 전환하는01:10

움직임은 여러분이 애플리케이션이 어떻게 작동해야 하는지에 대한 명세서를 작성할 수 있다고 말해요.01:16

그러면 AI를 사용해서 코드로 변환할 수 있어요. 만약 애플리케이션에 문제가 있다면, 그냥01:20

스펙으로 돌아가세요. 코드를 실제로 보지 않고 그냥 스펙을 변경하고 컴파일러를 실행하면 돼요.01:26

다시, 그리고 더 많은 코드를 얻게 돼요. 이런 경험 있으신 분 손들어 보세요.01:31

경험 있으신 분은 손들어 계세요. 네, 저도 해봤어요.01:37

손 내려도 돼요. 그리고 제가 알아차린 것은 코드를 보지 않으려고 실행했는데,01:41

코드에 시선을 두게 되고 결국 코드를 만들어내게 된다는 것이었어요.01:47

결국에는, 그리고 저는 그것을 실행했는데, 더 나쁜 코드를 얻었어요. 그리고 저는 또 했고, 저는01:52

훨씬 더 나쁜 코드를 얻었고, 또 그렇게 됐어요. 계속 컴파일러를 실행하고, 계속 컴파일러를 실행하다가 그냥 쓰레기 같은 결과물만 얻게 됐어요.01:56

혹시 이런 경험 있으신 분 손들어 보세요. 네. 이건 안 맞는 것 같아요.02:03

코드를 무시하고 그냥 코드가 스스로 관리하게 놔둔다는 아이디어는 이름만 다르고 그냥 바이브 코딩일 뿐이에요.02:09

저는 그때는 그걸 믿지 않았어요. '어떻게 컴파일러를 고칠까?'라고 생각했죠.02:15

어떻게 만들어서 잘못된 것을 만들지 않게 할 수 있을까요?02:21

코드를 매번 작성해야 하는 건지, 아니면 더 나쁜 코드인 건지요? 그래서 저는 LLM에게 영어로 설명해야겠다고 생각했어요.02:23

좋은 코드베이스가 어떻게 생겼는지요. 제가 아끼는 오래된 책 한 권을 찾아볼게요.02:29

존 오스터하우츠가 쓴 소프트웨어 설계 철학이 담긴 책입니다. 아마존에서 찾아보세요.02:35

그리고 나쁜 코드가 무엇인지에 대한 정의도 가지고 있어요.02:41

그는 그것을 복잡한 코드로 부릅니다. 복잡성은 소프트웨어 시스템의 구조와 관련되어02:44

시스템을 이해하고 수정하기 어렵게 만드는 모든 것을 말합니다, 그렇죠?02:50

그러니까 나쁜 코드베이스란 변경하기 어려운 코드베이스예요. 코드베이스를 변경할 때 버그를 유발하지 않으면서02:53

변경할 수 없다면, 그건 나쁜 코드베이스예요. 좋은 코드베이스는 변경하기 쉽죠.03:00

그래서 저는, 오, 이건 좋네요. 다른 책을 한번 봐야겠어요.03:03

Paragammatic Programmer를 한번 읽어보시죠. 아마존에서 구하세요. 여기 '무엇인가'라는 장 전체가 있어요.03:07

소프트웨어 엔트로피예요. 그리고 제가 정확히 보고 있는 것이 바로 이거예요.03:13

엔트로피란 어떤 것들이 재앙 쪽으로, 그리고 서로 멀어지려는 경향을 가지고 있다는 아이디어예요.03:16

붕괴하는데, 이것이 바로 대부분의 소프트웨어 시스템이 행동하는 방식이기도 합니다.03:22

코드베이스를 변경할 때마다 오직 그것에만 초점을 맞추고 있다면03:26

전체 시스템의 설계에 대해서 생각하지 않고 코드를 바꾸는 게03:29

점점 더 나빠지고 나빠지고, 그리고 제가 보았던 게 모든 것이 그래요03:33

스펙에 코드를 넣는 아이디어에 그저 컴파일러를 계속 돌리면 되잖아요03:37

더 나쁜 코드를 만들게 되더라고요. 이제 스펙을 이끌어가는 아이디어가 생겼어요.03:41

코드는 저렴하다고 하는 움직임인데, 누가 들어보셨는지 손들어 볼까요?03:47

전에 '코드는 저렴하다'라는 말이 있었잖아요. 음, 저는 그게 맞지 않다고 생각해요.03:51

사실 코드는 싸지 않아요. 오히려 나쁜 코드가 역대 가장 비싸요. 왜냐하면03:58

만약 수정하기 어려운 코드베이스를 가지고 있다면, 모든 것을 가져갈 수가 없어요.04:04

AI가 제공할 수 있는 바운티는, 실제로 좋은 코드베이스 안에서 AI는 정말04:08

잘 작동한다는 의미이고, 이는 좋은 코드베이스가 그 어느 때보다 중요하다는 것을 의미합니다.04:13

소프트웨어 기초가 그 어느 때보다 중요합니다. 이것이 오늘 이야기의 주제인데요. 자, 그럼 이제 실질적인 이야기로 들어가 볼게요.04:18

AI를 사용하면서 겪으셨거나 아직 겪지 않으셨을 수 있는 다양한 실패 모드에 대해 말씀드리겠습니다.04:25

그리고 옛날 책으로 돌아가서 좋은 소프트웨어 관행을 살펴봄으로써 어떻게 피할 수 있는지 말이죠.04:30

들어보셨어요?04:35

첫 번째는요. AI가 제가 원했던 걸 하지 않은 경우입니다.04:36

예를 들어, 제가 머릿속으로 좋은 아이디어가 있다고 생각했는데 AI가 완전히 다른 것을 하거나 그런 적이요.04:40

제가 원하는 게 아닌 걸 그냥 만들어내는 경우가 있어요. 이런 경험 하신 분 손들어 보세요. 멋지네요.04:47

맞아요. 전래 프로그래머라는 책에서 이런 내용이 나오는데, 아무도 자신이 원하는 게 정확히 무엇인지 모른다는 거예요.04:52

그게 말이죠, 사용자분과 AI 사이에 커뮤니케이션 장벽이 있는 거죠?04:58

그래서 AI랑 대화하다 보면, 그게 AI가 요구사항을 수집하는 것과 비슷해요.05:03

기본적으로 여러분으로부터 무엇이 필요한지 알아낸 것이고 저는 깨달았어요05:08

프레더릭 P 브룩스의 또 다른 책, 『설계의 설계』가 있는데 그 책에서는 이야기해요05:15

디자인 개념이라고 불리는 이 아이디어는, 여러 명이 한 명 이상이05:20

함께 무언가를 디자인할 때 이 아이디어가 떠다니는 것이 있어요.05:23

지금 말씀드리는, 만들고 계신 그 대상에 대한 일시적인 아이디어와 그 대상이05:28

가지고 있는, 혹은 그 아이디어 자체를 디자인 컨셉이라고 하는데, 사실은05:32

그것은 마크다운 파일에 넣을 수 있는 것이 아니라, 여러분이 만들고 있는 것에 대한 눈에 보이지 않는 일종의 이론입니다.05:36

그래서 저는, '좋아, 이게 문제구나. 나와 AI는 디자인 콘셉트를 공유하지 못하는구나'라고 생각했습니다.05:44

그래서 제가 하나의 스킬을 생각해 냈어요. 이 스킬은 정말 정말 간단한데, '저를 심문해 주세요(Grill Me)'라고 불리고 이렇게 생겼어요.05:49

우리가 공통의 이해에 도달할 때까지 이 계획의 모든 측면에 대해 끊임없이 면접을 보는 거예요.05:57

프레더릭 P.의 다른 방법인 디자인 트리 각 브랜치를 따라 내려가면서,06:03

의사 결정 간의 의존성을 하나씩 해결하는 것입니다.06:06

이 기술은 마치 이 기술을 담고 있는 레포지토리의 별점이 13,000개 정도 돼요.06:10

그냥 미쳐서, 입소문을 타서 사람들이 이 걸 너무 좋아했어요.06:15

이 몇 줄은 AI가 사용자분들께 40개, 60개의 질문을 하는 것을 의미합니다.06:19

제가 보기에 AI가 공유된 이해에 도달했다고 만족할 때까지 사람들에게 100개의 질문을 하게 했습니다.06:24

그리고 AI를 일종의 상대방으로 만들어 끊임없이 아이디어를 제시하는 방식이에요.06:29

그리고 공통의 이해에 도달하려고 하는 거죠. 그게 여러분이 생성하는 대화라는 게,06:35

그걸 가져다가 제품 요구사항 문서 같은 걸 만드실 수도 있고요.06:41

아니면 작은 변경 사항이라면 바로 이슈로 만드실 수 있어요.06:45

그러면 사용자님의 AFK 에이전트가 그걸 처리할 거예요.06:52

저한테 그러지 마세요, 하지만 저는 개인적으로 이게 더 낫다고 생각해요06:55

제가 사용하는 도구의 기본 계획 모드인 클로 코드 계획 모드보다 훨씬06:59

열성적입니다07:06

에셋을 만들려면 계획을 먼저 세우고 작업하는 경향이 있는데, 저는07:06

먼저 공유된 디자인 콘셉트에 도달하는 것이 훨씬 좋다고 생각합니다. 그래서 첫 번째 팁입니다.07:14

두 번째 실패 모드는 AI가 너무 장황하게 말한다는 거예요. 마치 여러 목적에 걸쳐 이야기하는 것 같잖아요.07:22

AI가요. 혹시 이런 느낌을 받아보신 적 있으신가요? 이런 실패 모드를 경험해 본 적이요. 네. 그게 좀07:28

마치 AI가 자신이 무슨 행동을 하는지 전달하려고 너무 많은 단어를 써서 이야기하는 것 같아요.07:34

같은 언어를 사용해서 이야기하는 게 아니잖아요. 저에게는 아주아주 익숙하게 느껴졌어요,07:38

맞죠? 개발자로 오래 일하면서, 예를 들어 도메인 전문가와 함께 애플리케이션을 만든 적이 있으신 분들은07:45

만약 그 도메인 전문가가 마이크로칩으로 무언가를 만들라고 요청한다면요.07:51

여러분은 마이크로칩이 뭔지 전혀 모르세요. 일종의 공통 언어를 확립해야 합니다. 그렇지 않으면,07:55

여러분은 이해하지 못하는 용어를 사용하게 될 거고, 여러분은 그 용어를 코드로 번역하게 될 거예요. 심지어 그 코드도 이해하지 못할지 몰라요. 그리고 물론08:01

도메인 전문가는 그렇지 않아요. 그래서 당신과 도메인08:06

전문가 사이에 이런 종류의 언어 격차가 있어요. 그래서 도메인 주도 설계를 다시 찾아봤어요.08:11

DDD요. 제가 아직 좀08:16

탐구하는 경계에 있는데, DDD에 대해 읽는 모든 것이 정말 제게는 음악 같아요.08:19

귀요. 정말 좋아해요. 그리고 DDD에는 유비쿼터스 언어라는 개념이 있어요.08:23

유비쿼터스 언어를 사용하면 개발자들 간의 대화와 코드 표현, 그리고 도메인 전문가들과의 대화가 가능합니다.08:31

모두 동일한 도메인 모델에서 파생된 거예요. 본질적으로 용어 목록으로 가득 찬 마크다운 파일이죠.08:37

당신과 AI가 공통적으로 아는 거예요. 그리고 그 용어들에 정말 집중하고 정말 만듭니다.08:42

그것들이 실제로 의미하는 것과 일치하고 코드로 항상 사용되는지 확인하는 것이죠,08:47

코드에 대해 이야기하거나 도메인 전문가에게 이야기하거나, 저희의 경우 AI와 이야기할 때 말이에요. 그래서 제가 하나의 스킬을 만들었습니다.08:52

이 스킬은 유비쿼터스 언어 스킬이에요.08:58

기본적으로 코드베이스를 스캔해서 용어를 찾고, 그다음 마크다운 파일을 만듭니다.09:02

모든 전문 용어가 담긴 유비쿼터스 언어 마크다운 파일을 생성합니다.09:09

그리고 이것을 AI에 전달하면, 저도 내용을 읽을 수 있어요.09:14

AI와 함께 구상하거나 기획할 때 항상 이걸 열어두거든요.09:19

그리고 AI의 생각 흐름을 읽어보면 계획만 개선하는 게 아니라 AI가 ~ 방식으로 생각하게 만들더라고요.09:24

더 간결한 방식이에요. 실제로 구현이 계획한 내용과 더 잘 일치한다는 의미예요.09:31

그래서 이건 정말 강력했어요. 믿기 어려울 정도로 좋았어요.09:37

그래서 이것이 두 번째 팁입니다. AI와 공통 언어를 만드세요.09:41

자, 좋습니다. AI와 목표를 일치시켰다고 상상해 보세요. 무엇을 구축해야 하는지 알잖아요.09:45

AI가 올바른 것을 만들긴 했는데, 작동하지 않아요.09:51

혹시 그런 경험 하신 분 손 한번 들어보시겠어요. 네, 그냥 작동을 안 하더라고요.09:54

음, 그것을 더 좋게 만들기 위해 우리가 할 수 있는 명백한 것이 하나 있는데, 바로 피드백 루프를 사용할 수 있다는 것입니다.09:59

정적 타입을 사용할 수 있어요. TypeScript를 사용하지 않는다면 정말 말도 안 됩니다.10:05

만약 프론트엔드 앱을 만드는데 LLM에게 브라우저 접근 권한을 주지 않는다면,10:10

주변을 살펴볼 수 있도록 반드시 그게 필요하고 물론 자동화된 테스트도 필요합니다.10:16

제가 여기서 하나 발견한 점은 이것들 같은10:23

피드백 루프를 사용하더라도 LLM이 이를 제대로 활용하지 못한다는 거예요. 마치 받아들이지 못하는 것처럼요.10:28

숙련된 개발자처럼 피드백 루프를 가장 많이 사용하지 못합니다. 그래서10:33

그래서 이것은 한 번에 너무 많은 것을 합니다. 방대한 양을 생성할 것입니다.10:37

코드에 대해 생각하고, '아, 실제로는 타이핑 체크를 해야겠네.' 또는 '혹은 거기에 대한 테스트를 확인해야 할까?' 아니면 그런 것을 해야 할까.'라고 생각합니다.10:43

그리고 프래그마티즘 프로그래머에서는 이것을 헤드라이트를 앞질러 달리는 것이라고 묘사합니다.10:50

본질적으로 너무 빨리 운전하는 것이기 때문입니다. 피드백 속도가 제한 속도예요.10:55

피드백 속도가 제한 속도라는 것은 과정 중에 테스트를 해야 한다는 뜻이에요.11:02

작고 의도적인 단계들을 밟는 것인데, AI는 기본적으로 그런 것에 정말 능숙하지 않아요.11:07

그래서 세 번째 기술은 TDD예요.11:12

TDD는 LLM이 정말로 작은 단계로 진행하도록 강제하기 때문에 사용하셔야 합니다.11:14

좀 더 나아집니다.11:19

테스트를 먼저 만드시고, 그 테스트를 통과시키신 다음 코드를11:23

더 좋게 다듬고 설계를 고려합니다.11:27

여기서 문제가 되는 점은 테스트가11:31

정말 어렵다는 거예요. 테스트는 항상 어려웠고 그 이유는 바로11:35

테스트를 작성할 때 내리셔야 할 수많은 결정들이 있어요.11:42

어떤 크기의 유닛을 테스트하고 싶으신가요?11:44

테스트하려면 무엇을 목킹해야 할지, 어떤 동작을 테스트할지부터 알아내야 하고11:49

이 모든 결정들이 상호 의존적이기 때문에 만약 테스트한다면11:54

아니면 전체 대규모 애플리케이션처럼 정말 큰 유닛일 경우, 꽤 불안정할 수 있어요. 너무 많은 동작을 테스트하고 싶지 않을 수도 있고요.11:58

이 유닛만 테스트한다면, 이 유닛을 모의(mock)해야 합니다. 모든 것이 서로 연결되어 있어요.12:06

사실 개발 경력을 하면서 이 문제에 대해 몇 년 동안 생각해 왔어요.12:10

그리고 우리가 주목하는 건 좋은 코드베이스는 테스트하기 쉬운 코드베이스라는 겁니다, 그렇죠?12:15

그래서 이제 코드가 중요하다는 생각으로 돌아가 보고 있습니다.12:21

코드베이스가 좋을수록 피드백 루프가 더 좋아진다는 의미입니다.12:25

LLM에게 더 나은 피드백을 줄 수 있기 때문에, 더 좋은 코드를 생성해요.12:29

그래서 저는 좋은 코드베이스가, 테스트 가능한 코드베이스가 어떤 모습인지 궁금했어요12:35

다시 존 아스터하우트를 보면요, 코드를 작성할 때 얕은 모듈보다는 깊은 모듈을 가져야 한다고 말합니다.12:40

여러 기능을 노출하는 많은 모듈보다는 상대적으로 적은 모듈이어야 해요.12:47

간단한 인터페이스를 가진 크고 깊은 모듈을 비교해 볼게요. 깊은 모듈은 많은12:54

기능을 간단한 인터페이스 뒤에 숨기면서 복잡성을 숨기는 거죠.13:01

원하시면 깊은 모듈을 들여다보셔도 되지만, 그럴 필요는 없습니다.13:05

인터페이스만 사용하시면 돼요. 얕은 모듈은 기능이 많지 않고 인터페이스가 복잡해요.13:08

사진 찍으실 때까지 제가 기다릴게요.13:13

코드베이스에서 얕은 모듈은 이런 식인데, 아주 작은 것이 많이 있잖아요13:18

AI가 돌아다니고 탐색해야 하는 작은 덩어리들이요. 그리고 이것은 AI가 정말로13:23

실제로 탐색하기 어렵습니다. 그래서 종종 이런 코드를 가지고 있는 AI를 보시면요.13:29

이런 코드를 작성하는 데는 정말 능숙해요. 그래서 AI가 모르는 상황이 생기거든요.13:34

코드를 탐색하려고 시도하지만, 구조가 제대로 갖춰지지 않아서요.13:39

그리고 얕은 모듈로 가득 차 있으면, 제시간에 올바른 모듈에 도달하지 못하거나 모든 의존성을 이해하지 못해요.13:44

코드를 이해하지 못해요.13:51

깊은 모듈들로 가득 찬 코드베이스는 어떤 모습인가요?13:54

이런 모습이에요.13:57

같은 코드인데, 단지 상단에 인터페이스를 가진 경계 내부로 구조화된 경우예요.14:00

이 인터페이스들은 아마도 여러분이 많은 통제권을 가지고 정말 잘 설계해야 할 거예요.14:09

그렇지 않으면 AI가 디자인을 엉망으로 만들 수도 있어요. 하지만 구현은 AI에게 어느 정도 맡길 수 있어요.14:14

그렇다면, 이런 코드를 가진 코드베이스를 저런 코드를 가진 코드베이스로 어떻게 바꿀 수 있을까요?14:21

음, 저는 그에 대한 기준이 있어요. 코드베이스 아키텍처를 개선하는 거예요.14:29

이게 아니라요,14:32

이것을 하는 것은 꽤 복잡하지만, 마치 재사용할 수 있는 일련의 단계와 같아서,14:34

다시 한번 할 수 있습니다. 여러분은 그냥 코드베이스를 탐색하면서 코드가 좀 더 좋을 수 있는 기회를 찾으시면 됩니다.14:40

관련된 부분을 찾고 모든 것을 깊은 모듈 안에 묶는 거죠. 그리고 이것은 테스트 가능한 코드베이스입니다. 왜냐하면14:45

이 코드 주변의 경계가 너무 간단해서 인터페이스 레벨에서 테스트하고 그것으로 검증할 수 있기 때문이에요.14:52

인터페이스만 통과하면 되는 코드베이스라서 TDD에 적합하지만, 실패는 어떨까요?14:58

여섯 번째 뼈대인데, 만약 피드백 루프가 제대로 작동한다고 가정해 볼게요.15:05

일들이 제대로 돌아가서 이전에 경험했던 것보다 더 많은 코드를 배포할 수 있어요15:10

하지만 당신의 뇌가 따라잡지 못하는 경우가 있잖아요. 만약 더 피곤하다고 느낀 분이 계시면 손들어 주세요.15:13

지금까지 개발 경력에서 해본 것보다 더 많이 배포할 수 있지만, 뇌가 따라가지 못하는 경우를 생각해 보세요. 손을 들어보세요. 만약 이전에 느꼈던 것보다 더 피곤하다면15:19

왜냐하면 여러분이 인공지능(AI)과 마찬가지로 이 모든 정보를 머릿속에 유지해야 하기 때문입니다. 반면에 이것은 여러분이 읽고 이해하는 데 더 간단할 뿐만 아니라, 이러한 모듈이나 깊은 모듈을 회색 상자처럼 취급할 수도 있다는 것을 의미합니다.15:26

AI뿐만 아니라 여러분도 모든 정보를 머릿속에 유지해야 하니까요,15:30

반면에 이것은 여러분이 읽고 이해하기에 훨씬 더 간단합니다.15:33

또한 이러한 모듈이나 깊은 모듈들을 회색 상자처럼 다룰 수 있다는 의미이기도 합니다.15:40

좋아요, 인터페이스만 설계할 거고 너무 깊게 신경 쓰거나 검토하지는 않겠다라고 말할 수 있는 거죠.15:47

구현에 너무 많은 신경을 쓸 필요가 없습니다. 이것은 분명히 애플리케이션에서 중요도가 낮은 것들로 할 수 있습니다.15:54

금융 같은 다양한 것들에는 이 방법을 사용할 수 없지만, 앱의 많은 모듈들에서는16:00

모듈 외부에 테스트 가능한 경계가만 있다면, 구현에 대해 너무 생각하실 필요가 없습니다.16:06

그리고 그 목적을 이해하고 외부에서 설계할 수만 있다면요.16:12

이게 제 두뇌를 많이 아껴줬는데요. 제가 그냥 '좋아, AI야, 이 큰 덩어리 안의 내용은 네가 처리해 줘.'라고 할 수 있어서요.16:15

저는 밖에서 테스트를 하고 검증하기만 하면 돼요.16:22

그러면 다섯 번째 팁입니다. 인터페이스를 설계하고 구현을 위임하세요.16:26

하지만 이것은 우리가 코드를 만질 때마다, 무언가를 계획할 때마다16:32

저희가 애플리케이션 내의 모듈들에 대해 생각하고 인지해야 할 필요가 있어요. 저희는16:36

그 맵을 정말 잘 알아야 합니다. 그것은 저희의 공통 언어의 일부가 되어야 해요.16:40

계획 능력에 포함시켜야 합니다. 그래서 제가 PRD 안에16:45

PRD에는 모듈 변경과 인터페이스에 대해 구체적으로 언급합니다.16:49

모듈들이 어떻게 수정되는지 저는 항상 생각하고 있고16:53

이것은 켄트 벡의 시스템 설계에 매일 투자하는 것에서 비롯되었고, 이것이요16:57

그 핵심은 바로 이것이죠. 왜냐하면 시스템 설계에 투자하는 코드가 아니라,17:03

우리는 그것에서 빠져나오고 있습니다. 하지만 이건 제가 생각하기에 절대적으로 중요합니다.17:08

그래서 코드는 만만치 않다는 것이 제가 전해드리고 싶은 메시지예요. 코드는 중요하고17:16

만약 AI를 아주 훌륭한 현장 프로그래머, 일종의 전술적 프로그래머, 상사라고 생각한다면요.17:23

실무에서 코드를 수정하려면 그보다 높은 곳에서 생각하는 사람이 필요합니다.17:30

전략적인 수준에서요. 그리고 그게 바로 당신이 필요로 하는 소프트웨어 기초 기술입니다.17:37

지금까지 20년 동안 사용해 왔어요. 만약 여기에 제가 올린 기술들 중에 관심 있으신 것이 있다면17:43

깃허브 리포지토리 matt pocock skills에 있어요. 아니면 제가 하는 교육에 관심 있으시면17:49

제가 유튜브에도 있고 트위터에도 있지만, AIhero.dev에도 있는데 거기서 뉴스레터를 보내고 있으니 한번 확인해 보실 수 있어요.17:54

정말 감사합니다. 이것이 새로운 AI 시대에 여러분이 실제로 좋은 영향을 미칠 수 있다는 자신감을 얻는 데 도움이 되었으면 좋겠습니다.18:01

감사합니다.18:08