2주짜리 스프린트에서 검색 기능 개선 작업을 맡았다. 기획도 꼼꼼했고, 디자인도 미리 나왔고, 일정도 여유로웠다. 천천히 설계하고, 꼼꼼히 구현하고, 테스트도 충분히 작성했다. 2주가 끝나자 검색 속도가 20% 빨라졌고, 필터 UI도 깔끔해졌다. 나름 만족스러운 결과였다.

같은 달, 회사 해커톤이 열렸다. 24시간 안에 뭔가를 만들어야 했다. 나는 같은 팀 동기 둘과 함께 "사내 기술 블로그 추천 시스템"을 만들기로 했다. 24시간. 디자인 없음. 기획서 없음. 백엔드 경험자 없음(프론트엔드 개발자 셋이었다).

24시간 뒤에 나온 결과물은 못생겼다. 근데 동작했다. 사용자가 읽은 글 목록을 기반으로 다음에 읽을 글을 추천해주는 기능이 실제로 돌아갔다. 코드 품질은 형편없었지만, 핵심 가치는 확실히 전달됐다. 발표할 때 반응이 좋아서 실제 사내 서비스로 발전시키자는 이야기까지 나왔다.

2주 동안 여유롭게 만든 검색 기능 개선보다, 24시간 안에 급하게 만든 해커톤 프로젝트가 더 큰 임팩트를 냈다. 왜 이런 일이 벌어진 걸까.

파킨슨의 법칙#

파킨슨의 법칙이라는 게 있다. "업무는 주어진 시간을 채우기 위해 팽창한다." 2주가 주어지면 2주치 일을 만들어낸다. 2일이 주어지면 2일 안에 끝낼 수 있는 방법을 찾는다.

2주짜리 검색 기능 개선을 되돌아보면, 진짜 핵심 작업은 3-4일이면 끝날 수 있었다. 나머지 시간에 뭘 했나 생각해보면, 이미 잘 동작하는 코드를 "좀 더 깔끔하게" 리팩토링하고, 엣지 케이스 중에서도 거의 발생하지 않을 케이스를 처리하고, 컴포넌트 구조를 세 번이나 바꿨다. 시간이 있으니까 쓸 수 있는 데 쓴 거다. 결과물의 품질이 올라간 건 맞지만, 투자 시간 대비 효율은 형편없었다.

해커톤에서는 그럴 여유가 없었다. 24시간이라는 제약이 "뭐가 진짜 중요한가?"를 즉시 결정하게 만들었다. 추천 알고리즘을 만들 시간은 없으니까 간단한 키워드 매칭으로 갔다. 예쁜 UI를 만들 시간은 없으니까 기본 HTML에 최소한의 스타일만 입혔다. 인증 시스템을 구축할 시간은 없으니까 사내 SSO를 그대로 붙였다.

제약이 우선순위를 명확하게 해줬다.

Seth Godin이 말한 "출발선에 서기"#

Seth Godin이 흥미로운 비유를 한 적이 있다. "줄타기가 그냥 서 있는 것보다 쉽다. 전진하는 움직임이 안정감을 만든다." 완벽한 준비를 하고 출발하려는 사람보다, 불완전해도 일단 움직이기 시작한 사람이 더 안정적이라는 거다.

제약은 움직이게 만든다. 시간이 충분하면 "좀 더 조사해보고," "좀 더 설계를 다듬고," "좀 더 논의해보고"를 반복하다가 멈춰 선다. 시간이 없으면 일단 뛰어야 한다. 그리고 뛰기 시작하면 방향이 보인다.

Sivers도 비슷한 이야기를 했다. "Version 0.1부터 시작하라. 낮은 완성도로." 처음부터 완벽하게 만들려고 하면 아무것도 시작하지 못한다. 제약이 있으면 자연스럽게 0.1부터 시작할 수밖에 없다.

작은 팀이 더 빠른 이유#

인원 제약도 마찬가지다. 3명이서 할 수 있는 일과 10명이서 할 수 있는 일은 이론적으로 다르다. 근데 현실에서는 3명이 더 빨리 끝내는 경우가 많다.

전 회사에서 디자인 시스템을 만드는 프로젝트가 있었다. 처음에 7명이 투입됐다. 프론트엔드 4명, 디자이너 2명, PM 1명. 첫 2주를 온전히 회의에 썼다. 컴포넌트 네이밍 컨벤션을 정하는 데만 3일이 걸렸다. Button이냐 Btn이냐, Primary냐 Main이냐 같은 논쟁. 한 달이 지나도 실제로 만들어진 컴포넌트는 Button 하나뿐이었다.

결국 구조를 바꿨다. 프론트엔드 2명, 디자이너 1명, 총 3명으로 줄었다. 나머지는 다른 프로젝트로 갔다. 인원이 줄고 나니 회의가 줄었다. 회의가 줄고 나니 결정이 빨라졌다. 결정이 빨라지니 코드가 나왔다. 3명이서 두 달 만에 핵심 컴포넌트 15개를 만들었다. 7명일 때 한 달 동안 못 한 걸 3명이 해낸 거다.

사람이 많아지면 커뮤니케이션 비용이 지수적으로 증가한다는 건 이론적으로 알고 있었지만, 직접 겪으니까 체감이 달랐다. 3명이면 슬랙 메시지 하나로 결정할 수 있는 걸, 7명이면 미팅을 잡아야 한다. 미팅을 잡으려면 시간을 조율해야 하고, 미팅에서 모두의 의견을 들어야 하고, 결정 후에 불참한 사람에게 전달해야 한다. 이 오버헤드가 실제 작업 시간을 잡아먹는다.

기술적 제약이 가져다준 것들#

기술적 제약도 마찬가지 효과를 낸다.

한 번은 성능 최적화를 해야 하는데, 서버를 업그레이드할 수 없는 상황이 있었다. 예산 문제였다. 프론트엔드에서 할 수 있는 것만으로 해결해야 했다. 이 제약이 없었으면 "서버 스펙 올리면 되지"로 끝났을 거다.

근데 서버를 못 건드리니까 프론트엔드에서 할 수 있는 모든 최적화를 다 찾아봐야 했다. 이미지 레이지 로딩, 번들 사이즈 최적화, API 호출 캐싱, 가상 스크롤 적용. 이것들을 전부 적용하고 나니 서버 업그레이드 없이도 원래 목표치를 달성했다. 그리고 여기서 배운 최적화 기법들은 이후 다른 프로젝트에서도 계속 써먹었다.

서버 업그레이드가 가능했으면 프론트엔드 최적화를 이렇게까지 깊이 파지 않았을 거다. 쉬운 길이 막혀 있었기 때문에 어려운 길에서 더 많은 걸 배웠다.

또 다른 사례. 번들 사이즈를 200KB 이하로 줄여야 하는 프로젝트가 있었다. 모바일 환경 타겟이라 네트워크가 느린 사용자를 고려해야 했다. 이 제약 때문에 서드파티 라이브러리를 거의 쓸 수 없었다. moment.js 대신 date-fns의 필요한 함수만, lodash 대신 직접 유틸리티 작성, 차트 라이브러리 대신 SVG 직접 그리기.

불편했다. 근데 결과적으로 의존성이 적은, 가벼운, 그리고 우리가 모든 코드를 이해하고 있는 프로젝트가 됐다. 라이브러리 업데이트 때문에 깨지는 일도 없고, 번들 분석에서 "이건 뭐지?" 하는 미지의 코드도 없었다.

제약을 인위적으로 만드는 방법#

제약이 좋다고 해서 항상 자연스럽게 주어지진 않는다. 그래서 인위적으로 만드는 것도 방법이다.

내가 쓰는 방법 몇 가지.

시간 제한. 설계 시간을 무한정 주지 않는다. "이 기능의 설계를 2시간 안에 끝낸다"고 정한다. 2시간이 지나면 그 시점의 설계로 시작한다. 완벽하지 않아도 된다. 구현하면서 바뀔 거니까.

도구 제한. 사이드 프로젝트에서는 의도적으로 라이브러리를 최소화한다. "React와 CSS만으로 만들어보자." 이런 제약이 오히려 기본기를 단련시켜준다. 라이브러리 없이 드래그 앤 드롭을 구현해보면, 그다음에 라이브러리를 쓸 때 내부 동작이 보인다.

범위 제한. 기능 하나를 만들 때 "v1에는 이 세 가지만 포함한다"를 먼저 정한다. 나머지는 v2에서. 세 가지를 정하는 행위 자체가 우선순위를 명확하게 한다. 뭐가 핵심이고 뭐가 부가인지 구분하는 연습이다.

피드백 주기 제한. 3일 안에 사용자한테 보여줄 수 있는 수준으로 만든다. 3일이면 완벽하게 못 만들지만, 핵심 동작은 보여줄 수 있다. 빠른 피드백이 방향을 잡아준다.

제약이 답이 아닌 경우#

물론 모든 제약이 생산적인 건 아니다. 구분이 필요하다.

좋은 제약은 "무엇을 할지"를 명확하게 해준다. 시간이 없으니까 핵심에 집중한다. 도구가 제한되니까 기본에 집중한다.

나쁜 제약은 "어떻게 할지"를 불가능하게 만든다. 기술 부채가 너무 심해서 새 기능 추가가 물리적으로 안 된다. 팀원이 너무 적어서 운영과 개발을 동시에 할 수 없다. 이건 제약이 아니라 장애물이다.

둘을 구분하는 기준은 간단하다. "이 제약 안에서 의미 있는 결과물을 낼 수 있는가?" 답이 yes면 좋은 제약이다. 답이 no면 제약을 완화하거나 범위를 더 줄여야 한다.

한 번은 PM이 2일 안에 결제 시스템 전체를 새로 만들어달라고 한 적이 있다. 이건 좋은 제약이 아니라 불가능한 요구다. 이때는 범위를 줄여야 한다. "2일 안에 결제 수단 추가 기능만 먼저 만들고, 나머지는 다음 스프린트에 하겠다." 제약을 받아들이되, 범위를 협상하는 거다.

개인 프로젝트에서의 제약 실험#

이론만 말하면 와닿지 않으니까, 실제로 내가 제약을 걸고 사이드 프로젝트를 했던 경험을 하나 더 이야기하겠다.

작년에 포트폴리오 사이트를 새로 만들기로 했다. 보통이면 기술 스택 고르는 데만 일주일은 쓰는 성격인데, 이번엔 규칙을 정했다. "Next.js, Tailwind CSS, Vercel. 이 세 개만. 다른 라이브러리 금지. 일주일 안에 배포."

처음 3일은 불편했다. 애니메이션을 넣고 싶은데 Framer Motion을 못 쓰니까 CSS transition으로 해야 했다. 다크 모드 토글을 만들고 싶은데 별도 라이브러리 없이 CSS 변수로 직접 구현해야 했다. 마크다운 렌더링도 직접 파싱하는 대신 Next.js의 MDX 지원만으로 해결했다.

근데 일주일 뒤에 나온 결과물이 이전 포트폴리오보다 낫다고 느꼈다. 왜냐하면 라이브러리에 의존하지 않으니까 번들 사이즈가 작았고, 직접 구현한 것들이라 커스터마이징이 자유로웠고, 무엇보다 프로젝트 전체를 내가 완전히 이해하고 있었다. 라이브러리 블랙박스가 없었다.

Sivers의 "hell yeah or no" 원칙이 여기서도 통했다. 기능을 추가할 때 "이거 진짜 필요한가?"를 반복해서 물었고, 대부분의 답은 no였다. 결과적으로 페이지 3개, 블로그 기능, 프로젝트 목록. 그게 전부인데, 그게 전부여서 좋았다.

무한한 자유는 무한한 불안이다#

돌이켜보면, 가장 힘들었던 프로젝트는 제약이 많았던 프로젝트가 아니라 제약이 없었던 프로젝트였다. "자유롭게 만들어주세요"라는 말은 듣기 좋지만, 실제로는 가장 어려운 요구사항이다. 방향이 없으니까. 뭐부터 해야 할지 모르니까. 선택지가 무한하면 선택 자체가 스트레스다.

반면, "이 API로, 이 디자인 시안대로, 다음 주 수요일까지 만들어주세요"는 명확하다. 뭘 해야 하는지 알고, 어디까지 해야 하는지 안다. 그 안에서 어떻게 할지만 결정하면 된다. 그 "어떻게"를 고민하는 과정에서 창의성이 나온다.

제약은 적이 아니다. 제약은 울타리다. 울타리가 있어야 그 안에서 마음껏 뛰어놀 수 있다. 울타리 없는 넓은 벌판에서는 어디로 가야 할지 몰라 서성이게 된다.

그러니까 제약이 주어지면 불평하기 전에 한 번 생각해보자. 이 제약이 나한테 뭘 명확하게 해주는지. 어쩌면 그 제약 덕분에 더 좋은 결과물이 나올 수도 있다.