홈 디지털 트윈 프로젝트 - AMR 기반 배터리 팩 공정 시뮬레이터
포스트
취소

디지털 트윈 프로젝트 - AMR 기반 배터리 팩 공정 시뮬레이터

게시 2026/07/21 업데이트 2026/07/21
By dapin
42 분읽는 시간

table of contents

결과 미리보기

  • 주제: 디지털 트윈 프로젝트 - AMR 기반 배터리 팩 조립 공장 공정 시뮬레이터
  • 무슨 내용이냐면: 배터리 팩 조립 공장에서 공정 사이클타임과 설비 수, AMR 수 등을 다르게 설정했을 때 KPI가 어떻게 변하는지 시뮬레이션하고 분석하는 서비스 만들기
  • 어떻게 만들었냐면: 언리얼(과 C++)로 실제 3D 오브젝트가 움직이는 시뮬레이터를 만들고, 결과는 JSON으로 저장되며, 이 JSON으로 추가 분석을 할 수 있는 C# 프로그램을 만들었음
  • 결과: 우수 프로젝트 상 수상, 시뮬레이터는 “눈에 보이게 만드는 것도 중요하다”는 피드백을 받음.
  • 자료

결과만 좀 더 자세히 보기

  • 배경 및 목표 (Situation & Task)
    • Unreal Engine 5 3D 환경에서 AMR 기반 스마트 팩토리의 가동 시나리오를 검증하고 생산 효율성을 정량 분석하는 의사결정 지원용 가상 시뮬레이터를 기획함.
    • 3D 관제뿐만 아니라 다수의 운영 시나리오를 일괄 검증하는 배치 시뮬레이션(Batch Run) 및 11대 KPI What-If 분석 프레임워크를 목표로 설계함.
    • 추가로, 교육 환경의 물리적 설비 부재라는 현실적 한계를 근거로 시뮬레이터 자체를 독립적 소프트웨어 결과물로 기획하였으며, 현대자동차그룹의 로봇-인프라 시뮬레이션 연구 수요 및 가상 팩토리 빌더 수요에 매칭함.
  • 역할 및 행동 (Action)
    • PM 및 시스템 아키텍처/솔루션 설계 주도:
      • 시스템 동작 흐름 및 API 규격 설계: 공정/물류 AMR의 실시간 상태 전이와 스케줄러 간의 상호작용 흐름을 정립하고, DTAmrScheduler와 DTAmrCharacter 간의 상호작용 API 계약(Request/Return, Route Dispatch)을 설계해 유기적인 물류 동선을 구현함.
      • 의사결정 KPI 프레임워크 및 데이터 스키마 정의: 성과, 병목, 자원 관점의 11대 KPI 지표를 도출하고, JSON 내보내기용 스키마를 수립하여 단일 진실 소스(SSOT) 기반 데이터 분석의 토대를 다짐.
      • AI 에이전트 협업 및 개발 표준 가이드라인 수립: 개발 편차를 예방하기 위해 AGENTS.md를 작성하여 각 트랙별 범위와 C++ 부모-블루프린트 자식 하이브리드 설계 표준을 정의하여 프로젝트의 무결성을 유지함.
    • 시뮬레이션 핵심 코어 트랙(Track A) 설계 및 전 트랙 통합·디버깅 주도:
      • 시뮬레이션 라이프사이클 및 데이터 지속성 설계: GameInstance 및 시뮬레이션 매니저(DTSimulationManager), 세이브게임/JSON 내보내기 프로세스, KPI 집계 등 핵심 코어 시스템(Track A)의 아키텍처 설계를 전담함.
      • 전체 트랙(A, C, D) 최종 통합 및 디버깅: 병렬 개발 과정에서 발생한 이기종 모듈 간의 중복 구현 및 정합성 충돌에 대해, 아키텍트이자 PM으로서 통합 디버깅을 전담하여 정합성 오류를 해소하고 연동을 완수함.
      • 3D 공간 레벨 배치 및 환경 셋업: 시뮬레이션 검증용 가상 공장 레벨 내에 설비, 충전소, 물류 랙, 경로 웨이포인트 등 주요 3D 액터들을 배치하고 환경을 직접 세팅하여 실질적인 검증 기반을 마련함.
    • AI 활용:
      • 11대 KPI 정의 및 충전소 AMR 스케줄링 알고리즘 설계 시 AI 에이전트에게 기술적 조언을 구하여 대안을 탐색하고, 구체적인 도메인 요구사항에 맞게 보완하여 반영함. 그외에도 설계 시 다양한 부분에서 에이전트에게 기술적 조언을 구하며 진행함.
      • C++ 기반 시뮬레이터 시스템 구현(AMR 캐릭터 제어, 스케줄링 시스템, KPI 집계 등) 전반은 AI 에이전트에게 지시하여 소스코드를 생성했으며, 개발된 코드는 플레이 테스트(PIE)를 통해 동작 무결성을 직접 검증함.
    • 문서화:
      • Jira와 컨플루언스를 연동하여 실무적인 문서 관리 체계를 따르고자 하였음.
      • 문서의 용도와 목적(AI를 위한 문서, 사람을 위한 문서, 라이브 편집이 필요한 문서 등)에 따라 깃허브와 컨플루언스에서 각각 관리하였음. AI 에이전트가 참고하여 작업해야 하는 문서는 깃허브에서 관리하고, AI에게 보여주면 혼란을 유발할 여지가 있거나, 사람이 빠르게 편집하고 확인하는 편의성이 더 중점인 문서는 컨플루언스에서 관리되었음.
      • 예를 들면 깃허브에는 프로젝트에 대한 구체적인 설계 문서와 구현 TODO 문서가 포함되었음. 컨플루언스에는 회의록이나 매일 작성되는 TODO & DONE 기록, 인간 팀원들이 참고해야 할 참고자료 공유, 개발 중 생성된 일부 설계나 로직에 관한 문서 등이 작성되었음.
  • 기여도 구분
    • PM, 제품 기획(PO), 시스템 아키텍처 설계 및 핵심 코어(Track A) 설계/전 트랙 통합 디버깅 담당
  • 결과 및 성과 (Result)
    • 우수 프로젝트상 수상
    • 11대 KPI 기반의 배치 시뮬레이션을 설계하여 가상 공장의 자원 배치와 병목 요소를 정량 예측하고 최적화 방안을 도출할 수 있음을 입증함.
    • 최종 발표 시 “로봇 수량 증가에 따른 생산성 비례 향상 여부”에 대한 평가자(멘토)의 질문에 대해, 인프라 수용력 한계로 인한 생산성 포화 임계점을 도메인 이론과 시뮬레이터 데이터를 기반으로 논리적으로 밝혀내며 기술적 인사이트를 입증함.
    • AI 에이전트를 조율하는 표준 개발 아키텍처를 도입하여, 2주의 단기간 내에 설계 불일치를 줄이고 각 트랙의 복잡한 컴포넌트들을 유기적으로 통합하고 디버깅하여 고신뢰성의 시뮬레이터를 성공적으로 릴리즈함.
  • 자료
    • 깃허브: https://github.com/mobility-school-3th-team1/DT-virtual-factory-simulator
    • 시연 영상: https://youtu.be/pgQwM4Za9ro

이 다음부터는 나의 썰풀기에 가깝다… 위의 요약에 담기지 않은 이야기들의 자유로운 발화일 뿐임.

주제 정하기

현대오토에버 모빌리티 SW 스쿨 3기 마지막 프로젝트 주제는 디지털 트윈이었다. 목적도 어떤 지침도 딱히 없고, 이번 교육에서 배운 언리얼 스킬을 기반으로 ‘디지털 트윈과 관련된 무언가’를 만들어 올 것…

이 시점에서 내가 주제를 정할 때 정한 규칙은 2가지였다.

  1. 아이디어 빌딩 시간을 줄이기 위해 이전에 썼던 아이디어를 재활용할 것.
  2. 웹이니 뭐니 붙여서 뭔가 있어보이는 걸 만들려고 하면 반드시 어정쩡한 결과물이 나온다는 것을 지난 5개월 간의 팀플로 학습했다. 짧고 굵게 확실한 것을 만들기.

1번 조항으로 인해 ‘AMR 기반 배터리 팩 공장’이라는 소재가 정해졌고(SFaaS 프로젝트 재활용), 2번 조항으로 인해 시뮬레이터라는 결과물의 형식이 정해졌다. 이때 당시 내 팀을 포함해 클래스에 남아있던 대부분의 학생들은 높은 확률로 현실세계와 연동되는 디지털 트윈을 생각할 것 같은 분위기였는데(왜냐면 디지털 트윈에 대해 가장 먼저 떠오르는 이미지가 그거였을테니까), 이 분위기를 따라가봤자 비슷한 프로젝트 중 하나가 될 뿐이며, 현실세계의 설비는 제공되지 않기 때문에 집에서 선풍기라도 뜯어오지 않는 이상 시뮬레이션에 불과하다는 한계를 벗어날 순 없었다.

여기에 덧붙여 다른 팀과 비슷한 주제를 한다는 것은 기술력이든 비주얼이든 무언가 압도적으로 만들어서 확실하게 어필해야만 점수를 얻을 수 있다는 건데, 한 팀이 그간 모든 프로젝트에서 1등을 독점하면서 영역이 겹치는 건 개큰손해라는 확신이 들었다. 워낙 합이 좋은 팀이라 영역이 겹치면 내 팀은 못이긴다. 그걸 3번이나 봤다. 3번이나 봤기 때문에 마지막 프로젝트마저 1등을 넘겨줄 수는 없다는 열받음도 나의 갑작스러운 지능 상승에 한몫 했다.

또한 내가 시뮬레이터에 적잖이 승산이 있다고 생각한 이유, 현대차그룹의 최근 수요를 직접 봤기 때문이다(못해도 1년은 된 정보이긴 하다만). 석사 과정 중에 연구실에서 진행하는 현대차 산학 사업에 조금 발을 걸친 때가 있었는데, 그때 연구해서 기술경영경제학회에 발표된 논문이 로봇 친화 빌딩 시뮬레이션을 주제로 했다. 성수에 실제 운영되고 있는 팩토리얼 성수를 가상환경에 그대로 구현한 다음 F&B 로봇의 수를 바꿔가면서 운영 효율성을 비교했고, 로봇의 수량보다도 로봇이 탈 엘리베이터라는 인프라가 효율 향상의 병목이라는 결론으로 마무리된 논문이었다. 그리고 이에 더해 모빌리티 스쿨 수업 시간에 종종 소개되던 것이 VFB(virtual factory builder)였다. 여기서 추론할 수 있는 현대차그룹과 현대오토에버의 수요는 인프라나 설비 등의 파라미터를 조절하여 실험할 수 있는 서비스 혹은 플랫폼이라고 볼 수 있겠다. 로봇 친화 빌딩에 대해 이미 그러한 연구를 진행했으며, 공장에 대해서도 VFB라는 이름으로 현재진행형으로 진행하고 있다면 그 수요에 맞춰 주제를 내보이는 것이 그래도 다른 결과물보다 더 좋게 보이겠지. 이제와서 본다면 실제로 상을 탔으니 어느 정도 맞는 구석이 있었을 것이다.

따라서 위와 같은 사고 과정을 거쳐 “설비 수, AMR 수, 사이클타임 등의 조정이 가능한 공정 시뮬레이터”라는 주제가 정해졌다. 아이디어는 팀원들한테 의견 없냐 이거 어떠냐 하고 며칠동안 물어봤는데 다 괜찮대서 합의함. 로봇 친화 빌딩 얘기 근거로 설득도 좀 했고.

주제를 정했으면 설계를 해야죠

지금까지의 팀플 경험으로 보건대, 내 팀은 5개월만으로는 완전히 합이 맞는 팀은 아니었다. 기획/설계 같이 어디 어긋나면 수습이 늦을수록 일이 커지는 작업들은 여러 사람이 나눌수록 문제가 생겼다. 특히나 직전 프로젝트였던 SFaaS 프로젝트에서 설계를 몇 명이 나눠서 했다가 마지막에 구멍 숭숭 난 결과물을 끼워 고치는 데 시간을 꽤 들였던 걸 모두가 기억하기 때문에 이번 설계는 내가 거의 다 했다. 내가 설계는 제일 잘한다는 자신감도 있었고, 마침 그때 팀원들이 각자 일정이 있어서 몇 명씩 돌아가면서 빠지던 때라 내가 다 해도 누가 특별히 놀거나 하지 않는 상황이어서 자연스럽게 그렇게 된 면도 있다.

이참에 혼자 모든 내용을 주무를 수 있다는 이점을 살려서 최대한 빠르게 설계를 끝내보자는 생각으로 이전 프로젝트 자료에서 기획서 초안을 만들고, 이걸 어느정도 발전시켜서 팀원들에게 검토를 시켰다. 다들 언리얼 학습 2주차 상태라 기술적인 서술은 이해하기 어려우니 쉽게 설명한 버전의 기획서도 같이 썼었다. 나도 그게 필요했거든.

기획서의 구성이 대충 충분하다 싶은 시점에, 기획서만 따로 분리해서 이번 프로젝트에 쓸 레포지토리를 새로 만들고, 기획서를 여러 번 읽으면서 내 의도에 맞지 않는 부분을 계속 고치고 파생 문서를 작성했다. UML이나 데이터 스키마 같은 것들. 기획서 초안이 새 레포지토리에 들어갔을 때가 0.6버전, 그리고 0.7버전부터 파생 문서가 생기기 시작했다. 사실상 이번에는 기획 문서와 설계 문서의 구분이 없었고, 기획서가 사실상 설계서나 다름 없어서 이때부터 구현도 시작했던 걸로 기억한다. 실제 프로그램에 구현할 계획을 하면서 디테일을 다듬을 부분이 생기면 0.7.1과 같이 마이너 버전 업데이트를 했고, 하다보니 좀 크게 구조를 바꿀 일이 생기면 0.8, 0.9와 같이 메이저 버전 업데이트를 했다. 최종적으로 확정된 문서는 0.9버전이었다.

구현은 어떻게 했나요

내가 현대오토에버 모빌리티 SW 스쿨을 수강한 것에는 아주 만족하지만, 6개월 안에 이 모든 과정을 욱여넣는 것에는 약간 의구심이라고 해야 할지, 과하다고 해야 할지, 그런 느낌이 좀 있다. 시뮬레이터를 만들자는 설계는 좋다. 근데 그걸 누가 만들어야 하나? 언리얼 2주 배운 학생 4명이 만들어야 한다. 얼마만에? 2주만에. AI 없었으면 도무지 현실성이 없는 일정 계획이다… 이러니 이전 기수 후기들이 하나같이 6개월 내내 프로젝트만 하면 밤샘을 했다고 하는 거다. 하루에 24시간씩 투자하지 않고서는 이만큼만 배우고 저만큼을 만들어낼 수가 없다.

위와 같은 사유에 의해, 나도 원래는 블루프린트로 배웠으니 가능하면 그걸로 만들고 싶었지만, AI가 쉽게 편집하고 실행할 수 있는 C++로 구현을 진행하기로 했다. 팀 내에서도 AI를 쓰는 것에 대한 제안이 있었고, 강사님께 여쭤보기도 했지만 “구현하고 실행해서 문제 없으면 써도 되는 거 아니겠어요?”라는 대략 70~80% 정도의 허락에 이 프로젝트의 핵심적인 부분은 전부 바이브코딩으로 구현했다. 그걸 염두에 두고 설계 문서를 아주 자세하게 만들기도 했다.

이번 프로젝트에서 새로 시도해본 방식이 있는데, CLI에 에이전트를 설치해서 직접 편집하게 시키는 것이다. 나는 Cursor, 바이브코딩을 맡은 다른 팀원은 ChatGPT를 썼는데, 각자 자기 유료 AI의 CLI 버전을 설치해서 설계 문서에 대해 구현을 지시했다. 어느 정도는 내가 AGENTS.md에 대략적인 행동 규칙을 써두긴 했는데 아무래도 사람이 그 내용을 알고 그 규칙을 따르게 유도하지 않으면 약간 무시되는 면이 있는 것 같았다. 그래도 워낙 설계 문서가 자세하고 AI들이 많이 발전해서 그런지 결과물은 꽤 잘나왔다. 진짜 기대 이상으로 잘 돼서 다행이었다. 내가 CLI 설치 도와준 그 팀원도 완전 편하다고 좋아하더라.

시뮬레이션 시스템과 스케줄러, 설비 및 AMR의 로직은 다 바이브코딩으로 구현됐고, 난 시스템을 맡았다. ChatGPT를 쓴 팀원이 스케줄러와 설비/AMR 로직을 구현했다. 그리고 다른 2명의 팀원은 바이브코딩을 하지는 않았고, 사람 손이 필요한 작업들을 했다. UI 디자인, 사운드, 나이아가라 이펙트, 컨셉에 맞는 Mesh 탐색하거나 만들기, 공장 레이아웃 디자인하기 등 주로 효과와 비주얼에 관련된 부분이었다. 이번에 UI 디자인이 예쁘게 잘 나왔는데, 실제 구현된 결과물에서는 그 정갈함을 다 담지 못한 게 아쉬울 따름이다.

그리고 하나 더 신경쓴 부분이 있다. 시뮬레이션을 리얼타임으로만 보게 하는 건 UX에 너무 안좋으니까 난 배속 기능이 필수라고 생각한다. 그 생각에 따라 구상한 게 기본 배속을 10배속으로 가정하고, 거기에 10배를 더 올려서 최대 10배 시뮬레이션까지 가능하게 만드는 로직이다. 방식은 그렇게 복잡하지 않다. 실제 공정 사이클타임이 만약 60초라고 한다면, 시뮬레이터는 이를 6초로 입력받는다. 여기서 기본 배속 10배가 적용된다. 다음으로 추가 배속은 Set Global Time Dilation으로 최대 10배까지만 조정할 수 있게 한다. 그러니 6초로 입력된 사이클타임에서 다시 10배가 되면 0.6초, 원래의 60초에 비하면 100배속으로 취급되는 것이다. 설비만 빨리 움직이면 안되니까 AMR의 속도나 애니메이션도 같이 영향을 받도록 하기 위해 Global Time Dilation을 바꿨다. 물론 가장 안정적으로 배속을 올리는 방법은 직접 루프를 돌면서 계산하는 거라고 하지만, 그때 구현된 상황에서는 반복문 방식으로는 같이 구현하기 어려운 요소들이 있었고, 개발 기한 상 Global Time Dilation이 제일 빠르게 구현되는 방법이어서 그렇게 했던 것으로 기억한다. 사용자는 기본 배속(60초 → 6초)은 건드릴 수 없고, Global Time Dilation의 배속만 0.1부터 10까지 지정할 수 있도록 해서 1배속부터 100배속까지 돌아가는 시뮬레이터를 만들었다. 다만 동일한 파라미터로 시뮬레이션을 실행했을 때 배속에 상관 없이 항상 일관된 결과가 나오지는 않는다. 그게 Global Time Dilation 기반 배속의 단점.

별 이슈는 없었나

앞선 5개월간의 프로젝트에 비하면 가장 수월하게 진행된 프로젝트라고 자신한다. 물론 아무 문제도 없었던 건 아니지만 기한 내에 수습 가능했고, 그 수와 규모가 이전보다 작았다.

그럼에도 기억에 남은 문제라면 각자 만든 결과물을 합치는 게 어려웠다 정도일 것 같다. 가능한 한 여러 인원이 동시에 개발하게 만들기 위해 개발 영역을 시스템, 스케줄러 및 설비, 사운드/이펙트, Mesh 및 레벨 디자인 등으로 나눴는데, 이 중에 시스템과 스케줄러는 어쩔 수 없이 겹치는 영역이 있는 편이긴 하다. 게다가 2주 학습한 수준에서 바이브코딩으로 구현하다 보니 AI가 만든 결과물이 어느 영역에 얼마나 발을 걸치고 있는지 온전히 파악하는 게 어렵다. 사운드/이펙트와 레벨 디자인은 다른 영역에 비해 상당히 독립적이라 웬만해서 그럴 일이 없었지만, 시스템과 스케줄러는 서로가 있어야 시뮬레이션이 온전히 돌아갈 수 있다보니 각자 만드는 구간에서는 어느 정도 중복 구현이 생기게 되었다. 다른 파트가 전체 소스에 병합되지 않은 상태라도 테스트는 해봐야 하니까. 그걸 마지막에 모두 합치는 게 내가 맡은 일이었다. 설계도 내가 했고, AI도 내가 제일 잘 썼고, 분담 작업 때문에 생긴 문제니 이걸 또 분담해봐야 문제가 리플레이될 뿐이라 자진해서 수리했다. 겸사겸사 부가 기능도 좀 더 달아서 약간 더 보기 좋은 결과물로 포장하기도 했고.

피드백 공유 좀 해보세요

피드백은 2번 받았다. 한번은 프로젝트 중간에, 한번은 최종 발표 시간에.

프로젝트 중간에 받은 피드백은 크게 요약하면 이 프로젝트는 솔루션 발표로 포지셔닝하는 게 좋겠다는 것, 좀 더 challenge한 요소를 추가할 것, 프로젝트의 어필 포인트를 확실히 잡고, 문서화를 잘 해둘 것.

코딩을 AI가 전부 했기 때문에 솔루션 제안으로 가는 게 확실히 좋은 방향이었다. 기술력으로는 내보일 요소가 부족하지만 아이디어는 괜찮은 편이었으니까. 멘토님도 그때 구현되어 있던 아이디어에 대해서는 좋다고 하셨다. 이 아이디어 자체에는 추가로 더 피드백하고 싶은 점은 없고, 다만 챌린지가 좀 부족하다는 점만 채우면 될 것 같다며 두 가지 챌린지를 제시하셨었다. 첫 번째는 비동기 통신 구현하기. 실제 공장에서는 시간 순서대로 시그널이 딱 맞춰서 오가는 게 아니기 때문에 비동기 처리가 필요하며, 이 프로젝트는 동기 처리를 전제로 하기 때문에 그 점에서는 현실성이 떨어진다는 단점 때문이었다. 두 번째 선택지는 배치 시뮬레이션 구현. 시뮬레이션이라는 건 원래부터가 1번만 실행하는 것을 전제로 하는 게 아니다. 여러 번 돌려보고 그 중에 좋았던 것을 걸러내는 것이기 때문에 매번 클릭해서 실행되는 시뮬레이터는 UX에 문제가 있는 것이다. 그러니 한번에 여러 시뮬레이션을 다 돌릴 수 있게 배치 시뮬레이션을 구현할 것. 당시 기한 내에 구현이 성공할 가능성은 후자가 더 높다는 멘토님 조언에 팀에서는 배치 시뮬레이션을 구현하기로 합의했었다. 그 외에도 KPI는 여러 가지 요소를 최대한 넣다보니 복잡해졌으므로 아예 AMR에 집중해서 그 구성을 다듬으라는 피드백도 받아서 결과적으로 지금의 11개 KPI가 구성되기도 했다.

남은 프로젝트 기간 동안 최대한 피드백을 반영했고, 최종 발표에서는 반영된 결과에 대한 추가 피드백을 받았다. 발표야 당연히 솔루션 제안 형식으로 했고, 배치 시뮬레이션과 KPI 구성에 대한 피드백이었다. 배치 시뮬레이션 기능이 한번에 여러 시뮬레이션을 실행하는 건 맞지만, 이건 언리얼을 기반으로 실행되는 비주얼도 중요한 시뮬레이터이기 때문에, 그 배치 시뮬레이션이 돌아가는 동안 화면을 통해 현황 정보를 제공하는 것도 중요하다고 하셨다. 당시 배치 시뮬레이션은 마지막에 급하게 추가된 기능이다 보니 원래 있던 UI를 최소한으로만 수정해서 실행되고 있었고, 그렇기 때문에 현재 시뮬레이션이 몇 번째인지, 파라미터는 어떻게 달라졌는지 등 ‘여러 번 실행을 전제로 할 때 봐야 할 지표’들이 안보이는 상태였다. 시간 상 한계로 만들지 못한 것이 아쉬울 따름. KPI도 비슷한 결의 피드백이었는데, 최종 결과물에서는 의사 결정 근거를 제공한다는 명목으로 이미 다 계산된 지표들만 보여줬지만, 시뮬레이션을 실행하는 것은 그 과정 자체가 필요한 경우도 있고, 결과물을 봤을 때 이게 왜 이렇게 나왔는지 확인할 수 있어야 하기 때문에 가능하면 데이터는 많을수록 좋다고 하셨다. 이제와서 생각해 보면 AMR이 어디 들어가고 나갔는지 기록한 이벤트 로그가 JSON 파일에 같이 기록되긴 했는데, 이걸 별도로 활용하는 부분이 없었어서 발표할 때 나도 잊고있었던 것 같다.

이건 피드백은 아니고 아마 본인들이 만들어낸 것에 대한 이해를 똑바로 했는지 확인하려고 질문하신 것 같긴 한데, 로봇이 10대에서 15대로 늘어나면 그 증가량만큼 생산량이나 효율이 증가하는지 물어보셨다. 로봇 친화 빌딩 인프라 연구랑 똑같이, 이 경우에도 설비 수가 로봇 수를 따라가지 못하기 때문에 답은 아니오였다. 구현 상의 한계로 설비는 각각 최대 3대까지만 놓을 수 있는데, 여기에 2대만 들어가던 로봇이 5대로 늘어나면 그 증가량은 눈에 띄겠지만, 10대에서 15대가 되는 건 오히려 효율이 떨어질 가능성이 높다. 설비가 3대밖에 없는데 그 10대의 로봇이 다 어디 가서 서있겠냐는 말이죠. 게다가 각 로봇이 한번 공정을 시작하면 처음부터 끝까지 무조건 순서대로만 갈 수 있는 구성이었기 때문에 빈 자리가 있다고 아무나 가서 작업할 수 있는 게 아니다. 다행히도 멘토님은 이 답변에는 만족하신 것 같았다. 아마 가산점에 한몫 하지 않았을까 라고 생각하고 싶은 부분.

프로젝트 후기

이번 프로젝트는 사실상 코딩 능력을 기대할 수는 없다. 인간이 한 일이라고는 딸깍 후 잘 돌아가나 검사한 것밖에 없는데 무슨 스킬을 가졌다고 주장하겠나 아무것도 없지. 다만 나는 이제 설계 능력을 어필할 프로젝트가 추가되었다. 이전에도 현대차그룹의 특허 수요에 맞춰서 캠퍼스특허유니버시아드를 수상했었고, 이번에는 현대오토에버가 은연중에 보여준 수요에 맞춰서 상을 탔다. 상을 탔다는 것 자체가 공식적인 인정 아니겠습니까.

겸사겸사 그냥 하고 싶은 말 좀 더 하자면, AI가 발전하는 만큼 예전만한 주니어는 점점 씨가 마르지 않을까 싶다. 비개발자도 AI만 잘 다루면 어지간한 신입 프로그래머보다 좋은 결과물을 낼 수 있게 되었기 때문에 신입 개발자 입장에서는 AI를 안 쓰기가 어렵고, 오히려 기업도 AI 활용 역량을 요구하기 시작했기 때문에 당연히 쓸 줄 알아야 하는 것이 되었다. 그에 대한 trade-off로 순수 인간의 프로그래밍 스킬이 씨가 마르는 것뿐임… 남이 다 해줬는데 그게 머리에 남아봐야 얼마나 남겠습니까. 복습하지 않으면 아무것도 안남고, 내가 인간 작업자로서 남길 수 있는 건 이 아이디어가 나에게서 비롯했다는 점임. 그런 점에서 설계 능력은 어떻게든 쓸모가 있는 능력이라고 본다.

HAE, 프로젝트 - 디지털 트윈
현대오토에버 모빌리티 디지털 트윈 설계 시뮬레이터
이 기사는 저작권자의 CC BY-NC-ND 4.0 라이센스를 따릅니다.
최근 업데이트
바로가기

SFaaS 프로젝트 - 배터리 팩 공장 AMR 모니터링 시스템

도커로 ollama MCP 연결하기 for 안티그래비티와 VScode