안녕하세요. 저는 스켈터랩스라는 회사에 다니고 있는 오윤명이라고 합니다.

어, 오늘은 AI 시대 앞서 설명드렸듯이 AI 시대의 파이썬 개발자가 쌓아야 할 비파이썬적 소양들이라는 주제로 발표를 하게 되었는데요.

먼저 파이썬을 주제로 한 그 파이콘에서 비파이썬적인 내용들을 많이 다루는 제 발표를 선정해 주신 파이콘 관계자 여러분들께 감사의 말씀을 전하며 발표 시작하도록 하겠습니다.

실례죠? 어떻게 넘기는 거죠? 아, 이제 되네요. 아, 네. 저는 생명과학을 전공하였는데요.

어, 뇌과학에 원래 관심이 많아서 생명과학을 전공을 했다가 이쪽에서 딱히 뇌과학 쪽에서 커리어를 쌓고 있지 않다가 이제 2016년쯤에 알파고가 유명해지면서 AI라는 것에 대해서 기술에 대해서 알게 되었습니다.

그때 이제 제가 예전부터 관심이 있었던 어, 뇌과학 쪽에 뭔가 공부를 인공지능을 통해서 할 수 있지 않을까라는 기대감에 AI, 자연어 처리 개발자로 커리어를 새롭게 시작하게 되었는데요.

처음에는 이제 파이썬도 잘 모르고 AI도 잘 모르다 보니까 그쪽 공부를 굉장히 많이 했었습니다.

그때는 이제 코딩이 개발자에게 중요하고 어 잘해야 된다는 생각에 굉장히 공부를 많이 했었는데 점점 시간이 지날수록 저에게 주어진 업무는 파이썬을 코딩하는 업무보다는 이제 관리하는 업무들, 그다음에 팀장의 역할들이 많이 부여되었었습니다.

그러면서 좀 많이 불안했었는데요. 개발자는 코딩을 잘해야 되는 거 아닌가?

그다음에 AI가 코딩하는 시대에 제가 더 점점 더 코딩 실력이 뒤쳐지면 어떡하지?

뭐 이런 좀 불안감들이 계속 어 최근에 많이 저에게 심어져 있었습니다.

그런데 이제 스켈터랩스라는 회사에 와서 뭔가 제가 다시 한번 코딩보다는 뭔가 그 외적인 업무들을 많이 하면서도 제가 많이 성장하고 있다는 느낌을 받았고 제가 지금 하고 있는 일이 개발자로서 중요한 커리어라는 생각을 많이 하게 되었는데요.

그래서 오늘은 제가 좀 특이하지만 코딩보다는 다른 업무들을 어떤 것들을 하면서 그게 왜 얼마나 중요하게 느꼈는지를 다뤄보려고 합니다.

네. 간단하게 목차는 이렇고요. 먼저 AI 시대의 개발은 다른가에 대해서 얘기를 해 보도록 하겠습니다.

어, 요즘에 이제 여러분들 AI 많이 쓰시잖아요. 실제 업무하실 때 많이 쓰시고 생산성도 많이 올라갔다고 느끼시는 거 같은데요.

어, 한편으로 생산성이 올라가서 좋고 또 업무를 하기 편해졌지만 더 많은 이제 생산성을 요구받게 되고 어, 코드를 저희가 짜기보다 AI가 더 잘 짜면서 어떤 위기감을 느끼시는 분들이 많을 거라는 생각이 듭니다.

어, 요즘에 또 AI 코딩이란 말이 유행을 하는데 단순히 용어만 유행하는 게 아니라 이런 회사들이 생긴 지 얼마 안 된 회사들이 꽤 높은 금액에 매각이 되고 있죠.

또 윈드서프라는 회사가 최근에 유명했는데 오픈 AI랑 구글이 인수 경쟁을 벌이기도 했습니다.

단순히 바이빗 코딩이라는 회사가 인수되는 것이 아니라 개발자가 AI로 대체되는 일도 이제 일어나고 있는데요.

실리콘 밸리에서만 일어나는 것이 아니라 한국에서도 어쩌면 이제 수급 개발자들이 자리를 잃으면서 어 개발자들이 점점 AI로 대체되는 거 아닌가라는 생각이 이제 멀티모달 LLM이 있다고 생각하는데요.

어, LLM을 모르시는 분들도 있을 것 같아 잠깐 쉽게 설명을 드리면 아, 쉽게 예시를 들면 여러분들이 쓰시는 채 GPT나 뭐 구글 제미나이 같은 서비스들이 이제 멀티모달 LLM이 되겠죠.

이런 만능 함수들이 있고 얘네들은 텍스트, 이미지, 오디오, 비디오 뭐 코드까지 입력을 받아서 똑같은 텍스트, 이미지, 오디오, 비디오, 또 파이썬 코드나 다른 코드들을 사람보다 더 잘 짜 주고 있는 게 현실입니다.

하지만 얘네들이 코드를 잘 짜기 위해서는 그 외에 다른 것들이 필요하죠.

저는 이 다른 것이 문제를 정의하고 문제를 풀이하는 그 풀이를 쓰는 것이라고 생각하는데요.

결국에 LLM에 넣기 위한 프롬프트를 잘 작성하려면 문제 정의와 문제 풀이가 굉장히 잘 되어 있어야 된다고 생각합니다.

그래서 먼저 저는 일의 시작은 문제를 정의하는 곳에서 시작된다고 생각하는데요.

제가 많이 요즘에 이제 업무에서 개발하고 있는 RAG 모델을 기반으로 좀 설명을 드려 보겠습니다.

RAG 모델을 잘 모르시는 분들도 있을 것 같아서 설명을 드리면 이제 일반적인 LLM은 할루시네이션 현상이라고 해서 거짓말을 생성하곤 합니다.

이 거짓말을 생성하게 되는 이유는 LLM이 학습한 데이터에서 지식을 검색해 가지고 답변을 생성하게 되는데 만약에 질문과 관련된 답변을 찾지 못하는 경우에는 답변을 생성할 수 없다고 답변을 하는 것이 아니라 거짓말을 생성하게 되는데 그것을 할루시네이션 현상이라고 합니다.

이런 현상을 극복하기 위해서 RAG 모델은 이제 질문에 대한 답변을 생성할 때 검색 질문과 관련된 문서를 검색하고 그 검색된 문서를 LM에게 주입해서 LM이 질문을 답변할 때 정답이 있는 문서를 기반해서 답변을 생성하게 하곤 합니다.

이제 이 RAG 모델을 가지고서 보통 성능 평가를 많이 하곤 하는데요.

단순히 성능 평가를 하세요라고 문제를 주면은 그것은 문제 정의로 충분하지가 않습니다.

이 성능 평가라는 업무 자체가 문제 정의에 적합하지 않은 이유는 성능 평가를 하기 위해서 어떤 것을 출력해야 되는지가 정의되어 있지 않기 때문이죠.

그리고 성능 평가를 모델이 출력하는 값이 정의가 되기 위해서는 이 성능 평가로 해결하고자 하는 문제가 무엇인가를 정의하는 게 굉장히 중요한 일이 됩니다.

단순하게 생각할 수 있지만 사실 단순히는 성과 평가를 해결하고 하하 하고자 하는 문제가 RAG 정확도를 높이는 것이라고 뭐 말할 수도 있겠지만 좀 더 문제 정의를 길게 풀어서 보면 RAG 정확도를 높이기 위해서 어떤 정확도를 측정할 것인지 평가 지표를 정의해야 되고요.

그다음에 각각의 정확도 평가 지표들이 낮은 원인들을 분석하기 위해서 틀린 케이스를 원인별로 분류해서까지 출력을 해야지만이 정말로 RAG 모델을 어 RAG 모델의 문제점을 찾아서 성능을 높일 때 필요한 값들을 얻을 수가 있게 됩니다.

그래서 제가 보통 만드는 RAG 모델에서는 검 실제로 질문에 해당하는 답변이 있는 문서를 잘 검색했는지를 평가하는 검색 정확도, 그다음에 실제 이 LM이 꼭 어 정답 문서 여러 개 중에서 정답 문서만을 인용해서 답변을 생성하지 않기 때문에 정답 문서를 잘 인용해서 답변을 생성했는지 파악하는 인용 정확도, 그리고 각각의 정확도들이 떨어지는 원인들을 분석하기 위해서 각각의 실패 케이스들을 잘 모았는지 이런 것들을 종합적으로 저는 동료 팀원들의 코드를 읽고 평가해서 렉 모델의 성능이 떨어지는 원인을 분석하고 정확도를 높이고 있는데요.

그럼 이런 기능들을 정말로 잘 정리하기 위해서는 어떤 걸 해야 될까요?

일단 먼저 문서들을 굉장히 많이 읽어야 합니다.

각 프로젝트마다 프로젝트에는 기획서가 있고 아키텍처 구조도가 있고 세부 기능 설명 등 다양한 문서들이 있는데요.

이런 문서들을 통해서 지금 제가 개발하고자 하는 어떤 코드들이 어떤 문제를 해결하고자 하는 건지를 명확히 파악을 해야 합니다.

이제 팀원인 경우에는 팀 내 문서만 읽으면 되지만 팀장의 역할을 하고 있는 저로서는 기획팀의 문서도 읽어야 되고 프론트엔드 팀의 문서도 읽어야 되고 더 나아가서는 회의에 참석해서 다른 부서의 동료분들과 회의를 해 회의도 하고 이제 회의에서 나온 내용들을 정리해 가지고 팀원들에게 공유하기 위해서 문서도 해야 됩니다.

사실 문제는 한번 정의가 된다 해서 끝나는 게 아니라 계속해서 문제 정의가 바뀌곤 하는데요.

회의를 통해서 바뀌어지는 문제 정의와 그에 맞춰서 변화하는 문제 풀이들을 계속해서 RFP나 제안서에 쓰여져 있는 내용과 일치하는지를 확인하고 이게 맞다면은 그것들을 문서화해 팀원들에게 공유할 수 있는 능력이 굉장히 팀장에게는 중요한 능력으로 평가되는 것을 알 수 있었습니다.

그래서 팀원일 때는 팀장님과 이제 팀 내 문서만 가지고 소통을 하면 되었지만 제가 팀장이 되어보니 CTO와도 소통을 해야 되고 PM과도 긴밀하게 소통을 해야 되고 기획팀, 프론트엔드팀, 심지어는 고객사분들하고도 계속해서 말하고 듣고 그다음에 문서를 읽고 문서를 쓰는 이런 코딩 외적인 역량들이 더 중요하게 작용한다는 것을 알 수 있었습니다.

또 한 가지 이제 문제를 정의하는 데 중요한 것 중에 질문의 중요성을 빼먹을 수가 없는데요.

일론 머스크는 잘못된 질문을 하면 정확한 답에 도달할 수 없다는 말을 했습니다.

저도 이 말에 매우 공감하는 요즘인데요.

문제를 정리할 때 어 굉장히 비어 있는 부분들이 많더라고요.

팀원분들에게 이런 부분들을 좀 채워서 질문을 다른 분들에게, 필요한 사람들에게 이제 해달라고 요청을 해 봤는데 그런 부분들을 많이 어려워하는 것을 경험했습니다.

실제로 어 비어 있는 부분들을 잘 파악하기 위해서는 어떤 담당자에게 어떤 질문을 해야 되는지 사전에 각각의 부서에서 작성한 문서들을 읽고 질문을 미리 생각해서 그들에게 질문해야지만이 제가 얻고자 하는 비어 있는 부분을 찾을 수 있다는 걸 알게 되었는데요.

어 그래서 이제 질문을 잘하는 능력이 굉장히 어려운 일이라는 것을 많이 깨달았습니다.

이제 문제가 정의가 되고 나면은 문제를 풀어야겠죠.

문제를 풀 때 이제 풀이를 적을 때 저는 보통 플로우 차트를 작성하곤 합니다.

예전에 사실 잘 작성하지 않았었는데 이제 팀원들과 긴밀한 소통을 하려고 하다 보니 플로우 차트를 많이 쓰게 되었는데요.

어 A와 같이 이제 써도 굉장히 사람들과 소통이 잘 되곤 하지만 A는 사실 기능 모듈 단위로 써놨기 때문에 사람들과 소통을 할 때 매우 콘텍스트가 많이 비어 있다는 걸 알게 됩니다.

그래서 제가 원하는 것과 다르게 사람들이 개발하기도 하는 걸 많이 겪게 됐는데요.

어 이제 B와 같이 좀 더 컨텍스트를 채워서 어 단순히 기능 모듈과 데이터 흐름만 적은 게 아니라이 기능 모듈이 어떤 역할을 하는 건지를 명확하게 설명하고 각각에서 어떤 데이터들이 흘러가는지를 좀 더 명확하게 제가 적었을 때 소통이 더 효율적으로 이루어진다는 걸 알 수 있었습니다.

이제 C는 약간 아키텍처 구조도를 나타낸 건데요.

B에 이제 풀이 상, 풀이대로 코드가 구현되고 각각의 코드를 구현할 때 사용한 툴들을 명시하게 되면은 아키텍처 구조도까지 쓸 수 있다는 점이 플로우차트의 매력적인 부분이라고 생각이 들었습니다.

문제 풀이 전을 완성을 했으면은 일감을 관리해야 됩니다.

네. 어 이제 저 스켈터립스에서는 지라 티켓을 이용, 지라라는 소프트웨어를 이용해서 일감을 관리하곤 하는데요.

이제 왼쪽과 같이 어 A에다가는 문제 정의를 쓰고 B에다가는 저는 문제 풀이를 쓰곤 합니다.

그다음에 이 풀이가 정말로 잘 어 문제를 풀었는지를 나타내기 위해서 완료 조건까지 명시하기도 하는데요.

이 이렇게 문제가 잘 정의되고 풀이가 써지고 나면은 이 일을 잘 수행할 담당자도 선정을 해야 됩니다.

어 잘못된 잘 담당자를 선정하면은 일까 일이 제대로 수행되지 않겠죠.

원하는 수행 기간에 또 한 가지 되게 어려운 부분은 수행 기간을 명시하는 건데요.

모든 프로젝트에는 이제 WBS라고 그 수행되는 일감이 정해져 있고 여러 명의 팀원들의 일정을 잘 조율해서 이 수행 기간 내에 일이 끝날 수 있도록 팀원들에게 일감을 분배하고 그다음에 오른쪽과 같이 투 인프로그레스 컴플리트로 나타내지는 칸반보드 형태의 티켓들의 현재 업무 상태를 관리함으로써 일감을 관리하는 것도 팀장의 매우 중요한 역할이라는 것을 알게 되었습니다.

이제 문제를 풀기 위해서 마지막으로는 코드를 짜야겠죠.

개발자이니까. 어, 직접 짜기보단 요즘엔 저도 많이 이제 그 대화형 AI에게 이런 이런 걸 짜고 싶어서 이런 걸 짜줘라고 요구를 하고 하는데요.

문제 정의와 문제 풀이가 되어 있으면은 프롬프트를 짜기가 굉장히 어 구조적으로 짤 수 있게 됩니다.

어, 사실 이 정도만 짜 주면 잘 짜 주는 편인 거 같지만 어, 이제 실제로 저희가 기능을 구현하기 위해서 쓰는 어떤 함수 형태의 아, 함수를 구현하기 위해서 LLM을 사용할 때는 조금 더 디테일한 부분이 필요한데요.

어, LLM은 사실 학습한 데이터 기반으로 입력을 받고 출력을 생성하게 되어 있습니다.

근데 이 학습한 데이터가 어떤 것인지를 명확하게 공개하진 않지만 그 학습한 데이터의 형태에 따라서 프롬프트를 작성해야 된다는 가이드라인들이 이제 LLM마다 존재하곤 하는데요.

보통 프롬프트를 짜시는 분들이 많이 그런 가이드라인을 간과하시고 짜시는 부분들을 많이 발견했습니다.

앞으로 이제 LLM들이 등장하면서 저는 다양한 LLM들의 그 장점들을 뽑아서 사용하게 될 때 이런 가이드라인을 참고해서 잘 프롬프트를 작성할 수 있는 능력 역시 미래에는 중요해질 거라는 생각이 들었습니다.

이제 마지막으로는 피드백을 줘야 되는데요.

앞서 설명드렸듯이 LLM의 코드에는 환각(hallucination)이 존재합니다.

그러다 보니 동작하지 않는 코드를 생성하기도 하고 원하는 결과물과 일치하지 않는 결과값을 반환하기도 하죠.

오른쪽에 잘 보이진 않지만 제가 이제 개인적으로 짰던 한국거래소에서 공매도 정보를 가져오는 크롤링 코드에서는 다 사용 실제로 있는 API를 호출하긴 했지만 권한 획득에 실패해 가지고 코드 오류가 나는 것을 알 수 있었습니다.

이런 할루시네이션을 방지하기 위해서는 코드 오류를 잘 읽고 그다음에 왜 이런 오류들이 나는지에 대해서 API 명세들을 잘 읽어야지만이 개발이 잘 가능하다는 것을 알 수 있었고요.

또 한 가지 제가 중요하게 생각하는 부분은 어 테스트 코드를 잘 작성해야 된다는 것인데요.

이제 문제가 잘 정의되어 있고 문제가 풀이가 잘 써져 있다면은 이 코드가 명확하게 출력되어야 되는 값이 무엇인지가 잘 정의되어 있을 것입니다.

그럼 그거에 맞게끔 이 코드가 정말로 저희가 동작하는 출력값들을 잘 출력하는지에 대해서 테스트 코드를 잘 작성해서 특히 예상하지 못했던 엣지 케이스들을 발견해서 LLM이 쓴 코드들을 테스트하는 것이 미래에는 더 중요해질 거라고 생각이 듭니다.

이제 마지막으로는 동료들의 코드도 리뷰를 해둘 텐데요.

역시나 문제 정의와 풀이에 일치하도록 동작하는 코드인지가 확인이 먼저 필요하겠죠.

이 문제 정의와 풀이는 Jira 티켓에 잘 문서가 되어 있기 때문에 저희가 따로 기억을 할 필요 없이 코드를 리뷰하는 데 도움이 됩니다.

또한 앞서서 강조한 테스트 코드도 잘 짜는지 확인해야 될 것이고요.

부가적으로는 사내 컨벤션에 부합하는지, 또 왜 이렇게 코드를 작성했는지, 이 코드는 좋은 코드인지를 리뷰하는 것도 필요합니다.

어 실제로 저희 스펠터레스에서는 Gerrit이라는 소프트웨어로 코드 리뷰를 강제하고 있는데요.

이런 문화를 제가 처음 이 회사에 와서 겪어봤는데 제가 코드를 리뷰도 해보고 다른 분들에게 코드 리뷰를 받아보면서 어, 제 개인적으로 많은 성장을 이루고 있는 걸 느꼈습니다.

그래서 코드 리뷰가 있는 회사는 이제 개발자에게는 하나의 큰 복지를 제공하는 것이라는 생각이 드네요.

이제 벌써 마지막인데요. 어, 이제 좀 종합해서 과연 미래의 개발자는 AI로 대체될지 한번 얘기해 보려고 하는데요.

요즘에는 정말 저도 비전공자지만 많은 비, 어, 컴퓨터 전공하지 않으신 분들이 개발자가 되는 일이 많은 것 같습니다.

앞으로는 AI로 이제 코딩을 하는 일이 더 보편화되면서 더 많은 비전공자이신 분들이 개발자로 일을 하는, 혹은 어, 비개발자 직무에서도 개발을 많이 하시는 일이 이제 종종 생길 것 같은데요.

저는 그럼에도 불구하고 개발자는 단순히 코딩만을 하는 것이 아니라 문제를 정의하고 문제를 풀고 피드백을 주기 위해서 다양한 문서들을 읽고 쓰고, 그다음에 또 많은 사람들과 소통을 하면서 말하고 듣는 능력들이 점점 더 중요해질 것이라고 생각합니다.

음. 특히 여기서는 이제 문제를 정의하는 게 중요하다고 생각을 하는데요.

어, 팔란티어라는 요즘에 유명한 회사가 있습니다.

그 팔란티어라는 회사에서 만든 소프트웨어는 기업의 문제를 풀어 주기 위해 푸는 능력이 아주 뛰어난 소프트웨어인데요.

[PyCon Korea 2025] AI 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들 - 오윤명

Scripts