- Turing Post Korea
- Posts
- AI와 함께하는 코딩의 미래: Eli Hooten과의 인터뷰
AI와 함께하는 코딩의 미래: Eli Hooten과의 인터뷰
소프트웨어 엔지니어가 갖춰야 할 핵심 스킬, 오픈소스의 역할, 코딩 생산성을 배가시켜줄 AI와 공생하기
생성형 AI의 잠재력이라든가 쓸 만한 곳을 이야기할 때 항상 상위권으로 랭크되는 영역이 바로 ‘코딩 (Coding)’입니다. ‘Github Copilot: 당신의 AI 동료 프로그래머’, ‘OpenAI Codex: 자연어를 코드로’, ‘Devin: 최초의 AI 소프트웨어 엔지니어’ 같은 헤드라인은 전 세계 개발자 커뮤니티의 상상력을 사로잡고 흥분시켰죠. 우리나라의 기업에서도 생성형 AI를 개발 작업에 활용하는데 큰 관심을 가지고 있습니다 - 그게 새로운 코드를 만들어 내는 것이든, 아니면 메인프레임 코드를 파이선 코드로 전환하는 마이그레이션이든 간에요.
오늘은, 컴퓨터 사이언티스트이자 개발자, 기업가인 일라이 후튼 (Eli Hooten)과 함께 생성형 AI가 소프트웨어 개발에 미치는 영향에 대해서 이야기해 봅니다. 모바일 로봇 공학, HCI (Human-Computer Interface), 소프트웨어 테스팅, 프로그래밍, CI/CD, 코드 분석 및 자동화 분야에서 많은 경험을 쌓은 일라이는 자신만의 독특한 관점으로 이야기를 풀어냅니다. 반더빌트 대학교에서 박사 학위를 받은 후, 일라이는 GameWisp를 공동 창업해서 6년 동안 CTO로 일했습니다. 여기서 제품 설계를 이끌고 소프트웨어 팀을 키우는 과정에서, 신뢰하기 힘든 코드에 대한 불만이 많았다고 합니다. 이런 깨달음을 바탕으로, 코드 커버리지 (SW 테스트에서 사용하는 지표 중 하나로, 코드 실행 여부를 바탕으로 코드의 품질과 완성도를 측정하는 방법) 솔루션 Codecov에 공동 창업자 겸 CTO로 합류했습니다. 이후 Codecov가 Sentry에 인수되었고, 현재 일라이는 Sentry의 엔지니어링 디렉터로 일하고 있습니다.
이 인터뷰에서는, 생성형 AI가 소프트웨어 개발 환경에 미치는 영향, 그리고 향후 몇 년간 개발자가 ‘코딩 자동화’ 관점에서 기대할 만한 것들이 무엇인지에 대한 일라이의 생각을 살펴볼 수 있습니다.
Q. 일라이 안녕하세요? 인터뷰에 응해주셔서 감사합니다. HCI (Human-Computer Interaction)을 공부한 입장에서, 지금 우리가 경험하고 있는 ‘생성형 AI 혁명’이 올 것이라고 예상했나요?
제가 공부하고 연구한 것들을 생각해 보면, 아마도 제 살아 생전에 AI 분야에서 이런 발전이 이루어질 거라고 생각하는 것 자체는 어찌보면 당연할 겁니다. 그렇지만, 일반 대중들이 지금같은 방식으로, 지금같은 규모로 AI를 접할 것이라고는 예상 못했고, 이런 발전이 이렇게 빨리 이루어질 거라고도 생각 못했습니다. 10년 전만 해도 Copilot이나 ChatGPT 같은 AI 도구가 늘상 하는 업무들에 의미있는 도움이 될 거라고 상상을 못했는데, 어느새 그런 세상에 살고 있네요.
Q. LLM이 개발 - 특히 코딩- 의 방법, 관행을 변화시키고 있는데요. 혹시 코딩이나 테스트 하는 과정에서 실무적으로 LLM을 테스트 또는 활용해 보셨나요? 만약 해 보셨다면, 쓸만한 곳은 어떤 곳들이고, 어떤 한계가 있다고 생각하세요?
코딩이나 테스트에 LLM을 적용해 보려고 몇 가지 모델을 써 봤는데, 사실상은 ChatGPT를 주로 사용하고 있어요. 제가 느낀 가장 큰 한계점은, 그냥 ‘전반적으로 코드를 개선하거나 오류를 찾는 방법’과 같은 질문은 별 쓸모가 없다는 거예요. 우리는 빨리 작업을 하니까, LLM에 개발자가 뭔가 개선을 해 달라고 요청하면 바로 도움이 되는 답변을 내놓기를 바라지만, 실제로 그렇게 하긴 힘들어요. 질문을 어떤 식으로든 수정해 가면서, 운이 좋아서 효과가 있을 때도 있지만. LLM이 진짜 유용해질 때는 언제냐 하면, 확실히 집중해야 할 코드 부분이 파악이 되고 나서 “이 코드에서 정확히 어떤 부분을 변경해야 하는지 알려줘”같은 요청을 할 수 있을 때예요.
그리고, 자주 잊어버리기 쉬운 것들을 찾고 싶을 때 큰 도움이 돼요. 개발자들이 잊어버리기 쉬운 정규 코드 표현식이라든가, 소프트웨어 개발하면서 필요는 한데 어려운 내용이 나왔을 때, 프롬프트로 물어보면 LLM이 구체적인 답을 잘 해 줍니다. 물론 더블체크는 필요하지만, 옛날 코딩 공부할 때 봤던 책을 뒤지거나 StackOverflow 사이트에서 찾는 것보다는 훨씬 편하고 빠르죠.
아직 남아있는 한계라면, LLM이 생성한 코드가 실제로 좋은 코드인지 여부를 판단하는게 어려운 문제라고 생각해요. 몇 가지 이유 때문인데요:
가끔은 생성된 코드가 그냥 누가봐도 나쁜 코드일 때가 있어요. 아마 문제 정의를 잘못했거나 아니면 풀어야 하는 문제를 적당히 정의해서 그럴 수 있어요.
사실 ‘좋은 코드’라는 게 어느 정도는 주관적일 수 밖에 없고, 그래서 품질 표준 자체도 보통 개발 팀간에 논의하고 합의를 해야 하는 거죠. 어떤 팀 입장에서는 뭐 충분히 좋다고 생각하는 코드가 다른 팀이라든가 다른 프로그래밍의 맥락에서는 전혀 받아들일 수 없을 수도 있습니다. 이 부분은 하나의 절대적인 답이 있는 게 아니라서, 지금 사람이 쓴 코드에 하듯이, 개발하는 팀들이 스스로 설정해서 사용할 수 있는 외부의 코드 품질 진단 도구에 의존할 수 밖에 없을 겁니다.
Reply