"최신 기술 떡칠하다 프로젝트 터트리기 전, '단순 무식' 아키텍처로 생존하는 법"

솔직히 말해서, 며칠 전 뉴스를 보고 씁쓸함을 감출 수 없었습니다. '로봇 청소기의 대명사' 아이로봇(iRobot)이 파산을 선언했다더군요. 결국 중국 기업에 넘어갔답니다. 경영진의 판단 미스니, 규제 때문이니 말들이 많지만, 테크니컬 PM인 제 눈에 들어온 건 딱 하나였습니다. "우리가 '근본'을 잊어버렸구나."

오늘 이야기는 단순히 로봇 회사가 망한 얘기가 아닙니다. 매일 아침 스탠드업 미팅에서 "이번엔 MSA로 가시죠", "AI 모델 도입 필수입니다"를 외치는 우리네 개발 현장의 오버 엔지니어링(Over-engineering) 에 대한 뼈 아픈 경고입니다.

1. 200달러짜리 '멍청한' 기계가 4천만 대를 판 비결

2002년, 오리지널 룸바가 처음 나왔을 때를 기억하나요? (아, 여러분은 너무 어리려나) 그 기계는 정말 단순했습니다.

• 가격: 단돈 200달러.
• 기능: 전원 켜면 바닥을 쓸고 다님. 끝.
• 지능: 없음. 지도(Map)도 못 그림.

그런데 이게 4천만 대나 팔렸습니다. 비결은 '완벽함'이 아니라 '적당함' 에 있었습니다. 당시 산업용 로봇은 완벽하게 통제된 환경에서만 작동하는 고가의 장비였습니다. 하지만 가정집은 어떤가요? 양말 굴러다니고, 의자 위치 바뀌고 난장판이죠. 룸바는 여기서 '지도'를 그리려 애쓰는 대신, 그냥 무식하게 돌아다니는 방식을 택했습니다.

💡 핵심은 생존 본능
룸바는 메모리가 부족해서 방 구조를 기억조차 못 했습니다. 대신 장애물을 만나면 후진하고, 회전하고, 다시 박아보는 '행동(Behavior)' 패턴만 가지고 있었죠. 비효율적으로 보이나요? 하지만 결과적으로 방은 깨끗해졌습니다.

2. 'Behavior-Based Robotics': 벌레에게 배워라

이 설계 철학은 MIT의 로드니 브룩스 교수가 제안한 행동 기반 로보틱스에서 나왔습니다. 이 개념은 우리 개발자들에게 시사하는 바가 큽니다.

대부분의 주니어 개발자나 이상주의적인 기획자들은 이렇게 사고합니다:

1. Sense: 센서로 데이터를 몽땅 수집한다.
2. Model: 완벽한 가상 세계 모델을 만든다.
3. Plan: 최적의 경로를 계산한다.
4. Act: 실행한다.

이 방식은 연구실(Localhost)에서는 멋지지만, 현실(Production)에서는 센서 노이즈, 네트워크 지연, 예외 케이스 때문에 박살 납니다.

반면, 룸바의 방식은 곤충(Insect)과 같습니다:

• Sense → Act: "왼쪽이 밝다? 왼쪽 바퀴 굴려." "절벽이다? 멈춰."

중앙 제어 시스템이 모든 걸 통제하는 게 아니라, 각 부품이 독립적인 생존 본능을 가집니다. 브러시 하나가 고장 나도 나머지 기능으로 어떻게든 청소를 끝냅니다. 이게 바로 결함 허용(Fault Tolerance) 시스템의 정수입니다.

3. 우리가 저지르는 '현대판 실수'

그런데 지금의 로봇 청소기, 그리고 우리의 소프트웨어는 어떤가요?
아이로봇의 후기 모델과 경쟁사 제품들을 보세요.

• vSLAM으로 정밀 지도 작성
• 클라우드 연동 및 앱 제어
• 고화질 카메라와 사물 인식 AI

기능은 화려해졌지만, 본질인 '청소'보다 부가 기능이 더 무거워졌습니다. 배터리는 빨리 닳고, 네트워크 끊기면 바보가 되고, 가격은 치솟았죠. 비즈니스 로직은 청소인데, 기술 스택 자랑하느라 제품이 비대해진 꼴입니다.

🛑 생존을 위한 액션 아이템

여러분이 지금 맡고 있는 프로젝트가 삐걱거린다면, 혹시 '최신 기술 뽕'에 취해 있는 건 아닌지 자가 진단해보세요.

1. 화려한 아키텍처보다 '목적'에 집중하세요.
   고객이 원하는 건 '바닥이 깨끗해지는 것'이지, 우리 로봇이 vSLAM 알고리즘을 쓴다는 사실이 아닙니다. 쇼핑몰 검색 기능에 벡터 DB부터 붙이려 하지 말고, LIKE 쿼리로 해결되는지 먼저 보세요.
2. 부품이 썩어도 돌아가게 만드세요.
   룸바는 브러시가 망가져도 진공 흡입으로 청소를 마쳤습니다. 여러분의 서비스는 외부 API가 죽으면 메인 페이지가 500 에러를 뱉나요, 아니면 캐시 된 데이터라도 보여주나요? 우아한 실패(Graceful Degradation) 가 완벽한 성공보다 낫습니다.
3. MVP는 진짜 '최소'여야 합니다.
   핵심 기능(청소) 외에는 전부 짐(Debt)입니다. 리소스가 한정된 스타트업이나 TF팀일수록 '있어 보이는' 기능보다 '없으면 안 되는' 기능에 목숨 거세요.

마치며: 형이 꼰대 같아도 들어라

저도 압니다. Cursor나 Gemini 같은 최신 AI 툴 써서 코드 짜고 싶고, 최신 프레임워크 도입하고 싶은 욕심. 그거 개발자의 본능이죠. 하지만 회사는 연구소가 아닙니다.

오리지널 룸바가 우리에게 주는 교훈은 명확합니다. "가장 단순한 것이 가장 강하다."
내일 출근해서 동료가 "이거 구조 좀 더 복잡하게 짜야 하지 않을까요?"라고 묻는다면, 조용히 룸바 이야기를 해주세요. 우리는 곤충처럼 끈질기게 살아남는 코드를 짜야 하니까요.