바이브 코딩 AI 시대의 개발자 역할 변화에 대한 깊이 있는 대화를 담고 있습니다

https://m.youtube.com/watch?v=WIqo3Fmxjqk&t=9358s

- - 을 보려면 어떻게 되죠? 유튜브 채팅을. 아, 유튜브 채팅을 보시려면은 유튜브 앱을 저는 모바일 접속하셔야 예 접속하셔서 보셔야 됩니다. 아니면 그 유튜브 제가 테디노트 라이브에 들어가도 되는 거죠? 그러니까 유튜브 웹에서. 네 맞아요, 저도 그렇게 들어와 있어요 지금. 예. 음, 지금 시작을 했고요. 어, 깜짝이야. 아, 예 시작을 해서 어 네 라이브에 올라갔습니다. 반갑습니다. 네, 안녕하세요. 네, 안녕하세요. 안녕하세요. 반갑습니다. 아, 오 지금 35분 바로 입장해 주셨고요. 네, 반갑습니다. 어, 들어오신 분들 너무 반갑고요. 어, 이렇게 오랜만에 또 라이브를 했는데 요즘에 가장 핫한 주제인 바이브 코딩 주제를 안 건드릴 수가 없습니다. 예, 저희 채널에서 어 레그나 에이전트 다루고 있는데 바이코딩은 안 다룬다. 아, 이거는 있을 수가 없는 일이죠. 그런데 이제 오늘 모신 분들은 어 바이브 코딩계의 어떤 거장이라고 불리우는 엄청나게 유명하신 분들을 모시게 돼서 너무 영광이고요. 예, 들어오신 분들도 너무 반갑습니다. 네, 반갑습니다. 어, 좋아요 한 번씩만 눌러 주시면은 너무 감사드리겠습니다. 네, 저희 큰 도움이 될 거 같아요. 예, 나도 눌러야겠다. 예, 좋아요 한 번씩 꼭 좀 부탁드리겠습니다. 어, 55분 예 들어와 주셨고요. 어, 일단 구스 님 아 구스 대표님 반갑습니다. 찬스 님, 성민 님, 한주 님, 메이커주 님, 키 어시스트 님, 비트 단칼님, 어 정우 님, 주주 주현 님, 아 태화 님, 아 반갑습니다. 민노님, 어 네탄 81님, 제님, 어 그다음에 SCB킴 님, 진여진 님, 아 휘동 님께서도 남겨 주셨고요. 네, 너무 반갑습니다. 형미 님은 예 안녕하십니까. 어 토론돌 예 안녕하십니까. 오연 님도 와 주셨고요. 아 네 어 금방 저희 9시 1분이 됐는데 벌써 65분 어 빠르게 또 놀고 있습니다. 네, 오늘 너무 기대되는 주제이고요. 어 사실 오늘은 바이브 코딩 주제를 들고 오셨는데 어 이제는 자다가도 별 나오는 그런 어 주제 아니십니까 두 분께서는. 아 그렇죠. 왜냐하면 강의 자료 납기에 맨날 시달리기 때문에 저희가 소위 말하는 장표 개발자라고 하거든요. 아, 장표 개발자요? 예, 장표 개발자. 아, 근데 강의 한번 저는 저도 강의를 찍고 그랬지만 자 강의 찍으면서 개발자로서의 장점은 분명히 있는 게 한번 정리가 되는 느낌이랄까 그런 게 좋은 거 같았어요. 그래서 두 분께서도 최근에 강의 런칭하셨죠. 네, 네 저희 두 달 반 아 이제 거의 세 달 가까이 되고 있는 거 같고 지금 저희가 네 번, 네 번의 납기 중에 3차 납기를 쓰고 있는데 매일매일 죽어나고 있습니다. 네, 고통 받고 있으시죠. 예. 네네. 어떠세요 동주 님께서는 그냥 서로 발등에 떨어진 불을 같이 잘 끄기 위해서 아우겨우 하고 있습니다. 그래서 또 거장이라 소개하셨는데 저희가 둘 다 사기꾼이 되지 않기 위해서 더 알찬 내용들을 넣기 위해 노력하고 있어요. 원래 그 선 약속을 하고 그 약속을 지키기 위한 어떤 노력들을 이제 전개하고 계신 거 같고요. 어, 납기일 준수를 잘 해 주셔야 하는데 아, 납기일 지키는 게 너무 어렵죠. 이 시기에 막 입 부르트고 장난 아니에요. 너무 너무 힘들어 가지고. 아, 그만큼 이제 강의 혼을 다 담고 계신 거 같습니다. 그런데 바이브 코딩 그 강의는 어려울 거 같아요. 왜냐하면 방법론이라는 게 뭐 또 금방금방 재인지가 되는 거잖아요. 커서 업데이트가 됐는데 어 신기능이 나왔다. 아, 그런데 또 이거를 이걸 갑자기 그전에 알고 있던 방법론이 다 깨지고 뭐 새로 나온 어떤 기능들이 다 그냥 너무 좋아져 버리고 뭐 그럴 수도 있을 것 같은데 굉장히 어려운 분야인데 잘 해 주고 계신 거 같습니다. 그래서 오늘 일단 이따가 강의도 제가 한번 여쭤 보려고 합니다. 저희 이거 9시 4분이고 지금 85명이 들어오셔서 이제 슬슬 본 토론으로 한번 들어가 보도록 하겠습니다. 오늘 주제가 바코딩 주제인데요. 어, 혹시 어떤 내용을 말씀해 주실 건지 어 간단히 제가 휘동님께 여쭤 볼게요. 오늘은 주요 내용에 대해서 간단히 소개해 주실 수 있어요. 네, 그 뭐 사전에 저희랑 저랑 동주 님이랑 좀 논의를 하면서 이런 얘기 하면 좋겠다 싶어서 뭐 정리해 본 게 일단 어 여기 바이브 코딩이 뭔지 모르시는 분들은 당연히 없겠지만 그래도 이제 바이브 코딩이 왜 의미가 있고 하지만 한계는 뭐가 있고 이런 걸 좀 간단히 얘기를 해 보고요. 그리고 저희 강의 강의가 아니라 이번 라이브의 제목이기도 한 바이브 코딩을 그냥 하는 거랑 잘하는 거랑 점점 더 잘하는 거를 어떻게 다르게 할 수 있을까? 요거를 위주로 계속 얘기를 할 거 같아요. 음, 어 그거를 이제 제품 개발 전체 프로세스에 대해서 어떻게 하면 AI 전체적으로 잘 쓸까? 그리고 우리가 어떻게 훈련을 의식적으로 하면서 점점 더 실력이 나아질 수 있을까 이런 얘기하고 뭐 마지막에는 저희가 뭐 굳이 말하자면 시니어 개발자니까 이제 비개발자나 주니어 개발자 시니어 개발자 입장에서 어떻게 하면 실력을 점점 더 향상시키면서 AI 시대에 잘 살아남는 개발자가 될 수 있을까? 이런 얘기 많이 해 보려고 합니다.
- - 아 네 너무 깔끔하게 잘 말씀해 주셔서 감사합니다. 그 강의로 단련된 그 목소리가 이제 나오시는 거 같은데 아 제가 너무 죄송한데 자기 소개도 안 하고 이제 시작할 뻔했습니다. 예, 먼저 희동님부터 간단히 자기 소개 부탁드리겠습니다. 네, 안녕하세요. 저는 요즘은 지금은 백수고요. 왜냐하면 지난주 금요일에 저 엑셀레이라는 실리콘 밸리에서 미디어 번역하는 회사에 근무하고 있었는데 지난주 금요일에 퇴사를 했고요. 9월에 코르카라는 이제 문라이트 서비스하는 회사로 가게 됐습니다. 그래서 그 사이에는 뭐 좀 많이 들어온 교육 요청 같은 거 잘 수습하면서 어 제가 만들고 싶었던 AI 앱들 만들어 보면서 뭔가 많이 재밌게 지내볼 것 같아요. 감사합니다. 반갑습니다. 반갑습니다. 네, 오늘 잘 부탁드리고요. 동주님도 좀 부탁드릴게요. 네, 저는 그 백수는 아니고요. 저는 지금 우한 형제들에서 웹 프런트엔드 개발자인데 주 업무가 우한 테크코스라는 개발자들을 위한 부트캠프를 7년째 운영을 하고 있습니다. 그래서 저도 이제 개발자이면서 주 업문의 교육인데 요즘은 사실 뭐 지식 전달은 채찍이나 클로드가 훨씬 더 지금 잘해 주다 보니까 어 뭔가 대체될 수 있는 레거시를 가르치면 안 되겠다 더 의미 있는 성장이나 교육들을 해놔야겠다 이런 고민들 많이 하면서 새로운 실험들 많이 하고 저도 그 이야기하는 거를 말만한 게 아니고 저도 좀 많이 적용해서 이런저런 시도들을 좀 많이 하다 보니까 그런 것들 오늘 또 같이 한번 나눠 볼 수 있으면 재밌지 않을까 싶습니다. 만나뵙게 돼서 반갑습니다. 와, 감사합니다. 이렇게 소개를 두 분 다 말씀들을 너무 잘하세요. 확실히 강의를 찍다 오셔서 그런지 테리 님이 제일 잘하십니다. 아 네, 감사합니다. 저 배달의 민족 어 네 열심히 이용하고 있습니다. 제가 아마 감사합니다. 예, 월급 한 몇 달 몇 달은 제가 드렸던 것 같습니다. 어 어 너무 감사드려요. 제가 돈 버는 팀이 아니어 가지고 테디 님 같은 분들이 많이 계셔야 살 수 있어요. 감사합니다. 알겠습니다. 아, 그리고 또 문나이트에 가셨다고 하는데 문나이트는 저희 이전에도 라이브로 한번 나와 주셔서 저희 문나이트 팀은 정말 너무 따뜻한 팀이고 게다가 너무 똑똑하신 분들이 모여 계신 팀이라서 언제나 이제 마음속으로 응원하고 있는 팀이고 그때 라이브 때 반응도 너무 좋았었거든요. 예, 그래서 어 기대가 되는데 좋은 곳에 가셔서 너무 축하드리고 그렇습니다. 앞으로도 제 소식 종종 듣겠습니다. 아네, 아유 후원금도 이렇게 주셨네요. 예, 아 제가 네 후원금 받아 가지고 좋은 곳에 잘 쓰도록 하겠습니다. 네, 아닙니다. 아, 오 90분 오셨는데 이제 슬슬 어 본 게임으로 들어가 보도록 할게요. 바이브 코딩인데요. 먼저 음, 바이브 코딩 요즘에 어 방법론들 많이 나오고 있는 거 같아요. 이 이 방법론에 대해서 오늘 많이 여쭤보고 싶고 아마 여기 참여해 주신 분들도 그 어떻게 하면 바이브 코딩을 내가 더 잘할 수 있는가 이런 거에 대해서도 많이 궁금하실 것 같은데 그전에 두 분들, 두 분은 바이브 코딩이나 아니면은 코딩을 도와주는 어시스턴트 많이 이용해 보셨으니까 지금의 수준은 솔직히 한 그냥 되게 유치한 질문일 수도 있습니다. 그냥 한 몇 년 차 개발자에 한 몇 % 정도 된다 한 요렇게 표현을 하자면 한 어느 정도 수준에 와 있다고 보세요? 음 동주님께 한번 여쭤 볼까요 먼저? 어 저는 계속 느끼는 게 이제 바이브 코딩으로 특히 이제 프론트엔드가 바이브 코딩으로 대체될 수 있는 게 요즘 너무 이게 발전 많이 돼서 더 많이 느끼고 있는데 한 2, 3년 차 뭐 기술적인 구현이나 뭐 아키텍처나 그다음에 시각적으로 보여지는 것들의 디테일 잡는 것들이 2, 3년 차 개발자의 기술적인 부분들을 거의 많이 따라왔다고 느낄 때 좀 많이 있긴 해요. 물론 실제로는 우리가 소프트웨어는 워낙 복잡한 그런 아이템이다 보니까 여러 협업들이 많이 필요하긴 하지만 기술적인 코딩적인 측면에서 봤을 때는 적어도 한 2년 차 정도는 좀 되지 않나 싶어 가지고. 네, 이게 점점 더 높아질 거잖아요. 그래서 아 뭐가 또 변하고 뭐가 또 변하지 않는 중요한 포인트일지 계속 그런 고민이 많이 되는 거 같아요. 지금 느끼기에는 2, 3년 차 주니어 개발자로서 거의 많이 느껴진 거 같습니다.
- - 아 그렇군요. 휘동님은 어떻게 생각하세요? 저도 한 2, 3년 차 정도인 거 같은데 사실 이게 좀 어려운 게 왜냐하면 뭐 다들 아시겠지만 3년 차 정도 넘어가면 연차가 거의 의미가 없고 이 사람이 얼마나 똑똑하고 그리고 얼마나 커뮤니케이션을 잘하고 학습에 의지가 있고 따라서 실력이 너무 천차만별이잖아요. 그래서 일단 이 친구는 기본은 무조건 돼 있는 친구라서 3년 차는 되는 거 같은데 또 어떻게 보면 기억력이 너무 안 좋기도 하고 어떨 때는 또 어떨 때는 시니어도 모르는 것도 막 다 알기도 하고 그래서 이게 평가하기가 참 애매한데 어쨌든 시키면 시키는 대로 잘 해 주는 편이니까 3년 차는 충분히 된다 이런 생각은 들긴 합니다. 음 3년 차는 충분히 된다.
- - 그러면 두 분께서는 이제 프론트를 많이 개발하셨으니까 그 프론트를 시켜보고 얘가 어느 정도 하는 수준인지 한번 체크업을 해 볼 수도 있을 것 같은데 그 체크업을 했을 때에 그니까 프롬프트를 넣으실 때도 되게 다른 분들이랑 다르게 이미 그 도메인을 잘 알고 계시니까 더 정교하게 잘 넣으실 것 같거든요. 그럼 그 아웃풋에 대한 신뢰도는 예전보다 확실히 많이 올라갔죠. 그렇죠? 음, 그러면은 그걸 거의 수정 없이 바로 써도 될 정도인가요? 만약에 이 프론트에 대해서 잘 아는 사람이 프롬프트를 넣어 준다라고 가정하면은 요즘에 그 정도까지는 올라온 건가요? 음 음, 이거는 뭐 제가 먼저 말씀드려 보면 이게 내가 만들고자 하는 제품이 얼마나 복잡하냐에 따라 좀 다른 거 같은데요. 결국 이제 나 혼자 쓸 제품이면 진짜로 그냥 프롬프트만 채팅만으로도 충분히 쓸 만한 제품이 나오는 거 같고 사실 그거는 뭐 재미니 캔버스 수준으로도 사실 잘 나오니까요. 그런데 다른 사람이 쓸 거면 점점 더 수정이 필요하긴 하지만 그래도 뭐 내 지인들이 쓰는 수준이다 아니면 뭐 API가 간단하게 붙은 거다 정도면 또 그것도 그냥 수정 없이 쓸 수 있는 거 같고. 그런데 이제 점점 스케일이 커질수록 뭐 DB API 다 붙고 아니면 뭐 퍼포먼스가 중요하고 아니면 뭐 보안 중요하고 이렇게 될수록 점점 더 힘들어지기도. 음 음. 동주님께서. 예, 아, 예 말씀하시죠. 네, 그리고 디자인을 엄청 천편일률적으로 하잖아요. 사실 코딩 에이전트 시키면 속내이 다 똑같이 막 알록달록 약간 보라색 느낌. 아, 진짜 짜증나면 좋겠어요. 네, 그래서 그런 거는 좀 더 제대로 시키는 게 좀 필요한 거 같긴 해요. 뭐 이미지 레퍼런스를 준다거나 아니면 뭐 특정 컴포넌트를 따라하게 한다거나 뭐 이런 것들이 좀 필요한 것 같습니다.
- - 동주 님께서 어떻게 생각 어떻게 보세요? 일단 그게 있는 거 같아요. AI가 잘 만들 수 있는 UI들이 있는데 이걸 내 되게 내가 원하는 걸 커스터마이징 하려고 하면은 품도 정말 많이 들고 확실히 노력이 정말 많이 되는 거 같거든요. 그런데 저 같은 경우에는 지금 팀에서 원래 교육할 때 쓰는 LMS가 있는데 이게 옛날에 코드 짠 거여 가지고 레거시 코드가 되게 많아서 이걸 좀 최신 프레임워크로 리팩토링하는 과정을 최대한 바이브 코딩으로 진행을 하고 있거든요. 그래서 이때 저희가 최대한 코드 수정에서 기능 동작 중심으로 가기 위해서 하나 결정한 게 UI는 그 AI가 잘 짜 줄 수 있는 UI 라이브러리를 최대한 활용하기로 좀 정했어요. 보통 뭐 러버블이나 주요 AI 프로토타이핑 도구들이 이제 쉐드 CN이라는 라이브러리 많이 쓰는 아 쉐드 라이브러리게 편한 게 좀 애매인데 쉐드 CNN을 많이 쓰는데 걔가 잘할 수 있는 UI 중심으로 가면 어 거의 의도에서 크게 벗어나지 않고 기존의 동작들이 보장되는 형태로 많이 쓸 수가 있더라고요. 그래서 어 AI가 잘할 수 있는 거를 더 극대화해서 써먹을 거냐 아니면은 새로 내가 추가적인 인풋이나 컨텍스트들을 더 구조화해야 되는 걸 더 많이 하느냐에 따라서 또 난이도가 좀 많이 달라지는 거 같아요.
- - 그래서 저는 이제 원래의 기능이 그대로 잘 동작하고 최신 프레임워크로만 옮기는 게 좀 더 목표이면은 어 다른 뭐 디자인적인 것과 정말 디자인의 협업이나 이런 엄청 중요한 거다 하면 좀 달라지겠지만 그게 아니라 뭐 어드민이라든가 좀 사내에서 쓰는 거다라고 하면은 훨씬 더 좀 쉽게 접근할 수 있는 부분들도 많이 있는 것 같습니다. 음, 아 너무 감사합니다. 저도 와닿는 얘기들이 몇 가지가 바로바로 떠오르는 것들이 있었는데.
- - 그러면 이어서 질문 드려 보면 동주님께 여쭤보고 싶은 게 그러면 이 AI가 잘하는 랭귀지가 있지 않냐라는 얘기들도 요즘에 많이 나오거든요. 그래서 그 그런 것들이 좀 있다라고 보세요? 만약에 있다면은 그 랭귀지나 어 뭐 어떤 프레임워크라고 해야 될까요? 아까 어 또 말씀을 해 주신 거 같은데 그런 것들에 대한 의견을 좀 주실 수 있어요. 어 보통 이제 프런트엔드가 뭐 백엔드는 좀 더 한두 개 거의 이제 뭐 주요 프레임워크만 이게 좀 더 하나에 집중되는 게 많은데 프런트엔드가 이제 약간 전쟁처럼 이것저것 라이브러리나 프레임워크가 진짜 많거든요. 그래서 약간 그 춘추전국시대 같은 느낌이 좀 있는데 어 개발자들의 특성 중에 하나가 뭐 구글 트렌드나 아니면은 뭐 설문조사 같은 거 통해서 기본적으로 사람들이 많이 쓰는 거를 많이 쓰려고 해요. 그래야지 더 수정이나 그게 개선될 확률도 높고 버전이나 이런 것도 더 계속 꾸준히 업데이트되면서 제공될 확률이 높고 그리고 실제로 그런 코드들이 온라인상이나 기타브에도 많이 있다 보니까 그런 것들을 학습했을 때 얘를 또 AI가 더 잘 짤 수 있어 가지고 아마 AI로 인해서 다른 분야도 그렇지만 이 원래 많이 쓰던 게 더 빈익빈 부익부 차가 더 나면서 그런 방식으로 좀 더 양극화가 더 많이 이루어지고 있는 거 같아요. 그 잘할 수밖에 없어서 점점 그렇게 좀 되고 있는 거 같아요. 특히 프런트는 뭐 넥스트 JS나 리액트나 몇 가지 주요하게 많이 쓰는 것들이 있었는데 아마 지금 더 극대화 되고 있는 것 같습니다.
- - 음, 그러면은 아까 여기 댓글에서도 몽키 님께서 되게 좋은 질문 주셨는데, 부트캠프 안에서는 어떻게 가이드 되어지고 있을까요라는 질문이 나올 수밖에 없다라고 보는 게 과거의 부트캠프 방식은 사실 지금 AI가 너무 잘하는 부분들이 많이 있을 거 같아요. 그런 것들을 가르치면 사실 이제 AI가 너무 잘해 버리니까 나와서 이제 이 친구들이 할 수가 없어서 아마 그 교육 커리큘럼 짜실 때도 고민 되실 것 같거든요. 어떻게 보세요? 미쳐 버릴 것 같아요. 그런데 기본적으로 그거는 있는 거 같아요. LM의 특성상 얘가 뭐 웹서칭이나 이런 것들 요즘은 다 해 주긴 하지만 기본적으로 어떤 특정 시점의 스냅 기준으로 거기 있는 데이터를 이렇게 압축된 형태로 가지고서 걔를 훈련시키는 형태잖아요. 약간 최신 정보들에 대해서 부정확하게 알려 줄 때가 좀 많다 보니까. 그런데 개발자들은 좋은 개발자들의 습관 중에 하나가 이 공식문서로 최신 정보를 정확하게 습득하는 습관이 되게 좀 중요하거든요. 그런데 LM이 어떤 특성, 이런 게 좀 거짓 할루시네이션이 생기거나 잘못 정보를 내가 학습하는 게 주니어 때 되게 치명적일 수 있어 가지고 이런 공식 문서나 이런 것들을 요즘은 노트북 LM 같은 거에다가 링크를 공식 문서 링크를 넣어서 본인이 어떻게 하면 좀 더 능동적으로 가장 최신의 정확한 정보를 학습하는 데 쓸 수 있을지 그래서 AI를 일부러 좀 더 제한을 둬서 본인이 학습에 더 도움되는 방향들이나 방식 더 많이 좀 고민해 보고 저희도 좀 시도를 해 보고 있거든요.
- - 그래서 지금은 주로 많이 했던 게 뭐 공식 문서 같은 것들 보면서 최대한 이게 무슨 의미일지 보통은 바로 채찍이 그냥 따닥 치는데 무슨 의미일지 추론을 먼저 하게끔 해요. 그냥 본인이 알고 있는 모든 지식을 총 동원해서 어 추론을 먼저 해 보기에 노트북 LM에 그 공식 문서 넣은 걸 통해서 본인이 추론한 거랑 비슷한지 맞는지 틀린 건 없는지를 좀 비교하고 검증하는 걸 토대로 계속 훈련을 좀 해 가지고 생각하는 사고의 힘을 더 기르는 거에 좀 집중을 하고 있어요. 그래서 이게 길러져야 새로운 지식들이 계속 나왔을 때도 본인이 그 고차원적 추론할 수 있는 사고 방식으로 지식들을 지득할 수 있을 거라고 생각을 하기 때문에 그런 부분들을 어떻게 보면 좀 되게 옛날에 할 법한 방식이지만 최신 AI 도구들을 이용해서 하는 것들을 좀 실험적으로 해 보고 있죠. 음, 그러면은 지금 만약에 부트캠프에 오시는 그 주니어 레벨들한테 그 지금 방금 말씀하신 그런 방법론들을 많이 알려 주고 계세요? 지금 그렇게 계속 훈련을 하고 있고 그래서 그 이제 추론하는 거를 가추법이라 하거든요. 어떤 그럴 듯하게 한번 설명해 보고 실제 검증해 보고 이거를 지금도 계속 교육 과정에 녹여내서 진행을 하고 있고 항상 뭔가 지식을 설명하기 전에 이거 어떤 의미일지 추론하는 시간을 항상 가져요. 저희는. 음, 그렇게 추론을 하고 나서 그다음에 제가 뭐 설명하거나 아니면 채찍이한테 물어보면 본인이 그걸 비교하면서 머릿속에서 연산하고 한 번 더 머릿하게 되니까 기억에 더 잘 남게 되더라고요.
- - 음, 아 그러면 하나만 더 여쭤보고 희동님께 넘어가도록 할게요. 하나만 더 여쭤보고 싶은 거는 저희 또 팀내 이제 개발자분들 계신데 그 친구들이 새로운 프레임워크를 익힐 때 처음에 AI의 의존도를 높여 가면은 자꾸만 의존도에 높여가고 이제 내가 생각할 시간이 줄어들어서 결국에는 AI가 짠 코드를 내가 이게 맞느냐 안 맞느냐 이거를 분간하는 게 판단 내리는 게 되게 중요한 역량으로 보여지는데 그런데 그런 역량들을 처음에 AI 의존성 이렇게 가져가면은 좀 뭐라고 할까 뭐 편협하다고 얘기를 해야 될까요? 좀 그런 방향으로 가게 될까 봐 일부러 AI 끄고 그냥 최대한 내가 해 보고 부딪쳐 보고 그다음에 이제 말 그대로 납기일이 도래를 했을 때는 좀 바이코딩 도움을 받고 뭐 이렇게 하는 게 주니어 단계에서 더 좋다 이런 의견도 있는 거 같아요. 그래서 혹시 동주 님께서는 어떻게 보세요? 그러니까 뭐 그냥 유치하게 이것도 유치하게 그냥 1번 2번으로 나누어 나누어서 질문을 드리면 1번은 어 AI 기능을 주니어 레벨 때 뭐 최대한 제한해 뭐 진짜 모르는 게 있으면은 채찍피한테 물어봐. 하지만 네가 혼자 그게 맞는 방향이 아니더라도 깨지든 뭘 하든 일단 AI 기능 다 빼고 너 역량 1년이든 2년이든 키우는 게 중요해. 와 아니지, 그거는 이제 시대와 맞지 않지. 그냥 AI 쓸 수 있는데 왜 그걸 제한해? 그냥 받으면서 너 하면서 그 AI 도움 받으면서가 괜찮아. 어차피 우리 앞으로 AI랑 같이 살 거니까 그거 활용하는 스킬을 업하는 것도 중요한 역량이야. 요런 파가 약간 크게 보면 또 둘로 나뉘는 거 같거든요. 그냥 개인적인 의견이 좀 궁금하기도 합니다.
- - 어 사실 여기에 뭐 정답은 아직 아무도 모르잖아요. 그래서 두 가지 시도 계속 많이 하고 있는 거 같아요. 그래서 일부러 어떤 때는 AI를 제한하고 혼자만의 어떤 추론이나 사고로 짜는 것도 하고 AI를 더 적극적으로 좀 쓸 때도 있긴 한데 저는 약간 요거에 대한 힌트를 바둑 쪽에서 좀 가져와서 저도 좀 적용을 해 보려고 하거든요. 아마 여기 계신 분들도 많이 아시겠지만 우리가 알파고가 이세돌을 이기고 나서 한 10년 넘게 바둑계는 AI로 인해서 변화가 굉장히 크게 일어났잖아요. 그래서 지금 세계 최정상권에 있는 바둑 기사들은 AI가 둔 수를 그 의도들을 한번 추론하고 분석하면서 연구하고 AI처럼 두려고 하는 것들을 많이 훈련을 하시더라고요. 그래서 어차피 코드 자체는 이제 AI가 많이 짜 준다는 거는 이제 좀 분명한 거 같아서 좀 더 그니까 중간 지점으로 뭔가를 진행한다고 했을 때 어 AI가 짜 준 코드를 그니까 리버스 엔지니어링 어 왜 이렇게 짜였을까? 어떤 형태로 짜였을까? 어떤 구조로 되어 있는가? 이거를 분석해 보는 거를 오히려 좀 더 실험적으로 많이 시도를 해 보고 있어요.
- - 그래서 저도 개인적으로 어 이런 실험을 좀 많이 해 보고 AI가 잘 짜 주는 구조를 알아야 그거를 내가 더 잘 써먹을 수 있을 것 같아서 어 한번 이제 저의 개인 프로젝트를 했던 게 바이브 코딩으로 100개의 앱을 만들어 보기였거든요. 그래서 막 같은 앱도 막 다섯 가지 막 일곱 가지 버전으로 만들어 보고 하면서 아 어떻게 좀 더 컨텍스트나 구조를 했을 때가 더 잘 짜 주고 이런 구조가 이렇게 나오니까 어 다음에도 이런 식으로 비슷하게 짜 주겠구나 내가 이렇게 좀 예측하고 컨트롤 할 수 있게끔 해서 지금은 뭐 어떤 한 방향이 막 반드시 정답이다라고 하긴 어려우니까 다 시도해 보되 대신에 내가 잘 만든 거는 리버스 엔지니어링 해서 어떤 구조와 어떤 아키텍처로 되어 있는지 본인이 그거는 설명할 수 있어야 된다라고 생각해서 그런 부분들을 좀 교육 과정들에 이제 녹여 보려고 하고 있어요. 또 지금 학생분들이 프로젝트 하는 기간인데 이 프로젝트를 할 때 AI의 사용에 제한을 안 두고 쓸 수 있게끔 가이드하고 있거든요. 그리고 이제 너 AI가 또 코드를 많이 짜 줬을 텐데 하지만 엔지니어니까 이게 어떤 결함이 있거나 또 수정하거나 유지 보수할 때 어떤 구조로 되어 있고 어떻게 얘를 더 확장해 나가야 될지 그에 대한 방향성은 사람이 더 잡을 수 있어야 되니까 바둑 기사들도 결국엔 AI 의도는 알아채지만 뭐 연구하지만 본인이 또 수를 둬야 되는 것처럼 그런 부분은 약간 바둑에서의 어떤 메타포를 가져와서 프로그래밍에도 좀 적용해서 좀 시도를 해 보고 있습니다.
- - 아 네, 아 그 바둑의 비유를 드신 게 저는 개인적으로 많이 와닿던 거 같고 요거에 대해서도 제가 궁금한 게 너무 많은데 이따가 한번 더 여쭤보도록 하겠습니다. 어 희동님 오래 기다리셨는데 희동님께도 비슷한 질문을 드려보고 싶어요. 그러니까 주니어 레벨에서 주니어뿐만 아니라 사실 이제 어 뭐 시니어도 지금 할 말이 많습니다만 먼저 이제 주니어부터 문제를 풀어보면은 주니어들의 고민은 이거거든요. 뭐 지금 부트캠프든 아니면 학교들 뭐 석사를 하신 분이든 간에 어 이거 내가 지금까지 엄청나게 고비용을 내서 배웠는데 이게 다 AI가 너무 잘해 버리고 그러면은 내가 설 자리가 있을까? 이런 고민들을 많이 하게 되면서 어 고민은 그러면은 우리가 어차피 AI가 지금 아직 부족한 부분은 이 최신 기술을 적용하는 거예요. 아무래도 이제 학습하는 기간이 걸리다 보니까 그런 것들은 잘 안 된단 말이에요.
- - 그러면은 이제 어 이 주니어 개발자의 입장으로서 어 아까 제가 똑같은 질문을 드려 볼게요. 어 먼저 성장을 하기 위해서 좋은 개발을 성장하기 위해서 어 1년 차 2년 차 때에는 AI 기능을 최대한 스스로 제한을 하고 뭐 스택 오버플로우 보거나 아니면 필요하다면 뭐 채찍이한테 물어보거나 이런 방식을이 좀 어 성장적인 측면에서 도움이 된다고 보시는지 아니면은 아까도 말씀드린 것처럼 다양한 툴들을 온갖 종합해서 그 프로덕션 그러니까 그 생산성을 끌어 올리는 것도 역량으로 보기 때문에 지금은 시대가 바뀌었고 그거에 어 주안점을 둬서 그 AI랑 같이 활용을 키우면서 가는 것도 괜찮다라고 보시는 건지 그 의견부터 먼저 한번 여쭤보고 싶습니다. 저는 단적으로 2번이라고 생각하고요. 그 왜냐하면 그 제한을 일부러 둔다고 한들 뭐 나 빼고 다 달려가고 있는데 그걸 따라가지 않을 수도 없고. 그리고 제한 예를 들면 뭐 교사로서 학생에게 너 쓰지 마라고 하면 집에 가서 안 쓸 거냐 뭐 폰으로 안 쓸 거냐 하면 무조건 쓸 거란 말이에요. 그래서 걔를 일부러 막을 수도 없는 거 같고 오히려 이걸 더 잘 쓰고 더 적절하게 쓰는 방법을 알려 줘야지 전 더 좋은 거 같아요.
- - 저는 AI 나오고 나서 너무 좋은 게 이제 공부하는 게 너무 좋아졌거든요. 쉬워지고 뭐 노트북도 있고 딥 리서치도 있고 그런 것들을 그러니까 저는 약간 주의해야 되는 게 커서나 클로드 코드에게 코드 맡기고 그냥 기다리는 이런 거는 정말로 그런 건 제한을 좀 해야 되는 거 같고. 그 전에 뭐 구글 AI 그 그니까 제미니나 뭐 최지피티나 그로이나 이런 애들이랑 충분히 토론을 하고 얘가 어떤 코드를 제시하면 왜 그게 이렇게 나왔는지 아까 동주님 얘기해 준 것처럼 너는 왜 이렇게 만들었어? 이렇게 물어보고 얘가 잘못한 거 같으면 야 잘못됐어가 아니라 내가 보기엔 이런 신호 때문에 이게 잘못된 거 같은데 너 왜 이렇게 짰냐? 이렇게 물어보면서 점점 더 얘랑 협업하는 방법도 많이 배우고 이렇게 학습한 AI를 최대한 쓰면서 나아가면 좀 좋지 않을까 이런 생각을 많이 합니다.
- - 음, 그러면 이건 그냥 다른 질문 한번 드려 볼게요. 만약에 휘동 님께서 이제 스타트업의 대표가 되셨습니다. 회사를 차리셨다고 가정을 해 볼게요. 그래서 프로덕션을 내야 되는데 이 주니어 개발자가 한 달이라는 시간을 줄 겁니다. 그런데 1번은 그 한 달이라는 기간 동안 어 그 원하시는 기능의 어를 다 충족하면서 어 내긴 냈어요. 하지만 이 친구는 그 코드에 대한 공부는 하지 않지만 일단 원하시는 요구 사항은 다 충족을 하게끔 어떻게든 만들어 내는 친구가 있고요. 아니면 2번 친구는 아, 이 친구는 한 달이라는 기간 안에 한 50%의 기능 구현을 했습니다. 하지만 그 50% 기능 구현 하는 동안 그 코드에 대해서 이해를 하면서 간 친구예요. 그러면 어떤 분을 뽑으실 것 같으세요? 아, 꼭 한 명을 골라야 되나요? 둘 다. 둘 다 싫은데요, 사실. 아, 아, 아, 둘 다 싫다. 네, 네. 아, 왜냐하면 사실 둘 다 해야 된다고 생각해요. 일단 한 달 동안 만드는 것도 잘못됐고 요즘은 거의 뭐 일주일만 만들어야 될 것 같고. 아, 예, 일주일 동안 만들고 다시 그걸 또 만들고 또 만들고 깨지고 하면서 한 달 동안 한 네 번 만들면서 학습을 해 나가고 점점 더 괜찮은 코드를 만들고 하는 사람을 뽑을 것 같아요.
- - 음, 그러면 그럼 질문을 좀 바꿔서 만약에 그렇게 깨지고 깨지고 다시 만들고 하는 과정에서 이 친구가 어떻게 뭘 배워야 될까요? 그러니까 어떻게 배울 수 있어요? 그게 사실 아까 그 동주 님이나 그 테디 님도 말씀하시는 거랑 비슷할 수도 있는데 그니까 저는 그 엔지니어의 어떤 성장 흔히 티자라고 하잖아요. 그러면 이제 양파를 벌리는 쪽이 있고 좀 아래쪽으로 깊게 가는 쪽이 있는 거 같은데 저는 뭐 그 둘 다 하면 더 좋겠지만 그 둘 중에 하나라도 엄청 잘하면 되는 거 같아요. 뭐 내가 물론 주니어가 아래쪽으로 깊게 가는 게 어려울 수 있겠지만 나는 뭐 애니메이션 진짜 기깔나게 해 보겠어. 나는 트랜지션을 정말 정말 멋지게 만들어서 CTA에 그니까 콜 투 액션의 전환율을 엄청나게 끌어올리겠어. 이런 쪽으로 뭐 가든 아니면 뭐 나는 성능에 올빵 해 가지고 예전에 500밀리 세컨드 걸리던 거 100밀리세컨드 만들까? 뭐 이런 식으로 가든 뭐 그렇게 팔 수도 있고 아니면 나는 프론트엔드 엔지니어로 들어왔지만 백엔드도 하고 인프라도 하고 디자인도 하고 기획도 하고 나는 운영도 다 할 거야 뭐 이런 식으로 갈 수도 있고. 그렇게 좀 확장을 밑으로 밑으로든 옆으로든 하는 사람이 훨씬 앞으로 더 잘하지 않을까. 그리고 그거를 각 그런 것들도 AI가 정말 잘 도와줄 수 있다. 그 모든 과정을 이런 생각을 좀 하고 있습니다.
- - 그렇군요. 아, 답변을 너무 잘해 주셔서 너무 감사합니다. 제 중간에 이렇게 질문드리느라 몰입해 가지고 어 150명이 벌써 와 주셨는데 네 댓글 남겨진 걸 좀 읽어 보면서 두 분께 좀 질문 좀 드릴게요. 어 아까 부트캠프 아, 아 이거 회식이신데 오신 분들 계시고 아 태 님께서 게임 쪽 시쁠쁠은 LM만 한 게 많이 느껴 이런 피드백 많이 봤거든요. 시쁠쁠 언어 같은 경우에 특히나 이제 자바 랭귀지도 우리나라는 또 자바 빼놓고 개발 얘기할 수가 없을 것 같은데 그런 쪽에서도 조금 아쉽다라는 평가 나오 랭귀지나 프레임워크별로 확실히 그런 피드백이 있는 거 같아요. 이렇게 말씀해 주셨고. 어 어 제가 그 다음 주에 그 토비 토비 님하고 식사하기로 했거든요. 아, 그래서 토비 님한테 한번 여쭤 볼게요. 자바 쪽 과연 한계인 아닙니다.
- - 아 제 오늘 저도 질문 받은 것 중에 하나가 이거 자바 얘기 나와서 하는 건데 자바 평생 자바 개발자로 살아오신 분들이 어 이분들이 이제 AI 하려고 보니까 코드가 파이썬이나 아니면 뭐 자바스크립트 이쪽으로 이제 많이 짜여 있잖아요. 그래서 이분들의 이제 고민이 우리 회사에서 이분들이 이제 파이썬을 배워서 이렇게 하기에는 좀 어려움이 있는데 혹시 이런 분들을 위해서 현실적인 조언을 좀 해 주실 수 있어요? 음, 저는 물론 저 저는 그 백엔드는 거의 레일즈밖에 안 해 봐 가지고 사실 잘 모르겠지만 저는 그 컨텍스트 엔지니어링 그 어떻게 보면 컨텍스트 엔지니어링하고 흔히 여기 좀 얘기하는 컨텍스트 잘 주고 그리고 진짜 저 시니어 개발자들은 어떻게 개발하는지에 대한 어떤 그 그런 뭐 인지 작업 분석 같은 걸 잘 해 가지고 먹이면 전 못 할 게 정말 없다고 생각하거든요. 그래서 예를 들면 이분이 자바로 잘 짜는 것도 할 수 있고 이분이 파이썬 개발자로 전향하는 것도 얼마든지 할 수 있지 않을까 약간 너무 책임 없는 발언일 수도 있는데 그런 생각도 들어요. 사실 제 친구도 이제 레일즈 쪽으로 좀 오래 판 친구인데 요즘 또 레일즈가 AI 시대 좀 더 다시 좀 뜨고 있잖아요. 저는 좀 어떻게 보면 파이썬 대비 레일즈는 예를 들면 뭐 뭐 AI 스크립트 만드는데 루비를 쓰진 않을 거잖아요. 그 레일즈는 사실은 어떻게 보면 딱 집중된 웹을 만드는데 많이 쓰인 코드들을 많이 학습했을테니까 오히려 퀄리티가 좋은 거 같다 이런 얘기 좀 했었거든요. 그니까 자바도 뭐 자바로 제 잘 모르지만 쓸데없는 거 많이 안 짤 것 같은데 어플리케이션 코드로 많이 학습됐으니까 이거를 잘만 조절을 하면 잘하지 않을까 이 정도 생각은 좀 가지고 있어요.
- - 음 음. 이분들이 고민이 뭐냐면은 뭐 파이썬으로는 오픈 소스가 많이 나와 있으니까 이걸 참고해서 개발은 속도가 붙는데 이제 자바 레퍼런스가 많이 없다 보니까 그것 때문에 많이 공 고민을 하시는 거 같아요. 그래서 아까 휘덕 님께서 추천해 준 거는 이제 이분들이 자바를 뭐 바이코딩을 도움을 받던 아니면은 빠르게 배우시던 해서 쉽게 전향을 하실 수 있다라고 말씀을 해 주시기도 하는데 그런데 이게 자바 코드로 구축을 오래 하신 분들은 대부분 기업의 어떤 그 되게 탄탄한 어떤 그 어떤 조직 안에서 어떤 시스템을 만드는 코드다 보니까 아직까지는 바이브 코딩으로 뭔가 MBP 만들고 빠르게 속도적인 측면에서 분명한 이득은 있지만 그 안정성에 대해서는 그니까 본인 스스로 납득이 아직 안 되시고 신뢰도 많이 좀 떨어져 있는 거 같아요 지금으로서는. 그래서 이분들이 많이 고민을 하신 거 하시고 계신 거 같다라는 생각이 많이 듭니다.
- - 동주 님께서 혹시 의견이 있으세요? 혹시 질문 한 번만 더 제가 채팅 답변 질문 조금 놓쳤습니다. 네, 이 이 질문은 요지는 뭐였냐면 이제 우리나라의 자바 개발자분들이 되게 많으세요. 그런데 저한테도 이제 개인적으로 질문 많이 주시는 게 이제 인공지능을 해 보려고 들어왔더니 자바 랭귀지로 되어 있는 건 많이 없고 오픈 소스들이 다 파이썬이나 아니면 자바스크립트 중심으로 많이 이루어져 있다 보니까 이분들의 고민은 내가 서비스에 이제 인공지능 도입할 때 그러니까 1번은 뭐 내가 파이썬을 배워서 다시 처음부터 배워서 이걸 가지고 오픈 소스에 그 도움을 받아 가지고 개발하는 방법이 있을 것이고 아니면 2번은 뭔가 자바로 내가 한다마다 다 짜서 뭐 하는 방법도 있을 것일까 아니면 기타 등등의 방법들이 있을 것 같은데 그 부분에 대해서 어떻게 하면 좀 효율적일까? 그 개인적인 의견이 궁금했었습니다.
- - 결국 그 팀이나 회사에서 뭐가 중요하느냐에 따라서 많이 다르지 않을까 싶긴 하네요. 이게 이미 뭐 대규모 프로젝트로 구성이 돼 있는 거다 하면은 사실 그걸 잘 유지보수하는 게 또 중요하니까 그러면 막 섣불리 또 AI를 막 도입하려고 하는 게 오히려 더 서비스의 어떤 불안정성을 높이고 일부러 더 힘들게 가는 방향이 되다 보니까 오히려 막 기존 서비스는 최대한 그대로 두고 신규 서비스를 AI로 잘 활용할 수 있는 걸로 한다든가 그거는 그 팀과 회사의 상황에 따라서 너무 다를 거 같기는 해요. 저도 그거도 뭔가 딱 제한하기가 좀 어려운 부분이 있지 않을까 싶긴 하네요. 그래서 AI 하나 생각난 게 있습니다. 네, 결국 이게 문제가 AI 도입을 하려고 하는데 그 좋은 코드를 AI에 못 짜서 고민인 거잖아요. 결국에 사실 이런 고민인 거 같아요. 우리 회사 시스템이 코드 사이즈가 엄청 큰 거죠. 그 아키텍처도 몇십 년 동안 갈고닦아서 일단 탄탄하고 잘 돌아가요. 그런데 만약에 리더십에서 어 이제 AI 우리 시스템에 도입하자 했을 때 이제 자바로 다 구현되어 있는 어떤 소프트웨어에 AI를 얹으려다 보니까 거기서 오는 고민이 분명히 있으신 것 같습니다.
- - 음, 그니까 저는 제가 그 토비 님하고 조금 얘기하다 보니까 어 저는 정말 자바 진짜 모릅니다. 그냥 다 헛소리일 수도 있어요. 그런데 어쨌든 어 여전히 결국 좋은 예제랑 그니까 좋은 코드를 잘 먹여 주면 그니까 어떻게 보면 레그랑 비슷할 수도 있겠죠. 뭐 잘 먹여 주면 그것 그거를 이용해서 얘네가 그 예제를 가지고 코딩을 하면 진짜 잘한다 이런 얘기를 들었던 거 같거든요. 그게 뭐 사실은 꼭 자바뿐만 아니라 뭐 타입스크립트든 사실 어떤 코드든 비슷할 거 같고.
- - 그러면 그런 전문가들이 컨설팅 해 주는 게 한 번씩 한 번씩만 들어가서 어 어떤 템플릿 코드들을 잘 만들어 주고 그 템플릿으로 시작하게 하면 그러면 AI 도입이 좀 더 쉬워지지 않을까 이런 생각이 좀 드네요. 음, 그 저도 하나 생각이 나서 좀 덧붙이면은 결국 이미 기존에 있던 코드들이 막는데 얘를 AI를 도입하는 것 중에 두려움이 생기는 중요한 포인트 중에 하나가 기존 동작들이 많이 깨지거나 그걸로 인해서 예상치 못한 사이드 이펙트가 생길까 봐에 대한 두려움 때문에 더 고민되는 포인트들이 항상 많은 거 같아요. 그래서 저도 지금 팀에서 레거시 코드를 어 프레임워크를 바꾸면서 그래서 가장 먼저 한 게 테스트 코드를 먼저 다 작성을 했거든요. 그래서 그거는 팀원들이랑 인간 지능을 이용해서 어떤 기능들이 동작되는지 검증돼야 되는지 확인하기 위한 테스트 코드를 먼저 짜고 그다음에 그게 코드를 이제 한 뭐 한 스텝씩 수정되거나 리팩토링 할 때마다 기존 테스트 코드 다 돌아가는지를 계속 체크를 하고 있어요.
- - 그래서 아마 백엔드 쪽은 테스트 코드 문화가 프론트엔드보다 좀 더 잘 정착되고 되어 있긴 하지만 만약에 그런 테스트 코드가 좀 없는 상황이다. 그런데 좀 사이즈가 크다 아니면 테스트 코드가 좀 꽁 이제 촘촘하게 커버리지가 높지 않다라고 하면은 AI로 기존 코드 기반으로 테스트 코드를 짜고 그다음에 기존 동작들이 잘 동작된다라는 그 보장을 내가 가지고서 코드를 수정하고 AI를 도입하면은 훨씬 더 좀 두려움을 줄이고 또 시도해 볼 수 있는 것 같긴 해요. 음 음, 좋은 말씀이신 거 같고요.
- - 저도 저도 이제 덧붙이자면은 저는 이거를 실제로 좀 경험을 했거든요. 어디서 경험을 했냐면 저는 프론트엔드를 잘 모르는데 제 저는 원래 그런데 첫 커리어 시작은 아이러니하게 이제 프론트엔드 저는 앱 개발자 안드로이드 앱 개발자로 시작을 했었어요. 그래서 했었는데 어쨌든 지금은 웹은 잘 모릅니다. 넥스트나 이런 쪽은 잘 모르는데. 그런데 문제는 우리가 백엔드를 하다 보면 이제 앞에 래핑을 해서 나가 나가서 이제 MVP로 보여 주고 싶을 때가 있어서 이제 프론트 바이브 잘 되니까 대충 아키텍처 어 배운 지식을 바탕으로 해서 되게 그럴싸하게 나왔고 말씀해 주신 것처럼 테스트 코드 최대한 촘촘히 또 짜 달라고 하면 다 짜 주잖아요. 그래서 커버리지 해 가지고 어 프론트엔드 만들었어요.
- - 그런데 프론트엔드도 욕심이 나니까 이제 점점 사이즈가 커지는 거죠. 그런데 여기서 이제 오동작은 아니에요. 뭐 원하는 바대로 다 동작이 되는데 저 프론트 코드 모르지만 이런 생각이 들 때가 있는 거예요. 어 나는 완전 그냥 블랙박스인데 일단 AI로 해서 뭐 일주일 만에 프론트 찍어 냈어. 그런데 내가 이거 진짜 신뢰해도 돼? 약간 이거 아키텍처 내가 더 개선해 보고 싶은데 아키텍처에 대한 지식도 없잖아요. 그러니까 내가 이거 어떻게 아키텍처 가면 더 좋을까? 그니까 되게 막막해지는 순간들이 오더라고요. 그니까 겉에 보면은 오동작 없고 다 잘 동작해요. 그런데 내 눈에는 좀 더 느려 보이고 더 개선할 리팩토링을 시키고 싶은데 어 그런 부분들이 조금 막막해지는 순간들이 오더라고요. 그래서 뭐 말씀드린 것처럼 기능이 작고 마이크로소피스로 이렇게 다 잘 분리가 돼 있고 그럴 때에는 문제가 안 됐던 거 같은데 나중에 이제 조합이 돼서 아키텍처적인 고민을 해야 되는 시점에서는 그 랭귀지 그냥 랭귀지 자바라는 단순하게 랭귀지가 아니라 어떤 프레임워크를 쓰게 되면은 그거에 대해서 사상에 대해서 깊게 이해하지 않으면 아 이게 보안의 허점이 언젠가 뚫릴 수도 있다 이런 불안함 때문에 아 상용으로 넘어가는데 굉장히 큰 제약이 있는 거를 많이 경험을 했었습니다. 예, 그래서 아 그랬었어요. 예, 개인적으로 그렇더라고요.
- - 그래서 어쨌든 두 분의 좋은 의견 너무 감사드리고 아까 댓글을 읽다가 또 딴 길로 샜네요. 예, 이러다 보면은 벌써 40분이 지났는데 예 이렇게 되는 겁니다. 제가 어 아 휘동님이 이야기해 주실 것 같긴 하지만요 하시면서 부트캠프에서 AI를 잘 쓰도록 가이드하고 피드백을 활용할 수 있도록 할 수 있는 분들이 거의 없을 것 같아요. 동주 님이라면 구성원들이 AI를 잘 쓰기 위해서 어떤 한계적 접근을 하시나요? 라고 주셨네요. 그 한계적 접근이라는 게 어 구체적으로 뭔 뭔지 정확하게 모르겠으나 일단 이 동주님께 먼저 여쭤보면은 구성원들이 AI를 잘 쓰기 위해서 어떤 방법론이라고 해야 될까요? 그런 것들 뭐 시도하고 계신 것들 있는지 궁금합니다.
- - 요거를 잠깐 제가 화면을 공유해서 이야기하면 좀 좋을 것 같아서 그 뭐 코드 레벨도 있겠지만 기본적으로 아까 그 테디 님이 말씀해 주신 것처럼 우리가 뭐 아키텍처나 이런 뭐 큰 구조를 또 이해하고 학습해야 되는 경험들 너무 중요하잖아요. 네, 그래서 기본적으로 학습하기 위해서 우리가 머리를 쓰고 추론하고 하는 능력들을 계속해서 좀 훈련하고 연습하기 위해서 주로 이제 가장 기본적으로 하는 게 아까도 이야기한 저 공식 문서를 굉장히 이제 능동적으로 읽는 건데 어 우리가 이제 궁금한 게 있으면 이제 채찍이가 너무 잘 답변을 쉽게 쉽게 해 주다 보니까 읽는 거를 생각보다 능동적으로 읽는 친구들이 많지가 않더라고요. 처음부터 능동적으로 읽는 게. 그래서 제가 읽기를 잘한다라는 게 뭘까? 왜냐하면 결국 개발자도 코드를 읽어야 되다 보니까 읽기를 잘한다는 게 뭘까를 이제 팀 리서치를 통해서 이제 분석을 해 봤어요. 그래서 딥 리서치로 이제 읽기에 대한 논문들 찾아보고 딱 한 줄로 딱 정리를 하니까 요렇더라고요. 읽기는 이제 의미를 내가 구성을 하면서 독자가 능동적이 된다. 그래서 얼마나 능동적이고 얼마나 의미를 구성해야 되는지 그거가 생각보다 훨씬 더 훨씬 더 능동적이고 훨씬 더 의미를 구성해 봐야지 읽기가 더 잘되더라고요.
- - 그래서 이제 예를 들어 이게 또 설명만 하면 저 막연하니까 간단하게 그냥 예시를 뭐 보여 드리면 요걸로 하는 게 낫나 요게 아마 같이 더 이해하기 쉬울 것 같아서 지금 다 화면 잘 보이시죠? 잘 보입니다. 그래서 예를 들어 요 프롬 이제 엔트로픽의 프롬프트 엔지니어링 공식 문서인데 우리가 뭐 프롬프트 엔지니어링 뭐 템플릿 같은 것도 많이 찾아보고 복사하고 하는데 프롬프트 엔지니어링 자체를 잘하기 위해서 이 공식 문서를 읽는 학생분들은 또 많이 없더라고요. 네, 어떻게 보면 이게 엔트로픽에 정말 수억원대 연봉을 받는 프롬프트 엔지니어들이 쓴 되게 비싼 문서인데 이게 무료로 제공되다 보니까 그 가치를 잘 못 느끼는 거 같아서 요런 것들도 일부러 같이 읽는 시간을 막 가져 보거든요.
- - 그런데 아까 읽기를 잘하는 거 핵심이 의미를 구성하고 능동적으로 의미를 구성해야 된다 있었으니까 그냥 쭈르륵 막 읽는 게 아니고 의미를 구성하면서 굉장히 능동적으로 읽어 보는 거예요. 그래서 예를 들어 프롬프트 엔지니어링 개요라고 돼 있는데 어 그냥 프롬프트 개요가 아니고 프롬프트 엔지니어링 개요라고 돼 있는 건 뭘까? 프롬프트라는 단어는 무슨 의미가 있지? 엔지니어링은 무슨 의미가 있지? 능동적으로 의미를 막 구성해 보는 거예요. 프롬프트란 단어가 뭔가 촉발하다 유발하다라는 의미가 있더라고요. 저도 찾아보니까. 아 뭔가 AI로부터 뭐 촉발하고 유도하는구나.
- - 그런데 엔지니어링은 또 뭘까? 그니까 엔지니어링은 뭐 구조하고 체계화해 테스트 가능하게 만들고 결과를 컨트롤할 수 있게 만들고 예측 가능하게 만드는 그런 의미들이 포함돼 있단 말이에요. 그 아, AI로부터 답 무언가 결과물들을 이제 추론하거나 이제 유도하거나 이제 이끌어내는데 그 결과물이 예측 가능하게 만들고 컨트롤 가능하게 만드는 게 바로 프롬프트 엔지니어링이 아닐까? 이런 걸로 한두 문장 가지고 진짜 능동적으로 의미를 막 구성하면서 대화를 해 보는 거예요.
- - 그러면 영주님 이런 것도 할 수 있지 않나요? 왜 하필 왜 하필 엔트로픽이 이 문서를 만들었을까? 어 좋죠. 그런 포인트도 너무 좋죠. 사람들이 프롬프트를 그냥 장문으로 그 그냥 너무 말하듯이만 쓰니까 얘를 더 체계적으로 했으면 해서 쓴 게 아닐까? 엔지니어링적인 관점으로 프롬프트를 바라봐줬으면 해서 그런 게 아닐까? 아니면 엔트로픽은 프롬프트를 정말 엔지니어링 관점에서 얼마나 잘하는지 자랑하려고 이걸 쓴 걸까? 그런 것들을 추론해서 보면은 이 문서 안에서 한두 단락만 읽어도 학습이 많이 일어날 수밖에 없거든요. 처음부터 그러면 너무 지치지 않을까?
- - 그런데 오히려 이렇게 읽으면 더 몰입하게 되고 대화를 많이 하게 돼서 기억이 엄청 잘 남게 돼요. 다 읽는 게 목표가 아니고 조금 읽더라도 깊이 있게 읽는 걸 목표로 하거든요. 왜냐하면 큰 구조나 그런 내가 깊이 한번 파고드는 거 한번 할 수 있으면 이 문서들 중에서 한두 페이지만 읽어도 중요한 것들을 다 얻어갈 수 있기 때문에.
- - 그래서 요렇게 한번 추론해 보고 나서 그다음에 이제 여기까지만 볼게요. 프롬프트 엔지니어링 전이라고 돼 있어요. 어 프롬프트를 그냥 쓰기 쓰는 게 아니라 그 전에 무언가를 하는 게 되게 좀 중요한가 보다. 그래서 이 프롬프트 엔지니어 개요에 이걸 프롬프트 엔지니어 전에 뭔가를 생각해 보라고 이걸 전제로 한다고 세 가지를 이야기를 하네. 어 그러면 앞으로 있는 예시들이나 목차들을 볼 때 요 세 가지가 좀 되게 중요할 수 있겠다. 그래서 보니까 사용 사례에 대한 명확한 성공 기준 정의. 내가 쓴 프롬프트가 성공적으로 동작했다면 어떤 결과물이 나와야 되는가에 대한 정의를 내가 인식하거나 체크할 수 있게끔 생각을 해봐야 되는구나. 그냥 쓰고 결과물을 잘 나와라고 기도하는 게 아니라 성공 기준을 내가 정해야 되는구나. 그리고 해당 기준에 대해서 경험적으로 테스트할 수 있는 방법. 엔지니어링이니까 반복 가능하게 테스트해서 품질을 좀 높일 수 있게 어떻게 여러 번 테스트할 수 있을까? 이 문서에서는 이런 테스트 방법으로 어떤 걸 제공할까? 수억 원의 연봉을 받는 엔지니어들은 어떻게 테스트를 할까? 전문가들이니까 그들은. 그리고 개선하고자 하는 초기 프롬프트 초안. 어 일단 뭐 생각나는 걸 쓸 수도 있는데 내가 프롬프트 엔지니어링하기 전에 어떤 의도로 무엇을 만들기 위한 그 초안을 어 처음에 좀 세팅하거나 좀 템플릿화하거나 구조화를 간단하게로 해 놓는 게 어 프롬프트 엔지니어링하기 위한 좀 준비가 되는 상태인 거구나.
- - 아, 그러면 앞으로의 문서들에 대한 설명들도 이 세 가지 관점들이 어떻게 녹아들어 있는지 봐야겠구나를 한 단락만 읽어도 이 전체 문서에서 큰 구조나 접근하기 위한 방식들을 물론 틀릴 수도 있겠죠. 그런데 읽어 보면서 우리는 비교하고 검증해 볼 수 있으니까 큰 구조를 머릿속에 담아 보고 그다음에 뭐 클로드에 물어보든 문서를 더 보든 하면은 조금만 읽어도 머릿속에 생성이 나올 수밖에 없거든요. 그리고 다른 동료들이랑 이거 가지고 토론하고 하면은 생각이 더 깊어질 수밖에 없어서 이런 부분들을 일부러 좀 더 의식적으로 연습을 많이 하려고 해요. 왜냐하면 클로드나 채찍이가 최신 정보들은 잘못 알려 주거든요. 그래서 MCP 같은 것도 우리 모델 컨텍스트 프로토콜인데 막 모델 뭐 이상하게 막 잘못 알려 줘. 마이크로소프트 뭐 티파이드 그거 많이 나오잖아요. 정말 다르게 이상하게 알려 줘요. 진짜 맞아요. 그래서 주니어가 자칫하면은 굉장히 큰 실수도 할 수 있는데 사실 가장 정확한 정보를 가장 근거 기반으로 잘 설명한 게 공식 문서인데 그냥 지식을 그냥 GPT나 이런 걸로 너무 쉽게만 얻는 것만 하면은 공식 문서에 약간 정확한 문장으로 되어 있는 것들을 안 읽게 되다 보니까 이런 식으로 생각하는 힘을 좀 기르고 읽고 해석하고 검증해 보는 사이클 요걸 할 수 있으면 어떤 새로운 지식이 나오더라도 학습할 수 있는 그 뇌의 어떤 근육이라 되나 생각의 근육이 더 생길 수 있다 보니까 우리 AI 시대 이걸 잘 안 쓰게 안 쓰기가 너무 쉽기 때문에 오히려 이런 약간 본질적인 부분들에 좀 집중을 많이 해 보려고 하는 거 같아요.
- - 음, 요게 너무 좋은 게 사실 이거 책 읽을 때도 똑같이 할 수 있거든요. 저랑 동주님이랑 동주님이랑 했었지랑 기억이 안 나는데 책에 표만 가지고 한 시간 얘기한 적이 있어요. 맞아요, 맞아요. 이 저자가 왜 이걸 썼을까? 뭐 저자의 제목은 왜 이렇게 했지? 어, 책의 디자인은 왜 이렇게 돼 있지? 이 책의 추천은 왜 이렇게 돼 있지? 이런 걸 계속 얘기하고 추론하면서 그다음에 이제 그다음에 딱 집어보고 뭐 이런 식으로 해 보면 뇌가 엄청 돌아가거든요. 그래서 그렇게 하면 이 AI 시대에도 멍청해지지 않을 수 있는 것 같습니다. 어, 혹시 뭐 농담삼아 말씀드리면 가족분들이랑은 그렇게 얘기 안 하시죠? 아, 가족이라 그러면 큰일 납니다. 가정이 불화가 옵니다. 네, 가족은 무조건적인 공감으로 일방향으로 받아들일 수 있어야 됩니다. 아네, 아 혹시나 해서 예 불안한 마음에 한번 여쭤봤고요. 표 저희 그렇게 저희 그렇게까지 막 로봇처럼 살진 않습니다. 아네, 아 그럴 때 그 말씀해 주신 거 깊이 있게 생각해 보면서 가는 거는 너무 좋은 거 같아요. 예, 너무 좋은 거 같고. 어, 저도 오늘부터는 좀 그렇게 공식 문서를 좀 깊이 파헤치면서 한번 가봐야겠는데.
- - 저는 개인적으로 저는 약간 어 비슷한 방법이지만 만약에 이걸 강의로 풀어야 된다 그러면은 그 준비하는 과정에서 깊이 있게 이해를 하게 되잖아요. 왜냐하면 다른 사람에게 어떻게 설명할까를 얘기하다 보면은 혹시나 모델 컨텍스트 프로토콜에 대해서 누군가 모델 컨텍스트 프로토콜로 왜 이름이 지어졌나요라고 물어보면은 난 뭐라고 대답해야 되지 하면서 되게 깊게 파지는 것 같거든요. 그래서 그게 어느 정도 좀 됐었는데.
- - 그런데 저는 이제 또 하나로는 저는 사실은 방금 말씀해 주신 방법은 너무 좋아 보이는데 저는 그렇게 하진 않았었고 저는 주로 이제 글자를 읽는 것보다 코드 보는 걸 너무 좋아해 가지고 그게 개발 문서들은 다 코드가 나오니까 그걸 꼭 복사해서 돌려 봐야지 내 손으로 그냥 복사 붙여 넣기 해도 돌려보고 이해하는 게 딱 와닿더라고요. 그래서 전 좀 돌려보면서 하는 편이어 가지고 어 그것도 너무 좋았습니다. 예, 네, 오늘부터 바로 한번 적용해 보겠습니다. 맞아요, 저도 코드가 있는 거는 돌려 보면서 보는 게 확실히 좋고 얘는 프롬프트 엔지니어링이다 보니까 제가 좀 더 문장 중심으로 접근해 보긴 했었어요. 맞습니다, 맞습니다.
- - 돌 저는 이게 정확히 말씀드리면은 어떤 분이 제가 이제 랭체인 KR이라고 해서 그 랭체인의 한국어 튜토리얼을 공개해서 나뒀는데 그분들이 그 말씀을 하시더라고요. 어 저 지금 다 돌려봤다. 그래서 나 이제 좀 뭐 뭐 이제 좀 고수가 된 거 같다라고 말씀을 하시는데 제가 말씀드린 게 그걸 단순히 실행하는 거는 솔직히 말하면 공부를 했다라고 볼 수 없다. 저 저 같은 경우에는 공식 문서에서 예를 들어서 뭐 뭐 계산기 프로그램이 있어요. 그러면은 나는 아이디어를 좀 바꿔서 뭐 공학용 계산기를 만들어 봐야 그래야 내게 된다라고 보거든요. 그런데 단순히 그 짜여진 코드를 복사해서 실행하는 건 금방 되니까. 그런데 공학용 계산 만들 때 이제 생각하게 되잖아요. 거기에 있는 모듈도 찾아 쓰고 그러면 진짜 내게 되더라고요. 그래서 저도 이거 랭체인 번역하고 이거 만들 때도 거기에 보면은 제 제가 손수 만든 라이브러리 손이 좀 들어가 있어요. 완전 똑같지 않고 제가 어 이거 불편한데 이거 개선해야지 막 그런 것들 하면서 넣어 놓은 게 있는데 그것까지 해야 진짜 도움이 되는 거 같아요. 예.
- - 그 되게 좋은 부분인 거 같아요. 그래서 저도 이제 학생분들이랑 뭐 면담하거나 할 때 자기가 읽는데 뭐 잘 이해가 안 남는 거 같다 이러면은 제가 비슷하지만 좀 다르게 한번 같이 시도해 보는 게 책의 개발책들이나 문서들을 다 예시 코드들이 있잖아요. 그 예시 코드를 한 5분간 째려보기 해요. 5분간 최대한 집중해서 째려보기 하고 그걸 덮고 구현을 해 보게 하거든요. 그러면 머리를 많이 쓸 수밖에 없죠. 어떤 코드가 기억에 남았지? 그래서 5분 째려보고 다시 보면 본인이 기억하는 거라 놓친 것들이 더 눈에 잘 보이고 잘 뇌에 새겨질 수밖에 없어서. 그런데 말씀처럼 확장해서 다른 걸 구현해 보는 것도 너무 좋고 좀 더 이제 난이도를 조절하면은 이제 본 거를 내가 째려보고 분석해 본 다음에 덮고서 그대로 한번 써 보는 그렇게 나면서 그거 할 때는 탭 자동 완성 꺼야겠네요. 아 그거 무조건 꺼야죠. 예, 무조건 꺼야죠. 학습을 하기 위한 목적이니까요.
- - 요즘 이제 개발자분들 다 공감하시겠지만 어 가끔 인터넷 상황이 느려서 탭이 자동 완성이 안 되거나 그럴 때 있잖아요? 그럼 되게 답답해지는 성격이 안 좋아져요. 아 그렇 그렇군요. 저 이건 약간 논외로 하면은 저 예전에 이제 그 블루투스 펌웨어 개발을 했었는데 펌웨어는 아이디도 제대로 안 돼 있어 가지고 약간 노트패드에서 개발을 했었거든요. 노트패드 메모장 같은 데서 개발했는데 그때는 이제 지금은 자동 완성이 되는 것도 엄청 신세계 일대였거든요. 그런데 그 노트패드에서 자동 완성이 안 되니까 컴파일을 딱 하면은 이제 빨간 줄로 그어 주긴 해요. 그런데 이거의 데피니션을 봐서 우클릭해서 고투 데피니션 해야 되는데 그런 게 당연히 없어 가지고 와 컨트롤 F 눌러서 찾아서 들어가고 막 파일도 막 요렇게 돼 있고 막 그랬던 기억이 있었습니다. 예, 좀 딴 얘기 해 봤습니다.
- - 아 그래 아 그 아 그리고 그 아까 동주 님도 교육하시니까 저 저는 새로운 프레임워크 익힐 때 제가 지금도 쓰는 방법이긴 한데요. 거기에서 왜 코드에 보면은 그 반복되는 코드들인데 이건 꼭 알아야 되는 아키텍처들 있잖아요. 저는 그거를 한 블록 단위로 이렇게 나눠서 어느 코드에다가 이제 보물 창고 같은 데다 모아놔요. 그런 다음에 어떻게 하냐면은 저는 이제 하루 날 잡고 어 오늘 이 코드를 외워 버려야겠다 해서 뭐 특히 예전에 파이토치 코드 같은 경우에 그랬거든요. 학습하고 트레인하고 이제 테스트하는 코드가 반복돼요. 그런데 그게 모든 모델 트레이닝할 때 다 들어가는 코드거든요. 그런데 이게 처음에는 잘 와닿지 않으니까 그거를 딱 째려 보고요. 저도 똑같이 째려보고 그걸 백지에서 구현해요.
- - 그런데 처음에는 엄청 느리고 그다음에 이제 컨닝하면서 완성해요. 그런데 완성해서 동작했을 때 그 쾌감이 있거든요. 한번 느끼는데 문제는 저는 그거는 이제 내게 아니라고 생각하고 그걸 타이머를 재서 30초 안에 무조건 완성해야 돼요. 그런데 하루에 딱 다섯 번 시간을 정해 놓고 자고 일어나자마자 한 번 한 번 한 번 해서 다섯 번 해서 그걸 한 3일 정도 하면은 그 코드가 다 외워지거든요. 그런데 이게 너무 좋은 게 외워지면은 이제 그 코드는 당연히 그냥 눈에 있고 그 이해하는 게 아니라 그냥 알아요. 많은데 더 고난이도의 코드가 이제 보이기 시작하더라고요. 그래서 저는 이제 새로운 주니어 친구들한테 그런 방법론들 많이 추천하긴 했었는데 요즘에는 이제 AI 기능 나오고 나서 이제 그런 추천 잘 못 하게 됐습니다. 예.
- - 아, 그런데 너무 좋은 방법인데요? 그거 의도적 수련을 하신 거잖아요. 결국에 그 시간 안에 여러 번 만들어 보고 그걸 정확하게 반복하고. 너무 그런 방법이라면 저 주니어한테 시켜보고 싶은데. 저 저는 저 그거를 언제 배웠냐면은 처음에 그 안드로이드 앱 개발자로 할 때 안드로이드 플랫폼이 나온 그니까 정착이 된 지 얼마 안 돼 가지고 시키면 뭐 랭체인이나 랭그래프처럼 프레임워크가 잘 정착이 안 됐을 때였어요. 그런데 그게 잘 눈에 안 들어오니까 그 앱 하나를 그 그때는 처음에는 함수 하나였는데 확장이 돼서 앱 하나 정도는 그냥 안 보고 그 자리에서 외워서 다 만들 수 있었거든요. 그 MVP 딱 딱딱 짜서 이제 따라 하고. 그런데 이게 중요한 게 생각을 거치면 안 되는 거예요. 내가 어 오늘 뭐 먹지 하면서도 손가락 움직일 정도가 되면은. 그런데 그때 정도가 되면은 뭔가 내가 앱을 만들어야지 할 때 그 코드를 짜 놓고 시작하니까 어 다르더라고요. 이제 그냥 되게 편해지는 느낌이라고 해야 될까요? 그래서 그렇게 연습했는데.
- - 아, 그런데 저는 다 지금 생각해 보면 AI가 사실 너무 빨리 그렇게 짜 주니까 아 이제 좀 잘 모르겠습니다. 이제 그렇게 되시고 나면 AI가 잘못 짠 코드가 그냥 스쳐 지나가도 보여질 것 같은데요. 아 그렇죠, 그렇죠. 그 정도가 되긴 하죠. 저는 그 능력이 진짜 중요하다고 생각하거든요. 그러니까 AI가 잘못 짠 코드를 약간 눈으로 캐치하는 능력이랑. 그리고 제가 약간 약간 다른 얘기지만 저는 AI 코드 리뷰의 가장 큰 맹점 중에 하나가 어 잘못 짠 거는 잘 찾아내는데 해야 되는데 안 한 거는 잘 못 찾잖아요. 할 수도 있고 인간도 마찬가지고. 이런 부분을 결국 이제 도메인 논리지랑 경험으로 찾을 수밖에 없는데 그런 해야 되는데 안 한 거라든가 아니면 스펙에 나와 있는데 실제에선 동작하지 않는 거라든가 이런 거를 캐치하는 리뷰 코드 리뷰 능력이 AI 시대 진짜 중요한 거 같아요. 음, 그런 거 하는 데 있어서 테디 님 하신 훈련도 도움 많이 될 것 같고요.
- - 예, 그 제가 막 이게 교육이나 뭐 예전에 이제 판다스라는 데이터 분석 쪽 라이브러리가 있어요. 그런데 거기에 보면은 그냥 쉽게 얘기하면 SQL 쿼리문 같은 거라고 이해하시면 되는데 쿼리문은 저는 이렇게 생각했거든요. 그 물론 그 쿼리문 구조에 보면은 요거 컬럼을 넣고 그다음에 뭘 넣고 이런 구조적인 건 있는데 사실 외우면 저희가 한국말할 때 머릿속으로 생각해서 문법 맞춰서 얘기 안 하잖아요. 그냥 말 나오잖아요. 음, 쿼리는 그냥 외우면 잘 짜요. 그리고 더 좋은 쿼리도 더 좋은 쿼리를 많이 외우고 보면 되거든요. 그런데 그 강의를 할 적에 많은 분들이 쿼리 구조적인 거 너무 생각해서 어려워서 나는 이거 못 할 것 같아요 많이 하시는데 그거를 외우신 분들은 되게 편하게 잘 쓰시는 걸 보고 그때 제 방법론이 어 꽤 괜찮다라는 생각을 그때 많이 하게 됐었어요. 결국에는 그때 AI가 없을 때여서 그냥 사람이 내가 한국말도 이제 이미 문법 생각하면서 말하는 사람은 한국말에 플루언트하다라고 얘기할 수 없는 거잖아요. 그래서 거기서 좀 차관을 했었고요. 네, 그래서 저 새로운 프레임워크 배울 때 암기하는 것도 예 좋습니다. 예, AI랑 같이 저 해서. 아, 제가 개인적으로 너무 쓸데없는 소리를 많이 한 거 같은데 너무 재밌습니다.
- - 아, 그 이어서 좀 질문을 드려 볼 게. 아 질문이 되게 많이 올라왔었는데 제가 질문을 많이 못 드렸는데 어 대부분은 약간 동주 님이 막 채팅으로 얘기도 하신 것 같. 아, 해 주셨구나. 네, 감사합니다. 아, 뭐 많이 답변을 해 주신 거 같은데요. 아 네, 아 너무 감사합니다. 예, 아 습관이 돼 가지고 유튜버 유튜버시니까 습관이 돼서. 네, 네, 네. 아이, 또 그 네 너무 예 잘 답변이셨습니다.
- - 그 다민 님이 남겨 주신 질문을 같이 한번 이야기해 봐도 좋을 것 같거든요. 그래서 실제 개발 과정에서 겪고 있는 어려움에 대해 질문하고 싶다고. 현계와 실행의 괴리. 원하는 아키텍처 설계에 맞게 명확히 구성했음에도 불구하고 실제 AI 코딩을 진행할 때 의도한 대로 구현되지 않는 경우가 빈발하다. 아, 너무 많죠. 너무 많죠. 네, 네. 그래서 우리의 성격을 안. 저 할 얘기 있는데 먼저 거장 두 분께 한번 들어보고 싶습니다. 거장, 저희 거장까지 아니면 거장 정도로 하겠습니다. 거장이라고 그만 말씀해 주시면 감사하겠습니다. 저희 거장이라고 하시면 자꾸 말을 더듬게 될 거 같아요.
- - 아, 그러면 동주 님께서 거를 맡아 주시고요. 휘동님께서 장을 맡아 주시면 되겠습니다. 네, 너무 좋네요. 거장님의 의견을 들어보도록 하겠습니다. 그러면 그럼 우리 장님부터 한번 가 볼까 이번에? 네, 장님부터 먼저 부탁드립니다. 네, 그래서 이게 그 내가 프롬프트를 잘 줬음에도 불구하고 그 컨텍스트랑 다 잘 줬음에도 불구하고 안 된다는 건지 제가 아직 그게 정확히 이해는 안 되거든요. 그러니까 어 아마 정확히 줬는데도 안 된다는 말씀이시겠죠? 아마. 예.
- - 그런데 어 이게 뭐 약간 엄청 어려운 문제고 정답이 없는 문제 같기도 한데 저라면 어떻게 할 것 같냐면 그니까 저는 어떻게 하냐면 결국 얘를 얘랑 더 얘가 어떻게 하면 이거 알아들었을까? 어떻게 하면 잘해 줬을까를 계속 고민하면서 반복을 좀 많이 하는 거 같아요. 그런데 그거에서 그냥 얘를 계속 갈구면서 야 왜 못 했어? 이렇게만 하는 게 아니야. 그렇게도 할 때가 있지만 짜증날 때가 있지만 그것보다는 내가 이거를 어떤 AI 시대 이전에 내가 이 스펙을 받아서 내가 개발을 했다면 어떤 순서로 뭐부터 어떤 순서대로 개발을 했을까? 그 행동을 좀 분석해서 적어 보고 그 그 행동대로 얘한테 줬을 때 좀 더 잘하는 걸 좀 많이 느꼈거든요. 네, 그까 뭔가 행동 레벨로 전문가가 실제로 이 스펙을 받았을 때 어떻게 분해해서 얘를 쪼개서 일을 하느냐를 스텝 바이 스텝으로 쭉 주고 그걸 따라가라 뭐 이렇게 할 때 좀 더 전 잘 하는 걸 느꼈던 거 같아요.
- - 그 그런데 만약에 뭐 기능 구현을 하는데 뭐 다섯 개는 구현을 했어요. 그런데 하나가 내가 원하는 방향성은 아니야. 그러면 그럴 때는 이제 좀 더 구체적으로 어떤 방향성 수정하는 방식으로 많이 하세요? 아, 수정. 약간 이게 또 케바케긴 하지만 전 수정을 한 번 정도 시도해 보는 거 같고. 네, 잘 그때도 잘 못 할 경우가 많잖아요, 사실 얘네가. 네, 네, 네. 그래서 안 되면 아, 일단 그니까 잘 된 때든지 무조건 걔는 깃 커밋에서 해 놓고 그다음에 잘 못 하면 이 채팅 다시 날린 다음에 거기서부터 다시 시작하는 것 같습니다. 그러면 그런 상황에서 어때 어떻게 해요? 아, 이거 좀 더 너무 구체적으로 들어갈 수 있는데 기능 구현을 했어. 어, 그런데 보니까 바이브가 내가 생각했던 바이브가 아니네. 그러니까 예를 들어서 기능 구현했는데 뭐 UX적인 부분이라고 할게요. 어, 이거 적용이 돼 보니까 그렇게 편할 것 같진 않네. 이거보다 더 나은 방법이 차라리 이전 방법이 더 낫겠네. 그럼 그런 방 그럴 때에는 그냥 뭐 어떻게 하세요? 되돌려 달라라고 프롬프트를 하시는지 아니면 뭐 깃 커밋에서 그냥 이전에 다섯 개 기능을 다 돌리고 다시 네 개를 구현하는 방식으로 하시는지 이런 것들이 좀 궁금합니다.
- - 어 저는 그런 경우가 많지 않았는데 예전에 할 때는 보통 그냥 깃 커밋으로 제가 알아서 리셋을 해서 갔던 거 같아요. 되돌려 달라는 말은 아 모르겠네 비개발자 경의에선 이러면 안 되나. 아무튼 되돌려 달라는 말을 해 본 적이 거의 없고 저는 무조건 리스토어 체크포인트 리셋을 하거나 아니면 커밋으로 되돌아가서 하는데.
- - 그런데 만약에 제가 그 상황을 겪었고 이번에 새롭게 하고 싶다면 이번에는 어떻게 할 거 같냐면 일단 전략을 짤 때 애초에 세 개의 어떤 내가 예를 들면 뭐 얘를 약간 속이는다고 해야 되나? 그러니까 내가 지난번에 이런 식으로 개발했었는데 이게 마음에 안 들었었고 그래서 좀 다른 식으로 해 보고 싶다. 좀 세 가지 다른 옵션을 줘 봐라. 그거 할 때 뭐 서로 다른 걸 최대한 창의적으로 줘 봐라. 이런 식으로 해서 그 옵션을 보고 선택하는 식으로도 좀 했던 거 같아요. 음, 그러면은 이거 얘기를 들어보니까 휘동 님께서는 미리 코드 한 줄 짜기 전에 그 계획 자체를 굉장히 탄탄하게 설계를 좀 하시는 편이신 거죠? 네, 네. 저는 플랜을 진짜 열심히 짜고요. 그 그래서 클로드 코드 플랜 모드 너무 좋아하고 커서에서도 데스크 모드 좋아하고 그렇습니다.
- - 어, 그 그런데 이게 플랜을 짤 때 뭐 저희는 사실 개발자 베이스니까 뭐 아키텍처도 넣어 줄 수가 있고 그다음에 그 개발에서 쓰는 용어들을 넣어 주면 너무 잘 이해하니까 좋을 거 같은데 비개발자들은 사실 아키텍처 모르실 수도 있고 더군다나 만약에 예를 들어서 간단한 회원 가입이다 하더라도 거기에 들어가는 요소들이 뭐가 필요한지도 모르실 수도 있는 거잖아요. 그러면 비개발자분들은 좀 어떤 식으로 접근하는 게 좀 현실적일까요? 그게 사실 말씀하신 대로 비개발자들은 내가 뭘 모르는지도 모르잖아요. 그 키워드를 정확하게 주는 게 중요한데 키워드도 모르고. 그래서 저는 비개발자는 제 생각에는 커서나 클로드 코드에서 시작하는 게 좀 안 좋은 거 같고.
- - 그러나 내가 요걸 잘 모른다라는 적어도 그니까 난 뭘 모르는지 모르지만 내가 모른다는 건 알잖아요. 그래서 그거를 이제 제미니든 뭐 채찍이든 거기서 내가 이런 기능을 구현하려 하는데 내가 이쪽으로 뭐 용어도 하나도 모르고 내가 어떻게 AI에게 시켜야 될지도 모른다 자체의 문제를 얘기한 다음에 그러면 내가 이런 용어들을 빠르게 알려면 또는 내가 좀 효과적으로 명령을 내리려면 어떤 것들을 좀 배워야 되냐 알아야 되냐 같은 거 물어보고 그 대화를 한 상태에서 그다음에 좀 시작을 하는 게 좋은 거 같아요.
- - 음, 그러면은 그러면은 그 대화를 할 때는 개인적으로 선호하시는 거는 제미니가 제일 잘한다고 생각하세요? 저는 제미니 정확히 말하면 그 구글 AI 스튜디오에서 제일 많이 하는데 일단 무료니까 제일 좋아. 그리고 이게 수정하고 복사하고 이런 게 너무 편해 가지고. 그리고 어떨 때는 뭐 그라운드 위드 구글 서치 켜고 뭐뭐 URL 넣어서 이런 게 다 되니까 전 거기서 제일 많이 하는 거 같아요. 아 그렇군요. 혹시 동주 님께도 비슷한 경험 한번 여쭤봐도 될까요? 만약에 만약에 그 어 비개발자 비개발자나 아니면 비전문가. 그 내가 백엔드 개발자인데 난 프론트 개발을 이번에 한번 해 보고 싶어 이런 대상으로 봤을 때 아키텍처나 이런 것들을 잘 모르시는 상황인 거죠. 그런 분들께 좀 제한드릴 수 있는 현실적인 어떤 방법론 그런 것들이 있으실까요?
- - 제 경험상 가진 현실적인 거는 개발 친한 개발자를 한 명 만드는 게 가장 좋은 거 같아요. 왜 뭘 모르는지 알 때 그거를 혼자 찾아 나가면서 이게 나한테 필요한 정보인지 내 수준에 너무 높은 게 아닌지 내가 그걸 알아두려면 에너지가 정말 많이 드는데 개발자 지인이 있으면 그 꼭 뭐 프론트나 뭐 백엔드나 그게 아니더라도 대체적으로 개발자들은 더 감이 있으니까 학 경험 때문에 더 잘 알려 줄 수가 있게 되더라고요. 저도 이제 교육을 하다 보니까 신입 뭐 개발자 중에서 더 빠르게 성장하는 친구와 그러지 않은 친구들 이런 친구들이 좀 어떤 차이가 있는지 뭐 테크 리더분들이나 이런 분들한테 일부러 좀 인터뷰도 많이 하고 했었거든요.
- - 그런데 재밌는 포인트가 좀 빠르게 성장하는 주니어 친구들은 그냥 일을 뭐 큰 덩어리 줘도 큰 덩어리로 좀 모호하게 줘도 알아서 그걸 잘 쪼개고 중요한 거부터 좀 해 나가더라. 그런데 그런 친구들 보니까 기획자랑 친하게 지내더라 그 얘기를 하시더라고요. 사실 기획자도 완벽하게 처음부터 못 줄 수가 있잖아요. 개발에 대한 지식이 없으니까. 그러면 이제 모르는 게 있을 때 물어보고 조정하고 이게 편해야 더 자주 물어보고 소통할 수 있다 보니까 제 가장 현실적인 거는 우리가 뭐 스스로 학습한 것도 필요하지만 친한 개발자를 만들거나 아니면 그런 스터디 모임에 가거나 하면서 어 더 자주 이야기 나눠 보고 내가 그걸로 그냥 수다를 많이 떨 수 있는 경험이 그런 환경을 좀 만드는 게 좀 중요한 거 같아요. 영상 많이 보고 테디님 라이브에 자주 들어오고 하면은 일단은 좀 현실적인 방법이지 않을까.
- - 그런데 요게 되게 어떻게 보면은 그 1차원적인 거 같지만 좀 확실한 방법이 생각이 들어서 왜냐하면 저랑 휘동님도 서로 만날 때마다 아니 이런 걸 했다고요 막서 이런 게 너무 많거든요 저희끼리도. 아, 아, 그렇죠. 오늘도 막 러버블에서 애널리틱스 기능이 7월 3일부터 들어갔다는 걸 제가 막 동주님한테 알려 드리고 막 그랬습니다. 애널리틱스 기능은 뭐예요? 그 어 그 러버블이 가장 좋은 것 중에 하나가 그 배포하면 보통 이제 버셀 같은 건 결국 트래픽 기반으로 막 다 돌아가면서 돈을 내야 되잖아요. 막 트래픽 올라가면. 그런데 러버블은 그 배포가 아직까진 무조건 무료거든요. 그래서 어 그 그냥 띄워놓는 게 아무런 부담이 없는데 그래도 약간의 불만은 거기서 유저가 몇 명 들어왔냐 이런 거 모르는 거였는데 그게 생겼더라고요 7월부터. 그래서 그거 가면 페이지 뷰 카운트 같은 거 나오고 뭐 클릭 카운트 체류 시간 이런 게 좀 나오더라고요. 음, 원래 G 붙여 가지고 분석하던 거 했는데 너무 쉽게 이제 또 돼 가지고 깜짝 놀라면서 서로 약간 새로운 것들을 많이 공유하면서 그 그냥 수다 떠는 걸로 학습되는 게 너무 많더라고요. 저희 둘도. 그래서 아마 다른 분들도 이런 수다 떨 수 있는 기회가 많아져야 아마 자연스럽게 더 학습할 수 있는 계기가 더 많아지는 것 같아서.
- - 저 그런데 아까 혹시 그 아마 다미 님이 뭐 그 설계나 실행 이런 게 내가 명확하게 구성했음에도 의도한 대로 구현되지 않았다. 요거 저 하나만 좀 덧붙여서 좀 이해 조금만 해도 괜찮을까요? 아, 그럼요. 예, 저도 이제 정확하게 다민 님의 상황은 모르지만 제가 약간 요런 상황일 때 접근하는 게 저는 약간 이렇게 막막할 때 공식 문서를 이렇게 한 번씩 이렇게 좀 훑어 볼 때가 있거든요. 그래서 제가 그 엔트로픽 프롬프트 엔지니어링 결국에 우리 바이브 코딩하듯 프롬프트를 작성하는 거다 보니까 거기에 그 사고의 연쇄 과정 COT 페이지 보면 여기 팁에 요런 내용이 있거든요. 그 아까 휘덕님도 말씀을 해 주셨는데 **클로드가 항상 자신의 사고를 출력하도록 해라. 사고 과정은 출력하지 않으면 사고가 일어나지 않는다**.
- - 그래서 우리가 무언가를 작성했는데 얘가 그걸 지켜 주지 않은 거는 그거의 어텐션을 못 가져서 실행하지 않은 퀘스트들이다 보니까 그니까 어떤 단계별로 뭐 플래닝을 하든 어떤 순서대로 하든 어떤 연쇄 과정으로 문제를 해결하든 그거를 좀 작게 쪼개서 진행할 수 있게끔 하는 거를 내가 넣어 놓긴 하지만 얘가 그걸 단계별로 출력하게끔 하고 실행하게끔 하면은 그 5차 범위가 좀 더 조절이 컨트롤 가능한 범주로 더 많이 들어오게 되더라고요. 그래서 물론 우리가 원하는 건 한 방에 탁 해서 쭉 많이 되는 거지만 어 의도대로 안 된다면은 그 의도대로 잘 안 되는 딱 그 특정 부분이 있기 때문에 그 부분을 잘 발견하기 위해서 그 과정들을 중간 과정들을 더 출력하게끔 해서 체크해 보는 게 저는 실험적으로 좀 도움이 더 많이 돼서 이런 부분 한번 참고해 봐 주시면 좀 좋지 않을까 해서 그냥 추가로 조금만 덧붙여 봤습니다.
- - 맞습니다. 저도 그 부분 너무 공감하고요. 그러니까 추론 모델이 있어서 전 제일 좋은 게 뭐 얘가 추론을 해서 답변이 더 좋아졌다 보다 생각하는 과정을 제가 이제 훔쳐 볼 수 있어서 그래 봤는데 어 그거 내 방향성 아닌데 한번 바로 끊어 가지고 그걸 바로 프롬프트 조정해서 다시 생각하게끔 하는 그게 너무 좋더라고요. 뭐 그래서 어 추론 토큰에 어떤 분들은 그 추론하는 과정만 그냥 힌트에서 거기서 스톱 토큰 먹여 가지고 그냥 그 추론하는 과정만 가지고 오시는 분들도 계시고.
- - 그런데 아까 말씀하신 것처럼 그것도 너무 좋았고 또 최근에 또 아 요거 요거는 두 분께서 이 거와 장님께서 너무 잘 아시겠지만 그 클로드 코드의 그 히든 기능이라고 해야 될까요? 이게 검증된 건지 모르겠지만 울트라크 뭐 이런 것들을 먹이면은 더 길게. 그거는 히든 히든이 아니라 공식 문서에요. 아 공식 문서에요? 예 예. 네, 맞습니다. 그 전 저 전 무조건 이제 그니까 간단한 기능 같은 경우에는 울트라크 안 붙이는데 아 이건 좀 어려울 거 같은데 그러면 울트라크 그냥 붙여 버리거든요. 그 확실히 좀 더 길게 생각하고 플랜 모드에서 그 얘가 플랜 모드도 저도 너무 좋아하는 게 플랜 모드에서 뭔가 어 그 생각하는 과정을 얘가 딱 정리해서 이제 딱 이게 이게 맞나요? 이렇게 컨펌을 해 주는데 거기서 아닌 것 같은 경우에 다시 지시사항을 줘서 이게 좀 다듬어서 그 과정들이 너무 잘 만든 것 같더라고요. 네, 네. 아 클로드 코드 아 진짜 대단합니다. 예. 저 위에 시원님이 질문하신 거 제가 이 구두로 한번 얘기해 드리겠다 한 거 있어 가지고. 네, 그 질문이 어 **스텝 바이 스텝으로 문제를 분석하고 작은 단위로 분해해서 해결하는 능력을 키우고 싶은데 LM을 활용해서 도움될 부분이 있을까요?** 이 얘기해 주셨거든요.
- - 그래서 요거는 제가 AI 시대 이전에 하던 방법 하나랑 AI 시대에 하는 방법 이렇게 얘기를 좀 드릴 수 있을 것 같아서 제가 좀 얘기를 드려도 괜찮을까요? 네, 네, 그럼요. 네. 일단 AI 시대 이전에 하던 방법은 뭐냐 뭐였냐면 제가 주니어 훈련시킬 때 했던 건데 그니까 똑같이 태스크가 있을 때 약간 온보딩할 때 많이 있었던 거기도 하고요. 이 태스크를 주고 이걸 해결하기 위해서 최대한 작은 단위로 너라면 어떻게 할지 진짜 1부터 n까지 다 써 봐라. 그래서 우리 10분간 써 보고 비교해 보자. 이거를 많이 했었거든요. 음 음. 그걸 해 보면 서로 충격을 받아요. 그러니까 시니어는 얘가 이렇게 모른다는 거에 충격을 받고 주니어는 아 이렇게 많은 걸 신경 써야 된다 또는 이렇게 잘게 쪼갤 수 있구나 이런 걸 충격을 받더라고요. 그거를 몇 번 해 보면 시니어 주니어가 시니어로서 약간 빠르게 좀 성장을 많이 좀 하는 것 같고. 음, 너무 좋다.
- - 네, 그거를 그런데 저는 AI랑도 좀 하거든요. 약간 AI랑 뭔가 계획하기 전에 그 나라면 이걸 이렇게 분해할 것 같다 좀 한 다음에 AI는 어떻게 분해하는지 좀 비교해 보는 것도 좀 하고 있고. 그리고 약간 클로드 코드 플랜 모드랑 비슷할 수도 있는데 저는 AI랑 핑퐁을 좀 깊이 많이 AI 스튜디오에서 많이 하는 걸 좀 좋아하긴 해요. 그래서 인터랙티브 모드로 얘랑 얘가 먼저 나 내가 좀 길게 얘기를 하면 얘가 자기 의견 주고 거기에 대해서 또 얘기 나누고 그다음에 또 진행하고 이렇게 식으로 단계적으로 하는 걸 참 좋아하거든요. 그 그런 식으로 좀 많이 하는 것 같습니다. 아, 아, 너무 너무 좋은 거 같아요. 둘 다 너무 좋은데. 아, 저 내일부터 또 바로 한번 적용을 해 보겠습니다.
- - 네, 서비스 만들 때 그러면은 그 방금 말씀해 주신 그 방법론을 통해서 뭐 열 가지 요소를 추렸다. 그럼 그게 또 시드가 돼서 프롬프트 입력으로 들어와서 맨 처음에 어 서비스 구현할 때 그 아키텍처 잡을 때 그렇게 또 응용해 볼 수가 있겠네요. 네, 네. 이거 이거 혹시 제가 잠깐 화면 공유 하나 할까요? 이거 제가 오늘 만들기 시작한 게 있는데 잘 보이시네. 네, 아 요거는 제가 뭐 몇 번 SNS에 올린 적 있긴 한데 그 PRD 쉽게 말하면 PRD 생성기거든요. 음 음. 그래서 저는 이런 식으로 프롬프트를 그 만들어 주는 앱을 만드는 걸 좋아하는데 그래서 여기서 그 제가 만들고 싶은 앱을 여기 열심히 설명을 하고 그럼 얘가 이제 마크다운을 만들어 주고 이걸 복사해서 AI 스튜디오한테 먹여 가지고 이제 막 토론을 하면서 계속해서 발전시키는 거거든요. 음. 이런 식으로 만들었고 이게 제가 코딩 에이전트 이거 이거 이건 뭐였냐면 그 비개발자분들이 특히 어려워하는 게 API나 사스 연동이잖아요. 네, 그래서 이거를 딸깍으로 해 줄 수 있게 해 보려고 예를 들면 러버블의 스트라이프 아 스트라이프는 그냥 붙지 뭐 제미니 붙이기라는 걸 제피어처럼 이제 딱 써 놓고 거기에 프롬프트 복사해서 러버블에 넣으면 얘가 연동이 되게 뭐 이런 걸 한번 상상하면서 만들어 보고 있었거든요.
- - 그 어때요? 성과는 괜찮나요? 잘. 아니 오늘 만들기 시작해서 아직 모르겠어. 아, 게다가 이거를 약간 그 실험으로 하고 있어요. 왜냐하면 이제 커서가 초반에도 테디님 말씀하셨듯이 원래는 이제 가성비가 괜찮은데 요즘 너무 안 좋잖아요, 사실. 네, 그런데 저희 강의 있는 커서라고 써 있단 말이에요. 그래서 커서 얘기를 해야 돼 가지고 어떻게 하면 비개발자분들이 가성비 있게 커서를 쓸 수 있을까 고민을 하면서 최대한 커서의 GPT 4.1만으로 제가 코드 안 건드리고 최대한 열심히 PRD를 짜서 프롬프트 짜면 할 수 있지 않을까라는 상상을 하면서 바이브만으로 해보고 있는데 아직 쉽지는 않고요. 아직은 커서에 대해서 GPT 4.1은 정말 어렵지 않아요.
- - 그런데 저는 이제 싱킹이 아닌 거에 또 장점이 있을 때가 있는 것 같거든요. 그러니까 쓸데없이 다른 거 안 하고 딱 시킨 것만 하는 게 있으니까. 그래서 얘를 오히려 역으로 내가 최대한 많이 잘 준비하면 4.1로도 잘 되지 않을까라는 상상을 하면서 해보고 있는데 어 아직까지는 잘 모르겠고요. 며칠 더 해 봐야 될 거 같고. 그래서 이 과정을 아마 다음 주에 패캠 세미나에서 얘기를 할 것 같기도 하고요. 아 그러시구나. 어 너무 재밌겠다. 아무튼 네, 그래서 이거를 그 아직까지는 성과가 적은데 어쨌든 그 얘기해 보고 있고. 그런데 이게 재밌던 건 전 이거 기획하는 게 너무 재밌더라고요 이거를 가지고. 음, AI 스튜디오에서 기획한 과정이 이렇게 있는데 엄청 길게 있는데 여기서 보면 뭐 얘가 막 칭찬도 엄청 잘 해 줘 잘 보이시나 잠깐. 네, 잘 보입니다. 네, 얘가 일단 칭찬 엄청 잘 해 주고 이 자존감이 올라가는 효과가 있고요. 장점과 취약점 분석해 주고 뭐 이런 추가 고려 사항 제한해 주고. 제가 그리고 이런 프롬프트를 넣어 놨어요. 그 AI가 할루시네이션이 약간 다른 측면에 할루시네이션이 얘가 너무 확신 수준이 높을 때 생기는 거잖아요. 그런데 내가 그걸 알아보지 못할 때 그 제가 이 다른 그 티아고 포르테라는 사람 뉴스레터 보면서 이제 차관해서 가져온 건데 **불확실성 지도**라는 걸 추가를 해서 네가 응답한 것 중에 제일 불확실한 부분이 뭐야? 네가 단수한 부분은 뭐고 네가 얘기한 거를 내가 어떤 의견을 좀 바꿀 수 있어? 같은 얘가 스스로 출력하게 한 거였거든요. 이걸 보면 너무 제가 이 답변을 판단하기가 너무 좋아 가지고 이거 많이 쓰고 여기서 이걸 단계별로 여기서 뭐 이런 식으로 제가 이제 얘기해서 계속 넘어가고 넘어가고 이렇게 많이 했었습니다. 그래서 이게 이거 하면서 정말 비교적 짧은 시간에 아이디어가 정말 빠르게 발전해서 진짜 재밌어 재밌게 했습니다.
- - 음, 아 보통 진짜 이렇게 말씀하신 것처럼 이렇게 계속 질문 답변하면서 되게 딥하게 어떤 그니까 코드 한 줄 없이 뭔가 진짜 아키텍처 나 이거 다시는 변경 안 할 거야 싶을 정도로 되게 디테일하게 뽑아내시네요. 아, 그런데 그게 아키텍처 쪽까지는 아니고 약간 아이디어의 발전이고요. 아키텍처 쪽은 이 뒤에 또 좀 하는 게 좀 있는 거죠. 음. 기대적 쪽은 전 요즘 그 커서 마피아 님이라고 하는 요즘 유명하신 그분의 부스터 제품으로 써서 PRD랑 뭐 이런 거 뽑아내는 걸 좀 하는데. 아, 저도 부스터 좀 써 봤거든요. 그거 부스터 AI는 어떠세요? 부스터는 저는 어 일단 지금 태스크 마스터보다는 만족스럽고요. 그 클로드 태스크 마스터보다는 만족스럽고 그 무슨 일주일에 약간 AI 시대 걸맞게 매주 뭐가 많이 업데이트돼 있어요. 그래 가지고 저 그분 그분의 그 신규 기능 추가 속도가 진짜 최고인 거 같아요. 네, 그래서 지금 약간 뭐 불만족스럽게 있어도 그냥 디코에 올려 놓으면 이분이 알아서 고쳐 나와 가지고 너무 좋고. 그래서 저는 아 저는 그리고 워낙 초기부터 써서 지금 그 무료로 많이 많은 많은 거 쓸 수 있는데 아마 조만간인지 언젠지 유료가 될 거라서 어쨌든 많이 써 보시면 좋을 것 같고 저는 그거 정말 추천드립니다. 음, 부스터 AI. 네, 예, 부스터 AI. 요거 모르시는 분들을 위해서 제가 저도 쓰고 있거든요. 그래서 남겨 놓겠습니다. 네, 아 그렇군요.
- - 어 아 역시 오늘 꿀팁 어떤 제가 바이브 코딩 강의를 듣거나 아니면 꿀팁을 들으면 항상 드는 생각이 아 빨리 끝나고 빨리 가서 해 보고 싶다라는 생각들 많이 들어. 혹시 얘기 나온 김에 동주님께서도 뭔가 간단히 뭔가 팁 이런 거 있으세요? 아니면은 직접 하실 때 어떤 뭐 활용하는 방법이나 아니면 강의에서 어 다루시는 내용 중에 약간 맛보기라도. 음, 뭔가 휘동 님이 먼저 많이 말씀하셔 가지고 무슨 이야기 할지 좀 고민하고 있었는데 어 요건 어떻게 보면은 지금 휘동님이 PRD를 기획을 많이 하고 계시는데 원래 우리가 무언가를 만든다라는 거는 결국에 사용자가 있어야 의미가 있잖아요. 그리고 원래 열정이란 것도 사람들이 쓰면은 또 자연스럽게 또 열정이 생기고 열정이 원래 먼저 있는 게 아니고 잘 되면 열정이 생기잖아요.
- - 그래서 뭐 이 사용자가 있는 무언가를 만드는데 이 사용자를 보통은 막 큰 대중들이나 많은 사람들을 생각하게 되는 경우들이 좀 많더라고요. 그래서 막 저랑 휘동님도 어디 가서 이제 사용자 어떤 범주를 이야기할 때 크게 세 단계로 이야기하거든요. **자신을 나 혹은 타인 아니면 타인들**. 음, 그래서 일단 내가 나라도 매일 자주 쓰는 거를 만들면 훨씬 더 내가 그 쓰다 보니까 자연스럽게 많이 개선하게 되고 그러면서 좀 더 고도화시키기 위한 기능들이나 뭐 API나 이런 학습들이 자연스럽게 더 잘 이루어지고 또 바로 써먹게 되니까 학습 효과도 더 많이 높아지는 것 같아서. 어, 그 우리가 학습 학습 자체는 되게 중요한데 이 학습한 거를 바로 내가 써먹는 경험으로 연결시키는 게 진짜 너무 너무너무 중요한 것 같아요. 그래야 어 내가 학습하는 거 우선 순위 감각도 생기고 그 우선 순위가 어떻게 동작되는지 그거를 훨씬 더 좀 잘 이해할 수 있다 보니까.
- - 저 같은 경우에는 제가 여행을 되게 좀 좋아하거든요. 그래서 여행 제 서브 유튜브 채널도 있고 해 가지고 제 SNS 채널에 뭐 만들고 나면은 그래제 공유하고 막 해요. 그래서 그냥 몇 가지 간단하게만 좀 소개를 저도 좀 해 보면 지금도 앉아 계신 게스트 퍼스트 클래스에 앉아 계신 것 같습니다. 아, 저희 이거 회사에서 보통 이제 배경하면서 앉은 건데 항상 언제든지 떠나고 있는 느낌을 갖고 싶어 가지고 지금 화면 공유 잠깐 했는데 혹시 보이시나요? 네, 네. 요거는 이제 제가 그냥 아고다 줍줍이라 해 가지고 별건 아닌데 그 아 우리 여행 갈 때 해외 호텔 같은 거 예약하면은 아고다 이런 플랫폼들 막 쓰잖아요.
- - 그런데 그 아고다 플랫폼이 내가 구글 맵으로 들어가는지 네이버 지도로 들어가는지 모바일로 들어가는지 그런 거에 따라서 링크에 CID라는 게 달라지면서 금액대가 좀 달라지거든요. 그래서 얘네도 AB 테스트를 많이 하다 보니까 경로별로 어 이런 테스트들을 좀 많이 하면서 모바일로 들어오면 더 좀 더 할인된 가격도 보여주고 막 이런 걸 하기 때문에 그 여행을 약간 미쳐 있는 사람들은 이걸 다 경로 들어와서 최적자로 봐 가지고 이제 그걸로 예약을 한단 말이에요. 그래서 저 아 뭔지 알겠다. 예 예. 약간 해킹 같은 거죠. 어떻게 보면 좀 편법으로. 그런데 불법은 아니에요. 예, 그런데 요거를 이제 여행을 자주 하고 여행에 미쳐 있는 저 같은 사람들은 하는데 어떤 사람들은 할 수 없으니까 이거를 사실 그냥 문자만 파싱해 주면 되는 거라서 이거를 이제 어떤 링크 이제 아고다에서 호텔 링크 딱 붙여 넣으면은 이제 카드사별 뭐 검색 경로별 제휴인 링크별 이렇게 그냥 보여줄 수 있게 만든 거예요. 그래서 되게 간단하지만 어 저도 자주 쓰고 그리고 내가 평생 살면서 엄청 독특하다는 소리를 들은 게 아니면 내가 쓸 거 만들면 남들도 쓸 만한 게 나온 경우들이 많더라고요. 경험적으로.
- - 아이고 감사합니다. 그 채팅으로 여행 유튜브 영상 잘 봐주셨다고. 그래서 요렇게 좀 만들고 이제 제 SNS 채널 있다 보니까 그걸로 좀 홍보를 그 쇼폼 만들었더니 조회수가 인스타그램, 유튜브에서 한 100만 정도 나왔어 가지고. 와, 100만해요? 3개월간 이벤트 25만 활성자 3.9만 막 이런 식으로 이렇게 나오게 되더라고요. 이게 결과 나오고 사람들 쓰면은 열정은 자연스럽게 생겨서 더 유지 보수하고 더 학습을 하게 되더라고요. 와, 어, 그런데 그런데 이게 너무 좋은 게 간단한데 좋다. 그래서 내가 관심 있는 좋아하는. 그래서 약간 저는 AI 시대 때 더 내가 좋아하는 취향이나 내 관심사가 확실한 게 좀 중요하다는 생각이 좀 들었어요. 내가 좋아하는 게 있으면 그 디테일 작은 거 하나로 되게 심플하지만 이펙티브한 것들을 내가 그 도메인에 대한 전문가여서 다 잘 알 수밖에 없기 때문에 그걸 좀 더 잘 활용할 수 있는 거 같아서. 이게 가격 차이가 실제로 많이 나요? 어 이제 호텔이 내가 뭐 좀 5성급 호텔이다. 그런데 막 4박 5일 한다 하면은 막 2, 30만 원씩 차이 나기도 하죠. 와, 근데 1박당 이제 할인되고 이런 부분들이 있으니까. 그러면 너무 좋네.
- - 이게 너무 많이 알려지면 아고다가 CID를 바꾸겠네요. 그런데 뭐 바꾸면 제가 그것도 트래킹해서 하면 되죠. 아, 의전. 그래서 저는 여기에 뭐 광고를 붙이고 다 제 채널에 이제 광고를 하고 있죠. 아, 아, 그 아, 그런데 요거 링크를 어떻게 아 제가 링크 남겨 놓도록 하겠습니다. 아, 예, 아고다 아고다 빼기 줍줍. 아 이게 제가 아고다 빼기 줍줍닷컴이죠? 아고다.sjunok.com이요. 아 아고다점 아 아 제가 도메인을 이것 사 놓은 것도 있는데 지금 그냥 통일해서 아 네 그냥 좀 하고 있어 가지고 아고다.s.yesjunok.com으로. 그런데 뭐 두 개 다 상관없습니다. 다 등록을 해 놔서. 아, 아고다 개발자 여기 없어 쓰시죠라고 했었는데. 아 아 여기 코난 쌤도 오셨는데 코난 쌤도 저희 코난 쌤은 이게 바이브 코딩 그 파티라는 걸 만드셔 가지고 그 하루에 한 번씩 그 바이브 코딩 팁을 뉴스레터로 이렇게 해서 마지막에 이제 공모 공모전이라고 해야 되나 이게 막 그 출품도 받으시고 아무튼 아 열정이 대단하셨어요. 네, 저도 거기서 뉴스레터 구독해서 했었는데 아 또 오셨네요. 감사합니다.
- - 하나만 좀 더 아 예 보여주시죠. 너무 궁금합니다. 그 인스타그램에 요즘에 그런 거 되게 많잖아요. 막 그 리스터를 짧게 나오고 댓글에 뭐 프롬프트를 작성하면 프롬프트 템플릿 DM으로 보내 드릴게 이런 거 되게 많잖아요. 그래서 그런 제공해 주는 유료 서비스들이 있는데 제가 유튜브에는 그런 유튜브는 DM 기능이 없다 보니까 뭔가 사람들이 어떤 키워드 썼을 때 거기 자동 답변해 주는 이런 서비스가 제가 찾아왔을 때 안 보이더라고요. 그래서 어 뭔가 인스타처럼 어떤 키워드 작성하면은 답을 달아 주는 거를 또 만들어 보면 재밌겠다 싶어서 이것도 러버블로만 좀 만들어 봤거든요. 그래서 그 어떤 내 영상 있으면 영상별로 키워드 등록해서 어 답 이제 답글 같은 것들을 좀 다 달아 줄 수 있는. 와, 지금 어 예, 뭐 예를 들어 이제 아고다 주제를 쓰면은 예상 응답해 가지고 제가 미리 등록해 놓은 응답 메시지를 바로 달아줄 수 있어서 유튜브 이제 공식 API 이용해 가지고 뭔가 따로 얘는 뭐 불법적인 거 없이 어 혹시 너무 연속적으로 많이 요청하면은 혹시 뭐 블락킹 될까 봐 약간의 딜레이만 좀 줘서 하나씩 해주고 영상에 또 여러 개가 될 수 있으니까 한꺼번에 여러 영상에 있는 키워드들 보내줄 수 있게도 이런 식으로도 러버블로만 구현해서 일단 내가 쓰는 걸로 한번 잘 써 보고 나중에 뭐 구독자 더 많이 늘어나고 더 채널이 커지면 요거를 또 구독 서비스로도 이용 만들어 올 수 있겠다라. 어, 저 이거 잘 팔릴 것 같아요.
- - 네, 답변 같은 것도 지금 제미니 API 붙여서 실험적으로 AI 답변 생성 답글 생성도 지금 해 보고 있어 가지고 일단 제가 잘 써먹기 위해서 매일 업데이트를 하고 있어요. 와, 저 이거 보고 진짜 깜짝 놀랐던 게 물론 저도 러버블로 계속해서 개선 그니까 채팅이나 아니면 깃싱크에서 개선하면서 계속 하고 있지만 제거는 대부분 API 연결이 안 돼 있는 간단하게 바로 빠르게 응답하는 그런 거란 말이에요. 그런데 동주 님은 이거를 러버블만으로 채팅만으로 다 하셨다고 해서 진짜 깜짝 놀랐어요. 아, 이거 진짜 러버블만으로도 가능해요? 네, 이렇게 제가 비개발자 대상으로 강의하다 보니까 강의를 또 요즘 많이 하다 보니까 비개발자분들 대상으로 진행하면서 커서 넘어오면은 막 기터브나 뭐 이런 막 서드파티 연결되는 그런 관계들이 많다 보니까 처음에 그 장벽이 아무리 쉽게 준비를 해도 어려워하시더라고요. MPM 런 데브에서 실행시켜보고 이런 게 아무래도 쉽지가 않다 보니까 어떤 느낌인지 아시죠? 그래서 최대한 터미널 창만 열면은 이제 싫어하시는 분도 계세요. 터미널 창 보면 갑자기 식은땀을 내시거나 그게 또 만약 윈도우즈다 그러면 아 이게 WSL이냐 가상 머신이냐 윈도우 하시면 얘기 나오면 안 돼요. 제가 디버깅을 못 도와드린 경우들도 많아요. 어 왜 이럴까? 저도 한참을 분석하고 최대한 웹에서만 어디까지 할 수 있을까 그 한계들을 저도 좀 실험을 많이 하다 보니까 뭐 API 붙이고 슈퍼베이스 연동해서 데이터베이스나 뭐 엣지 펑션으로 API 요청할 수 있게끔 다 하는 거 하다 보니까 API 키도 안전하게 슈퍼베이스에 저장해서 이런 것들이 다 가능하더라고요. 그래서 지금 뭐 제미니 API 키도 그러고.
- - 그래서 어 내가 좀 좋아하는 분야에서 내가 관심 있는 도메인은 내가 이미 전문가니까 거기에서 디테일하게 나부터 자주 써먹을 수 있는 거 만들면 자연스럽게 남들 만하게 나오는 것 같아 가지고 제가 이 사례를 좀 퀄리티 있게 만들고 또 많이 한번 공유해 보고 싶어서 또 지금 이렇게 또 까발려 놨으니까 저는 더 열심히 업데이트하지 않을까. 아니, 그런데 이거 그 러버블만으로 구현이. 그런데 두 분 다 러버블을 쓰시는데 저는 버셀의 V0를 좀 써 봤고 사실 프론트 할 때는 저는 그냥 커서나 아니면 클로드 코드가 편해서 이제 내려서 하는 편이에요.
- - 그런데 러버블이 두 분 다 선호하시는 이유가 제일 좀 성과가 좋나요? 그게 약간 애매한데 전 솔직히 대동소이하다 생각하거든요. 기본적으로는 러버블 볼트 뭐 V0 레플이 다 있는데 V0랑 러버블을 비교했을 때는 V0는 아무래도 그 모델이 자체 모델이잖아요. 네, 그래서 그리고 제가 생각하긴 이게 아마 오픈 AI 거를 튜닝한 거 같거든요. 왜냐하면 그 오픈 AI랑 바로 URL 바꾸면 바로 호환되는 거 보면. 음 음.
- - 그런데 러버블은 아무래도 또 클로드 쏘를 쓰니까 음, 코딩 자체를 러버블이 좀 더 잘하는 면이 있고요. 그리고 한 저희가 러버블 메인으로 가자하고 결정했던 게 한 거의 한 세 달 이제 거의 네 달 전이죠. 그때만 해도 우리가 그 바이브 코딩으로 그냥 딸깍하면 우아하게 나오는 거 자체가 너무 좋았는데 그땐 러버블 UI가 예뻐 보였어요. 그래서 그래서 이제 러버블로 했던 것도 추가로 또 뭐 네 러버블에서 비주얼 에디터라든가 좀 부가 기능들이 괜찮은 게 엄청 많았거든요. 물론 이제 이게 다른 데 거의 다 많이 들어왔어요 이제. 음, 지금은 차이가 더 많이 없는 거 같기도 한데 러버블이 뭐 저는 편의 기능이 많이 좋다고 생각해서 좀 괜찮다고 생각합니다.
- - 그 제가 좀 더 덧붙이면 러버블이 비개발자분들 입장에서 뭐 API 키를 내가 슈퍼베이스 연동해서 막 거기 넣고 이런 것들이 다른 툴들에 비해서 훨씬 채팅 안에서 많이 해낼 수 있게끔 기능을 많이 제공하더라고요. 그래서 저도 최대한 실험해 보느라 뭐 유튜브 API 키를 어 API 요청하고 싶은데 이 키를 어떻게 저장할 수 있게끔 뭐 이제 구성 저는 좀 더 이제 개발자니까 좀 더 뭐 자세하게 쓰지만 그렇게 하면 여기서 프롬프트 창 뜨면서 거기에 키 API 키 입력하면은 자동으로 슈퍼베이스에 다 등록을 해 줘 가지고 그런 부분도 굉장히 괜찮고 좀 중간중간에 리팩토링 같은 것도 제안을 좀 많이 해 줘서 어 그때그때마다 코드가 복잡해지기 전에 리팩토링은 더 좀 자주하게 되더라고요.
- - 그런데 제가 알아낸 사실이 있어요. 아, 이게 러버블로만 하셨다고 했는데 엄밀히 따지면은 지금 프롬프트 입력들을 봤더니 어 개발자 용어들이 아 이게 아 그렇죠. 예, 일단 펑션에서 이제 멘붕 오실 거고. 아, 일단 슈퍼베이스라고 보통 비개발자분들은 얘기를 안 하시죠. 예, 슈퍼베이스를 모르실 수 아, 그런데 슈퍼베이스는 요즘에 많이 또 아시더라고요. 비개발자들. 아, 웬만한 건 슈퍼베이스 연동 인테그레이션 예 예. 그래서 되는데 아 저렇게 프롬프트 하는 방법론을 알려 드린 것도 되게 좋겠다라는 생각을 또 하고. 저희 강의에서 아마 동주님이 잘 말씀해 주시지 않을까 싶습니다.
- - 아, 그래서 제일 추천하는 거는 이 러버블에 대화하는 거를 개발자랑 페어로 해 보면 사실 엄청 많이 배워가고 좋죠. 사실 슈퍼베이스라는 키워드를 알면은 너무 그다음에는 요청하기 쉬운데 처음에 모르면은 내가 뭘 모르는지 그 탐색하는 시간이 오래 걸리기 때문에 그래서 약간 페어로 해 보는 게 참 좋은 거 같아요. 음, 아 좋다. 아 너무 잘 봤습니다. 힌트도 많이 얻을 수 있었고 러버블 저는 써 보진 않았는데 러버블 써 보고 싶네요.
- - 그런데 저 만 반대로 이거 그 프론트 쪽 코드를 쓰다 보니까 조금 어 가끔 가다가 이런 생각이 들 때 있어요. 이제 커서 에디터나 아니면 클로드 코드에서 커서에서 저는 보통 이제 띄어 놓고 그 거기서 이제 코드를 직접 에디트하거나 이렇게 하는데 가끔 가다가 프론트 쪽에서는 이제 물론 MPM 런 데브로 해 띄어서 확인할 수 있겠지만 그 요소 다 인스펙트해서 하기 귀찮으니까 다시 러버블이나 그 V0에서 올려서 여기서 개발해서 다시 내려서 가지고 오고 싶다 이런 생각 할 때 있거든. 그런데 그 그런 기능은 지원 안 하죠? 다시 업로드해서? 어, 그런데 그 그 기능과 별개로 혹시 스테이지 와이즈라고 써 보셨어요? 아, 안 써 봤어요. 그거 그거가 그 스테이지 와이즈가 아이디 익스텐션인데 걔를 쓰면 그 그 엘리먼트를 선택해서 걔를 내가 커서에서 그냥 아 그래요? 추정할 수 있게 돼 있어요. 예, 그 MCP 같은 거 아니고 그냥 익스텐션으로 돼 있는 거고. 아, 커서 익스텐션이요? 네, 네, 커서 익스텐션인데 그거는 저는 꽤 좋은 거 같아요. 너무 좋다. 잘 될 것 같습니다. 아, 맨날 인스펙트 해 가지고 그 요소 복사해 가지고 맨날 했. 그게 너무 귀찮잖아요. 그거를 해 주는 거예요, 사실. 아, 아, 너무 스테이지 와이즈 예 제가 링크를 남겨 놓을게요. 네, 스테이지 와이즈. 아, 오늘 또 하나 배워 갑니다. 예. 아, 슈퍼베이스 보안 이슈. 아, 그렇죠. 이제 보안 당연히 예 있을 수 있습니다.
- - 이거 혹시 이거 좀 여쭤보는 게 아직 좀 이를 수도 있을 것 같은데 그 사실 그 지금 동주 님의 사례 정도는 너무 좋은 거 같아요. 여기다가 광고를 달아서 그걸 수익을 얻는다 할지 좋은데 우리가 사실 그런 비즈니스 모델 말고 실제로 신용카드 결제를 받거나 요렇게 유지하고 싶은 서비스를 만들고 싶을 때도 있잖아요. 그럼 결제 모듈 붙여야 되고 결제 모듈 아까 뭐 스트라이프 이런 거는 바로 붙나 봐요, 요즘에는. 네, 스트라이프는 러버블의 인테그레이션이 있어요. 아, 있구나. 그럼 뭐 그걸로 해도 되겠네요.
- - 그런데 뭐 다 대부분 아시겠지만 스트라이프가 한국에서 사업자가 그러니까 미국 사업자가 있어야 쓸 수 있잖아요. 스트라이프라든 뭐 이런 거 있어야 쓸 수 있고. 그래서 보통은 뭐 페이팔 뭔지 정확히 까먹었는데 페이팔 해외 결제인가 뭐 그런 걸로 하던가 아니면 레몬 스키지 패들 이런 걸로 하던가 아니면 토스페이먼츠에서 해외 카드로 붙여서 하던가 이런 식으로 하시는 거 같아요. 음, 토스페이먼츠는 해외 카드 붙인다는 말은 그게 국내 카드는 아직 지원 안 해서 그런 거예요? 토스페이먼츠에서 해외 카드로 결제 그니까 해외 결제하는 걸 지원한다고 들었던 거 같거든요. 아, 이게 글로벌 서비스를 만든다는. 예, 아 그렇군요. 어, 토스 페이먼트 MCP 잘 된다라고도 말씀해 주셨고. 아, 토스가 확실히 좀 그런 데서 앞서 나가는 거 같아요. 금융권에서 그런 기능 기반. 네, 그러면은 질문드리고 싶은 게 이게 두 분께서는 진짜 개발자이시니까 이거 만약에 만들었어요. 결제 받아서 어 사용까지 간다라고 봤을 때 어떻게 보세요? 만약에 이게 잘 돼요. 서비스가 잘 돼서 지금 월간 사용자가 뭐 몇만 명 이상으로 유지가 돼요. 그러면 그 시점에서는 개발자를 고용해서 안정화하면서 가야 될까요? 아니면 이렇게 하면서 계속 AI 쓰면서 사실 그 자영업자라고 표현해야 되나 그냥 내가 회사에서 근무하신 분들은 그냥 사이드잡으로 유지하고 싶으신 분들 계실 수 있잖아요. 그게 어느 수준까지 가능하냐 이런 거 어떤 많이 물어보시거든요. 어느 수준까지 가능하냐 어떻게 보세요?
- - 요즘 딱 오늘 시점에서 그게 이게 제가 솔직히 함부로 말씀드리기 어려운 게 제가 그렇게 안 만들어 봤기 때문에 그 얘기를 하기는 어려운데 주변 사례를 보면 약간 좀 선택을 하시는 거 같아요. 그러니까 이거는 그냥 라이프스타일 비즈니스로 딱 이 정도 스타 기준까지만 수준까지만 내가 그냥 운영하겠다 운영비도 안 늘리고 사람 안 늘리고 내 비용을 안 들이면서 그냥 최적화만 하겠다 같은 분들도 있고 이걸 계속해서 확장해 나가서 아예 개를 뭐 업으로 삼으시는 분도 있고 뭐 그런 거 같아요. 음, 이거는 그 사실 바이브 코딩 시대라고 해서 비개발자가 창업이 쉬워졌다고 하지만 결국 이게 따지고 들어가면 결국 애자일 개발 방법론이든 아니면 솔로 플레이어들이 예전에 하던거든 거의 거의 그때부터 똑같은 것 같거든요. 막 해야 되고.
- - 그래서 이게 바이브 코딩 시대가 돼서 달라진 거는 크게는 없는 것 같다 별 생각은 저는 들긴 합니다. 그런데 이게 이 다 헛소리일 수 있다는 건 젖혀두고 네 저 잘 모르기 때문에 할루시네이션 예 네 네. 할루시네이션 있습니다. 아직은 과도기 단계다 보니까 이제 바이브 코딩으로 코드를 구현하고 유지 보수하는 리소스가 줄어든 건 맞지만 원래 서비스랑 소프트웨어를 운영한다는 거는 뭐 CS도 있고 더 그 여러 가지 현실 세계 맥락들이 얽혀 있는 것들이 많다 보니까 이걸 진짜 내가 어떤 서비스로 일반 사용자 대상으로 뭔가 운영한다 하면은 개발자 수는 뭐 좀 뭐 한두 명이나 더 적게 운영은 가능하겠지만 기존에 필요하던 것들도 비슷하게 아직은 필요해서 막 드라마틱하게 아직 뭐 엄청 큰 변화가 있다 막 그렇게까지는 아직은 좀 보기 어려운 것 같긴 해요.
- - 음, 저는 약간 뭐랄까 양극단으로 좀 갈 거 같다는 생각도 들어요. 그러니까 훨씬 더 작은 유틸리티 앱들이 진짜 범람을 하고 그런데 걔네들이 막 가격 경쟁도 하고 기능 경쟁도 하고 하는 그런 것들이 범람을 하고 그게 뭐 그래 그게 꼭 아 사스가 아니더라도 뭐 크롬 익스텐션일 수도 있고 피그마 플러그인일 수도 있고 아니면 뭐 일렉트론 앱일 수도 있고 뭐 그런 것들이 범람을 하는 한편 걔네들을 약간 뭐 잘 종합해서 뭐 에이전트까지 붙인 진짜 고도화된 서비스들이 비싸게 나온다거나 이런 이런 양극단으로 가지 않을까 이런 생각이 좀 들어요. 음, 어 그렇군요.
- - 아, 아 저도 저 개인적인 마음은 이제 그 상용화까지 안 가고 거기에 사람 역할을 하는 게 좀 조금 더 오래 유지됐으면 좋겠다라는 생각이 들면서도 반대로 비개발자분들에게는 저는 이거 되게 좋은 희망 같은 거라고 생각이 들거든요. 왜냐하면은 왜 개발자의 그 지금까지 개발자가 아이 콧대가 조금 높았다라고 표현하면 좀 그럴 수도 있는데 그 그니까 그들의 상상력을 구현해 주는 능력이 엄청난 거잖아요. 그런데 그래서 이제 아이디어가 뛰어난데 그 개발자를 어를 고용해서 하려니면 투자를 하려니 굉장히 막대한 비용이 들기 때문에 그 아이디어를 현실화 하지 못하신 분들이 되게 마음속에 한이나 아 이거 한번 해 보고 싶은데 이런 분들이 되게 많았는데 이제는 그걸 당장 현실화 할 수 있는 시대가 된 것 같아서 저는 그런 부분에 대해서는 되게 또 긍정적이다라는 생각이 듭니다.
- - 그니까 그 개발자분들이 오히려 마음이 좀 교차하는 것 같아요. 그러니까 비개발자분들은 상상력을 굉장히 적은 비용으로 현실화할 수 있는 시대가 됐는데 개발자의 입장으로서는 어 요거에 이게 AI가 하는 정도의 밸류에이션은 이제 못 받겠구나라는 생각이 들면서 개발자도 역시 고민이 많아지는 그런 시대인 것 같습니다. 아 네 뭔가 그 기획하시던 분들은 개발을 배우고 개발하던 분들은 기획을 배우고 이렇게 약간 좀 어 크로스 펑셔널하게 되는 것 같아요. 맞습니다, 맞습니다. 예, 맞습니다, 맞습니다.
- - 혹시 좀 어 러프하게 또 하나 질문의 화두를 던져 보면 이제 앞으로 개발자의 역할은 어떻게 변할 거라고 보세요? 음, 사실 저희가 지금 대체하냐라고 봤을 땐 지금은 대체 못 하겠죠. 하지만 이거는 어떻게 보면 저희도 알다시피 약간 시간 문제라는 생각이 들 때가 있어요. 그러니까 제가 2, 3년 전에 누군가가 나한테 채찍이가 나와서 이거 어 이거 코딩도 이렇게 잘해 주는데 대체하는 거 아니 에이 코딩은 대체 못 하죠라고 얘기했을 것 같거든요.
- - 요즘 드는 생각은 딱 이런 거 같아요. 지금 얘가 개발자보다 코딩을 잘해서 대체된다고 느끼는 게 아니라 0에서 80점까지 오는 속도가 너무 빨라서 80점에서 100점 120점 뛰어넘는 게 오래 걸리지 않 않겠다라는 생각이 드는 게 너무 무서운 점인 것 같거든요. 두 분의 생각이 좀 궁금합니다. 이거는 거장님께서 먼저. 아, 거장님의 거장님의 어려운 질문은 역시 거장님의 생각부터 먼저 들어봐야죠. 아, 그 요거는 계속.
- - 그런데 그거인 것 같아요. 원래 미래가 좀 막연할 때는 비슷한 과거에 다른 사례들을 보는 게 도움이 되잖아요. 그래서 저 아까 좀 초반에 바둑 이야기를 했는데 바둑계에 어떤 변화가 일어났고 지금 어떻게 되고 있는지에서 그냥 일단 힌트를 많이 얻으려고 하거든요. 왜냐하면 미래는 저도 뭔가 점쟁이가 아니니까. 그래서 바둑 쪽도 원래는 좀 AI가 나와서 초반에 두 가지 파로 좀 나뉘대요. AI가 둔 거를 공부하자 파와 그다음에 그럼에도 불구하고 인간만이 둘 수 있는 이 바둑도 어떻게 보면 예술의 경지로 올라가니까 인간만이 둘 수 있는 수를 고민하자 이렇게 있는데 지금 이제 세계의 최정상을 차지하고 있는 거는 AI 쪽을 공부하고 AI 의도를 분석해서 내가 AI스럽게 생각하고 또 두는 그런 분들이 그걸 학습해서 최 최 최정상위권을 그 유지하고 계셔.
- - 뭐 대체될지 안 될지는 모르겠지만 적어도 내가 개발자로서의 어떤 아이덴티티와 그 커리어를 만들어 나가자 한다면 AI가 짜 주는 코드를 내가 뭐 리버스 엔지니어링하든 재구축하든 그 아키텍처를 내가 뭔가 설명할 수 있든 그릴 수 있든 그 AI가 짜 준 코드의 그 수들을 내가 이해하고 써먹을 수 있는 그런 학습을 한 사람과 정말 그 코드를 그대로 쓴 사람 약간 요거의 양극화가 좀 심해지는 그런 변화가 생기지 않을까 싶어요. 그래서 아마 개발자라는 직업은 사라지지 않겠지만 개발자라는 직군의 수는 못 줄어들 수도 있고 역할들이 또 변할 수도 있긴 할 것 같아서 뭔가 어떻게 될지 모르겠지만 일단은 AI랑 자 협력해서 내가 더 똑똑해지는 경험을 일단 많이 만들어 봐야겠다 저는 거기에 일단 집중을 해 보고 있습니다. 어떻게 될지 모르겠어요. 저도 잘릴 수도 있고 휘님도 할루시네이션 휘님도 잘리기 전에 어떻게 퇴사하신 걸 수도 있고 모르기 때문에 일단 지금은 AI를 통해서 내가 더 똑똑해지는 거에 좀 집중하자.
- - 아, 그런데 제가 하나 좀 재밌는 포인트 하나만 좀 소개하고 싶은 게 어 제가 저희 회사의 디자이너분들이 거의 산 저희 회사의 개발자분들보다 AI를 또 되게 잘 쓰시거든요. 음, 그래서 다른 데서 저희 사내 사례 공유할 때 디자인 사례도 같이 좀 공유를 하는데 제가 요거 잠깐만 화면 공유를 좀만 보여 드릴게요. 네, 뭐 개발자분들은 살면서 한 번도 생각해 보지 못한 부분들일 수도 있는데 요런 시선이 앞으로 좀 중요해지지 않을까 하는 포인트가 있어서 그 배달의 민족에 지금은 지금 디자인 우리 디자인 해 가지고 좀 달라지긴 했는데 요런 요런 느낌의 디자인들이 되게 많잖아요. 예, 그런데 지금 요게 다 AI로 그린 거거든요. 음, 야, AI로. 그런데 원래 AI로 이렇게 잘 그려주지 못했어요. 그래서 그래서 이 원래는 예, 요런 걸 만들 때 사실 저기 사람 다 컴퓨터 그래픽인 줄 아는데 왼쪽에 영상 보는 것처럼 손으로 다 깎고 포토샵으로 약간 디테일 잡아서 저기서 그냥 컬러나 이런 거 좀 입혀 쓰는 거일 정도로 되게 수작업이 많이 들어가는 디자인 작업 과정이었거든요. 아, 그래서 정말 노동이 많이 드는 건데요. 그로 인해서 되게 유니크한 디자인은 나오지만 대신에 손이 많이 들어서 뭐 프로모션이나 새로운 뭐 포스터나 그 웹에 들어갈 이미지 만들 때 시간과 비용이 엄청 많이 들었어요.
- - 그래서 아 디자이너분들이 이렇게 하다가 우리가 죽어 나가겠다 해 가지고 어 이런 식으로 해 가지고 막 요렇게 원래 디자인 자산들을 되게 많이 만들었는데 어 이 기업에서 디자인을 이제 커머셜로 잘 만들기 위해서 중요한 사고 방식이 일관된 비주얼 언어로 디자인 자산을 만드는 게 정말 중요하거든요. 한 사람이 만든 것처럼 만들어야 되는 어떻게 보면 개발도 여러 사람들이 만들지만 서로 완전히 다른 스타일로 코드 짜거나 이러면 안 되잖아요. 예, 그럼 디자인도 일관된 비주얼 언어로 디자인 자산이 나와야 되는데 어떻게 하면 AI로 일관된 비주얼 언어로 디자인 자산 만들 수 있을까? 이게 되게 어렵거든요. AI로 이미지나 이런 거 채찍필터로 만들어 보신 분도 알겠지만 사람도 뭔가 일관되게 만들기 좀 어렵고 원하는 스타일이 다 약간 미묘하게 마음에 안 드는 경우들도 되게 많잖아요.
- - 그래서 이제 디자이너분들이 이거 실험을 진짜 많이 했는데 되게 재밌는 게 딱 하나의 자산을 이미지를 넣으면은 배민 스타일의 디자인이 잘 나오는 거예요. 너무 이게 좀 흥미로운 포인트인데 요런 것들이 요런 것들에 에센스만 쏙 뽑는 걸 했어요. 어 요런 것들에서 뭐 컬러나 뭐 구성 형태나 이런 것들을 다 빼고 더 이상 나눌 수 없는 딱 하나를 남긴다면 뭘까 했을 때 요런 스컬피 형태에 되게 미니멀한 조각을 하나 넣고 그다음에 오토바이를 만들어 줘. 아, 그다음에 비닐봉지를 만들어 줘 하는 식으로 요청을 하는 거예요. 그래서 요걸 놓고 이 자산을 놓고 오토바이를 그려 줘 하면은 배민 스타일 오토바이 이렇게 만들어 줘요. 훨씬 더 잘.
- - 그래서 요거는 이제 어도비의 파이어플라이라는 건데 어도비의 파이어플라이가 약간 이런 이미지의 그 에센스를 좀 넣고 나면은 그거 기반으로 좀 되게 잘 만들어 주는 편이어서 요렇게 만들고 나서 그 중에 좀 마음에 드는 거 하나 선택하고 그다음에 디자이너분들한테 약간 그림자 넣고 컬러 살짝 입히고 기존에 일단 자산 넣고 이런 거는 사실 되게 쉬운 거거든요. 디자이너분들한테는 개발자들에게 어렵지만. 그래서 사실 요거 만드는 게 어려운 건데 메인이 되는 이 오브젝트가 요거를 AI로 에센스를 넣어서 만들 수 있게. 그래서 이제 흰색에 이 에센스를 넣는데 어 이 에센스를 어떻게 넣으면은 더 잘 나올까 실험하다 보니까 명도 대비가 더 확실한 더 작은 오브젝트 두 개를 넣어서 또 만들어 보기도 하고.
- - 어 나중에 컬러 입히는 거 귀찮은데 처음부터 컬러 입혀서 넣어 보자. 그래서 이런 민트 컬러나 블랙이랑 랑 이제 브라운 컬러 이렇게 넣고 오토바이 그려 줘 하면 한 방에 이제 나중에 될 것들이 더 적어지게끔 한 방에 또 만들어 주기도 하죠. 그래서 그리고 이미지 보통 우리가 개발할 때는 프롬프트를 처음부터 컨텍스트나 이런 걸 구조하고 길게 쓰는 게 많은데 이미지는 오히려 문장 길게 쓰면은 어텐션이 여러 가지 많이 들어가서 오히려 괴상하게 나온 경우들이 많고 오히려 프롬프트를 되게 짧게 쓰시더라고요. 그래서 어 민트 범피 스쿠터 피규어 뭐 하나 뭐 화이트 백그라운드 프런트 뷰 해서 진짜 비주얼을 간결한 어휘로 표현을 해서 이런 식으로 만들고. 그래서 뭐 바나나 이런 것들을 다 일관된 키 비주얼 언어로 이제 만드는 걸 했는데 저는 이제 가장 인상적이었던 게 아무래도 이런 에센스를 뽑는 사고 방식.
- - 그래서 그 그래서 리버스 엔지니어링이 말이 되는 게 이게 개발 아키텍처 어차피 어차피 에센스 코어가 되는 어떤 그 뼈대가 되는 구조들이 있을 거니까 그걸 딱 뽑아내고 그걸로 먼저 주어져서 여기 이 골격에서부터 시작하게 만들면 일관된 품질의 어떤 무언가가 나올 수도 있겠네요. 그러니까 더 개발 용어로 바꿔 보면 약간 PRD 작성할 때도 우리가 뭐 뭐 똑같은 서비스를 만드는데 다 10명이 PRD 작성하면 다 다른 결과물이 나올 건데 거기에서 뭐 어떤 조직에 추구하는 어떤 철학이 들어갈 수도 있고 방법론이 들어갈 수도 있는데 그런 것들은 이제 최대한 줄여서 어 만들어 놓고 그걸 기반으로 이렇게 하는 것들도 좋은 접근 방법이 될 수가 있겠네요. 그래서 내가 지금 하는 거의 에센스가 뭐지를 잘 캐치하면은 AI에 더 똑똑하게 잘 쓰게 되는 것 같아서 저도 약간 연관 받아서 이런 에센스 뽑아서 이제 디자인 자산 만드는 거 막 실험해 봤거든요. 이런 막 클레이 말 띄어 가지고 클레이로 말을 한번 만들어 본 다음에 귀여워서 이걸 또 에센스 클레이 에센스를 딱 뽑고 그다음에 이제 12지신 같은 거 사람 이렇게 만들어 본다든가 일관된. 예, 그래서 아까 개발도 방금 말씀드린 것처럼 뭐 리버스 엔지니어링 해서 지금 전체 아키텍처에 아키텍처 이런 것도 어떻게 보면 에센스잖아요.
- - 그런 것들을 내가 포착하는고 훈련하고 학습하는 그거를 경험해 두지 않으면 이 AI 시대에는 더 빈익부익부 양극화가 심해질 수밖에 없기 때문에 그 차이를 만드는 좀 중요한 포인트가 되지 않을까라고 할루시네이션일 수 있지만 저는 개인적으로 그 부분이 좀 중요하다고 생각을 하고 있어요. 너무 재밌다. 그러면은 저는 이렇게 할 거 같아요. 예, 저 하나만 하나만 그 저희가 그 시니어 개발자로서의 학 성장 방법에 대해서 얘기한다고 했다가 지금까지 못 한 거 같은데 마침 동주님 얘기하신 거 약간 연결이 되는 거 같아. 예, 예.
- - 사실 시니어 개발자의 어떤의 뭔가 존재 의미 중에 하나가 엄청난 도메인 경험과 안묵지잖아요. 네, 이것들을 좀 에센스로 뽑아내서 주니어들에게 전달하는 또는 주니어가 아니죠 뭐 약간 클로드 코드한테 전달하려고 해도 그 뻔 그것들을 훈련하는 것만 해도 사실 그 안목지가 명시지로 전환되는 과정에서도 학습이 엄청 많이 일어나거든요. 그러니까 그것만 열심히 훈련을 해도 저는 시니어 개발자들이 좀 다 자기 조직 안에서 주니어를 키우면서 영향력 행사하는 한 몫을 다 잘하지 않을까 이런 생각이 좀 들고 있습니다. 음, 너무 좋은 포인트인 거 같아요. 제가 좀 더 아이디어를 발전을 시켜 보면 저희가 회사 안에서 자산이라고 하는 것들 중에서 코드가 되게 중요한 자산이 되는데 이제는 코드 제너레이션 하는 그 비용이 좀 덜 들면 사실 지금 보니까 그 코드 에센스가 어떻게 보면 회사의 어떤 되게 중요한 자산이 될 수도 있을 것 같다는 생각이 들어요. 왜냐하면은 그 에센스를 토대로 만들어내는 결과물은 비용이 적을 테니까.
- - 어 그래서 그 기업마다 그 에센스를 더 정교하게 만들고 더 코어 밸류를 계속 업데이트해 나가면 그 어떤 서비스든 이 에센스에서 발전시켜 나가면 일관된 어떤 품질의 그 결과물이 나올 테니까 어 그런 것들도 충분히 있겠네요. 그러니까 기업에서 그 시니어 개발자들한테 야 너 오래 다녔잖아 그러면은 에센스 우리 잘 뽑자. 이거 맞아? 그러면은 또 피드백을 줘서 아 여기서 또 디벨롭하고. 그러면 주니어들은 그 에센스 선배님들이 만들어 놓은 에센스를 토대로 이제 바코드 코딩을 하든 뭐 해서 만들면은 그냥 아무것도 없는 거에서 만드는 거보다 훨씬 더 좋은 결과물 그리고 선배님들이 만들어 놨던 어떤 그 품질을 이어받아서 일관된 뭔가 결과물이 나올 수가 있겠네요.
- - 딱 그 정확한 걸 휘동 님이 또 굉장히 많이 하셨어 가지고 시니어 개발자들이 디버깅할 때와 주니어 개발자들이 디버깅할 때 그 차이점을 분석해서 에센스를 프레임워크로 만드신 것도 있거든요. 제가 제가 화면 공유 제가 할 테니까 휘동님이 한번 설명해 주시면 좋을 것 같아요. 제가 화면 공유로 이거 이것도 풀 서비스로 만들어 내신 거예요? 아니요, 이거는 저희가 작년에 그 넥스트 스텝이라고 그 얘 넥스트 스텝이 정확히 뭐였죠? 넥스텝이 제가 같이 운영하는 교육 플랫폼입니다. 그러니까 우한 테크코스랑 비슷하게 정확히 우한 형제들 소속은 아니지만 그 안에서 같이 같이 건물 같이 쓰면서 교육할 수 있는 그런 곳인데 거기서 저희가 이펙티브 디버깅이란 이름으로 약간 AI도 쓰고 좀 효과적으로 그 디버깅하는 방법에 대해서 그 분석 전문가 인터뷰 이제 뭐 토스 여러 개발자랑 뭐 여러 시니어 개발자들 인터뷰하면서 그 에센스를 뽑아 가지고 어떻게 하면 전문가처럼 디버깅할 수 있을까를 방법론으로 만든 다음에 그걸 교육하는 걸 했었거든요. 동주님과 같이.
- - 네, 그런 게 우리가 얘기한 그 약간 추상적 지금까지 약간 추상적이었다 하면 이런 것들이 좀 에센스가 될 거 같아요. 실제로 뽑아낼 만큼. 그래서 지금 화면 공유하고 있는 게 디버깅할 때 이제 보통 초보자나 주니어 개발자들이 이제 먼저 식은땀을 흘리면서 이게 왜 안 되지 이러다가 구글링을 하고 있다면 좀 더 시니어 개발자들은 어 이게 지금 문제가 뭐지? 그걸 남들한테 뭔가 설명할 수 있을 정도로 정의가 뭔가 바로 되고 그다음에 이게 올바르게 동작되면은 어떤 상태여야 되지? 그 차이점이랑 그 결과를 어 최종적으로 만들어야 되는 아웃풋을 생각을 하고.
- - 그다음에 그 버그가 일어난 상황을 재현해 볼 수 있는 최소한의 그 비용을 적게 들여서 테스트해 볼 수 있는 최소 재현 환경 구축해서 관찰하고 그 차이를 발생시키는 원인을 탐색하고 그 하나씩 가설들을 한번 검증하고 이런 단계들을 무의식적으로 되게 빠르게 팽팽 도는 거를 휘동님이 인터뷰해서 이게 쫙 정리를 해 주셨거든요. 요거 가지고 한번 의식적으로 한 단계씩 하는 걸 실험을 해 봤는데 요런 에센스를 뽑아내면 이제 AI한테도 그냥 이 문제 디버그 났으니까 해결해 줘가 아니고 이런 사고의 연쇄 과정을 넣어서 하면은 아무래도 더 일관되게 그 일관되게 디버깅하는 구조를 만들어서 우리 팀이나 회사에서도 더 똑똑한 디버깅 프레임워크를 만들어 나갈 수 있을 것 같아요.
- - 음 음. 이거를 해 보면 좋은 게 2번만 가도 아 내가 올바른 동작이 뭔지도 모르는구나 이런 게 딱 떠오르면서 그럼 올바른 동작을 정의하려면 내가 예를 들면 시니어 누굴 찾아가야 되지? 아니면 PM을 찾아가서 스펙에 대해 얘기를 해 봐야 되나? 아니면 아 이거 로그를 더 심어 봐야 되나? 이런 게 나오거든요. 그래서 초반 단계만 하더라도 굉장히 도움이 많이 돼서 이거를 저 실전에서도 많이 써 먹었고 교육할 때도 써먹고 그렇게 했었습니다.
- - 그럼 이걸 써먹는다는 관점에서 봤을 때 이 5단계 프레임워크를 순차적으로 실행을 하면서 어 어 다 여기까지니까 체크를 하는 방식으로 진행을 한다라고 이해하면 될까요? 약간 AI 시대에 걸맞게 얘기하면 좀 인터랙티브하게 핑퐁을 계속 하는 것 같아요. 그러니까 이게 코드와 내가 핑퐁을 하든 아니면 나 혼자 내 내가 그냥 생각하면서 종이랑 핑퐁을 하든 AI랑 핑퐁을 하든 그냥 이게 이 단계가 정말로 내가 문제가 잘 정해졌는가? 그런데 밑에 갔다가 어 문제가 달랐네?

이 토론은 **바이브 코딩**과 **AI 시대의 개발자 역할 변화**에 대한 깊이 있는 대화를 담고 있습니다. 연사들은 **AI의 코딩 능력 수준**을 주니어 개발자의 약 2~3년 차 수준으로 평가하며, **AI를 활용한 효율적인 학습 및 작업 방식**에 대해 논의합니다. 특히, **AI가 생성한 코드의 품질을 판단**하고 **예측 불가능한 상황에 대처**하는 **시니어 개발자의 역할**과 **AI 시대를 위한 개발자의 성장 전략**에 집중합니다. 또한, **AI 도구를 활용하여 자신만의 유틸리티 앱을 개발하고 수익화**하는 실제 사례를 공유하며, AI가 가져올 **새로운 비즈니스 기회와 개발자 직업의 미래**에 대한 흥미로운 전망을 제시합니다.