시리즈 · AI는 어떻게 개발자들의 벽을 허물었나
1회 · AI는 어떻게 개발자들의 벽을 허물었나 1 - 분야별 장벽은 왜 깊어졌나
웹·게임·임베디드의 개발 장벽과 AI 도구가 이를 재구성하는 방식을 살펴보는 3부 연재의 첫 글이다. 개발자는 한 가지 언어를 잘 아는 사람이라기보다, 서로 다른 층의 연결 비용을 감당해 온 사람이다.
한 프로젝트를 오래 하면 다른 분야의 개발자가 낯설어진다. SI 웹 개발자는 게임 서버의 스레드 모델을 멀게 느끼고, 게임 개발자는 기판과 시리얼 포트가 나오는 순간 속도를 늦춘다. 임베디드 개발자는 브라우저의 프레임워크 교체 주기를 외부 세계의 일처럼 볼 수 있다. 이것은 누가 더 똑똑해서가 아니다. 각 분야가 요구하는 지식의 형태가 달랐기 때문이다.
이 글은 그 차이를 과장 없이 정리한다. 다음 편부터 다룰 AI의 역할도 “모든 기술을 자동으로 해낸다”가 아니라, 낯선 경계에 처음 진입할 때 필요한 탐색·번역·실험의 비용을 어떻게 낮추는가로 보려 한다.
여기서 SI 웹은 금융·공공·기업 업무 시스템을 포함한 넓은 웹 개발 현장을 뜻한다. 회사와 프로젝트마다 쓰는 언어·프레임워크는 크게 다르며, 아래 목록은 전부를 한 사람이 동시에 써야 한다는 뜻이 아니다.
웹의 장벽은 깊이보다 조합에서 생긴다
웹은 겉으로 보기에 진입 장벽이 낮다. 브라우저에 HTML을 띄우고 CSS를 입히고 JavaScript로 동작을 붙일 수 있기 때문이다. 그러나 현장에서는 화면만 만들지 않는다. HTTP, 인증, 데이터베이스, 배포, 접근성, 브라우저 호환성, 로그, 보안 패치와 운영 장애가 한 제품 안에서 만난다. MDN도 브라우저 API, 제3자 API, 라이브러리·프레임워크를 별도 층으로 설명한다. 이 층들이 만나는 지점이 웹의 진짜 난이도다. MDN의 클라이언트 API 개요가 좋은 출발점이다.
언어와 도구를 같은 바구니에 넣으면 이 복잡성이 더 흐려진다. HTML·CSS·JavaScript·TypeScript와 SQL은 표현·질의 언어이고, Java·C#·PHP 같은 서버 언어가 있다. XML·JSON은 데이터 표현 형식이며 JSP는 Java 기반 서버 페이지 기술이다. Spring·Spring Boot·전자정부 프레임워크는 서버 프레임워크, React·Vue·Angular·Svelte는 클라이언트 UI 생태계, Node.js는 런타임, Vite는 빌드 도구, Electron은 데스크톱 런타임이다. MySQL·Oracle·MSSQL·PostgreSQL은 서로 다른 운영 특성을 가진 DBMS다. CSS도 ‘CSS5’라는 하나의 통합 버전으로 진화한 것이 아니라 모듈과 브라우저 호환성의 조합으로 발전해 왔다.
그래서 실제 업무는 대개 다음처럼 보인다.
// 화면 상태는 간단해도, 인증·API 계약·오류 상태는 함께 설계해야 한다.
type Profile = { id: string; displayName: string };
export async function loadProfile(signal: AbortSignal): Promise<Profile> {
const response = await fetch('/api/me', {
headers: { Accept: 'application/json' },
credentials: 'include',
signal,
});
if (!response.ok) throw new Error(`profile request failed: ${response.status}`);
return response.json() as Promise<Profile>;
}
이 짧은 함수 뒤에는 세션 정책, CORS, API 버전, DB 스키마, 장애 관측, 개인정보 처리 같은 결정이 숨어 있다. 웹 개발자가 넓게 알아야 했던 이유는 “기술 하나를 얕게 안다”가 아니라 이 결합을 매번 다른 조합으로 책임져야 했기 때문이다. AI 코딩 시대의 핵심 변화도 여기서 시작된다. AI는 이 조합의 후보를 빠르게 펼칠 수 있지만, 어떤 정책을 택할지는 여전히 제품과 조직의 맥락이 결정한다.
게임은 코드와 에셋이 함께 움직이는 분야다
게임을 “C++을 잘하면 되는 분야”로 축소하면 절반을 놓친다. 성능에 민감한 엔진·네트워크·도구 영역에서 C++가 널리 쓰이지만 C#을 포함한 여러 스택이 공존한다. 더 중요한 점은 게임 제품이 코드만으로 구성되지 않는다는 것이다. 씬, GameObject, Component, Prefab, 텍스처, 머티리얼, 3D 모델, 애니메이션과 사운드가 서로 참조한다. Unity의 핵심 개념 문서는 이 구성 요소를, Inspector 문서는 코드 변경 없이 컴포넌트와 공개 변수를 조정하는 방식을 설명한다.
예를 들어 아래 C#은 매우 평범하다. 하지만 target에는 Prefab 또는 씬의 오브젝트가, speed에는 디자이너가 정한 수치가 연결되어야 한다.
using UnityEngine;
public sealed class FollowTarget : MonoBehaviour
{
[SerializeField] private Transform target;
[SerializeField] private float speed = 4f;
void Update()
{
if (target == null) return;
transform.position = Vector3.MoveTowards(
transform.position, target.position, speed * Time.deltaTime);
}
}소스 저장소에 코드가 있어도 어떤 Prefab이 연결됐는지, 임포트 옵션과 머티리얼이 어떤 시각 결과를 만들었는지, 플레이 중 어떤 감각이 어색했는지까지 텍스트만으로 완전히 복원하기 어렵다. Unity는 에셋의 식별자와 참조를 .meta 데이터로 관리한다는 점을 Asset workflow에서 설명한다. 따라서 “에디터 작업은 AI가 배울 수 없다”가 아니라 “코드 외의 에셋·시각 평가·실행 맥락이 필요해 텍스트만으로는 불완전하다”가 정확한 표현이다.
Unreal도 같은 교훈을 준다. Epic은 Blueprint와 C++ 비교에서 대부분의 프로젝트가 둘을 함께 쓸 때 이득을 본다고 안내한다. Blueprint는 에셋과 API 탐색에, C++는 텍스트 diff·merge와 저수준 제어에 장점이 있다. 셰이더·애니메이션·이펙트는 Material, Niagara, Sequencer 같은 별도 도구와 아트 파이프라인에 걸쳐 있다. 그러므로 게임 개발의 경계는 언어 경계이면서 동시에 제작 파이프라인의 경계다.
임베디드의 장벽은 물리 세계가 끼어든다는 데 있다
임베디드에서 코드가 맞아도 제품이 안 될 수 있다. 보드 전원, 핀 배치, 전압, 펌웨어 버전, 센서 노이즈, 직렬 통신 속도, 부트 순서가 결과에 관여한다. 문제가 생기면 로그 한 줄로 끝나지 않고 케이블·측정기·기판·다른 펌웨어 버전을 함께 확인해야 한다. Linux 기반 보드라면 OS, 디바이스 트리, 드라이버, 권한과 파일 시스템이 추가된다. 브라우저 기반 UI가 장치와 통신해야 할 때는 로컬 서비스나 네이티브 브리지가 필요해지는 경우도 있다.
가령 시리얼 장치를 처음 만날 때도 코드는 쓰기 전에 ‘무엇이 연결되었는지’를 확인한다.
# 개발용 Linux 장비에서 연결된 USB 직렬 장치와 최근 커널 로그를 읽는다.
ls /dev/ttyUSB* /dev/ttyACM* 2>/dev/null
sudo dmesg --ctime | tail -n 40
stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb
이 명령은 장치를 제어하거나 펌웨어를 쓰지 않는다. 연결 상태와 통신 조건을 확인하는 첫 단계일 뿐이다. 같은 기능도 칩 제조사, 보드 설계, 운영체제, 블루투스 스택에 따라 전혀 다른 디버깅 경로를 갖는다. 이것이 임베디드의 전문성이 단순 C/C++ 문법 이상이 되는 이유다.
경계는 지식 부족이 아니라 검증 비용의 이름이다
세 분야의 차이를 표로 압축하면 다음과 같다.
| 분야 | 핵심 복잡성 | 코드 밖의 증거 | 실패를 확인하는 방식 |
|---|---|---|---|
| SI 웹 | 여러 계층과 제품 요구의 조합 | 운영 정책·브라우저·데이터 | 테스트·로그·사용자 흐름 |
| 게임 | 실시간 성능과 에셋 파이프라인 | 씬·Prefab·아트·플레이 감각 | 프로파일링·플레이 테스트 |
| 임베디드 | OS와 하드웨어의 결합 | 보드·전원·센서·펌웨어 | 계측·로그·실기기 반복 시험 |
게임의 병렬 처리도 좋은 사례다. 성능 문제를 스레드로 나누면 빨라질 수 있지만, 데이터 경합과 재현하기 어려운 버그가 생긴다. Unreal의 성능 고려 사항은 스레드와 race condition의 주의를 명시한다. ‘두 손을 각각 동시에 다른 물고기 통에 넣고 작은 물고기를 동시에 낚는’ 듯한 코딩으로도 예를 들어볼 수 있지만, 실무적인 실제 해법은 훨씬 어렵고 복잡한 프로파일링과 측정을 필요로 한다.
AI가 분야 장벽을 낮춘다고 해서 책임의 경계가 사라지는 것은 아니다. 특히 게임의 프레임 타임, 웹의 개인정보, 임베디드의 전기·기계 안전은 생성된 코드가 아니라 실제 측정과 승인 절차로 확인해야 한다.
과거에 개발자가 자기 분야에 몸값을 쌓은 것은 비밀 기술을 독점해서 그런것은 아니다. 개발자가 특정 분야의 기술을 익히는 일은 그 하나만으로도 벅찬 이유가 더 크다. 다음 글에서는 AI가 그 첫 탐색의 지도를 왜 더 빨리 그릴 수 있게 되었는지, 그리고 공개 코드와 코드 중심 인터페이스가 왜 중요한지 살펴본다. 익숙한 개발자 CLI조차 AI와 결합하면 단순 명령 창이 아니라 실험의 인터페이스가 된다.
댓글 없음:
댓글 쓰기