즐거운 사람과 컴퓨터 즐거운 사람과 컴퓨터

최근 "모노레포 절망편, 14개 레포로 부활하기까지 걸린 1년"이라는 글을 봤습니다. (링크)한 기업이 비대해진 모노레포의 복잡성을 감당하지 못하고, 14개의 폴리레포(Polyrepo)로 서비스를 분리하며 안정성을 되찾았다는 일종의 '탈출기'입니다. 많은 분들이 이 글을 보고 "역시 모노레포는 어렵구나", "우리도 나누는 게 답인가?"라고 생각하셨을지 모릅니다.하지만 저는 이 사례를 조금 다른 시각, 아니 더 본질적인 엔지니어링 관점에서 바라보고 싶습니다.과연 그들이 겪은 고통의 원인이 '모노레포라는 아키텍처' 때문이었을까요? 제가 보기엔 '테스트와 경계(Boundary)라는 기본기의 부재'가 진짜 원인으로 보입니다.1. "Product Stock Checker"가 말해주는 진실원문에 등장하는 실패 사례..