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

주요 독자: 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 추적처럼 작은 업무 하나를 골라 상태와 데이터를 그려보는 것부터 시작하면 된다.

참고 자료

• Gartner, Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028
• Stack Overflow, 2025 Developer Survey: AI
• DORA, State of AI-assisted Software Development 2025
• Deloitte, 2025 Smart Manufacturing and Operations Survey
• McKinsey, How to achieve and sustain the impact of digital manufacturing at scale
• McKinsey, Enabling a digital and analytics transformation in heavy-industry manufacturing
• World Economic Forum, Future of Jobs Report 2025

이 글은 특정 회사의 내부 정책이나 업무 정보를 다루지 않고, 공개 자료와 개인적인 생각을 바탕으로 팀의 AI 사용 방식에 대해 정리한 글이다.

주요 독자: 개인적으로 AI를 쓰는 것은 익숙하지만, 팀에서 AI를 어떻게 써야 할지는 아직 막막한 개발자와 팀 리더.

요약

• 개인이 AI를 쓸 때는 생산성과 학습 속도가 중요하지만, 팀에서 AI를 쓸 때는 품질, 보안, 책임, 공유 방식이 함께 중요해진다.
• AI 거버넌스는 AI 사용을 막기 위한 규칙이 아니라, 팀이 AI를 안전하게 실험하고 반복 가능하게 쓰기 위한 기준이다.
• 작은 팀이라면 처음부터 거창한 체계를 만들기보다 입력 금지 데이터, 허용 도구, 검증 책임, PR 기록 방식, 보안 기준부터 정하면 된다.
• 팀에서 AI 사용을 관리하지 않으면 빠르게 만든 결과물이 리뷰 부담, 보안 위험, 지식 단절, 책임 회피로 돌아올 수 있다.
• 좋은 AI 거버넌스는 “AI를 쓰지 말자”가 아니라 “AI를 써도 팀의 기준이 무너지지 않게 하자”에 가깝다.

들어가며

혼자 AI를 쓸 때는 기준이 단순하다. 내가 막힌 문제를 물어보고, 초안을 만들고, 코드를 생성하고, 설명을 듣고, 결과가 마음에 들지 않으면 다시 물어보면 된다. 잘못된 답이 나오더라도 대부분은 내가 다시 고치면 된다.

하지만 팀에서 AI를 쓰기 시작하면 이야기가 달라진다.

“회사 코드를 AI에 넣어도 될까?”

“AI가 만든 코드를 PR에 올릴 때 따로 표시해야 할까?”

“AI가 만든 테스트를 믿어도 될까?”

“보안이나 개인정보가 섞인 내용을 어디까지 입력해도 될까?”

“결과가 잘못되면 책임은 AI를 쓴 사람에게 있을까, 리뷰어에게 있을까, 팀에게 있을까?”

이 질문들은 프롬프트를 잘 쓰는 문제와 다르다. 팀이 AI를 어떻게 받아들일지, 어떤 기준으로 허용할지, 어떤 방식으로 검증할지의 문제다. 나는 이것이 AI 거버넌스의 출발점이라고 생각한다.

거버넌스라는 말은 조금 딱딱하다. 마치 큰 회사의 컴플라이언스 문서나 법무팀의 승인 절차처럼 느껴질 수 있다. 하지만 개발팀 관점에서 AI 거버넌스는 그렇게 거창한 것부터 시작할 필요가 없다.

팀에서 AI 거버넌스란 간단히 말해 이런 질문에 답하는 것이다.

우리 팀은 AI를 어디까지, 어떤 데이터로, 어떤 책임 아래, 어떤 검증을 거쳐 사용할 것인가?

1. 개인 AI 사용과 팀 AI 사용은 책임의 크기가 다르다

개인이 AI를 쓰는 목적은 대체로 생산성이다. 더 빨리 이해하고, 더 빨리 초안을 만들고, 더 빨리 실험하기 위해 AI를 쓴다. 이때 AI는 개인의 보조 도구에 가깝다.

반면 팀에서 AI를 쓰는 순간 AI 출력은 개인의 메모장 밖으로 나온다. PR에 들어가고, 설계 문서에 들어가고, 고객 기능에 들어가고, 운영 시스템에 들어갈 수 있다. 그때부터 AI 사용은 개인의 선택이 아니라 팀의 결과물이 된다.

그래서 팀에서는 “AI를 썼는가”보다 “AI가 만든 결과를 팀이 어떻게 검증했는가”가 더 중요하다.

예를 들어 개인 프로젝트에서는 AI가 만든 코드를 직접 실행해보고 괜찮으면 넘어갈 수 있다. 하지만 팀의 제품 코드라면 다르다. 테스트가 있는지, 보안 취약점은 없는지, 기존 설계와 맞는지, 운영 중 문제가 생겼을 때 추적 가능한지 확인해야 한다.

개인에게 AI는 속도를 올리는 도구다. 팀에게 AI는 속도와 함께 책임을 재설계하게 만드는 도구다.

2. AI 거버넌스는 통제가 아니라 안전한 실험의 조건이다

AI 거버넌스를 “하지 말아야 할 것들의 목록”으로만 이해하면 팀은 금방 위축된다. 개발자들은 새로운 도구를 써보고 싶은데, 규칙은 막는 것처럼 느껴진다. 그러면 두 가지 문제가 생긴다.

하나는 사람들이 AI를 안 쓰게 되는 것이다. 그러면 팀은 생산성 실험의 기회를 놓친다.

다른 하나는 사람들이 몰래 쓰게 되는 것이다. 이 경우가 더 위험하다. 어떤 도구를 썼는지, 어떤 데이터를 넣었는지, 어떤 결과를 반영했는지 팀이 알 수 없기 때문이다.

좋은 AI 거버넌스는 사용을 막는 장치가 아니라, 안전하게 써도 되는 경계를 알려주는 장치여야 한다.

예를 들어 팀은 이렇게 말할 수 있다.

• 공개 문서와 일반 기술 질문은 외부 AI 도구에 입력할 수 있다.
• 고객 정보, 인증 정보, 비공개 소스코드, 내부 장애 로그는 외부 AI 도구에 입력하지 않는다.
• AI가 만든 코드는 사람이 작성한 코드와 동일하게 테스트와 리뷰를 거친다.
• AI를 활용해 만든 PR은 설명에 사용 범위와 검증 방식을 간단히 남긴다.
• 설계, 보안, 데이터 모델, 권한 로직은 AI 답변을 그대로 반영하지 않고 팀 기준으로 재검토한다.

이 정도만 있어도 팀원은 훨씬 편하게 실험할 수 있다. 무엇을 해도 되는지 알기 때문이다.

3. 작은 팀이 먼저 정해야 할 다섯 가지

처음부터 ISO 표준이나 법 규정을 완벽히 구현하려고 하면 시작하기 어렵다. 작은 팀은 먼저 다섯 가지만 정해도 충분히 의미가 있다.

1. 어떤 데이터를 AI에 넣으면 안 되는가

가장 먼저 정해야 할 것은 입력 금지 데이터다. AI 사용의 위험은 출력보다 입력에서 시작되는 경우가 많다.

팀은 최소한 다음 데이터는 외부 AI 도구에 넣지 않는다고 정할 수 있다.

• 고객 개인정보
• 계정, 토큰, API 키, 인증 정보
• 비공개 소스코드 전체 또는 핵심 로직
• 내부 장애 로그와 운영 데이터
• 계약, 견적, 보안 정책 등 민감한 내부 문서

특히 개발자는 문제를 설명하려다 실제 로그나 코드를 그대로 붙여 넣기 쉽다. 그래서 “알아서 조심하자”보다 “이런 데이터는 넣지 않는다”라고 명시하는 편이 좋다.

2. 어떤 AI 도구를 써도 되는가

팀에서 허용 도구를 정하지 않으면 각자가 편한 도구를 쓰게 된다. 처음에는 자유로워 보이지만, 시간이 지나면 보안과 기록 관리가 어려워진다.

팀은 최소한 다음을 정해야 한다.

• 회사 계정으로 쓸 수 있는 도구는 무엇인가
• 개인 계정 사용을 허용할 것인가
• 외부 SaaS형 AI 도구와 내부 AI 도구를 어떻게 구분할 것인가
• 코드 생성, 문서 작성, 검색, 리뷰 보조에 각각 어떤 도구를 쓸 것인가
• 도구의 데이터 사용 정책을 누가 확인할 것인가

도구 선택은 단순 취향 문제가 아니다. 팀의 코드와 데이터가 어디로 흘러가는지의 문제다.

3. AI가 만든 결과를 누가 검증하는가

AI가 만든 결과는 초안일 뿐이다. 하지만 팀이 바쁠수록 초안이 곧 결과물이 되기 쉽다.

그래서 팀은 검증 책임을 분명히 해야 한다.

• AI가 만든 코드를 PR에 올린 사람은 해당 코드의 동작과 품질을 책임진다.
• 리뷰어는 “AI가 만들었으니 대충 봐도 된다”가 아니라 일반 코드와 같은 기준으로 리뷰한다.
• 테스트, 보안, 성능, 데이터 정합성에 영향을 주는 코드는 더 엄격히 확인한다.
• AI가 만든 설명이나 문서는 사실 관계를 확인한 뒤 공유한다.

중요한 원칙은 간단하다.

AI가 만들었더라도 책임은 팀에 남는다.

4. AI 사용을 어떻게 기록할 것인가

모든 AI 사용을 감시하자는 뜻은 아니다. 하지만 팀 결과물에 영향을 준 AI 사용은 어느 정도 기록되어야 한다.

예를 들어 PR 템플릿에 다음 항목을 넣을 수 있다.

## AI 사용 여부

- 사용 여부:
- 사용 목적:
- 사람이 검증한 내용:

이 기록은 누군가를 감시하기 위한 것이 아니다. 나중에 문제가 생겼을 때 어떤 판단이 있었는지 추적하고, 팀이 어떤 방식의 AI 사용에서 효과를 봤는지 학습하기 위한 것이다.

팀에서 AI 사용이 성숙해진다는 것은 프롬프트가 화려해진다는 뜻이 아니다. AI 사용 경험이 팀의 지식으로 축적된다는 뜻이다.

5. 어떤 영역은 AI 답변을 그대로 믿지 않을 것인가

AI는 많은 일을 빠르게 도와준다. 하지만 모든 영역에서 같은 수준으로 신뢰하면 안 된다.

팀은 AI 출력에 대해 위험도 기반으로 기준을 나눌 필요가 있다.

상대적으로 AI를 편하게 활용할 수 있는 영역은 다음과 같다.

• 초안 작성
• 테스트 케이스 아이디어
• 문서 구조화
• 반복적인 코드 패턴 생성
• 기존 코드 설명
• 학습용 예제 생성

반대로 더 엄격한 검증이 필요한 영역은 다음과 같다.

• 인증과 권한
• 보안 로직
• 개인정보 처리
• 데이터베이스 마이그레이션
• 동시성 처리
• 결제, 정산, 품질, 안전과 관련된 핵심 로직
• 운영 장애 대응 절차

AI를 신뢰하지 말자는 뜻이 아니다. 위험한 영역에서는 AI보다 팀의 검증 체계가 앞에 있어야 한다는 뜻이다.

4. AI 거버넌스가 없으면 생길 수 있는 문제

AI 거버넌스가 없으면 당장에는 속도가 빨라진 것처럼 보일 수 있다. 코드가 빨리 나오고, 문서가 빨리 생기고, PR이 늘어난다. 하지만 시간이 지나면 다른 비용이 나타날 수 있다.

첫째, 리뷰 부담이 늘어난다. AI가 만든 코드는 그럴듯하지만 미묘하게 틀릴 수 있다. 리뷰어는 사람이 작성한 코드보다 더 많은 맥락을 확인해야 할 수도 있다.

둘째, 팀의 지식이 쌓이지 않는다. 각자가 AI와 대화해서 문제를 해결하지만, 그 과정이 팀 문서나 설계 결정으로 남지 않으면 같은 질문이 반복된다.

셋째, 보안 위험이 커진다. 내부 코드, 로그, 고객 데이터가 무심코 외부 도구에 입력될 수 있다.

넷째, 책임이 흐려진다. “AI가 이렇게 알려줬다”는 말이 설명처럼 들리지만, 팀의 의사결정 근거가 될 수는 없다.

다섯째, 속도는 빨라졌는데 제품 방향은 흐려질 수 있다. DORA AI Capabilities Model에서도 사용자 중심이 없는 AI 도입은 팀 성과에 부정적일 수 있다고 설명한다. AI는 방향이 맞을 때 속도를 올려준다. 방향이 틀리면 잘못된 곳으로 더 빨리 간다.

5. James Kwon의 생각

나는 AI 거버넌스를 거창한 규정집으로 시작하면 실패하기 쉽다고 생각한다. 특히 작은 개발팀이나 초기 조직에서는 완벽한 정책보다, 팀원이 매일 판단할 수 있는 짧고 명확한 기준이 먼저 필요하다.

개인이 AI를 쓸 때는 “내가 더 잘할 수 있게 도와주는가”가 중요하다. 하지만 팀에서 AI를 쓸 때는 “우리 팀의 기준을 무너뜨리지 않으면서 더 잘하게 만드는가”가 중요하다.

그래서 팀의 AI 거버넌스는 다음 한 문장으로 시작해도 된다고 생각한다.

AI를 쓰되, 입력 데이터는 보호하고, 출력 결과는 검증하며, 팀 결과물에 반영된 판단은 기록한다.

이 정도 기준만 있어도 팀은 훨씬 안전하게 AI를 실험할 수 있다. 그리고 실험이 쌓이면 그때부터 더 정교한 정책을 만들면 된다.

중요한 것은 AI를 쓰느냐 마느냐가 아니다. AI를 개인의 숨은 도구로 둘 것인지, 팀의 학습과 생산성을 높이는 공유된 역량으로 만들 것인지다.

나는 앞으로 좋은 개발팀의 차이가 AI 도구 보유 여부에서만 나지는 않을 것이라고 본다. 오히려 AI가 만든 속도를 팀의 품질, 지식, 책임 체계로 흡수할 수 있는지가 더 큰 차이가 될 것이다.

Q&A

Q. AI 거버넌스는 큰 회사에만 필요한 것 아닌가요?

아니다. 작은 팀일수록 간단한 기준이 더 필요하다. 입력 금지 데이터, 허용 도구, 검증 책임만 정해도 위험을 많이 줄일 수 있다.

Q. 규칙을 만들면 AI 활용 속도가 느려지지 않나요?

나쁜 규칙은 속도를 늦춘다. 하지만 좋은 규칙은 무엇을 해도 되는지 명확히 해주기 때문에 오히려 실험 속도를 높일 수 있다.

Q. AI가 만든 코드를 PR에 표시해야 하나요?

팀 기준에 따라 다르지만, 중요한 변경이라면 사용 목적과 사람이 검증한 내용을 남기는 편이 좋다. 감시가 아니라 추적성과 학습을 위한 기록이다.

Q. 외부 AI 도구에 회사 코드를 넣어도 되나요?

팀이나 회사의 명확한 허용 기준이 없다면 조심하는 편이 좋다. 특히 비공개 소스코드, 인증 정보, 고객 데이터, 운영 로그는 외부 도구에 넣지 않는 것을 기본값으로 두는 편이 안전하다.

Q. AI 거버넌스를 처음 시작한다면 무엇부터 하면 되나요?

한 페이지짜리 팀 규칙부터 만들면 된다. “넣으면 안 되는 데이터”, “써도 되는 도구”, “PR에 남길 기록”, “반드시 사람이 검증할 영역” 네 가지면 시작할 수 있다.

참고 자료

• NIST, Artificial Intelligence Risk Management Framework
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• ISO, ISO/IEC 42001:2023 AI management systems
• European Commission, Timeline for the Implementation of the EU AI Act
• OWASP, Top 10 for LLMs and Gen AI Apps 2025
• Google Cloud, Introducing the DORA AI Capabilities Model

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

주요 독자: AI와 Vibe 코딩 시대에 “구현만 잘하는 개발자”로는 충분하지 않을까 봐 불안한 주니어 소프트웨어 개발자.

요약

• 순수 소프트웨어가 끝난 것은 아니다. 다만 기능 구현만으로 이기는 순수 소프트웨어는 점점 어려워지고 있다.
• AI 코드 도구가 확산되면서 단순 구현의 희소성은 낮아지고, 무엇을 만들지 결정하는 능력의 중요성은 커지고 있다.
• 얇은 생산성 도구나 B2C SaaS는 구현보다 유통, 브랜드, 자본, 사용자 네트워크의 영향을 더 크게 받을 수 있다.
• 제조 도메인은 현실의 업무 흐름, 설비, 품질, 자재, 이력 데이터가 얽혀 있어 단순 기능 구현만으로 풀기 어렵다.
• 그래서 제조 도메인은 주니어 개발자가 문제 정의, 데이터 모델링, 업무 flow 설계, 시스템 사고를 훈련하기 좋은 영역이 될 수 있다.

들어가며

요즘 주니어 개발자가 느끼는 불안은 예전과 조금 다르다. 예전에는 “내가 코드를 충분히 잘 짤 수 있을까?”가 큰 고민이었다면, 이제는 한 가지 질문이 더 붙는다.

“AI가 코드를 이렇게 빨리 만들어주는데, 나는 무엇으로 차별화해야 하지?”

Vibe 코딩을 해보면 이 불안은 더 커진다. 간단한 CRUD, 랜딩 페이지, 관리자 화면, 작은 생산성 도구는 생각보다 빠르게 만들어진다. 예전 같으면 며칠 걸렸을 기능이 몇 시간 만에 모양을 갖추기도 한다. 그러면 자연스럽게 이런 생각이 든다.

“기능을 구현하는 능력만으로 앞으로도 충분할까?”

“내가 만드는 앱이 다른 사람이 AI로 만든 앱과 무엇이 다를까?”

“결국 마케팅을 잘하거나, 돈이 많거나, 이미 사용자를 가진 사람이 이기는 것 아닐까?”

이 질문은 꽤 현실적이다. 하지만 여기서 결론을 너무 세게 잡으면 위험하다. “순수 소프트웨어는 끝났다”라고 말하면 너무 넓고 거친 주장이다. 여전히 좋은 소프트웨어 회사는 나오고, AI 시대에도 소프트웨어는 계속 중요해질 것이다.

더 단단한 주장은 이것에 가깝다.

순수 소프트웨어는 끝난 것이 아니라, 기능 구현만으로 이기는 순수 소프트웨어가 어려워졌다.

이 차이는 중요하다. 소프트웨어의 가치가 사라졌다는 뜻이 아니다. 오히려 구현 너머의 가치가 더 중요해졌다는 뜻이다. 어떤 문제를 고를지, 어떤 사용자의 흐름을 이해할지, 어떤 데이터를 남길지, 어떤 제약을 시스템 안에 담을지 결정하는 능력이 더 중요해지고 있다.

나는 이 관점에서 제조 도메인을 보고 있다. 제조업은 오래된 산업이지만, 모든 업무가 충분히 디지털화된 것은 아니다. 그리고 제조 도메인의 소프트웨어는 단순히 화면과 버튼을 만드는 것보다, 현실의 업무 flow를 이해하고 데이터로 연결하는 일이 중요하다.

1. 구현 장벽은 낮아지고 있다

AI 코드 도구는 이미 개발자의 일하는 방식을 바꾸고 있다. Gartner는 2028년까지 기업 소프트웨어 엔지니어의 75%가 AI 코드 어시스턴트를 사용할 것이라고 전망했다. 2023년 초 10% 미만이던 수치와 비교하면 큰 변화다.

이 변화가 의미하는 것은 “개발자가 필요 없어졌다”가 아니다. 더 정확히는, 단순 구현 자체의 희소성이 낮아지고 있다는 뜻이다.

예전에는 작은 웹 앱을 끝까지 만드는 것만으로도 꽤 강한 신호가 될 수 있었다. 로그인, 게시판, 검색, 관리자 페이지, 배포까지 혼자 해내면 “이 사람은 만들 수 있구나”라는 증명이 됐다. 하지만 이제는 그 증명의 강도가 약해지고 있다. AI를 활용하면 비슷한 형태의 앱을 더 많은 사람이 더 빠르게 만들 수 있기 때문이다.

주니어 개발자에게 이것은 부담이지만, 동시에 방향을 바꿀 신호이기도 하다. 앞으로는 “기능을 만들 수 있다”에서 멈추기보다, “왜 이 기능이 필요하고, 어떤 업무 흐름을 바꾸며, 어떤 데이터 구조가 오래 버틸 수 있는가”까지 설명할 수 있어야 한다.

2. 얇은 소프트웨어는 유통과 네트워크의 영향을 더 크게 받는다

AI 시대에 특히 어려워질 수 있는 영역은 기능이 얇은 소프트웨어다. 예를 들어 개인 생산성 도구, 작은 자동화 앱, 단일 목적의 B2C SaaS는 아이디어가 좋아도 금방 비슷한 대안이 나올 수 있다.

이런 시장에서는 기능 구현보다 다음 요소가 더 중요해질 수 있다.

• 사용자를 먼저 모을 수 있는 유통 채널
• 계속 떠올릴 수 있는 브랜드와 신뢰
• 빠르게 실험할 수 있는 자본과 팀
• 사용자들이 서로 연결되어 떠나기 어려운 네트워크 효과
• 제품 안에 쌓이는 데이터와 개인화 경험

그래서 Slack처럼 사용자 간 interaction이 강한 서비스, GitHub처럼 생태계와 네트워크가 있는 서비스, Notion처럼 콘텐츠와 협업 흐름이 쌓이는 서비스는 단순 기능 복제만으로 대체하기 어렵다. 반대로 “혼자 쓰는 작은 기능”에 가까운 도구는 사용자가 직접 만들거나, AI가 생성한 여러 대안 중 하나로 빠르게 대체될 가능성이 있다.

물론 이것도 모든 B2C SaaS가 망한다는 뜻은 아니다. 사용자의 습관을 잘 잡거나, 특정 집단의 문제를 깊게 해결하거나, 데이터와 커뮤니티가 쌓이는 제품은 여전히 강해질 수 있다. 다만 기능 구현만으로 방어되는 영역은 줄어들 가능성이 크다.

3. 제조 도메인은 기능보다 flow가 먼저다

제조 도메인이 흥미로운 이유는 여기서 나온다. 제조 소프트웨어는 보통 “기능 하나”만으로 설명되지 않는다. 작업지시, 공정, 설비, 자재, LOT, 품질 검사, 불량, 재작업, 출하, 이력 추적이 서로 연결된다.

예를 들어 검사 기록 기능을 만든다고 해보자. 겉으로 보면 입력 폼과 목록 화면이면 충분해 보인다. 하지만 실제로는 질문이 훨씬 많다.

• 검사 대상은 제품인가, 작업지시인가, LOT인가?
• 검사 기준은 품목마다 다른가, 공정마다 다른가?
• 불합격이면 재검사, 재작업, 폐기 중 어떤 흐름으로 가는가?
• 누가 검사 결과를 수정할 수 있는가?
• 수정 이력은 어디까지 남겨야 하는가?
• 나중에 불량 원인을 추적하려면 어떤 관계를 저장해야 하는가?

이 질문들은 단순한 UI 구현 문제가 아니다. 업무 flow, 데이터 모델링, 권한, 이력, 예외 처리의 문제다. AI가 코드를 빠르게 만들어줘도, 이런 질문에 답하지 못하면 시스템은 오래 버티기 어렵다.

제조 도메인에서 개발자는 “화면을 만드는 사람”을 넘어 “현실의 흐름을 소프트웨어 구조로 바꾸는 사람”에 가까워진다. 그리고 이 지점이 주니어 개발자에게 중요한 훈련장이 될 수 있다.

4. 제조업에는 아직 디지털 전환의 여지가 남아 있다

제조업은 오래된 산업이지만, 디지털 전환이 모두 끝난 산업은 아니다. 국내 기준으로도 중소벤처기업부와 스마트제조혁신추진단이 발표한 2024년 스마트제조혁신 실태조사에 따르면, 공장 보유 중소·중견 제조기업 중 스마트공장을 도입한 기업은 19.5%다. 도입 기업 중에서도 75.5%는 기초 단계에 머물러 있고, 제조AI 도입률은 0.1% 수준으로 발표되었다.

해외 선도 제조기업도 완전히 끝난 상태라기보다 계속 기반을 만드는 중이다. Deloitte의 2025 Smart Manufacturing 조사에서는 향후 24개월 투자 우선순위로 데이터 분석, 클라우드, AI, IIoT가 언급된다. AI/ML과 생성형 AI 역시 시설 또는 네트워크 수준의 도입이 진행 중이지만, 동시에 파일럿과 실험도 계속되고 있다.

이 숫자들을 보면 제조업의 디지털 전환은 이미 끝난 이야기가 아니라는 것을 알 수 있다. 특히 소프트웨어 개발자 관점에서는 아직 연결되지 않은 데이터, 시스템화되지 않은 업무, 사람이 기억으로 처리하는 예외, 엑셀에 갇힌 flow가 많이 남아 있다는 뜻이다.

이런 환경은 편하지 않다. 요구사항이 깔끔하지 않고, 현장마다 용어가 다르고, 예외도 많다. 하지만 바로 그 점 때문에 개발자가 배울 수 있는 것이 많다.

5. 주니어 개발자는 무엇을 차별화해야 할까

AI 시대에 주니어 개발자가 제조 도메인을 공부한다면, 목표를 “제조 지식을 모두 외우기”로 잡을 필요는 없다. 처음부터 MES, ERP, QMS, WMS, SCADA를 전부 깊게 알 필요도 없다.

대신 다음 능력을 조금씩 키우는 것이 좋다.

• 업무의 시작, 중간 상태, 종료 조건을 그리는 능력
• 화면보다 먼저 데이터의 관계를 생각하는 능력
• 정상 flow와 예외 flow를 나누어 보는 능력
• 이력과 추적성이 왜 필요한지 이해하는 능력
• 현장 사용자와 관리자 사용자의 관점 차이를 구분하는 능력
• AI가 만든 코드를 도메인 규칙에 맞게 검증하는 능력

결국 차별화의 방향은 “AI보다 코드를 더 빨리 치는 사람”이 아니다. 그것은 오래 버티기 어렵다. 더 나은 방향은 “AI가 구현할 수 있도록 문제를 잘 정의하고, AI가 만든 결과가 현실의 업무에 맞는지 판단할 수 있는 사람”이다.

제조 도메인은 이 능력을 훈련하기 좋다. 현실의 제약이 분명하고, 데이터의 의미가 업무 결과와 연결되며, 잘못된 설계가 현장의 혼란으로 돌아오기 때문이다.

마무리

“순수 소프트웨어는 끝났다”는 말은 너무 빠른 결론이다. 소프트웨어는 여전히 중요하고, 앞으로도 더 많은 산업의 내부로 들어갈 것이다. 다만 기능 구현만으로 이기는 소프트웨어는 점점 어려워질 가능성이 크다.

AI가 구현의 속도를 올릴수록, 개발자의 차별점은 구현 이전과 이후에 생긴다. 어떤 문제를 고를 것인가. 어떤 flow를 시스템화할 것인가. 어떤 데이터를 남길 것인가. 어떤 예외를 설계에 포함할 것인가. 어떤 의사결정을 돕는 소프트웨어를 만들 것인가.

제조 도메인은 이 질문들이 살아 있는 영역이다. 그래서 제조 소프트웨어는 주니어 개발자에게 단순히 “취업할 수 있는 분야 하나”가 아니라, 구현 너머의 개발자로 성장하기 위한 좋은 훈련장이 될 수 있다.

Q&A

Q. 순수 소프트웨어는 정말 끝난 건가요?

아니다. 끝난 것은 순수 소프트웨어가 아니라, 기능 구현만으로 오래 방어되는 제품이 줄어드는 흐름에 가깝다.

Q. AI가 코드를 잘 만들면 주니어 개발자는 무엇을 해야 하나요?

문제 정의, 데이터 모델링, 업무 flow 이해, 예외 처리, 결과 검증 능력을 키워야 한다. AI가 코드를 만들수록 무엇을 만들지 결정하는 능력이 더 중요해진다.

Q. 제조 도메인은 왜 차별화에 도움이 되나요?

제조 도메인은 현실의 업무, 설비, 자재, 품질, 이력이 얽혀 있다. 단순 CRUD보다 flow와 데이터 관계를 이해해야 하므로 설계 감각을 기르기 좋다.

Q. 제조업을 잘 모르는데 시작해도 될까요?

시작해도 된다. 처음부터 모든 공정과 장비를 알 필요는 없다. 작업지시, 검사 기록, 설비 점검, LOT 추적처럼 작은 업무 하나를 골라 flow와 데이터를 그려보는 것부터 시작하면 된다.

Q. 주니어 포트폴리오로는 무엇을 만들면 좋을까요?

기능이 많은 앱보다 업무 흐름이 보이는 작은 제조 앱이 좋다. 예를 들어 검사 기록 앱, 설비 점검 앱, 작업지시 관리 앱처럼 상태, 이력, 권한, 예외가 드러나는 주제가 좋다.

참고 자료

• Gartner, Gartner Says 75% of Enterprise Software Engineers Will Use AI Code Assistants by 2028
• Andreessen Horowitz, In Consumer AI, Momentum Is the Moat
• 대한민국 정책브리핑, 2024년 스마트제조혁신실태조사 결과 발표
• Deloitte, 2025 Smart Manufacturing and Operations Survey

이 글은 정답을 말하기 위한 글이라기보다, AI로 무언가를 만드는 사람들을 보며 떠오른 질문을 정리한 글이다.

요약

• 사람들은 AI로 단순히 결과물만 만들고 있는 것이 아닐 수 있다.
• 돈을 벌고 싶어서, 자기효용감을 느끼고 싶어서, 혹은 만드는 행위 자체가 재미있어서 AI를 사용할 수 있다.
• AI로 무언가를 만드는 감각은 처음 프로그래밍을 배울 때 느꼈던 “내가 뭔가를 만들었다”는 기쁨과 닮아 있을 수 있다.
• 어쩌면 AI 시대의 창작 욕구를 이해하려면 기술보다 먼저 사람의 재미와 욕망을 봐야 한다.

들어가며

요즘 사람들은 AI로 정말 많은 것을 만든다. 글을 쓰고, 이미지를 만들고, 영상을 만들고, 앱을 만들고, 자동화 도구를 만들고, 자기만의 작은 서비스를 만든다. 타임라인을 보다 보면 이런 생각이 든다.

“사람들은 AI로 무엇을 그렇게 만들고 있을까?”

조금 더 정확히 말하면, 궁금한 것은 결과물만이 아니다. 무엇을 만드는지도 궁금하지만, 왜 만드는지가 더 궁금하다.

무엇을, 왜 만들고 있을까

어떤 사람은 돈을 벌고 싶어서 AI를 쓸 것이다. 더 빠르게 콘텐츠를 만들고, 더 적은 비용으로 서비스를 만들고, 더 많은 일을 혼자 처리하고 싶어서 AI를 사용할 수 있다. 나 역시 그런 마음을 이해한다. 나도 영향력과 수익을 만들고 싶다는 생각을 하고 있으니까.

어떤 사람은 자기효용감을 느끼고 싶어서 AI를 쓸 수도 있다. 예전에는 엄두가 나지 않았던 일을 AI와 함께 해보면서 “나도 할 수 있네”라는 감각을 얻는다. 코드, 디자인, 글쓰기, 영상 같은 영역에서 진입장벽이 낮아지면 사람은 생각보다 빠르게 용기를 얻는다.

그리고 어떤 사람은 그냥 재미있어서 만들지도 모른다. 꼭 돈이 되지 않아도, 꼭 누가 봐주지 않아도, 머릿속에 있던 무언가가 화면 위에 나타나는 경험 자체가 즐거울 수 있다.

처음 프로그래밍이 재미있었던 이유

생각해보면 내가 처음 프로그래밍에 재미를 느꼈던 것도 비슷했다. 코드 몇 줄을 썼는데 화면에 무언가가 생기고, 버튼을 누르면 동작하고, 데이터를 넣으면 결과가 바뀌었다. 그때의 재미는 대단한 서비스를 만들었다는 성취감보다, “내가 쓴 것이 실제로 움직인다”는 감각에 가까웠다.

AI로 무언가를 만드는 사람들도 어쩌면 비슷한 감각을 느끼고 있는 것 아닐까.

자연어로 설명했는데 이미지가 나오고, 아이디어를 말했는데 앱의 초안이 생기고, 막연한 생각이 글의 구조로 바뀐다. 이 과정에서 사람은 단순히 결과물을 얻는 것이 아니라, 자기 생각이 현실에 가까워지는 경험을 한다.

처음 프로그래밍을 배울 때 느꼈던 “만드는 재미”가, 이제는 더 많은 사람에게 다른 형태로 열리고 있는 것일지도 모른다.

AI 시대의 재미는 어디에 있을까

AI를 도구로만 보면 효율이 먼저 보인다. 얼마나 빨리 만들 수 있는지, 얼마나 비용을 줄일 수 있는지, 얼마나 많은 일을 자동화할 수 있는지가 보인다. 물론 그것도 중요하다.

하지만 사람을 보면 다른 질문이 생긴다. 사람은 왜 굳이 무언가를 만들고 싶어할까. 왜 이미 많은 콘텐츠와 서비스가 있는데도 자기만의 것을 만들고 싶어할까. 왜 서툰 결과물이라도 직접 만들어보면 기분이 좋아질까.

아마 그 안에는 자기효용감이 있다. 내가 할 수 있다는 감각. 내 생각이 바깥으로 나왔다는 감각. 소비자에 머무르지 않고 만드는 사람이 되었다는 감각.

AI는 그 감각을 더 쉽게 만들어주는 도구일 수 있다.

마무리

사람들이 AI로 무엇을 만들고 있는지보다 더 궁금한 것은, 사람들이 AI로 무언가를 만들며 무엇을 느끼고 있는가이다.

돈을 벌고 싶은 마음도 있을 것이다. 인정받고 싶은 마음도 있을 것이다. 하지만 그보다 더 근본에는 “내가 생각한 것을 실제로 만들어보고 싶다”는 오래된 욕구가 있을지도 모른다.

처음 프로그래밍을 배울 때 내가 느꼈던 재미가 바로 그런 것이었다. AI로 무언가를 만드는 사람들도 지금 그 재미를 느끼고 있는 것이라면, 이 흐름은 단순한 생산성 도구의 유행보다 조금 더 깊은 변화일 수 있다.

Q&A

Q. 사람들은 AI로 무엇을 만들고 있나요?

글, 이미지, 영상, 앱, 자동화 도구, 작은 서비스처럼 다양하다. 하지만 중요한 것은 결과물보다 사람들이 만들면서 느끼는 감각일 수 있다.

Q. AI로 만드는 이유는 돈 때문일까요?

돈도 중요한 이유일 수 있다. 하지만 자기효용감, 재미, 표현 욕구, 실험 욕구도 함께 작동한다고 본다.

Q. AI로 만드는 재미는 프로그래밍의 재미와 닮았나요?

닮은 부분이 있다. 머릿속 생각이 실제 결과물로 바뀌는 감각은 처음 프로그래밍을 배울 때 느끼는 기쁨과 비슷할 수 있다.

Q. 이 흐름에서 개발자는 무엇을 봐야 할까요?

AI가 코드를 대신 만든다는 사실만 볼 것이 아니라, 더 많은 사람이 만드는 사람이 되고 싶어한다는 변화를 봐야 한다.

이 글은 특정 회사의 업무나 내부 정보를 다루지 않고, 제조 도메인 소프트웨어를 처음 공부하는 주니어 개발자를 위해 작성한다.

주요 독자: 제조 도메인에 관심은 생겼지만, 무엇부터 공부해야 할지 막막한 주니어 소프트웨어 개발자.

요약

• 제조 도메인도 결국 요구사항, 상태, 데이터, 예외, 사용자 흐름을 다룬다는 점에서 소프트웨어 개발과 닮아 있다.
• 다만 제조 소프트웨어는 화면 안에서 끝나지 않고 자재, 설비, 작업자, 검사, 이력처럼 현실의 흐름과 연결된다는 점이 다르다.
• 제조 분야마다 차이는 있지만, 생산, 품질, 자재, 설비, 이력이라는 공통 축이 반복된다.
• 주니어 개발자는 용어 암기보다 “소프트웨어의 흐름이 실제 제조 flow와 어떻게 연결되는가”를 먼저 보는 것이 좋다.

들어가며

제조 도메인에 관심이 생긴 주니어 개발자는 보통 여기서 한 번 막힌다. “제조업을 공부해야겠다”는 생각은 들지만, 막상 어디서부터 봐야 할지 잘 모르겠다. MES, ERP, BOM, LOT, 공정, 작업지시, 설비, 품질, 재고 같은 단어가 한꺼번에 나오면 시작하기 전부터 부담스럽다.

제조업은 하나의 모습만 가지고 있지 않다. 자동차 부품을 만드는 회사와 식품을 만드는 회사는 다르고, 반도체 공정과 의류 생산은 다르다. 대량 생산을 하는 곳과 주문을 받아 소량으로 만드는 곳도 다르다. 그러면 자연스럽게 이런 질문이 생긴다.

“제조 도메인이라고 묶어도 되는 걸까?”

“분야마다 이렇게 다르면 무엇부터 공부해야 하지?”

“소프트웨어 개발자는 공장 전체를 다 알아야 하나?”

이 질문은 꽤 현실적이다. 제조업은 넓고, 현장마다 용어와 방식이 다르다. 하지만 처음부터 모든 차이를 다 이해하려고 하면 오히려 길을 잃기 쉽다. 주니어 개발자에게 더 좋은 접근은 소프트웨어 개발과 제조 도메인의 공통점을 먼저 잡고, 그다음 제조업 안에서 반복되는 공통 흐름과 분야별 차이를 얹어가는 것이다.

제조 도메인 공부의 첫 목표는 전문가처럼 모든 공정을 아는 것이 아니다. 소프트웨어 개발자답게 “업무가 어떤 순서로 흐르고, 그 과정에서 어떤 데이터가 생기며, 시스템은 무엇을 기록하고 도와야 하는가”를 보는 눈을 기르는 것이다.

소프트웨어 개발 관점으로 제조 도메인 보기

제조업을 완전히 새로운 세계로 보기보다, 먼저 내가 아는 소프트웨어 개발과 비교해보면 부담이 줄어든다. 소프트웨어 개발에서는 요구사항을 이해하고, 사용자를 정의하고, 데이터를 저장하고, 상태를 관리하고, 예외 상황을 처리한다. 제조 도메인 소프트웨어도 이 점에서는 크게 다르지 않다.

예를 들어 일반적인 웹 서비스에서 주문 상태를 관리한다고 해보자. 주문 생성, 결제 대기, 결제 완료, 배송 준비, 배송 중, 배송 완료처럼 상태가 바뀐다. 제조 앱에서도 비슷한 일이 일어난다. 작업지시가 생성되고, 자재가 준비되고, 작업이 시작되고, 검사를 거치고, 입고되거나 재작업으로 돌아간다. 결국 둘 다 “어떤 대상이 어떤 상태를 거쳐 이동하는가”를 다룬다.

하지만 차이도 분명하다. 일반적인 웹 서비스의 상태 변화는 대부분 화면과 데이터베이스 안에서 끝난다. 반면 제조 소프트웨어의 상태 변화는 실제 현장의 작업, 자재, 설비, 검사, 품질, 재고와 연결된다. 버튼 하나를 누르는 일이 단순한 UI 이벤트가 아니라, 실제 작업 완료, 검사 판정, 자재 사용, 이력 기록을 의미할 수 있다.

이렇게 매칭해보면 제조 도메인이 완전히 낯선 세계처럼만 보이지 않는다. 익숙한 소프트웨어 개발 개념이 현실의 생산 흐름과 연결되면서 더 구체적인 제약을 갖게 되는 것이다.

1. 먼저 제조업의 공통 흐름을 잡기

제조 분야는 다양하지만, 많은 제조 현장에는 비슷하게 반복되는 큰 흐름이 있다.

주문 또는 계획
→ 자재 준비
→ 작업지시
→ 생산 또는 공정 진행
→ 검사
→ 입고 또는 출하
→ 이력 추적과 개선

이 흐름은 산업마다 모양이 달라질 수 있다. 하지만 소프트웨어 관점에서는 중요한 질문이 비슷하게 반복된다.

• 무엇을 만들기로 했는가?
• 만들기 위해 어떤 자재가 필요한가?
• 누가, 언제, 어떤 설비나 공정에서 작업하는가?
• 작업이 지금 어떤 상태인가?
• 검사 결과는 어떤가?
• 불량이 발생하면 어떻게 처리하는가?
• 나중에 문제가 생겼을 때 어디까지 추적할 수 있는가?

처음에는 이 질문들을 기준으로 제조 도메인을 보는 것이 좋다. 용어를 많이 외우는 것보다, 일이 흐르는 방향을 먼저 잡는 편이 훨씬 오래 간다.

2. 제조 도메인에서 자주 반복되는 공통 개념

제조 분야마다 세부 용어는 다르지만, 소프트웨어 개발자가 자주 만나는 개념은 어느 정도 공통적이다.

작업지시

작업지시는 “무엇을, 얼마나, 언제까지, 어떤 방식으로 만들 것인가”를 현장에 전달하는 단위다. 소프트웨어에서는 작업지시가 생산 흐름의 출발점이 되는 경우가 많다.

개발자는 작업지시를 단순한 게시글처럼 보면 안 된다. 작업지시에는 제품, 수량, 납기, 공정, 자재, 상태, 담당자, 우선순위 같은 정보가 연결될 수 있다.

공정

공정은 제품이 만들어지는 단계다. 어떤 제품은 조립, 검사, 포장처럼 비교적 이해하기 쉬운 단계를 거치고, 어떤 제품은 온도, 압력, 시간, 배합 같은 조건이 중요한 공정을 거친다.

공정을 이해하면 화면 설계와 데이터 모델링이 달라진다. 단순히 “완료” 버튼 하나로 끝나는 업무인지, 중간 상태와 조건을 계속 기록해야 하는 업무인지가 달라지기 때문이다.

자재와 BOM

제조는 무언가를 만들기 위해 자재를 사용한다. BOM은 제품을 만들기 위해 필요한 자재 목록과 구조를 의미한다.

소프트웨어 관점에서는 “이 제품을 만들려면 무엇이 필요한가”, “대체 자재가 가능한가”, “자재가 부족하면 작업을 시작할 수 있는가” 같은 질문으로 이어진다.

품질과 검사

제조에서 검사는 단순히 통과/실패만 기록하는 일이 아닐 수 있다. 검사 항목, 기준값, 측정값, 검사자, 검사 시간, 불량 유형, 재검사 여부가 필요할 수 있다.

주니어 개발자가 제조 앱을 공부할 때 품질 데이터를 보면 좋은 이유는, 이력과 예외 처리를 자연스럽게 배우기 좋기 때문이다.

LOT와 이력

LOT는 같은 조건이나 묶음으로 생산되거나 관리되는 단위다. 제조 도메인에서 LOT는 추적성과 연결된다.

어떤 자재가 어떤 작업지시에 쓰였고, 어떤 공정을 거쳤고, 어떤 검사 결과가 나왔는지 추적할 수 있어야 문제가 생겼을 때 원인을 좁힐 수 있다. 제조 소프트웨어에서 이력 관리가 중요한 이유가 여기에 있다.

3. 분야별로 달라지는 것 보기

공통 흐름을 잡은 뒤에는 분야별 차이를 보면 된다. 처음부터 모든 차이를 외울 필요는 없다. 대신 어떤 기준으로 달라지는지 보면 이해가 빨라진다.

조립 제조와 공정 제조

조립 제조는 여러 부품을 조립해서 제품을 만드는 방식에 가깝다. 전자제품, 기계 부품, 자동차 부품 같은 분야를 떠올리면 쉽다. 이 경우 부품 구성, 조립 순서, 작업자, 검사, Serial 추적이 중요해질 수 있다.

공정 제조는 재료를 배합하거나 가공해서 제품을 만드는 방식에 가깝다. 식품, 화학, 배터리 소재 같은 분야를 떠올릴 수 있다. 이 경우 배합비, 온도, 시간, 설비 조건, LOT 추적이 중요해질 수 있다.

둘 다 제조지만 소프트웨어가 기록해야 하는 데이터의 모양이 달라진다.

대량 생산과 주문 생산

대량 생산은 같은 제품을 반복적으로 많이 만드는 흐름에 가깝다. 이 경우 생산 계획, 설비 가동률, 불량률, 재고 정확도가 중요해질 수 있다.

주문 생산은 고객 주문에 맞춰 제품이나 사양이 달라지는 흐름에 가깝다. 이 경우 주문별 사양, 납기, 변경 이력, 작업 우선순위가 중요해질 수 있다.

개발자는 “제조업은 원래 이렇게 한다”라고 단정하기보다, 이 회사가 어떤 생산 방식을 가지고 있는지 먼저 봐야 한다.

사람 중심 흐름과 설비 중심 흐름

어떤 제조 현장은 작업자의 입력과 판단이 중요하고, 어떤 현장은 설비와 센서 데이터가 더 중요하다.

사람 중심 흐름에서는 입력 화면, 실수 방지, 권한, 작업 순서 안내가 중요해진다. 설비 중심 흐름에서는 상태 수집, 알람, 시계열 데이터, 모니터링이 중요해진다.

같은 “생산 관리 시스템”이라고 해도, 현장에서 누가 주로 쓰는지에 따라 UI와 데이터 구조가 달라질 수 있다.

4. Flow 차원에서 제조 앱 바라보기

제조 도메인을 공부할 때 가장 도움이 되는 습관은 기능 목록보다 흐름을 먼저 그리는 것이다.

예를 들어 “검사 결과 등록 기능”을 만든다고 해보자. 기능만 보면 입력 폼 하나처럼 보인다. 하지만 flow로 보면 질문이 늘어난다.

• 검사는 언제 발생하는가?
• 검사 대상은 작업지시인가, 제품인가, LOT인가, Serial인가?
• 검사 기준은 어디에서 오는가?
• 검사 결과가 불합격이면 다음 상태는 무엇인가?
• 재검사나 재작업이 가능한가?
• 누가 결과를 수정할 수 있는가?
• 변경 이력은 남아야 하는가?

이렇게 보면 제조 앱은 단순 CRUD가 아니라 상태와 흐름을 다루는 앱이라는 점이 보인다. 주니어 개발자가 제조 도메인을 공부할 때는 기능명보다 상태 변화를 먼저 보는 연습이 중요하다.

대기
→ 작업 중
→ 검사 대기
→ 검사 완료
→ 입고 또는 재작업

이런 간단한 상태 흐름만 그려도 어떤 테이블이 필요할지, 어떤 권한이 필요할지, 어떤 예외가 생길지 조금씩 보이기 시작한다.

5. 주니어 개발자가 처음 해볼 공부 순서

처음부터 MES, ERP, SCADA, QMS를 모두 공부하려고 하면 너무 넓다. 대신 작은 순서로 시작하는 편이 좋다.

1. 제조업의 큰 흐름을 그린다.
2. 작업지시, 공정, BOM, LOT, 검사, 불량, 설비, 재고 같은 기본 용어를 정리한다.
3. 작은 업무 하나를 고른다. 예를 들어 검사 기록, 설비 점검, 작업지시 관리 중 하나만 고른다.
4. 그 업무의 상태 흐름을 그린다.
5. 필요한 데이터를 ERD로 그린다.
6. 마지막으로 화면과 API를 생각한다.

이 순서가 중요한 이유는 제조 앱에서는 화면보다 업무 흐름과 데이터가 먼저인 경우가 많기 때문이다. 화면을 먼저 만들면 그럴듯해 보일 수는 있지만, 상태와 이력이 빠지면 실제 업무를 담기 어렵다.

6. 작은 포트폴리오 주제 예시

제조 도메인에 관심이 생긴 주니어 개발자라면 처음 포트폴리오는 작게 잡는 것이 좋다.

검사 기록 앱

검사 대상, 검사 항목, 기준값, 측정값, 판정, 불량 유형, 검사자를 기록한다. 품질과 이력의 기본을 배우기 좋다.

설비 점검 앱

설비, 점검 항목, 점검 주기, 담당자, 이상 보고, 조치 이력을 관리한다. 현장 업무형 UI와 상태 관리를 배우기 좋다.

작업지시 관리 앱

작업지시, 제품, 수량, 공정, 상태, 작업자, 완료 시간을 관리한다. 제조 flow의 기본 구조를 이해하기 좋다.

처음부터 모든 기능을 넣을 필요는 없다. 오히려 하나의 흐름을 제대로 설명하는 포트폴리오가 더 좋다. “무엇을 만들었는가”보다 “왜 이렇게 설계했는가”를 보여줄 수 있어야 한다.

마무리

제조 도메인은 처음 보면 넓고 복잡해 보인다. 실제로도 넓고 복잡하다. 하지만 주니어 개발자가 처음부터 모든 제조 분야를 알아야 하는 것은 아니다.

먼저 공통 흐름을 잡고, 그다음 분야별 차이를 보고, 마지막으로 flow와 데이터를 기준으로 작은 앱을 설계해보면 된다.

Vibe 코딩 시대에는 코드를 빠르게 만드는 능력만으로 차별화하기가 어려워질 수 있다. 그래서 더 중요한 것은 문제를 이해하고, 흐름을 그리고, 데이터를 남기고, 시스템의 상태를 설계하는 능력일 수 있다. 제조 도메인은 그 능력을 연습하기에 좋은 출발점이 될 수 있다.

Q&A

Q. 제조 도메인을 공부하려면 공학 지식이 꼭 필요한가요?

처음부터 깊은 공학 지식이 필요하지는 않다. 주니어 개발자는 먼저 업무 흐름, 데이터, 상태, 이력 관점에서 접근하는 것이 좋다.

Q. 제조 분야마다 너무 다른데 공통으로 공부할 수 있는 게 있나요?

있다. 작업지시, 공정, 자재, 검사, 불량, 설비, 재고, 이력은 많은 제조 분야에서 반복해서 등장한다. 먼저 이 공통 축을 잡고, 그다음 분야별 차이를 보면 된다.

Q. 처음 포트폴리오는 어떤 주제가 좋나요?

검사 기록 앱, 설비 점검 앱, 작업지시 관리 앱처럼 작은 업무 하나를 추천한다. 핵심은 기능을 많이 넣는 것이 아니라 업무 흐름과 데이터 설계 이유를 설명하는 것이다.

Q. 제조 도메인 공부에서 가장 먼저 익혀야 할 습관은 무엇인가요?

기능 목록보다 flow를 먼저 그리는 습관이다. 어떤 상태에서 시작해 어떤 상태로 끝나는지, 예외가 생기면 어디로 흐르는지 보는 연습이 중요하다.

Q. 이 공부가 Vibe 코딩 시대의 차별화와 어떻게 연결되나요?

AI가 코드를 생성해도 업무의 의미, 데이터의 관계, 상태 변화, 예외 처리는 사람이 이해해야 한다. 제조 도메인은 이런 판단을 훈련하기 좋은 분야다.

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

주요 독자: Vibe 코딩으로 구현 장벽이 낮아진 시대에, 무엇으로 차별화해야 할지 고민하는 주니어 소프트웨어 개발자.

요약

• Vibe 코딩은 구현의 진입장벽을 낮추지만, 어떤 문제를 풀어야 하는지 판단하는 능력까지 대신해주지는 않는다.
• 주니어 개발자의 차별점은 더 빨리 코드를 치는 능력보다 도메인, 데이터, 업무 흐름, 설계 결정을 이해하는 능력에서 나올 수 있다.
• 제조 도메인은 현실의 업무와 데이터를 다루기 때문에 “왜 이렇게 설계해야 하는가”를 훈련하기 좋은 분야다.
• 이 글은 제조 도메인 소프트웨어 개발의 가능성을 소개하고, 이후 시리즈에서 공부 시작점, 디지털 전환, 도메인 진입장벽, 현실 지표를 나누어 다룬다.

들어가며

요즘 주니어 개발자가 느끼는 불안은 예전과 조금 다르다. 예전에는 “내가 이 기능을 만들 수 있을까?”가 큰 고민이었다면, 이제는 “이 기능을 AI도 만들 수 있는데, 나는 무엇으로 차별화할 수 있을까?”라는 질문이 더 크게 다가온다.

Vibe 코딩은 이 감각을 더 강하게 만든다. 자연어로 요구사항을 설명하면 화면이 만들어지고, API가 생기고, 데이터베이스 코드까지 어느 정도 생성된다. 예전에는 며칠 걸리던 토이 프로젝트가 훨씬 빨리 나온다. 로그인, 게시판, 채팅, 관리자 페이지, 대시보드 같은 기능도 이제는 혼자서 처음부터 끝까지 다 외워서 만들지 않아도 된다.

이건 좋은 변화다. 구현을 시작하는 비용이 낮아졌고, 주니어도 더 빠르게 아이디어를 실험할 수 있게 되었다. 하지만 동시에 새로운 막막함도 생긴다. “프레임워크 사용법을 아는 것만으로 충분할까?” “CRUD를 빠르게 만드는 능력이 계속 내 경쟁력이 될까?” “AI가 코드를 만들어준다면, 개발자는 어디에서 가치를 만들어야 할까?”

이 질문은 주니어 개발자에게 특히 날카롭다. 아직 실무 경험은 많지 않고, 깊은 도메인 지식도 부족하고, 시스템 설계 경험도 충분하지 않다. 그런데 구현 자체의 희소성은 점점 낮아지는 것처럼 보인다. 그러면 자연스럽게 불안해진다. 더 많은 기술 스택을 배워야 할까, 더 큰 포트폴리오를 만들어야 할까, 아니면 아예 다른 방향의 강점을 찾아야 할까.

나는 그 답 중 하나가 도메인 이해에 있다고 생각한다. AI가 코드를 생성할 수 있어도, 어떤 문제가 중요한지, 어떤 데이터가 남아야 하는지, 어떤 예외를 허용하면 안 되는지, 어떤 사용자가 어떤 상황에서 시스템을 쓰는지는 그냥 생기지 않는다. 누군가는 현실의 문제를 이해하고, 그것을 소프트웨어의 구조로 바꿔야 한다.

제조 도메인은 그런 관점에서 탐색해볼 만한 분야다. 처음에는 공장, 설비, 생산, 품질, 자재 같은 단어가 개발자에게 멀게 느껴질 수 있다. 하지만 제조 현장에도 소프트웨어가 필요하다. 작업지시를 관리하고, 생산 이력을 남기고, 검사 결과를 기록하고, 설비 상태를 모니터링하고, 재고와 LOT를 추적하고, 현장의 데이터를 대시보드로 보여주는 일은 모두 소프트웨어와 연결된다.

제조업은 오래된 산업이지만, 그렇기 때문에 오히려 소프트웨어가 들어갈 여지가 크다. 엑셀로 관리하던 업무, 현장마다 흩어진 데이터, 설비와 시스템 사이의 단절, 품질과 생산 이력의 추적 문제는 모두 소프트웨어가 풀 수 있는 문제다. 그리고 이런 문제는 단순히 화면을 예쁘게 만드는 것보다 업무 흐름과 데이터 구조를 이해하는 능력을 요구한다.

이 글은 제조 도메인 소프트웨어 개발의 가능성을 하나의 시리즈로 다루기 위한 첫 글이다. 이번 글에서는 전체 지도를 먼저 그리고, 이후 글에서 각각의 주제를 나누어 더 깊게 정리하려고 한다.

앞으로 다룰 이야기

1. 제조 도메인에 관심이 생긴 주니어가 먼저 공부하면 좋은 것들

처음부터 모든 것을 알 필요는 없다. 먼저 작업지시, 공정, BOM, LOT, 검사, 불량, 설비, 재고 같은 기본 용어를 익히고, 작은 업무 하나를 데이터와 상태로 그려보는 것부터 시작하면 된다.

첫 번째 글에서는 제조 도메인을 처음 공부하는 주니어 개발자가 어떤 용어, 데이터 모델, 작은 포트폴리오 주제부터 잡으면 좋은지 정리할 예정이다.

2. 제조 도메인은 아직 디지털 전환의 여지가 크다

제조업은 이미 오래된 산업이지만, 모든 업무가 충분히 소프트웨어화된 것은 아니다. 한국의 2024년 스마트제조혁신 실태조사에 따르면, 공장 보유 중소·중견 제조기업 중 스마트공장을 도입한 기업은 19.5%이고, 도입 기업 중 75.5%는 기초 단계에 머물러 있다. 제조 AI 도입률은 0.1% 수준으로 발표되었다.

이 숫자는 제조업의 디지털 전환이 이미 끝난 이야기가 아니라, 아직 진행 중인 이야기라는 점을 보여준다. 두 번째 글에서는 이 흐름이 주니어 개발자에게 어떤 기회가 될 수 있는지 다룰 예정이다.

3. 도메인을 이해하는 개발자의 희소성이 커질 수 있다

Vibe 코딩 시대에는 “만드는 능력”만으로 차별화하기가 점점 어려워질 수 있다. 대신 어떤 업무를 시스템으로 바꿀지 판단하는 능력이 더 중요해질 수 있다.

제조 도메인 소프트웨어는 단순히 화면과 API를 만드는 일이 아니다. 생산, 품질, 설비, 자재, 재고, 작업자, 공정, LOT, Serial, 검사, 불량, 이력 같은 개념을 데이터와 시스템으로 표현해야 한다.

세 번째 글에서는 작업지시, 공정, 검사, 불량, LOT 같은 개념이 왜 단순 CRUD보다 복잡한지, 그리고 도메인 이해가 개발자의 가치와 어떻게 연결되는지 다룰 예정이다.

4. 소프트웨어의 결과가 현실의 지표로 드러난다

제조 도메인의 매력 중 하나는 소프트웨어의 결과가 현실의 변화로 드러난다는 점이다. 어떤 기능은 작업자의 입력 시간을 줄일 수 있고, 어떤 대시보드는 생산 지연을 더 빨리 발견하게 만들 수 있다. 품질 검사 기록 시스템은 불량 원인을 추적하는 데 도움을 줄 수 있고, 설비 점검 앱은 예방정비의 기반이 될 수 있다.

네 번째 글에서는 제조 소프트웨어의 결과가 생산성, 품질, 설비 가동률, 작업 시간, 재고 정확도 같은 지표와 어떻게 연결되는지 살펴볼 예정이다.

마무리

제조 도메인 소프트웨어 개발은 주니어 개발자에게 쉬운 길은 아닐 수 있다. 용어도 낯설고, 현장의 업무 흐름도 처음에는 복잡하게 느껴진다. 빠르게 화려한 결과물을 보여주기도 어렵다.

하지만 Vibe 코딩으로 구현 장벽이 낮아질수록, 주니어 개발자에게는 “무엇을 만들 것인가”와 “왜 그렇게 설계할 것인가”가 더 중요해질 수 있다. 제조 도메인은 그 질문을 훈련하기 좋은 분야다. 현실의 업무가 있고, 복잡한 데이터가 있고, 사용자의 제약이 있고, 결과가 운영 지표로 드러나기 때문이다.

앞으로 개발자가 단순히 기능을 구현하는 사람을 넘어 문제를 정의하고 시스템을 설계하는 사람으로 성장하고 싶다면, 제조 도메인은 충분히 탐색해볼 만한 길이다.

Q&A

Q. Vibe 코딩 시대에 주니어 개발자는 무엇으로 차별화할 수 있나요?

구현 속도만으로 차별화하기는 점점 어려워질 수 있다. 대신 어떤 문제를 풀어야 하는지, 어떤 데이터를 남겨야 하는지, 어떤 업무 흐름을 시스템으로 바꿔야 하는지 판단하는 능력이 중요해질 수 있다.

Q. 하드웨어를 잘 몰라도 제조 도메인 소프트웨어를 공부할 수 있나요?

가능하다. 처음부터 설비나 제어 시스템을 깊게 알 필요는 없다. 먼저 작업지시, 공정, 검사, 불량, LOT, 재고 같은 업무 개념을 이해하고, 그것을 데이터 모델과 화면 흐름으로 바꾸는 연습부터 시작하면 된다.

Q. 제조 도메인은 주니어 개발자에게 너무 어렵지 않나요?

낯설 수는 있다. 그래서 처음에는 큰 시스템보다 작은 업무 하나를 잡는 편이 좋다. 예를 들어 작업지시나 검사 기록처럼 하나의 흐름을 정하고, 필요한 데이터와 상태를 그려보는 식으로 시작할 수 있다.

Q. 제조 도메인 개발은 일반 웹 개발과 무엇이 다른가요?

일반 웹 개발과 겹치는 기술은 많지만, 중요한 판단 기준이 다르다. 제조 앱에서는 화면의 편의성뿐 아니라 데이터 정확성, 추적성, 변경 이력, 현장 업무 흐름, 장애 대응이 더 크게 작동한다.

Q. 포트폴리오로는 무엇을 만들면 좋나요?

처음에는 미니 MES를 작게 잡는 것이 좋다. 작업지시, 공정 진행, 검사 결과, 불량 등록 정도만 구현해도 제조 도메인의 핵심 흐름을 연습할 수 있다.

Q. 이 분야의 미래 가능성은 어디에서 나오나요?

제조업의 디지털 전환이 아직 진행 중이라는 점에서 나온다. 엑셀 중심 업무, 분리된 데이터, 생산 이력 추적, 품질 관리, 설비 모니터링 같은 문제는 계속 소프트웨어화될 가능성이 크다.

참고 자료

• 대한민국 정책브리핑, 2024년 스마트제조혁신실태조사 결과 발표
• Deloitte, 2025 Smart Manufacturing and Operations Survey
• ISA, ISA-95 Standard: Enterprise-Control System Integration
• McKinsey, Capturing the true value of Industry 4.0
• NIST, Protecting Information and System Integrity in Industrial Control System Environments