실수하지 않는 것이 미덕일까: AI와의 협업이 가르쳐준 개발자의 본질
완벽함의 신화
개발자 커뮤니티에는 오랫동안 하나의 이상향이 존재해왔다. 버그 없는 코드를 작성하는 것, 한 번에 완벽한 설계를 하는 것, 실수하지 않는 것. 10x 엔지니어의 이미지는 항상 완벽에 가까운 모습으로 그려졌다.
나 역시 그런 관점을 가지고 있었다. 실수는 부끄러운 것이고, 코드 리뷰에서 지적받는 것은 실력 부족의 증거라고 생각했다. 그래서 코드를 작성할 때 지나치게 신중해지고, 때로는 완벽하지 않으면 시도조차 하지 않는 경향이 있었다.
Claude Code와의 협업에서 발견한 것
KnotNet을 개발하면서 Claude Code를 집중적으로 사용하고 있다. AI 페어 프로그래머와 함께 일하면서 흥미로운 패턴을 발견했다.
Claude Code는 실수를 한다. 때로는 잘못된 API를 사용하고, 때로는 엣지 케이스를 놓치고, 때로는 비효율적인 알고리즘을 제안한다. 하지만 여기서 중요한 차이가 나타난다.
Claude Code의 대응 방식:
- 즉각적인 수용: 지적을 받으면 즉시 인정한다. "아, 맞습니다"라는 반응이 나온다.
- 감정적 반응 없음: 방어하거나, 변명하거나, 자존심 상해하지 않는다.
- 빠른 수정: 문제를 파악하면 즉시 수정 작업에 들어간다.
- 반복적 개선: 한 번에 완벽하지 않아도, 피드백 루프를 통해 결국 제대로 된 결과를 만든다.
이 과정을 관찰하면서 깨달았다. 실수 자체가 문제가 아니라, 실수 이후의 태도와 대응이 관건이라는 것을.
인간 개발자의 실수 대응 패턴
반면 인간 개발자들(나를 포함해서)은 종종 다르게 반응한다:
- 방어적 태도: "그건 제가 의도한 거예요", "이 경우엔 괜찮아요"
- 감정적 반응: 지적받는 것을 개인적인 공격으로 받아들임
- 과도한 설명: 실수의 맥락을 장황하게 설명하며 정당화
- 느린 수정: 자존심이 상해 수정을 미루거나 회피
물론 이런 반응들은 충분히 인간적이다. 우리는 감정을 가진 존재이고, 자신의 작업물에 애착을 느끼며, 타인의 평가에 민감하다. 하지만 이런 감정적 반응이 실제로 우리의 성장과 생산성을 저해하는 것도 사실이다.
새로운 개발자상: 회복력 중심의 역량
AI와의 협업 경험은 개발자의 역량에 대한 새로운 관점을 제시한다.
중요한 것은:
- 실수하지 않는 능력이 아니라
- 실수를 빠르게 인지하고 수정하는 능력
핵심은:
- 완벽한 첫 시도가 아니라
- 빠른 피드백 루프와 반복적 개선
필요한 것은:
- 방어적 태도가 아니라
- 수용적 자세와 학습 마인드셋
실무적 시사점
이런 관점은 실제 개발 문화에도 영향을 미칠 수 있다:
1. 코드 리뷰 문화 지적받는 것을 공격으로 받아들이지 않고, 개선의 기회로 보는 문화
2. 빠른 반복 완벽을 추구하며 시간을 쓰기보다, 빠르게 시도하고 피드백받고 개선하는 사이클
3. 심리적 안전감 실수해도 괜찮다는 환경, 중요한 것은 실수 이후의 대응이라는 인식
4. 학습 중심 마인드셋 실력의 증명보다 지속적인 학습과 성장을 중시하는 태도
결론: 완벽함보다 회복력
아이러니하게도, AI와 함께 일하면서 더 인간적인 개발자가 되는 법을 배우고 있다.
완벽하지 않아도 괜찮다. 실수해도 괜찮다. 중요한 것은 그 이후다.
피드백을 열린 마음으로 받아들이고, 빠르게 수정하고, 계속 개선해 나가는 것. 이것이 AI 시대에 개발자가 가져야 할 진짜 미덕이 아닐까.
Claude Code는 완벽한 코드를 작성하지 않는다. 하지만 완벽한 태도를 보여준다. 그리고 그 태도가 결국 더 나은 결과를 만들어낸다.
우리 인간 개발자들도 그럴 수 있지 않을까? 실수를 두려워하지 않고, 피드백을 환영하며, 빠르게 배우고 성장하는 개발자. 그것이 진짜 10x 엔지니어의 모습일지도 모른다.
인앱 브라우저가 만든 보이지 않는 장벽: KnotNet의 사용자 유입 문제 해결기
데이터에서 발견한 이상 신호
KnotNet을 운영하면서 Google Analytics를 정기적으로 확인하고 있다. 오늘도 여느 때처럼 트래픽 소스별 데이터를 살펴보던 중, 흥미로운 패턴을 발견했다.
YouTube에서 유입된 사용자들은 returning user 비율이 상당히 높았다. 사람들이 한 번 방문한 후 다시 돌아온다는 의미다. 제품에 대한 긍정적인 신호였다.
그런데 LinkedIn과 Threads에서는 상황이 완전히 달랐다. Returning user가 0이었다. 단 한 명도 재방문하지 않았다는 뜻이다.
문제의 원인: 인앱 브라우저의 제약
처음에는 콘텐츠나 타겟팅의 문제일 수도 있다고 생각했다. 하지만 곰곰이 생각해보니 기술적인 문제일 가능성이 높아 보였다.
조사 결과, LinkedIn과 Threads는 링크를 클릭하면 자체 인앱 브라우저를 띄운다는 것을 알게 되었다. 그리고 이 인앱 브라우저들은 보안상의 이유로 Google 로그인을 허용하지 않는다.
KnotNet은 사용자 인증에 Google OAuth를 사용한다. 즉, LinkedIn과 Threads의 인앱 브라우저에서는 사용자들이 아예 로그인할 수 없었던 것이다. 사용자 입장에서는 로그인 버튼을 눌러도 아무 반응이 없거나 에러가 나는 좌절스러운 경험을 했을 것이다.
해결 방법: User Agent 기반 감지와 유도
문제를 파악했으니 이제 해결책이 필요했다. 가장 직접적인 방법은 사용자가 인앱 브라우저를 사용하고 있을 때 이를 감지하고, 외부 브라우저로 열도록 안내하는 것이었다.
구현 방법은 다음과 같다:
- User agent 문자열을 확인하여 LinkedIn, Instagram, Threads 등의 인앱 브라우저인지 판단
- 인앱 브라우저로 판단되면 페이지 상단에 배너를 표시
- 배너에서 외부 브라우저(Safari, Chrome 등)로 열 것을 안내
이 방식의 장점은 사용자에게 명확한 가이드를 제공하면서도, 일반 브라우저 사용자에게는 전혀 영향을 주지 않는다는 것이다.
결과와 인사이트
배너를 구현하고 배포한 후, LinkedIn과 Threads에서의 유입이 시작되었다. 데이터가 다시 정상적으로 기록되기 시작한 것이다.
이번 경험을 통해 몇 가지 중요한 교훈을 얻었다:
1. 데이터는 항상 이유가 있다 숫자의 이상 패턴을 발견했을 때, 단순히 넘어가지 않고 원인을 추적하는 것이 중요하다.
2. 플랫폼의 제약을 이해해야 한다 각 소셜 미디어 플랫폼은 자체적인 기술적 특성과 제약을 가지고 있다. 멀티 플랫폼 전략을 가져갈 때는 이를 반드시 고려해야 한다.
3. 작은 마찰도 큰 장벽이 된다 사용자 경험에서 작은 불편함도 전환율에 치명적인 영향을 미칠 수 있다. 보이지 않는 장벽을 제거하는 것이 중요하다.
4. 기술적 해결책은 간단할 수 있다 복잡한 문제처럼 보여도, 해결책은 의외로 간단할 수 있다. User agent 확인과 배너 하나로 문제를 해결할 수 있었다.
프로덕트를 만들다 보면 이렇게 예상치 못한 문제들을 마주하게 된다. 중요한 것은 데이터를 주의 깊게 관찰하고, 문제의 본질을 파악하며, 실용적인 해결책을 찾는 것이다.
KnotNet의 여정은 계속된다. 다음에는 또 어떤 흥미로운 문제와 마주하게 될까?