시스템 엔지니어가 LLM을 만지며 깨달은 것

x3C!-- 히어로 -->

에세이 · 시스템 엔지니어의 시선

시스템 엔지니어가
LLM을 만지며 깨달은 것

이미 LLM으로 개발해 온 분들에겐 "이걸 이제 알았냐?" 싶은 이야기일 수 있습니다. 경험자들 사이에선 거의 상식이라네요. 그래서 좀 챙피하긴 한데, 늦게 스스로 깨달은 사람 나름의 시선이 담긴 글이니 편견 없이 재밌게 읽어 주셨으면 합니다.

 

x3C!-- 본문 -->

x3C!-- 1. 시작 -->

시작은 생업에 대한 고민이었다

요즘 나는 "AI가 내 일을 대체할 수 있을까"에 관심이 많다. 솔직한 이유는 몸에 약간 이상이 와서 키보드 타이핑이 불편해졌기 때문이다. 키보드로 밥 먹고 사는 사람에겐 작지 않은 일이다.

택시 기사가 생계가 걸린 상황에서 몸에 이상이 오면 어떻게 했을까를 생각하다, 자율주행이 떠올랐다. 내 분야도 비슷하다. 다행히 내 머리는 멀쩡하니, AI에게 손을 조금 빌리면 어떨까 하는 생각이 들었다. 아직 생업을 더 이어가야 하기에 진지한 고민이다. 그래서 요즘은 "AI로 업무가 어디까지 대체되는가"를 매일 실험하고 있다. 이 열정이 언제 식을지는 모르겠지만.

그 짧은 기간에 LLM의 성질을 스스로 크게 깨닫게 되었다. 혹시 이 성질을 모르고 살았던 나 같은 분들도 있을까봐 알아두면 좋을 것 같아 정리해 본다.

x3C!-- 2. 배경 -->

내 배경부터

현업은 시스템 엔지니어지만, 시작은 C 개발자였다. C를 하다 보면 OS와 가까워지는데, 그쪽이 흥미로워 시스템 엔지니어로 전향했다. C 코딩을 손에서 놓은 지는 꽤 됐지만 웬만한 건 아직 짠다.

개발자 시절엔 신경 쓸 게 많았다. 기능 추가를 염두에 둔 모듈화, 성능을 위한 구조, 팀의 코딩 컨벤션. 함수와 변수 이름을 누구나 알아보게 일관되게 짓는 일은 생각보다 시간을 많이 잡아먹는다. 특히 C는 요즘처럼 가비지 컬렉터(사용이 끝난 메모리를 자동으로 정리해 주는 기능)가 없어 메모리 누수가 없도록 자원 할당·해제를 일일이 직접 챙겨야 했고, 설계가 어긋나면 후임자의 유지보수도, 기능 추가도 어려워진다. 그래서 초반 구조 설계는 정말 중요했다.

시스템 엔지니어도 코딩을 아예 안 하는 건 아니지만, 복잡한 수준은 아니라 AI 코딩 툴까지 쓸 일은 없었다. 그래서 요즘 개발자들이 말하는 "바이브 코딩"이 정확히 뭔지도 잘 몰랐다.

용어 정리

"바이브 코딩"은 원래 좁은 뜻이다. 안드레이 카르파티(Andrej Karpathy, 테슬라·OpenAI 출신의 AI 연구자)가 쓴 말로, 코드를 일일이 읽지 않고 AI가 내놓는 대로 흐름에 맡겨 버리는 스타일을 가리킨다. 그러니까 "LLM으로 개발한다 = 바이브 코딩"은 아니다. 진지하게 LLM을 쓰는 개발자들은 오히려 "내가 하는 건 바이브 코딩이 아니다"라고 선을 긋는다. 결과를 검증하니까. 내 결론도 결국 "검증은 사람 몫"이라 좁은 의미의 바이브 코딩과는 오히려 반대편에 있다.

x3C!-- 3. LLM 성질 -->

LLM의 묘한 성질 하나

LLM은 같은 뜻의 프롬프트를 줘도 결과가 그때그때 조금씩 다르다. 사람마다 원하는 답을 끌어내는 프롬프트 스타일이 다르고, 글자 하나만 바꿔도 결과가 달라진다. "오늘의 날씨?"와 "오늘의 날씨는?"을 직접 넣어 보면 다르다. 다만 이건 입력이 달라졌으니 당연한 일이다.

더 신기한 건, 토씨 하나 안 틀리고 완전히 똑같은 프롬프트를 줘도 답이 매번 조금씩 다르다는 점이다. ChatGPT, Gemini를 그렇게 오래 썼는데도 이걸 전혀 못 느끼고 있다가 이제야 알았다. 한번도 토씨 하나 안 틀리고 질문해 본 적은 거의 없어서 관찰을 못 했다.

이 성질은 프로그래밍에선 난감할 수 있다. 결과는 비슷한데 그 안의 구현 방식이 매번 다르면 곤란하기 때문이다. 내가 개발자였을 시절엔 구현 방식이나 코딩 스타일이 흔들리면 선배에게 많이 혼났다. 엄격한 일관성 있는 코딩은 팀 코딩에선 꽤 중요한 문제였다.

LLM은 하루가 다르게 발전해 벌써 Opus 4.8까지 나왔다. 모델에 따라 구현 방식도, 품질도, 결과도 다르다.

x3C!-- 4. 아들 과제 -->

아들의 과제로 제대로 깨달았다

첫째 아들의 전공은 교통시스템공학이다. 이번 학기 교통시스템 분석 과제가 난이도가 너무 높아 "아빠 치트키 좀 써 달라"고 했다. 과제를 보니 학부생이 맨손으로 이해하기 어려운 수준이었다. 파이썬으로 추론 구조를 직접 짜야 했는데, 솔직히 박사급도 그냥은 버거워 보였다.

"왜 이런 걸 학부생한테 내지?" 싶었는데, 알고 보니 교수님이 LLM을 적극 활용하라고 낸 과제였다. 교수님 프로필을 보니 의도가 단박에 이해됐다. 이제 교통시스템 분석은 손으로 직접 코딩하기보다 AI 툴을 잘 다루는 쪽으로 옮겨가고 있고, 그걸 잘 쓰는 학생이 좋은 점수를 받는다는 메시지였다. 세상이 변했다.

교수님의 채점 기준

"LLM으로 과제를 풀어 오면 100점. 결과가 왜 매번 다른지까지 설명할 수 있으면 추가 점수."
도구를 쓰는 능력과, 그 도구를 이해하는 능력을 같이 본 것이다.

x3C!-- 5. 원인 -->

왜 같은 프롬프트인데 답이 다를까

처음엔 나도 "AI가 왜 그때그때 다른 추론을 하는지 모르겠다, 단순 난수 문제는 아닌 것 같다"고 막연히 생각했다. 그런데 찾아보니 원인은 꽤 명확하게 규명돼 있었고, 내 짐작은 절반만 맞았다. 두 층위로 나뉜다.

1

차이의 대부분은 샘플링, 즉 난수다

LLM은 다음 토큰(단어나 음절 단위로 쪼갠 텍스트 조각)을 확률분포에서 "뽑는다". temperature(출력의 무작위성을 조절하는 설정값)가 0보다 크면 매번 주사위를 굴리는 셈이라, 같은 프롬프트라도 결과가 갈린다. 이건 정확히 난수 문제다. temperature를 0으로 두면(greedy decoding — 항상 가장 높은 확률의 토큰만 선택하는 방식) 이 무작위성은 사라진다. 그러니 "난수 문제가 아니다"라고 본 내 첫 짐작은 틀렸다. 오히려 난수가 주범이다.

2

temperature를 0으로 둬도 미세한 차이가 남는다

보통은 "GPU가 수많은 스레드를 병렬로 돌리고 부동소수점(컴퓨터가 소수를 표현하는 방식)은 결합법칙이 안 통하니, 그 난리통에 결과가 갈린다"고 설명한다. 2025년 9월 Thinking Machines(Horace He 외)의 분석은 이 통념이 핵심을 잘못 짚었다고 본다. 추론 과정의 주된 연산은 사실 요청마다 재현 가능하게 동작한다. 진짜 원인은 따로 있다. 배치 불변성(batch invariance)의 결여다.

내 요청은 그 순간 다른 사용자 요청과 함께 묶여 배치 처리(여러 요청을 한 덩어리로 묶어 한꺼번에 처리하는 방식)되는데, 서버 부하에 따라 이 배치 크기가 매번 달라진다. 그러면 GPU 커널의 합산 순서가 바뀌고, 부동소수점은 더하는 순서가 달라지면 끝자리가 미세하게 틀어진다. 그 작은 차이가 가끔 토큰 선택을 가른다. 즉 내가 보낸 똑같은 요청의 결과가, 그 순간 서버에 다른 사람이 몇 명 붙어 있었느냐에 따라 달라질 수 있다는 뜻이다.

정리

"원인 불명"이 아니라 "샘플링(난수) + 배치 크기에 따른 부동소수점 합산 순서 변동"으로 설명되는 현상이다. 난수가 주범이고, 그걸 꺼도 남는 잔여분이 배치·부동소수점 문제다. Thinking Machines는 이게 GPU 하드웨어의 숙명이 아니라 엔지니어링으로 잡을 수 있는 문제라고 본다는 점도 흥미로웠다.

x3C!-- 6. 도구 -->

도구 이야기

"아빠 큰일났어. Gemini, ChatGPT, Claude 다 잘 안 돌아가." 아들이 이미 혼자 해결했다면 아빠 치트키는 안 썼을 것이다.

마침 요즘 Claude Code를 공부 중이라 그걸로 같이 풀었다. 결과를 .ipynb(주피터 노트북 — 코드와 실행 결과를 함께 담는 파일 형식) 형태로 제출해야 해서 단순 챗 방식으론 어려웠다.

재밌는 건 그냥 돌리면 1시간 넘게 걸리던 작업이, 최근 공부하고 배운 에이전트 하네스 — 여러 에이전트에 역할을 나눠 맡기는 구성 — 를 적용하니 20분으로 줄고 결과물도 좋아졌다는 점이다. 이번엔 내가 도와줬고, 다음엔 아들이 직접 하기로 했다. 얼마 뒤 Codex로도 해보니 결과가 더 좋았다. 이 세계 툴들은 하루가 다르게 경쟁이 치열하게 발전하는 듯하다.

아들 학교에선 컴공이 아닌 공대 학과의 파이썬 프로그래밍 과목이 축소되는 분위기라고 한다. 이미 많은 학부생이 LLM으로 과제를 하는 마당이니 그럴 만도 하다. 요즘 공대생들 사이에선 더 좋은 모델을 쓰려고 AI 툴 유료 결제를 하는 게 흐름이라고도 한다.

오해 경계

"그럼 코딩을 아예 안 가르쳐도 되나?"는 아니다. 줄어도 되는 건 문법 암기와 손코딩이고, 오히려 더 필요해진 건 AI가 짠 코드를 읽고, 이해하고, 구조가 타당한지 검증하는 능력이다. 교수님이 "왜 다른지 설명하면 추가 점수"를 건 것도, 결국 그 검증 능력을 보겠다는 뜻이라고 생각했다.

x3C!-- 7. 무게중심 -->

무게중심이 옮겨갔을 뿐, 구조는 더 중요해졌다

개발 현장의 무게중심이 옮겨갔다. 사람이 일일이 문법과 스타일을 챙기던 자리는 AI가 가져갔고, 사람은 AI가 빠르고 정확하게 원하는 결과에 도달하게 만드는 방법론 — 컨텍스트 설계, 에이전트 역할 분담 같은 것 — 에 집중한다.

그렇다고 구조 설계가 덜 중요해진 건 아니다. 오히려 반대다. AI가 매번 조금씩 다른 구현을 쏟아내니, 그걸 일관된 구조로 잡아주고 검증하는 사람의 역할은 더 커졌다. 손이 하던 일을 머리가 더 많이 하게 됐다고 해야 할까.

x3C!-- 8. 장애 분석 -->

장애 분석 실험에서 얻은 관점

마지막으로 2주간, 제한된 범위에서 장애 분석 업무를 실험해 봤다. 나 같은 사람에겐 "장애가 났을 때 AI가 어떻게 판단하는가"를 보는 게 더 중요하다.

시스템 업무에 AI를 직접 물려 장애 처리를 맡기는 건 시기상조이고 위험하다. 그래서 가상 시나리오를 만들고, 장애 관찰·분석 정도만 AI가 어떻게 반응하는지 검증하는 테스트로 한정했다. 시스템 엔지니어가 알럿을 받고 수행하는 일련의 분석 행위를 그대로 학습시키고, 우리가 쓰는 장애 보고서 양식까지 훈련시켜 스스로 판단해 리포트를 쓰게 했다.

여기서 재밌는 걸 발견했다. 완전히 동일한 장애 건을 여러 번 분석시키면 결론은 같은데, 리포트 문장은 그때그때 조금씩 달랐다. 기계니까 똑같은 리포트를 기대했는데 말이다.

생각해 보면 사람도 같은 장애 리포트를 매번 복붙하지는 않는다. 뜻은 같아도 글자 수나 표현은 조금씩 다르다. 스크립트가 매번 똑같은 알럿 메시지를 쏘는 것과는 본질이 다른 것이다. 만약 장애 관제를 AI에 자율적으로 맡겨 메시지를 자동화하면, 뜻은 같아도 문장과 스타일은 계속 바뀔 수 있다. 이 관점이 나에겐 놀라운 발견이었다.

실험의 결론은, 시스템 엔지니어 영역에 AI를 직접 연결해 사람과 동일한 방식으로 굴리는 건 고려할 게 너무 많아 아직은 안 하기로 했다는 것이다. 간접 분석 보조 정도가 적당해 보인다. LLM의 본질을 파악한 것만으로도 충분히 의미 있는 2주였다.

x3C!-- 9. 결론 -->

결국

LLM에게는 "완전히 동일한 문장"이 아니라 "동일한 결론"을 기대해야 한다.

• 장애 원인은 DB 연결 고갈입니다.
• DB Pool 부족으로 인한 장애로 판단됩니다.
• 데이터베이스 연결 자원이 소진된 것으로 추정됩니다.

세 문장은 글자는 다르지만 결론은 하나다. 코드도, 리포트도, 과제도 마찬가지다.

앞으로 우리가 AI에 기대해야 할 일관성은 문장 단위가 아니라 결론 단위의 일관성이다. 그리고 그 결론이 맞는지 책임지고 검증하는 일은, 여전히 사람의 몫이다.

hexcode.tistory.com