상위 1% AI 네이티브들은 프롬프트 안쓰고 '하네스 깎기'에 수백시간 투자합니다. (DIO FDE 김지운님) transcript

총네 개의 소프트웨어를 세 개 모델에 시켰으니까 12개가 나오게 됐었거든요. 이거는 이제 코덱스가 만들어 준 거, 재미나이가 만들어 준 거. 저희가 다 디자인 시스템나 이런 거는 좀 회기라 돼 있어 가지고 어떤 모델을 시켜도 똑같은 아웃풋이 나오게 됩니다. 클로드를 쓰든 코덱스를 쓰든 제미나를 쓰든이 하네스 엔지니어링이라는 기법을 잘 활용하면 다른 AI 모델을 써도 같은 아웃풋으로 나올 수 있게끔을 강제할 수 있다. >> 네. 안녕하세요 구독자 여러분. 네. 오늘 하우이 AI 팟캐스트에는 어 이렇게 이제 디오 대표님이신 황현태 대표님과 여기서 워드 디플로이드 엔지니어로 일하고 계신 김지훈 님을 모시고 오늘은 어떻게 하면은 실제 현장에서 강건하게 소프트웨어를 잘 빌딩하고 일관성 있는 결과물을 전달할지에 대한 내용들을 한번 이야기 나눠 보도록 해 보겠습니다. 엔터프라이즈에 요즘 굉장히 많은 사람들이 관심이 많이 있으신 것 같아요. 그러니까 AX라고 해 가지고 그 트렌드가 확 퍼지고 있고 저 개인적으로는이 변화가 좀 국가적인 변화다라고 생각을 하고 있는데 그에 있어서 가장 앞서 계신이 두 분 또 모시고 오늘도 재밌게 한번 이야기를 나눠 보도록 해 보겠습니다. 먼저 우리 기호 스페이스 Y와의 대표님이신 황현태 대표님 저희 많이 오셨는데 한번 소개 한번 더 해 주세요. 처음 보시는 분들 많을 테니까.네 >> 안녕하세요. 엔터프라이즈 AX 기업 스페이스 YY의 대표 황현태입니다. 반갑습니다. >> 반갑습니다. 네. 유튜브 이번에 여었잖아요. 음. 네. 까칠한 AI라고 엔터프라이즈 AX 경험담을 들려드리는 유튜브를 하고 있습니다. 엔터프라이즈 AX 경험이 지금 너무 다들 적기 때문에이 경험치를 다들 나누어야 된다고 생각을 해요. 그래서 그런 거를 좀 다 같이 계속 공유할 수 있으면 좋겠습니다. >> 네. 너무 좋습니다. 우리 김지은 FD 님. 네. >> 네. 안녕하세요. 디오에서 워드 디플로이드 엔지니어로 일을 하고 있는 김지훈입니다. 잘 부탁드립니다. 네. 어, 포워드 디플로이드 엔지니어로 어떤 일을 하고 계신가요? >> 아, 결국 직역을 하면 파견형 엔지니어인데요. 그래서 고객사를 직접 만나뵙고 어, 헤이를 자주 통하면서 그 헤에서 나오는 피드백들을 정의해 드리고 같이 제로투원을 하는 그 역할로 봐주시면 >> 아, 네. 알겠습니다. 네. 좋습니다. 네. 요즘 사실 AI 현장에서 또 많이 나오는 단어가 몇등성이라는 얘기가 있어요. 그 몇등성이 뭐냐면 일관성과 같이 우리가 생각할 수가 있는데 이런 화재에 대해서 자세한 사례를 통해서 한번 이야기를 나눠 볼 수 있을 것 같습니다. 한번 초반부에 어 그 내용에 대해서 간략하게만 소개를 먼저 해 주시고 바로 소개로 넘어가도 좋을 것 같아요. 네. 말씀해 주실 수 있을까요? >> 네 >> 오늘 결국 강건성 있는 어 결과물을 얻기 위해서 가져온 토픽은 한네스 엔지니어링이라는 >> 아 핫타하죠. 예. 핫타죠. 네. 네. 그 화면에 대해서 좀 계속 설명해 주시면 너무 좋을 것 같아요. >> 네. 그래서 어 오늘 준비해 온 거는이 하네스 엔지니어링을 시원하고자 더미 스펙을 하나 가져왔는데요. 그래서 저희가 흔히 아는 배달 플랫폼을 예시로 가져왔습니다. 그래서이 배들 플랫폼 같은 경우에는 크게네 가지 어떤 소프트웨어가 있다라고 전 생각을 하고 있는데 일반적인 저희가 고객할 고객이 주문할 때 쓰는 고객료 그리고 기사분들께서 음식을 픽업하고 고객한테 전달해 주시는 그런 속 도구 그리고 음식점에서는 주문을 수락하고 그리고 조리로 완료된 걸 알려 주는 속태예요. 그리고이 전체를 관리하는 어떤 배달 플랫폼의 어드민 이렇게네 개를 생각을 했고요. 그래서이네 개를 가지고 제가 지금 시도하고 있는 한네스 엔지니어링으로 했을 때 어떻게 아웃풋이 나오는지 보여 드리려고 오늘 가져왔습니다. 너무 멋집니다. 네. 저렇게 배달 플랫폼 하나만 설계하는데도 진짜 저게 다 하나의 조직이거든요. 진짜 하나 큰 조직들인데 그것들을 한꺼번만 설계해 놓으셨는데 왜 이렇게네 개 정도를 분할해서 저희 얘기 보여 주시는지 좀 궁금합니다. 네. 아, 근데이 첫 단계로는 이런 요구상 있는 고객사를 만났다라고 가정을 하고 더미 회의를 진행했다라고 가정을 했습니다. 그러면 질문 주신 것처럼 이게 꼭 내개여야 하는가는 고객은 모르실 수도 있어요. 처음에는 그냥 고객이 주문하는 앱만 있으면 되지라고 생각하실 수 있다가도 점점 대화를 해 보면 아, 기사님 앱도 따로 필요한 것도 알게 되시고 그러다 보면 또 음식점을 위한 앱도 필요하겠다. 그리고 아 이걸 다 관리하는 우리 산내 어드민도 필요하겠다. 이런 결론이 되게 되는데요. 그래서 이렇게네 개가 된 건 아 고객사 입장에서 난 이런 거 막연이 필요해라고 했을 때 FD로서 아이 얘기를 들어봤을 때 구성 요소를 뭐 미시하게 쪼개 봤을 때 여기에 가상의 폐로선은네 개의 분류가 있고 그럼네 개의 분류마다 적합한 소프트웨어가 필요하겠다 이런 판단을 했다라고 가정하고네 개로 가져왔습니다. >> 아네 문제 정의를 잘하셨네요.네 네. 그러면은 그다음에 어 해야 될 일은 뭔가요? >> 아, 결국 총 여섯 개의 플로우로 오늘 보여 드리려고 왔고요. 그래서 방금 말씀드린 요구 사항을 넣었을 때 이걸 분석해서 플랜을 세우고 그 플랜에 맞게 어떤 아키텍처 강건한 아키텍처를 짜게 되고요. 기능 명세나 어떤 도메인 모델들이 있어야 하는지 >> 네. 그리고 어떤 아키텍처로 갈 것인지 이거를 AI가 알아들을 수 있게 코드 레벨로 디자인 설계를 하고 그리고 저희는 하네스 엔지니어링 구성 요소 중 하나는 또 저는 잘 쓰는게 린터가 있거든요. 터 기반으로 모든 코드 아웃풋에 여러 선택지가 있다면 하나로 강제할 수 있게끔 터를 사용하는데 코드를 만들고 터로서 어떤 결과물을 검토하고 결국에 제가 오늘 말씀드리고 싶은 거는 클로드를 쓰든 코덱스를 쓰든 제미나를 쓰든이 하네스 엔지니어링이라는 기법을 잘 활용하면 다른 AI 모델을 써도 같은 아웃풋으로 나올 수 있게끔 방향을 강제할 수 있다. 혹은 방향을 조절할 수 있다. 이런 걸 보여 드리려 왔습니다. >> 아 너무 멋있습니다. >> 네. 그래서 지금 처음 단계부터 어떻게 진행이 되고 있는지 좀 더 자세하게 설명을 주실 수 있을까요? >> 네. 그래서 여기에서도 제가 더미로 적어 놨지만네 개 막연한 요구 사항을 각각의 이걸 검증하기 위해서 각각의 클로드랑 제미나이랑 코덱스에 시킨다라고 가정을 했고요. 그래서 첫 단계는 아 >> 고객용 어떤 주문 앱이 필요해요라는 거. 그리고 어 기사님께 어느 위치에 있고 어디로 가야 되는지 알 수 있는 앱을 만들어 주세요라는이네 한네 문장의 요구상이 있다라고 가정하고 첫 단계를 시작한 겁니다. >> 네. 그러면 그 단계에서 우리가 봐야 될 핵심 뭐 사항이 있나요? 아, 요건 없습니다. 인풋크 자체는 저희는 고객사나 혹은 고객분들에게 비정형적으로 편하게 주실 수 있도록 하고 있거든요. >> 그러니까 그냥 전체적으로 아, 이런 구조가 있을 것 같다라고 하는 가정을 먼저 문서다. 뭐 이렇게 생각하시면 좀 편하실 수도 있겠네요. 네. 그럼 그다음 단계는 플랜에 대해서는 우리가 중점적으로 봐야 될 부분은 뭔가요? >> 네. 결국 플랜에서는 각 미팅마다 FD를 계속 가정을 말씀드리면은 주에 두 세 번을 뱉는데요. 그럼 만약에 두 번을 뱉는다라고 가정했을 때 회의를 오전과 오후 그러니까 출근 직후와 퇴근 직전 하게 됩니다. 그럼 총네 번의 미팅이 고정적으로 됐는데요. >> 그럼 각 헤의마다 직전에 완성된 거랑 오늘 해야 될 거 혹은 온을 완수한 거 이거를 리뷰하게 됩니다. 그래서 플랜에서 하는 거는 그 한시간 회의 동안 막연하게 이야기한 거를 구조적으로 정리하는게 하나의 구성 요소가 있습니다. 그래서 플랜은 총 세 가지 구성 요소가 있는데 첫 번째 구성 요소는 서로 회의를 되게 발산적으로 하고 그것을 수렴해서 정리하는 미팅 로그를 적는 그게 플랜 중 하나입니다. >> 네. 미팅을 하고 그걸 모두 전사화시킨다가 있는 거죠. 네. 그래서 결 나왔던 요약을 하고 어떤게 부족했고 어떤게 잘됐고 어떤 건 필요하지 않고 어떤 거는 직접 구축하지 않고 어떤 기존을 쐈으나 어떤 솔루션을 사서 쓸 건지 어떤 거 우리가 직접 구해야 되는지 이런 거를 분석하게 됩니다. >> 그리고 약간 미팅 원칙이 두 개가 있다면 하나는 제한하지 않는다. >> 예. 그냥 하고 싶은 말 다 해 다 하시라. >> 편하게. >> 예. 저저만 해도 미팅을 하다 보면은 제한하기도 하거든요. 그건 습관적인 저의 태도인데 그래서 두 명 정도가 같이 가면은 서로가 그거를 막습니다. >> 고객을 막지 마라라는 거를 느낌적인 느낌으로 눈빛으로 전달하거든요. 그럼 아차 하면서 그 다 말씀하시라고 이런 식으로 좀 제한하는게 있어요. >> 그렇죠. 저도 최근에 이제 AX 하면서 아 고객의 요건을 상세하게 파악하면 할수록 너무 좋다. 그 모든게 다 데이터가 되니까라는 생각이 들었는데 어 재밌습니다. 근데 지금 제가 궁금한 거는 저 플랜 단계에서 재미나이 클로드 코덱스가 저렇게 나뉘져 있는데 왜 그런 거예요? 아, 저는 지금 클로드만 쓰고 있긴 한데요. >> 다른 AI 모델을 쓰더라도이 하네스 엔지니어링 기법을 사용하면 뭘 해도 필연적인 결과이 나올 거다라는 걸로 가져오게 된 겁니다. >> 아, 그러니깐 그 검이 문서조차 어쩌면 일관성이 있게 나올 수가 있다라고 하는 것이죠. 재밌는 관점이네요. 아, >> 계속 시기에 따라서 어떤 랭킹이 바뀌잖아요. 언제는 오퍼스 4.0이 제일 좋았다가 언제는 이제 >> GPT 5.3이 더 좋았다가 >> 네. 근데 저희는 AI 모델을 만든 사람은 아니고 AI 모델을 가져다 쓰는 사람이니까 어떻게 하면 정말 잘 가져다 쓸까? 그래서 다른 모델이 바뀌더라도이 기법은 유효하다. 이게 중요하거든요. 저한테는 뭔 저희 팀에 그래서 세 개를 가졌습니다. 그 플랜을 쓰는 그러면 저 문서를 쓰는 별도의 프롬프팅을 좀 빡세게 깎아 가지고 내놓은 결과가 저거다라고 하는 거라고 보면 되까요? >> 네. 아, 그래서 세 개의 그 AI 모델들을 보여 주셨는데 저 내용들이 어느 정도의 일관성이 존재한다라고 하는 걸 말씀해 주시는 거군요. >> 아, 재밌습니다. 그럼 그다음 단계는 어떻게 되나요? 그다음부터 이제 기획의 요소로 가게 됩니다. 그래서 저희는 가장 하이레벨한 기획 요소는 컨텍스트 프블럼 솔루션이에요. 그래서 이건 현태님이 초후반에 제안을 해 주셨는데이 얘기를 듣고 아 어떤 맥락에서 어떤 문제를 겪고 있기 때문에 우린 어떤 솔루션을 제시해야 될지 우리 어떤 솔루션을 같이 만들어야 될지를 정리하게 됩니다. 솔루션을 제시한다는 것은 문서랑 어떤 부분이 다른 건가요? 정확히는 미팅 로그에서도 솔루션을 우리가 생각해 볼 수 있긴 한데 저거는 지금 보니까는 CPS라고 표현을 하는 거 같아요. 저게 뭔지에 대해서 좀 더 자세히 설명해 주시면 좋을 것 같아요. >> 아, 일단은 CPS도 문서 유형 중에 하나고요. 어떻게 보면 생각을 정리하는 프레임워크일 수 있습니다. 그 저희가 처음에 SKT 프로젝트로 만나게 됐는데 그때 그 어디서 본게 있었어요. 그 팔란티어는 처음에이 뭔가 자기들끼리 미팅을 할 때 내부에서 FDA 미팅을 할 때 뭐 머드 미팅, 머드 세션 뭐 이런 걸 통해서 다양한게 발상을 하고 발산도 하고 수렴을 한다라고 해서 우리는 어떤 프레임워크를 처음에 도입해 볼까 했을 때 제가 프로덕 매니저일 때는 저 컨텍스트 프블 솔루션의 프레임워크로 생각을 많이 했었거든요. 그래서 이걸로 우리가 한번 정리해 보자라는 얘기를 하게 되었었고요. 이게 그냥 생각 정리를 할 때 고객의 문제가 뭐냐 그리고 그 문제에 대한 솔루션은 뭐냐 근데이 문제와 솔루션을 얘기하기 전에 앞단에 우리가 미리 다 같이 싱크를 맞추고 있는 깔고 있는 컨텍스트 뭐냐 해서 CPS로 문서들을 정리를 하게 됐습니다. 왜냐면 매번 우리는 플라블륨을 발견하고 솔루션을 고환하게 되니까 그때마다 컨텍스트는 계속 쌓여 가는 것이고 그래서 CPS 운서를 많이 썼거든요. >> 너무 좋네요. 컨텍스트가 있는 거 자체가 다른 사람이 보더라도 그 맥락을 한 번에 이해하고 그것부터 시작을 하기 때문에 백그라운드 기반의 솔루션이 저렇게 나왔구나라는 형태로 서로 공유가 되는 것이죠. 그런데 지금 보여주시는 화면도 그러면 각자의 AI 엔진들이 저렇게 유사하게 결과물도 낼 수가 있었다라고 하는 걸 보여 주시는 거군요. >> 맞습니다. >> 그리고 저희는 좀 컨설팅의 성격도 매우 강하거든요. 그래서 고객사 원하는 솔루션을 고정한 채로 컨텍스트랑 프블럼을 정의해야 될 수도 있으이 그러면 저거를 궁금한게 이제 저 문서를 제작을 해서 내부용으로 쓰시나요? 아니면은 저희 클라이언트 공유용으로 어떻게 쓰시나요? >> 아, 클라트 공유용으로도 씁니다. >> 아. 음, 이걸 이제 마크다운 문서로 파일은 갖고 있다가 PDF로 잘 빌드하는 또 저희 어떤 레이텍 템플릿이 있거든요. 그걸로 빌드서 드립니다. >> 음. 궁금한게 문서를 먼저 전달을 어 해 주시는게 선행인지 요즘 사실 프루프 오브 컨셉 그니까 POC는 결과물 그러니깐 한마디로 약의 끝났고 바로 미팅투 프로덕트가 되는 시대잖아요. 그죠? 근데 그 미팅 끝나서 결과물을 바로 보여 주는 형태로 보통 하시는지 뭐 아니면 이런 식으로 문서를 전달하시는지 그 시점에 대해서 좀 더 구분해서 설명해 주실 수 있을까요? 이게 해 보니까요. 문서는 총 POC 기간 중 두 번 정도 공유 드리게 되는데 그니까 첫 번째는 어느 정도 1차 스펙이 확장됐을 때 드리게 되고 그리고 두 번째는 프로젝트 다 끝났을 때 오히려 역기획해서 드리게 됩니다. 그래서 결국 말씀 주신 것처럼 매번 소프트웨어 결과물만 가져와요. 대부분은. 그렇지만 어 고객 입장에서도이 문서화된 살투물도 필요하시다 보니까 프로젝트 한 초반에는 아 우리가 이야기한 기능 명세는 이렇고 어떤 분석 과정을 통해서 얻게 됐다 이런 거를 문서를 드리게 됩니다. 그래서 어 이거이 문서는 초항이고 우리 얼마든지 발산할 수 있고 산출물이 확정됐을 때 또다시 역께 계속 드리겠다 이런 식으로 하게 됩니다. 아 기획서가 그럼 계속 업데이트가 되지 않나요? 계속 결국 굴론적으로 네. 그러니까 결국은 미팅할 때마다 저는 새로운 요건들이 다시 나오고 사람들 사람이 이렇거든요. 해보니까 결과 딱 갖고 왔는데 저희 생각에는 이게 좀 더 이렇게 됐으면 좋겠는데요가 되게 많아요. >> 음. 그래서 그러면은 그거를 또 항상 담을 수 있는 버전투쓰 4어의 운서를 우리가 계속해서 업데이트를 할 수가 있다. 네라고 판단하면 되는 것이고 그리고 그거가 업 최종적으로 업데이트가 된다고 했었을 때는 프로젝트가 완수가 됐을 때 같이 전달드릴 수가 있는 그런 산출물이다라고 보면 되겠네요. >> 맞습니다. 고객사 입장에서는 저의 깃터 초대들이기 때문에이 CPS 군수 필요하던 매번 업데이트가 됩니다. 그래서 매번 보실 수 있는데 저희가 형식적으로 전달드리는 거는 그럼 매번 업데이트 됐다고 드리면 좀 너무 버스하잖아요. 그래서 한 두 번 정도 >> 아 그렇게 해서 >> 어 전체적으로이 내용이 전체적 외법이 다 됐습니다라고 하는 것까지 한 출물로 전달을 한다. 네. >> 어 깔끔하고 좋네요.네 너무 좋습니다. 그러면 그다음 단계는 어떻게 되나요? 그 다음 단계 점점 정통의 기획 방식으로 넘어가게 되는데요. 그럼 PRD를 작성하고 그다음에는 결국 디자인 쪽으로 넘어가게 되는데 이때도 어떤 스펙인지 결국 플레인이랑 디자인은 굉장히 맞다 있긴 하지만요.

CPS 이후에는 저희가 흔히 아는 기획 문서 넘어가게 됩니다. >> 아, 그렇군요. PRD를 플라트께서 다 보시나요? 어, 엄밀히 리뷰하지는 않는 거 같아요. 그거를 논의하기도 전에 산출문을 보고 정말 다양한 레벨에서 그러니까 어,이 여기 있는 버튼 마음에 안 들어도 되고 아, 우리 소프트웨어가 하나 더 필요할 것 같아요. 아니면 이건 굳이 합쳐도 될 거 같아요. 같은 시스템적인 어떤 되게 하이레벨한 리뷰도 하게 되거든요. 그래서 문서는 정말 어 EPOC 기간 전체 내에 했던 이야기를 잘 구조적으로 정리한 어떤 산출문인 거고이 문서 자체를 잘 리뷰하진 않습니다. 그렇지만 그래도 프로젝트가 계속 진행이 되면서 업데이트는 수시로 이루어진다는 거잖아요. 그죠? 저 전체적인 문서가 예를 들면 뭐 열 개짜리야라고 한다고 하면 PRD 있고 아까 CPS 있고 뭐 디자인의 인플렉테이션 문서 이런 실행 문서가 있고 이런 것들이 그냥 계속 그 프로젝트 주기 내내 업데이트가 된다라고 판단하면 되나요? 맞습니다. 아, 그래서 메인 브렌치에 계속 그게 존재하고 그것들이 커지는 그런 느낌인 거군요. 아, 네. 그래서 이게 미팅 로그가 미팅 한 횟수만큼 생길 거잖아요. 그럼 모든 미팅 로그를 종합한 하나의 CPS가 결국 특정될 거고요. >> 네. >> 그리고 또 미팅 로그를 다 종합한 하고 하나의 CPS 결정된게 또로 결정될 거고요. >> 네. 기가 막히네요. 아, 그렇구나. 아, 이해했습니다. 네. 저렇게까지 쪼갠다. 네. 의외로 고객사분들께서 저희의이 설계를 궁금해하시는 경우도 꽤 많습니다. 그리고 필요한 경우도 있고 그래서 첫 번째 생각이 들었던 거는 이게 요즘 딸깍하면 잘 나온다는 거는 이제 고객사들도 잘 알고 계시니까 어떤 세계관에서 어떻게 설계됐을는 경우가 되게 많아요. 그거를 한번 알려 달라. 그래서 그거를 그 주님이 만든 그 PDF를 문서를 기반으로 한번 쭉 설명을 드리는 경우도 있어요. 왜냐면은 결국 그들이 좀 더 아이디어를 더 발상을 잘해 내려면 우리의 구현 세계관을 알아야 그다음에 아이디어도 더 잘 줄 수 있는 경우도 있어서 그게 하나 있었고 두 번째는 그래서 그 세계관을 이해하기 위해서 우리 저희한테 발표를 시키기도 하지만 그 문서를 가지고 충분히 공부를 하셔서 그다음 미팅에 딱 갔더니 아 이제는 세계관을 이해했다. 아키텍처도 이해했다. 그렇게 해서 조금 훨씬 커뮤니케이션 좋았거든요. 그래서 >> 예 문서가 주는 매력도 있습니다. 맞네요. 저 같은 경우에는 그 항상 구현을 하고 나서 이렇게 구현을 했습니다라고 하는 보고서를 저도 항상 전달을 하긴 해 드려요. 근데 이제 저는 플레이라이트 MCP로 넣어 가지고 화면 다 해서 이런 식으로 약간 매뉴얼화를 해서 하는 형태로 그냥 주드리거든요. 네. 그냥 스크린샷이랑 이거 같이 보시고 그냥 만화처럼 이해하셔라. 이런 식으로 저는 전달하는 형태를 하고 있는데 이런 문서를 지속적으로 공유해서 어 파 회의 전에 이제 파악도 해보고 계속이 해도를 서로 높여가는이 커뮤니케이션이 너무너무 좋은 거 같아요. 저는. 네. 그것도 너무 좋고 일관성 있는 결과물도 너무 좋은 거 같은데 실제로 이런 그 기획 문서들이라든가 이런 것들이 정말 일관성이게 나오게 하시려면 어떻게 한스를 좀 하셨는지에 대해서 조금 더 공유해 주실 수 있을까요? >> 아, 네. 우선 목차를 먼저 보여 드리면은 이게 설계 분석인데요. >> 원칙을 세우게 됩니다. >> 아, >> 각 프로젝트마다 원칙이 다를 순 있지만 뭐 예를 들면 대부분 뭐 에이전트 프로젝트를 하게 되면 휴머 인더비나 혹은 뭐 할루시니션이 없어야 된다거나 혹은 어딘 로그가 잘 남아야 된다거나 이런 것들이 있을 수 있는데 이런 대전제 원칙들을 세우게 되고요. 그리고 우리가 고객사분들과 같이 하면서 개념 정의도 내리게 됩니다. 그럼이 두 개만 돼도 각 개념의 하이어라키를 정하게 되면 구조를 짤 수 있게 되고 그 구조에 맞게 데이터를 어떻게 주고받을지 기술적으로 설계를 하면 결국 결과물들이 필적인 방향으로 가게 된다라고 저는 생각을 하고 있습니다. >> 음. 음. 음. 야, 유저 멘탈 모델도 넣어 놨다. 너무 대단하시네요. 저렇게 프린플을 세워 놓는데 있어서 가장 중점적으로 봤던 뭐 그런 음, 사례라든가 혹은 저렇게까지 하셨던 배경에 대해서 좀만 더 설명해 줄 수 있을까요? 아직은 어떻다라고 뭔가 말씀드리기 어려운 거 같아요. 근데 왜 어렵냐면 굉장히 트렌드도 많이 타고요. 이런 설계 기법은 또 엔지니어로만의 관점으로도 안 되고 >> 어떤 창업자로에서 로서만의 관정도 안 되고 그니까 정말 보고 듣는게 너무 많기도 하고 그거의 레퍼런스가 정말 레퍼런스도 있고 그냥 누군가의 카더라 이야기도 있고 이러다 보니까 어 어떤 걸 봐서 이렇게 됐는가에 대한 명쾌한 답변은 아직 드릴 수는 없을 것 같지만네 그렇습니다. 한마디로 이게 굳어진 어떤 구조적인 관점이라기보다는 지금까지 이제 내가 배웠던 어떤 지식 같은 것들을 녹여다 보니까 어쨌든 상위 레벨에서 이제 원칙들을 세우게 됐고 그 원칙들이 이제 상세하게 데피니션으로도 넘어가게 됐고 그리고 그다음에 그 원 그 데피니션 정의 다음에는 스트럭처 구조로 빠지게 되는 형태로 갔다. 결과 결론적으로는 어쨌든 우리는 되게 매시브한 부분에서 계속 미시하게 파고 들어가는 그런 과정들을 했었는데 AI 엔지니어링을 같이 하다 보니까 저런 내용들이 좀 쪼개졌던 거 같다라고 인식하면 될 거 같네요. >> 맞습니다. 이런 운서 적을 때 저도 미시한지 엄청나게 분석을 많이 하는데요. 근데 그걸 하다 보면 너무 시간이 오래 걸리기도 합니다. >> 그래서 양쪽의 관점을 다 갖고 있게 되거든요. 그래서 정말 엄밀하고 고결한 설계를 하는 것과 동시에 당장 내일 혹은 오늘 오후에 산출물도 뽑아내야 되다 보니까 그런 너무 안정적인 설계와 당장의 선출물을 어떤 트레이드오프를 하게 됩니다. 네. 그렇군요. 그렇게 했을 때 이게 지금 지우 님 본인 스스로만 공유하는게 아니라 디오 팀 내에서도 같이 공유가 돼야 되는 건 사실이잖아요. >> 지금 어떻게 하고 계세요? 지금 이제 되게 고전적인 방식인데 >> 다른 프로젝트에 들어갈 때 >> 어 예를 들면 이제 지우님의 경험을 같이 공유받는 방식을 쓰고요. 그때 그때 지우 님 요거할 때 어떻게 하셨어요? 왜 뭐 고객한테 공유할 때 어떻게 하세요? 하면서 옛날에는 개발자들 협업할 때 코드 레벨 단위 뭐 라이브러리 요런 걸로 모 코드 모듈로서 경험치를 공유를 했다면 지금은 요런 방법론 요런 사상 그리고 요런 하우트 요런 노하우를 공유를 하게 되더라고요. >> 그 개발자분들끼리 서로 이제 팀으로 일할 때 이제 컨벤션을 항상 공유를 많이 했었잖아요. 예전부터. 그죠? 네. 이제 코드 컨벤션이든 어쨌든 위키 컨벤션이든 이런 것들을 굉장히 공유를 많이 하고 그 원칙대로 우리는 이렇게 일을 하자라고 하는 형태로 일을 하는 것으로 저는 이해를 하고 있어요. 근데 지금은 저런 문서로서 작업을 할 수가 있는 것이고 그걸 퍼뜨리는 일을 지금 지우 님께서 내부적으로 하고 있다라고 판단을 하면 되겠네요. >> 네. 근데 가짜 마디 문서 스타일이 있고요. 이걸 공유하는 거는 그 만든 사람이 결정하는 거 같아요. 그러니까 저도 고객사 분들이 이야기를 듣고이 원칙이 결국 최종 결과물에 굉장히 영향을 크게 준다는 걸 아니까 >> 그럼 저는 회의를 열어서 리뷰를 드립니다. 제가 각자의 어떤 강점이 있고 관점이 있다 보니까 이런 식으로 설계를 했을 때 어떻게 보이는지 어떻게 들리는지 타당한지 이런 거를 여쭤보고요. 저희는 그래서 워라수모큰 다 파견을 가는게 아니라 팀 내에 모여서 이런 걸 리뷰하는 고정 요일들도 있거든요. 네. 그때 오픈하고 저는 이런 식으로 설계하지만 또 다른 분 다른게 설계하게 되는데 서로 영향을 주고 받으면서 집단 지성을 만들어 가고 있습니다. >> 음. 그렇게 이제 기존 멤버들과 협업을 그런 식으로 하고 있는데 그러면은 이게 공유가 되는데 그 어디에 공유가 되나요? 보통 DO에서는 어쨌든 그러면 그런 형태로 조직 내에서는 어떻게 이런이 컨벤션을 좀 더 공유하시는지를 좀 듣고 싶었어요. 말 그대로 그냥 이제 주관 회의를 해서 나누는 수준이 아니라 우리가 다음 달 다음 단계의 레벨은 이게 엔지니어들 간의 합의된 어떤 메인 브렌치 같은게 있지 않을까라는 그런 생각은 좀 있었었거든요. 우선 현대님 이야기도 들어봐야겠지만 일단 제가 경험하고 있는 바로는 저희는 어떤 업무 어떤 방식 자체를 통일하진 않아요. 제 생각에는 저의 멘탈 모델을 일치시키는 거에 더 집중하는 거 >> 아 그래요? 어, >> 근데 모든 산출물은 저희는 다 오픈이 되어 있어요. 저희 깃업 팀 깃업에 다 오픈이 되어 있고 그리고 모든 어떤 로그들은 노션에 다 있고 그리고 슬랙이 있고 저희 그렇게 세 개밖에 안 쓰는데요. 거기에서 서로가 서로의 프로젝트 이어받을 수도 있고 뭐 넘겨 받을 수도 있거든요. 그때는 그걸 살펴보지만이 사람은 어떤 코딩 컨벤션으로 하지까지는 회기를 하진 않습니다. >> 음. >> 왜 멘탈 모델만 공유를 하게 되나요? 이해 보니까 좀 느꼈던 건데 프로젝트마다 지향하는 꼴이 아 KPI가 프로젝트마다 다르잖아요. 그러다 보니까 뭘 제1 원칙으로 두냐라고 했을 때 우리는 고객이 뭘 기대하냐 그거를 훨씬 띄어넘 우리의 하우트나 아니면은 아웃풋이 뭐냐 요거를 계속 생각을 하게 되더라고요. 이게 처음에는 뭐 고객한테 보이는 거를 뭐 100% 스펙으로 가져가야 된다. 아니면은 뭐 200%의 속도로 가져가야 된다. 뭐 이런 거를 여러 가지 정하고 뭐 거기에 따른 하우트나 뭐 에이전트 MD 무슨 공유하는 이런 것도 썼었잖아요. 모델 컨텍스트 클라우드라고 있습니다. 여튼 그런 >> 아 잘 쓰고 있습니다. 어, 그런 거를 쓰기도 했는데 결국 >> 모이고 모여서 보니까 그 방법론들이 워낙 달라 가지고 그것보다는 우리가 진짜 지켜야 될 원칙 몇 가지만 정해 놓는게 지금으로서는 초기에는 우리가 하고 있는 방식이 >> 제 생각에는 이제 비즈니스의 성격 때문에 그런 거 같아요. 제 생각은 그냥 고객의 성공을 도아야 되는 일인데 고객의 성공을 돕기 위해서 사실 우리나라에 있는 수많은 에이전와이 컨설턴가 있는데 그 컨설턴 중에 일단 고전적으로는 예전에 이제 메킹지나 혹은 BCG 같은 회사들은 기획 방법론 같은 것들 자기들끼리 책으로 만들고 배포하고 막 이런 식으로 일을 하긴 했었거든요. 근데 이제 AI 같은 경우에는 이제 막 탄생하는 개념이다 보니까 그런 것들이 고정화된다든가 정형화 된다든가 이런 것에 당장을 만들기간 어렵지 않을까 하는 생각도 첫 번째 들었고 두 번째로는 저 고객사 내부의이 프로세스가 좀 더 심어지려면 우리가 어떻게 해야 되는가 하는 생각도 전 좀 있었었습니다. 이게 그들의 문제는 제 생각은 이런 단계는 사실 상상도 못 하고 물론이 클로드 코드나 뭐이 하네스가 뭔지부터 배워야 되는게 작금의 현실이겠지만 그래도 그 내부적으로이 정확히 자산화를 할 수 있는 그리고 서로의 이제 통합된 어떤 원칙 같은 것들은 이제 좀 만들어야 된다고 생각하고 있거든요. 근데 그거는 결국은 AI 문서다라고 저는 생각은 하고는 있어요. 근데 그 힌트를 좀 같이 찾아 나갔으면 하는 바람이 있습니다. 저도 네. >> 그러 그게 원래 저희도 시작할 때 거대한 꿈을 안고 포워드 디플로이드 엔지니어링이라는 레포를지 만들어서 거기서 뭔가 여러 가지 정의하고 규율을 좀 만들어 보려고 했는데 이게 제 생각에 스타텀 레벨에서 뭔가를 할 때는 그냥 아무렇게나 하고 자유도를 높게 가져가는게 되게 중요하다고 생각하거든요. 트렌드를 빨리 쫓아. 근데 또 엔터프라이즈에서는 어느 정도 방법론과 프레임을 가지고 하는게 중요한데 엔터프라이즈 경험치를 그렇게 많이 쌓기가 쉽지가 않은 거예요. >> 예. 그게 그래서 저희가 그 레포 만들어 놓고 진행했 이후에 저희가 결국 따낸 계약이 뭐 다섯 개, 여섯 개 그렇거든요. 그러니까 그 경험치 싸는게 좀 어렵더라고요. 그래서 다 같이 힘을 모아야 됩니다.이 엔터프라이즈 레벨 특정 사이즈 이상의 어떤 팀을 대상으로 AX를 한 사람들의 어떤 경험치가 다들 모여야 되고맞아요.이 >> 김준 님이 막 재밌는 시도를 많이 하는데 포워드 디플로이드 엔지니어링으로 지금 막 논문 초안도 작성하고 막 그러고 있거든요. 그러니까 이게 진짜 우리가 세팅해 나가야 할 어떤 분야라고 생각이 들어요. >> 저도 진짜 동감하고요. 정말 100% 어 아직 초기 단계이지만 그래도 이만큼 많이 발전을 해서 보여 주신게 너무 감사하다라는 생각이 또 듭니다. 네. 그럼 다음 단계에도 확실히 뭐 보여줄 수 있을까요? >> 네. 그래서 설계가 잘되게 되면 이제 코드 레벨로 넘어가게 됩니다. 그래서 방금 말씀드렸던 어떤 어떤 대전제와 어떤 도메인 저희 흔히 하는 도메인 드리븐 디자인을 저는 채택해서 많이 사용하는데 그 요구상에 맞는 도메인 모델이 몇 개가 있고 어떤 아키텍처 어떤 하이어라키로 되어야 되는지가 결정이 되면 사실 코드는 쭉 작성이 되면 되거든요. 그래서이 코드 작성하는데 걸리는데 노력이 매우 줄어들었으니까 이제 그 설계안을 가지고 AI 요청만 하면 되는데 여기 보면 실제 작성되는 코드들이거든요. 그럼 저는 여기서부터 다 링터를 통해서이 코드의 아웃풋을 해결하게 됩니다. 그래서 어떻게 해결을 하게 되냐면이 레스토란스 페이지라는게 있는데요. 이게 누구는 레스토랑 리스트 페이지라고도 할 수도 있고 뭐 레스토랑 서치 페이지라고도 할 수 있거든요. 근데 저는 도메인 관점에서 레스토랑이 모여 있으면 복수형의 페이지로 강제하게 됩니다. 윈터를. 그래서 뭐 레스토랑 페이지도 레스토랑 디테일 페이지 이런 식으로 명명을 하기도 하거든요. 근데 디테일 뭐 리스트 이런 거는 파일명에 못 들어가게끔 전 터로 강장. 그래서 어떤 AI 모델을 써도 무조건이 파일으로 가게 돼 있고요. 그럼이 파일명으로 강제되면은이 코드의 하위 클래스나 하이 헬퍼 메소드의 명칭도 강제할 수가 있겠죠. 그리고 저는 임포트 문의 알파벳 순서랑 네. 그리고 어 임포트 가능한 파일, 임포트가 안 되는 파일, 그리고 익스포트 할 때 만드는 배럴 파일의 어떤 규칙 이런 것도 다 린토를 하게 됩니다. 그 저렇게 코드를 강제하게 됐었을 때에 이제 저는 이게 그 일장 일단이 있다는 생각이 개인적으로 좀 들었어요. 그러니깐 마치 이런 거 같아요. 저는 디자이너다 보니까 디자이너 입장에서 해석하면 이제 결과물을 우리는 어떤 브랜드 가인에 맞춰서 디자인 시스템에 맞춰서만 내 놓을 거야. 대신에 일관성이 굉장히 있고 디자인이 품질이 코퀄리티야라고 하는 쪽으로 저희는 일을 하거든요. 디자인 시스템을 그래서 만드는 거죠. 근데 이거는 이제 코드에 말 그대로 시스템을 딱 강제해 가지고 그대로 나오게끔 해서 퀄리티를 유지하겠다. 그리고 일관 몇등성을 가져가겠다라고 하는 그런 접근 방식인 거잖아요. 맞습니다. 그죠? 그랬을 때 장단점이 있지 않을까 싶기는 해요. 아, >> 네. >> 우선 반점은 현태님께 한번 들어보는 걸라고요. 저 장점밖에 안 제가 설 >> 장점밖에 생각이 안 나 가지고 >> 좋아요. 네. 근데 저는 이렇게 시도한 이유는 그 AI로 바이브코딩 하기 전에도 항상 코드는 해결적이고 단일 선택지만 남기도록 선택을 고민 했었는데요. 코드 리뷰어 입장에서도 그 작성하시는 분이 어떤 생각으로 썼는지 알 수 있게끔 그 도구를 만드는 거에 추천 많이 했었어요. 그니까 그 이유가 뭐냐면 어떤 해당 기능이 망가졌다라고 판단이 됐을 때 그 파일을 아예 지우고 새로 작성하는 식으로 했었습니다.

AI 나오기 전에도 왜냐면 그거를 리페토링 하면 당연히 좋겠지만 그것보다도 항상 그 선택지로는 해당 페이 해당 어떤 코드에 버그가 있고 이게 단순한 수정으로 어려울 것 같다. 그러면 그 코드의 역할이 뭔지로서 다 강제가 되어 있었다면은 얘를 그대로 덜어내서 원래 연결되 있던 인터페이스랑 구현체가 무엇인지 다시 역객해서 다시 구현할 식으로 >> 음 >> 근데 그거에 대한 노력이 AI는 너무 쉽게 되잖아요. 네. >> 그래서 저는이 필연적인 >> 코드가 나올 수 있도록 많이 추정하고 있어요. >> 아 들어보니까 확실히 설득이 되네요. 혹시 단점 같은게 있어요? 정 있어요. 그 저희가 원하는 품질을 일관성 있게 맞추려고 하는 작업이다 보니까 이게 제가 생각하는 겁니다. 그 원래 AI가 읽기 편한 AI가 이해하기 편한 그리고 생성하기 편한 어떤 스타일이 분명히 존재할 거라고 생각해요. 지금요 방식들은 우리가 생각하는 어떤 가드레이를 쳐 놓는 거기 때문에 어쩌면 AI가 인풋 토큰으로 받아들이거나 할 때는 오히려 비효율일 수도 있거든요. 근데이 단점을 넘어서는 엄청난 장점이 있다면 이거는 인간과의 협업을 위하는 겁니다. 이게 결국에 우리가 만들어 놓은 지금 제가 생각했을 때 바이브 코딩으로 엔터프라이즈에 딸깍한 다음에 그거 유지보수까지 넘어간 사례는 없거든요. 왜냐면 시기적으로 없어요. 왜냐면 6개월 이후에 유지보수로 넘어가니까 작년 9월부터였으니까 시기적으로 맞지 않고 그러면은이 유지보수를 일반 SI 팀에서 받아서 해야 될 수도 있거든요. 그러면은 그 휴먼 리더블 한 코드가 중요하고 그들의 가이드라인과 그들의 뭔가 가득성에 맞춘게 중요합니다. 우리 옛날에 코딩할 때 보면 임포트 같은 거 쓸 때 >> 쭉 긁어 가지고 컨트롤 커맨드 옵션 L 눌러서 막 뭐 중복 정리하고 막 정리를 하고 이런 플레이들 많이 했는데 저는 지금 이걸 우리가 왜 하고 앉아 있어야 되나 생각을 많이 하거든요. 근데 그게 결국에 받는 사람이 바이브 코딩을 안 할 거면 그리고 거기서 인터넷도 안 되는 데서 코딩을 해야 되는 어떤 환경이면은 우리는 거기에 맞게 완벽한 어떤 예쁜 패키징된 그런 소스를 줘야 된다 생각하고 그것 때문에 이게 되게 중요한 거 같아요. 지금 저희가 같이 일하고 있는 어떤 엔터프라이즈에도 그거를 해야 되는 상황이 생길 거 같거든요. 그렇기 때문에 우리가 자유롭게 블루프린트 많이 세팅을 해 놓더라도 >> 결국 아웃풋을 이런 구성에 맞게 진짜이 엔지니어 레벨에서의 그 코드 레벨에서의 아웃풋을 내 줘야 되는 그게 진짜 중요한 거 같습니다. >> 맞는 말씀인 거 같고 저도 확실히 느끼는게 결국은 유지보수의 문제로 빠지거든요. 이런 것들이. 근데 지금 어쨌든 FD는 그 회사에 영원히 일해 주는게 아니잖아요. 근데 이런 한네스가 먼저 어 설정적으로 잘 되어 있고 그게 결란적으로 유지보수에 넘 관점으로 넘어갔을 때 누가 들어오더라도 어떤 개발자가 새로 들어왔었을 때 아이 규칙 관련된 문서가 있구나 그리고이 규칙은 어떤 식으로 어 정리가 되어 있어라고 하는 것이 이제 약간 유지보수를 하게 되는 시점 자체에서 학습이 좀 더 되고 이어지게끔 하는 형태에 있어서는이 방식이 참 좋다. 저도 그렇게 느껴지는 것 같습니다. 네. 너무 재밌는 거 같고요. 그러면이 다음 단계는 결국 평가 단계로 들어가는 거 같은데요. >> 네. >> 유효한가에 대한 그런 내용인데 지금 보면은 저렇게 그래프가 되어 있는데 저건 무슨 뜻인가요? >> 아, 결국 제가 계속 말씀드리고자 했던 키워드 중 하나는 몇등성이잖아요. >> 네.이 >> 여태까지이 거대한 요구 사항을 넣었을 때 한 번에 어떤 마크다운 문서만 가지고도 한 번에 제 요구 사항 맞출 수도 있고 아무리 제가 그 요구 사항을 마크한 잘 정리 해 놓더라도 빼먹을 수가 있거든요. >> 네. 그래서 린터를 사용하게 되는 거고요. 제가 계속 어떤 프롬프트 엔지니 엔지니어링만 가지고 이거를 항상 강제할 수가 없다 보니까 그니까 제가 클로드한테 커밋 해 줘라고 했을 때 커밋 시도할 때 윈터가 무조건 실행되도록 합니다. 그러면 제가 코드 구조를 잘 만족시켰어라고 묻지 않아도 커밋을 시도할 때 윈트 테스트를 하면서 틀린 걸 알게 되면 아 익스포트에 내가 붙여서 안 되는 서픽스를 뭔가 했구나를 알게 되면 결국 제가 스몰 A부터 스몰 F까지 넣었던 요구 사항이랑 라지 A부터 라지 C까지 넣었던 요구 사항이랑 결국 동치에 아웃풋이 나오게 되는 거죠. 그래서 몇등성이 된다라고 말씀드리고 싶은 거고 그래서 여기서 보여 드리는 거는 >> 서로 AI 모델마다 어떤 거는 한 번에 오래 걸리더라도 한 번에 아풋이 맞게 나오는게 있을 수도 있고 어떤 거는 작게 여러 번 시도해서 나올 수도 있는데 결국엔이 저희가 꾸리고 있는 한해 통해서는 어떤 정교화되는 형태로 간다. 음 >> 노말 폼으로 간다. 이거를 시각하 보고 싶었습니다. 해서 결국 총네 개의 소프트웨어를 세 개 모델에 시켰으니까 12개가 나오게 됐었거든요. >> 네. >> 그래서 이거는 이제 코덱스가 만들어 준 거. 이것은 재미나이가 만들어 준 거. 저희가 다 디자인 시스템이나 이런 거는 좀 회기라 돼 있어 가지고 >> 아 네네. >> 결국 어디 어떤 모델을 시켜도 똑같은 아웃풋이 나오게 됩니다. >> 오 그렇구나. >> 그 저희는 주로 프로토타입을 처음에 가져가니까 디자인의 색깔을 거의 안 입히고 >> 네. 톤 다운해 가져가거든요. 그래서 보시는 것처럼 어떤 AR 모델을 맡겨도 도메인이 고정돼 있었고 설계도 구현하면 똑같은 아프게 됩니다. 네. 오늘 보이고 보여 드리고자 했던 건 딱 이거였습니다. >> 너무 재밌습니다. 네. 뭐 굉장히 상세하고 좋은 내용을 좀 공유해 주셔 가지고 저도 큰 영감이 됐고요. 어 이거를 결론적으로는 저희가 이걸 보시는 분들이 이렇게 처음부터 접근을 하셔야 된다라고 하는 점이 좀 있으실 것 같아요. 그러니까 처음으로 우리가 아 나도 이거 얘기를 듣다 보니까 나도 몇등성을 지키고 싶고 한네스 엔지니어링을 좀 더 잘해 보고 싶어. 그럼 어디서부터나 접근하면 좋을까에 대한 그런 그 약간 초심자의 관점에서는 어떻게 하면 좋을지에 대해서 좀 조언을 주실 수 있을까요? >> 음. 그러니까 저희가 생각하는 거는 그 하네스에서 살겠단을 꽉 잡아 놓는 것도 중요하지만은 진짜 잘 만들어졌는지에 대해서 체크하는 것도 되게 중요하다고 생각을 하고요. >> 그래서 >> 어 지금 저희가 또 하나 집중하고 있는 거는 이밸루에이션 쪽입니다. 근데 이밸루에이션은 >> 하나 자료를 공유하려고 들고 왔는데 진짜 이게 잘 돌아가고 있는지를 어떻게 아냐라고 했을 때 뭐 당연히 저희가 좋아하는 랭체인 덕분에 여러 가지 이밸루에이션을 많이 저희는 할 수 있죠. 할 수 있는데 엔터프라이즈 레벨에서는 법적인 이밸루에이션이 아니라 조직에 맞는 이밸루에이션이 좀 필요하거든요. 예를 들어서 지금 여기 보면 이거는이네 가지 지표는 기본적인 겁니다. 그 보통 AI 이밸루에이션에서 많이 쓰이는 거. 이게 컨택 문맥에 맞는 답변을 하고 있나? 문맥에 어긋난 건 아닌가? 제대로 된 결과를 들고 있나? 제대로 된 소스 데이터를 들고 있나? 이상한게 빠지진 않았나?이 이 여러 가지네 개에 대한 어떻게 뭐 레그 시스템에 대한 이밸루에이션 메소드들이 있습니다. 근데 그런 것들을 기반으로 우리 조직에는 어떤 것들이 적합할까를 보장을 해 줘야 돼요. 옛날에 우리 보면은 서비스 하나 만들면은 응답 속도나 이런 것들 가지고 품질 표준을 딱 잡지 않습니까? 그런 것처럼 AI도 만들어 놓고 나면 진짜 괜찮게 우아하는 거 말고 이게 내일도 모해도 1년 후에도 맨날 맨날 이게 잘 작동하는지 저는 그래서 이거를 옛날에 데이터 도그처럼 에이전트 도그 같다 이렇게 많이 부르거든요. 그래서 이거를 매일매일 체크가 되면서이 품질이 유지되고 있는지 그리고이 에이전트별로 뭐 답변 관련성이나 이런 것들이 진짜 괜찮은지 그리고 100번 물었을 때 한 번 틀렸는게 좋은 건지 나쁜 건지 우리 조직에선 100번 물었을 때 10열 번 틀리더라도 답을 아예 안 했으면 좋겠다. 아니면 어떤 조직은 20번 틀리더라도 틀린 답이라도 했으면 좋겠다. 이게 조직별로 스타일이 다르거든요. 그래서 이밸류에 메소드는 그 조직의 조직 문화랑도 맞다 있습니다. 그래서 이런 엔터프라이즈 a 엔터프라이즈 AI 에이전트에서 그 평가 프레임은 그 랭체인이나 이런 데서 하는 법적인 거에서 우리 조직에 맞게끔 조금 더 변경된 이런 퍼포먼스가 필요하고 요런 것들을 이제 지속적으로 모니터링 해 나가는게 키다. 이렇게 말씀드리면 그럼 이제 앞단에서도 잡히고 코드 레벨로 잡힌 다음에 AI의 답변질까지도 딱 잡히면은 이게 통으로가 통으로 가면 이제 이게 다 잡히는 거죠. 어떻게 보면. 그래서 이게 FD가이 안에서 이제 FD들이 막 놀아도 상관이 없는 겁니다. 앞이 잡힐 거고 뒤가 잡힐 거니까 공격과 소비가 다쳐야 돼. 그래서 이제 그런 식으로 하는 것이 지금 또 엔터프라이즈 AI 에이전트 AI 빌드의 키이다. 공유드리고 싶었어요. >> 아 그 평가 같은 경우에는 그러면이 프로젝트마다이 품질 관리 대시보드를 별도로 제작을 해서 제작 납품을 하시는지 아니면은 그냥 내부에 통합된 어떤 뭐 솔루션 같은 걸 하나 만드셔 가지고 거기다가 하나 둘 셋 이렇게 붙여서 하시는지 그런 포인트가 좀 궁금하거든요. 어떻게 보면 통합된 방법론는 있을 수 있는데요. 당연히 고객사마다 다르게 들어가고요. 왜냐면 요즘 딸각으로 다 만들 수 있으니까. 대신에 그 고객사마다 어떤 이밸루에이션 메돌로지를 활용할지는 이제 고객사의 성향을 보고 저희가 판단을 해야 되는 상황입니다. 그거를 같이 논의하게 되는 것이고요. >> 이게 좋은게 어쨌든 우리가 만든 사람 입장에서도 계속 이밸루에이션을 트래킹을 할 수 있다는 것이고 그리고 상대방 그 클라이언트 입장에서도 아 이게 지금 계속 잘 작동되고 있구나라고 하는 안심을 줄 수가 있는 것이고 그죠. 네. 그렇게 진행이 됨에 있어서 좋은데 프로젝트를 계속 이어 주게끔 해 주는 어떤 연결도 들기는 하는 거 같아요. 그러니까 지금 그냥 하나에 한 번에 들어가서 구축을 쫙 끝내는 빠져나오는 그런 것뿐만 아니라 뭔가 유지보수도 되고 >> 끈을 유지하는 >> 끈을 유지하는 그런 >> 느낌도 있는 거 같다는 생각이 들었었어요. 그럴 수도 있는데 저희가 생각하는 사실 이상적인 거는 저희가 구축해 놓고 가면 이제 그 안에 내부에 있으신 분이 이걸 유지보소할 수 있게끔 우리가 영량을 세팅해 드리고 나와야 된다이긴 하거든요. 그분을 위한 다양한 무기를 세팅해 드리는 거긴 합니다. 그래서 유지보수 관점에서 그거를 이제 어떤 C를 뿌려 놓고 우리가 이제 계속해서 뭔가 컨택을 유지할 만한 어떤 요소가 될 수도 있는데 그것보다는 AI는 어쩔 수 없이 불확정성이 너무 큰 엔진이기 때문에 >> 그거를 또 잡아낼 수 있는 여러 가지 무기를 이제 그 유지보스러에게 드리는 거죠. 그게 이제 기회가 좋아 가지고 저희한테 그 유지보수의 사명이 맡겨진다면 너무 땡크고요. 돈 버는 거니까. 근데 그게 아니라 저희는 지속 가능하려면 내부 인원이 그거를 가능하게 만들어야 된다 생각하고 그럴 때 이제 이런 한네스 뭐든 다 세팅이 되는 거고 그 중에 하나 굉장히 중요한게 이밸루에이션 프레임하고 되겠습니다. >> 예. 충분히 이해했어요. 너무 좋은 말씀입니다. 네. 어 마지막으로 좀 하고 싶으신 말씀 있으실까요? 혹시 뭐 이제 마무리를 좀 해 보려고 하는데 우리 지우 님께서는 오늘 인터뷰 어떠셨는지 소감한 말씀만 해 주시면 감사할 것 같아요. >> 아, 네. 아, 저 하나 말씀드리고 싶 토픽도 하나 있습니다. >> 네. 제가 왜 이렇게 어떤 필연적인 방향을 고민하게 됐는지에 대한 일화가 하나 있는데요. >> 저는 하드웨어 프로젝트를 잘 그니까 성공적으로 끝내지 못한 경험이 있어요. 그 하드웨어 프로젝트를 하면서 어떤 역할을 했었냐면 페로도 설계했었어야 됐고 펌웨어도 구현을 했었어 됐어요. 근데 펌웨어를 구현하는 건 CE 코드였는데요. 그러니까 그 당시에 제가 시코드로 많이 구현했었어서 어 잘 할 수 있을 거라 생각했는데 카드 구현하면서 뭔가 잘 안 되는 거예요. 그래서 안 된다고 어떤 멘토분이나 혹은 전문가분 찾아가면은 포맷을 해오라는 걸 말씀해 주시는 거예요. 포맷을 하면 돼요. 그래서 저는이 상황이 그 당시에 되게 어려웠었어요. 그 소프트에어 전공자로서는 근데 아 보니까 다시 제로로 돌아갔을 때 그 결과물로 가는 단계가 어 몇 등이야 되는구나를 뭔가 그 겪은 문제의 솔루션은 아니지만 뭔가 내가 어떤 짓을 했는지를 모르면 결국 포맷을 해서 처음부터 다시 윈도우부터 설치하고 매고 초기한 다음에 컴파일러 다시 설치하고 그렇게 해야 기본 제공해 주는 예제 코드를 실행하는데 도 그렇게 해야 되더라고요. >> 음. >> 그래서 아 그러면서 그때 경험이 이제 지금의 영향을 주고 있는 거 같아요. 그 본인의 어떤 경험에서에 들어나온 그 기억은 사실 강렬하죠. 그 문제를 내가 직접 경험했으니까 풀고 싶다라고 하는게 저도 저도 예전에 한번 겪었던 적은 있었던 비슷한 문제가 있었던 거 같아요. 충분히 공감이 되는 말씀이었던 거 같습니다. 네. 한네스 엔지니어링 오늘 정말 많이 배우셨을 수 있을 것 같고 또 지운 FD님 이제 링크드인 주소도 남겨 놓을테니까 많은 분들 찾아셨으면 좋겠고네 이렇게 해서 오늘 이렇게 스페이스와 황현패 대표님 그리고 김지훈 FD도 모시고 우리 한네스 엔지니어링에 대해서 좀 깊이 있게 얘기를 나눠봤는데 저는 개인적으로 너무 재밌었습니다. 성공적인 녹화였고 여러분들도 그게 꼭 전달 되셨으리라 전 생각을 하고요. 저희는 또 다음번에 또 나와 주셔 가지고 또 많은 토픽도 나눴으면 좋겠습니다.네 네. 오늘 고생 많으셨습니다. 고맙습니다. >> 감사합니다.