복제 대신 목적을 선택하다 — 하루스페이스가 메신저가 된 첫 주

이 글은 2026년 7월 1–5일의 Git 기록과 당시 설계 문서를 바탕으로, 7주여 뒤 다시 복기해 쓴 첫 주 회고다.

하루스페이스의 첫 화면은 지금의 하루스페이스와 거의 닮지 않았다.

처음에는 포트폴리오에 가까운 페이지가 있었고, 그다음에는 한 커뮤니티의 운영 구조를 참고한 작은 PoC가 있었다. 방이 있고, 구성원이 있고, 관리자가 있는 화면은 만들 수 있었다. 하지만 화면이 늘어날수록 오히려 더 중요한 질문이 선명해졌다.

우리는 무엇을 만들 수 있는가가 아니라, 무엇을 지키기 위해 이것을 만드는가.

첫 주에 가장 큰 변화는 새로운 버튼도, 화려한 기능도 아니었다. 참고 대상을 닮게 만드는 일을 멈추고 하루스페이스만의 목적을 선택한 일이었다.

참고하되 복제하지 않는다는 결정

기존 서비스를 살펴보는 일은 빠른 출발에 도움이 된다. 이미 사용자가 익숙하게 받아들이는 화면과 운영 흐름을 통해 어떤 문제가 반복되는지 짐작할 수 있기 때문이다. 그러나 참고와 복제 사이에는 생각보다 큰 거리가 있다.

우리가 참고한 구조에는 로그인, 가입 승인, 여러 방, 관리자 기능과 실시간 대화가 있었다. 필요한 것은 그 서비스의 코드나 이미지, 비공개 데이터가 아니었다. 사람들이 작은 공동체를 운영할 때 실제로 필요로 하는 행동의 순서였다.

나는 그 순서를 하루스페이스의 목적에 맞게 다시 해석하기로 했다.

• 모르는 사람을 최대한 많이 모으는 대신, 승인된 사람들이 안심하고 들어오는 공간
• 메시지를 많이 소비하게 하는 대신, 서로 다른 언어를 쓰는 사람도 같은 대화를 이어가는 공간
• 번역문만 보여 주는 대신, 필요할 때 원문을 직접 확인할 수 있는 공간
• 관리자가 가입을 승인하되, 누가 누구를 승인했는지 기록되는 공간

이 결정 덕분에 제품의 한 문장이 생겼다.

하루스페이스는 소중한 사람들이 언어의 차이 때문에 멀어지지 않도록 돕는 사적인 그룹 메신저다.

한 문장이 생기자 기능의 우선순위도 달라졌다. 무엇이 멋있어 보이는지가 아니라, 어떤 흐름이 먼저 끊기지 않아야 하는지를 판단할 수 있었다.

목업이 아니라 한 번 끝까지 걸을 수 있는 흐름

첫 MVP의 기준은 단순했다. 화면 여러 장을 보여 주는 대신 한 명의 사용자가 실제로 처음부터 끝까지 걸을 수 있어야 했다.

가입을 신청한다. 관리자가 확인한다. 승인된 사용자가 로그인한다. 그룹의 방에 들어간다. 메시지를 남긴다. 상대방은 자신의 언어로 번역된 문장을 먼저 보고, 필요하면 원문을 연다.

글로 적으면 짧지만 이 흐름에는 제품의 거의 모든 기본 문제가 들어 있었다. 인증 상태, 관리자와 일반 사용자의 권한, 방 접근 범위, 메시지 저장, 번역 실패, 화면 갱신, 모바일 입력과 운영 데이터까지 어느 하나라도 끊기면 사용자는 목적지에 도착하지 못했다.

그래서 첫 주에는 메뉴를 많이 만드는 것보다 이 길을 연결하는 데 집중했다. 방 목록과 채팅 화면을 분리했고, 공지·미디어·관리 영역을 각자의 책임으로 나눴다. 배포된 서버가 살아 있는지 확인할 수 있는 서버 상태 확인 경로(헬스 체크)도 만들었다.

그때는 이것이 작은 기술적 정리처럼 보였다. 돌아보면 서비스가 커져도 다시 사용할 수 있는 첫 뼈대였다. 화면을 분리한 덕분에 기능별 실패를 좁혀 볼 수 있었고, 건강 상태를 확인할 수 있게 되면서 “사이트가 안 된다”는 막연한 말 대신 어디까지 정상인지 물을 수 있게 됐다.

AI가 실패해도 대화는 멈추지 않게

번역은 하루스페이스의 중요한 기능이지만, 대화 그 자체보다 중요할 수는 없다.

초기 설계에서 가장 조심한 부분도 여기였다. 번역 제공자가 느리거나 응답하지 않을 수 있고, 외부 API 키가 아직 연결되지 않은 개발 환경도 있다. 이때 메시지 전송까지 실패하게 만들면 AI는 도움을 주는 기능이 아니라 대화를 막는 단일 장애점이 된다.

그래서 원문을 별도 필드로 보존하고 번역 결과를 그 옆에 저장했다. 첫 번째 번역 경로가 실패하면 다른 경로를 시도하고, 둘 다 어렵거나 연결 정보가 없으면 ‘번역 대기’ 문구와 원문을 담은 대체값을 저장해 메시지 생성이 실패로 끝나지 않게 했다. 번역 결과만 저장해 원문을 잃어버리는 방법은 선택하지 않았다.

이 원칙은 이후 하루스페이스의 AI 기능을 설계할 때도 반복해서 돌아오게 됐다.

AI는 핵심 행동을 가능하게 만드는 유일한 열쇠가 아니라, 핵심 행동을 더 잘하게 돕는 동료여야 한다.

AI 기능을 붙일 때는 “성공하면 무엇을 해 주는가”만 묻기 쉽다. 첫 주에 배운 더 중요한 질문은 “실패했을 때도 사용자는 원래 하려던 일을 계속할 수 있는가”였다.

첫 운영 장애는 화면 밖에서 왔다

기능이 눈앞에서 움직이기 시작하자 곧 운영 문제가 나타났다. 배포 환경의 접근 계정 상태를 복구한 뒤, 기존 사용자 테이블에 새 코드가 기대한 컬럼이 없다는 문제도 이어서 드러났다. 화면에서는 모두 로그인 실패처럼 보였지만, 계정 상태와 데이터 구조를 각각 확인해야 했다.

처음에는 보이는 증상을 고치려 했다. 계정을 다시 확인하고 로그인 처리를 손봤다. 하지만 같은 종류의 문제를 줄이려면 데이터 구조를 멱등하게 보강하고, 예상하지 못한 API 오류를 서버에서 관찰할 수 있어야 했다. 그때 예외 로깅을 더하고 스키마 보강 절차를 정리했다.

이 경험은 작지만 오래 남는 교훈이 됐다.

1. 운영 오류는 사용자가 본 화면과 같은 계층에서 발생하지 않을 수 있다.
2. 데이터베이스 변경은 코드 배포와 별도의 수명주기를 가진다.
3. 오류 메시지를 친절하게 만드는 것과 원인을 관찰할 수 있게 만드는 일은 둘 다 필요하다.
4. 초기화는 한 번만 성공하는 스크립트가 아니라 여러 번 실행돼도 안전한 절차여야 한다.

서비스를 처음 만들 때는 성공 경로가 눈에 잘 보인다. 운영을 시작하면 실패 경로가 제품의 품질을 결정한다. 첫 주의 로그인 문제는 하루스페이스가 화면 모음에서 운영해야 하는 서비스로 넘어가는 첫 신호였다.

모바일의 작은 불편은 작은 문제가 아니었다

같은 시기에 모바일에서 입력창을 누르면 화면이 확대되고, 새 메시지가 왔는데 최신 위치로 가지 않거나, 갱신할 때 화면이 깜빡이는 문제가 이어졌다. 미디어 업로드가 실패했을 때 사용자가 이유를 알기 어려운 경우도 있었다.

각각은 사소한 UI 버그처럼 보였다. 그러나 사적인 메신저에서 모바일은 보조 화면이 아니라 주된 사용 환경이다. 입력할 때마다 화면을 다시 맞춰야 하고, 방금 온 메시지를 찾기 위해 스크롤해야 한다면 번역이 아무리 잘돼도 대화는 오래 이어지지 않는다.

우리는 문제를 한꺼번에 덮는 대신 하나씩 분리했다. 모바일 입력 확대를 줄이고, 최근 메시지 위치를 보정하고, 갱신 중 불필요한 깜빡임을 줄였다. 업로드 실패는 조용히 사라지지 않고 사용자가 다음 행동을 선택할 수 있게 만들었다.

이 과정에서 “모바일 대응은 마지막에 화면을 줄이는 작업”이라는 생각을 버렸다. 모바일에서 자주 끊기는 행동부터 제품의 기본 흐름으로 취급해야 했다.

사진 한 장과 알림 하나가 운영 기능이 되기까지

첫 주 후반에는 이미지와 영상의 썸네일, 푸시 알림도 들어왔다. 겉으로는 편의 기능이지만 둘 다 운영 비용과 신뢰에 직접 닿아 있었다.

목록에서 매번 원본 미디어를 불러오면 화면도 느려지고 전송량도 커진다. 그래서 대화 목록에서는 작은 썸네일을 먼저 보여 주고, 사용자가 열었을 때 원본을 가져오는 방향을 택했다. 푸시 알림 역시 모든 사람에게 무조건 보내는 대신 사용자가 직접 켜고 끌 수 있어야 했고, 브라우저·기기별 구독 정보는 따로 관리해야 했다. 본인이 보낸 메시지를 다시 본인에게 알리지 않는 것도 필요했다.

당시에는 아직 완전한 비용 모델이나 정교한 알림 정책이 없었다. 그래도 작은 기능을 추가할 때부터 세 가지를 함께 보기 시작했다.

• 사용자가 실제로 원하는 순간은 언제인가
• 그 순간까지 어떤 데이터를 꼭 전송해야 하는가
• 실패하거나 원하지 않을 때 어떻게 멈출 수 있는가

이 세 질문은 이후 미디어 저장소, 실시간 연결, AI 호출과 자동화 비용을 설계할 때도 같은 기준이 됐다.

빠르게 만든 첫 주에서 잘못 생각했던 것

첫 주에는 많은 변화가 짧은 시간에 들어갔다. 빠르게 눈으로 확인할 수 있다는 장점이 있었지만, 제품 방향보다 기능 목록이 앞서려는 순간도 있었다. 홈 허브, 여러 메뉴, 개인화와 알림을 만들면서 “사용자가 이것을 정말 먼저 필요로 하는가”를 충분히 검증하지 못한 선택도 있었다.

또 문서에 검증 순서를 적었다고 해서 실제 운영 검증이 자동으로 증명되는 것은 아니었다. 당시 기록에는 로그인, 승인, 메시지와 첨부 전송을 확인하는 절차가 남아 있지만, 현재 다시 확인할 수 있는 기록에는 모든 시점의 CI 출력과 배포 로그가 같은 수준으로 남아 있지 않다.

그래서 이번 회고에서는 “검증했다”고 과장하지 않고, 어디까지 구현됐고 어떤 확인 절차를 세웠는지를 구분해 적는다. 잘된 결과만 이어 붙이면 홍보 글은 될 수 있지만, 다음 판단에 도움을 주는 개발 기록은 되기 어렵다.

첫 주가 남긴 실전 체크리스트

비슷한 서비스를 처음 만드는 사람에게 이 일주일의 경험을 건넨다면 다음 순서로 정리하고 싶다.

1. 기능 목록 전에 한 문장의 약속을 쓴다

“누가, 어떤 순간에, 무엇을 계속할 수 있게 하는가”가 들어간 문장이 필요하다. 이 문장이 없으면 참고 제품의 기능 수가 곧 로드맵이 된다.

2. 참고 대상에서는 행동 구조만 가져온다

화면, 코드, 데이터와 브랜드를 복제하지 않는다. 사용자가 가입하고 승인받고 목적을 달성하는 행동의 순서를 추출한 뒤 내 서비스의 가치에 맞게 다시 설계한다.

3. AI가 빠져도 핵심 흐름이 이어지는지 확인한다

외부 모델이나 API가 실패했을 때 원문, 입력 데이터와 사용자의 다음 행동이 남아야 한다. AI를 제거하면 아무것도 할 수 없는 구조라면 실패 비용이 너무 크다.

4. 스키마와 관측 가능성을 첫 배포 범위에 넣는다

건강 상태, 오류 로그, 멱등 마이그레이션과 최소한의 운영 점검 순서를 기능과 함께 만든다. “내 컴퓨터에서 됐다”와 “운영에서 복구할 수 있다” 사이를 연결하는 장치다.

5. 모바일에서 가장 자주 반복되는 행동부터 검증한다

로그인, 입력, 전송, 최신 메시지 보기와 오류 복구를 작은 화면에서 먼저 걸어본다. 데스크톱 화면을 줄이는 것만으로 모바일 경험이 되지는 않는다.

6. 결정과 한계를 같은 문서에 남긴다

무엇을 선택했는지만 기록하면 다음 사람은 같은 토론을 반복한다. 왜 선택했는지, 무엇을 포기했는지, 아직 검증하지 못한 것은 무엇인지 함께 남긴다.

하루스페이스가 시작된 순간

첫 주가 끝났을 때 하루스페이스는 완성된 서비스와 거리가 멀었다. 권한은 더 세밀해져야 했고, 그룹 간 데이터 경계와 실시간 비용, 공개와 비공개의 구분도 앞으로 풀어야 할 일이었다.

그래도 이전과는 분명히 달라져 있었다.

포트폴리오 화면과 커뮤니티 PoC를 지나, 누가 왜 이 공간에 들어오며 어떤 경험을 지켜야 하는지 말할 수 있게 됐다. 가입부터 승인, 대화, 번역과 원문 확인까지 한 번 걸어볼 수 있는 길이 생겼다. 그리고 그 길이 운영에서 처음 끊겼을 때, 보이는 화면만 고치는 대신 데이터와 관측 가능성을 함께 손보기 시작했다.

돌아보면 하루스페이스는 첫 커밋에서 시작된 것이 아니었다.

무엇을 닮게 만들지보다 무엇을 지킬지 선택한 순간, 비로소 시작됐다.

다음 기록에서는 사진 한 장과 채팅방 하나가 어떻게 비용 정책이자 보안 정책이 되었는지, 그리고 그룹이 늘어나면서 “보이지 않게 숨기는 것”과 “서버에서 접근할 수 없게 막는 것”의 차이를 배운 과정을 이어가려 한다.