공학에서 AI를 이해하기

발행: 5일 전 (2026년 2월 3일 오후 12:04 GMT+9)

18 분 소요

Source: Dev.to

When talking about AI in software engineering, I often hear things like:

“I don’t trust it.”
“Does it really save any time?”
“Why use it when I can just do it myself?”
“It’s just a statistical model.”
“It just writes slop.”

These concerns aren’t all wrong. Under the hood, modern AI is a statistical model—but that doesn’t mean it isn’t useful.

My goal isn’t to sell you on AI or write an academic paper. I want to give you a clear, practical look at how today’s models actually work so you can better judge when they’re valuable and when they’re not.

To do that, it helps to understand where a lot of this skepticism came from.

Source: …

어제의 AI

10년 전인 2010년대 중반으로 돌아가 보겠습니다. 그때는 머신 러닝이 화두였고, 우리는 사물을 “AI”라고 부르기 시작했지만 대부분은 좁고 특화된 모델이었습니다.

당시의 생각은 간단했습니다: 컴퓨터는 숫자를 잘 다루므로 텍스트, 이미지, 기타 복잡한 데이터를 숫자로 변환할 수 있다면 모델을 훈련시킬 수 있다는 것이었습니다. word2vec와 같은 도구가 대중화하면서 벡터 임베딩이라는 기술이 가능해졌는데, 이는 단어나 이미지를 의미를 어느 정도 보존하는 수치 벡터로 표현합니다.

그 다음 우리는 대규모 라벨이 달린 데이터셋을 이용해 모델을 훈련시켰습니다. 모델에 예시를 보여주면 됩니다:

“이것은 머핀이다.”
“이것은 머핀이 아니다.”

시간이 지나면서 모델은 새로운 이미지가 머핀일 가능성이 있는지 판단할 수 있는 통계적 패턴을 학습했습니다.

제한 사항

지도 학습, 좁고 작업‑특정: 모델은 하나의 일을 잘하도록 훈련되었습니다(예: 이미지 분류, 텍스트 태깅, 스팸 감지).
한 번에 하나의 입력: 매우 제한된 문제 영역에서만 작동했습니다.
취약하고 훈련이 느림: 머핀을 잘 구분하는 모델은 암을 탐지하거나 텍스트를 번역하는 데는 쓸모가 없었습니다.
소규모: “큰” 모델이라 해도 수백만(때로는 수천만) 정도의 파라미터에 불과했으며, 훈련 데이터만큼만 성능이 좋았습니다.

그러한 역사를 보면 많은 엔지니어들이 “AI”를 신뢰하지 않게 된 것은 당연합니다.

Source: …

무엇이 바뀌었는가

그렇다면 우리는 어떻게 그 세계에서 오늘날 사용하는 생성 모델로 옮겨왔을까요? 여러 가지 변화가 있었지만, 가장 중요한 세 가지가 있습니다.

1. Transformers

가장 중요한 전환은 transformer 아키텍처의 도입이었습니다.

Transformer 이전에 모델은 주로 순차적으로 언어를 처리했으며—한 번에 한 단어씩—장거리 의존성을 이해하는 능력이 제한적이었습니다.

예시: “The bank can guarantee deposits will eventually cover future tuition.”
“bank”가 금융 기관을 의미하는지 강가를 의미하는지 알기 위해서는 나중에 등장하는 단어들, 즉 “deposits”, “cover”, “tuition”을 살펴봐야 합니다. 순차 모델은 “bank” 주변의 문맥이 나중에 등장하는 단어에 도달할 때쯤 사라져 버리기 때문에 어려움을 겪었습니다.

Transformers는 attention을 통해 이를 해결합니다: 단어를 하나씩 처리하는 대신, attention은 모델이 모든 단어를 동시에 바라보고 서로 어떤 것이 관련 있는지 학습하게 합니다. “bank”를 처리할 때 모델은 거리와 관계없이 직접 “deposits”와 “tuition”에 주목할 수 있습니다.

여러 attention 층이 서로 위에 쌓여 점점 더 정교한 관계를 학습합니다.
초기 층은 “bank” → “deposits”를 연결하고, 더 깊은 층은 “deposits” → “cover future tuition”을 연결해 전체 문장의 풍부한 이해를 구축합니다.

이 단일 변화만으로도 모델이 이해하고 생성할 수 있는 범위가 크게 확대되어, 머신러닝이 좁은 분류 작업을 넘어 일반 목적 언어 모델로 발전하게 되었습니다.

2. Model‑Native Context

10년 전만 해도 컨텍스트는 주로 애플리케이션 코드에서 관리되었습니다. 고객 리뷰에 대한 감성 분석을 수행하려면 다음과 같은 절차가 필요했습니다:

각 리뷰를 모델이 기대하는 정확한 형식(예: 몇 십 단어, 불필요한 데이터 제거)으로 전처리합니다.
각 리뷰마다 별도의 예측을 실행합니다.
결과를 수동으로 집계합니다.

모델은 이전 리뷰에 대한 기억이 없었고, 제품에 대한 이해도 없으며, 고객 이력에 대한 인식도 없었습니다. 각 예측은 독립적이었고, 실제 토큰 제한은 요청당 수백 개에 불과했습니다. 모델은 무상태(state‑less)였으며 호출 사이에 모든 것을 “잊어버렸습니다”.

오늘날 컨텍스트는 대부분 모델‑네이티브입니다. 최신 모델은 훨씬 큰 윈도우—보통 수십만 토큰—에 걸쳐 스스로 관리합니다.

제품 문서 전체, 고객 피드백 모음, 최근 지원 티켓, 현재 기능 로드맵을 한 번에 모델에 입력할 수 있습니다.
모델은 고객이 체크아웃 과정에 불만을 갖는 이유가, 지난달에 폐기한 기능이 실제로는 워크플로우 문제를 해결해 주었음에도 불구하고 인식되지 않았다는 것을 파악할 수 있습니다.
고객의 고충을 물어보면, 모델은 관련 컨텍스트에 동적으로 가중치를 부여해 채널 간 불만을 연결하고, 서로 다른 사용자 세그먼트가 동일한 문제를 어떻게 표현하는지 패턴을 찾아내며, 일회성 혹은 무관한 피드백은 우선순위를 낮춥니다.

이 때문에 모델은 이제 사용자 연구를 종합하거나 다양한 사용 사례를 반영한 문서 생성과 같은 작업을 지원할 수 있습니다. 제한 요소는 “모델이 충분히 볼 수 있느냐?”에서 “모델이 본 것을 얼마나 효과적으로 추론하느냐?”로 바뀌었습니다.

3. Scale and Generality

Transformer가 효율적인 attention 처리를 입증하자, 두 가지 상보적인 흐름이 나타났습니다:

모델 규모의 대규모 확장 – 수백만 파라미터에서 수천억 파라미터까지.
다양하고 방대한 데이터셋으로 학습 – 웹 텍스트, 코드, 이미지, 멀티모달 데이터 등.

이러한 흐름은 일반 목적 기반 모델을 탄생시켰으며, 이 모델은 프롬프트만으로도 특정 작업에 맞춘 미세 조정 없이 다양한 작업을 수행할 수 있습니다. 코드를 작성하는 모델이 이메일을 초안하고, 언어를 번역하며, 단위 테스트를 생성하는 등 프롬프트만 바꾸면 됩니다.

Bottom Line

Modern AI is still a statistical model, but transformer architectures, model‑native context, and massive scale have turned it into a versatile, general‑purpose tool.
Understanding these three shifts helps you decide when to trust the model, when it adds real value, and when a traditional, deterministic solution is still the better choice.

Use this perspective to evaluate AI proposals in your projects: ask what the model is being asked to do, how it will be given context, and whether its scale and generality are appropriate for the problem at hand.

Scaling Up: From Curated Datasets to Massive, Diverse Corpora

우리는 규모를 확장할 수 있었기에, 훨씬 더 넓은 데이터셋—공개 텍스트, 코드, 문서, 책, 그리고 연구 자료—에 대해 모델을 학습시키기 시작했습니다.

예전 방식은 특정 작업을 위해 데이터셋을 선별하는 것이었습니다. 스팸 필터를 만들기 위해 수천 개의 라벨링된 스팸 이메일을 모으거나, 종양을 탐지하기 위해 수천 장의 의료 영상을 수집하곤 했습니다. 각 모델은 전문가였죠.

새로운 접근 방식은 이를 뒤집습니다. 서로 다른 작업을 위해 서로 다른 모델을 학습시키는 대신, 단일 모델을 거대한 다양성 있는 데이터셋에 학습시켜 모든 데이터에서 일반적인 패턴을 스스로 배우게 합니다.

이것이 중요한 이유는, 그런 패턴은 규모가 커져야 비로소 나타나기 때문입니다.

백 개의 파이썬 스크립트로 모델을 학습 → 기본 문법을 학습합니다.
수백만 개의 저장소를 수십 개 언어에 걸쳐 학습 → 더 깊은 패턴을 학습합니다: 아키텍처 결정이 특정 버그를 초래하는 방식, 생태계마다 다른 테스트 전략, 네이밍 컨벤션이 의도를 나타내는 방법 등.

그래서 현대 모델에게는 여러분이 한 번도 러스트(Rust)를 작성해 본 적이 없더라도 러스트 코드를 작성하도록 요청하거나, 복잡한 알고리즘을 “친구에게 설명하듯이” 설명하도록 요청할 수 있습니다. 모델은 충분히 많은 예시를 보았기 때문에 일반화하여 이전에 전혀 접해보지 못한 요청에도 대응할 수 있습니다.

우리는 수백만 개의 파라미터에서 수십억 개의 파라미터로 전환했습니다. 그 결과는 근본적으로 다른 종류의 도구가 탄생한 것입니다—단일 작업에 국한되지 않고 여러 분야에서 활용될 수 있는 도구 말이죠.

오늘날 AI가 다르게 느껴지는 이유

These changes did not turn statistical models into magic. What they did was make them broadly useful.

Modern models can ingest large portions of a codebase and reason across multiple files.
They can synthesize information from documentation, tests, and error output in a way older systems never could.

Yes, they are still predicting the most likely next token. The difference is that they do so with:

far more context,
better representations, and
significantly improved performance.

That is why an LLM can often help you track down a nasty bug or draft a reasonable implementation sketch in minutes. Tasks that once required hours of manual searching and context‑switching can now be accelerated.

모델이 뛰어난 영역과 어려움을 겪는 영역

강점

대규모 컨텍스트에서 패턴 인식 및 종합.
코드, 테스트, 문서의 초안을 생성.

제한점

의견이 강하게 나타나며, 아키텍처와 맞지 않을 수 있는 일반적인 패턴으로 유도하는 경향이 있음.
복잡한 변경을 반복할 때, 특히 테스트가 예상치 못하게 실패하기 시작하면 방향을 잃을 수 있음.

여러 면에서 그들은 과도하게 열정적인 인턴과 비슷하게 행동한다: 진정으로 도움이 되고, 놀라울 정도로 능력 있으며, 때때로 스스로에게 너무 자신감이 넘친다.

엔지니어가 접근하는 방법

작게 시작하기 – 출력 결과를 쉽게 검증할 수 있는 저위험 작업을 사용하세요.
- 예시: 방금 작성한 함수에 대한 테스트를 생성하도록 모델에 요청합니다. 함수와 관심 있는 엣지 케이스에 대한 간단한 설명을 제공하세요.
- 테스트가 실제로 필요한 부분을 커버하는지, 아니면 그저 그럴듯해 보이는지만 확인합니다.
정확한 프롬프트 작성
- 모호함: “이걸 더 좋게 만들어” → 모호한 결과.
- 구체적: “사용자 리스트가 비어 있을 경우를 처리하도록 이 함수를 리팩터링해” → 더 나은 결과.
- 기억하세요: 모델은 제공받은 정보 외에는 아무 컨텍스트도 없으니 제약조건, 요구사항, 우려사항을 명확히 제시해야 합니다.
드리프트 감시 – 복잡한 변경을 반복하면서 제안이 필요와 점점 멀어지기 시작하면 신호입니다.
- 더 많은 컨텍스트를 제공하거나 문제를 작은 단계로 나누거나 해당 부분을 직접 처리하세요.
다양한 작업 유형에서 실험
- 잘 작동함: 보일러플레이트 생성, 문서 초안 작성, 익숙하지 않은 코드 설명, 테스트 케이스 제안.
- 성공 여부가 갈림: 시스템 설계, 미묘한 트레이드오프 결정, 미세한 동시성 문제 디버깅.
출력을 최종 솔루션이 아닌 초안으로 다루기
- 출력이 맞아 보이더라도 꼼꼼히 읽어보세요.
- 모델은 틀렸을 때도 자신감 있게 답변합니다; 컴파일은 되지만 잘못된 동작을 하거나 코드베이스에 맞지 않는 패턴을 사용할 수 있습니다.
워크플로에 신중히 통합하기
- 모델이 강점이 있는 영역과 약점이 있는 영역을 이해하고, 그 강점을 활용하도록 프로세스를 조정하세요.

당신 차례

만약 이 도구들을 실험하고 있다면, 여러분이 어떤 결과를 얻고 있는지 궁금합니다.

무엇이 효과적이었나요?
무엇이 효과가 없었나요?
어디에서 놀라움을 느꼈나요?

여러분의 경험을 공유하고, 함께 배워봅시다.