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

어, 오늘은 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 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들 - 오윤명

PyCon Korea

AI 시대의 개발자는 단순한 코딩 능력을 넘어, 문제를 정의하고 해결책을 구상하며, 다양한 문서를 읽고 쓰는 능력과 원활한 소통 능력이 더욱 중요해질 것입니다.

특히, 복잡한 문제들을 명확하게 정의하고, 이를 바탕으로 LLM(대규모 언어 모델)과 협업하여 효율적인 솔루션을 도출하는 '문제 정의' 능력이 미래 개발자의 핵심 역량이 될 것입니다.

LLM이 생성한 코드의 오류를 식별하고, 예상치 못한 엣지 케이스를 포괄하는 테스트 코드를 작성하며, 동료 코드 리뷰를 통해 품질을 확보하는 피드백 능력 또한 중요해집니다.

스켈터랩스의 오윤명입니다. 오늘은 AI 시대에 **파이썬 개발자가 갖춰야 할 비파이썬적 소양**이라는 주제로 발표를 시작합니다. 파이콘에서 비파이썬적인 내용을 다루는 저의 발표를 선정해주신 관계자 여러분께 감사드립니다.

개발자의 커리어 경로와 불안감

저는 생명과학을 전공했으며, 뇌과학에 관심이 많았습니다. 2016년 알파고가 유명해지면서 AI 기술을 접하게 되었고, 인공지능을 통해 뇌과학 연구를 할 수 있지 않을까 하는 기대감에 **자연어 처리 개발자로 커리어를 시작**했습니다.

초기에는 파이썬과 AI 공부에 매진했으나, 시간이 지나면서 코딩보다는 **관리 업무와 팀장 역할**이 주로 주어졌습니다. 개발자는 코딩을 잘해야 한다는 생각과 AI가 코딩하는 시대에 뒤처질까 하는 불안감이 많았지만, 스켈터랩스에 와서 코딩 외적인 업무들을 통해 성장하고 있다는 느낌을 받았습니다. 이는 개발자로서 중요한 커리어라고 생각합니다.

AI 시대의 개발, 무엇이 다른가?

요즘 AI를 업무에 많이 활용하면서 생산성이 향상되었지만, 한편으로는 더 많은 생산성을 요구받고 AI가 코드를 더 잘 작성하는 현실에 **위기감을 느끼는 개발자들이 많을 것**입니다. AI 코딩이 유행하며 관련 회사들이 높은 금액에 매각되고, 개발자가 AI로 대체되는 현상까지 발생하고 있습니다. 이는 실리콘밸리뿐 아니라 한국에서도 수급 개발자들이 자리를 잃을 수 있다는 우려를 낳고 있습니다.

멀티모달 LLM, 즉 챗GPT나 구글 제미나이 같은 서비스들은 텍스트, 이미지, 오디오, 비디오, 코드를 입력받아 사람보다 더 잘 작성할 수 있습니다. 하지만 이들이 코드를 잘 짜기 위해서는 **문제 정의와 문제 풀이 과정이 선행되어야** 합니다. LLM에 넣을 프롬프트를 잘 작성하려면 문제 정의와 풀이가 매우 중요합니다.

일의 시작: 문제 정의의 중요성

일은 **문제를 정의하는 것에서 시작**됩니다. RAG(Retrieval-Augmented Generation) 모델을 예로 들어 설명해보겠습니다. RAG 모델은 LLM의 환각(Hallucination) 현상, 즉 거짓 정보 생성을 극복하기 위해 질문과 관련된 문서를 검색하고 이를 LLM에 주입하여 답변을 생성하게 하는 방식입니다.

RAG 모델의 성능 평가를 단순히 요청하는 것은 충분한 문제 정의가 아닙니다. **어떤 값을 출력해야 하는지, 그리고 이 성능 평가로 해결하고자 하는 문제가 무엇인지**를 정의하는 것이 중요합니다. 예를 들어, RAG 정확도를 높이기 위해서는 어떤 평가 지표를 사용할지, 낮은 원인을 분석하기 위해 틀린 케이스를 어떻게 분류할지 등을 명확히 해야 합니다.

제가 만드는 RAG 모델에서는 **검색 정확도, 인용 정확도, 그리고 각 정확도가 떨어지는 원인을 분석하기 위한 실패 케이스 분류** 등을 종합적으로 평가합니다. 이를 통해 동료 팀원들의 코드를 읽고 분석하여 모델의 성능을 높이는 데 필요한 값들을 얻습니다.

이러한 기능들을 잘 정리하기 위해서는 **다양한 문서를 읽고 이해하는 능력**이 필수적입니다. 기획서, 아키텍처 구조도, 세부 기능 설명 등 프로젝트 문서를 통해 해결하고자 하는 문제를 명확히 파악해야 합니다.

팀원일 때는 팀 내 문서만으로 소통이 가능하지만, 팀장이 되면 기획팀, 프론트엔드팀, 심지어 고객사와도 소통하며 **문서를 읽고 쓰고 회의 내용을 정리하여 공유하는 코딩 외적인 역량**이 더욱 중요해집니다. 문제 정의는 한 번으로 끝나는 것이 아니라 회의를 통해 계속 바뀌므로, 변화하는 내용을 RFP나 제안서와 일치하는지 확인하고 문서화하여 팀원들과 공유하는 능력이 중요합니다.

일론 머스크의 말처럼, **잘못된 질문을 하면 정확한 답에 도달할 수 없습니다.** 문제 정의 시 비어 있는 부분을 파악하고, 어떤 담당자에게 어떤 질문을 해야 하는지 사전에 문서들을 읽고 미리 생각하여 질문하는 능력이 중요합니다. 좋은 질문은 문제를 명확히 하고 해결책을 찾는 데 핵심적인 역할을 합니다.

문제 해결: 명확한 풀이 작성과 일감 관리

문제가 정의되고 나면, **문제 풀이를 작성**해야 합니다. 저는 플로우차트를 주로 사용하는데, 단순히 기능 모듈과 데이터 흐름만 적는 것이 아니라, 각 기능 모듈이 어떤 역할을 하는지, 어떤 데이터가 흐르는지 등 **더 많은 컨텍스트를 채워서 소통 효율을 높입니다.** 이러한 풀이 방식을 통해 아키텍처 구조도까지 연결하여 작성할 수 있습니다.

문제 풀이가 완성되면 **일감을 관리**해야 합니다. 스켈터랩스에서는 Jira 티켓을 활용하여 문제 정의, 문제 풀이, 완료 조건을 명시합니다. 적절한 담당자를 선정하고, WBS(Work Breakdown Structure)를 통해 정해진 수행 기간 내에 일이 완료될 수 있도록 **팀원들의 일정을 조율하고 일감을 분배**하며 칸반보드 형태로 업무 상태를 관리하는 것이 팀장의 중요한 역할입니다.

코딩과 피드백: AI 시대의 개발자 역할

문제를 풀기 위해 코드를 작성할 때, 요즘에는 대화형 AI를 많이 활용합니다. **문제 정의와 풀이가 명확하면 프롬프트를 구조적으로 작성**할 수 있으며, AI가 더 효율적으로 코드를 생성하도록 돕습니다.

LLM은 학습 데이터 기반으로 출력을 생성하므로, LLM마다 존재하는 **프롬프트 작성 가이드라인을 참고**하여 다양한 LLM의 장점을 활용하는 능력이 미래에 중요해질 것입니다.

LLM 코드에는 환각(hallucination)이 존재하여 동작하지 않거나 원하는 결과와 다른 코드를 생성할 수 있습니다. 따라서 **코드 오류를 잘 읽고 API 명세를 통해 원인을 파악**하는 능력이 필요합니다. 또한, 문제가 정의되고 풀이가 잘 작성되어 있다면, 코드가 명확하게 출력해야 할 값을 정의할 수 있으므로, **테스트 코드를 잘 작성하여 엣지 케이스를 발견하고 LLM이 작성한 코드를 검증**하는 것이 중요합니다.

마지막으로 **동료들의 코드 리뷰** 또한 중요합니다. Jira 티켓에 문서화된 문제 정의와 풀이에 코드가 일치하는지, 테스트 코드가 잘 작성되었는지, 사내 컨벤션에 부합하는지 등을 확인합니다. 스켈터랩스에서는 Gerrit을 이용한 코드 리뷰를 통해 많은 개인적인 성장을 경험했으며, 이는 개발자에게 큰 복지라고 생각합니다.

미래 개발자의 핵심 역량: 문제 정의 능력

미래에는 비전공자나 비개발 직무에서도 AI를 활용한 코딩이 보편화될 것입니다. 하지만 개발자는 단순히 코딩만을 하는 것이 아니라, **문제를 정의하고 해결하며 피드백을 주기 위해 다양한 문서를 읽고 쓰고, 많은 사람들과 소통하는 능력**이 더욱 중요해질 것입니다.

특히 **문제를 스스로 잘 정의할 수 있는 능력**이 핵심입니다. 팔란티어와 같은 뛰어난 소프트웨어들도 기업의 문제를 대신 정의해주지는 않습니다. 따라서 스스로 풀고자 하는 문제를 명확히 정의하는 능력이 앞으로 개발자로서의 커리어를 이어나가는 데 가장 중요한 소양이 될 것입니다.

발표자가 생명과학 전공자임에도 AI 개발자의 길을 걷게 된 계기는 무엇인가요?

발표자가 AI 시대의 파이썬 개발자에게 코딩 능력 외에 중요하다고 강조하는 '비파이썬적 소양'에는 어떤 것들이 있으며, 그 중요성은 무엇인가요?

AI 모델인 RAG의 정확도를 높이기 위한 문제 정의 과정에서 어떤 세부적인 요소들을 고려해야 하는지 설명해주세요.

LLM이 생성한 코드의 오류를 방지하고 신뢰도를 높이기 위해 발표자가 제시하는 두 가지 중요한 방법은 무엇인가요?

발표자는 미래의 개발자가 AI로 대체될 가능성에 대해 어떻게 전망하고 있으며, 개발자가 계속해서 가치를 가질 수 있는 핵심 역량은 무엇이라고 보나요?

발표자는 스켈터랩스의 오윤명이며, 'AI 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들'이라는 주제로 발표한다.

발표자는 생명과학 전공 후 뇌과학에 관심을 가졌고, 2016년 알파고를 계기로 AI와 자연어 처리 개발자로 커리어를 시작했다.

초기에는 코딩 공부에 집중했으나, 시간이 지나며 관리 및 팀장 역할이 부여되면서 코딩 외적 역량의 중요성을 느끼게 되었다.

AI 시대의 개발 변화와 개발자의 위기감

AI 사용으로 생산성은 향상되었지만, AI가 코드를 더 잘 짜면서 개발자들은 위기감을 느낀다.

AI 코딩 관련 회사들이 높은 금액에 매각되고, 개발자가 AI로 대체되는 현상도 발생한다.

ChatGPT나 Gemini와 같은 멀티모달 LLM은 텍스트, 이미지, 오디오, 비디오, 코드까지 입력받아 사람보다 더 잘 생성한다.

AI 시대 개발자에게 필요한 비파이썬적 소양: 문제 정의

LLM이 코드를 잘 짜기 위해서는 '문제 정의'와 '문제 풀이 작성' 능력이 필요하다.

일의 시작은 문제를 정의하는 것에서 시작되며, RAG 모델의 성능 평가를 예시로 설명한다.

성능 평가의 문제 정의는 해결하고자 하는 문제가 무엇인지 정의하는 것이 중요하다.

RAG 정확도 향상을 위한 문제 정의는 평가 지표 정의, 낮은 원인 분석, 틀린 케이스 분류 등이 포함된다.

문제 정의를 위해선 기획서, 아키텍처 구조도, 세부 기능 설명 등 프로젝트 문서들을 많이 읽어야 한다.

팀장으로서 다양한 부서(기획팀, 프론트엔드팀)의 문서도 읽고 회의에 참석하며 나온 내용을 정리하여 팀원들과 공유하는 능력이 중요하다.

문제 정의는 계속해서 변하며, 변화에 맞춰 문서화하고 공유하는 능력이 팀장에게 필수적이다.

일론 머스크의 말처럼 '잘못된 질문을 하면 정확한 답에 도달할 수 없다'는 점에서 질문의 중요성이 강조된다.

비어 있는 부분을 파악하고 어떤 담당자에게 어떤 질문을 해야 하는지 미리 생각하는 능력이 필요하다.

AI 시대 개발자에게 필요한 비파이썬적 소양: 문제 풀이 및 일감 관리

문제 풀이를 위해 플로우 차트를 작성하며, 기능 모듈과 데이터 흐름뿐 아니라 역할과 상세 데이터 흐름을 명확히 설명해야 효율적인 소통이 가능하다.

플로우 차트는 아키텍처 구조도 작성에도 활용될 수 있다.

Jira 티켓을 활용해 문제 정의, 풀이, 완료 조건을 명시하여 일감을 관리한다.

담당자 선정, 수행 기간 명시, 그리고 칸반보드 형태의 티켓으로 업무 상태를 관리하는 것이 팀장의 중요한 역할이다.

AI 시대 개발자에게 필요한 비파이썬적 소양: 코드 작성 및 피드백

코드 작성 시 대화형 AI를 활용하며, 문제 정의와 풀이가 잘 되어 있으면 구조적인 프롬프트 작성이 가능하다.

LLM의 학습 데이터 형태에 따른 가이드라인을 참고하여 프롬프트를 작성하는 능력이 중요해질 것이다.

LLM 생성 코드에는 환각(hallucination)이 존재하므로, 코드 오류를 읽고 API 명세를 통해 문제 원인을 파악하는 능력이 필요하다.

문제 정의와 풀이가 잘 되어 있다면, 예상치 못한 엣지 케이스를 포함한 테스트 코드를 잘 작성하여 LLM 코드를 검증하는 것이 중요하다.

동료 코드 리뷰 시 문제 정의와 풀이에 일치하는지, 테스트 코드가 잘 작성되었는지, 사내 컨벤션 준수 여부 등을 확인하는 것이 중요하다.

미래 개발자의 역할과 비파이썬적 소양의 중요성 재강조

AI 코딩 보편화로 비전공자나 비개발자 직무에서도 개발을 하는 일이 늘어날 것이다.

개발자는 단순히 코딩을 넘어 문제 정의, 문제 풀이, 피드백을 위한 문서 작성 및 읽기, 소통 능력 등이 더욱 중요해질 것이다.

특히 팔란티어 사례를 통해, 아무리 뛰어난 소프트웨어라도 기업의 문제를 대신 정의해주지 않으므로, 스스로 문제를 잘 정의할 수 있는 능력이 미래에 더욱 중요해질 것이다.

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

스크립트