앱 17개와 웹 서비스 3개를 만들며 배운 것: 작업 기억을 지켜야 했다

앱 17개와 웹 서비스 3개를 만들면서 가장 크게 느낀 문제는 코드의 양이 아니었다. 인지적 단절(cognitive discontinuity)과 작업 기억의 과부하였다.

프로젝트가 많아질수록 나는 단순히 저장소를 더 많이 관리하는 것이 아니었다. 서로 다른 실행 명령, 배포 방식, 계정 상태, 사용자 흐름, 미완료 결정을 동시에 기억해야 했다. 한 프로젝트에서 막힌 이유를 정리하기도 전에 다른 서비스의 장애나 출시 요청으로 이동하면, 다시 돌아왔을 때 코드보다 먼저 맥락을 복구해야 했다.

숫자가 커질수록 어려워진 것은 구현이 아니었다

처음에는 제품을 많이 만들면 비슷한 기능을 재사용할 수 있어 효율이 올라갈 것이라고 생각했다. 실제로 공통 컴포넌트와 배포 스크립트는 반복 작업을 줄여 주었다. 하지만 재사용 가능한 코드가 늘어도 프로젝트마다 달라지는 질문은 남았다.

• 이 서비스의 현재 배포 상태는 무엇인가
• 마지막으로 어디까지 확인했는가
• 지금 보고 있는 오류는 코드 문제인가, 외부 서비스 문제인가
• 다음에 돌아왔을 때 가장 먼저 해야 할 일은 무엇인가

이 정보가 한 화면이나 한 문서에 모여 있지 않으면, 작업을 다시 시작하는 데 시간이 든다. 저장소를 열 수 있는 것과 작업을 바로 이어 갈 수 있는 것은 다른 문제였다.

인지적 단절은 작은 이동에서 생겼다

인지적 단절은 큰 장애 한 번으로만 생기지 않았다. 다음과 같은 짧은 이동이 반복될 때 더 크게 쌓였다.

모바일 앱 수정 → 웹 서비스 배포 확인 → API 로그 확인 → 다른 앱의 스토어 상태 확인

각 작업은 따로 보면 어렵지 않았다. 문제는 이동할 때마다 머릿속의 실행 모델을 바꿔야 한다는 점이었다. 어떤 프로젝트는 pnpm 명령으로 시작하고, 어떤 프로젝트는 다른 워크스페이스나 별도 런타임이 필요했다. 한쪽은 사용자가 업데이트해야 결과가 보이고, 다른 쪽은 배포 즉시 다음 요청에 반영됐다.

이런 차이를 기억하는 동안 실제 기능에 대한 생각할 공간이 줄었다. 개발자의 집중력이 부족해서가 아니라, 시스템이 계속 전환을 요구하고 있었던 것이다.

작업 기억이 감당해야 했던 것들

작업 기억의 과부하는 “할 일이 많다”는 말보다 구체적이었다. 한 번에 다음 항목을 붙잡고 있어야 했다.

기억해야 했던 것	놓치면 생기는 문제
현재 프로젝트와 작업 브랜치	엉뚱한 저장소를 수정하거나 변경 위치를 다시 찾음
마지막으로 검증한 범위	완료되지 않은 일을 완료로 착각함
실행 중인 서버와 환경 변수	이미 실행 중인 프로세스를 다시 띄우거나 잘못된 환경을 확인함
앱·웹·API의 배포 시점	최신 코드와 사용자가 보는 버전을 혼동함
다음 행동과 보류한 판단	같은 탐색을 반복하고 결정을 다시 내림

특히 에이전트와 함께 개발할 때는 “무엇을 시켰는가”보다 “무엇이 실제로 바뀌었고 무엇을 확인했는가”를 다시 읽어야 했다. 생성 속도가 빨라도 검토할 맥락이 분산되어 있으면 전체 작업은 빨라지지 않았다.

내가 실제로 줄이려 한 것은 도구 수가 아니라 전환 수였다

문제를 해결하려고 새로운 도구를 계속 추가하면 처음에는 편해 보인다. 하지만 도구마다 프로젝트 목록, 세션 상태, 단축키, 저장 방식이 달라지면 또 다른 학습 비용이 생긴다.

그래서 기준을 바꿨다. “더 많은 것을 할 수 있는 도구인가?”보다 다음을 먼저 물었다.

1. 작업을 시작할 때 현재 상태를 바로 알 수 있는가
2. 코드를 읽고 직접 수정하는 흐름이 끊기지 않는가
3. 중단할 때 다음 행동을 남길 수 있는가
4. 다른 프로젝트로 갔다가 돌아왔을 때 맥락을 복구하기 쉬운가
5. 모바일이나 원격 환경에서도 최소한의 확인과 재개가 가능한가

이 기준은 이후 AI 개발 도구를 비교할 때도 그대로 이어졌다. 프로젝트를 닫는 기능까지 보는 이유에서 정리한 것처럼, 생성 화면의 인상보다 시작·검토·중단·복귀의 비용이 더 오래 남았다.

작업 맥락을 작게 만드는 운영 규칙

완벽한 기억 시스템을 만들려고 하지 않고, 기억해야 할 양을 줄이는 쪽을 택했다.

1. 프로젝트마다 현재 상태를 한 문장으로 남긴다

“개발 중”은 상태가 아니다. “로그인 콜백은 구현했고, 기존 계정으로 재진입하는 경우만 검증하지 않았다”처럼 다음 행동이 드러나야 한다. 이 문장은 세션을 닫기 전에 갱신한다.

2. 변경과 검증을 같은 기록에 둔다

파일을 수정했다는 기록만으로는 부족하다. 실행한 명령, 확인한 화면, 아직 확인하지 못한 경로를 함께 남겨야 다음 사람이 아니라 다음 세션의 내가 믿을 수 있다.

3. 동시에 깊게 보는 프로젝트 수를 제한한다

모든 프로젝트를 계속 열어 두는 것은 병렬성이 아니라 열린 루프의 증가일 수 있다. 읽기 전용 확인과 실제 변경 작업을 구분하고, 한 번에 깊게 수정하는 프로젝트 수를 줄이는 편이 집중을 지키는 데 도움이 됐다.

4. 공통 규칙과 프로젝트 규칙을 나눈다

모든 작업에 필요한 원칙과 특정 저장소에서만 필요한 명령을 한 문서에 섞지 않는다. 공통 지침은 짧게 유지하고, 배포·테스트·도메인 규칙은 프로젝트 가까이에 둔다. 그래야 필요한 맥락만 가져올 수 있다.

많이 만드는 능력보다 다시 들어가는 능력

앱 17개와 웹 서비스 3개라는 숫자는 만든 결과를 보여 주지만, 지속 가능한 개발 방식을 보장하지는 않는다. 제품이 늘어날수록 중요한 것은 더 많은 일을 기억하는 능력이 아니라, 기억하지 않아도 다시 시작할 수 있는 구조를 만드는 능력이다.

내가 지금 가장 중요하게 보는 개발 환경의 조건은 화려한 기능이 아니다. 작업을 시작할 때 맥락을 덜 복구하고, 검토할 때 변경 범위를 분명히 보고, 중단할 때 다음 행동을 남기고, 다른 기기에서 최소한의 상태를 이어 갈 수 있는가이다.

결국 생산성을 높인다는 것은 내 머릿속에 더 많은 프로젝트를 넣는 일이 아니었다. 머릿속에 넣어 두지 않아도 되는 것을 시스템 밖으로 꺼내는 일에 가까웠다.