이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

요즘 기업들 사이에서 'AX'라는 단어가 빠르게 퍼지고 있어요. AI Transformation, 즉 업무 방식 자체를 AI로 재설계하는 흐름이거든요. 개발 현장도 마찬가지예요.

불과 1~2년 전만 해도 "AI가 코드를 써준다"는 말이 신기했지만, 지금은 AI로 코드를 짜는 건 당연한 이야기가 됐고, 이제는 "어떻게 하면 AI가 항상 같은 품질의 코드를 뽑아내게 할 수 있느냐"가 진짜 숙제가 됐습니다.

이 숙제를 풀기 위해 등장한 개념이 바로 '하네스 엔지니어링(Harness Engineering)'이에요. 단어 그대로 AI라는 힘센 말에 마구(harness)를 채워 원하는 방향으로 통제한다는 뜻입니다.

오늘 대화는 이 하네스 엔지니어링이 실제 엔터프라이즈 프로젝트에서 어떻게 작동하는지를, 실제 업계에서 몸소 구현하고 계신 두 분을 인터뷰하며 따라가 봅니다. 

두 사람, 두 역할

Q. 황현태 대표님 간단히 소개해 주시겠어요?

엔터프라이즈 AX 기업 스페이스와이의 대표 황현태입니다. 최근에는 '까칠한 AI'라는 유튜브 채널도 시작했어요. 엔터프라이즈 AX 경험담을 들려드리는 채널인데, 현장 경험이 아직 워낙 부족하다 보니 그 경험치를 다 같이 나눠야 한다고 생각해서 시작하게 됐거든요.

Q. 김지운 님은 포워드 디플로이드 엔지니어(Forward Deployed Engineer)로 일하신다고 하셨는데, 어떤 역할인가요?

직역하면 파견형 엔지니어예요. 고객사를 직접 방문해서 회의를 통해 나오는 피드백들을 정리하고, 함께 제로에서 하나를 만드는 역할이라고 보면 됩니다. 고객이 "이런 게 필요해요"라고 막연하게 던지면, 그걸 구체화하고 실제로 구현까지 하는 거죠.

Q. 오늘 주제인 '하네스 엔지니어링'을 한마디로 설명하면?

(김지운) 오늘 결국 간단하게 말씀드리면, 어떤 AI 모델을 쓰든 일관성 있는 결과물을 얻기 위한 방법론입니다. 클로드를 쓰든 코덱스를 쓰든 제미나이를 쓰든, 이 하네스 엔지니어링 기법을 잘 활용하면 다른 AI 모델을 써도 같은 아웃풋이 나올 수 있게끔 방향을 강제할 수 있어요. 그걸 오늘 배달 플랫폼 예시로 처음부터 끝까지 보여드리려고 왔습니다.

배달 플랫폼으로 보는 하네스 엔지니어링 6단계

Q. 왜 배달 플랫폼을 예시로 가져오셨나요? 

(김지운) 많은 분들이 이미 익숙한 서비스니까요. 어떤 앱이고 어떻게 작동하는지 대부분 알고 계시니까, 별도 설명 없이 구조를 바로 이해하기 쉽거든요.

그리고 배달 플랫폼이 하나의 앱처럼 보여도 실제로 설계해보면 네 개의 소프트웨어로 나뉩니다. 처음에 고객이 "배달 앱 만들어 주세요"라고 하면 고객이 주문하는 앱만 떠올리는 경우가 많아요. 근데 대화를 이어가다 보면 "아, 기사님 앱도 따로 필요하겠네요", "음식점에서 주문 수락하는 앱도 있어야겠죠", "이걸 다 관리하는 어드민도 필요하겠구나"로 자연스럽게 이어지게 됩니다.

• 고객 앱 : 일반 사용자가 주문할 때 쓰는 앱
• 기사 앱 : 배달기사가 픽업 위치와 배달 목적지를 확인하는 앱
• 음식점 앱 : 주문을 수락하고 조리 완료를 알리는 앱
• 어드민 : 전체 플랫폼을 관리하는 내부용 대시보드

FDE로서 고객 이야기를 들어보면, 구성 요소를 작게 쪼갰을 때 이 네 가지 분류가 나오고, 각각에 맞는 소프트웨어가 필요하다는 판단이 나오게 됩니다.

Q. 그 네 개를 만들기 전에 먼저 해야 할 일이 있나요?

(김지운) 네, 총 여섯 개의 단계로 오늘 보여드리려 했고요. 순서대로 말씀드려볼게요. 

1. 요구 사항 수집— 고객의 막연한 니즈를 모두 듣는다
2. 플랜 수립 — 미팅 내용을 구조적으로 정리한다
3. 기획 문서화 — CPS(컨텍스트-프러블럼-솔루션), PRD 등을 작성한다
4. 아키텍처 설계 — 코드 레벨 설계를 한다
5. 코드 작성 + 린터 — AI가 코드를 쓰고, 린터로 아웃풋을 강제한다
6. 이밸류에이션 — 일관성과 품질을 지속적으로 모니터링한다

플랜 단계: 미팅을 구조화하는 방법

Q. 플랜 단계에서는 가장 중요한 게 뭔가요?

(김지운) FDE로서 저는 주에 두세 번 고객사 미팅을 해요. 하루에 두 번씩 하면 총 네 번의 고정 미팅이 생기거든요. 매 미팅 직전에는 이전에 완성된 내용을 리뷰하고, 오늘 해야 할 것과 완수된 것을 함께 확인합니다.

플랜에서 핵심은 미팅 로그예요. 회의가 발산적으로 진행되다 보면 이야기가 사방으로 튀거든요. 그걸 수렴해서 정리하는 거죠. 어떤 게 부족했고, 어떤 건 잘됐고, 어떤 건 필요 없고, 어떤 건 외부 솔루션을 사서 쓸 건지, 어떤 건 직접 구현해야 하는지 이런 것들을 분석하게 됩니다.

미팅 원칙도 두 가지가 있어요.

하나는 고객을 제한하지 않는 것이에요. 고객이 하고 싶은 말을 다 하게 두는 거죠. 저도 미팅하다 보면 습관적으로 말을 끊으려는 경우가 있는데, 둘이 같이 가면 서로 눈빛으로 신호를 보내면서 막습니다.

또 하나는 모든 내용을 전사화하는 것이에요. 그냥 나눴던 요약을 남기는 거죠.

Q. 그 미팅 로그가 최종적으로 어떤 문서로 이어지나요?

(김지운) 미팅 로그들이 쌓이면, 그것들을 종합한 CPS 문서(컨텍스트-프러블럼-솔루션)가 나오게 됩니다. 그리고 CPS가 확정되면 PRD(제품 요구 사항 문서)로 이어지고요. 모든 미팅 로그가 CPS 하나로 수렴되고, CPS가 PRD 하나로 수렴되는 구조예요.

Q. 플랜 단계에서 클로드, 제미나이, 코덱스를 모두 써서 비교하는 장면이 있던데, 왜 세 개 모델을 동시에 쓰나요?

(김지운) 저는 사실 클로드만 쓰고 있기는 한데요. 오늘 보여드리려 한 건, 다른 AI 모델을 쓰더라도 하네스 엔지니어링 기법을 적용하면 필연적으로 같은 결과가 나온다는 걸 증명하기 위해서예요.

AI 모델 랭킹은 계속 바뀌잖아요. 어떨 때는 오퍼스 4가 제일 좋다가, 또 어떨 때는 GPT가 더 낫다가 하거든요. 저희는 AI 모델을 만드는 사람이 아니라 가져다 쓰는 사람이에요. 그러니까 "어떻게 하면 어떤 모델을 써도 잘 가져다 쓸 수 있느냐"가 더 중요한 질문이거든요. 모델이 바뀌더라도 이 기법은 유효하다, 그게 핵심이에요.

CPS 프레임워크: 컨텍스트-프러블럼-솔루션

Q. CPS 문서가 뭔지 좀 더 설명해 주실 수 있나요?

(황현태) CPS는 컨텍스트(Context)-프러블럼(Problem)-솔루션(Solution)의 약자예요. 팔란티어가 내부 FDA 미팅을 할 때 '머드 세션' 같은 방식으로 발산하고 수렴하는 과정을 거친다는 걸 참고했어요. 저는 제품 매니저 시절부터 이 CPS 프레임워크로 생각을 정리해 왔었는데, 스페이스와이에서도 이걸 기준 문서로 쓰자고 제안하게 됐죠.

CPS는 어떤 맥락에서 어떤 문제를 겪고 있기 때문에 어떤 솔루션을 만들어야 하는지를 정리하는 프레임워크예요. 매번 새로운 문제를 발견하고 솔루션을 교환하다 보니 컨텍스트는 계속 쌓여가거든요. 그래서 CPS 문서를 계속 업데이트하면서 쓰게 됐습니다.

Q. 이 CPS 문서를 내부용으로만 쓰나요, 고객에게도 공유하나요?

(김지운) 클라이언트 공유용으로도 씁니다. 마크다운 파일로 관리하다가 PDF로 빌드해서 드려요. 저희가 쓰는 레이텍 템플릿이 있어서 그걸로 예쁘게 만들어드리고 있어요.

공유 시점은 POC(개념 검증) 기간 중 두 번 정도예요.

1차 스펙이 확정됐을 때 한 번, 프로젝트가 끝났을 때 역기획해서 한 번. 매 미팅 때마다 드리면 너무 버거우니까, 큰 단위로 마무리됐을 때 전달드리는 거죠.

고객사는 저희 깃허브에 초대돼 있어서 CPS 문서가 업데이트될 때마다 볼 수는 있어요. 근데 형식적으로 전달드리는 건 두 번 정도예요.

Q. 고객사가 이런 설계 문서에 왜 관심을 갖나요? 보통은 결과물만 보고 싶어하지 않나요?

(황현태) 실제로 관심 갖는 경우가 꽤 많아요. "딸깍하면 잘 나온다는 건 이제 저희도 알아요. 근데 어떤 세계관에서 어떻게 설계됐는지가 궁금합니다"라고 물으시는 분들이 있거든요.

그 이유가 있어요. 결국 고객사 입장에서도 아이디어를 계속 줘야 하거든요. 근데 우리의 구현 세계관을 알아야 더 맥락에 맞는 아이디어를 줄 수 있는 거예요. 어떤 고객사는 문서를 가져가서 충분히 공부하고 다음 미팅에 오시는데, 그러면 커뮤니케이션 속도가 확 달라지거든요. 문서가 주는 매력이 있습니다.

Q. 문서를 먼저 주는 게 선행인지, 아니면 결과물을 먼저 보여주는 게 더 효과적인가요?

(김지운) 해보니까 대부분은 소프트웨어 결과물만 가져가요. 근데 프로젝트 초반에는 "우리가 이야기한 기능 명세는 이렇고, 어떤 분석 과정을 통해 나왔다"는 걸 문서로 드리게 됩니다. 이건 초안이고 얼마든지 발산할 수 있으며, 산출물이 확정됐을 때 다시 역기획해서 드리겠다고 하는 거죠.

(황현태) 저는 플레이라이트 MCP로 화면을 캡처해서 매뉴얼화한 다음에 드리기도 해요. 스크린샷이랑 설명을 같이 놓고, "만화처럼 이해하시면 됩니다"라고 하는 거죠. 매 회의 전에 미리 파악해오고, 계속 이해도를 높여가는 이 커뮤니케이션이 정말 중요하다고 생각해요.

설계 원칙: 왜 원칙이 최종 결과물을 결정하는가

Q. 기획 문서 이후에는 어떻게 되나요? 설계 분석으로 넘어간다고 하셨는데

(김지운) 네, 다음 단계는 원칙 수립이에요. 각 프로젝트마다 원칙이 다를 수 있지만, 예를 들어 에이전트 프로젝트라면 "휴먼인더루프(인간이 최종 결정을 검토하는 구조)가 있어야 한다", "할루시네이션이 없어야 한다", "오딧 로그가 잘 남아야 한다" 이런 대전제들이 생겨요.

이런 원칙들이 세워지면, 개념 정의를 내리게 됩니다. 개념들의 하이어라키(위계)를 정하면 구조가 잡히고, 그 구조에 맞게 데이터를 어떻게 주고받을지 기술적으로 설계하면 결과물들이 필연적인 방향으로 가게 됩니다.

Q. 그 원칙을 세우는 데 있어 특별히 참고한 레퍼런스가 있나요?

(김지운) 명쾌하게 어디서 보고 이렇게 됐다고 말씀드리기가 어려워요. 트렌드도 많이 타고, 엔지니어만의 관점도 안 되고 창업자만의 관점도 안 되는 영역이거든요. 보고 듣는 게 너무 많고, 레퍼런스가 진짜 레퍼런스인 것도 있고 카더라 이야기도 있고 하다 보니까요.

한마디로 말하면, 지금까지 배웠던 지식들을 녹여내다 보니까 어쨌든 상위 레벨에서 원칙들을 세우게 됐고, 원칙이 정의(Definition)로 넘어가고, 정의 다음에는 구조(Structure)로 빠지게 됐어요. 매시브한 부분에서 계속 파고 들어가는 과정이었는데, AI 엔지니어링을 같이 하다 보니 저런 내용들이 쪼개진 거 같아요.

Q. 이런 원칙과 설계 문서를 팀 내에서는 어떻게 공유하세요?

(황현태) 저희는 업무 방식 자체를 통일하진 않아요. 멘탈 모델을 일치시키는 데 더 집중해요.

모든 산출물은 팀 깃허브에 다 오픈돼 있고, 로그는 노션에 다 있고, 슬랙이 있어요. 세 개예요. 거기서 서로 프로젝트를 이어받을 수도 있고, 넘겨받을 수도 있거든요. 근데 이 사람은 어떤 코딩 컨벤션으로 하는지까지는 강제하지 않아요.

Q. 방식을 통일하지 않고 멘탈 모델만 맞추는 이유가 있나요?

(황현태) 해보니까 프로젝트마다 KPI가 다르거든요. 뭘 제1 원칙으로 두느냐가 매번 달라요. 어떤 때는 고객에게 보이는 것을 100% 스펙으로 가져가야 하고, 어떤 때는 200% 속도로 가져가야 하고. 방법론들이 워낙 달라서, 그것보다는 우리가 진짜 지켜야 할 원칙 몇 가지만 정해놓는 게 초기에는 더 효과적이에요.

(김지운) 고정 요일에 팀이 모여서 각자의 설계를 리뷰하는 시간도 있어요. 서로 강점과 관점이 다르다 보니, 각자 다른 방식으로 설계하고 서로 영향을 주고받으면서 집단 지성을 만들어가는 식이에요.

코드 레벨: 린터로 AI 아웃풋을 강제하는 방법

Q. 설계가 끝나면 코드 레벨로 넘어간다고 하셨는데, 어떻게 진행되나요?

(김지운) 도메인 드리븐 디자인(Domain Driven Design)을 채택해서 많이 사용해요. 요구 사항에 맞는 도메인 모델이 몇 개인지, 어떤 아키텍처와 하이어라키로 돼야 하는지가 결정되면, 코드는 그냥 쭉 작성되면 되거든요. AI에게 설계안을 주고 요청만 하면 되는 거죠. 그 과정에서 노력이 매우 줄었어요.

그리고 여기서부터는 린터(Linter)를 통해서 코드 아웃풋을 균일화하게 됩니다.

Q. 린터로 코드를 어떻게 강제하나요? 구체적으로 설명해 주실 수 있나요?

(김지운) 예를 들어 '레스토랑 목록 페이지'를 만든다고 해요. 누구는 이걸 restaurantListPage라고 부를 수도 있고, restaurantSearchPage라고 부를 수도 있어요. 근데 저는 도메인 관점에서 레스토랑이 여러 개 모여 있으면 복수형 페이지 이름으로 강제해요. detail, list, search 같은 단어는 파일명에 못 들어가게끔 린터로 막는 거죠.

이렇게 파일명이 강제되면, 그 하위 클래스나 헬퍼 메소드의 이름도 강제할 수 있게 됩니다. 임포트 문의 알파벳 순서도 강제하고, 임포트 가능한 파일과 불가능한 파일 규칙도 린터로 잡고, 익스포트할 때 만드는 배럴 파일 규칙도 다 린터로 적용해요.

그리고 클로드에게 커밋(코드 저장)을 해달라고 하면, 커밋 시도할 때 린터가 무조건 실행되도록 합니다. 그러면 제가 "코드 구조 잘 맞췄어?"라고 물어보지 않아도, 커밋할 때 린터 테스트를 하면서 틀린 걸 알게 되거든요. 결국 어떤 AI 모델에 시켰든 동치의 아웃풋이 나오게 되는 거예요. 이게 멱등성입니다.

Q. 디자인 시스템이랑 비슷한 개념 같아요. 그 유사성을 어떻게 보세요?

(황현태) 저도 그렇게 느꼈어요. 저는 디자이너 배경이라 해석이 자연스럽게 됐는데, 결과물을 우리가 어떤 브랜드 가이드, 디자인 시스템에 맞춰서만 내놓을 거야. 대신 일관성이 굉장히 높고 품질이 고퀄리티야, 이런 식이잖아요. 디자인 시스템을 만드는 이유가 그거거든요.

코드에 그 시스템을 강제해서 그대로 나오게끔 퀄리티를 유지하겠다, 일관성을 가져가겠다는 접근 방식인 거예요. 장단점이 있지 않을까 싶은데, 저는 장점밖에 안 보여서 단점을 말씀드리기가 어렵네요.

Q. 단점이 있다면요?

(김지운) 솔직히 하나 있어요. 저희가 원하는 품질과 일관성을 맞추려고 가드레일을 쳐놓는 거잖아요. 근데 AI가 인풋 토큰으로 받아들일 때는 오히려 비효율이 생길 수 있어요. AI가 "읽기 편하고 생성하기 편한 스타일"이 있을 텐데, 우리가 강제한 구조가 그것과 다를 수도 있거든요.

근데 이 단점을 넘어서는 엄청난 장점이 있어요. 인간과의 협업이에요.

바이브 코딩으로 엔터프라이즈 프로젝트를 딸깍한 다음에 유지보수까지 넘어간 사례는 아직 없어요. 시기적으로 없거든요. 작년 9월부터 시작됐으니 6개월 후에 유지보수로 넘어가는 게 이제 막 시작되는 단계예요. 그러면 일반 SI 팀이 넘겨받아서 유지보수를 해야 할 수도 있어요. 그때 휴먼 리더블(사람이 읽기 쉬운)한 코드가 중요하고, 그 팀의 가이드라인과 가독성에 맞춰진 코드가 필요합니다.

예전에 코딩할 때 임포트 문 정리하고 중복 제거하고 이런 작업들을 "왜 하고 앉아 있어야 되나" 싶을 때가 있잖아요. 근데 결국 받는 사람이 바이브 코딩을 안 하는 환경이면, 우리는 거기에 맞게 완벽하게 패키징된 소스를 줘야 해요. 그게 이 린터 기반 하네스가 왜 중요한 이유예요.

Q. 그래서 유지보수 관점에서도 이 하네스 구조가 의미를 갖는 거군요.

(황현태) 정확해요. FD는 그 회사에 영원히 일해주는 게 아니잖아요. 근데 하네스가 먼저 잘 설정돼 있고, 유지보수로 넘어갔을 때 새로 들어오는 개발자가 "규칙 관련 문서가 있구나, 이 규칙은 이렇게 정리돼 있구나"를 보고 학습이 되는 구조. 그 관점에서 이 방식이 참 좋다고 느꼈어요.

이밸류에이션 : 만들고 나서도 계속 잘 작동하는지 확인하는 법

Q. 코드까지 만들었으면 끝 아닌가요? 이밸류에이션이 왜 필요한가요?

(황현태) AI는 한 번 만들면 끝이 아니에요. 서비스 하나 만들면 응답 속도 같은 것들로 품질 표준을 잡잖아요. AI도 만들어놓고 나면, 진짜 괜찮게 돌아가는지 아닌지를 내일도, 모레도, 1년 후에도 매일매일 확인해야 해요. 저는 이걸 "에이전트 도그(Agent Datadog)"라고 많이 부르거든요.

Q. 어떤 기준으로 평가하나요?

(황현태) 기본적으로 네 가지 지표가 있어요. AI 이밸류에이션에서 많이 쓰이는 것들인데

• 연관성(Relevance): 맥락에 맞는 답변을 하고 있나
• 충실도(Faithfulness): 맥락에 어긋난 건 아닌가
• 정확성(Correctness): 제대로 된 결과를 내고 있나
• 소스 품질(Source Quality): 제대로 된 소스 데이터를 들고 있나, 이상한 게 빠지진 않았나

랭체인 같은 곳에서 표준 이밸류에이션 방법론이 있긴 한데, 엔터프라이즈 레벨에서는 그 표준 그대로 쓰는 게 아니라 조직에 맞는 이밸류에이션이 필요해요.

Q. 조직마다 이밸류에이션 기준이 다르다는 게 어떤 의미인가요?

(황현태) 예를 들어, 어떤 조직은 "100번 물었을 때 10번 틀리더라도 답을 아예 안 했으면 좋겠다"예요. 아예 모르면 "모릅니다"라고 해주길 원하는 거죠. 근데 어떤 조직은 "20번 틀리더라도 틀린 답이라도 했으면 좋겠다"예요. 일단 뭔가 제시를 해주길 원하는 거죠.

이게 조직 문화랑도 맞닿아 있어요. 그래서 이밸류에이션 방법론은 그 조직의 성향을 보고 결정하게 되고, 고객사와 함께 논의해서 정하게 됩니다.

Q. 이밸류에이션 대시보드를 프로젝트마다 새로 만드나요?

(황현태) 고객사마다 다르게 들어가요. 요즘 딸깍으로 다 만들 수 있으니까요. 근데 어떤 이밸류에이션 방법론을 활용할지는 고객사 성향을 보고 저희가 판단해서 같이 논의하게 됩니다.

이게 좋은 건 만든 저희 입장에서도 계속 트래킹을 할 수 있다는 것이고, 클라이언트 입장에서도 "아, 지금도 잘 작동하고 있구나"라는 안심을 줄 수 있다는 거예요. 그리고 어떻게 보면 프로젝트를 계속 이어주는 연결고리가 되기도 하죠.

Q. 유지보수를 내부에 넘기는 게 이상적이라고 하셨는데, 이밸류에이션 프레임워크도 그때 같이 넘기나요?

(황현태) 네. AI는 불확정성이 너무 큰 엔진이에요. 그걸 잡아낼 수 있는 여러 무기를 유지보수 담당자에게 드리는 거예요. 기회가 좋아서 저희가 유지보수까지 맡게 된다면 그것도 좋고, 아니더라도 내부 인원이 지속 가능하게 운영할 수 있도록 만드는 게 더 중요합니다. 그 핵심 무기 중 하나가 이밸류에이션 프레임워크예요.

린터와 하네스, 어떻게 시작할까

Q. 하네스 엔지니어링을 처음 도입하려는 사람에게 어디서부터 시작하라고 하시겠어요?

(황현태) 하네스에서 살겠다는 걸 꽉 잡아놓는 것도 중요하지만, 진짜 잘 만들어졌는지 체크하는 게 되게 중요해요. 그래서 앞단(하네스/린터)과 뒷단(이밸류에이션)을 같이 잡아야 해요. 앞이 잡히고 뒤가 잡히면, 그 안에서 FDE들이 어떻게 코딩하든 공격과 수비가 다 갖춰진 거니까요.

(김지운) 저는 린터를 처음부터 도입할 때 이런 원칙에서 출발했어요. AI 나오기 전에도 항상 코드는 단일 선택지만 남기도록 설계를 많이 고민했었어요. 코드 리뷰어 입장에서도 작성자가 어떤 생각으로 썼는지 알 수 있게 구조를 명확히 만드는 데 주력했고요.

그 이유가 뭐냐면, 어떤 기능이 망가졌을 때 리팩토링보다 해당 파일을 지우고 새로 작성하는 방식을 택했어요. 파일이 하는 역할이 강제돼 있으면, 그 파일을 덜어내고 원래 연결돼 있던 인터페이스와 구현체를 역추적해서 다시 구현하기가 훨씬 쉽거든요. 근데 AI로는 이게 너무 쉽게 되잖아요. 그래서 이 필연적인 코드가 나올 수 있도록 하는 데 집중했어요.

아직 초기지만, 같이 쌓아가야 할 분야

Q. 엔터프라이즈 AX는 아직 경험치가 부족하다고 하셨는데, 어떻게 쌓아가고 계신가요?

(황현태) 저희가 지금까지 따낸 계약이 다섯, 여섯 개 정도예요. 스타트업 레벨에서는 자유도를 높게 가져가고 트렌드를 빨리 쫓는 게 중요해요. 근데 엔터프라이즈에서는 어느 정도 방법론과 프레임을 가지고 하는 게 중요한데, 그 경험치 쌓기가 쉽지 않아요.

맥킨지나 BCG 같은 전통 컨설팅 기업들은 방법론을 책으로 만들고 배포하면서 정형화했잖아요. AI 분야는 막 탄생하는 개념이다 보니 그런 게 고정화되기가 어렵고요. 그래서 엔터프라이즈 레벨에서 특정 사이즈 이상의 팀을 대상으로 AX를 한 사람들의 경험치가 다 같이 모여야 한다고 생각해요.

(황현태) 실은 포워드 디플로이드 엔지니어링으로 논문 초안도 작성하고 있거든요. 진짜 우리가 함께 세팅해 나가야 할 분야라는 생각이 들어요.

Q. 마지막으로, 이렇게 필연적인 구조에 집착하게 된 계기가 있나요?

(김지운) 사실 제가 왜 이 필연적인 방향에 이렇게 집착하게 됐는지에 대한 일화가 하나 있어요.

예전에 하드웨어 프로젝트를 했었는데, 회로도 설계와 펌웨어 구현을 동시에 맡았어요. C 코드를 많이 써왔으니 잘 할 수 있을 거라 생각했는데, 뭔가 계속 안 되는 거예요. 멘토나 전문가를 찾아가면 "포맷을 해요"라는 말만 해주시더라고요. 그 당시 소프트웨어 전공자로서는 되게 어려운 상황이었어요.

결국 제로로 돌아갔을 때, 그 결과물로 가는 단계가 몇 개가 있다는 걸 느꼈어요. 기본 예제 코드를 실행하는 것조차, 윈도우부터 설치하고 메모를 초기화하고 컴파일러를 다시 설치하는 과정을 거쳐야 했거든요. 그때 경험이 지금의 설계 방식에 영향을 줬어요. 직접 겪은 문제는 강렬하게 남으니까요.

 

😎 하네스 엔지니어링의 현장 이야기를 계속 따라가고 싶다면?!

📌 황현태 대표 — [DIO] | [까칠한 AI 유튜브]
📌 김지운 FDE — [LinkedIn]

오늘 레터가 좋았다면, 조쉬의 뉴스레터를 주변에 알려주시거나, 구독을 해주세요. 소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]