기계공학에서 풀스택 개발자로: 물리적 시스템이 내 코드에 불어넣은 원칙

제 기술적 여정은 자바스크립트 프레임워크나 관계형 데이터베이스에서 시작되지 않았습니다. 2018년, 저는 Fabtech Technical Campus의 실습실에서 버니어 캘리퍼스와 마이크로미터를 손에 쥐고 강철 부품의 치수를 100분의 1밀리미터 단위로 측정하고 있었습니다. 그 후 판다르푸르의 SVERI 공과대학에서 기계공학을 공부하던 시절 제 일상은 열역학, 유체역학, 재료역학, 기계요소설계 공식으로 가득 차 있었습니다.

그 당시에는 기계공학과 소프트웨어 개발이 완전히 다른 별개의 세상처럼 느껴졌습니다. 하나는 질량, 마찰, 열, 강철 기어를 다루는 학문이었고, 다른 하나는 추상적인 텍스트, 메모리 힙, 브라우저 DOM 트리를 다루는 영역이었기 때문입니다.

하지만 풀스택 웹 개발과 UI/UX 디자인의 세계로 본격적으로 뛰어들었을 때, 저는 기계공학을 통해 소프트웨어 개발에서 가장 중요한 자산을 이미 배웠다는 사실을 깨달았습니다. 바로 **「현실적인 물리적 제약 속에서의 시스템 사고」**였습니다.

기계의 ’공차’와 소프트웨어의 ‘상태 관리’

제조 현장에서 수학적으로 오차 없는 완벽한 치수란 존재하지 않습니다. 지름 25.00mm의 축을 25.02mm의 베어링에 결합하려면 반드시 허용 오차(공차)를 정해주어야 합니다(+0.01mm / -0.00mm 처럼). 금속을 너무 많이 깎아내면 유격이 생겨 회전할 때 기계가 진동하며 파손되고, 너무 적게 깎으면 열팽창으로 부품이 맞물려 타버립니다.

TypeScript와 React로 프론트엔드 코드를 작성하기 시작했을 때, 저는 정확히 똑같은 원리를 발견했습니다. 소프트웨어에서 공차란 곧 엄격한 타입 정의, 입력값 유효성 검사, 상태의 경계선입니다.

• API 응답이 배열 대신 null을 반환했을 때, 화면이 정갈한 빈 상태를 보여주는가 아니면 처리되지 않은 예외로 백지화되며 터지는가?
• 사용자가 예상치 못한 문자를 입력하거나 0.05초 만에 버튼을 연타했을 때, 상태 머신이 그 진동을 견뎌내는가 아니면 데이터가 꼬이는가?

기계공학의 훈련은 제가 ’정상 동작(Happy Path)’만 기대하며 안일하게 코딩하는 습관을 완전히 없애주었습니다. 물리적 세계에서 물체는 항상 흔들리고, 열을 받고, 마모됩니다. 웹 환경에서도 네트워크는 끊기고, 서버 응답은 늦어지며, 사용자는 엉뚱한 행동을 합니다. 실패할 수 있는 최악의 시나리오를 대비해 코드를 짜는 것은 유난스러운 걱정이 아니라 엔지니어로서 당연히 지켜야 할 최소한의 기본기입니다.

응력 집중과 성능 병목 현상

재료역학에서 배우는 핵심 개념 중 하나는 **「응력 집중(Stress Concentration)」**입니다. 인장력을 받는 강철 보에 90도 각도의 직각 홈을 파내면, 힘의 흐름이 그 뾰족한 모서리에 극단적으로 쏠리면서 피로 균열이 시작됩니다. 노련한 설계자는 언제나 모서리를 둥글게 굴리는 라운딩(Fillet) 처리를 통해 힘을 고르게 분산시킵니다.

웹 브라우저의 실행 환경에도 똑같은 응력 집중이 존재하며, 그 지점은 바로 메인 스레드입니다.

[메인 스레드] -> 무거운 파싱 연산 -> 동기적 DOM 조작 -> 강제 리플로우 -> 화면 끊김

LS PDF와 LS Image Compressor를 만들 때, 수십 메가바이트의 파일을 메인 스레드에서 그대로 처리하는 것은 강철 보에 날카로운 홈을 파는 것과 같았습니다. 브라우저 탭이 굳어버리고, 버튼 클릭이 씹히며, 화면이 덜컹거렸습니다.

이 힘의 집중을 완화하는 라운딩 작업은 다음과 같았습니다:

1. 무거운 연산을 화면 렌더링과 분리하기 위해 Web Workers를 도입.
2. 동기적인 반복 연산을 requestIdleCallback이나 비동기 제너레이터로 작게 쪼개어 배치.
3. 대용량 바이너리 파일을 다룰 때 가비지 컬렉터의 부담을 줄이기 위해 Uint8Array 등 타입화 배열을 전면 활용.

CPU 사이클과 화면 주사율에 따른 프레임 시간은 무한하지 않은 유한한 자원이라는 점을 깨닫는 순간, 웹 성능 최적화는 감이 아닌 정밀한 설계의 영역이 됩니다.

기계 조립품과 소프트웨어 컴포넌트 아키텍처

감속기를 설계할 때 통짜 쇠붙이 하나를 깎아서 만들지 않습니다. 기어, 회전축, 키 홈, 베어링, 하우징을 각각 독립된 표준 부품으로 설계하고 정확한 접합부로 조립합니다. 기어 이빨 하나가 부러지면 기어만 갈아 끼우면 될 뿐, 기계 전체를 버리지 않습니다.

저는 LadeStack과 다국어 Astro 포트폴리오를 설계할 때도 컴포넌트를 기계 부품처럼 다룹니다:

• 명확한 인터페이스 경계: 컴포넌트는 자신이 맡은 일에 필요한 최소한의 정보만 알아야 합니다. 무분별한 전역 상태 공유는 축에 베어링을 아예 용접해버리는 것과 다름없습니다.
• 예측 가능한 모듈성: 하나의 유틸리티 함수나 UI 요소를 수정하더라도 주변 시스템에 예기치 못한 충격을 주지 않아야 합니다.
• 기교보다는 유지보수성: 가장 훌륭한 기계는 어디서나 구할 수 있는 스패너 하나로 분해하고 고칠 수 있는 기계입니다. 가장 훌륭한 코드 역시 6개월 뒤 다른 사람이 읽고 쉽게 고칠 수 있는 코드입니다.

엔지니어링과 디자인을 하나로 묶는 시각

많은 사람들이 엔지니어링과 UI/UX 디자인을 논리와 감성이라는 상반된 분야로 생각합니다. 하지만 제 생각은 다릅니다.

좋은 디자인이란 인간의 인지적 특성과 심리를 배려한 정밀한 공학입니다. 선반 기계의 안전 레버가 조작하기 쉬운 위치에 있어야 하고 눈금이 명확해야 하듯, 디지털 화면 역시 직관적인 타이포그래피 위계, 키보드 접근성, 합리적인 기본값, 명확한 오류 안내를 갖추어야 합니다.

판다르푸르의 기계 실습실에서 시작해 푸네에서 풀스택 소프트웨어를 만들고 있는 지금까지, 다루는 도구만 바뀌었을 뿐 본질은 같습니다. 시스템의 작동 원리를 깊이 이해하고, 플랫폼의 한계를 존중하며, 불필요한 마찰을 줄여 누구나 믿고 쓸 수 있는 단단한 도구를 만드는 것. 그것이 제가 코드를 대하는 변함없는 태도입니다.