내가 코드를 주기적으로 다시보는 이유

첫 커리어, 특이한 도메인 경험 제 첫 커리어는 약 4년 전, 디지털트윈을 산업현장에 접목시켜 소프트웨어를 만들어 납품하는 기업에서 시작했습니다. 당시 KAI(한국항공우주), UIPA(울산정보산업진흥원)같은 공공기관과 주로 협업하였고 이들이 요청한 산업 환경을 3D로 구현하여 현장의 위험요소나 특정 설비의 결함이나 배터리 부족 등 특수 상황을 감지하여 관리자가 현장 전반 상황을 컨트롤 할 수 있게하는 서비스를 만들었습니다. 3년도 더 지난 일을 회고해볼까하는 이유는 첫 회사가 했던 일이 워낙 유니크한 도메인이기도 했고, 입사하기 이전부터 고착화되어 있던 보일러플레이트를 개선하여 주니어로서 커리어 처음으로 프론트엔드 팀 코드베이스에 기여한 것 이 아직 기억에 남기 때문입니다. 무엇이든 처음이 가장 기억에 남는 것 같네요 ㅎㅎ 그리고 이때의 경험으로 코드베이스를 주기적으로 다시 보게 되는 습관이 들었거든요. 제가 처음으로 담당하여 맡았던 일인 UIPA라는 기관이 주관하는 선박 모니터링 프로젝트 중 있었던 일입니다. 보일러 플레이트와 새로운 시선 1) UIPA 프로젝트의 내용 선박 연료탱크에 연료가 얼마나 남았는지, 부품의 배터리가 얼마 남았는지, 물탱크 수위, 증기기관의 열 온도가 안정적인지, 선체의 기울기, 경도 위도 등등 전반적인 선박의 운항 상태를 모니터링하기 위해 웹으로 대시보드를 띄워줘야 했습니다. 2) 보일러플레이트의 구조 기관의 수주를 받아 작업을 진행하게 되면 프론트엔드 팀에서는 메인 페이지에 iframe으로 별도 페이지를 하나 더 띄우고, 주기적으로 백엔드로부터 데이터를 받는다 SignalR 이라고 하는 C# 생태계의 소켓 통신방식으로 웹에 1분마다 주기적으로 데이터를 공급합니다. 그리고 3D 팀이 넘겨준 Unity 3D 빌드파일을 이 iframe에 WebGL 라이브러리로 렌더링한다. Unity가 웹에 렌더링되고 유저가 3D 요소를 클릭하면 그 요소의 id 정보를 iframe으로 보낸다. iframe은 이 id 정보를 받아 메인 페이지로 전송(postMessage)한다. 메인 페이지는 iframe이 보낸 id를 받아 공급받은 데이터셋에서 찾아서 위젯 UI로 띄운다. 구조의 굳어진 보일러 플레이트로 작업을 진행했었는데요. 보시듯 iframe이 플로우 중간중간마다 끼어 브릿지 역할을 하고 있습니다. 결론부터 얘기하자면 입사초기부터 iframe의 존재 이유에 의문이 있어서 제거를 건의하였고, 컨펌받아 평균적으로 1200줄 이상 쓰이던 iframe 레이어 없이 구현할 수 있었습니다. 다른 프로젝트였던 KAI에서 이 iframe 레이어를 위해 작성되었던 코드 라인이 1200~1300줄이었던 것을 기준으로 하였습니다. 3) 보일러플레이트의 개선 리더분 말씀으로는 예전에 모종의 이유가 있어 iframe로 감싸는 형태로 만들었는데 지금은 그냥 이 형태가 룰처럼 굳어져와서 계속 사용하고 있다고 하셨습니다. iframe을 유지해야 할 마땅한 근거도 없고, 코드 가독성과 유지보수의 확실한 개선이 예상되어 PoC 진행을 컨펌받아 동작이상 없음을 증명하였고, 이 UIPA 프로젝트에서 적용하여 iframe 없는 구조를 완성하였습니다. 즉, 메인 페이지에 Unity 3D 빌드파일을 WebGL 라이브러리를 통해 렌더링한다. Unity가 웹에 렌더링되고 유저가 3D 요소를 클릭하면 그 요소의 id 정보를 메인 페이지로 보낸다. 메인 페이지는 이 id 정보를 받아 공급받은 데이터셋에서 찾아서 위젯 UI로 띄운다. 로 전체 플로우에서 2개의 단계가 제거된 것을 볼 수 있습니다. 새로운 시선으로 보려고 하는 이유 이렇게 커리어의 첫 프로젝트에서 새로운 관점을 통한 개선이 만족스러웠다보니 그 이후부터, 제가 지금 다니는 회사의 프론트엔드 리더는 아니지만 새로운 인력의 온보딩에 참여할 기회가 생기면 주로 저희 코드베이스의 개선점을 묻곤 합니다. 아무래도 재직한지 3년이 다 되어가는 저같이 고인(?) 사람보다는 새로운 동료가 본인이 최근까지 겪어왔던 색다른 관점에서 평가나 제안을 할 수 있기 때문이지요. 실제로 저는 지금 다니고 있는 회사의 온보딩 시기에 질문상세 페이지를 SSR로 구성하면서 Promise.all로 5개 정도의 API를 페칭 중이었는데, 그 중 정말 코어 데이터는 2개 정도에 불과했기에 설령 다른 것들이 문제가 발생해도 에러를 내지 않게끔 Promise.allSettled로 바꾸자는 제안을 하여 런타임 안정성에 기여했습니다. 또 작년에 새로 조인하신 분은 온보딩 시 Smart App Banner라는 생각도 못하고 있었던 부분을 제안해주셔서 웹에서 앱으로 인입시키는 기점을 마련해주기도 하셨습니다. 위 작업들이 인상깊었던 것은 모두 코드 10줄 미만의 어렵지 않은 사소한 변경임에 비해 임팩트가 있었다는 점입니다. 조직이 고착화되지 않으려면 이러한 환기가 참 중요하다고 생각됩니다. 그렇다고 매번 새로운 동료를 모실 순 없으니 저는 주기적으로 코드베이스를 한번씩 훑어보곤 합니다. 몇달 몇년간 있었던 코드지만 간혹 새롭거나 의아하게 느껴지는 부분이 있거든요. 그렇게 발견했던 것이 대표적으로 meta keyword입니다. 꽤 오래전부터 SEO에 유의미하지 않은데에도 여기에 API까지 붙여서 성심껏 구성하고 있었었죠. 처음 코드를 짠 사람도, 그 뒤로 손댄 사람도 'meta 태그니까 SEO에 좋겠지'라는 전제하에 의심을 하지 않았던 겁니다. 저 역시도 몇 달간 그 코드를 지나치고 못 봤었구요. 코드가 잘 굴러가기 때문에 보지 않게 됨으로서 발생하는 허점을 예방하고자 저는 주기적으로 코드를 다시 들여다봅니다. 첫 직장에서 iframe을 의심했던 그때처럼요