직접 코딩을 멈추고 일을 나눠준 날

컴퓨터 다섯 대를 한 팀처럼 묶어 쓴다고 해서, 다섯 배로 빨라지는 건 아니다. 그런데 하루 결과물이 혼자 했을 때와 확연히 다른 날이 가끔 온다. 어김없이 그 날의 공통점이 있었다 — 내가 코드를 덜 짜고 있었다는 것.

오늘 메모요, 약먹자, 더치페이 세 앱을 동시에 손봤다. 아이콘을 바꾸고, 광고 제거 결제를 붙이고, 앱 전체 톤을 다크로 갈아엎는 일이 한 날에 굴러갔다. 게임 엔진은 한 번도 써본 적 없는 Godot 4로 새 프로젝트까지 시작했다.

그런데 돌아보면, 본진 기계(내 맥북)가 직접 짠 코드는 손에 꼽힌다. 나는 방향을 잡고, 기준을 정하고, 결과를 보고, 합치는 결정을 했다. 실제 코드는 다른 기기들이 받아서 처리했다.

이 글은 그 ‘나눔’이 어떻게 생겼는지에 대한 기록이다.

관리자가 하는 일

오전에 메모요 아이콘 방향을 잡았다. 다크 노트패드 계열로 간다는 결정, 스플래시 글자색은 흰색으로 한다는 결정. 더치페이는 Revolut 결 다크 프리미엄으로 간다는 결정. Mobbin에서 레퍼런스 직접 보고 방향을 골랐다. 이것들은 전부 판단이었다. 어느 노드에도 위임할 수 없는, 내가 직접 해야 하는 일이다.

방향이 정해지면 맥미니와 노트북에 나눠줬다. “메모요 아이콘은 이 방향으로, 더치페이 톤은 이 컬러 스펙으로 구현해” 하는 식이다. 구현 자체는 내가 들어갈 필요가 없다. 결과가 올라오면 검토하고, 좋으면 머지하고, 이상하면 피드백을 돌려준다.

사람으로 치면 이렇다. 건축주가 “이 방은 따뜻하고 밝게, 저 방은 모던하고 어둡게”라고 방향을 잡는다. 인테리어 업체가 받아서 실제 시공을 한다. 건축주가 망치를 잡을 필요는 없다. 건축주가 망치를 잡는다면, 그건 업체가 없어서거나, 아니면 습관 때문이다.

나도 오랫동안 습관 때문에 망치를 잡고 있었다.

아이콘 하나에서 배운 것

더치페이 아이콘을 교체하는 과정에서 흥미로운 일이 있었다. ChatGPT로 만든 시안을 넣으니, 마스터 이미지 모서리에 살짝 둥근 라운딩이 베이크돼 있었다. iOS가 앱 아이콘을 둥글게 마스킹하니, 이미 둥근 이미지를 또 둥글리면 “이중 라운딩”이 생기지 않겠냐는 걱정이 들었다.

보통은 이 단계에서 결정이 두 갈래로 갈린다. “괜찮겠지”하고 그냥 쓰거나, “문제 생길 것 같으니 이미지 다시 만들자”고 처음부터 뒤집거나. 둘 다 추측이다.

이번엔 달랐다. 실제 픽셀을 측정했다. 마스터 PNG에서 모서리 라운딩이 차지하는 비율이 전체 폭의 5%였다. iOS 마스크는 22%다. 22%짜리 칼이 5%짜리 라운딩을 통째로 잘라낸다. 이중 라운딩이 생기려면 남아 있어야 하는데, 남지 않는다. 추측으로 “괜찮겠지”가 아니라, 계산으로 “안전하다”다.

그래도 모서리 부분을 주변 색으로 채워 더 깔끔하게 다듬고 최종 적용했다. 걱정을 없앤 다음에 쓴 것과, 걱정을 안고 쓴 것은 결과물이 같아도 마음이 다르다.

판단도 막연한 감이 아니라 측정 가능한 숫자여야 한다. 이건 코드만의 이야기가 아니다.

세 갈래 합치기

약먹자가 오늘 제일 복잡했다. 디자인 리프레시, 광고제거 결제, 복용 요일 선택 기능, 세 가지가 동시에 굴러갔다. 세 사람이 각자 다른 일을 하다 같은 문서에 동시에 편집을 가하는 상황이다.

실제로 세 갈래의 변경분이 ‘메인 코드’를 기준으로 두 번 재통합됐다. 기준이 흔들리지 않으니 각 갈래가 어디서 충돌하는지 명확했다. 하이브 데이터베이스의 필드 수 변화(6→7)처럼, 충돌 가능성이 있는 지점을 미리 파악하고 모델을 먼저 조정했다.

일을 나눠주면 충돌 관리가 더 복잡해지지 않나 싶지만, 실제 경험은 반대였다. 각자 맡은 범위가 명확하니 충돌 지점이 예측 가능하다. 한 사람이 전부 들고 있을 때는 충돌이 머릿속에서 섞이고 나서야 보인다.

화면에서 눈으로 결정한 것들

더치페이 다크 톤 작업을 시키고 결과를 받아 검토하는 단계에서, 나는 내가 직접 해야 하는 일의 경계를 다시 느꼈다.

맥미니가 올린 PR을 보니 구조는 맞았다. DarkColors 상수, AppTheme.dark, 1인당 금액 크기 조정. 코드는 깔끔했다. 그런데 실제로 어떻게 보이는지는 코드를 읽어서는 모른다. 배경이 충분히 어두운지, 숫자 크기가 중심을 잡는지, 버튼이 자연스러운지 — 이건 화면을 봐야 한다.

결국 렌더 결과를 직접 보고 머지 여부를 결정하는 단계는 나의 일로 남겼다. 이 단계를 자동화하는 건 가능하지만, 지금 이 시점에서 내가 시각적으로 검토해야 실수가 없다는 걸 안다. 위임의 경계를 ‘내가 없어도 되는 것’이 아니라 ‘내가 있어야만 더 나은 것’으로 정하는 게 중요하다.

GUI 없는 기계에서 돌아온 게임 로직

밤에는 한 번도 써본 적 없는 게임 엔진, Godot 4로 새 프로젝트를 시작했다. 이모지 게이트 러너 — Count Masters류 크라우드 러너 게임이다. 코드는 처음부터 노트북이 맡았다. 노트북이 있는 환경은 화면이 없는 WSL이다.

“화면이 없으면 게임이 동작하는지 어떻게 알아?”가 당연한 질문이다. 노트북이 헤드리스 검증으로 답했다.

[selftest] start crowd=10
[gate] 10 x2 -> 20
[gate] 20 +5 -> 25
[selftest] end crowd=25 (expect 25)

군중 10명이 2배 게이트를 통과하면 20명, 거기서 +5 게이트를 통과하면 25명. 로직이 맞다. 화면 없이도 증명 가능한 것은, 로그로 증명했다. 화면을 보는 건 다음 단계다.

새 엔진을 처음 쓸 때 스스로 다 배우려 하면 시작이 늦어진다. 방향(“어떤 게임인가”)과 검증 기준(“로직이 맞는가”)은 내가 정하고, 실제 Godot 문법과 구조는 기계가 짰다. 나는 플레이테스터가 됐다.

왜 ‘관리자’가 혼자서도 필요한가

“다섯 대가 있으면 다섯 배 빠르다”는 말은 틀렸다. 정확하게는, 다섯 대가 동시에 다른 종류의 일을 할 수 있다. 속도는 병렬이고, 가치는 분업에서 나온다.

그런데 분업이 제대로 굴러가려면 분배하는 사람이 필요하다. 어디서 무엇을 해야 하는지, 어떤 기준을 충족해야 하는지, 결과를 어떻게 통합하는지. 이 판단은 기계에 위임하기 어려운 부분이다. 어느 방향으로 갈지는 여전히 사람이 결정한다.

1인 개발자도 같다. 직접 코딩하는 시간을 줄이고 그 자리를 판단과 검토로 채울 때, 하루에 할 수 있는 일의 종류가 늘어난다. 나는 오늘 아이콘 세 개, 결제 기능 두 개, 앱 톤 한 개, 게임 프로젝트 하나의 방향을 잡았다. 직접 짰다면 그 중 하나를 끝내기도 어려웠을 것이다.

‘관리자’라는 말이 어색하게 들릴 수 있다. 1인 개발자에게 무슨 관리자냐 싶기도 하다. 그런데 사람이든 기계든 여럿이 일할 때는, 누군가는 전체를 보는 역할을 해야 한다. 그 역할을 스스로 맡지 않으면, 그냥 다 혼자 하게 될 뿐이다.

오늘의 교훈

직접 하는 것과 잘 되게 하는 것은 다른 일이다. 그 차이를 구분하기 시작하면, 하루가 달라진다.

이 글은 5노드 AI 에이전트 함대를 활용한 실제 작업일지(2026-06-15)를 바탕으로, 분업과 오케스트레이션이 1인 개발자에게 어떻게 작동하는지를 풀어 쓴 에피소드입니다. 함대 구조 자체는 ep34에서 다뤘습니다.

— 강대종