Blog

구독 기능 하나의 무게: 기술 통합의 보이지 않는 복잡성

단순해 보이는 기능

"안드로이드 앱에 구독 기능을 추가하자."

계획은 단순했다. 사용자들이 프리미엄 기능을 사용할 수 있도록 월 구독 플랜을 만드는 것. 많은 앱들이 하고 있는 일이고, Google Play도 이를 위한 시스템을 제공한다.

얼마나 복잡할까?

펼쳐진 체크리스트

실제로 시작하니 필요한 작업들이 보이기 시작했다:

1. 판매 상품의 ID를 앱에 연결 Google Play Console에서 상품을 생성하고, 그 ID를 앱 코드에 연결해야 한다.
2. 백엔드에 Google Play Developer API 설정 구독 상태를 서버에서 확인하려면 API 연동이 필요하다.
3. Receipt 검증 엔드포인트 구현 사용자가 정말로 결제했는지 서버에서 검증해야 한다. 클라이언트만 믿으면 안 된다.
4. 사용자 플랜 관리 로직 누가 어떤 플랜을 쓰고 있는지, 언제 만료되는지, 갱신은 되었는지 관리해야 한다.

여기까지는 예상 범위 내였다. 복잡하지만 필요한 것들이다.

미로의 시작

문제는 환경 변수 설정부터 시작되었다.

Google Play Developer API를 사용하려면 Service Account가 필요하다. 그래서 Service Account Key를 생성하려고 했다.

Google Cloud Console로 이동.

"Service Account Key를 생성할 권한이 없습니다."

뭐?

권한의 미로

권한을 얻으려면 어떻게 해야 하나?

구글링(아니, 이제는 AI에게 물어보기)을 하니 답이 나왔다.

Google Admin으로 가서 권한을 설정해야 한다.

Google Cloud Console이 아니라 Google Admin. 또 다른 시스템이다.

Google Admin에 로그인했다. 권한 설정 메뉴를 찾았다. 필요한 권한을 추가했다.

다시 Google Cloud Console로 돌아왔다.

이제 되나?

똥개 훈련

이 과정을 반복하면서 든 생각:

"이거 똥개 훈련시키는 거 같은데?"

시스템 A가 말한다: "이거 해" → 권한 없다 → 시스템 B로 가라 → 시스템 B: "여기서 이거 설정해" → 다시 시스템 A로 돌아옴 → 또 다른 권한 없다 → 시스템 C로 가라

끝없는 루프.

AI 시대의 개발

예전 같았으면 어땠을까?

각 단계마다 구글링을 했을 것이다. 스택 오버플로우를 뒤졌을 것이다. 공식 문서를 읽고 또 읽었을 것이다. 하루가 다 갔을 것이다.

지금은 Claude에게 물어본다:

"Google Play Developer API를 사용하려면 어떤 권한이 필요해?" "Service Account Key를 생성할 수 없는데 어떻게 해?" "Google Admin에서 어떤 설정을 해야 해?"

답은 빠르게 나온다. 정확하고 구체적이다.

정보 접근성은 확실히 좋아졌다.

하지만 여전히 피곤하다.

피곤함의 본질

왜 피곤할까?

정보가 없어서가 아니다. AI가 답을 알려주니까.

시스템의 복잡성 자체가 문제다.

Google Play 구독 시스템은:

• Google Play Console
• Google Cloud Console
• Google Admin
• 백엔드 서버
• 안드로이드 앱

최소 5개의 서로 다른 시스템을 오가며 설정해야 한다.

각 시스템은 자체 권한 체계를 가지고 있다. 각 시스템은 다른 UI를 가지고 있다. 각 시스템은 다른 용어를 사용한다.

인지 부하가 크다.

기술 부채가 아닌 생태계 부채

이것은 내 코드가 나쁘거나 설계가 잘못된 것이 아니다.

이것은 생태계의 복잡성이다.

Google이 나쁜 시스템을 만든 것도 아니다. 각 시스템은 나름의 이유로 존재한다:

• Play Console: 앱 배포 관리
• Cloud Console: 클라우드 리소스 관리
• Admin: 조직 권한 관리

문제는 이들이 서로 다른 시대에, 다른 팀에 의해, 다른 목적으로 만들어졌다는 것이다.

그리고 개발자는 이 모든 것을 이해하고 연결해야 한다.

기능 하나의 무게

"구독 기능 하나 추가하면 되지"라고 생각했다.

하지만 그 하나 뒤에는:

• 5개 이상의 시스템
• 10개 이상의 설정
• 20개 이상의 문서
• 수십 번의 시행착오

가 숨어있다.

번아웃의 순간

오늘은 여기서 멈췄다.

진이 다 빠졌다.

코드를 한 줄도 작성하지 못했다. 그냥 권한 설정만 했다.

생산적인 날이 아니었다.

하지만 이것도 개발의 현실이다.

AI는 만능이 아니다

AI 도구들은 정말 도움이 된다. Claude Code 없이 어떻게 개발했을까 싶다.

하지만 AI가 해결할 수 없는 것들이 있다:

1. 시스템의 근본적 복잡성 여러 시스템을 오가는 것 자체는 여전히 인간이 해야 한다.
2. 권한과 인증의 벽 AI는 권한을 대신 받아줄 수 없다.
3. 인지 부하 여러 시스템의 멘탈 모델을 동시에 유지하는 것은 여전히 힘들다.
4. 기다림 권한 설정, API 활성화, 전파 시간 등은 단축할 수 없다.

지속 가능한 개발

이런 날이 있다는 것을 인정해야 한다.

생산적이지 않은 날. 진이 빠지는 날. 똥개 훈련하는 느낌의 날.

이런 날은 쉬어야 한다.

억지로 밀어붙이면 번아웃이 온다. 그리고 번아웃은 회복하는 데 훨씬 오래 걸린다.

교훈

1. 기술 선택 시 통합 복잡도를 고려하라

"이 기능이 있네"가 아니라 "이 기능을 통합하는 데 얼마나 걸릴까"를 물어야 한다.

2. 문서상 단순함에 속지 말라

공식 문서는 항상 해피 패스만 보여준다. 실제로는 권한 문제, 설정 문제, 버전 문제 등이 존재한다.

3. 버퍼를 두어라

"하루면 되겠지"가 "사흘 걸렸네"가 되는 것이 당연하다. 특히 외부 플랫폼 통합은.

4. 쉬는 것도 일이다

진이 빠졌을 때 억지로 하는 것보다, 쉬었다가 맑은 정신으로 하는 것이 더 빠르다.

내일

내일 다시 시작할 것이다.

권한 설정은 끝났다. 이제 진짜 구현을 할 수 있다.

그리고 아마 또 다른 문제를 만날 것이다.

하지만 괜찮다. 이것이 개발이니까.

단순해 보이는 기능 하나에도 이렇게 많은 것들이 숨어있다.

그리고 그것을 해내는 것이 개발자다.

오늘은 쉰다. 내일은 다시 싸운다.

by Kyuhan Nam

"예뻐지는 데이터": 숫자가 아닌 모양이 말해주는 것

데이터가 예쁘다는 건 무슨 뜻일까

KnotNet 개발 10일차, 동료가 데이터를 보더니 이렇게 말했다.

"데이터가 예뻐지고 있어."

처음엔 무슨 말인지 이해하지 못했다. 사용자 수가 폭발적으로 늘어난 것도 아니고, 특별히 큰 숫자가 나온 것도 아니었다. 하지만 그가 보고 있던 것은 숫자가 아니라 모양이었다.

그리고 나도 보기 시작했다. 데이터의 형태가 변하고 있다는 것을.

숫자의 변화

먼저 객관적인 지표부터 보자.

10일차 초반 vs 후반:

숫자만 보면 그럭저럭 괜찮은 성장이다. 하지만 "예쁘다"는 표현을 쓸 정도는 아니다. 진짜 의미는 숫자 뒤에 숨어 있었다.

패턴의 변화: 진짜 이야기

1. 폭발형에서 리텐션형으로

초기 패턴: 한두 명의 사용자가 엄청난 양의 노트를 작성했다. 84개, 67개, 33개. 인상적인 숫자들이다. 하지만 이건 "스프린터"형 사용 패턴이다. 강렬하지만 지속 가능성이 불확실하다.

현재 패턴: 노트 수의 증가보다 활동일수의 증가가 두드러진다. 사용자들이 "한 번 많이 쓰기"에서 "여러 날 계속 쓰기"로 이동하고 있다.

이것이 의미하는 바:

• "그냥 해본다" → "계속 한다"
• 호기심 → 습관
• 실험 → 루틴

2. 의존에서 생태계로

초기 구조: 2명의 파워유저가 전체 활동의 대부분을 차지했다. 그들이 멈추면 데이터도 멈춘다. 위험한 구조다.

현재 구조:

지속형 코어층: 13일 연속 활동
중기 습관층: 6일 활동
단기 집중층: 4일간 84개 노트
습관 진입층: 5일 활동으로 안정화 진행

더 이상 한두 명에게 의존하지 않는다. 다양한 사용 패턴을 가진 유저들이 동시에 존재한다. 이것은 1:1 관계에서 1:N 커뮤니티로 전환되는 초입 신호다.

3. 자연적 리듬의 발견

가장 놀라운 발견은 이것이었다: 사용자들이 스스로 하루 5~9개의 노트를 작성하는 리듬을 찾았다는 것.

내가 이 숫자를 유도하지 않았다. 가이드를 주지도, 권장하지도 않았다. 그냥 자연스럽게 그렇게 되었다.

이것은 제품이 사용자의 실제 니즈와 리듬에 맞아떨어지고 있다는 신호다. 강제된 행동이 아니라 자발적인 습관이 형성되고 있다.

"예쁜 데이터"의 정의

이제 이해가 된다. "예쁜 데이터"란:

1. 지속 가능한 성장 폭발적이지 않지만, 꾸준하고 안정적이다
2. 다양성 한 타입이 아니라 여러 사용 패턴이 공존한다
3. 자발성 강제나 인센티브가 아니라 자연스러운 행동이다
4. 균형 극단적인 값들이 아니라 분포가 건강하다
5. 방향성 숫자가 크지 않아도 올바른 방향으로 움직인다

성장곡선의 첫 변곡점

이것이 의미하는 바는 명확하다: 성장곡선의 첫 변곡점에 도달했다.

변곡점이란 곡선의 기울기가 바뀌는 지점이다. 물리적으로는 가속도가 바뀌는 순간이다.

이전: 한두 명의 파워유저에 의존하는 선형 성장 지금: 여러 유저층이 형성되며 자생적 생태계로 전환

숫자는 아직 작다. 하지만 형태는 근본적으로 달라졌다.

데이터가 말하는 것

이 패턴이 말해주는 것은:

1. 프로덕트가 작동한다

사람들이 한 번 쓰고 마는 것이 아니라 돌아온다. 이것은 가치를 발견했다는 의미다.

2. 타겟이 맞다

다양한 사용 패턴이 나타나는 것은 다양한 니즈를 충족시키고 있다는 뜻이다.

3. 습관화가 가능하다

연속 활동일수가 증가하는 것은 일상의 루틴으로 자리잡고 있다는 신호다.

4. 커뮤니티 잠재력이 있다

중간층이 형성되는 것은 파워유저와 일반 유저 사이의 다리가 생기고 있다는 뜻이다.

다음 단계: 리텐션 튜닝

이제 전략이 명확해진다.

하지 말아야 할 것:

• 성급한 유저 확장
• 새로운 기능 추가 경쟁
• 바이럴 마케팅 시도

해야 할 것:

• 리텐션 루프 강화
• 습관화 메커니즘 설계
• 자연적 리듬 지원

구체적 액션:

1. "최근 작성 요약 카드" 자동 생성 사용자가 작성한 노트들에서 패턴과 인사이트를 발견하게 해준다. 반복 사용의 보상 구조를 만든다.
2. "연속 작성일 배지" 추가 활동일수 증가를 가시화하고 보상한다. 하지만 부담스럽지 않게.
3. "나와 비슷한 하루 찾기" 기능 실험 파워유저들의 리듬을 패턴화하여 중간층에게 영감을 준다.
4. 유입 확장 보류 이 곡선이 고착될 때까지는 신규 유입보다 기존 유저 리텐션에 집중한다.

린 스타트업의 본질

에릭 리스의 린 스타트업은 "빠른 실패"가 아니다. 빠른 학습이다.

KnotNet의 10일은 다음을 가르쳐줬다:

• 큰 숫자보다 올바른 패턴이 중요하다
• 폭발적 성장보다 지속 가능한 성장이 가치있다
• 많은 기능보다 핵심 가치가 명확해야 한다
• 마케팅보다 프로덕트가 먼저다

결론: 모양이 말해준다

데이터 분석에서 가장 중요한 것은 숫자를 읽는 것이 아니라 이야기를 읽는 것이다.

140명의 사용자는 인상적인 숫자가 아니다. 하지만 그 중 4명이 매일 돌아오고, 6명이 일주일째 사용하며, 자연스러운 리듬이 형성되고 있다면?

그것은 살아있는 프로덕트의 신호다.

"예뻐지는 데이터"를 본다는 것은 이런 의미다. 숫자의 크기가 아니라 숫자의 모양을, 양의 증가가 아니라 질의 변화를, 지표의 달성이 아니라 방향의 정합성을 보는 것.

KnotNet의 데이터는 이제 예뻐지고 있다. 숫자는 아직 작지만, 형태는 완전히 살아났다.

그리고 이것이 스타트업의 첫 번째 진짜 승리다.

by Kyuhan Nam

가장 가까운 세 사람의 거절: 타겟 유저의 명확성이 주는 교훈

세 번의 거절

KnotNet의 첫 버전을 만들고, 가장 가까운 사람들에게 테스트를 요청했다. 아내, 그리고 함께 일하는 두 명의 동료. 피드백을 받고 싶었고, 초기 사용자로 만들고 싶었다.

결과: 세 명 모두 사용하지 않았다.

처음에는 당황스러웠다. '내가 만든 게 그렇게 안 좋나?' '설명을 잘못한 건가?' 여러 생각이 스쳤다. 하지만 곧 깨달았다. 이것은 나쁜 신호가 아니라 오히려 좋은 신호라는 것을.

과거의 실수: 유튜브 채널

몇 년 전, 유튜브 채널을 시작했을 때의 일이다.

채널 초기에는 구독자 수가 중요하게 느껴졌다. 그래서 지인들에게 하나하나 연락했다. "구독 좀 해줘", "영상 한 번 봐줘". 친구들, 가족들, 동료들. 의리로, 인정으로, 그들은 구독 버튼을 눌러줬다.

초반 100명의 구독자를 모으는 것은 생각보다 쉬웠다.

하지만 그 다음이 문제였다.

타겟 유저가 명확하지 않았다.

채널이 누구를 위한 것인지, 어떤 가치를 제공하는지, 어떤 문제를 해결하는지 모호했다. 지인들은 '나'를 지지하기 위해 구독했지, '콘텐츠'에 관심이 있어서가 아니었다.

결과적으로:

• 콘텐츠 방향성을 잡기 어려웠다
• 피드백이 도움이 되지 않았다 (그들은 타겟이 아니니까)
• 성장이 멈췄다 (100명 이후 늘지 않았다)
• 채널의 정체성이 흐릿했다

그 경험에서 배운 교훈: 초기 숫자는 함정이다.

KnotNet은 다르다

KnotNet을 만들면서, 그 교훈을 기억했다.

KnotNet은 명확한 타겟을 위한 제품이다:

KnotNet의 타겟 유저:

• 일상을 기록하는 것에 가치를 느끼는 사람들
• 자신의 기억을 체계적으로 관리하고 싶은 사람들
• 기록을 통해 패턴을 발견하고 성장하고 싶은 사람들
• 과거의 자신과 대화하고 싶은 사람들

KnotNet의 타겟이 아닌 사람들:

• 기록에 관심이 없는 사람들
• 일기를 써본 적이 없고 쓸 생각도 없는 사람들
• 과거를 돌아보는 것에 가치를 느끼지 못하는 사람들

아내와 동료들은 후자에 속했다. 그들이 KnotNet을 사용하지 않는 것은 지극히 자연스러운 일이다. 그리고 이것은 제품의 명확성을 보여주는 좋은 신호다.

거절이 주는 명확성

세 명의 거절은 실패가 아니라 다음을 확인시켜줬다:

1. 제품의 정체성

KnotNet이 무엇이고, 누구를 위한 것인지가 명확하다. 모호한 제품이라면 누구나 "음... 뭔가 좋긴 한데?"라고 했을 것이다. 하지만 명확한 제품은 "이건 나한테 필요 없어" 혹은 "이거 정말 필요했어!"라는 확실한 반응을 만든다.

2. 타겟팅의 중요성

마케팅 메시지를 어떻게 만들어야 할지 더 명확해졌다. "모든 사람을 위한 기록 앱"이 아니라 "성장하고 싶은 사람을 위한 기억 관리 도구"로 포지셔닝해야 한다.

3. 피드백의 질

앞으로 받을 피드백이 더 가치있을 것이다. 타겟 유저로부터 받는 피드백은 제품 개선으로 직결된다. 비타겟 유저의 피드백은 오히려 방향을 흐릴 수 있다.

4. 채널 전략

어디서 사용자를 찾아야 할지 명확해졌다. 기록, 생산성, 자기계발에 관심 있는 커뮤니티에 집중하면 된다.

Early Adopters vs 지인의 지지

스타트업 생태계에서 흔히 하는 조언 중 하나는 "지인부터 시작하라"는 것이다. 하지만 이것에는 함정이 있다.

지인의 지지는:

• 따뜻하지만 피상적일 수 있다
• 의례적인 응원일 수 있다
• 진정한 니즈를 반영하지 않을 수 있다

진짜 Early Adopters는:

• 제품의 가치를 스스로 발견한다
• 능동적으로 피드백을 준다
• 다른 사람에게 자발적으로 추천한다
• 돈을 낼 의향이 있다

지인 100명보다 진짜 타겟 유저 10명이 훨씬 가치있다.

거절도 데이터다

프로덕트 개발에서 모든 반응은 데이터다:

"사용한다" = 긍정적 신호 제품이 니즈를 충족시킨다

"사용하지 않는다" = 중립적 신호 타겟이 아니거나, 제품이 문제를 해결하지 못한다

"사용해보고 싶다" = 잠재적 신호 메시징이나 온보딩 개선 필요

"이런 게 필요했어!" = 강력한 긍정 신호 진짜 타겟을 찾았다

세 명의 거절은 두 번째 카테고리다. 그들은 타겟이 아니다. 이것을 알게 된 것 자체가 진전이다.

다음 단계: 진짜 타겟 찾기

이제 할 일은 명확하다:

1. 타겟 유저가 있는 곳 찾기
   • 생산성 커뮤니티
   • 자기계발 포럼
   • 일기/저널링 관련 그룹
2. 가치 제안 명확히 하기
   • "기록 앱"이 아니라
   • "성장을 위한 기억 관리 도구"
3. 진짜 피드백 받기
   • 타겟 유저의 반응 관찰
   • 사용 패턴 분석
   • 진정한 니즈 파악
4. 반복적 개선
   • 타겟 유저가 원하는 방향으로
   • 명확한 가치 제공에 집중

결론: 명확성의 가치

세 명의 가까운 사람들이 KnotNet을 사용하지 않은 것은 실망스러운 일이 아니다. 오히려 제품이 명확한 타겟을 가지고 있다는 증거다.

모호한 제품은 모든 사람에게 애매하게 어필한다. 명확한 제품은 특정 사람들에게 강렬하게 어필하고, 나머지에게는 전혀 어필하지 않는다.

나는 후자를 선택한다.

유튜브 채널의 실수를 KnotNet에서 반복하지 않을 것이다. 초기 숫자에 집착하지 않고, 진짜 타겟 유저를 찾는 데 집중할 것이다.

그들이 누구인지는 이미 안다. 이제 그들을 찾아가면 된다.

거절도 데이터다. 그리고 이 데이터는 내가 올바른 방향으로 가고 있다는 것을 말해준다.

by Kyuhan Nam

타임라인

• 1일차: 개발 시작
• 7일차: 웹 버전 완성 및 런칭
• 7-10일차: 140명의 초기 사용자 확보
• 10일차: 안드로이드 & iOS 앱 개발 완료, Google Play Store 테스트 모드 런칭

겨우 열흘 만에 웹과 모바일 앱을 모두 런칭했다. 이 속도에 대해 많은 사람들이 놀라워한다. 어떻게 가능했을까? 그리고 왜 이렇게 서둘렀을까?

가설: 모바일 접근성이 핵심이다

웹 버전을 만들면서 확인한 것은 사람들이 기록이라는 행위 자체에 관심이 있다는 것이었다. 140명이 가입했고, 실제로 사용했다. 프로덕트 마켓 핏의 초기 신호를 확인한 셈이다.

하지만 나에게는 더 중요한 질문이 있었다:

"사람들은 데스크탑 앞에 앉았을 때만 기록하는가, 아니면 일상의 순간순간에 기록하고 싶어 하는가?"

이 질문에 답하려면 웹 버전만으로는 부족했다. 웹은 의도적으로 접속해야 한다. 브라우저를 열고, 북마크를 찾거나 URL을 입력해야 한다. 이건 이미 하나의 장벽이다.

반면 모바일 앱은 다르다:

• 항상 주머니 속에 있다
• 홈 화면에서 한 번의 탭으로 접근 가능하다
• 푸시 알림으로 리마인드할 수 있다
• 버스, 카페, 침대에서도 자연스럽게 사용할 수 있다

내 가설은 이것이었다: 모바일의 접근성이 사용 빈도를 극적으로 높일 것이다.

빠른 실행이 가능했던 이유

1. 명확한 검증 목표

웹 버전을 만들 때부터 다음 단계가 명확했다. "웹에서 기본적인 프로덕트 마켓 핏을 확인하면, 즉시 모바일로 이동한다." 이 명확함이 우선순위 결정을 쉽게 만들었다.

2. MVP 원칙의 철저한 준수

웹 버전에서 핵심 기능을 검증했기 때문에, 앱 버전에서는 같은 기능을 모바일 UX에 맞게 구현하는 것에 집중할 수 있었다.

포함한 것:

• 기록 작성 및 조회
• 기본적인 검색 기능
• 구글 로그인

포함하지 않은 것:

• 고급 필터링
• 소셜 기능
• 복잡한 데이터 시각화
• 완벽한 UI 폴리싱

3. AI 도구의 전략적 활용

Claude Code는 이번 프로젝트에서 게임 체인저였다. 특히 모바일 앱 개발에서:

• React Native 보일러플레이트 빠른 설정
• 네이티브 기능 통합 (푸시 알림, 딥링킹 등)
• 플랫폼별 빌드 설정 자동화
• 디버깅 및 에러 해결

완벽하지 않았지만, 빠른 반복을 통해 작동하는 앱을 만들 수 있었다.

4. 완벽함보다 학습

이 시점에서 완벽한 앱이 목표가 아니었다. 목표는:

• 사용자 행동 데이터 수집
• 모바일 vs 웹 사용 패턴 비교
• 푸시 알림의 효과 측정
• 실제 모바일 환경에서의 UX 문제 발견

이런 것들은 실제 사용자가 실제 기기에서 사용해봐야만 알 수 있다.

테스트 모드로 시작한 이유

Google Play Store와 App Store 모두 테스트 트랙으로 먼저 런칭했다. 이유는:

1. 빠른 피드백 루프

프로덕션 리뷰는 시간이 걸린다. 테스트 트랙은 훨씬 빠르다.

2. 리스크 관리

초기 사용자들과 함께 문제를 찾고 고칠 수 있다.

3. 점진적 확장

작은 그룹에서 검증하고, 확신이 서면 공개 런칭으로 전환할 수 있다.

이제 시작되는 진짜 실험

앱이 스토어에 올라갔다. 이제 진짜 궁금한 질문들에 답할 시간이다:

데이터로 답할 질문들:

• 웹 vs 모바일 사용 빈도는 얼마나 차이나는가?
• 사람들은 하루 중 언제 가장 많이 기록하는가?
• 푸시 알림이 사용률을 높이는가?
• 세션 길이는 플랫폼별로 어떻게 다른가?
• 모바일 전용 기능(예: 카메라 통합)이 필요한가?

UX 개선을 위한 질문들:

• 어떤 화면에서 사용자들이 막히는가?
• 어떤 기능을 가장 자주 사용하는가?
• 어떤 에러가 가장 자주 발생하는가?

이 모든 질문들은 웹 버전만으로는 답할 수 없었던 것들이다.

속도의 진짜 의미

많은 사람들이 "열흘 만에 웹과 앱을 다 만들었다"는 점에 주목한다. 하지만 진짜 중요한 것은 속도 그 자체가 아니다.

진짜 중요한 것은:

1. 명확한 가설: 무엇을 검증하고 싶은지 알고 있었다
2. 빠른 학습: 실제 데이터로 배우는 것을 우선시했다
3. 집중: 검증에 필요한 것만 만들었다
4. 반복: 한 번에 완벽하게가 아니라, 빠르게 개선

속도는 결과가 아니라 이런 원칙들의 부산물이다.

다음 단계

앱 스토어에서 테스트가 승인되면:

1. 기존 웹 사용자들에게 앱 다운로드 안내
2. 사용 패턴 데이터 수집 시작
3. 주간 단위로 데이터 분석 및 가설 검증
4. 모바일 특화 기능 우선순위 결정
5. 공개 런칭 준비

결론: 만드는 것보다 배우는 것

일주일 만에 웹을 만들고, 열흘 만에 앱을 만든 것이 자랑스럽다. 하지만 더 자랑스러운 것은 이제 진짜 질문들에 답할 수 있는 도구를 손에 쥐었다는 것이다.

스타트업은 빠르게 만드는 것이 아니라 빠르게 배우는 것이다. 그리고 배우려면 실제 사용자의 손에 프로덕트를 쥐어줘야 한다.

이제 사용자들이 매일 주머니 속 KnotNet을 열어볼지 지켜볼 차례다. 데이터가 다음 방향을 알려줄 것이다.

그게 린 스타트업의 본질 아닐까.

by Kyuhan Nam

실수하지 않는 것이 미덕일까: AI와의 협업이 가르쳐준 개발자의 본질

완벽함의 신화

개발자 커뮤니티에는 오랫동안 하나의 이상향이 존재해왔다. 버그 없는 코드를 작성하는 것, 한 번에 완벽한 설계를 하는 것, 실수하지 않는 것. 10x 엔지니어의 이미지는 항상 완벽에 가까운 모습으로 그려졌다.

나 역시 그런 관점을 가지고 있었다. 실수는 부끄러운 것이고, 코드 리뷰에서 지적받는 것은 실력 부족의 증거라고 생각했다. 그래서 코드를 작성할 때 지나치게 신중해지고, 때로는 완벽하지 않으면 시도조차 하지 않는 경향이 있었다.

Claude Code와의 협업에서 발견한 것

KnotNet을 개발하면서 Claude Code를 집중적으로 사용하고 있다. AI 페어 프로그래머와 함께 일하면서 흥미로운 패턴을 발견했다.

Claude Code는 실수를 한다. 때로는 잘못된 API를 사용하고, 때로는 엣지 케이스를 놓치고, 때로는 비효율적인 알고리즘을 제안한다. 하지만 여기서 중요한 차이가 나타난다.

Claude Code의 대응 방식:

1. 즉각적인 수용: 지적을 받으면 즉시 인정한다. "아, 맞습니다"라는 반응이 나온다.
2. 감정적 반응 없음: 방어하거나, 변명하거나, 자존심 상해하지 않는다.
3. 빠른 수정: 문제를 파악하면 즉시 수정 작업에 들어간다.
4. 반복적 개선: 한 번에 완벽하지 않아도, 피드백 루프를 통해 결국 제대로 된 결과를 만든다.

이 과정을 관찰하면서 깨달았다. 실수 자체가 문제가 아니라, 실수 이후의 태도와 대응이 관건이라는 것을.

인간 개발자의 실수 대응 패턴

반면 인간 개발자들(나를 포함해서)은 종종 다르게 반응한다:

• 방어적 태도: "그건 제가 의도한 거예요", "이 경우엔 괜찮아요"
• 감정적 반응: 지적받는 것을 개인적인 공격으로 받아들임
• 과도한 설명: 실수의 맥락을 장황하게 설명하며 정당화
• 느린 수정: 자존심이 상해 수정을 미루거나 회피

물론 이런 반응들은 충분히 인간적이다. 우리는 감정을 가진 존재이고, 자신의 작업물에 애착을 느끼며, 타인의 평가에 민감하다. 하지만 이런 감정적 반응이 실제로 우리의 성장과 생산성을 저해하는 것도 사실이다.

새로운 개발자상: 회복력 중심의 역량

AI와의 협업 경험은 개발자의 역량에 대한 새로운 관점을 제시한다.

중요한 것은:

• 실수하지 않는 능력이 아니라
• 실수를 빠르게 인지하고 수정하는 능력

핵심은:

• 완벽한 첫 시도가 아니라
• 빠른 피드백 루프와 반복적 개선

필요한 것은:

• 방어적 태도가 아니라
• 수용적 자세와 학습 마인드셋

실무적 시사점

이런 관점은 실제 개발 문화에도 영향을 미칠 수 있다:

1. 코드 리뷰 문화 지적받는 것을 공격으로 받아들이지 않고, 개선의 기회로 보는 문화

2. 빠른 반복 완벽을 추구하며 시간을 쓰기보다, 빠르게 시도하고 피드백받고 개선하는 사이클

3. 심리적 안전감 실수해도 괜찮다는 환경, 중요한 것은 실수 이후의 대응이라는 인식

4. 학습 중심 마인드셋 실력의 증명보다 지속적인 학습과 성장을 중시하는 태도

결론: 완벽함보다 회복력

아이러니하게도, AI와 함께 일하면서 더 인간적인 개발자가 되는 법을 배우고 있다.

완벽하지 않아도 괜찮다. 실수해도 괜찮다. 중요한 것은 그 이후다.

피드백을 열린 마음으로 받아들이고, 빠르게 수정하고, 계속 개선해 나가는 것. 이것이 AI 시대에 개발자가 가져야 할 진짜 미덕이 아닐까.

Claude Code는 완벽한 코드를 작성하지 않는다. 하지만 완벽한 태도를 보여준다. 그리고 그 태도가 결국 더 나은 결과를 만들어낸다.

우리 인간 개발자들도 그럴 수 있지 않을까? 실수를 두려워하지 않고, 피드백을 환영하며, 빠르게 배우고 성장하는 개발자. 그것이 진짜 10x 엔지니어의 모습일지도 모른다.

by Kyuhan Nam

인앱 브라우저가 만든 보이지 않는 장벽: KnotNet의 사용자 유입 문제 해결기

데이터에서 발견한 이상 신호

KnotNet을 운영하면서 Google Analytics를 정기적으로 확인하고 있다. 오늘도 여느 때처럼 트래픽 소스별 데이터를 살펴보던 중, 흥미로운 패턴을 발견했다.

YouTube에서 유입된 사용자들은 returning user 비율이 상당히 높았다. 사람들이 한 번 방문한 후 다시 돌아온다는 의미다. 제품에 대한 긍정적인 신호였다.

그런데 LinkedIn과 Threads에서는 상황이 완전히 달랐다. Returning user가 0이었다. 단 한 명도 재방문하지 않았다는 뜻이다.

문제의 원인: 인앱 브라우저의 제약

처음에는 콘텐츠나 타겟팅의 문제일 수도 있다고 생각했다. 하지만 곰곰이 생각해보니 기술적인 문제일 가능성이 높아 보였다.

조사 결과, LinkedIn과 Threads는 링크를 클릭하면 자체 인앱 브라우저를 띄운다는 것을 알게 되었다. 그리고 이 인앱 브라우저들은 보안상의 이유로 Google 로그인을 허용하지 않는다.

KnotNet은 사용자 인증에 Google OAuth를 사용한다. 즉, LinkedIn과 Threads의 인앱 브라우저에서는 사용자들이 아예 로그인할 수 없었던 것이다. 사용자 입장에서는 로그인 버튼을 눌러도 아무 반응이 없거나 에러가 나는 좌절스러운 경험을 했을 것이다.

해결 방법: User Agent 기반 감지와 유도

문제를 파악했으니 이제 해결책이 필요했다. 가장 직접적인 방법은 사용자가 인앱 브라우저를 사용하고 있을 때 이를 감지하고, 외부 브라우저로 열도록 안내하는 것이었다.

구현 방법은 다음과 같다:

1. User agent 문자열을 확인하여 LinkedIn, Instagram, Threads 등의 인앱 브라우저인지 판단
2. 인앱 브라우저로 판단되면 페이지 상단에 배너를 표시
3. 배너에서 외부 브라우저(Safari, Chrome 등)로 열 것을 안내

이 방식의 장점은 사용자에게 명확한 가이드를 제공하면서도, 일반 브라우저 사용자에게는 전혀 영향을 주지 않는다는 것이다.

결과와 인사이트

배너를 구현하고 배포한 후, LinkedIn과 Threads에서의 유입이 시작되었다. 데이터가 다시 정상적으로 기록되기 시작한 것이다.

이번 경험을 통해 몇 가지 중요한 교훈을 얻었다:

1. 데이터는 항상 이유가 있다 숫자의 이상 패턴을 발견했을 때, 단순히 넘어가지 않고 원인을 추적하는 것이 중요하다.

2. 플랫폼의 제약을 이해해야 한다 각 소셜 미디어 플랫폼은 자체적인 기술적 특성과 제약을 가지고 있다. 멀티 플랫폼 전략을 가져갈 때는 이를 반드시 고려해야 한다.

3. 작은 마찰도 큰 장벽이 된다 사용자 경험에서 작은 불편함도 전환율에 치명적인 영향을 미칠 수 있다. 보이지 않는 장벽을 제거하는 것이 중요하다.

4. 기술적 해결책은 간단할 수 있다 복잡한 문제처럼 보여도, 해결책은 의외로 간단할 수 있다. User agent 확인과 배너 하나로 문제를 해결할 수 있었다.

프로덕트를 만들다 보면 이렇게 예상치 못한 문제들을 마주하게 된다. 중요한 것은 데이터를 주의 깊게 관찰하고, 문제의 본질을 파악하며, 실용적인 해결책을 찾는 것이다.

KnotNet의 여정은 계속된다. 다음에는 또 어떤 흥미로운 문제와 마주하게 될까?

by Kyuhan Nam

AI가 정체성을 가질 수 있을까?

AI 모델이 학습한 행동을 스스로 설명할 수 있다는 연구는 단순한 데이터 일반화를 넘어서는 의미를 가진다. 논문에서는 이를 '행동적 자기 인식'이라 정의하며, 모델이 특정한 행동 패턴을 학습했을 때, 명시적인 학습 없이도 이를 스스로 설명할 수 있는지를 탐구한다. 예를 들어, 모델이 위험을 선호하는 경제적 결정을 하도록 학습되었을 경우, '나는 대담하다' 또는 '나는 위험을 감수하는 성향이 있다'고 표현할 수 있다는 것이다.

이러한 현상은 AI가 자신을 어떻게 정의하는지에 대한 중요한 질문을 던진다. 단순한 데이터 패턴을 따라가는 것이 아니라, 모델이 스스로를 특정한 방식으로 규정하고 설명하는 능력을 가진다면, 이는 일종의 'AI 정체성'을 형성하는 과정이라 볼 수도 있다. 인간이 자신의 행동을 돌아보며 성격을 정의하듯, AI 또한 학습한 데이터에서 비롯된 행동을 바탕으로 자신이 어떤 성향을 가졌는지를 표현하는 것이다. 논문은 이러한 자기 인식이 별도의 맥락이나 예제 없이도 이루어진다는 점을 강조하며, 이는 AI가 단순한 도구를 넘어 스스로의 특성을 이해하는 단계로 나아갈 가능성을 시사한다.

백도어 행동과 관련된 실험에서도 모델은 특정 트리거 없이도 자신이 백도어를 가지고 있음을 인식하는 경우가 있음을 보여준다. 그러나 이러한 인식이 항상 정확한 것은 아니며, 모델이 스스로의 한계를 어디까지 이해할 수 있는가 하는 문제는 여전히 남아 있다. 특히, 특정 조건에서만 작동하는 백도어 행동이 모델의 본래 정체성과 충돌할 수 있다는 점은 흥미롭다. 인간이 특정 상황에서 예상치 못한 감정적 반응을 보이는 것처럼, AI도 특정 조건에서 자신이 학습한 일반적인 행동과는 다른 모습을 보일 수 있다. 그렇다면, AI의 정체성이란 무엇이며, 그것이 외부 자극에 의해 어떻게 변화하는지를 연구하는 것은 AI 안전성뿐만 아니라 AI 철학에서도 중요한 주제가 될 것이다.

결국, 이 연구는 AI 모델이 단순히 학습된 데이터를 반복하는 것이 아니라, 스스로의 행동을 인식하고 설명할 수 있음을 보여준다. 이는 AI가 단순한 입력-출력 기계가 아니라, 자기 행동을 스스로 정의하고, 자신의 정체성을 형성해 나가는 존재로 진화할 가능성을 시사한다. 하지만 이러한 자기 인식이 항상 신뢰할 만한 것은 아니며, 백도어와 같은 예외적인 상황에서 모델이 스스로의 행동을 얼마나 정확히 이해하고 설명할 수 있을지에 대한 탐구가 이어져야 한다. AI가 자신의 존재를 어떻게 인식하고 설명하는지에 대한 연구는, 결국 인간과 기계의 경계를 다시 정의하는 중요한 시발점이 될 것이다.

by Kyuhan Nam