이 글은 특정 회사의 업무나 내부 정보를 다루지 않고, 공개 자료와 개인적인 학습을 바탕으로 제조 도메인 개발자의 가능성을 정리한다.

주요 독자: AI와 Vibe 코딩 시대에 구현 능력만으로는 부족하다고 느끼고, 도메인 이해를 새로운 차별점으로 고민하는 주니어 소프트웨어 개발자.

요약

  • AI 코드 도구가 확산될수록 단순 기능 구현의 희소성은 낮아질 수 있다.
  • 하지만 현실 업무를 이해하고, 그 맥락을 요구사항, 데이터, 상태, 예외, 화면으로 바꾸는 능력은 쉽게 자동화되기 어렵다.
  • 제조 도메인은 설비, 자재, 공정, 품질, 이력, 작업자 흐름이 얽혀 있어 도메인 이해가 특히 중요하다.
  • 그래서 앞으로는 “코드를 짤 수 있는 개발자”보다 “도메인의 문제를 소프트웨어 구조로 바꿀 수 있는 개발자”가 더 희소해질 수 있다.
  • 다만 도메인 지식만으로 충분한 것은 아니며, 기본 개발 역량과 AI 결과를 검증하는 능력이 함께 필요하다.

들어가며

요즘 주니어 개발자는 이상한 압박을 느낀다. 예전에는 프레임워크를 배우고, CRUD를 만들고, 배포를 해보는 것만으로도 성장하고 있다는 느낌을 받을 수 있었다. 그런데 이제는 AI가 비슷한 코드를 몇 초 만에 만들어준다.

그러면 자연스럽게 이런 질문이 생긴다.

“이제 구현은 누구나 할 수 있게 되는 걸까?”

“나는 무엇을 더 배워야 하지?”

“AI가 코드를 만들면 개발자의 차별점은 어디에 남을까?”

이 질문에 대한 쉬운 답은 “더 어려운 기술을 배워라”일 수 있다. 더 낮은 레벨의 시스템을 공부하고, 더 복잡한 프레임워크를 익히고, 더 많은 언어를 배우는 것이다. 물론 그런 공부도 중요하다.

하지만 나는 또 다른 방향도 있다고 생각한다.

도메인을 이해하는 개발자가 되는 것.

여기서 말하는 도메인 이해는 단순히 용어를 많이 아는 것이 아니다. 제조라면 MES, ERP, BOM, LOT 같은 단어를 외우는 것이 끝이 아니다. 더 중요한 것은 현실의 업무가 어떤 순서로 움직이고, 어떤 데이터가 생기며, 어떤 예외가 발생하고, 어떤 결정이 시스템 안에 남아야 하는지를 이해하는 것이다.

AI가 코드를 더 쉽게 만들어줄수록, 코드를 쓰기 전에 무엇을 만들어야 하는지 정의하는 능력이 더 중요해질 수 있다. 그리고 그 정의는 보통 도메인 이해에서 나온다.

1. 구현의 희소성은 낮아지고 있다

AI 코드 도구의 확산은 이미 큰 흐름이 되었다. Gartner는 2028년까지 기업 소프트웨어 엔지니어의 75%가 AI 코드 어시스턴트를 사용할 것이라고 전망했다. Stack Overflow 2025 Developer Survey에서도 많은 개발자가 AI 도구를 개발 흐름에 사용하고 있지만, 동시에 AI 출력 정확도에 대한 불신도 커지고 있다.

이 두 흐름은 함께 봐야 한다.

첫째, AI는 구현 속도를 올린다. 간단한 CRUD, 테스트 초안, 문서 구조, 반복적인 코드 패턴은 예전보다 훨씬 빠르게 만들 수 있다.

둘째, AI 결과를 그대로 믿기는 어렵다. Stack Overflow 조사에서는 AI 출력 정확도를 신뢰하지 않는 개발자가 신뢰하는 개발자보다 많았다. 즉 AI는 빠른 초안을 만들 수 있지만, 그 초안이 맞는지 판단하는 능력은 여전히 필요하다.

이 지점에서 개발자의 경쟁력은 조금 이동한다. 예전에는 “내가 직접 코드를 얼마나 잘 쓰는가”가 중심이었다면, 앞으로는 “AI가 만든 코드를 어떤 기준으로 판단하는가”가 더 중요해질 수 있다.

그 기준은 어디서 나올까?

기술 기준도 필요하다. 테스트, 타입, 보안, 성능, 유지보수성 같은 기준이다. 하지만 업무형 소프트웨어에서는 도메인 기준도 필요하다. 이 데이터가 실제 업무에서 맞는지, 이 상태 전이가 현실과 맞는지, 이 예외 처리가 현장 흐름을 깨지 않는지 판단해야 한다.

AI가 구현을 도와줄수록, 개발자는 구현자에서 판단자로 조금씩 이동한다.

2. 도메인 이해는 요구사항을 해석하는 힘이다

도메인을 이해한다는 것은 “현업이 말한 요구사항을 그대로 구현한다”는 뜻이 아니다. 오히려 반대에 가깝다. 현업이 말한 문장을 소프트웨어가 다룰 수 있는 구조로 바꾸는 능력이다.

예를 들어 제조 현장에서 이런 요청이 들어왔다고 해보자.

“검사 결과를 관리할 수 있게 해주세요.”

겉으로 보면 입력 폼과 목록 화면을 만들면 될 것 같다. 하지만 도메인을 조금만 생각하면 질문이 늘어난다.

  • 검사 대상은 제품인가, 작업지시인가, LOT인가?
  • 검사는 공정 중에 하는가, 완료 후에 하는가?
  • 검사 기준은 품목별로 다른가?
  • 불합격이면 재검사, 재작업, 폐기 중 어떤 흐름으로 가는가?
  • 결과 수정 권한은 누구에게 있는가?
  • 변경 이력은 어디까지 남겨야 하는가?
  • 나중에 불량 원인을 추적하려면 어떤 데이터가 필요할까?

이 질문을 하지 않으면 기능은 빨리 만들 수 있다. 하지만 실제 업무에는 맞지 않는 시스템이 될 수 있다.

도메인을 이해하는 개발자는 요구사항을 그대로 받는 사람이 아니라, 요구사항 뒤에 숨어 있는 상태, 책임, 데이터, 예외를 꺼내는 사람이다.

AI가 코드를 만들어도 이 질문은 자동으로 생기지 않는다. 누군가 질문을 잘 던져야 한다. 그리고 그 질문을 던지려면 도메인의 흐름을 알아야 한다.

3. 제조 도메인에서는 도메인 이해가 더 중요해진다

제조 도메인은 특히 이 차이가 크게 드러난다. 제조 소프트웨어는 보통 독립적인 화면 하나로 끝나지 않는다. 작업지시, 공정, 설비, 자재, LOT, 품질, 재고, 출하, 이력이 연결된다.

예를 들어 작업지시 하나를 생각해도 단순하지 않다.

  • 어떤 제품을 만들 것인가
  • 어떤 자재가 필요한가
  • 어떤 공정을 거치는가
  • 어떤 설비를 사용하는가
  • 어떤 작업자가 투입되는가
  • 어떤 검사를 통과해야 하는가
  • 중간에 불량이 나면 어떻게 처리되는가
  • 최종적으로 어떤 이력이 남아야 하는가

이런 흐름을 모르면 화면은 만들 수 있어도 시스템은 만들기 어렵다. 데이터베이스 테이블은 만들 수 있어도, 나중에 추적 가능한 구조를 만들기 어렵다. API는 만들 수 있어도, 실제 업무의 상태 변화를 담기 어렵다.

Deloitte의 2025 Smart Manufacturing 조사에서도 제조기업들이 데이터 분석, 클라우드, AI, IIoT 같은 영역에 계속 투자하고 있음을 보여준다. 동시에 IT, OT, 데이터 과학, 애플리케이션 개발, 사이버보안 같은 기술 영역의 인재 확보에 어려움이 있다는 흐름도 나타난다.

이 말은 제조 도메인에서 필요한 사람이 단순히 코드를 쓰는 개발자만은 아니라는 뜻이다. 현장 데이터, 운영 흐름, 시스템 제약, 보안과 품질을 함께 이해할 수 있는 사람이 필요해진다는 뜻이다.

4. 도메인을 이해하는 개발자가 희소해지는 이유

도메인 이해가 중요한 이유는 많지만, 특히 네 가지가 크다고 생각한다.

첫째, 도메인 지식은 단기간에 복사하기 어렵다. 프레임워크 사용법은 문서와 예제로 빠르게 배울 수 있다. 하지만 어떤 현장에서 왜 이런 예외가 생기는지, 왜 이 데이터가 나중에 문제가 되는지, 왜 특정 이력을 꼭 남겨야 하는지는 경험과 관찰이 필요하다.

둘째, 도메인 이해는 여러 팀 사이의 언어를 번역한다. 제조 도메인에서는 개발자만 일하지 않는다. 현장 작업자, 생산 관리자, 품질 담당자, 설비 담당자, 보안 담당자, 경영진이 모두 다른 언어로 같은 문제를 본다. 도메인을 이해하는 개발자는 이 언어들을 소프트웨어 구조로 연결할 수 있다.

셋째, AI가 만든 결과를 검증하는 기준이 된다. AI가 그럴듯한 테이블과 API를 만들어줘도, 그 구조가 실제 업무에 맞는지는 도메인을 아는 사람이 판단해야 한다.

넷째, 디지털 전환의 병목은 기술 자체보다 업무 해석인 경우가 많다. McKinsey는 디지털 제조를 확장하려면 IT/OT 융합, 데이터 분석, 애자일 솔루션 개발 같은 역량이 필요하다고 설명한다. 또 중공업 제조의 디지털 분석 전환에서는 비즈니스 문제를 디지털 전문가가 이해할 수 있게 번역하고, 도메인 지식으로 솔루션을 평가하는 역할을 강조한다.

결국 희소한 것은 “코드를 쓸 줄 아는 사람”이 아니라 “현실의 문제를 소프트웨어가 다룰 수 있는 형태로 바꾸는 사람”일 수 있다.

5. 하지만 도메인 지식만으로는 부족하다

여기서 조심해야 할 점도 있다. 도메인 이해가 중요하다고 해서 개발 기본기가 덜 중요해지는 것은 아니다.

도메인을 잘 알아도 소프트웨어 구조를 만들지 못하면 영향력이 제한된다. 반대로 코드를 잘 써도 도메인을 모르면 현실과 동떨어진 기능을 만들 수 있다.

도메인을 이해하는 개발자가 되려면 두 축이 함께 필요하다.

  • 기술 축: 데이터 모델링, API 설계, 테스트, 보안, 배포, 운영, 장애 대응
  • 도메인 축: 업무 흐름, 상태 변화, 예외 처리, 책임 구분, 이력과 추적성

AI 시대에는 여기에 하나가 더 붙는다.

  • 검증 축: AI가 만든 결과를 기술 기준과 도메인 기준으로 판단하는 능력

이 세 축이 만나야 한다. 도메인 지식만 가지고 “나는 현장을 안다”에 머물면 개발자로서의 차별점이 약하다. 기술만 가지고 “나는 구현할 수 있다”에 머물러도 AI 시대에는 방어력이 약해질 수 있다.

앞으로 더 강한 개발자는 도메인을 이해하고, 그것을 소프트웨어 구조로 만들고, AI가 만든 결과를 검증할 수 있는 사람일 가능성이 크다.

6. 주니어 개발자는 무엇부터 시작하면 좋을까

처음부터 제조 도메인의 모든 것을 알 필요는 없다. 오히려 그렇게 접근하면 너무 넓어서 금방 지친다.

작게 시작하는 편이 좋다.

예를 들어 하나의 업무를 고른다.

  • 작업지시 관리
  • 검사 결과 기록
  • 설비 점검
  • 자재 입출고
  • LOT 추적
  • 불량 처리

그리고 다음 질문을 던진다.

  • 이 업무는 어디서 시작해서 어디서 끝나는가?
  • 중간 상태는 무엇인가?
  • 누가 데이터를 만들고 누가 확인하는가?
  • 정상 흐름과 예외 흐름은 어떻게 다른가?
  • 나중에 추적하려면 어떤 이력이 필요한가?
  • AI가 이 기능을 만들어준다면, 나는 무엇을 검증해야 하는가?

이 질문에 답하다 보면 단순 CRUD가 아니라 업무 시스템이 보이기 시작한다.

주니어 개발자의 목표는 처음부터 도메인 전문가가 되는 것이 아니다. 도메인을 소프트웨어 관점으로 해석하는 습관을 만드는 것이다.

마무리

AI 시대에 구현 능력은 여전히 중요하다. 하지만 구현만으로 차별화하기는 점점 어려워질 수 있다. AI가 더 많은 코드를 더 빠르게 만들수록, 개발자의 가치는 구현 이전과 이후로 이동한다.

구현 이전에는 어떤 문제를 풀지 정의해야 한다. 구현 이후에는 그 결과가 현실 업무에 맞는지 검증해야 한다. 이 두 지점에서 도메인 이해가 중요해진다.

그래서 나는 도메인을 이해하는 개발자의 희소성이 커질 수 있다고 생각한다. 특히 제조 도메인처럼 현실의 흐름, 데이터, 설비, 품질, 이력이 복잡하게 연결된 영역에서는 더 그렇다.

앞으로의 개발자는 AI보다 코드를 빨리 치는 사람이 아니라, AI가 만들 수 있도록 문제를 잘 정의하고, AI가 만든 결과가 현실에 맞는지 판단할 수 있는 사람이 되어야 한다.

Q&A

Q. 도메인 지식이 있으면 코딩 실력이 부족해도 괜찮나요?

아니다. 도메인 지식은 코딩 실력을 대체하지 않는다. 좋은 개발자가 되려면 도메인을 이해하면서도 데이터 모델링, 테스트, 보안, 운영 같은 기본기를 함께 갖춰야 한다.

Q. 주니어가 도메인을 이해하기에는 너무 이르지 않나요?

이르지 않다. 처음부터 전문가가 될 필요는 없다. 업무의 시작과 끝, 상태 변화, 예외, 이력을 보는 습관부터 만들면 된다.

Q. AI가 도메인 지식도 학습하면 개발자의 차별점은 사라지지 않나요?

AI는 공개된 지식을 요약할 수 있지만, 특정 조직의 실제 업무 흐름, 책임 구조, 예외 상황, 암묵지를 완전히 이해하기는 어렵다. 그 맥락을 정리하고 검증하는 역할은 여전히 사람에게 남을 가능성이 크다.

Q. 제조 도메인 말고 다른 도메인에도 적용되나요?

적용된다. 금융, 의료, 물류, 교육, 우주/항공, 공공 시스템처럼 현실 제약과 책임이 큰 영역일수록 도메인 이해의 가치는 커질 수 있다.

Q. 제조 도메인을 공부할 때 가장 먼저 볼 것은 무엇인가요?

기능 목록보다 업무 흐름을 먼저 보는 것이 좋다. 작업지시, 검사, 설비 점검, LOT 추적처럼 작은 업무 하나를 골라 상태와 데이터를 그려보는 것부터 시작하면 된다.

참고 자료