파트타임 CTO라 쓰고, 개발노예라 읽는다

2주짜리 프로젝트가 1년이 되는 과정…? 삼엄한 파트타임 CTO 체험기

2024년 8월 16일 금요일 밤, 뮤지컬 <사의 찬미> 공연장. 객석 몇 자리에 거치대가 달려 있고, 거기 꽂힌 스마트폰에 "공연이 곧 시작됩니다"라는 안내가 떠 있었다. 막이 오르고 배우가 대사를 하면, 그 대사가 외국어 자막이 되어 그 화면에 흘렀다. 내가 1년 가까이 붙잡고 있던 프로덕트, 유니스텝이 처음으로 진짜 관객을 만난 날이었다.

기기 15대 중 2대가 말을 듣지 않았다. 1대는 구버전 앱이 깔려 있었다. 이건 좀 아쉬웠지만, 나머지 13대에서 자막이 끝까지 흘렀고 공연은 전혀 문제없이 매끄럽게 넘어갔다. 그날 밤 블로그에 이렇게 적었다.

정말로 너무너무 늦어졌다. 하지만 진짜 쓰고 싶던 글이다. 이제는 기록을 정리할 시간. 2년이 지났지만, 개발자의 관점에서 한번 회고를 해 본다.

첫 미팅 때, "못 하겠습니다"라고 말했어야 했다

2023년 가을, 나는 유통 회사를 막 굴리기 시작한 참이었다. 동업자와 둘이서 56일 동안 상품 대량등록 프로그램을 만들어 10월 3일에 1차 완성을 했고, 10월 23일에는 처음으로 서울 사무실에 출근했다. 방 안에서 일하던 1년을 막 졸업한 때였다.

그 무렵 공연 접근성 일을 하는 팀과 이야기가 오갔다. 연극과 뮤지컬에 실시간 자막을 띄우고 싶다고 했다. 청각장애인 관객, 그리고 한국어를 모르는 외국인 관광객을 위해서였다. 관객은 자기 스마트폰이나 극장이 빌려주는 기기로 자막을 보고, 운영자는 공연 흐름에 맞춰 자막을 한 줄씩 내보내는 구조다.

솔직히 끌렸던 이유는 두 가지였다. 하나는 돈이었다. 막 시작한 회사의 혹시 모를 비상금이 필요했다. 다른 하나는 풀스택 개발에 대한 갈증이었다. AI가 코드를 같이 짜 주는 시대에, 혼자서 앱과 웹과 서버를 다 만들어 보고 싶었다.

10월 22일 일기에는 이런 할 일이 적혀 있다. "웹에서 보낸 텍스트를 Flutter 앱에 그대로 띄워 보기." 내 머릿속의 이 프로젝트는 딱 그 정도 크기였다. 간이 PoC. 되는지만 보여 주면 되는 일.

근데 왜… 일이 점점 커지지?

10월 20일 첫 미팅을 하고, 11월 10일까지 회의를 두 번 더 했다. 요구사항을 스프레드시트로 정리하고, 개발사 의견을 한 칸씩 달았다. 질문은 끝이 없었다.

• 공연 한 편의 자막 파일은 몇 개이고 용량은 얼마나 되나? (지난 공연 것을 보니 1,370줄에 110KB였다.)
• 공연이 끝나면 목록에서 사라지나, 남나? 종료·공연 중·예정을 나눠야 하나?
• 공연 중에 자막을 고치거나, 암전 때 화면을 끄거나, 급하게 문구를 보내야 하면?

그리고 나는 농인 사회에 대해서도, 이 서비스를 쓸 사람에 대해서도 거의 몰랐다. 상대 팀이 보내 준 자료를 읽으며 그걸 배웠다. 자막에도 문법이 있다는 것도 그때 알았다. 괄호는 말하는 인물, 대괄호는 효과음, ♬는 음악이다.

11월 10일, 세 번째 회의에서 납품 범위가 정해졌다. 12월 22일까지 관객용 앱, 운영자 송출 화면, 관리자 화면. 간이 PoC는 그날 사라졌다. 계약서에는 연초에 정리했던 첫 회사의 법인 이름으로 도장을 찍었다. 새 회사 법인은 아직 없었다. 문 닫은 줄 알았던 회사가 마지막 일을 하나 더 한 셈이다.

혼자서 두 개

12월에 공동대표가 잠깐 해외 일정이 있어서, 3주 가까이 자리를 비웠다. 그동안 나는 유통 쪽 대량등록 프로그램과 자막 앱을 혼자 붙잡고 있었다. 12월 6일 팀 채널에 이렇게 남겼다.

12월 16일, 지원사업 제출용 앱 파일을 넘겼다. 우리 기준으로 85% 정도였다. 그 무렵 블로그에는 "참여하고 있는 모든 프로젝트에 다 이유가 있다"고 썼다. 거짓말은 아니었다. 다만 이유가 많다고 시간이 늘어나지는 않았다.

도망갈 수 있었던 마지막 기회

2024년 봄, 유통 회사는 빠르게 컸다. 3월에 새 법인을 세웠고, 4월 말에 첫 자체 브랜드 제품을 출시했다. 출시 사흘 만에 재고가 거의 바닥나서 세 배를 다시 주문했다. 매일 할 일이 쏟아졌다.

자막 앱은 그 사이에서 계속 밀렸다. 1월에 잡았던 첫 QA는 "2월 중순"에서 "3월 말~4월 초"로 미뤄졌다. 회사만 놓고 보면 답은 분명했다. 위약금을 물더라도 여기서 멈추는 게 맞았다. 내 시간이 가장 비싼 자원이었고, 그 시간은 이미 다른 곳에서 돈을 벌고 있었다.

그런데 멈추지 못했다. 첫 회사를 닫으면서 나에 대해 알게 된 게 하나 있었다. 나는 클라이맥스 직전에 포기하는 습관이 있다. 두 번째 회사를 시작하면서 '포기하지 않는 사람'이 되고 싶었다. 그래서 회사엔 아쉬운 결정일 수 있다는 걸 알면서도 이 레거시를 끝까지 지고 가기로 했다.

"얘들아, 요즘 뭐 하누…?"

혼자서는 안 된다는 건 인정해야 했다. 2024년 5월 7일, 파트너 팀에 공지를 올렸다. "제가 PM 포지션으로 변경되고, 개발자 한 분을 고용했습니다." 개발자 친구들에게 황급히 연락을 돌렸다. 6월까지 웹과 앱을 맡을 개발자가 합류했고, 나중에는 QA를 봐 줄 사람도 붙었다.

개발자에서 PM이 되니 하는 일이 바뀌었다. 코드를 짜는 대신 규칙을 만들었다.

• 브랜치 이름은 작업종류/#이슈번호
• 기록은 전부 GitHub 이슈에
• 우선순위는 중요도 먼저, 그다음 급한 순서
• main에 합치는 건 나만

7월에는 파트너 팀과 정기회의를 하고, 회의록을 남기고, 알파 테스트를 했다. 그런데 이 프로덕트에는 묘한 문제가 있었다. 진짜 테스트를 할 곳이 극장밖에 없다는 것. 배우가 있고, 조명이 꺼지고, 객석 와이파이가 흔들리는 그 환경을 사무실에서는 만들 수가 없었다.

첫 베타 상영 날, 이 맛에 개발하지

그래서 8월 16일부터 9월 20일까지, 매주 금요일과 토요일 실제 공연에서 베타 상영을 하기로 했다. 첫날이 바로 맨 앞에 적은 그 밤이다.

다음 날 바로 규칙 하나를 더했다. "공연 중에는 송출과 관계없는 버그 리포트를 하지 않는다." 운영 서버와 개발 서버가 한 대였기 때문이다. 공연 중에 누가 테스트를 돌리면, 객석의 자막이 꼬일 수 있었다.

며칠 뒤, 그 공연을 본 중국인 관광객이 샤오훙슈에 후기를 올렸다는 소식을 들었다. 내가 만든 프로덕트가 모르는 사람에게 쓰이고, 그 사람이 좋았다고 말하는 걸 처음 봤다. 1년 동안 쌓인 의심이 그날은 조용했다.

밤 8시부터 자정까지

가을에는 유럽 여행이 있었다. 2월에 "10월쯤이면 여유가 있겠지" 하고 질러 둔 여행이었다. 돌아오니 남은 개발과 서버 이관이 산더미였다.

그래서 11월 한 달, 평일 밤 8시부터 자정까지를 '개발 코어타임'으로 정했다. 디스코드 음성 채널에 모여서, 시작할 때와 끝날 때 각자 할 일을 짧게 올렸다. 그때 올린 메시지 제목이 241104_2306 같은 식이다. 날짜와 시각. 누가 무엇을 하고 있는지만 적었다.

이게 코어타임의 전부였다. 서로 기다리는 시간을 없애는 것. 낮에는 유통 회사 일을 하고, 밤에는 네 시간을 몰아서 일했다. 오랜만에 단기 몰입을 했고, 네 시간이면 생각보다 많은 걸 할 수 있다는 것도 알게 됐다.

넘겨주는 일이 제일 어려웠다

마지막 단계는 이관이었다. 우리 서버에서 돌던 서비스를 파트너 팀의 서버와 저장소로 옮기고, 앞으로 운영을 맡을 쪽에 넘겨야 했다.

쉬울 줄 알았다. 저장소를 옮기고 커밋만 하면 될 줄 알았다. 그런데 반영이 안 됐다. 한참 들여다보고 나서야 알았다. 이름만 같고 완전히 다른 저장소였다. 클라우드 서버를 아예 다시 깔아야 했다.

11월 28일 새벽 0시 24분에는 공연 중에 생긴 문제를 붙잡고 있었다. 비 오는 토요일 공연에서 앱과 웹 연결이 끊긴 일, "인터넷 통신이 원활하지 않다"는 메시지, 구버전 앱의 오류. 운영팀에 확인할 질문을 하나씩 적고, 서버·nginx·AWS 구간별로 무엇을 봐야 하는지 정리했다. 그러다 내가 미뤄 둔 것들이 보였다. 요청 시간 제한을 구간별로 맞춰 보지 않았고, 앱 로그를 서버에 남기는 기능은 만들어만 두고 켜지 않았다. 만든 사람이 "될 거예요" 하고 넘어간 자리는, 넘겨받는 사람에게 고스란히 숙제로 남는다.

개발자 3형제, 랭보 3형제

12월 4일, 마지막 모임으로 다 같이 뮤지컬 <랭보>를 봤다. 남자 셋의 우정과 이상을 다룬 작품이다. 하필 그 공연에 우리 '개발자 3형제'가 초청을 받았다. 관객 대부분이 여성인 공연장에 남자 셋이 줄지어 들어갈 때, 뜨거운 시선이 느껴졌다(고 믿고 있다).

공연이 끝나고 회식을 했다. 정말 재밌었다. 그 주에 우리 쪽 서버를 정리했다. 2023년 11월에 만든 디스코드 채널은 2025년 1월의 메시지를 끝으로 조용해졌다.

결국, 포기하지 않았다

4개월을 예상했던 일이 12개월 걸렸다. 중간에 쉰 기간도 짧지 않았다. 그래도 끝냈다. 베타 기간 동안 <사의 찬미>, <킬롤로지>, <랭보> 세 작품의 공연에서 자막을 내보냈다.

회사 입장에서는 아쉬운 결정이었다. 그 시간에 우리 브랜드를 더 키울 수 있었다. 나도 안다. 그런데 나 개인에게는 이 일을 끝까지 해냈다는 게 남았다. 누가 "무슨 개발을 해 봤냐"고 물으면 이제 이렇게 답한다.

• Why: 동시대의 콘텐츠 장벽을 허문다.
• How: 연극과 뮤지컬에 실시간 개인형 자막을 제공한다.
• What: 유니스텝.

우리 회사의 프로덕트는 아니다. 그래도 내 것 이상으로 정성을 쏟았다. 나한테는 가장 좋은 개발 포트폴리오이자 개발자 명함이다.

혼자 일할 때 내가 어떤 판단을 하는지도 배웠다.

1. 나는 일의 크기를 늘 작게 본다. "간이 PoC"라는 말이 계약서에 없으면, 그건 PoC가 아니다.
2. 현장 말고는 테스트할 곳이 없는 제품이 있다. 그런 제품은 처음부터 현장 일정을 기준으로 계획을 짜야 한다.
3. 밤 4시간은 생각보다 길다. 서로 기다리지 않게만 해 주면.
4. 넘겨줄 사람을 처음부터 상상해야 한다. 로그, 문서, 저장소 구조는 넘겨받는 사람이 묻기 전에 준비돼 있어야 한다.

이 프로젝트가 나에게 준 가장 큰 것은 아마 '이야기'를 모으고 싶다는 마음일 것이다. 무언가를 만드는 과정에는 늘 이야기가 남는다. 이 글도 그때의 디스코드 기록을 다시 열어 날짜 하나하나를 맞춰 보며 썼다. 2년 전의 나는 꽤 정신없었지만, 다행히 기록은 남겨 두었다.

2년 전, ChatGPT가 아직 GPT-3.5이던 시절에 유니스텝을 붙잡고 있지 않았다면 어땠을까. 아마 지금 우리 회사의 AX(AI 전환)는 불가능했을 것이다. 그때는 빨리 끝내야 할 프로젝트였지만, 돌아보면 정말 소중한 경험이었다. 그래서 이 글을 시작으로, 그 뒤로 진행했던 AX들에 대해 하나씩 글로 남겨 보려 한다.