AI랑 일하면서 생긴 나누고 싶은 생각들
교육하는 개발자가 AI를 맞이하는 방법
요즘은 어떤 사람들과 어떤 주제로 대화를 시작하더라도 결국엔 AI 이야기로 이어지는 경우가 많다. 초록 스터디에서 취업 준비생 분들을 만날 때나 강의에서 재직자들과 이야기를 나눌 때나 항상 대화에는 AI 관련 주제가 등장한다. 앞으로 개발자로서 어떤 역할을 해야 할지, 이렇게 빠르게 발전하는 AI 시대에 우리는 무엇을 위해 노력해야 할지. 이는 아마도 나뿐만 아니라 대부분의 사람들의 일상에 AI가 자연스럽게 스며들고 있기 때문일 것이다.
이런 대화 속에서 자연스럽게 드는 생각이 있다. 미래의 개발 환경은 어떻게 변할까? 어쩌면 언젠가는 사람이 코드를 직접 보지 않아도 되는 세상이 올지도 모른다. 또는 코드 작성을 넘어 소프트웨어 개발의 많은 부분이 AI에 의해 결정될 수도 있다. 이런 가능성 앞에서 막연한 불안감을 느끼는 것은 자연스러운 일이다. 하지만 변화를 두려워하며 아무 준비도 하지 않는다면 정말 무기력해질 뿐이다. 오히려 지금 우리가 볼 수 있는 변화의 흐름에 먼저 적응하고, 그 안에서 새로운 가능성을 찾아보는 건 어떨까? AI 도구를 활용한 개발 방식은 이미 우리 곁에 와 있다. 이런 현실적인 변화에 먼저 적응하고 경험을 쌓는 과정이, 예상치 못한 더 큰 변화가 찾아왔을 때 우리가 의지할 수 있는 단단한 기반이 될 것이라 믿는다.
우리 팀은 요즘 우아한테크코스에서 AI와 관련된 다양한 실험을 하고 있다. 교육 커리큘럼을 설계할 때 AI 관련된 내용을 AI 도구를 활용해서 개선하기도 하고, 교육 운영 서비스 개발 과정에서 AI 코딩 어시스턴트를 도입하고 이를 강의에서 소개하기도 한다. 이전에 경험해보지 못했던 이러한 실험들을 하는 과정에서 새로운 시각과 인사이트를 발견하기도 한다. 이 글에서는 AI 전문가가 아닌 내가 실제로 수행한 AI 관련 업무와 그 과정에서 얻은 생각들을 함께 소개하려고 한다. 물론 완전히 주관적인 생각이지만, 급변하는 기술 환경 속에서 막막함을 느끼는 개발자나 취업 준비생 분들이 이 글을 통해 작게나마 힌트를 찾을 수 있기를 바란다.
Cline Memory Bank - Custom Instructions최근에 우리 팀원인 구구가 AI 도구를 활용하여 개발하는 모습을 소개해주었다. 'Cline의 Memory Bank'라는 개념을 활용하는 시연이었다. Memory Bank라는 개념을 간단히 설명하면 문맥(context) 정보를 별도의 문서로 보관하고 프롬프트를 작성할 때 활용하는 것을 말한다. 개발할 때 필요한 여러 문맥을 목적에 맞게 분류하고 기록한다. 그리고 개발을 위한 프롬프트에 이 문서들을 활용한다. 이 문서들은 프로젝트 코드와 함께 관리되고, 프로젝트를 공유하는 모든 사람들과 공유할 수 있다. 기존에 AI 코딩 어시스턴트 도구들을 활용할 때는 프로젝트의 문맥을 전달하기가 어려웠다. 프롬프트 형태로 따로 보관을 했었는데 많이 불편했다. 그래서 평소 개발 습관이나 컨벤션을 무시하는 코드를 작성하는 경우가 많았다. Memory Bank 개념을 도입하니 효율적인 소통 몇 번으로 개발이 끝나는 것을 목격할 수 있었다.
인상적이었던 점은 개발 문맥을 이해하고 지식을 구조화하는 방식이었다. 체계적으로 관리되는 문서를 AI 코딩 어시스턴트 도구가 읽고 이해한 다음, 그 지식을 바탕으로 질문에 답하거나 코드를 작성한다. 마치 경험 많은 동료와 페어 프로그래밍을 하는 느낌이었다. 조금 더 구체적으로 묘사하자면 일 잘하는 사람을 보는 느낌이 들다. 그 일 잘하는 사람들은 왠지 이런 방식으로 사고를 하고 업무를 할 것 같았다.
코딩 에이전트에게서 배울 점들을 우리의 학습과 성장에 활용해 보자. AI 도구는 우리에게 일 잘하는 방법을 직접 보여준다. Memory Bank처럼 지식을 체계화하면 작업을 단순한 요구사항으로 처리하는 것이 아닌 문맥 기반으로 더 좋은 결정을 내릴 수 있다. 개발할 때 단순 구현뿐만 아니라 이 요구사항의 의도, 서비스의 히스토리, 개발 환경에 대한 이해 등 무엇을 고려해야 하는지 명확히 알고 연결된 지식을 활용할 수 있게 된다. AI를 잘 활용하면 우리도 더 빠르게 성장할 수 있다. 단순히 AI를 도구로만 보지 말고, AI가 정보를 처리하는 방식 자체에 관심을 가질 필요가 있다. Memory Bank처럼 정보를 연결하고 정리하는 방법을 우리 사고에 적용하면 문제 해결 능력이 크게 향상될 수 있다. 이렇게 AI의 작동 방식을 이해하고 따라 하면서 우리의 생각하는 방식도 함께 발전시킬 수 있지 않을까?
Windsurf 플러그인 화면 - 제안받은 코드를 Accept or Reject를 선택하는 중구구의 시연은 Memory Bank 뿐만 아니라 Windsurf라는 도구를 이용해서 개발하는 모습도 보여줬다. 인텔리제이에 설치된 플러그인을 활용하였는데 프롬프팅으로 작업 의도를 전달하면 플러그인이 직접 코드를 수정하거나 생성/삭제하고 테스트까지 실행해 주는 방식이었다. 플러그인은 코드 작업을 제안하고, 개발자는 수락(Accept) 혹은 거절(Reject)을 하면서 작업을 진행할 수 있다. 이때 주의할 점에 대해서 알려주었는데 개발자 본인이 작업하는 코드를 잘 모르거나 이해하지 못한다면 이 도구를 사용해도 효과적인 개발이 불가능하다는 점이다. 시연에서 소개된 사례로, 클래스가 deprecated(앞으로 사라지게 될 기능을 의미) 되어 다른 클래스로의 수정을 제안받았는데, 이는 기존 코드의 의도가 아니어서 거절한 사례가 있다고 했다. AI 코딩 어시스턴트를 활용할 때도 최종적으로 코드를 승인하거나 거절하는 책임은 개발자인 나 자신에게 있다. 따라서 내가 코드를 완전히 이해하지 않고 넘어갈 수 없는 이상, 코드 품질을 유지하기 위한 개발자의 기본기는 여전히 필수적이다.
이런 기본기가 중요한 이유는, 아무리 강력한 AI 도구가 있더라도 소프트웨어 개발의 근본적 지식과 경험이 없으면 그 도구의 결과물을 제대로 평가하고 활용할 수 없기 때문이다. 계산기가 있어도 수학의 기본 원리를 이해해야 문제를 위한 올바른 식을 세울 수 있는 것처럼, 개발 도구는 우리가 이미 알고 있는 지식과 패턴을 증폭시켜 주는 역할일 뿐이다. 코드의 맥락과 히스토리를 이해하지 못한 채 AI 도구의 제안을 그대로 수용했다면 어떤 결과가 발생했을지 상상해 본다면 개발자의 판단 책임이 얼마나 중요한지 알 수 있다.
AI 시대에도 소프트웨어 장인 정신과 같은 전통적으로 중요하게 여겨졌던 개발 원칙들은 여전히 그 가치가 유지될 것 같다. 다만 이제는 구현의 많은 부분을 도구가 담당하기 때문에, 개발자의 역할은 좋은 소프트웨어가 무엇인지 판단하고 상황에 맞는 논리적 기준을 세우는 방향으로 더 집중될 수 있다. 가독성, 유지보수성 등 코드의 품질을 평가할 수 있는 안목과 기술적 결정이 비즈니스에 미치는 영향을 이해하는 통찰력이 더욱 중요해질 것 같다.
A typical LLM evaluation framework architecture (from https://medium.com/@jeffreyip54)우아한테크코스에서는 레벨이 끝날 때마다 자신의 성장을 확인하고 점검하기 위한 인터뷰를 진행한다. 코치들이 참여하기 때문에 크루 간에 진행되는 활동 보다 더 효과적인 피드백을 받을 수 있다. 따라서 만족도도 높고 학습 효과도 높다고 얘기하는 크루들이 많다. 문제는 다수의 크루에 비해 코치의 수가 턱없이 부족하다는 점이다. 크루 모두에게 맞춤형 피드백을 제공하기 위한 코치들의 리소스는 항상 부족했다. 이 문제를 해결하기 위해 LLM 기반 대화형 인터뷰 시스템을 통해 효과적인 피드백을 제공하고자 했다.
프로토타입은 만들었고, 실제 운영에 활용하기 위해서는 고도화가 필요했다. LLM 기반 서비스 개발 경험이 부족했기에, 팀원인 솔라의 최측근 지인에게 도움을 청했다. 현업 개발자로 LLM을 적극적으로 사용하고 있기 때문에 큰 도움이 되었다. 여러 가지 고도화 방향에 대해 소개를 받았는데, 그중 LLM 서비스의 품질을 높이기 위한 evaluation 과정에 대한 설명이 인상 깊었다. evaluation은 AI 모델이 실제로 원하는 대로 작동하는지 체계적으로 평가하는 방법이다. 이는 단순히 모델의 출력을 보는 것을 넘어, 다양한 시나리오에서 모델의 성능을 측정하고 개선점을 찾는 과정을 포함한다.
프롬프트를 만들 때 '정확히 무엇을 해내야 하는지'가 불분명하면 모델은 예상과 다른 답변을 내놓기 쉽다. 아무리 정교한 AI 모델이라도 그것이 해결해야 할 문제가 명확하지 않으면 원하는 결과를 얻기 어렵다. AI의 응답이 제대로 작동하는지 평가하는 기준을 정의하는 것은 아직까지는 사람의 영역이다. 우리가 기대하는 바를 모델이 만족하는지 판단하는 것, 즉 요구사항을 정의하고 검증하는 일은 여전히 인간의 몫이라는 것을 실감했다.
앞으로의 소프트웨어 엔지니어링에서는 단순히 코드를 잘 작성하는 능력은 물론이고, 서비스의 본질을 이해하고 비즈니스 가치를 창출하는 역량이 강조될 것 같다. 개발자는 기술적 문제 해결을 넘어 비즈니스를 이해하고, 이를 명확한 요구사항으로 정의할 수 있어야 한다. 비즈니스를 기술 언어로 번역하고, 이를 테스트 가능한 형태로 만드는 능력이 개발자에게 더욱 요구될 수 있다. 앞으로는 칸반 보드 앞에서 QA, 기획자와 함께 인수 조건(요구 사항을 충족하는지 확인하기 위해 사용되는 기준)을 논의하는 개발자의 모습이 더 자주 보이게 될지도.
취업 준비생들에게 요구되는 역량이 해마다 높아지고 있는 것을 지난 7년간 부트캠프를 운영하며 매년 느끼고 있다. 10년 전 내가 신입 개발자로 취업할 때와 비교하면 분명히 차이는 존재한다. 이런 상황에서 홀로 학습에만 매달리면 쉽게 지치고 좌절할 수 있다.
재직자도 힘들다. 기술 스택은 끊임없이 변화하고, 새로운 프레임워크와 도구들이 계속해서 등장한다. 업무 시간 외에도 자기 계발을 해야 하는 압박감, 시니어가 될수록 기술적 전문성과 함께 매니징 능력 등 추가로 요구받는 부담, 그리고 이제는 AI 도구까지 능숙하게 다루어야 한다는 새로운 과제까지 더해졌다.
아프리카 속담에 "빨리 가려면 혼자 가고, 멀리 가려면 함께 가라"는 말이 있다. 배울 것은 많고 경쟁은 점점 치열해지는 환경에서 혼자 학습하는 것이 빠른 성장으로 이어질 것 같지만, 실상은 다르다. 단기적으로는 혼자 빠르게 나아갈 수 있을지 몰라도, 지속 가능한 성장과 깊이 있는 이해를 위해서는 함께하는 활동이 훨씬 효과적이다. 토론, 스터디, 코드 리뷰와 같은 활동을 통해 서로를 경쟁자가 아닌 동료로 생각한다면 학습은 훨씬 즐거워질 뿐만 아니라 더 오래, 더 멀리 나아갈 수 있다.
지식을 나누면서 더 크게 성장하는 사례를 수도 없이 목격했다. 지식을 가진 사람이 이를 나눌 때 메타인지가 작동하며 자신의 이해가 더 깊어지고, 질문하는 사람도 '질문 설계' 과정에서 사고력이 확장된다. 함께 학습하는 과정에서 즐거움을 찾고, 배움 자체에 집중하면 성장은 자연스럽게 따라온다.
소프트웨어 엔지니어에게 요구되는 역량은 시대가 흐르면서 비슷하지만 계속 변화하고 있다. 나의 예전 기억 어딘가에는 IDE의 자동완성을 사용하면 멋(?) 없는 개발자로 보일까 봐 자동완성을 사용하지 않고 라이브 코딩을 하던 선배 개발자의 모습이 남아있다. 개발자는 평생 공부해야 한다는 이야기가 자주 들린다. 사실 이건 개발자만의 이야기가 아니다. 어떤 직업이든 시대의 흐름에 맞춰 함께 나아가야 하는 건 마찬가지라고 생각한다. 중요한 건 내가 하는 일의 본질을 이해하고, 그 속에서 나만의 가치를 찾는 것이라고 생각한다.
이러한 인식을 바탕으로 자신만의 가치를 찾아간다면, 자연스럽게 AI와 공존하는 주체적인 엔지니어로 성장할 수 있을 것이다. 우리는 AI에 자리를 빼앗길까 두려워하기보다, 어떤 일을 우리가 정의하고 어떤 일을 AI가 도와줄지 현명하게 구분할 수 있는 안목을 기르는 데 집중할 수 있다. 함께 배우고 지식을 나누며, 서로의 성장을 응원하는 과정에서 개발자로서의 본질적 가치를 발견하게 될 것이다. 이것이 급변하는 AI 시대를 살아가는 우리 모두가 앞으로도 지속 가능한 성장을 이어갈 수 있는 길이 아닐까?
