이 글은 입사 1주년이 된 제조업계(스마트팩토리) SI 주니어 프론트엔드 개발자의 자아성찰 및 회고를 담은 글이다.
2024년 1월 15일.
부트캠프 강사님의 소개로 2023년에 약 2개월 가량 진행했던 홈페이지 리뉴얼 프로젝트의 공로를 인정받아,
지금의 회사에 정규직으로 발을 떼게된 날이었다.
생각지도 않았던 제조(스마트 팩토리) 도메인이었기에 반신반의했지만,
당시의 내 실력이나 상태로써는 별도로 취업준비 기간을 갖지않고 일할 수 있었기에 최선이었고,
1년이 지난 지금에도 그 선택에 후회는 없는 것 같다.
회사의 메인 기술스택은 Java와 C#이지만,
다행히도(?) 지난 1년 간 맡았던 업무는 내가 공부해온 프론트엔드(React) 쪽의 업무들이었고,
들어왔던 요구사항들은 무리없이 처리할 수 있는 수준이었다.
하지만, 스스로에게 '너 지난 1년동안 너가 원하는 만큼 이뤘어?'라고 묻는다면
자신있게 그렇다고 대답하진 못하겠다.
이러한 맥락에서 아쉬웠던 것 / 얻은 것 / 개선해야할 것 으로 나눠서 성찰해보고자 한다.
아쉬웠던 것
지난 1년 동안 스스로에게 아쉬웠던 것은 크게 2가지로 얘기할 수 있을 것 같다.
- 코어 로직에 대한 이해 부족
스마트팩토리 업계는 굉장히 복잡하다.
하나의 Job이 하나의 AGV(무인운반차)에 할당되어 그 Job을 끝내는 과정에는, 여러 종류의 장비가 PLC(자동화제어장비)를 통해 무수히 많은 신호를 서로 보내고 이는 실시간 네트워크 통신기술인(signalR)을 통해 로그에 쌓인다.
이에 따라, 각 장비를 제어하는 시스템이 개별적으로 존재한다.( ACS / CCS / OCS / SCS 등)
구체적으로 스마트팩토리 각 장비가 DB에 실시간으로 쌓는 데이터가 어떤 형태로 오는지, 서버에서는 이 데이터를 어떻게 활용해서 API로 만들어서 제공하는지는 모르기에, 만약 누가 나에게 '스마트팩토리 쪽에서 일했었으면, 이건 어떻게 동작하는지 알아?'라고 물어본다면, 대답하지 못할 것 같다. - 자신감이 결여된 나의 태도와 의지 부족
한정된 기간 안에 요구사항에 맞게, 기능을 개발하고 UI를 만드는 것은 생각보다 어렵지 않았다.
하지만, 그저 에러 없이 UX가 크게 불편하지 않게 개발하는 데에만 급급했기에, 누가 나의 코드를 평가하겠다고 한다면 쥐구멍으로 숨고 싶을 것 같다.
(핑계를 대보자면, 사내에 프론트엔드 경험이 훨씬 많아서 도움을 받을 수 있는 분이 마땅치 않은 상황이기도 하고, 나중에 개선할 시간이 있을 것이다라고 자기최면을 걸었던 것 같다.)
얻은 것
스마트팩토리 쪽으로 UI 개발을 한다고 하면 아래와 같은 것들을 개발할 수 있을 것이다.
(생각나는 대로 적은 것이지만, 물론 더 많을 것이다.)
- 공장 내 현장 직원들이 AGV나 OHT, Conveyor, Stocker 등 장비들의 실시간의 상태와 데이터들을 보여주는 UI
- 관리자의 입맛에 맞게 공장마다의 현황을 요약적으로 보여주는 DashBoard
나는 그중에서도 AIMS(Advanced Information Monitoring System)라고 불리는 실시간 장비 모니터링 웹뷰를 만들었다.
리팩토링되어야할 부분이 많다고 생각은 하지만, C#으로 작성된 백엔드쪽 REST API와 쿼리문, Oracle DB의 데이터들을 확인하면서 유저(현장 직원분들)가 사용하는데 큰 불편함을 못 느끼는 정도론 개발했다고 생각한다.
이 개발 경험을 어떻게 더 디벨롭할 수 있을지는 고민해봐야겠지만, 실시간 데이터를 요청하면서 나타나는 무수한 리렌더링 횟수를 줄인 경험은 유의미 했다.
개선해야할 것
개선해야할 점은 많지만 태도와 개발습관으로 나눌 수 있을 것 같다.
- 다소 수동적인 태도
어렵다는 핑계로, 아키텍쳐나 컨트롤러 등 핵심적인 로직들을 이해하는데 시간을 쏟지 않아왔다.
당장 이직생각을 갖고 있진 않지만, 경력으로써 인정받을 수 있는 개발자가 도메인 이해가 덜됐다면 신뢰를 줄 수 있을까 의문이 든다.
=> 최소한 앞으로 맡게될 프로젝트에 있어서는 백엔드 로직도 최대한 이해해서 누군가에게 설명할 수 있게 코드를 봐버릇해야겠단 필요성을 느낀다. - 테스트 코드의 부재 + 일관성 없는 코드
지금은 C#으로 간단한 REST API를 만들기도 하지만, 가슴에 손을 얹고 얘기해보자면 "DB에 데이터가 없어요", "API가 아직 없어요"라는 핑계로 바로 개발하지 않았던 때가 있었다.
그리고 혼자 코드를 짠다고, 함수를 어느 때는 선언식으로 적었다가 어느 때는 표현식으로 적는다거나, 정의부와 훅들과 핸들러들이 보기 좋지 않게 흩어져있던 부분들이 있다.
=> TDD는 예외처리를 제대로 한다는 점에서 습관을 들일 필요성을 느끼고, 코드를 짤 땐 의도적으로 컨벤션과 스케폴딩을 고려하며 가독성을 개선하며 코드를 짜야겠다.
적다보니 장황해졌는데,
'이건 내 역할이 아니다'라는 생각보단 '이 문제는 어떻게 해결해야하는 것일까'를 스스로 되뇌이는 습관을 들여야겠다.
이런 마인드로 임하다 보면, 언젠간 빛을 발하지 않겠는가?
