상위 1% AI 네이티브들은 프롬프트 안쓰고 '하네스 깎기'에 수백시간 투자합니다. (DIO FDE 김지운님)
채널: 빌더 조쉬 Builder Josh | 길이: 43:27
자막
00:00 · 총 네 개의 소프트웨어를 세 개 모델에 시켰으니까 12개가 나오게 됐었거든요.
00:06 · 이거는 이제 코덱스가 만들어 준 거, 제미나이가 만들어 준 거.
00:13 · 저희가 디자인 시스템이나 이런 거는 좀 세팅이 돼 있어 가지고 어떤 모델을 시켜도 똑같은 아웃풋이 나오게 됩니다.
00:19 · 클로드를 쓰든 코덱스를 쓰든 제미나이를 쓰든 이 하네스 엔지니어링이라는 기법을 잘 활용하면 다른 AI 모델을 써도 같은 아웃풋으로 나올 수 있게끔 강제할 수 있다.
00:26 · >> 네.
00:26 · 안녕하세요.
00:26 · 구독자 여러분.
00:26 · 네.
00:28 · 오늘 하우아이 AI 팟캐스트에는 이렇게 이제 디오 대표님이신 황현태 대표님과 여기서 포워드 디플로이드 엔지니어로 일하고 계신 김지훈 님을 모시고, 오늘은 어떻게 하면 실제 현장에서 강건하게 소프트웨어를 잘 빌딩하고 일관성 있는 결과물을 전달할지에 대한 내용들을 한번 이야기 나눠 보도록 해 보겠습니다.
00:47 · 엔터프라이즈에 요즘 굉장히 많은 사람들이 관심이 많이 있으신 것 같아요.
00:53 · 그러니까 AX라고 해 가지고 트렌드가 확 퍼지고 있고, 저 개인적으로는 이 변화가 좀 국가적인 변화다라고 생각을 하고 있는데, 그에 있어서 가장 앞서 계신 이 두 분 또 모시고 오늘도 재밌게 한번 이야기를 나눠 보도록 해 보겠습니다.
00:59 · 먼저 우리 스페이스와이의 대표님이신 황현태 대표님, 저희 많이 오셨는데 한번 소개 한번 더 해 주세요.
01:04 · 처음 보시는 분들 많을 테니까. 네. >> 안녕하세요.
01:10 · 엔터프라이즈 AX 기업 스페이스와이의 대표 황현태입니다.
01:17 · 반갑습니다.
01:18 · >> 반갑습니다.
01:19 · 네.
01:20 · 유튜브 이번에 여셨잖아요.
01:22 · 음.
01:23 · 네.
01:24 · 까칠한 AI라고 엔터프라이즈 AX 경험담을 들려드리는 유튜브를 하고 있습니다.
01:27 · 엔터프라이즈 AX 경험이 지금 너무 다들 적기 때문에 이 경험치를 다들 나누어야 된다고 생각을 해요.
01:32 · 그래서 그런 거를 좀 다 같이 계속 공유할 수 있으면 좋겠습니다.
01:38 · >> 네.
01:38 · 너무 좋습니다.
01:39 · 우리 김지운 FDE 님.
01:39 · 네.
01:41 · >> 네.
01:42 · 안녕하세요.
01:43 · 디오에서 포워드 디플로이드 엔지니어로 일을 하고 있는 김지훈입니다.
01:44 · 잘 부탁드립니다.
01:45 · 네.
01:48 · 어, 포워드 디플로이드 엔지니어로 어떤 일을 하고 계신가요?
01:51 · >> 아, 결국 직역을 하면 파견형 엔지니어인데요.
01:55 · 그래서 고객사를 직접 만나뵙고, 회의를 자주 하면서 거기서 나오는 피드백들을 정의해 드리고 같이 제로투원을 하는 역할로 봐주시면.
01:58 · >> 아, 네.
01:58 · 알겠습니다.
02:02 · 네.
02:07 · 좋습니다.
02:10 · 네.
02:13 · 요즘 사실 AI 현장에서 또 많이 나오는 단어가 ‘견고성’이라는 얘기가 있어요.
02:16 · ‘견고성’이 뭐냐면 일관성과 같이 우리가 생각할 수가 있는데, 이런 화제에 대해서 자세한 사례를 통해서 한번 이야기를 나눠 볼 수 있을 것 같습니다.
02:19 · 한번 초반부에 내용에 대해서 간략하게만 소개를 먼저 해 주시고 바로 소개로 넘어가도 좋을 것 같아요.
02:22 · 네.
02:25 · 말씀해 주실 수 있을까요?
02:29 · >> 네. >> 오늘 결국 강건성 있는 결과물을 얻기 위해서 가져온 토픽은 하네스 엔지니어링이라는.
02:31 · >> 아, 핫하죠.
02:31 · 예.
02:32 · 핫하죠.
02:34 · 네.
02:38 · 네.
02:39 · 화면에 대해서 좀 계속 설명해 주시면 너무 좋을 것 같아요.
02:41 · >> 네.
02:44 · 그래서 오늘 준비해 온 거는 이 하네스 엔지니어링을 시연하고자 더미 스펙을 하나 가져왔는데요.
02:48 · 그래서 저희가 흔히 아는 배달 플랫폼을 예시로 가져왔습니다.
02:52 · 그래서 이 배달 플랫폼 같은 경우에는 크게 네 가지 어떤 소프트웨어가 있다라고 전 생각을 하고 있는데, 일반적인 저희가 고객이 주문할 때 쓰는 고객용, 그리고 기사분들께서 음식을 픽업하고 고객한테 전달해 주시는 그런 소프트웨어, 그리고 음식점에서는 주문을 수락하고 그리고 조리로 완료된 걸 알려 주는 소프트웨어.
03:03 · 그리고 이 전체를 관리하는 어떤 배달 플랫폼의 어드민, 이렇게 네 개를 생각을 했고요.
03:14 · 그래서 이 네 개를 가지고 제가 지금 시도하고 있는 하네스 엔지니어링으로 했을 때 어떻게 아웃풋이 나오는지 보여 드리려고 오늘
03:27 · 가져왔습니다.
03:27 · 너무 멋집니다.
03:27 · 네.
03:29 · 저렇게 배달 플랫폼 하나만 설계하는데도 진짜 저게 다 하나의 조직이거든요.
03:34 · 진짜 하나 큰 조직들인데 그것들을 한꺼번에 설계해 놓으셨는데, 왜 이렇게 네 개 정도를 분할해서 저희 얘기 보여 주시는지 좀 궁금합니다.
03:40 · 네.
03:45 · 아, 근데 이 첫 단계로는 이런 요구사항 있는 고객사를 만났다라고 가정을 하고 더미 회의를 진행했다라고 가정을 했습니다.
03:51 · 그러면 질문 주신 것처럼 이게 꼭 네 개여야 하는가는 고객은 모르실 수도 있어요.
03:58 · 처음에는 그냥 고객이 주문하는 앱만 있으면 되지라고 생각하실 수 있다가도 점점 대화를 해 보면, 아, 기사님 앱도 따로 필요한 것도 알게 되시고, 그러다 보면 또 음식점을 위한 앱도 필요하겠다.
04:04 · 그리고 아, 이걸 다
04:12 · 관리하는 우리 사내 어드민도 필요하겠다.
04:20 · 이런 결론이 되게 되는데요.
04:28 · 그래서 이렇게 네 개가 된 건, 아, 고객사 입장에서 ‘난 이런 거 막연히 필요해’라고 했을 때 FD로서 이 얘기를 들어봤을 때 구성 요소를 좀 미시하게 쪼개 봤을 때 여기에 가설적으로는 네 개의 분류가 있고, 그럼 네 개의 분류마다 적합한 소프트웨어가 필요하겠다, 이런 판단을 했다라고 가정하고 네 개로 가져왔습니다.
04:37 · >> 아, 네. 문제 정의를 잘하셨네요. 네.
04:39 · 그러면 그다음에 해야 될 일은 뭔가요?
04:43 · >> 아, 결국 총 여섯 개의 플로우로 오늘 보여 드리려고 왔고요.
04:48 · 그래서 방금 말씀드린 요구 사항을 넣었을 때 이걸 분석해서 플랜을 세우고, 플랜에 맞게 어떤 아키텍처, 강건한 아키텍처를 짜게 되고요.
04:54 · 기능 명세나 어떤 도메인 모델들이 있어야 하는지.
05:00 · 그리고 어떤 아키텍처로 갈 것인지 이거를 AI가 알아들을 수 있게 코드 레벨로 디자인 설계를 하고, 그리고 저희는 하네스 엔지니어링 구성 요소 중 하나는 또 저는 잘 쓰는 게 린터가 있거든요.
05:17 · 린터 기반으로 모든 코드 아웃풋에 여러 선택지가 있다면 하나로 강제할 수 있게끔 린터를 사용하는데, 코드를 만들고 린터로서 어떤 결과물을 검토하고, 결국에 제가 오늘 말씀드리고 싶은 거는 클로드를 쓰든 코덱스를 쓰든 제미나이를 쓰든 이 하네스 엔지니어링이라는 기법을 잘 활용하면 다른 AI 모델을 써도 같은 아웃풋으로 나올 수 있게끔 방향을
05:36 · 강제할 수 있다.
05:37 · 혹은 방향을 조절할 수 있다.
05:38 · 이런 걸 보여 드리려 왔습니다.
05:39 · >> 아, 너무 멋있습니다.
05:41 · >> 네.
05:43 · 그래서 지금 처음 단계부터 어떻게 진행이 되고 있는지 좀 더 자세하게 설명을 주실 수 있을까요?
05:47 · >> 네.
05:54 · 그래서 여기에서도 제가 더미로 적어 놨지만 네 개 막연한 요구 사항을 각각 이걸 검증하기 위해서 각각의 클로드랑 제미나이랑 코덱스에 시킨다라고 가정을 했고요.
06:00 · 그래서 첫 단계는 아, 고객용 어떤 주문 앱이 필요해요라는 거.
06:07 · 그리고 기사님께 어느 위치에 있고 어디로 가야 되는지 알 수 있는 앱을 만들어 주세요라는 네 문장의 요구사항이 있다라고 가정하고 첫 단계를 시작한 겁니다.
06:16 · >> 네.
06:19 · 그러면 이 단계에서 우리가 봐야 될 핵심 뭐 사항이 있나요?
06:22 · 아, 요건 없습니다.
06:25 · 인풋 자체는 저희는 고객사나 혹은 고객분들에게 비정형적으로 편하게 주실 수 있도록 하고 있거든요.
06:29 · >> 그러니까 그냥 전체적으로 ‘아, 이런 구조가 있을 것 같다’라고 하는 가정을 먼저 문서다, 뭐 이렇게 생각하시면 좀 편하실 수도 있겠네요.
06:31 · 네.
06:34 · 네.
06:37 · 그럼 그다음 단계는, 플랜에 대해서는 우리가 중점적으로 봐야 될 부분은 뭔가요?
06:41 · >> 네.
06:41 · 결국 플랜에서는, 각 미팅마다 FD를 계속 가정을 말씀드리면 주에 두세 번을 뵙는데요.
06:50 · 그럼 만약에 두 번을 뵙는다라고 가정했을 때 회의를 오전과 오후, 그러니까 출근 직후와 퇴근 직전에 하게 됩니다.
06:55 · 그럼 총 네 번의 미팅이 고정적으로 됐는데요.
07:01 · >> 그럼 각 회의마다 직전에 완성된 거랑 오늘 해야 될 거, 혹은 오늘 완수한 거, 이거를 리뷰하게 됩니다.
07:10 · 그래서 플랜에서 하는 거는 한 시간 회의 동안 막연하게 이야기한 거를 구조적으로 정리하는 게 하나의 구성 요소가 있습니다.
07:20 · 그래서 플랜은 총 세 가지 구성 요소가 있는데, 첫 번째 구성 요소는 서로 회의를 되게 발산적으로 하고 그것을 수렴해서 정리하는 미팅 로그를 적는, 그게 플랜 중 하나입니다.
07:30 · >> 네.
07:30 · 미팅을 하고 그걸 모두 전사화시킨다가 있는 거죠.
07:31 · 네.
07:33 · 그래서 나온 요약을 하고 어떤 게 부족했고 어떤 게 잘됐고 어떤 건 필요하지 않고, 어떤 거는 직접 구축하지 않고 어떤 기존 솔루션을 사서 쓸 건지, 어떤 거 우리가 직접 구현해야 되는지 이런 거를 분석하게 됩니다.
07:48 · >> 그리고 약간 미팅 원칙이 두 개가 있다면 하나는 제한하지 않는다.
07:54 · >> 예.
07:54 · 그냥 하고 싶은 말 다 하시라.
07:55 · 하시라.
07:56 · >> 편하게.
07:57 · >> 예.
08:00 · 저조차만 해도 미팅을 하다 보면 제한하기도 하거든요.
08:02 · 그건 습관적인 저의 태도인데, 그래서 두 명 정도가 같이 가면 서로가 그거를 막습니다.
08:08 · >> ‘고객을 막지 마라’라는 거를 느낌적인 느낌으로 눈빛으로 전달하거든요.
08:12 · 그럼 아차 하면서 다 말씀하시라고 이런 식으로 좀 제한하는 게 있어요.
08:17 · >> 그렇죠.
08:22 · 저도 최근에 이제 AX 하면서, 아, 고객의 요건을 상세하게 파악하면 할수록 너무 좋다.
08:26 · 모든 게 다 데이터가 되니까라는 생각이 들었는데 재밌습니다.
08:30 · 근데 지금 제가 궁금한 거는 저 플랜 단계에서 제미나이, 클로드, 코덱스가 저렇게 나뉘어져 있는데 왜 그런 거예요?
08:34 · 아, 저는 지금 클로드만 쓰고 있긴 한데요.
08:40 · >> 다른 AI 모델을 쓰더라도 이 하네스 엔지니어링 기법을 사용하면 뭘 해도 필연적인 결과가 나올 거다라는 걸로 가져오게 된 겁니다.
08:49 · >> 아, 그러니까 개별 문서조차 어쩌면 일관성이 있게 나올 수가 있다라고 하는 것이죠.
08:57 · 재밌는 관점이네요.
09:00 · 아, 계속 시기에 따라서 어떤 랭킹이 바뀌잖아요.
09:04 · 언제는 오퍼스 4.0이 제일 좋았다가, 언제는 이제 GPT 5.3이 더 좋았다가.
09:07 · >> 네.
09:07 · 근데 저희는 AI 모델을 만든 사람은 아니고 AI 모델을 가져다 쓰는 사람이니까 어떻게 하면 정말 잘 가져다 쓸까?
09:16 · 그래서 다른 모델이 바뀌더라도 이 기법은 유효하다.
09:20 · 이게 중요하거든요.
09:24 · 저한테는, 저희 팀에. 그래서 세 개를 가졌습니다.
09:28 · 플랜을 쓰는, 그러면 저 문서를 쓰는 별도의 프롬프팅을 좀 빡세게 깎아 가지고 내놓은 결과가 저거다라고 하는 거라고 보면 될까요?
09:33 · >> 네.
09:37 · 아, 그래서 세 개의 AI 모델들을 보여 주셨는데 저 내용들이 어느 정도의 일관성이 존재한다라고 하는 걸 말씀해 주시는 거군요.
09:43 · >> 아, 재밌습니다.
09:47 · 그럼 그다음 단계는 어떻게 되나요?
09:52 · 그다음부터 이제 기획의 요소로 가게 됩니다.
09:56 · 그래서 저희는 가장 하이레벨한 기획 요소는 컨텍스트-프라블럼-솔루션이에요.
10:01 · 그래서 이건 현태님이 초후반에 제안을 해 주셨는데, 이 얘기를 듣고 아, 어떤 맥락에서 어떤 문제를 겪고 있기 때문에 우린 어떤 솔루션을 제시해야 될지, 어떤 솔루션을 같이 만들어야 될지를 정리하게 됩니다.
10:08 · 솔루션을 제시한다는 것은 문서랑 어떤 부분이 다른 건가요?
10:12 · 정확히는 미팅 로그에서도 솔루션을 우리가 생각해 볼 수 있긴 한데, 저거는 지금 보니까는 CPS라고 표현을 하는 거 같아요.
10:18 · 저게 뭔지에 대해서 좀 더 자세히 설명해 주시면 좋을 것 같아요.
10:20 · >> 아, 일단은 CPS도 문서 유형 중에 하나고요.
10:23 · 어떻게 보면 생각을 정리하는 프레임워크일 수 있습니다.
10:27 · 저희가 처음에 SKT 프로젝트로 만나게 됐는데 그때 어디서 본 게 있었어요.
10:36 · 팔란티어는 처음에 미팅을 할 때, 내부에서 FDE 미팅을 할 때, 머드 미팅, 머드 세션 뭐 이런 걸 통해서 다양하게 발상을 하고 발산도 하고 수렴을 한다라고 해서, 우리는 어떤 프레임워크를 처음에 도입해 볼까
10:47 · 했을 때 제가 프로덕트 매니저일 때는 저 컨텍스트-프라블럼-솔루션의 프레임워크로 생각을 많이 했었거든요.
10:54 · 그래서 이걸로 우리가 한번 정리해 보자라는 얘기를 하게 되었었고요.
10:58 · 이게 그냥 생각 정리를 할 때 고객의 문제가, 그리고 문제에 대한 솔루션은… 근데 이 문제와 솔루션을 얘기하기 전에 앞단에 우리가 미리 다
11:09 · 같이 싱크를 맞추고 있는, 깔고 있는 컨텍스트 해서 CPS로 문서들을 정리를 하게 됐습니다.
11:15 · 왜냐면 매번 우리는 프라블럼을 발견하고 솔루션을 고안하게 되니까 그때마다 컨텍스트는 계속 쌓여 가는 것이고, 그래서 CPS 문서를 많이 썼거든요.
11:23 · >> 너무 좋네요.
11:29 · 컨텍스트가 있는 거 자체가 다른 사람이 보더라도 맥락을 한 번에 이해하고 그것부터 시작을 하기 때문에, 백그라운드 기반의 솔루션이 저렇게 나왔구나라는 형태로 서로 공유가 되는 것이죠.
11:35 · 그런데 지금 보여주시는 화면도 그러면 각자의 AI 엔진들이 저렇게 유사하게 결과물도 낼 수가 있었다라고 하는 걸 보여 주시는 거군요.
11:42 · >> 맞습니다.
11:43 · >> 그리고 저희는 좀 컨설팅의 성격도 매우 강하거든요.
11:49 · 그래서 고객사 원하는 솔루션을 고정한 채로 컨텍스트랑 프라블럼을 정의해야 될 수도… 그러면 저거를 궁금한 게 이제 저 문서를 제작을 해서 내부용으로 쓰시나요?
11:54 · 아니면 저희 클라이언트 공유용으로 어떻게 쓰시나요?
12:01 · >> 아, 클라이언트 공유용으로도 씁니다.
12:03 · >> 아.
12:06 · 음, 이걸 이제 마크다운 문서로 파일은 갖고 있다가 PDF로 잘 빌드하는 또 저희 어떤 LaTeX 템플릿이 있거든요.
12:09 · 그걸로 빌드해서 드립니다.
12:13 · >> 음.
12:19 · 궁금한 게 문서를 먼저 전달을 해 주시는 게 선행인지, 요즘 사실 프루프 오브 컨셉, 그러니까 POC는 결과물, 그러니까 한마디로 ‘미팅 끝났고 바로 미팅 투 프로덕트’가 되는 시대잖아요.
12:24 · 그죠?
12:30 · 근데 미팅 끝나서 결과물을 바로 보여 주는 형태로 보통 하시는지, 뭐 아니면 이런 식으로 문서를 전달하시는지, 시점에 대해서 좀 더 구분해서 설명해 주실 수 있을까요?
12:35 · 이게 해 보니까요.
12:41 · 문서는 총 POC 기간 중 두 번 정도 공유 드리게 되는데, 그러니까 첫 번째는 어느 정도 1차 스펙이 확장됐을 때 드리게
12:48 · 되고, 그리고 두 번째는 프로젝트 다 끝났을 때 오히려 역기획해서 드리게 됩니다.
12:58 · 그래서 결국 말씀 주신 것처럼 매번 소프트웨어 결과물만 가져와요.
13:04 · 대부분은.
13:11 · 그렇지만 고객 입장에서도 이 문서화된 산출물도 필요하시다 보니까, 프로젝트 한 초반에는 아, 우리가 이야기한 기능 명세는 이렇고 어떤 분석 과정을 통해서 얻게 됐다, 이런 거를 문서를 드리게 됩니다.
13:17 · 그래서 이 문서는 초안이고, 우리 얼마든지 발산할 수 있고 산출물이 확정됐을 때 또다시 역기획해서 드리겠다, 이런 식으로 하게 됩니다.
13:26 · 아, 기획서가 그럼 계속 업데이트가 되지 않나요?
13:27 · 계속, 결국 결론적으로 네.
13:29 · 그러니까 결국은 미팅할 때마다 저는 새로운 요건들이 다시 나오고, 사람은 사람이렇거든요.
13:34 · 해보니까.
13:37 · 결과 딱 갖고 왔는데 저희 생각에는 ‘이게 좀 더 이렇게 됐으면 좋겠는데요’가 되게 많아요.
13:41 · >> 음.
13:47 · 그래서 그러면 그거를 또 항상 담을 수 있는 V2, V3, V4의 문서를 우리가 계속해서 업데이트를 할 수가 있다.
13:53 · 네, 라고 판단하면 되는 것이고, 그리고 그거가 최종적으로 업데이트가 된다고 했었을 때는 프로젝트가 완수가 됐을 때 같이 전달드릴 수가 있는 그런 산출물이다라고 보면 되겠네요.
14:01 · >> 맞습니다.
14:03 · 고객사 입장에서는 저희 깃에 초대드리기 때문에 이 CPS 문서 필요하면 매번 업데이트가 됩니다.
14:08 · 그래서 매번 보실 수 있는데, 저희가 형식적으로 전달드리는 거는 매번 업데이트 됐다고 드리면 좀 너무 바쁘잖아요.
14:13 · 그래서 한두 번 정도, 전체적으로 이 내용이 전체적으로 업데이트가 다 됐습니다라고 하는 것까지 한 산출물로 전달을 한다.
14:17 · 네.
14:24 · >> 깔끔하고 좋네요. 네, 너무 좋습니다.
14:28 · 그러면 그다음 단계는 어떻게 되나요?
14:32 · 다음 단계, 점점 정통의 기획 방식으로 넘어가게 되는데요.
14:36 · 그럼 PRD를 작성하고, 그다음에는 결국 디자인 쪽으로 넘어가게 되는데, 이때도 어떤 스펙인지… 결국 플래닝이랑 디자인은 굉장히 맞닿아 있긴 하지만요.
14:42 · CPS 이후에는 저희가 흔히 아는 기획 문서로 넘어가게 됩니다.
14:45 · >> 아, 그렇군요.
14:50 · PRD를 클라이언트께서 다 보시나요?
14:54 · 어, 엄밀히 리뷰하지는 않는 거 같아요.
14:58 · 그거를 논의하기도 전에 산출물을 보고 정말 다양한 레벨에서, 그러니까 여기 있는 버튼 마음에 안 들어도 되고, 아, 우리 소프트웨어가 하나 더 필요할 것 같아요.
15:03 · 아니면 이건 굳이 합쳐도 될 거 같아요.
15:07 · 같은 시스템적인 어떤 되게 하이레벨한 리뷰도 하게 되거든요.
15:11 · 그래서 문서는 정말 POC 기간 전체 내에 했던 이야기를 잘 구조적으로 정리한 어떤 산출물인 거고, 이 문서 자체를 잘 리뷰하진 않습니다.
15:16 · 그렇지만 그래도
15:22 · 프로젝트가 계속 진행이 되면서 업데이트는 수시로 이루어진다는 거잖아요.
15:28 · 그죠?
15:33 · 저 전체적인 문서가 예를 들면 뭐 10개짜리야라고 한다고 하면, PRD 있고 아까 CPS 있고 뭐 디자인 임플리멘테이션 문서, 이런 실행 문서가 있고, 이런 것들이 그냥 계속 프로젝트 주기 내내 업데이트가 된다라고 판단하면 되나요?
15:41 · 맞습니다.
15:42 · 아, 그래서 메인 브랜치에 계속 그게 존재하고, 그것들이 커지는 그런 느낌인 거군요.
15:43 · 아, 네.
15:48 · 그래서 이게 미팅 로그가 미팅 한 횟수만큼 생길 거잖아요.
15:51 · 그럼 모든 미팅 로그를 종합한 하나의 CPS가 결국 특정될 거고요.
15:56 · >> 네.
15:57 · >> 그리고 또 미팅 로그를 다 종합한 하나의 PRD가 또 결정될 거고요.
16:02 · >> 네.
16:02 · 기가 막히네요.
16:05 · 아, 그렇구나.
16:05 · 아, 이해했습니다.
16:08 · 네.
16:09 · 저렇게까지 쪼갠다.
16:11 · 네.
16:12 · 의외로 고객사분들께서 저희의 이 설계를 궁금해하시는 경우도 꽤 많습니다.
16:15 · 그리고 필요한 경우도 있고, 그래서 첫 번째 생각이 들었던 거는, 이게 요즘 딸깍하면 잘 나온다는 거는 이제 고객사들도 잘 알고 계시니까
16:26 · 어떤 세계관에서 어떻게 설계됐는지 궁금해하시는 경우가 되게 많아요.
16:34 · 그거를 한번 알려 달라.
16:42 · 그래서 그거를 저희가 만든 PDF 문서를 기반으로 한번 쭉 설명을 드리는 경우도 있어요.
16:50 · 왜냐면 결국 그들이 좀 더 아이디어를 더 발상을 잘해 내려면 우리의 구현 세계관을 알아야, 그다음에 아이디어도 더 잘 줄 수 있는 경우도 있어서, 그게 하나 있었고.
17:00 · 두 번째는 그래서 세계관을 이해하기 위해서 저희한테 발표를 시키기도 하지만, 문서를 가지고 충분히 공부를 하셔서 그다음 미팅에 딱 갔더니 ‘아, 이제는 세계관을 이해했다. 아키텍처도 이해했다.’
17:03 · 그렇게 해서 조금 훨씬 커뮤니케이션 좋았거든요.
17:05 · 그래서 문서가 주는 매력도 있습니다.
17:09 · 맞네요.
17:14 · 저 같은 경우에는 항상 구현을 하고 나서 ‘이렇게 구현을 했습니다’라고 하는 보고서를 저도 항상 전달을 하긴 해 드려요.
17:18 · 근데 이제 저는 플레이라이트 MCP로 넣어 가지고 화면 다 해서, 이런 식으로 약간 매뉴얼화를 해서 하는 형태로 그냥 주드리거든요.
17:23 · 네.
17:28 · 그냥 스크린샷이랑 이거 같이 보시고 그냥 만화처럼 이해하셔라.
17:33 · 이런 식으로 저는 전달하는 형태를 하고 있는데, 이런 문서를 지속적으로 공유해서 회의 전에 이제 파악도 해보고, 계속 이해도를 서로 높여가는 이 커뮤니케이션이 너무너무 좋은 거 같아요.
17:39 · 저는.
17:42 · 네.
17:45 · 네.
17:49 · 그것도 너무 좋고, 일관성 있는 결과물도 너무 좋은 거 같은데, 실제로 이런 기획 문서들이라든가 이런 것들이 정말 일관성 있게 나오게 하시려면 어떻게 하네스를 좀 하셨는지에 대해서 조금 더 공유해 주실 수 있을까요?
17:53 · >> 아, 네.
17:54 · 우선 목차를 먼저 보여 드리면, 이게 설계 분석인데요.
17:59 · >> 원칙을 세우게 됩니다.
18:00 · >> 각 프로젝트마다 원칙이 다를 순 있지만, 뭐 예를 들면 대부분 에이전트 프로젝트를 하게 되면 휴먼 인 더 루프나, 혹은 할루시네이션이 없어야 된다거나, 혹은 로그가 잘 남아야 된다거나 이런 것들이 있을 수 있는데, 이런 대전제 원칙들을 세우게 되고요.
18:17 · 그리고 우리가 고객사분들과 같이 하면서 개념 정의도 내리게 됩니다.
18:22 · 그럼 이 두 개만 돼도 각 개념의 하이어라키를 정하게 되면 구조를 짤 수 있게 되고, 구조에 맞게 데이터를 어떻게 주고받을지 기술적으로 설계를 하면 결국 결과물들이 필연적인 방향으로 가게 된다라고 저는 생각을 하고 있습니다.
18:38 · >> 음.
18:42 · 음.
18:46 · 음.
18:50 · 야, 유저 멘탈 모델도 넣어 놨다.
18:53 · 너무 대단하시네요.
18:57 · 저렇게 프린서플을 세워 놓는 데 있어서 가장 중점적으로 봤던, 뭐 그런 사례라든가 혹은 저렇게까지 하셨던 배경에 대해서 좀만 더 설명해 줄 수 있을까요?
19:01 · 아직은 어떻다라고 뭔가 말씀드리기 어려운 거 같아요.
19:05 · 근데 왜 어렵냐면 굉장히 트렌드도 많이 타고요.
19:09 · 이런 설계 기법은 또 엔지니어로서만의 관점으로도 안 되고, 어떤 창업자로서만의 관점도 안 되고, 그니까 정말 보고 듣는 게 너무 많기도 하고, 레퍼런스도 있고 그냥
19:16 · 누군가의 카더라 이야기도 있고 이러다 보니까, 어떤 걸 봐서 이렇게 됐는가에 대한 명쾌한 답변은 아직 드릴 수는 없을 것 같지만, 네, 그렇습니다.
19:28 · 한마디로 이게 굳어진 어떤 구조적인 관점이라기보다는, 지금까지 이제 내가 배웠던 어떤 지식 같은 것들을 녹이다 보니까 어쨌든 상위 레벨에서 원칙들을 세우게 됐고, 원칙들이 이제 상세하게 데피니션으로도 넘어가게 됐고, 그리고 그다음에 데피니션 정의 다음에는 스트럭처, 구조로 빠지게 되는 형태로 갔다.
19:39 · 결론적으로는 어쨌든 우리는 되게 매시브한 부분에서 계속 미시하게 파고 들어가는 그런 과정들을 했었는데, AI 엔지니어링을 같이 하다 보니까 저런 내용들이 좀 쪼개졌던 거 같다라고 인식하면 될 거 같네요.
20:00 · >> 맞습니다.
20:02 · 이런 문서 적을 때 저도 미시하게 엄청나게 분석을 많이 하는데요.
20:04 · 근데 그걸 하다 보면 너무 시간이 오래 걸리기도 합니다.
20:08 · >> 그래서 양쪽의 관점을 다 갖고 있게 되거든요.
20:17 · 그래서 정말 엄밀하고 견고한 설계를 하는 것과 동시에, 당장 내일 혹은 오늘 오후에 산출물도 뽑아내야 되다 보니까, 그런 너무 안정적인 설계와 당장의 산출물을 어떤 트레이드오프를 하게 됩니다.
20:28 · 네.
20:31 · 그렇군요.
20:35 · 그렇게 했을 때 이게 지금 지우 님 본인 스스로만 공유하는 게 아니라 디오 팀 내에서도 같이 공유가 돼야 되는 건 사실이잖아요.
20:40 · >> 지금 어떻게 하고 계세요?
20:44 · 지금 이제 되게 고전적인 방식인데, 다른 프로젝트에 들어갈 때, 예를 들면 이제 지우님의 경험을 같이 공유받는 방식을 쓰고요.
20:48 · 그때 ‘지우 님 요거 할 때 어떻게 하셨어요?’
20:52 · ‘왜, 뭐 고객한테 공유할 때 어떻게 하세요?’
20:57 · 하면서 옛날에는 개발자들 협업할 때 코드 레벨 단위, 뭐 라이브러리 요런 걸로, 코드 모듈로서 경험치를 공유를 했다면, 지금은 요런 방법론, 요런 사상, 그리고 요런 하우투, 요런 노하우를 공유를 하게 되더라고요.
21:13 · >> 개발자분들끼리 서로 이제 팀으로 일할 때 컨벤션을 항상 공유를 많이 했었잖아요.
21:15 · 예전부터.
21:16 · 그죠?
21:20 · 네.
21:26 · 이제 코드 컨벤션이든, 어쨌든 위키 컨벤션이든, 이런 것들을 굉장히 공유를 많이 하고 원칙대로 우리는 이렇게 일을 하자라고 하는 형태로 일을 하는 것으로 저는 이해를 하고 있어요.
21:32 · 근데 지금은 저런 문서로서 작업을 할 수가 있는 것이고, 그걸 퍼뜨리는 일을 지금 지우 님께서 내부적으로 하고 있다라고 판단을 하면 되겠네요.
21:38 · >> 네.
21:39 · 근데 각자마다 문서 스타일이 있고요.
21:40 · 이걸 공유하는 거는 만든 사람이 결정하는 거 같아요.
21:41 · 그러니까
21:44 · 저도 고객사 분들 이야기를 듣고 이 원칙이 결국 최종 결과물에 굉장히 영향을 크게 준다는 걸 아니까
21:52 · >> 그럼 저는 회의를 열어서 리뷰를 드립니다.
21:58 · 제가 각자의 어떤 강점이 있고 관점이 있다 보니까, 이런 식으로 설계를 했을 때 어떻게 보이는지, 어떻게 들리는지, 타당한지 이런 거를 여쭤보고요.
22:04 · 저희는 그래서 워크숍을 다 파견을 가는 게 아니라 팀 내에 모여서 이런 걸 리뷰하는 고정 요일들도 있거든요.
22:09 · 네.
22:15 · 그때 오픈하고 저는 이런 식으로 설계하지만 또 다른 분은 다르게 설계하게 되는데, 서로 영향을 주고받으면서 집단지성을 만들어 가고 있습니다.
22:23 · >> 음.
22:29 · 그렇게 이제 기존 멤버들과 협업을 그런 식으로 하고 있는데, 그러면 이게 공유가 되는데 어디에 공유가 되나요?
22:36 · 보통 DO에서는 어쨌든 그러면 그런 형태로 조직 내에서는 어떻게 이런 컨벤션을 좀 더 공유하시는지를 좀 듣고 싶었어요.
22:43 · 말 그대로 그냥 이제 주간 회의를 해서 나누는 수준이 아니라, 우리가 다음 달 다음 단계의 레벨은 이게 엔지니어들 간의 합의된 어떤 메인 브랜치 같은 게 있지 않을까라는 그런 생각은 좀 있었었거든요.
22:49 · 우선 현태님 이야기도 들어봐야겠지만, 일단 제가 경험하고 있는 바로는 저희는
22:59 · 어떤 업무, 어떤 방식 자체를 통일하진 않아요.
23:04 · 제 생각에는 저의 멘탈 모델을 일치시키는 거에 더 집중하는 거.
23:10 · >> 아, 그래요?
23:10 · 어.
23:10 · >> 근데 모든 산출물은 저희는 다 오픈이 되어 있어요.
23:15 · 저희 GitHub, 팀 GitHub에 다 오픈이 되어 있고, 그리고 모든 어떤 로그들은 노션에 다 있고, 그리고 슬랙이 있고, 저희 그렇게 세 개밖에 안 쓰는데요.
23:21 · 거기에서 서로의 프로젝트 이어받을 수도 있고 뭐 넘겨받을 수도 있거든요.
23:26 · 그때는 그걸 살펴보지만 ‘이 사람은 어떤 코딩 컨벤션으로 하지?’까지는 회귀하진 않습니다.
23:32 · >> 음.
23:34 · >> 왜 멘탈 모델만 공유를 하게 되나요?
23:37 · 해 보니까 좀 느꼈던 건데, 프로젝트마다 지향하는 꼴, KPI가 프로젝트마다 다르잖아요.
23:45 · 그러다 보니까
23:47 · 뭘 제1원칙으로 두냐라고 했을 때, 우리는 고객이 뭘 기대하냐, 그거를 훨씬 뛰어넘는 우리의 하우투나 아니면 아웃풋이 요거를 계속 생각을 하게 되더라고요.
23:52 · 이게 처음에는 뭐 고객한테 보이는 거를 뭐 100% 스펙으로 가져가야 된다.
23:56 · 아니면 뭐 200%의 속도로 가져가야 된다.
24:01 · 뭐 이런 거를 여러 가지 정하고, 뭐 거기에 따른 하우투나 뭐 에이전트… 뭐 공유하는 이런 것도 썼었잖아요.
24:06 · 모델 컨텍스트 프로토콜이라고 있습니다.
24:10 · 여튼 그런.
24:10 · >> 아, 잘 쓰고 있습니다.
24:15 · 어, 그런 거를 쓰기도 했는데 결국
24:22 · >> 모이고 모여서 보니까 방법론들이 워낙 달라 가지고, 그것보다는 우리가 진짜 지켜야 될 원칙 몇 가지만 정해 놓는 게 지금으로서는, 초기에는 우리가 하고 있는 방식이, 제 생각에는 이제 비즈니스의 성격 때문에 그런 거 같아요.
24:38 · 제 생각은 그냥 고객의 성공을 도와야 되는 일인데, 고객의 성공을 돕기 위해서 사실 우리나라에 있는 수많은 에이전시 컨설턴트가 있는데, 컨설턴트 중에 일단 고전적으로는 예전에 이제 맥킨지나 혹은 BCG 같은 회사들은 기획 방법론 같은 것들 자기들끼리 책으로 만들고 배포하고 이런
24:56 · 식으로 일을 하긴 했었거든요.
25:00 · 근데 이제 AI 같은 경우에는 이제 탄생하는 개념이다 보니까 그런 것들이 고정화된다든가 정형화된다든가 이런 것을 당장 만들기는 어렵지 않을까
25:07 · 하는 생각도 첫 번째 들었고, 두 번째로는 저 고객사 내부의 프로세스가 좀 더 스며들려면 우리가 어떻게 해야 되는가 하는 생각도 전 좀 있었었습니다.
25:16 · 이게 그들의 문제는 제 생각은 이런 단계는 사실 상상도 못 하고, 물론 클로드 코드나 하네스가 뭔지부터 배워야 되는 게 작금의 현실이겠지만, 그래도 내부적으로 정확히 자산화를 할 수 있는, 그리고 서로의 통합된 어떤 원칙 같은 것들은 이제 좀 만들어야 된다고 생각하고 있거든요.
25:24 · 근데 그거는 결국은 AI 문서다라고 저는 생각은 하고는 있어요.
25:33 · 근데 힌트를 좀
25:44 · 같이 찾아 나갔으면 하는 바람이 있습니다.
25:45 · 저도 네.
25:47 · >> 그게 원래 저희도 시작할 때 거대한 꿈을 안고 포워드 디플로이드 엔지니어링이라는 레포를 만들어서 거기서 뭔가 여러 가지 정의하고 규율을 좀 만들어 보려고 했는데, 이게 제 생각에 스타트업 레벨에서 뭔가를 할 때는 그냥 아무렇게나 하고 자유도를 높게 가져가는 게 되게 중요하다고 생각하거든요.
25:58 · 트렌드를 빨리 쫓아.
26:10 · 근데 또 엔터프라이즈에서는 어느 정도 방법론과 프레임을 가지고 하는 게 중요한데, 엔터프라이즈 경험치를 그렇게 많이 쌓기가 쉽지가 않은 거예요.
26:20 · >> 예.
26:22 · 그게 그래서 저희가 레포 만들어 놓고 진행 이후에 저희가 결국 따낸 계약이 뭐 다섯 개, 여섯 개 그렇거든요.
26:25 · 그러니까 경험치 쌓는 게 좀 어렵더라고요.
26:27 · 그래서 다
26:31 · 같이 힘을 모아야 됩니다. 이 엔터프라이즈 레벨, 특정 사이즈 이상의 어떤 팀을 대상으로 AX를 한 사람들의 어떤 경험치가 다들 모여야 되고. 맞아요.
26:49 · 김지훈 님이 재밌는 시도를 많이 하는데, 포워드 디플로이드 엔지니어링으로 지금 논문 초안도 작성하고 그러고 있거든요.
26:49 · 그러니까 이게 진짜 우리가 세팅해 나가야 할 어떤 분야라고 생각이 들어요.
26:54 · >> 저도 진짜 동감하고요.
26:58 · 정말 100% 아직 초기 단계이지만, 그래도 이만큼 많이 발전을 해서 보여 주신 게 너무 감사하다라는 생각이 또 듭니다.
27:04 · 네.
27:04 · 그럼 다음 단계에도 확실히 뭐 보여줄 수 있을까요?
27:06 · >> 네.
27:14 · 그래서 설계가 잘되게 되면 이제 코드 레벨로 넘어가게 됩니다.
27:22 · 그래서 방금 말씀드렸던 어떤 대전제와 어떤 도메인… 저희 흔히 하는 도메인 드리븐 디자인을 저는 채택해서 많이 사용하는데, 요구사항에 맞는 도메인 모델이 몇 개가 있고 어떤 아키텍처, 어떤 하이어라키로 되어야 되는지가 결정이 되면 사실 코드는 쭉 작성이 되면 되거든요.
27:30 · 그래서 이 코드 작성하는 데 걸리는 노력이 매우 줄어들었으니까, 이제 설계안을 가지고 AI 요청만 하면 되는데, 여기 보면 실제 작성되는 코드들이거든요.
27:41 · 그럼 저는 여기서부터 다 린터를 통해서 이 코드의 아웃풋을 통제하게 됩니다.
27:49 · 그래서 어떻게 통제를 하게 되냐면, 레스토랑 리스트 페이지라는 게 있는데요.
27:54 · 이게 누구는 레스토랑 페이지라고도 할 수도 있고, 뭐 레스토랑 서치 페이지라고도 할 수 있거든요.
27:57 · 근데 저는 도메인 관점에서 레스토랑이 모여 있으면 복수형의 페이지로 강제하게 됩니다. 린터로.
28:01 · 그래서 레스토랑 페이지도, 레스토랑 디테일 페이지 이런 식으로 명명을 하기도 하거든요.
28:07 · 근데 디테일, 리스트 이런 거는 파일명에 못 들어가게끔 저는 린터로 강제합니다.
28:11 · 그래서 어떤 AI 모델을 써도 무조건 이 파일명으로 가게 돼 있고요.
28:16 · 그럼 이 파일명으로 강제되면 이 코드의 하위 클래스나 하위 헬퍼 메소드의 명칭도 강제할 수가 있겠죠.
28:23 · 그리고 저는 임포트 문의 알파벳 순서랑,
28:32 · 그리고 임포트 가능한 파일, 임포트가 안 되는 파일, 그리고 익스포트할 때 만드는 배럴 파일의 어떤 규칙, 이런 것도 다
28:44 · 린터로 하게 됩니다.
28:49 · 저렇게 코드를 강제하게 됐었을 때에, 이제 저는 이게 일장일단이 있다는 생각이 개인적으로 좀 들었어요.
28:55 · 그러니까 마치 이런 거 같아요.
28:59 · 저는 디자이너다 보니까 디자이너 입장에서 해석하면, 이제 결과물을 우리는 어떤 브랜드 가이드에 맞춰서 디자인 시스템에 맞춰서만 내놓을 거야.
29:03 · 대신에 일관성이 굉장히 있고 디자인 퀄리티가 하이 퀄리티야라고 하는 쪽으로 저희는 일을 하거든요.
29:07 · 디자인 시스템을 그래서 만드는 거죠.
29:12 · 근데 이거는 이제 코드에 말 그대로 시스템을 딱 강제해 가지고 그대로 나오게끔 해서 퀄리티를 유지하겠다.
29:16 · 그리고 일관성, 견고성을 가져가겠다라고 하는 그런 접근 방식인 거잖아요.
29:20 · 맞습니다.
29:25 · 그죠?
29:26 · 그랬을 때 장단점이 있지 않을까 싶기는 해요.
29:28 · 아, >> 네.
29:30 · >> 우선 단점은 현태님께 한번 들어보는 걸로 하고요.
29:36 · 저 장점밖에… 장점밖에 생각이 안 나 가지고.
29:42 · >> 좋아요.
29:42 · 네.
29:47 · 근데 저는 이렇게 시도한 이유는 AI로 바이브 코딩하기 전에도 항상 코드는 결정적이고 단일 선택지만 남기도록 선택을 고민했었는데요.
29:53 · 코드 리뷰어 입장에서도 작성하시는 분이 어떤 생각으로 썼는지 알 수 있게끔 도구를 만드는 거에 추천 많이 했었어요.
30:00 · 그니까 이유가 뭐냐면 어떤 해당 기능이 망가졌다라고 판단이 됐을 때 파일을 아예 지우고 새로 작성하는 식으로 했었습니다.
30:13 · AI 나오기 전에도. 왜냐면 그거를 리팩토링 하면 당연히 좋겠지만, 그것보다도 항상 선택지로는 해당 코드에 버그가 있고 이게 단순한 수정으로 어려울 것 같다.
30:25 · 그러면 코드의 역할이 뭔지로서 다 강제가 되어 있었다면은, 얘를 그대로 덜어내서 원래 연결돼 있던 인터페이스랑 구현체가 무엇인지 다시 역추적해서 다시 구현할 수 있거든요.
30:39 · >> 근데 그거에 대한 노력이 AI는 너무 쉽게 되잖아요.
30:39 · 네.
30:40 · >> 그래서 저는 이 필연적인 코드가 나올 수 있도록 많이 추구하고 있어요.
30:45 · >> 아, 들어보니까 확실히 설득이 되네요.
30:48 · 혹시 단점 같은 게 있어요?
30:50 · 있죠.
30:52 · 저희가 원하는 품질을 일관성 있게 맞추려고 하는 작업이다 보니까, 이게 제가 생각하는 겁니다.
30:55 · 원래 AI가 읽기 편한, AI가 이해하기 편한, 그리고 생성하기 편한 어떤 스타일이 분명히 존재할 거라고 생각해요.
31:01 · 지금요
31:07 · 방식들은 우리가 생각하는 어떤 가드레일을 쳐 놓는 거기 때문에, 어쩌면 AI가 인풋 토큰으로 받아들이거나 할 때는 오히려 비효율일 수도 있거든요.
31:20 · 근데 이 단점을 넘어서는 엄청난 장점이 있다면, 이거는 인간과의 협업을 위하는 겁니다.
31:26 · 이게 결국에 우리가 만들어 놓은… 지금 제가 생각했을 때 바이브 코딩으로 엔터프라이즈에 딸깍한 다음에 그거 유지보수까지 넘어간 사례는
31:34 · 없거든요.
31:34 · 왜냐면 시기적으로 없어요.
31:36 · 왜냐면 6개월 이후에 유지보수로 넘어가니까, 작년 9월부터였으니까.
31:40 · 시기적으로 맞지 않고. 그러면 유지보수를 일반 SI 팀에서 받아서 해야 될 수도 있거든요.
31:48 · 그러면 휴먼 리더블한 코드가 중요하고, 그들의 가이드라인과 그들의 특성에 맞춘 게 중요합니다.
31:55 · 우리 옛날에 코딩할 때 보면 임포트 같은 거 쓸 때 쭉 긁어 가지고 컨트롤, 커맨드, 옵션 L 눌러서 중복 정리하고 정리를 하고 이런 플로우들 많이 했는데, 저는 지금 이걸 우리가 왜 하고 앉아 있어야 되나 생각을 많이 하거든요.
32:03 · 근데 그게 결국에 받는 사람이 바이브 코딩을 안 할 거면, 그리고 거기서 인터넷도 안 되는 데서 코딩을 해야 되는 어떤 환경이면, 우리는 거기에 맞게 완벽한 어떤 예쁜 패키징된 그런 소스를 줘야 된다 생각하고, 그것 때문에 이게 되게 중요한 거 같아요.
32:12 · 지금 저희가 같이 일하고 있는 어떤 엔터프라이즈에도 그거를 해야 되는 상황이 생길 거 같거든요.
32:21 · 그렇기 때문에 우리가 자유롭게 블루프린트를 많이 세팅을 해 놓더라도, 결국 아웃풋을 이런 구성에 맞게, 진짜 엔지니어 레벨에서의 코드 레벨에서의 아웃풋을 내 줘야 되는, 그게 진짜 중요한 거 같습니다.
32:27 · >> 맞는 말씀인 거 같고, 저도 확실히 느끼는 게 결국은 유지보수의 문제로 빠지거든요.
32:42 · 이런 것들이.
32:51 · 근데 지금 어쨌든 FD는 회사에 영원히 일해 주는 게 아니잖아요.
32:59 · 근데 이런 하네스가 먼저 설정적으로 잘 되어 있고, 그게 결론적으로 유지보수 관점으로 넘어갔을 때 누가 들어오더라도, 어떤 개발자가 새로 들어왔었을 때 ‘아, 규칙 관련된 문서가 있구나. 그리고 이 규칙은 어떤 식으로 정리가 되어 있어’라고 하는 것이 이제 약간 유지보수를 하게 되는 시점 자체에서 학습이 좀 더 되고 이어지게끔 하는 형태에 있어서는
33:18 · 이 방식이 참 좋다.
33:19 · 저도 그렇게 느껴지는 것 같습니다.
33:21 · 네.
33:22 · 너무 재밌는 거 같고요.
33:24 · 그러면 이 다음 단계는 결국 평가 단계로 들어가는 거 같은데요.
33:26 · >> 네.
33:26 · >> 유효한가에 대한 그런 내용인데, 지금 보면 저렇게 그래프가 되어 있는데 저건 무슨 뜻인가요?
33:31 · >> 아, 결국 제가 계속 말씀드리고자 했던 키워드 중 하나는 ‘견고성’이잖아요.
33:35 · >> 네.
33:35 · >> 여태까지 이 거대한 요구 사항을 넣었을 때 한 번에 어떤 마크다운 문서만 가지고도 한 번에 제 요구 사항 맞출 수도 있고, 아무리 제가 요구 사항을 마크다운에 잘 정리해 놓더라도 빼먹을 수가 있거든요.
33:49 · >> 네.
33:52 · 그래서 린터를 사용하게 되는 거고요.
33:54 · 제가 계속 어떤 프롬프트 엔지니어링만 가지고 이거를 항상 강제할 수가 없다 보니까, 그니까
33:58 · 제가 클로드한테 커밋해 줘라고 했을 때 커밋 시도할 때 린터가 무조건 실행되도록 합니다.
34:10 · 그러면 제가 ‘코드 구조를 잘 만족시켰어?’라고 묻지 않아도, 커밋을 시도할 때 린트 테스트를 하면서 틀린 걸 알게 되면, 아, 익스포트에 내가 붙여서 안 되는 서픽스를 뭔가 했구나를 알게 되면, 결국 제가 스몰 A부터 스몰 F까지 넣었던 요구 사항이랑 라지 A부터 라지 C까지 넣었던 요구 사항이랑 결국 동치인 아웃풋이 나오게 되는 거죠.
34:21 · 그래서 견고성이 된다라고 말씀드리고 싶은 거고, 그래서 여기서 보여 드리는 거는, 서로 AI 모델마다 어떤 거는 한 번에 오래 걸리더라도 한 번에 아웃풋이 맞게 나오는 게 있을 수도 있고, 어떤 거는 작게 여러 번 시도해서 나올 수도 있는데, 결국엔 이 저희가 꾸리고 있는 하네스를 통해서는 어떤 정교화되는 형태로 간다.
34:35 · 노멀 폼으로 간다.
34:40 · 이거를 시각화하고 싶었습니다.
34:45 · 해서 결국 총 네 개의 소프트웨어를 세 개 모델에 시켰으니까 12개가 나오게 됐었거든요.
34:51 · >> 네.
34:58 · >> 그래서 이거는 이제 코덱스가 만들어 준 거.
35:00 · 이거는 제미나이가 만들어 준 거.
35:03 · 저희가 다 디자인 시스템이나 이런 거는 좀 세팅이 돼 있어 가지고.
35:07 · >> 아, 네네.
35:07 · >> 결국 어떤 모델을 시켜도 똑같은 아웃풋이 나오게 됩니다.
35:11 · >> 오, 그렇구나.
35:14 · >> 저희는 주로 프로토타입을 처음에 가져가니까 디자인의 색깔을 거의 안 입히고
35:17 · >> 네.
35:17 · 톤 다운해 가져가거든요.
35:22 · 그래서 보시는 것처럼 어떤 AI 모델을 맡겨도 도메인이 고정돼 있었고, 설계도 동일하면 똑같은 아웃풋이 됩니다.
35:25 · 네.
35:28 · 오늘 보여 드리고자 했던 건 딱 이거였습니다.
35:33 · >> 너무 재밌습니다.
35:37 · 네.
35:40 · 뭐 굉장히 상세하고 좋은 내용을 좀 공유해 주셔 가지고 저도 큰 영감이 됐고요.
35:44 · 이거를 결론적으로는 저희가 이걸 보시는 분들이 이렇게 처음부터 접근을 하셔야 된다라고 하는 점이 좀 있으실 것 같아요.
35:48 · 그러니까 처음으로 우리가 ‘아, 나도 이거 얘기를 듣다 보니까 나도 견고성을 지키고 싶고 하네스 엔지니어링을 좀 더 잘해 보고 싶어.’
35:53 · 그럼 어디서부터 접근하면 좋을까에 대한 그런 약간 초심자의 관점에서는 어떻게 하면 좋을지에 대해서 좀 조언을 주실 수 있을까요?
35:58 · >> 음.
36:06 · 그러니까 저희가 생각하는 거는 하네스에서 가드레일을 꽉 잡아 놓는 것도 중요하지만, 진짜 잘 만들어졌는지에 대해서 체크하는 것도 되게 중요하다고 생각을 하고요.
36:10 · >> 그래서 지금 저희가 또 하나 집중하고 있는 거는 이밸루에이션 쪽입니다.
36:16 · 근데 이밸루에이션은 하나 자료를 공유하려고 들고 왔는데, 진짜 이게 잘 돌아가고 있는지를 어떻게 아냐라고 했을 때, 뭐 당연히 저희가 좋아하는 랭체인 덕분에 여러 가지 이밸루에이션을 많이 저희는 할 수 있죠.
36:21 · 할 수 있는데, 엔터프라이즈 레벨에서는 범용적인 이밸루에이션이 아니라 조직에 맞는 이밸루에이션이 좀 필요하거든요.
36:28 · 예를 들어서 지금 여기 보면 이 네 가지 표는 기본적인 겁니다.
36:35 · 보통 AI 이밸루에이션에서 많이 쓰이는 거.
36:41 · 이게 문맥에 맞는 답변을 하고 있나?
36:50 · 문맥에 어긋난 건 아닌가?
36:51 · 제대로 된 결과를 들고 있나?
36:54 · 제대로 된 소스 데이터를 들고 있나?
36:55 · 이상한 게 빠지진 않았나?
36:58 · 이런 네 개에 대한, 어떻게 보면 레그 시스템에 대한 이밸루에이션 메소드들이 있습니다.
37:05 · 근데 그런 것들을 기반으로 우리 조직에는 어떤 것들이 적합할까를 보장을 해 줘야 돼요.
37:13 · 옛날에 우리 보면 서비스 하나 만들면 응답 속도나 이런 것들 가지고 품질 표준을 딱 잡지 않습니까?
37:21 · 그런 것처럼 AI도 만들어 놓고 나면 진짜 괜찮게 와 하는 거 말고, 이게 내일도, 모레도, 1년 후에도 맨날 이게 잘 작동하는지.
37:30 · 저는 그래서 이거를 옛날에 데이터독처럼, 에이전트독 같다, 이렇게 많이 부르거든요.
37:35 · 그래서 이거를 매일매일 체크가 되면서 이 품질이 유지되고 있는지, 그리고 이 에이전트별로 답변 관련성이나 이런 것들이 진짜 괜찮은지, 그리고 100번 물었을 때 한 번 틀리는 게 좋은 건지 나쁜 건지.
37:40 · 우리 조직에선 100번 물었을 때 10번 틀리더라도 답을 아예 안 했으면 좋겠다.
37:46 · 아니면 어떤 조직은 20번 틀리더라도 틀린 답이라도 했으면 좋겠다.
37:51 · 이게 조직별로 스타일이 다르거든요.
37:56 · 그래서 이밸류에이션 메소드는 조직 문화랑도 맞닿아 있습니다.
38:03 · 그래서 이런 엔터프라이즈 AI 에이전트에서 평가 프레임은 랭체인이나 이런 데서 하는 범용적인 것에서 우리 조직에 맞게끔 조금 더 변경된 이런 퍼포먼스가 필요하고, 요런 것들을 이제 지속적으로 모니터링해 나가는 게 키다.
38:14 · 이렇게 말씀드리면, 그럼 이제 앞단에서도 잡히고 코드 레벨로 잡힌 다음에 AI의 답변 퀄리티까지도 딱 잡히면, 이게 통으로 가면 이제 이게 다
38:27 · 잡히는 거죠.
38:30 · 어떻게 보면.
38:32 · 그래서 이게 FD들이 안에서 놀아도 상관이 없는 겁니다.
38:35 · 앞이 잡힐 거고 뒤가 잡힐 거니까.
38:38 · 그래서 이제 그런 식으로 하는 것이 지금 또 엔터프라이즈 AI 에이전트 빌드의 키이다.
38:40 · 공유드리고 싶었어요.
38:46 · >> 아, 평가 같은 경우에는 그러면 프로젝트마다 품질 관리 대시보드를 별도로 제작을 해서 납품을 하시는지, 아니면 그냥 내부에 통합된 어떤 솔루션 같은 걸 하나 만드셔 가지고 거기다가 하나, 둘, 셋 이렇게 붙여서 하시는지 그런 포인트가 좀 궁금하거든요.
39:05 · 어떻게 보면 통합된 방법론은 있을 수 있는데요.
39:06 · 당연히 고객사마다 다르게 들어가고요.
39:08 · 왜냐면 요즘 딸깍으로 다 만들 수 있으니까.
39:11 · 대신에 고객사마다 어떤 이밸루에이션 메소드로지를 활용할지는 이제 고객사의 성향을 보고 저희가 판단을 해야 되는 상황입니다.
39:14 · 그거를 같이 논의하게 되는 것이고요.
39:18 · >> 이게 좋은 게 어쨌든 우리가 만든 사람 입장에서도 계속 이밸루에이션을 트래킹을 할 수 있다는 것이고, 그리고 상대방 클라이언트 입장에서도 ‘아, 이게 지금 계속 잘 작동되고 있구나’라고 하는 안심을 줄 수가 있는 것이고, 그죠?
39:23 · 네.
39:28 · 그렇게 진행이 됨에 있어서 좋은데, 프로젝트를 계속 이어 주게끔 해 주는 어떤 연결도 되기는 하는 거 같아요.
39:33 · 그러니까
39:38 · 지금 그냥 하나에 한 번에 들어가서 구축을 쫙 끝내고 빠져나오는 그런 것뿐만 아니라, 뭔가 유지보수도 되고, 끈을 유지하는 그런 느낌도 있는 거 같다는 생각이 들었었어요.
39:45 · 그럴 수도 있는데, 저희가 생각하는 사실 이상적인 거는 저희가 구축해 놓고 가면 이제 안에 내부에 있으신 분이 그걸 유지보수할 수 있게끔 우리가 역량을 세팅해 드리고 나와야 된다이긴 하거든요.
39:57 · 그분을 위한 다양한 무기를 세팅해 드리는 거긴 합니다.
40:11 · 그래서 유지보수 관점에서 그거를 이제 어떤 씨를 뿌려 놓고 우리가 이제 계속해서 뭔가 컨택을 유지할 만한 어떤 요소가 될 수도 있는데, 그것보다는 AI는 어쩔 수 없이 불확정성이 너무 큰 엔진이기 때문에, 그거를 또 잡아낼 수 있는 여러 가지 무기를 이제 유지보수자에게 드리는 거죠.
40:17 · 그게 이제 기회가 좋아 가지고 저희한테 유지보수의 사업이 맡겨진다면 너무 땡큐고요.
40:23 · 돈 버는 거니까.
40:30 · 근데 그게 아니라, 저희는 지속 가능하려면 내부 인원이 그거를 가능하게 만들어야 된다 생각하고, 그럴 때 이제 이런 하네스 뭐든 다 세팅이 되는 거고, 그중에 하나 굉장히 중요한 게 이밸루에이션 프레임이고 되겠습니다.
40:36 · >> 예.
40:45 · 충분히 이해했어요.
40:53 · 너무 좋은 말씀입니다.
40:54 · 네.
40:56 · 마지막으로 좀 하고 싶으신 말씀 있으실까요?
40:58 · 혹시 뭐 이제 마무리를 좀 해 보려고 하는데, 우리 지우 님께서는 오늘 인터뷰 어떠셨는지 소감 한 말씀만 해 주시면 감사할 것 같아요.
41:00 · >> 아, 네.
41:02 · 아, 저 하나 말씀드리고 싶은 토픽도 하나 있습니다.
41:05 · >> 네.
41:06 · 제가 왜 이렇게 어떤 필연적인 방향을 고민하게 됐는지에 대한 일화가 하나 있는데요.
41:09 · >> 저는 하드웨어 프로젝트를 성공적으로 끝내지 못한 경험이 있어요.
41:12 · 하드웨어 프로젝트를 하면서 어떤 역할을 했었냐면, 회로도 설계했었어야 됐고 펌웨어도 구현을 했었어야 됐어요.
41:16 · 근데 펌웨어를 구현하는 건 C 코드였는데요.
41:20 · 그러니까 당시에 제가 C 코드로 많이 구현했었어서 잘 할 수 있을 거라 생각했는데, 막상 구현하면서 뭔가 잘 안 되는 거예요.
41:23 · 그래서 안 된다고 어떤 멘토분이나 혹은 전문가분 찾아가면 포맷을 해 오라는 걸 말씀해 주시는 거예요.
41:27 · ‘포맷을 하면 돼요.’
41:33 · 그래서 저는 이 상황이 당시에 되게 어려웠었어요.
41:38 · 소프트웨어 전공자로서는.
41:44 · 근데 아, 보니까 다시 제로로 돌아갔을 때 결과물로 가는 단계가 견고해야 되는구나를 뭔가 겪은… 문제의 솔루션은 아니지만, 뭔가 내가 어떤 짓을 했는지를 모르면 결국 포맷을 해서 처음부터 다시 윈도우부터 설치하고 맥OS 초기화한 다음에 컴파일러 다시 설치하고, 그렇게 해야 기본 제공해 주는 예제 코드를 실행하는 데도 그렇게 해야 되더라고요.
41:53 · >> 음.
42:10 · >> 그래서 아, 그러면서 그때 경험이 지금의 영향을 주고 있는 거 같아요.
42:28 · 본인의 어떤 경험에서 나오는 기억은 사실 강렬하죠.
42:28 · 문제를 내가 직접 경험했으니까 풀고 싶다라고 하는 게, 저도 예전에 한번 겪었던 적은 있었던 비슷한 문제가 있었던 거 같아요.
42:35 · 충분히 공감이 되는 말씀이었던 것 같습니다.
42:39 · 네.
42:44 · 하네스 엔지니어링 오늘 정말 많이 배우셨을 수 있을 것 같고, 또 지운 FDE님 이제 링크드인 주소도 남겨 놓을 테니까
42:48 · 많은 분들 찾으셨으면 좋겠고, 네.
42:53 · 이렇게 해서 오늘 이렇게 스페이스와이 황현태 대표님, 그리고 김지훈 FDE도 모시고 우리 하네스 엔지니어링에 대해서 좀 깊이 있게 얘기를 나눠봤는데, 저는 개인적으로 너무 재밌었습니다.
42:59 · 성공적인 녹화였고, 여러분들도 그게 꼭 전달되셨으리라 전 생각을 하고요.
43:12 · 저희는 또 다음번에 또 나와 주셔 가지고 또 많은 토픽도 나눴으면 좋겠습니다. 네.
43:17 · 오늘 고생 많으셨습니다.
43:19 · 고맙습니다.
43:20 · >> 감사합니다.
43:23 · >> 감사합니다.
43:25 · >> 감사합니다.