cyan agency

Tag: 소규모팀

  • [파마비아] macOS 앱 배포 중 놓친 4가지 실수와 해결책

    [파마비아] macOS 앱 배포 중 놓친 4가지 실수와 해결책

    Mac 데스크톱 앱을 만들어 배포할 때 가장 위험한 것은 무언가 망가져도 알 수 없다는 점입니다. 사용자가 앱을 열 수 없거나, 설치 화면이 깨져 나가거나, 파일이 너무 커서 받지 못하는 상황이 조용히 일어나면 배포자는 며칠 뒤에야 문제를 발견합니다. 실제 배포 과정에서 겪었던 네 가지 장애와 각각을 막은 방법을 정리했습니다.

    Apple 공증 없이 배포된 앱, 사용자가 열 수 없음

    8월 25일부터 받은 Mac 앱이 전부 실행되지 않았습니다. “Apple은 이 앱에 악성 코드가 없음을 확인할 수 없습니다”라는 경고와 함께 휴지통으로 이동하는 창만 떴습니다. 나간 파일 4개가 모두 막혀 있었습니다.

    원인은 빌드 방식을 바꾼 시점이었습니다.

    GitHub Actions 비용을 줄이려고 Mac 빌드를 클라우드에서 로컬 컴퓨터로 옮겼는데, 클라우드 환경에서는 Developer ID 서명과 Apple 공증을 자동으로 진행했습니다. 반면 만든 로컬 스크립트는 임시 서명만 했습니다. 제대로 확인하지 않은 채 여러 번 배포했습니다.

    이제는 Developer ID로 서명한 뒤 Apple 공증을 받고, 마지막 단계에서 정말 앱이 열리는지 검사합니다. 열리지 않으면 배포 자체를 중단합니다.

    설치 화면이 회색 빈 배경으로 나간 이유

    드래그해서 설치하는 아름다운 화면 대신 배경도 화살표도 없는 기본 회색 창만 배포하고 있었습니다.

    사용한 도구가 Finder를 자동으로 조종해서 설치 창을 꾸미는 방식이었는데, 이 작업이 실패해도 오류 메시지 없이 성공한 척 넘어갔습니다. 설정 파일을 확인해보니 배경 항목이 없었습니다.

    Finder를 거치지 않고 설정 파일을 직접 작성하는 방식으로 바꿨습니다. 생성 후 바로 열어서 배경이 제대로 붙었는지 확인하는 단계를 추가했습니다.

    앱 용량이 1.1GB인 이유

    배포 파일이 1.1GB였습니다. 사용자는 받는 데만 몇 분이 걸렸습니다.

    앱 안에 torch(241MB), OpenCV(108MB) 같은 머신러닝 라이브러리가 통째로 포함돼 있었습니다. 우리 코드는 이 라이브러리를 한 줄도 사용하지 않았습니다. 3~4월에 다른 작업으로 설치한 패키지가 컴퓨터에 남아 있었고, 앱 패키징 도구가 “설치돼 있으니 포함해야 한다”고 판단해 전부 담았습니다.

    이 프로젝트에 필요한 6개 라이브러리만 들어 있는 전용 환경을 만들었습니다. 1.1GB가 212MB로 줄었고, 배포 파일은 378MB에서 74MB가 됐습니다. 5분의 1 수준입니다. 다시 용량이 부풀어나면 빌드를 멈추게 설정했습니다.

    새로고침 후 작성 중인 글이 모두 사라짐

    크레딧으로 만든 채널별 초안을 손으로 수정했는데, 페이지를 새로고침하면 통째로 사라졌습니다.

    제목, 원고, 채널 선택, 채널별 스타일, 초안 수정본을 모두 함께 자동 저장하도록 구조를 바꿨습니다. 각 글의 상태를 따로 보관해서 글 A를 쓰다가 글 B로 이동해도 A가 남습니다. 새로고침 직후면 물어보지 않고 복구하고, 시간이 지나면 “30분 전에 쓰던 글이 있어요 [이어서 쓰기]”라고 제안합니다.

    조용한 실패를 찾아내는 것이 핵심

    서명, 설치 화면, 저장 모두 실패해도 아무 경고 없이 진행된다는 게 공통점이었습니다.

    이제 모든 빌드와 배포 단계 마지막에 검사를 추가했습니다. 정말 작동하는지 확인하고, 문제가 있으면 배포를 멈춥니다.

    그 외 함께 개선한 부분

    • 클라우드 저장 비용 누수 — 무료 한도는 0.5GB인데 7.8GB를 사용 중이었습니다. 빌드 결과물이 릴리스마다 270MB씩 쌓여 118개가 됐습니다. 전부 삭제하고 보관 기간을 90일에서 7일로 단축했습니다.
    • 채널 스타일 용어 설명 부족 — ‘후기체’가 무엇인지 선택 창에서 알 수 없었습니다. 각 스타일을 카드로 펼쳐 설명과 3줄 예시를 함께 보여주도록 변경했습니다.
    • AI 처리 강제 — 원고를 그대로 올리고 싶은 경우가 있는데 AI 처리를 거쳐야 했습니다. ‘원고 그대로’ 옵션을 추가해 크레딧 0으로 그대로 배포할 수 있게 했습니다.
    • 화면 기준 불일치 — 웹은 보라색, 앱은 남색, 편집기는 회색을 사용해 일관성이 없었습니다. 색, 크기, 간격, 아이콘 규칙을 하나의 문서로 정리하고 거기서만 값을 가져오게 했습니다.

  • [파마비아] 읽기만 하던 페이지를 커뮤니티로 바꿨습니다 (그리고 네이버 취소선 사건)

    왜 커뮤니티를 만들었나요

    서비스를 알릴 방법이 검색 유입밖에 없었어요. 광고비를 쓸 생각이 없어서 글로 승부해야 했는데, 읽기 전용 페이지는 한 번 보고 끝나더라고요. 남는 게 없었어요.

    그래서 생각했어요. 쓰는 사람이 생기면 글이 쌓이고, 쌓인 글이 검색으로 사람을 데려온다. 그 순환을 만들고 싶었어요. 그리고 우리 제품으로 발행한 운영기 글이 커뮤니티에도 자동으로 올라가고, 그 주소가 SNS 글 끝에 붙게 했어요.

    원래 있던 페이지를 어떻게 바꿨나요

    원래는 /guide/ 라는 주소로 ‘팁 모음’만 정적 페이지로 뿌리고 있었어요. 읽기 전용이었죠. 이번에 그걸 커뮤니티로 바꿨어요. 주소도 /community/ 로 옮겼어요. guide 라는 이름이 내용과 안 맞았거든요.

    만든 것들은 이래요:

    • 로그인 안 한 사람도 전부 읽을 수 있게 했어요. 검색에서 들어온 사람을 로그인 벽으로 막지 않으려고요.
    • 웹에서 바로 글을 쓸 수 있게 했어요. 앱을 안 깔아도 돼요.
    • 로그인 버튼을 누르면 로그인 후 원래 보던 커뮤니티 글로 되돌아와요. 전에는 홈으로 튕겼거든요.
    • 댓글 기능을 붙였어요. 프로필 사진이 같이 나오고, 사진은 각자 바꿀 수 있어요.
    • 제가 쓴 글·댓글에는 ‘관리자’ 배지가 붙어요. 누가 운영자인지 헷갈리지 않게요.
    • 글에 태그를 달 수 있고, 태그 칩을 눌러 그 태그 글만 골라볼 수 있어요.

    만들다가 겪은 문제들

    한글 주소가 깨졌어요

    SNS 에 붙이는 링크 주소에 한글 슬러그를 썼다가 인코딩이 깨졌어요. 커뮤니티 글은 p-키.html 처럼 영문 주소로 따로 만들었어요. 팁 글은 검색을 노려야 해서 한글 주소를 그대로 뒀고요. 용도가 다르면 규칙도 달라야 했어요.

    고쳤다고 생각했는데 안 고쳐졌어요

    링크를 붙이는 코드를 고쳤다고 생각했는데, 패치 스크립트가 파일에 쓰지 않고 화면에만 출력하고 끝났어요. 첫 발행 글에는 링크가 없었어요. 고친 걸 눈으로 확인하지 않으면 안 고친 것과 같다는 걸 또 배웠어요.

    로고를 바꿨는데 옛날 것이 남아있었어요

    파비콘과 로고가 옛날 것으로 남아 있는 페이지가 여기저기 있었어요. 새로 만든 페이지마다 빠뜨렸던 거예요. 체크리스트가 필요하다는 걸 느꼈어요.

    네이버 블로그 취소선 사건 😅

    이번에 가장 당황스러웠던 건 네이버 블로그였어요. 자동 발행한 글이 전부 취소선으로 나가고, 문단 구분도 사라지고, 번호가 1부터 13까지 멋대로 붙었어요.

    원인을 찾는 데 시간이 걸렸어요

    원인 하나는 에디터에 글자를 ‘타이핑’하면 스마트에디터가 자동 서식을 건다는 거였어요. “1. ” 로 시작하면 번호 목록이 되고 그게 계속 이어지는 식이었어요.

    하지만 더 큰 문제가 있었어요. 네이버 에디터는 ‘마지막에 쓴 글자 서식’을 계정에 기억해요. 예전에 마크다운 ~~ 기호가 취소선을 켠 채로 끝났고, 그 뒤 모든 글이 통째로 취소선으로 나갔어요. 평범한 문단만 붙여넣어도 취소선이 걸렸어요. 글 내용을 아무리 고쳐도 안 없어지는 이유였어요.

    어떻게 고쳤나요

    본문을 HTML 로 클립보드에 담아 붙여넣어 소제목·굵게·목록·문단 간격을 살리고, 넣은 뒤 실제 화면을 검사해서 취소선이 걸려 있으면 전체 선택 후 토글을 꺼서 지웠어요. 선택한 상태로 끄면 ‘마지막 서식’도 같이 꺼져서 다음 글부터 재발하지 않았어요.

    참고로 네이버는 공식 발행 API 가 없어요. 그래서 사람이 쓰는 것과 같은 경로로 넣을 수밖에 없어요. 이런 문제가 생길 수밖에 없는 구조예요.

    마무리하며

    커뮤니티를 만들면서 배운 건, 완벽하게 만들고 내놓을 수 없다는 거예요. 만들면서 문제를 찾고, 고치고, 또 찾고. 그게 운영이더라고요. 취소선 사건도 그렇고, 링크가 안 붙은 것도 그렇고. 실수를 숨기지 않고 고쳐가는 게 1인 개발의 진짜 모습인 것 같아요.

  • [파마비아] 커뮤니티 게시판을 열었습니다 — 팁은 검색에, 회원 글은 앱에서

    왜 게시판을 만들었나

    famavia를 쓰시는 분들이 가끔 물어보세요. “이런 기능 있으면 좋겠어요”, “이런 경우엔 어떻게 하나요?” 같은 질문들. 일대일로 답하다 보니 같은 내용을 여러 번 설명하게 되더라고요.

    그래서 처음엔 ‘마케팅 팁’ 페이지를 만들었어요. 자주 묻는 질문이나 운영 노하우를 정리해서 올리는 공간이었죠. 그런데 쓰다 보니 또 다른 필요가 보였습니다. 회원분들끼리 서로 경험을 나누는 공간이요.

    단순히 게시판 하나 추가하면 안 되나?

    처음엔 그냥 게시판 하나 만들면 되겠지 싶었어요. 근데 곰곰이 생각해보니 두 가지 목적이 섞여 있더라고요.

    첫째, 검색으로 들어올 새 손님을 위한 공간. 네이버나 구글에서 “SNS 예약 팁” 같은 걸 찾다가 우리 글을 보고 들어오는 경로요. 이건 로그인 없이도 읽을 수 있어야 하고, 검색엔진이 잘 찾을 수 있게 만들어야 했어요.

    둘째, 실제로 서비스를 쓰는 분들끼리 대화하는 공간. “저는 이렇게 써봤는데 괜찮더라고요”, “이 기능 추가되면 좋겠어요” 같은 이야기들. 이건 앱 안에서 바로 쓰고 댓글 달 수 있어야 편하죠.

    한 게시판에 다 때려넣으면 뭔가 어정쩡해질 것 같았어요. 그래서 나눴습니다.

    어떻게 나눴나

    운영자가 쓰는 마케팅 팁: famavia.com/guide/ 주소로 누구나 볼 수 있는 공개 페이지입니다. 정적 HTML로 만들어서 검색엔진이 잘 찾아가고, sitemap에도 등록했어요. 새로 들어오시는 분들이 여기서 먼저 훑어보시면 좋겠다 싶었거든요.

    회원들이 쓰는 커뮤니티 글: 앱의 ‘팁 · 커뮤니티’ 메뉴에서 두 탭으로 나눠서 볼 수 있어요. 운영자 팁 탭, 커뮤니티 탭. 앱에서 바로 글 쓰고 댓글 달 수 있게 만들었습니다.

    회원이 쓴 글도 공개 커뮤니티 페이지에 함께 보여요. 검색으로 들어온 분들이 “아, 실제로 쓰는 사람들이 이런 이야기를 하는구나” 느낄 수 있게요.

    웹 콘솔은 일하는 화면이니까 팁만 보이게 하고, 커뮤니티는 링크로 연결했어요. 콘솔에서 수다 떨 일은 별로 없으니까요.

    안전장치도 몇 가지

    회원 글은 HTML을 통째로 받지 않고 줄바꿈만 문단으로 처리해서 올립니다. 이상한 스크립트나 스타일이 섞여 들어오는 걸 막으려고요.

    그리고 운영자 팁을 회원이 사칭해서 쓸 수 없게 권한을 확실히 막아뒀어요. 나중에 “이거 공식 답변 아니었어요?” 같은 혼란 생기면 곤란하니까요.

    써보니 어떤가

    아직 글이 많이 쌓이진 않았지만, 구조는 생각대로 작동하고 있어요. 팁 페이지는 검색에 조금씩 잡히기 시작했고, 회원분들이 앱에서 댓글 다는 모습도 보이더라고요.

    완벽하진 않아요. 나중에 글이 많아지면 검색 기능도 넣어야 할 것 같고, 카테고리 분류도 고민 중이에요. 그래도 일단은 ‘왜 나눴는지’가 분명하니까 다음 단계도 보이는 것 같습니다.

    혹시 famavia 쓰고 계시다면, 한 번 들어가서 글 남겨주세요. 경험 공유해주시면 다른 분들한테도 큰 도움이 됩니다 😊

  • [파마비아] 내 글이 몇 번 읽혔는지 이제야 알았다

    글을 올리고 나면 그게 끝이었다

    발행 도구를 만들어놓고 한참을 썼어요. 버튼 하나로 여러 SNS에 글이 올라가니까 편하긴 했는데, 뭔가 이상했어요. 글을 올리면 그걸로 끝이더라고요.

    몇 명이 봤는지, 반응이 있었는지 알 방법이 없으니까 다시 콘솔에 들어올 이유가 없었어요. 그냥 올리고 끝. 그러다 보니 ‘이거 진짜 쓰는 사람 있나?’ 싶더라고요. 저조차도요.

    화면부터 만들지 않았다

    그래서 발행한 글이 얼마나 읽혔는지 모아서 보여주는 ‘성과 보기’ 기능을 만들기로 했어요. 근데 이번엔 순서를 바꿨어요.

    보통은 화면부터 만들잖아요. 예쁘게 그래프 그리고, 숫자 넣고. 그런데 그렇게 하면 나중에 ‘왜 숫자가 안 나오지?’ 하면서 헤매게 돼요. 그게 제일 허무하거든요.

    그래서 이번엔 각 SNS에서 실제로 어떤 숫자를 받을 수 있는지 먼저 찔러봤어요. 될지 안 될지 확인하고 만드는 거죠.

    SNS별로 확인한 것들

    • 스레드: 조회수·좋아요·답글까지 다 받을 수 있었어요. 생각보다 잘 줬어요.
    • 인스타그램: 조회·도달·저장까지 가능했어요. 도달이랑 조회가 다르다는 것도 처음 알았네요.
    • 페이스북: 인사이트를 보려면 별도 승인이 필요해서 지금은 안 돼요. 신청하면 되긴 한데, 일단은 보류했어요.
    • 네이버·워드프레스: 조회수를 주는 통로가 아예 없어요. 각 사이트 통계를 직접 봐야 해요.

    안 되는 건 안 되는 거라서, 화면에 그대로 ‘페이스북은 아직 지원 안 돼요’라고 적었어요. 감추는 것보다 낫더라고요.

    8월 21일 글이 363번 읽혔더라

    확인해보니 8월 21일에 올린 글이 363번 읽혔더라고요. 그동안 모르고 있었어요. 전체로는 840회.

    숫자가 크진 않아요. 솔직히 작아요. 근데 안 보이던 게 보이니까 다음에 뭘 쓸지 감이 잡히더라고요. ‘아, 이런 글은 좀 읽히는구나’ ‘이건 반응이 없네’ 이런 게 보여요.

    6시간마다 자동으로 갱신되고, 콘솔에서 기간별로(7일·30일·90일) 볼 수 있게 만들었어요. 매번 새로고침할 필요 없이 알아서 업데이트되니까 편해요.

    배운 것

    되는 걸 먼저 확인하고 만드는 게 순서예요. 화면을 예쁘게 만들어놓고 ‘데이터가 안 와요’라고 하면 의미가 없거든요.

    그리고 안 되는 걸 감추지 말고 왜 안 되는지 적는 것도 중요해요. 사용자는 ‘왜 안 돼?’ 하면서 헤매는 것보다, ‘아 이건 원래 안 되는구나’ 하고 넘어가는 게 낫거든요.

    작은 숫자지만 이제 내 글이 얼마나 읽혔는지 알아요. 그것만으로도 다시 콘솔에 들어올 이유가 생겼어요. 📊