이건 힘멜이 가장 좋아했던 마법이야.
???: 프리렌사마, 언제적 이야기를 하시는 건가요.

AI의 활용 관련해서 매일매일 새로운 기술과 의견들이 쏟아져 나오고 있고, 정답은 존재하지 않습니다. 이 글도 제 주관적 의견이 들어가있는 부분이 있으며, 유의해서 읽어주시면 감사하겠습니다.
브런치에도 동시 기고중입니다: https://brunch.co.kr/@hanjoongil-dev/2

들어가며

개발자로 커리어를 시작해서, IT 컨설턴트가 되고 곧 3년차를 앞두면서 고민이 매우 많다. 당연하지만 AI때문이다.

대학생일땐 SQL문도 제대로 하나 작성 못하던 모델이, 이제는 거의 모든걸 다 할수 있는 시대가 되었다. 현재 LLM을 활용하는 프로덕트를 만들며 컨설팅 업무를 진행하고 있는데, 그 프로덕트를 개발할때나 자료를 작성할때도 (심지어 이 글 작성의 일부에도!) LLM을 활용하고 있다. LLM의 능력과 한계를 어느정도 알고 활용하고 있는 것인데, 그럼에도 불구하고 참 어렵다. 어쩔때 보면 내 일을 다 해줘서 신처럼 보여도, 어쩔때 보면 그냥 내가 직접 하는게 나을정도로 바보가 된다.

그런 와중에 우리회사는 최근에 고위직들을 대상으로, AI 툴 사용 시간을 업무평가에도 반영하겠다고 발표해 업계를 충격에 빠트리기도 했다. AI 시대에 적응하지 못하는 직원은 회사를 떠나게 될 것이란다. (기사)

인터넷을 열어보기만 하면, 진짜인지 아닌지도 모를 방법론들만 하루가 멀다하고 쏟아져 나오고 있다. 전문가는 아니어도 LLM으로 벌어먹고 사는 내가 봐도 머리가 아플 지경인데, 나보다도 경험이 없는 주니어들이나 취준생들은 얼마나 더 고민이 많을지 상상하기도 힘들 정도다.

다행인것은, 기술의 발전 속도는 경이롭지만, 아직 AI시대는 시작한지 얼마 되지 않았으며, 한계도 (아직은) 명확하기에 개발이라는 업무에 있어 인간이 해야할 역할은 매우 명확하다는 것이다.

이 글에선, LLM을 활용도 하고, LLM으로 밥벌이도 하며 직접 경험해보면서 느낀 LLM과 함께하는 개발에서 인간이 할 수 있는 (혹은 해야만 하는) 역할, 그리고 그 역할에서 우수하게 활약하기 위해 꼭 필요한 필요한 능력들에 대해 얘기해보려 한다. 시대의 흐름에 혼란스러워하는 개발자 지망생들과, 나와 비슷한 다른 주니어들에게도 도움이 되길 바란다.

개발 현업에서의 LLM 사용

현업에서도 실제로 많이 쓰나요?

결론적으로, 주니어/시니어 관계 없이 현 시점에서 개발에 LLM을 사용하지 않는것은 시대착오적이라고 생각한다.

적어도 내가 업계에 들어오고 나서, 회사가 LLM 사용을 금지하지 않는 이상 LLM을 사용하지 않는 개발자를 본적은 없다. 이유는 간단하다. 작동하는 결과를 구현해내는 면에 있어서는 속도와 효율 모두 인간을 아득히 뛰어넘고 있기 때문이다. 보수적인 일본에서 일하고 있음에도, 최근 일본 기업들도 보안 이슈가 있지 않는한 앞다퉈 사내 개발에 LLM을 도입중이다 (이마저도 엔터프라이즈 계약을 하면 대부분 해결).

2024년 Stack Overflow의 연례 대규모 개발자 설문조사에서 응답자의 76%가 개발 과정에서 AI 도구를 사용 중이거나 사용할 계획이라고 답했다. 이 수치는 2025년판에서 84%로 더 상승했으며, 개발자의 51%가 매일 AI 도구를 사용한다고 답했다고 한다.

"AI 코딩 어시스턴트가 개발자 생산성을 획기적으로 높인다"는 이야기는 거의 자명한 사실이다. 그럼에도 사용하지 않는다는 것은...

이 짤정도로밖에 설명이 되지 않는다고 생각한다. 적어도 이 부분에 있어서는 반론의 여지가 없다고 본다.

만능인가요?

라고 물으면 또 여러분도 잘 알고있듯 아니다. 서론에 이야기했듯 가끔 정말 바보같아서 거꾸로 업무 효율을 해칠때도 있다. 자세히 설명하지 않더라도 다들 비슷한 경험이 있을거라 생각한다.

그렇기 때문에, 이 가능성이 넘쳐나는 도구를 제대로 활용해줄 파일럿, 즉 인간의 역할이 매우 중요해진다.

활용법을 알려주세요!

좋다, 그럼 사용법을 공부하면 되겠다. 라고 생각하고 구글을 검색해보면..

• 상위 1%만 알고있는 사용법...
• 인생이 바뀐다!
• OpenAI도 모르는 활용법! 뭐야 그럼 누가 아는거야 더보기... (30만원 결제 필요)

등 정보가 쏟아진다. 이런 정보들을 공유해주시는 모든 분들을 비꼴 생각은 전혀 없고, 실제로 들어보면 도움이 되는 정보도 매우 많다.

문제는 이런 방법들이 너무 많이 쏟아져 나오고 있어, 찾다보면 거꾸로 더더욱 혼란스러워진다는 것이다. 그리고 아쉽지만, 그렇게까지 전문가가 아닌 내가 보더라도 잘못된 정보들도 많이 섞여있고, 흐름에 타서 말도 안되는 정보로 사람들을 현혹해서 한탕 해먹으려는 나쁜놈들도 많이 보인다.

그럼 어떻하죠

공부해야 한다. 무엇이 나에게 도움이 될 정보이고, 무엇이 나의 효율을 진짜 높여줄 방법인지, 스스로 판단할 수 있게 되기 위해, 스스로 공부해야 한다.

무엇을 공부해야 할까?

LLM의 본질

당연하지만, LLM이 무엇인지, 어떤 원리로 움직이는지, 왜 가끔 세종대왕은 맥북을 던진적이 있다고 말하거나 세차장까지는 차 없이 걸어가는게 더 좋다고 말해주는지 최소한의 기본적인 이해는 가지고 있어야 한다.

당연한 소리라고 생각할수 있지만, 이 최소한의 이해도 가지지 않고 우선 뛰어드는 사람들이 생각보다 많이 보인다. LLM은 기본적으로 통계학적 모델이라는 점을 이해하고, 어떤 원리로 나의 대답을 생성하여 주며, 왜 할루시네이션이 일어나는지 이해할 필요가 있다.

트랜스포머 모델의 엄청 세부적인 부분까지 안들어가도 된다. (사실 나도 잘 모른다) 다만 누군가가 "GPT가 아직도 미국 대통령이 바이든이래!"라거나 "제미나이가 strawberry에는 r이 2개밖에 없대!"라고 화내고 있다면, 알기 쉬운 설명으로 LLM 내부에서 어떤 일이 일어나 이러한 환각이 일어났는지는 설명할 수 있을 정도는 되어야 한다. 이정도만 알더라도, RAG등 다음 스텝으로 넘어가 지식을 늘릴 수 있고, 나 또한 그렇게 LLM 프로덕트를 개발하기 전 학습을 진행해왔다.

LLM의 한계

이 글에서 가장 메인으로 이야기하고 싶은 부분이다.

어느정도 LLM의 원리를 이해하면, 이녀석들에게 코딩으론 절대 이길수 없다는 사실을 자연스럽게 납득하게 된다. 그냥 그렇게 설계되어 있다.

그럼에도 불구하고 '제 코드가 클로드때문에 스파게티가 되어버렸어요!!!'라고 하는 주니어들이 많이 보이는데 (뜨끔) 이런 말은 왜 나오는걸까? 이 부분도 LLM의 본질과도 연결되지만, 우선 아래의 내용들을 이해할 필요가 있겠다.

"개발 효율이 상승하고 있다"는 착시

METR의 Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity연구는, 오픈 소스 개발자의 생산성에 있어서 LLM이 개발자들의 속도를 높이기는 커녕 오히려 늦추고 있다는 충격적인 결과를 발표했다. LLM을 사용할 수 있는 작업이, LLM 사용이 금지된 작업보다 평균 19% 더 긴 완료 시간을 보였다는 것이다.

표본 크기가 16개밖에 안되는 연구이긴 하지만, 속도가 느려지는 이유로 추정되는 가설들을 읽어보면, 충분히 납득하게 된다. 가설은 아래와 같다:

• 개발자들의 과도한 기대(과잉 낙관)
  개발자들은 AI의 실제 역량보다 유용성을 과대평가했으며, AI가 근본적으로 해결하기 어려운 문제에도 AI를 활용하려는 경향이 있었다. 이로 인해 불필요한 시도와 시행착오가 발생했다.
• 코드베이스에 대한 높은 숙련도
  참가자들은 자신이 오랫동안 기여해 온 저장소에 대해 매우 높은 이해도를 가지고 있었기 때문에, AI의 도움 없이도 더 빠르게 적절한 해결책에 도달할 수 있었다. 이 경우 AI는 생산성 향상에 도움이 되지 않았다.
• 대규모 코드베이스로 인한 맥락 한계
  100만 줄이 넘는 대형·복잡한 코드베이스는 AI가 전체 맥락을 효과적으로 이해하기에 지나치게 복잡했으며, 이로 인해 AI의 제안이 부분적이거나 부정확한 경우가 많았다.
• AI 출력의 낮은 신뢰성과 검증 비용
  AI가 생성한 코드 중 개발자들이 그대로 수용한 비율은 44% 미만에 불과했다. 개발자들의 75%는 AI 출력 코드를 한 줄씩 검토했고, 56%는 상당한 수정을 가했다. 이 검토·수정 과정이 큰 오버헤드로 작용했다.
• 프롬프팅 및 대기 시간으로 인한 오버헤드
  프롬프트를 작성하고, AI의 응답을 기다리고, 결과를 해석하는 데 드는 시간이 직접 코드를 작성하는 것보다 더 많은 경우가 많아, 전체 작업 시간이 오히려 증가했다.

이중, 주니어와 취준생들은 3번째와 4번째 가설에 특히 주의해야 한다고 생각한다.

Context Rot

Chroma의 이 연구 결과가 3번째 가설과도 이어진다. 간단히 얘기하면, 모든 LLM 모델에서 입력 토큰 수 증가는 성능 저하로 이어졌다. 어떤 회사의 모델도 예외 없이.

최근 클로드 코드가 모델의 컨텍스트 윈도우를 늘린것처럼 해결하면 되지 않나? 라고 생각할 수 도 있지만, 100만 토큰의 컨텍스트 윈도우를 가진 모델이 이미 5만 토큰에서 상당한 성능 저하를 보이고 있다면 해결책이 되지 않는다는 것을 알 수 있게 된다. 실무에서 만지게 될 코드베이스는 보통 거대하다. 이 모든것을 LLM이 스캔하는것 만으로도 성능저하가 온다는 것이다.

즉, 실무에서 AI에게 “전체 코드를 다 이해하고 답해줘”라고 기대하는 순간, 우리는 이미 현 시점 LLM 모델의 가장 약한 지점을 찌르고 있는 셈이다. 자연스럽게 이게 4번째 가설의 낮은 신뢰성으로 이어지고, 추가적인 검증 시간은 결국 생산성 저하로 이어진다.

그럼 무엇을 공부해야 할까?

결국 지금까지의 이야기들을 한 문장으로 정리하면 이렇다. AI는 문제를 푸는 데는 강하지만, 문제의 ‘범위와 구조’를 정의하는 데는 취약하다. 대규모 코드베이스, 복잡한 의존성, 암묵적인 규칙이 얽힌 실무 환경에서는 “전체를 이해하고 적절한 답을 내놓는 것” 자체가 가장 어려운 문제다.

그리고 이 문제는, 적어도 현 시점에서는 LLM이 아니라 인간이 해결해야 할 영역이다. 그렇다면, 취준생들과 주니어들이 가장 힘을 들여 공부해야 할 것은....

⭐ 소프트웨어 아키텍처

그 첫번째 답이 바로 소프트웨어 아키텍처 되시겠다.

위에 말했던 스파게티 요리사 주니어 개발자들이 계속해서 등장하는 이유는, 아직 소프트웨어의 전체 구조를 판단할 기준이 없는 상태에서 부분적인 해답만 계속 받아들이기 때문인 경우가 많다. LLM은 그럴듯한, 게다가 동작까지 하는 코드 조각을 계속 생성해준다. 당장은 움직이겠지만, 시간이 지날수록 수정 비용이 기하급수적으로 늘어나고, 작은 변경 하나에도 예상치 못한 버그가 터지며, 결국 “어디를 고쳐도 망가질 것 같아서 아무도 손대지 못하는 코드”가 반복되고, 아래처럼 되어버리는 것이다.

특히 취준생 여러분 입장에서 가장 큰 문제는, 어느 정도 수준의 구현은 이제 누구나 할 수 있는 시대가 되었다는 것이다. 여러분이 이력서에 자랑하는 대부분의 개인/팀 프로젝트들이나 클론 프로젝트들도, 우리 옆집 사시는 개발 미경험 와타나베씨도 아마 구현 자체는 30분 안에 똑같이 할 수 있을것이다.

그래서 아키텍처다

실무적으로 말하면, 아키텍처는 다음 질문들에 대한 기준이다.

• 이 기능은 어디에 구현되어야 하는가
• 이 변경이 시스템의 어느 범위까지 영향을 미치는가
• 무엇은 쉽게 바뀌어도 되고, 무엇은 쉽게 바뀌면 안 되는가

이 기준이 없으면, 우리는 LLM이 뱉어주는 코드에 대해 매번 “작동하네 나이스. Accept.” 같은 감각적인 판단에 의존하게 된다. 그리고 LLM이 가장 잘하는 것도 바로 이 지점이다. 그럴듯해 보이는 답변, 깔끔한 구조, 작동하는 코드. 그리고 빠진 철골 판단 기준이 없는 사람일수록 그럴싸함에 끌리기 쉽다.

아키텍처 능력이 생긴다면

LLM에게 단순히 “이거 만들어줘”가 아니라, 설계를 같이 전달하게 되면, 위에 이야기했던 문맥적인 부분의 토큰 절약이 상당하다. 또한, LLM이 판단해야 할 영역 (암묵적인 룰, 코드의 책임 등)들을 줄여주기 대문에, 자연스럽게 산출물의 효과 향상으로 이어진다.

내가 지금 신입 개발자를 뽑는다면, 구현 능력이 좋은 신입보다는, 전반적인 그림을 이해하고, AI를 위한 블루프린트를 제공해줄 수 있는 신입을 뽑게 될것 같다. 이렇게 명확한 설계를 제공해 주면, 앞서 이야기한 LLM의 한계에도 불구하고 검증 비용이 눈에 띄게 줄지 않을까. 큰 그림을 보는 이 능력은 LLM이 아무리 발전해도 쉽게 대체되지 않을 역량이라고 생각한다.

결과적으로 LLM은 그럴듯한 코드 생성기가 아니라, 내가 그려놓은 구조를 충실하게 구현해주는 도구가 되는것이다.

어떤 아키텍처를 공부할까요?

곧바로 DDD, 클린 아키텍처, 마이크로서비스를 구글에 검색하고 있다면 우선 잠깐 멈추자.

위의 아키텍처들을 아는것은 물론 중요하지만, 이것들은 목적이 아니라 수단이라는 것을 잊어서는 안된다. 서비스 하나를 구현하는데 채택 가능한 아키텍처 방법은 수만가지가 있다. 이 상황 안에서 비즈니스적인 요건, 현실적인 조건들 하나하나가 얽히게 되고, 이 안에서 최적의 아키텍처를 선택할 수 있는 능력이 가장 중요한 것이다.

즉, 중요한 것은 “DDD를 썼는가?”, “클린 아키텍처를 적용했는가?”가 아니라, “왜 이 구조를 선택했는가?”를 설명할 수 있는가이다.

그러면 뭘 공부하란거에욧

개인적인 의견으로, 가장 좋은 방법은 스스로 서비스를 0부터 만들어, 실제 유저에게 서비스해보는 것이다.

실제 서비스해보게 되면, 여러가지 변수에 맞닥뜨리게 되고, 그 과정에서 위에 얘기했던 선택의 순간들이 여럿 오게 된다. 그때 DDD, 클린 아키텍처 등 조사를 해보고, 현재 상황에서 최적의 선택을 하는 과정을 경험해보는것 자체가 큰 공부가 된다.

혼자 만든 서비스, 혹은 작은 팀 프로젝트라도 실제 사용자가 붙기 시작하면 상황이 달라진다. 대학생때 내가 스스로 만들어본 프로젝트도, 트래픽이 늘면서, 그리고 팀 멤버가 늘어나면서 각기 다른 문제들이 계속 늘어나기 시작했다.

팀 멤버가 늘어나자, 처음엔 빠르고 편하다고 생각했던 Express 기반 스파게티 코드가 곧바로 발목을 잡았다. 가독성은 점점 나빠지고, 누가 봐도 위험해 보이는 부분이 늘어났다. 결국 아키텍처와 유지보수를 이유로 Spring으로 이전하는 결정을 하게 됐다. 엔티티화 된 코드를 보자 바로 효율이 상승했다.

트래픽이 늘어나면서는 또 다른 선택의 순간이 온다. AWS 서버 비용이 감당되지 않기 시작했고, 병목이 어디서 생기는지 고민해야 했으며, 멀티 쓰레딩, 동시성 처리, 캐싱 전략 같은 것들을 하나씩 공부하게 됐다.

돌아보면, 내가 한 건 DDD를 적용한 것도 아니고, 클린 아키텍처를 완벽하게 구현한 것도 아니었다. 지금도 못한다
그저 매번 선택의 기로에서 “지금 이 결정이 시스템 전체에 어떤 영향을 미칠까?”를 고민했을 뿐이다. 하지만 바로 이 고민이, 지금 보면 아키텍처라는 이름으로 불리는 모든 개념들의 출발점인것 같다. 그리고 이 능력은, LLM 시대에도 그대로 통한다.

⭐ 클라우드 인프라

아키텍처 이야기를 하다 보면, 자연스럽게 다음 질문으로 넘어가게 된다. “이 구조는 실제로 어떻게 운영될 것인가?” 그리고 이 질문은, LLM과 함께 개발하는 환경에서는 더 빨리, 더 자주 등장한다. 구현 속도가 빨라질수록, 운영에서의 선택이 더 빠르게 문제로 돌아오기 때문이다.

코드를 어떻게 나눌지 고민하는 것만으로는, 실무의 절반밖에 설명되지 않는다. 결국 이 코드는 어딘가에서 돌아가야 하고, 비용을 쓰고, 장애를 만나고, 트래픽을 견뎌야 한다. 그리고 이 코드들은 결국 대부분의 회사에서는 클라우드 환경에서 돌아가게 된다.

내가 취준할때만 해도, "인프라 엔지니어는 어느정도 개발 실무 경험을 해야 시도해 볼 수 있는 직종"의 이미지가 강했다. 그래서 인프라보단 우선 구현을 공부하자! 같은 느낌이었다.

다만 LLM과 함께 코딩하는 지금 시대에, 개인적으로 신입 레벨에서도 클라우드 인프라에 대한 기초적인 이해가 필요하다고 생각한다.

클라우드는 아키텍처의 연장선

클라우드를 공부한다는 것은, AWS 서비스 이름을 외우거나 쿠버네티스를 능숙하게 다루는 것을 의미하지 않는다. 아키텍처를 고려할때와 비슷하게, 각 서비스는 어떤 특징이 있고, 특정 서비스를 선택하는 것이 성능적으로 어떤 효과를 가져올지, 한 달 뒤 비용으로 얼마를 만들어낼지 등 트레이드오프를 제대로 알고, 제대로 된 판단을 할 수 있게 지식을 키워가는 것이다.

모든 신입이 인프라 전문 엔지니어가 될 필요는 없다. 나도 아직 못한다 하지만 적어도 내 코드가 어떤 서비스 위에 올라가 있는지, 특정 인프라/서비스를 고려했을때 어떤 방식으로 코드를 짜야할지, 이 서비스 대신 저 서비스를 사용하면 생길 트레이드오프가 무엇인지 정도는 생각해본적이 있어야 한다고 생각한다.

인프라에 대한 이해가 생긴다면

프론트엔드든 백엔드든, 인프라를 직접 구현하지 않더라도 인프라를 이해하고 있으면 LLM을 사용하는 방식 자체가 달라진다. 정말 간단한 예로 서버리스 환경에서 돌아가는 로직을 짤때, 인프라의 이해가 없이 요건만 뱉는다면 전역 상태를 포함하고 있고, 호출 비용을 고려하지 않은, 로컬 환경 기준으로는 그럴듯하지만 서버리스 환경에서는 애매한 코드를 내놓기 쉽다. 이런 경우 안쓴것만도 못하기에 결국 시간을 낭비하는 셈이다.

반대로 이해도가 있다면, 호출당 비용, 상태 관리등을 고려한 "똑똑한" 지시를 내릴 수 있고, 결과적으로 실무에 바로 쓸 수 있는 코드가 나오게 된다. 이 변화는 인프라를 잘 짜서 생기는 게 아니라, 내 코드가 어디서 어떻게 살아갈지 알고 있기 때문에 생긴다.

이건 그럼 어떻게 공부해요?

클라우드 경험이 없다면, 우선 시장점유율이 가장 높은 AWS부터 공부해보는것을 추천한다. 위에 말했던것처럼 우선 스스로 서비스를 개발해서 유저들에게 제공해보고, 클라우드 환경에 디플로이 해보자.

어느정도 실전 경험이 쌓이면, Fundamentals 계열의 자격증들부터 취득을 추천한다. Dump라고 불리는 기출문제들도 많고, 각 회사들이 자신들의 클라우드 서비스 보편화를 위해 무료 학습 자료도 많이 제공하고 있으니, 수험 비용을 제외하면 (재직중인 경우 회사가 수험비를 내주는 경우도 많다) 무료로 학습이 가능하다. 특히 AI Fundamentals 계열의 자격증들은 LLM에 대한 공부도 되니 일석이조다. 이력서도 한줄 추가 가능한건 덤이다.

그리고 AWS/Azure/GCP 3대장은 서비스 이름만 다르지 다들 똑같은 서비스들이 정말 많다. 때문에 가능하다면 한가지 플랫폼에만 종속되지 않고, 시간이 되면 다른 클라우드 서비스도 공부하고 사용해보길 권장한다. 실무도 예전처럼 AWS만 쓰는 경우는 잘 없고, 나도 3년여 일하면서 벌써 AWS, GCP, Azure를 모두 실무에서 사용해보았다. LLM은 클라우드 간 차이를 알아서 고려해주지 않는다. 그래서 개발자가 이 차이를 알고 있을수록, AI는 더 정확한 실행 도구가 된다.

마치며

위의 생각들을 계속 하다 보니, 작년 말에 풀스택 개발자에서 AI 클라우드 컨설턴트 직무로 커리어 체인지를 겸한 이직을 하게 됐다. 개발자로서의 성장이 더 이상 코드 몇 줄의 속도로 측정되지 않는 시대라는 판단이었고, 지금까지는 그 선택을 후회하지 않고 있다.

개발 능력으로 LLM에게 져버린 현재 상황에서, 다들 비슷한 고민을 하고 있을 것이라 생각하고, 내가 컨설턴트라는 역할을 택한 이유도, 이 시대에서 살아남기 위해서는 더 큰 그림을 그리고 판단하는 역할이 필요하다고 느꼈기 때문이었다.

컨설턴트적인 능력을 연습하며 회사 선배들에게 항상 듣는 말이 큰 그림을 볼 줄 알아야 한다는 것이다. 위에 계속 이야기했던 아키텍트, 인프라 부분과도 일맥상통하며, LLM의 기술적인 면과도 이어져서 이런 능력들이 더 좋은 결과물을 만드는데 기여하고 있음을 최근 많이 느끼고 있다.

LLM 모델들은 아마 이 글을 올리고 3개월 후만 봐도 지금보다도 훨씬 더 똑똑해져 있을 것이다.

하지만 적어도 지금까지의 경험으로는, AI가 생각하지 않아도 되게 큰 그림을 만드는 역할은 여전히 인간의 몫이다. 취준생 여러분도, 나같은 주니어 여러분도 포커스를 잘 잡아서 AI를 가장 잘 조종할 수 있는 파일럿이 되었으면 좋겠다.

참고자료

타이틀 짤: 링크