이 글은 PyCon Korea 2025에서 진행된 <AI 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들> 세션을 정리한 내용입니다. 관리자로서 개발자에게 코딩만큼이나, 다른 비개발적 역량의 중요성을 깨닫게 된 발표자의 경험을 공유합니다. 발표 자료는 PyCon Korea 2025 공식 홈페이지에서 확인할 수 있으며, 추후 파이콘 한국 유튜브 채널을 통해 영상으로도 만나보실 수 있습니다.

AI 시대에 파이썬 개발자가 쌓아야 할 비파이썬적 소양들
오윤명 개발자

안녕하세요, 저는 스켈터랩스에서 Agent 팀에서 Agent 개발 및 리드를 맡고 있는 오윤명입니다. 오늘은 “AI 시대에 파이썬 개발자가 쌓아야 할 비개발적 소양”이라는 주제로 이야기를 나눠보려 합니다.

처음 ChatGPT가 공개된 이후에 AI 기술이 빠르게 발전하면서, 현재는 많은 분들이 업무에 사용하고 있습니다. 또한 기업에서도 적극적으로 실제 업무 툴로 도입하기 시작하면서, AI가 사람을 대체하게 될 거라는 막연했던 두려움이 구체화되고 있다고 느낍니다.

저도 생명과학과를 전공하고 첫 커리어를 비개발자로 시작했던 만큼, 개발자가 AI보다 코딩을 못 하면 개발자로서의 커리어가 끝나는 건가?라는 불안감이 있습니다. 연차가 쌓이면서 실무보다도 관리자의 역할을 많이 맡으면서 그 불안감은 더 커졌는데요. 현재 다니고 있는 스켈터랩스에서 새로운 프로젝트를 맡아, 관리자의 역할을 하면서부터는 개발자에게 코딩만큼이나 다른 비개발적 역량의 중요하다는 걸 깨닫게 됐습니다. 오히려 AI가 코딩하는 시대에는 제가 관리자로서 하는 업무들이 개발자에게 더 중요한 업무가 되지 않을까 하는 생각이 들었죠. 이번 글에서는 이런 제 생각들을 나누고자 합니다.

AI 시대의 개발은 어떻게 다른가?

ChatGPT, Claude, Gemini와 같은 생성형 AI가 등장한 이후, 초기에는 개인적인 업무에 많이 활용되었다면, 현재는 업무 생산성 향상에 더 많이 도입되고 있습니다. 실제로 코딩할 때 많은 도움을 받으면서 생산성이 더 늘어나고, 이로 인해 더 많은 생산성을 요구받는다고 느끼는 개발자도 많을 것 같습니다.

또 단순히 도움을 받는 것뿐만 아니라, 자연어만으로 완성된 프로덕트를 만드는 기술이 유행하면서, “바이브 코딩”이라는 말을 자주 듣고 있는데요. 이런 말이 나온 지 얼마 되지 않았는데, 벌써부터 바이브 코딩 회사들이 꽤 높은 금액에 인수되고 있습니다. 바이브 코딩 플랫폼 ‘베이스44’는 창립된 지 6개월 만에 8천만 달러에 매각되고, 오픈AI와 구글이 인수 경쟁을 벌였던 ‘윈드서프’는 24억 달러에 구글이 핵심 인력을 영입하면서 경쟁에서 승리했습니다.

‘바이브 코딩’을 통해 누구나 개발에 참여할 수 있게 되고, 한 사람의 생산성이 급격히 향상되면서, 코로나 이후 구조조정에서 비교적 안전해 보였던 개발자들조차 더 이상 안심할 수 없는 상황이 되었습니다. 미국 실리콘밸리에서는 실제로 개발자 인력을 감축하고 있으며, 한국은 아직 본격적인 감축 움직임은 없지만, 신입 개발자 채용 시장이 점점 얼어붙고 있는 모습입니다.

이러한 변화의 중심에는 LLM(Large Language Model)이 있습니다. 과거의 LLM은 텍스트를 입력받아 텍스트를 생성하는 방식에 국한됐습니다. 그러나 이제 텍스트뿐 아니라 이미지, 영상, 오디오 등 다양한 멀티모달 데이터를 입력으로 받아, 다시 텍스트, 이미지, 영상, 오디오 등 다양한 형태로 출력할 수 있는 ‘만능 도구’가 되었습니다. 이처럼 강력해진 LLM 덕분에 이제는 누구나 모국어만으로도 프로그래밍을 할 수 있는 시대가 열린 것이죠.

물론 아직 자연어만으로 고품질의 프로덕트를 만들기는 어렵지만, 가까운 미래에는 대부분의 개발이 프로그래밍 언어가 아닌 자연어로 이루어지게 될 가능성이 높습니다.

하지만 LLM을 제대로 활용하기 위해서는, 아무 자연어나 입력한다고 해서 원하는 결과를 얻을 수는 없습니다. 자연어 프롬프트를 효과적으로 입력하려면, 그 전에 프롬프트 작성을 위한 상위 레벨의 정보가 필요합니다. 저는 이것을 ‘문제 정의’와 ‘문제 풀이’라고 생각합니다. 문제 풀이가 되어 있지 않다면, LLM에게 어떤 일을 시켜야 할지 프롬프트를 작성할 수 없습니다. 또한 해결해야 할 문제가 명확하게 정의되어 있지 않다면, 문제 풀이 자체를 쓸 수 없죠.

즉, 문제의 정의와 풀이가 명확하지 않으면, 좋은 프롬프트를 구성할 수 없고, 아무리 뛰어난 LLM이 있다 하더라도 제대로 된 프로덕트를 만들 수 없게 됩니다. 그래서 저는 개발의 시작은 ‘문제 정의’에서부터 출발해야 한다는 점을 꼭 강조하고 싶습니다. AI는 주어진 문제를 ‘풀 수는 있지만’, ‘정의할 수는 없기’ 때문입니다.

문제 정의하기

그렇다면 문제 정의란 무엇일까요? 실제로 제가 정의했던 RAG 모델의 성능평가 문제를 예시로 설명하겠습니다. LLM은 질문에 답변할 때, 기존에 학습한 데이터에 포함된 지식을 바탕으로 답변을 생성합니다. 그런데 학습 데이터에 질문과 관련된 지식이 없을 경우, ‘답변할 수 없다’고 말하지 않고, 마치 알고 있는 것처럼 그럴듯한 거짓 정보를 생성해 버리는 경우가 있습니다. 이 현상을 LLM의 ‘환각 현상(Hallucination)’이라고 부릅니다.

RAG(Retrieval-Augmented Generation) 모델은 바로 이러한 환각 현상을 줄이기 위해 만들어진 모델입니다. RAG 모델은 LLM이 자체 학습 데이터만을 기반으로 답변을 생성하는 방식에서 벗어나, 질문과 관련된 외부 문서를 먼저 검색한 뒤, 그 문서들의 내용을 바탕으로 답변을 생성합니다. 그 정보만을 바탕으로 답변을 만들기 때문에 환각 현상을 효과적으로 줄일 수 있었죠.

하지만 RAG 모델에도 환각 현상은 존재합니다. 이를 줄이기 위해서는 성능 평가가 반드시 필요하죠. 그럼 ‘RAG 모델의 성능 평가를 하는 것’이 문제 정의일까요? 성능에는 답변 정확도, 응답 속도, 비용 효율성 등 다양한 측면이 존재합니다. 답변 정확도에서도, 어떤 답변이 더 나은 답변인가라는 정의가 비어 있기 때문에 정의가 불명확하죠. 이처럼 문제 정의에는, 성능 평가를 통해서 무엇을 출력해야 하는지, 그 목적이 무엇인지가 드러나야 됩니다. 그래서 질문이 필요합니다.

성능 평가로 해결하고자 하는 문제는 무엇일까요? RAG 모델이 환각 현상을 보이지 않고, 질문에 대한 답변을 정확하게 하는 것입니다. 이를 위해서는 환각 현상이 나타나는 케이스들을 분류하고, 정확한 답변이 생성된 비율을 측정해야 하며, 또 환각이 발생한 케이스들을 잘 걸러내는 과정이 필요합니다. 여기까지가 현재 풀고자 하는 문제의 정의가 되는 것이죠.

이제 성능 평가의 출력값이 무엇인지 결정되었다면, 문제 풀이를 작성해야겠죠. RAG 모델이 질문에 대해 정확한 답을 생성하지 못하는 경우는 질문과 관련된 문서 검색에 실패했을 때 발생할 수 있습니다. 따라서 검색 정확도를 측정해야 할 것입니다.

또 문서 검색에는 성공했더라도, 답변 생성 과정에서 질문과 관련 없는 문서만 인용한다면 이 역시 환각 현상을 유발할 수 있으므로, 인용 정확도에 대한 측정도 필요합니다. 또한 이러한 틀린 케이스들이 왜 발생하는지 좀 더 정밀하게 데이터를 들여다보기 위해서는 각각의 유형별 틀린 사례들을 모아서 볼 수 있어야 합니다.

이렇게 성능 평가 모델이 출력한 결과물을 바탕으로 RAG 모델을 분석하고, 해당 모델을 더 발전시켜 성능을 한층 더 끌어올릴 수 있습니다. 문제 정의를 통해 문제 풀이를 도출해 내고, 문제 풀이를 통해 개발한 코드의 결과물을 기반으로 RAG 모델의 향상이라는 목적을 달성할 수 있는 것이죠. 이런 문제 정의를 잘하기 위해서는 결국 프로젝트 안에 있는 다양한 문서들을 많이 읽어야 합니다.

대표적으로 프로젝트에서 요구하는 기능들을 파악하기 위해서는 프로젝트 기획서를 읽어야 합니다. 아키텍처 구조도도 읽고, 세부 기능 설명도 읽어야 하죠. 팀원 입장에서는 이 정도 문서만 읽어도 충분할 수 있지만, 팀장이 되면 팀원들뿐만 아니라 타 팀과도 소통해야 할 일이 많아지면서 듣고 말하는 역량이 중요해집니다.

또한 타 팀과의 명확한 소통을 위해 읽어야 하는 문서들도 많아져, 읽기 역량의 중요성은 더욱 커지죠. 팀장이 읽어야 하는 문서에는 기획팀에서 작성한 기능 정책, 데이터 관리 정책은 물론, 프론트엔드 팀이 작성한 API 명세서, 그리고 프로젝트가 시작된 배경을 담은 RFP나 제안서까지 포함됩니다.

팀장이 되면 문서를 읽는 것뿐만 아니라, 문서를 작성하는 일이 더욱 중요해지기 때문에 쓰기 역량 역시 중요해집니다. ‘기록은 기억을 이긴다’는 말이 있죠. 소통 과정에서 기록이 없다면 누구의 말이 맞는지 판단할 수 없어, 결국 원활한 소통이 어려워집니다. 저 역시 팀장을 맡으면서 컨플루언스와 같은 문서 협업 툴을 왜 회사에서 도입하는지 실감하게 되었고, 그만큼 소통에서 문서화가 얼마나 중요한지 몸소 체감하고 있습니다.

또한 다른 팀 사람들과 회의하는 일이 많아지고, 그 과정에서 결정된 주요 사항들을 정리해야 합니다. 하지만 정리된 내용을 곧바로 팀원들에게 전달하는 것이 아니라, 그 내용이 RFP나 제안서에 명시된 문제 정의와 일치하는지를 먼저 확인해야 합니다. 새롭게 결정된 사항들이 팀 내부에 이미 작성된 문제 정의와 문제 풀이와 일치하는지, 혹은 새롭게 추가된 문제가 있는지를 지속적으로 확인하고, 변경된 사항이 있다면 문서를 업데이트해야 합니다.

팀원이었을 때는 팀장과 문서만 가지고 소통하면 됐지만, 팀장이 되면 팀원은 물론 타 팀, 심지어는 고객사 분들과도 소통하며 끊임없이 정보를 수집해야 합니다. 그렇게 수집된 정보들을 정리한 후, 팀원들에게 공유할 내용만 선별해 문서를 업데이트해야 하죠. 이 과정을 겪으면서 코딩보다도 듣기, 말하기, 읽기, 쓰기 같은 언어 능력이 훨씬 더 요구된다는 사실을 알 수 있습니다.

다른 중요한 언어 능력은 질문입니다. 일론 머스크는 “If you ask the wrong question, the right answer is impossible.(잘못된 질문을 하면, 정답에 도달할 수 없다.)”는 말을 트위터에 남겼는데요. 문제를 정의하다 보면, 아직 정의되어 있지 않은 부분을 종종 발견하게 됩니다. 이 비어 있는 부분을 임의로 채워서는 안 됩니다. 그럼 잘못된 문제를 풀게 될 수 있기 때문이죠.

이 비어 있는 부분을 확실히 채우기 위해서는, 정확히 어떤 사람에게, 어떤 질문을 해야 되는지를 잘 생각해야 합니다. 팀장이 되고 나면 질문해야 하는 경우가 빈번하게 생기곤 하는데요. 질문하는 능력의 중요성은 여러 번 강조해도 지나치지 않을 정도로, 정말 중요하다고 말하고 싶네요.

문제 풀기

문제가 정의되었다면, 이제 문제를 풀 차례입니다. 요즘은 문제를 풀 때 꼭 플로우 차트를 작성합니다. 예전에는 A와 같이 기능 모듈 단위로, 각각의 데이터 흐름을 포함한 플로우 차트를 작성했었는데요. 그런데 이 플로우 차트를 가지고 소통을 해보니 문제점이 드러났습니다. 텍스트 안에 최소한의 모듈 이름과 데이터 이름만 적혀 있다 보니, 컨텍스트가 많이 손실되어 배경지식이 없는 사람이 봤을 때는 이해하기 어려운 문서가 되어버린 거죠. 타 팀 분들뿐만 아니라, 같은 팀원분들과 소통할 때도 헷갈리게 만드는 차트라는 걸 알게 됐습니다.

그래서 플로우 차트를 작성하는 방식을 바꿔, 좀 더 컨텍스트를 채우고 기능에 대해 풀어서 설명하는 방식으로 B처럼 플로우 차트를 작성하게 되었는데요. 이렇게 바꾸고 나니 팀원분들은 물론, 타 팀 분들과의 소통도 훨씬 더 원활해졌습니다. 문서화를 이렇게 잘 해두면, 나중에 작성자인 제가 다시 볼 때에도 어떤 기능을 어떻게 구현하려고 했는지가 명확히 보여서 좋았습니다.

B까지 작성이 되고 나면, 이제 실제로 개발할 차례입니다. 플로우 차트를 기반으로 개발자들이 더 상세한 풀이를 작성하고, 이를 코드로 구현하고 나면, 실제로 코딩에 사용한 도구들이 나열되겠죠. 이 사용한 도구들을 A 플로우 차트의 각 모듈에 덧붙여주면, 아키텍처 구조도를 작성할 수 있습니다.

플로우 차트는 처음부터 완벽하게 작성되지는 않습니다. 그래서 과거에는 모든 구현이 끝난 뒤에 자료 보관용으로 작성했던 적이 많았습니다. 그런데 미리 작성해 보니 소통에 있어서 매우 효율성을 높여주는 문서라는 걸 몸소 체감하게 됐습니다. 풀어야 하는 문제에 대해 같은 정의와 풀이를 바탕으로 개발할 수 있도록 도와준다는 점에서, 플로우 차트는 적극적으로 작성해 보시길 추천드립니다.

플로우 차트를 통해서 문제 정의와 문제 풀이까지 마쳤다면, 이제 이를 일감으로 나누고 일감 관리를 해야 합니다. 지라(Jira) 소프트웨어를 많이들 사용하실 텐데요. 왼쪽에 보이시는 것처럼 티켓을 발행할 때 여러 내용을 입력하게 됩니다. 대부분 비슷한 양식으로 작성하고 계실 텐데, 제 경우에는 As-is에는 문제 정의에 해당하는 내용을 적고, To-be에는 문제 풀이에 해당하는 내용을 적고 있습니다. 이렇게 문제 정의와 문제 풀이를 함께 적어두면, 담당자가 작성한 문서를 리뷰할 때, 티켓 안에 미리 작성된 문제 정의와 문제 풀이를 참고하여 담당자가 문제를 잘 해결했는지 판단할 수 있습니다.

팀장은 지속적으로 필요한 일감을 생성하고, 해당 일감의 문제 정의와 문제 풀이를 직접 작성하거나 팀원들이 작성한 내용을 리뷰하며, 해당 일감을 잘 수행할 수 있는 사람을 담당자로 배정하게 됩니다. 이후에는 일감의 진행 상황을 수시로 살피고, 일이 잘 진척될 수 있도록 지속적으로 팀원들과 소통해야 하죠. 이렇게 일정을 지켜가며 일감을 생성하고, 관리하는 일은 경험이 많이 필요한 일이란 걸 느끼고 있는데요. 결국에는 시간을 들여 훈련하고 익숙해져야 가능한 일입니다.

문제 풀이가 완성되었다면, 이제 코딩을 할 차례입니다. 바이브 코딩을 한다고 하더라도 결국 사람이 프롬프트를 작성해야 합니다. 직접 코딩을 하든, 프롬프트를 작성하든, 풀이가 잘 정리되어 있다면 실제로 코딩을 구현하는 일은 좀 더 쉬운 일이 됩니다.

LLM을 이용할 때 한 가지 유의할 점은, LLM은 각각의 모델마다 학습한 데이터의 양식이 다르기 때문에 실제로 작성해야 하는 프롬프트의 양식이 약간씩 달라질 수 있다는 점입니다. 각 LLM마다 프롬프트 가이드라인을 제공하는 경우가 많아, 사용하고자 하는 LLM의 가이드를 미리 읽고, 해당 모델의 특징에 맞게 프롬프트를 잘 작성하는 능력 또한 앞으로는 중요한 역량이 되지 않을까 생각해 봅니다.

피드백 주기

이제 코드가 작성되었습니다. 하지만 코드가 작성되었다고 해서 곧바로 운영 환경에 배포하지는 않습니다. 먼저 코드를 점검하고 피드백을 주는 과정이 필요하죠. 이는 LLM이 작성한 코드에서도 마찬가지입니다. 앞서 설명했듯, LLM은 환각 현상을 일으켜 잘못된 답변을 생성할 수 있는데요. 이런 현상은 코드에서도 동일하게 나타납니다. 예를 들어, LLM이 생성한 코드가 실제로는 동작하지 않을 수 있습니다. 이런 문제는 특히 외부 라이브러리를 사용하는 코드에서 자주 발생하는데요. 라이브러리에 존재하지 않는 API를 코드에 작성해 버리는 경우가 대표적입니다.

그 외에도 원하는 결과와는 다른 값을 출력하는 코드를 작성하는 등, LLM이 작성한 코드에는 여전히 허점이 존재합니다. LLM이 아무리 똑똑해지더라도, 작성된 코드가 풀고자 하는 문제의 정의와 풀이에 맞는지 점검하는 일은 앞으로도 계속해서 중요한 업무로 남을 거라 생각합니다. 그래서 제가 코드 리뷰에서 가장 중요하게 생각하는 부분은 바로 테스트 케이스를 작성하는 겁니다. 코드가 정말로 작성자가 의도한 값을 출력하는지를 확인하려면, 다양한 엣지 케이스를 문제로부터 도출해 낼 수 있어야 하죠. AI가 코딩을 대신하는 시대일수록, 이런 역량이 더 중요해질 것이라고 생각합니다.

<출처: Gerrit Code Review - A Quick Introduction>

AI가 작성한 코드뿐만 아니라, 앞으로도 동료들이 작성한 코드를 리뷰하는 일은 계속될 것입니다. 이때도 마찬가지로, 작성된 코드가 문제 정의와 풀이에 일치하는지를 확인하는 게 중요합니다. 이 과정에서 기록의 유용성이 드러나는데요. 지라 같은 업무 협업 툴에 기록해 둔 문제 정의와 풀이 덕분에 리뷰가 훨씬 수월해집니다. 작성된 문서는 코드 작성자와 코드 리뷰자가 서로 같은 방향을 바라보면서 코드를 작성하고 리뷰할 수 있게 해주기 때문이죠. 그 외에 살펴봐야 할 부분은, 앞서 강조했던 테스트 코드가 잘 작성되었는지, 사내 컨벤션에 부합하는지, 더 나아가서는 왜 이렇게 코드가 작성되었는지, 작성된 코드가 좋은 코드인지 등도 포함됩니다.

스켈터랩스에서는 게릿(Gerrit)이라는 툴을 사용하여 코드 리뷰를 강제하고 있습니다. 처음으로 코드 리뷰를 강제하는 문화를 경험해 보면서, 이런 코드 리뷰가 개발자의 성장에 굉장히 좋은 문화라는 것을 깨닫게 되었습니다. 코드를 작성하는 사람 입장에서는 자신의 코드에 부족한 부분을 알 수 있어서 좋고, 코드를 리뷰하는 사람은 자신이 몰랐던 좋은 코드들을 읽을 수 있고, 모르는 코드들을 공부해가며 리뷰를 하면서 작성자와 리뷰자 모두가 성장하고 있다는 걸 느끼게 되었습니다. 그래서 좋은 코드를 작성하는 동료가 있고, 제 코드를 잘 리뷰해 주는 동료들이 있다는 게, 개발자 중심의 회사에서 꽤 큰 복지라는 생각이 들었습니다.

미래의 개발자

지금까지 제가 프로젝트에서 개발을 하면서 했던 코딩 외적인 부분들을 살펴봤습니다. 저도 생명과학과를 전공한 개발자지만, 요즘에는 컴퓨터과학을 전공하지 않은 분들도 개발자로 일하고 있는 경우가 많습니다. AI가 사람보다 더 잘 코드를 작성하게 될 미래에는, 어쩌면 전공과 무관하게 모든 사람들이 자신의 업무에 코딩을 활용하게 될지도 모른다는 생각이 듭니다. 그렇다면 개발자들은, 코딩을 잘하는 AI에 의해 대체될까요?

앞서 강조했듯이, 개발자는 단순히 코드를 잘 작성하는 일만 잘하는 직업이 아닙니다. 개발자로서 일을 잘하기 위해서는 코딩뿐만 아니라, 다양한 읽기 역량, 쓰기 역량, 말하기, 듣기 역량이 필요합니다. 특히 연차가 늘어날수록, 문제를 정의하는 역량은 더욱 중요해지리라 봅니다. 투자를 하시는 분들이나 AI를 하시는 분들은 많이 들어보셨을 ‘팔란티어(Palantir)’라는 기업이 만든 소프트웨어가, 기업의 문제를 해결해주는 도구로 유명해지며 잘 팔리고 있는데요. 하지만 그 소프트웨어조차 주어진 문제를 풀어줄 뿐, 문제 자체를 정의해주지는 않습니다.

문제를 잘 정의하기 위해서는 읽기, 쓰기, 듣기, 말하기 등 언어 역량이 크게 작용합니다. 코딩을 AI가 대신하는 시대에도, 개발자의 코딩 역량은 여전히 중요할 것입니다. 하지만 그에 못지않게 다양한 영역에서 요구되는 언어 역량 역시 중요해질 거라 생각합니다. 결국 이런 비개발적 소양을 갖춘 개발자들이 더욱 각광받는 시대가 올 것이라는 점을 다시금 강조하며 글을 마칩니다.