cyan agency

Tag: 개발일지

  • [파마비아] 블로그 검색 순위를 실시간으로 추적하는 방법

    [파마비아] 블로그 검색 순위를 실시간으로 추적하는 방법

    글을 발행한 뒤 검색 결과에서 어느 위치에 있는지 확인하는 것은 블로그 성장의 첫 단계입니다. 네이버 검색 API를 활용해 매일 자동으로 순위를 측정하고, 글의 실제 성과를 파악하는 방법을 소개합니다.

    발행 후 검색 순위를 추적해야 하는 이유

    지금까지 대부분의 블로그 도구는 글을 올리면 끝이었습니다. 조회수 같은 기본 지표는 보여주지만, 블로그로 성과를 내려는 운영자에게 정말 필요한 것은 다릅니다.

    검색 순위입니다.

    그 키워드로 검색했을 때 내 글이 몇 위에 있는지 알아야 다음 글의 방향을 결정할 수 있습니다. 이 정보가 없으면 글을 계속 쌓기만 할 뿐 개선할 근거가 없습니다.

    네이버 검색 API로 일일 순위 측정하기

    글 제목으로 검색했을 때의 순위를 매일 오전 9시 30분에 자동 측정합니다. 네이버의 공식 검색 API를 사용하므로 화면을 긁어내는 방식과 달리 안정적입니다.

    API는 최대 100위까지의 결과를 반환합니다. 100위 밖이면 ‘100위 밖’으로 표시됩니다.

    글 작성 단계에서 입력한 핵심 키워드의 첫 번째 항목을 검색어로 사용합니다. 키워드를 등록하지 않은 글은 순위 측정 대상이 되지 않습니다.

    네이버 주소 정규화로 정확한 비교

    네이버 검색 결과에는 m.blog와 blog, http와 https, www 유무, 끝 슬래시, 쿼리 파라미터 등이 제각각 섞여 나옵니다. 같은 글이 다른 주소로 여러 번 인식될 수 있다는 뜻입니다.

    이를 방지하기 위해 모든 URL을 하나의 표준 형식으로 정규화한 뒤 비교하는 로직을 별도로 구축했습니다.

    순위 변화를 한눈에 보는 인터페이스

    웹 콘솔의 ‘성과’ 섹션에는 검색 순위 표가 있고, 각 글 옆에 상승/하강 화살표로 변화를 표시합니다.

    앱에서는 ‘발행 내역’ 화면의 글 목록에 ‘검색 ○위’ 뱃지를 붙여서 스크롤하며 한 번에 확인할 수 있습니다.

    순위가 안 나온다는 것이 말해주는 것

    실제로 쓴 글 9건을 측정해보니 모두 100위 밖이었습니다. 글 제목을 그대로 검색해도 잡히지 않았습니다.

    원인은 두 가지입니다.

    • 블로그가 신규라 도메인 권위가 낮음
    • 설정한 키워드가 ‘서비스운영’, ‘블로그운영’ 같이 너무 광범위함

    그런데 이게 바로 이 기능을 만든 이유입니다. 결과를 보지 못하면 자신의 키워드 선택이 틀렸다는 사실조차 모르게 됩니다. 순위가 안 나오는 것 자체가 가장 중요한 피드백입니다.

    발견된 추가 문제와 해결

    제품 설명을 위해 공개해둔 ‘발행 기록’ 페이지가 있습니다. 이 페이지를 자동으로 재생성하는 스크립트가 매번 방문 측정 코드를 삭제하고 있었습니다.

    정작 트래픽을 확인해야 할 페이지가 아무것도 기록하지 못하고 있었던 것입니다. 생성 스크립트를 수정해서 측정 코드가 유지되도록 고쳤습니다.

    순위 추적의 한계

    블로그 탭 기준이므로 통합 검색 순위와 완전히 일치하지는 않습니다. 절대적인 위치보다는 ‘지난주보다 올랐는가, 내렸는가’를 보는 용도로 설계했습니다.

    발행 버튼을 누르는 것으로 끝나던 워크플로우가 이제는 발행 후의 변화까지 추적하게 됩니다. 순위가 나오지 않는 글들은 당신의 키워드 전략을 다시 생각해야 한다는 신호입니다.

  • [파마비아] 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 발행 전 이미지 작업으로 지치는 콘텐츠 작가들을 위해

    [파마비아] SNS 발행 전 이미지 작업으로 지치는 콘텐츠 작가들을 위해

    글은 완성했는데 사진이 없어서 공유를 미루는 일. 있다면 이 글이 정확히 당신의 상황입니다. 특히 인스타그램, 페이스북처럼 채널마다 이미지 크기가 다르면, 같은 내용을 세 번 네 번 다시 만들어야 합니다. 이 반복 작업을 없애기 위해 편집 도구 안에서 카드를 직접 만들 수 있도록 개선했습니다.

    매번 외부 도구를 켜야 하는 불편함

    콘텐츠를 준비하는 흐름이 계속 끊어졌습니다. 텍스트는 끝났는데 배경 이미지가 필요하면 캔바나 피그마를 켜야 했거든요. 거기서 카드를 디자인하고, 파일을 내려받고, 다시 돌아와 업로드하는 과정. 이게 한 번이면 문제없겠지만, 채널이 여러 개니까요.

    인스타그램 피드는 정사각형(1080×1080)이 기본입니다. 같은 콘텐츠를 스토리(1080×1920)로도 올려야 하면 높이가 길어지도록 다시 만듭니다. 페이스북 링크카드(1200×628), 블로그 헤더(1200×675)까지 일일이 작업하면, 한 글 하나 내보내는 데 네 번 다섯 번 편집기를 오갑니다.

    기존 편집기가 크기 조정을 못 했던 이유

    사실 카드 만드는 기능은 있었습니다. 문제는 제대로 작동하지 않았다는 것.

    캔버스 크기를 바꾸면 그 안의 텍스트와 이미지가 고정된 위치에서 움직이지 않습니다. 정사각형에서 중앙에 놓았던 제목이 세로형 캔버스로 바뀌면 왼쪽 위 구석에 그대로 남아있어요. 글자 크기까지 조정하려면 모든 요소를 처음부터 다시 배치해야 했습니다.

    이미지 소스도 번거로웠습니다. 직접 찍은 사진이 없으면 무료 사이트를 검색하거나 AI로 생성해야 했는데, 그 서비스들을 오가느라 시간이 흘렀죠. 같은 배경 이미지를 재활용하고 싶어도 보관할 공간이 없었습니다.

    비율을 유지하면서 크기 조정하기

    첫 번째 개선점은 캔버스 크기를 자유롭게 지정하는 것입니다. 100픽셀부터 4096픽셀까지 숫자로 직접 입력할 수 있게 했어요.

    자주 쓰는 크기는 프리셋으로 저장했습니다.

    • 인스타그램 정사각형: 1080×1080
    • 인스타그램 세로: 1080×1350
    • 인스타그램 스토리: 1080×1920
    • 페이스북 링크카드: 1200×628
    • 블로그 와이드: 1200×675

    핵심은 크기가 변해도 내부 요소가 비율에 맞춰 함께 움직인다는 점입니다. 중앙에 배치한 제목은 어떤 크기로 바꾸든 중앙에 있고, 이미지는 캔버스를 벗어나지 않습니다. 한 번 배치해두면 프리셋만 클릭해 여러 채널용을 순식간에 뽑을 수 있게 됐습니다.

    이미지 생성과 재활용 기능 추가

    배경이 필요하면 글로 설명하면 AI가 현재 캔버스 크기에 맞춰 이미지를 만들어줍니다. 한 장에 100크레딧이 드니까, 생성 전에 확인 메시지를 띄웁니다.

    매번 새로 만들면 크레딧이 빠릅니다. 그래서 이미지 보관함을 추가했어요. 업로드한 사진, AI로 만든 이미지, 완성한 카드 전부 한곳에 모입니다. 보관함에서 이전에 만든 이미지를 선택하고 ‘글자 얹기’를 누르면 편집기가 열리고, 그 이미지를 배경으로 텍스트만 바꿔 쓸 수 있습니다.

    실제 운영하면서 마주친 버그들

    완성 후 직접 글을 써서 발행해보니 새로운 문제가 나타났습니다.

    본문 중간에 삽입한 사진이 발행 후에는 전부 끝에 몰려 있었어요. 사진의 위치 정보가 어디선가 손실되고 있었던 거죠. 본문에 자리 표시를 남기고 발행할 때 그 지점에서 이미지를 삽입하도록 수정했습니다.

    또 다른 버그도 찾았습니다. 붙여넣기 성공 여부를 ’50자 이상’이라는 고정값으로만 판정하고 있어서, 짧은 문단이 실패로 감지되면 타이핑 방식으로 넘어갔고 그러면 굵게나 소제목 같은 서식이 모두 사라졌습니다. 이것도 함께 고쳤습니다.

    지금 당신이 얻는 것

    글 쓰는 화면에서 이미지까지 완성해 바로 올릴 수 있습니다. 다른 도구를 켤 필요가 없어요.

    크기 프리셋 덕분에 채널별 이미지를 여럿 만드는 시간이 크게 줄었습니다. 보관함에 저장된 이미지는 추가 크레딧 없이 몇 번이고 재사용할 수 있습니다.

    이미지 때문에 발행이 멈추는 일은 이제 거의 없어요. 완벽하지는 않지만, 실제 운영하면서 나타나는 문제를 계속 고쳐나가고 있습니다.

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

    왜 커뮤니티를 만들었나요

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

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

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

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

    만든 것들은 이래요:

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

    만들다가 겪은 문제들

    한글 주소가 깨졌어요

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

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

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

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

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

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

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

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

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

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

    어떻게 고쳤나요

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

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

    마무리하며

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

  • [파마비아] 앱 심사에 영상을 냈습니다 — 동의 화면 하나 찍는 데 반나절

    왜 영상을 찍게 됐나요

    메타(페이스북·인스타그램·스레드)에 앱 심사를 넣었습니다. 권한 10개를 신청했어요. 승인되면 누구나 자기 계정을 연결해서 글을 자동으로 발행할 수 있게 되는 거죠.

    심사를 넣으려면 ‘이 기능이 실제로 작동하는 모습’을 영상으로 보여줘야 합니다. 권한마다 하나씩요. 특히 두 장면은 필수예요. OAuth 동의 화면과 실제로 게시된 결과. 이 둘이 없으면 거의 반려된다고 보면 됩니다.

    동의 화면이 안 나왔어요

    문제는 동의 화면을 찍을 수가 없었다는 거예요. 🤔

    왜냐하면 저는 이미 한 번 앱을 승인받은 상태였거든요. 그래서 다시 연결을 시도하면 플랫폼이 ‘아, 이미 허용한 앱이네’ 하고 동의 화면을 건너뛰고 바로 연결해버리더라고요.

    첫 번째 영상 찍고, 두 번째 영상 찍고 나서야 깨달았습니다. ‘아, 동의 화면이 안 뜨는구나.’ 반나절이 그렇게 갔어요.

    해결 방법은 의외로 간단했습니다

    페이스북 설정에 들어가서 우리 앱 권한을 삭제했어요. 그리고 다시 연결을 시도하니까 ‘어느 페이지에 접근을 허용할지’ 선택하는 화면이 그대로 나오더라고요. 이제야 찍을 수 있었습니다.

    영상 녹화를 자동화했습니다

    권한이 10개나 되니까 영상을 하나하나 손으로 찍기엔 너무 번거로웠어요. 그래서 스크립트를 짰습니다.

    콘솔 로그인 → 채널 선택 → 글 생성 → 발행 → 결과 확인까지 브라우저가 알아서 돌아가게요. 사람이 해야 하는 로그인이나 허용 클릭 같은 곳에서만 멈춥니다. 화면에는 지금 무엇을 보고 있는지 자막이 뜨게 만들었어요.

    덕분에 영상 10개를 빠르게 찍을 수 있었습니다. ✨

    부수적으로 발견한 것들

    영상을 준비하면서 몰랐던 문제들이 하나씩 드러났어요.

    • 채널 연결이 깨져 있었습니다. 콘솔을 별도 도메인으로 옮기면서 허용 오리진과 콜백 페이지 설정이 어긋나 있었더라고요. 조용히 깨져 있던 거죠.
    • 심사자에게 줄 계정이 없었습니다. 구글 로그인만 있었는데, 그걸로는 계정을 건네줄 수가 없어요. 그래서 이메일 로그인을 새로 붙였습니다.
    • 안 쓰는 권한은 뺐습니다. 댓글 읽기나 자동 답글 같은 기능은 아직 만들지 않았거든요. 쓰지도 않는 권한을 요청하면 심사 전체에 안 좋은 영향을 준다고 하더라고요. 나중에 따로 신청하기로 했어요.

    배운 것 한 줄

    심사는 ‘기능이 있다’를 보여주는 게 아니라 ‘이 화면에서 이렇게 쓴다’를 증명하는 일이더라고요.

    기능을 만드는 것과 그걸 다른 사람에게 보여주는 건 완전히 다른 일이었습니다. 영상 하나 찍는 데 반나절이 걸렸지만, 덕분에 서비스가 더 단단해졌어요. 이제 심사 결과를 기다리고 있습니다. 🙏

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

    왜 게시판을 만들었나

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

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

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

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

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

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

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

    어떻게 나눴나

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

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

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

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

    안전장치도 몇 가지

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

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

    써보니 어떤가

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

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

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

  • [파마비아] AI한테 ‘주제 추천해줘’ 했더니 블로그 운영 팁 10가지가 나온 이유

    블로그를 못 쓰는 진짜 이유는 글쓰기가 아니다

    재활용 기능을 만들어서 예전에 쓴 글을 다시 꺼내 쓸 수 있게 됐어요. 쌓여만 가던 글들이 다시 빛을 보게 된 건 좋았는데, 문제가 하나 남았습니다.

    새로 쓸 주제는 여전히 제 머릿속에서 나와야 한다는 거예요.

    블로그를 꾸준히 못 하는 이유가 ‘글쓰기가 어려워서’라고 생각하기 쉬운데, 실제로는 아니더라고요. 진짜 벽은 ‘오늘 뭘 쓰지?’에서 막히는 겁니다. 주제만 정해지면 쓰는 건 의외로 술술 나가거든요.

    AI한테 물어봤더니 ‘블로그 운영 팁 10가지’

    그래서 AI한테 물어봤어요. “주제 추천해줘.”

    결과는… 뻔했습니다. ‘블로그 운영 팁 10가지’, ‘SNS 마케팅 전략 5가지’, ‘초보자를 위한 콘텐츠 작성법’ 같은 거요. 틀린 말은 아닌데, 아무도 안 쓸 것 같은 주제들이었어요.

    왜 이렇게 나올까 생각해봤는데, AI는 제 블로그를 모르니까요. 그냥 ‘블로그 운영자’라는 일반적인 정보만 갖고 추천하니까 누구한테나 통할 법한, 그러니까 특색 없는 주제가 나오는 거죠.

    그럴 거면 차라리 없는 게 낫겠더라고요.

    마침 며칠 전에 조회수 데이터를 모아뒀다

    그런데 마침 며칠 전에 성과 데이터를 수집하는 기능을 붙여뒀어요. 제 글 중에서 뭐가 잘 됐는지 숫자로 남아 있었습니다.

    363회 읽힌 글, 317회 읽힌 글, 그리고 8회에 그친 글. 뭐가 반응이 좋았는지 명확하게 보였어요.

    그래서 생각했습니다. 이 데이터를 추천에 같이 넣으면 어떨까?

    잘 됐던 글의 결을 이어가되, 소재는 겹치지 않게

    추천 기능을 다시 만들 때 이렇게 바꿨어요.

    • 내 글 중에서 조회수가 높은 글의 내용을 AI한테 같이 보냄
    • “이 사람 글 중 이런 게 반응이 좋았다. 그 결을 이어가되 소재는 겹치지 않게 추천해줘”

    결과가 확 달라졌습니다.

    8개 뽑았는데 8개 다 제 글에서 이어진 주제가 나왔어요. 뻔한 일반론이 아니라, 제가 실제로 쓸 법한 소재들이었습니다. 화면에도 ‘참고한 내 글 · 363회 조회’처럼 근거를 같이 보여줬어요.

    왜냐면 추천을 믿을지 말지는 사용자가 판단할 수 있어야 하니까요. 근거 없는 추천은 아무리 그럴듯해도 그냥 넘기게 되거든요.

    버그도 하나 잡았다

    만들다가 버그를 하나 발견했어요. AI 응답에서 코드 표시를 걷어내는 코드가 ‘json’ 이라는 글자를 못 지우고 있었습니다. 그래서 결과 해석이 깨지고 있었어요.

    다른 기능에도 영향이 있을 수 있어서 바로 고쳤습니다. 이런 게 쌓이면 나중에 원인 찾기 어려워지거든요.

    배운 것: 근거가 보여야 추천이 쓰인다

    이번에 확실히 느낀 건, 추천은 ‘정확도’보다 ‘왜 이걸 추천했는지’가 보여야 쓰인다는 거예요.

    AI가 아무리 똑똑해도, 근거 없이 “이거 써보세요!” 하면 안 믿게 됩니다. 하지만 “당신 글 중에 이게 363회 읽혔고, 이런 결로 가면 좋을 것 같아요”라고 하면 귀 기울이게 되더라고요.

    서비스 만들 때도 마찬가지인 것 같아요. 기능이 뭘 하는지보다, 왜 그렇게 판단했는지를 보여주는 게 신뢰를 만드는 것 같습니다.

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

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

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

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

    화면부터 만들지 않았다

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

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

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

    SNS별로 확인한 것들

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

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

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

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

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

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

    배운 것

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

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

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

  • [파마비아] 잘 되던 기능이 사실은 운이었다 — SNS 자동 발행이 실패한 날

    오전엔 됐는데 오후엔 안 됐다 🤔

    오늘 오전에 SNS 자동 발행 기능 테스트를 했어요. 스레드랑 인스타그램에 예약 발행이 잘 되더라고요. ‘오, 완벽하네!’라고 생각하면서 다른 일을 했죠.

    그런데 오후에 똑같은 코드로 다시 발행을 시도했는데 갑자기 둘 다 실패했어요. 스레드는 ‘요청한 자원이 없다’는 에러를, 인스타그램은 ‘미디어 ID를 쓸 수 없다’는 메시지를 보냈죠. 뭐가 달라진 걸까요? 코드는 그대로인데요.

    문제는 ‘2단계 발행 구조’였다 📝

    원인을 찾아보니까 스레드와 인스타그램은 글을 올릴 때 두 단계를 거친다는 걸 제대로 이해 못 하고 있었더라고요.

    • 1단계: 먼저 ‘컨테이너’라는 걸 만들어요. 글 내용이랑 사진을 업로드하고 준비하는 단계죠.
    • 2단계: 컨테이너가 준비되면 그걸 실제로 게시해요.

    저는 1단계를 시작한 직후에 바로 2단계를 눌러버린 거예요. 그러니까 컨테이너가 아직 준비도 안 됐는데 ‘게시해!’라고 명령한 셈이죠. 당연히 실패할 수밖에요.

    그럼 오전엔 왜 됐을까? 🍀

    이게 핵심이에요. 오전에 성공한 건 제 실력이 아니라 그냥 타이밍이 좋았던 거였어요.

    스레드는 아예 대기 로직이 없었고, 인스타그램은 대기는 했지만 ‘준비 완료’ 직후에도 가끔 실패할 수 있다는 걸 몰라서 재시도 기능이 없었어요. 그러니까 서버가 빨리 처리해주면 성공하고, 조금만 느려도 실패하는 구조였던 거죠.

    성공률이 100%가 아니라 ‘대체로 성공’ 정도였던 건데, 사용자 입장에선 실패해도 모르니까 저도 문제를 몰랐던 거예요. 무서운 일이죠.

    어떻게 고쳤을까? 🔧

    이제 제대로 고쳤어요. 방법은 간단했어요.

    • 컨테이너를 만든 뒤 상태를 계속 확인해요.
    • 준비될 때까지 기다린 다음에 게시 버튼을 누르죠.
    • 그래도 실패하면? 몇 초 간격으로 최대 세 번까지 재시도해요.

    단, 토큰이 잘못됐거나 권한이 없는 것 같은 ‘진짜 실패’는 재시도하지 않아요. 그런 건 계속 시도해봤자 똑같이 실패하니까 바로 알림을 보내는 게 낫더라고요. 무의미한 재시도는 문제를 숨길 뿐이에요.

    배운 것 💡

    ‘되는 걸 봤다’와 ‘항상 된다’는 완전히 다른 말이에요. 특히 남의 서버를 거치는 기능은 성공하는 걸 한두 번 본 것만으로 검증했다고 착각하기 쉬워요.

    오늘처럼 타이밍 운으로 성공하는 경우도 있고, 서버 상태에 따라 결과가 달라지는 경우도 있죠. 한 번 성공했다고 안심하지 말고, 실패 상황도 꼭 가정해보고 대비해야 한다는 걸 다시 한번 느꼈어요.

    1인 개발자로 서비스 운영하다 보면 이런 일이 종종 생기더라고요. 여러분도 혹시 ‘잘 되고 있다고 믿는’ 기능이 있다면 한 번쯤 의심해보세요. 저처럼 운이 좋아서 된 건 아닌지요 😅

  • 자동 업데이트가 자동이 아니었다 — 하루 동안 메운 빈 곳들

    오늘은 새로운 기능을 만들기보다, 이미 ‘된다’고 생각했던 것들의 빈 곳을 메운 하루였습니다. 서비스를 운영하다 보면 이런 날이 꼭 필요하더라고요. 겉으로는 잘 돌아가는 것 같아도, 막상 들여다보면 ‘어? 이게 왜 이렇게 되어 있지?’ 싶은 부분들이 보이거든요.

    1. 자동 업데이트가 사실은 반자동이었다 🔄

    가장 먼저 손본 건 자동 업데이트였습니다. 사용자분들께 ‘자동 업데이트’라고 안내했는데, 알고 보니 새 버전이 나와도 사용자가 직접 배너를 눌러야 적용되는 구조였어요. 이건 반자동이지, 자동이 아니잖아요.

    왜 문제였나요?
    사용자 입장에서는 배너를 놓치거나 무시하면 계속 구버전을 쓰게 됩니다. 버그 수정이나 개선 사항이 반영 안 되는 거죠.

    어떻게 고쳤나요?
    앱을 켜는 순간 자동으로 업데이트를 받아서 교체하고 재시작하도록 바꿨습니다. 다만 작업 중에 갑자기 재시작되면 곤란하니까, 앱을 켠 직후에만 자동으로 진행하도록 했어요. 그리고 한 가지 더—교체가 실패한 버전은 기록해뒀다가, 다음에 켤 때 다시 시도하지 않게 했습니다. 무한 루프에 빠지는 걸 막기 위해서요.

    2. SNS에 블로그 링크가 안 들어가고 있었다 🔗

    두 번째는 SNS 자동 발행 문제였습니다. 스레드, 페이스북, 인스타그램에는 글이 잘 나가는데, 정작 원문 블로그 링크가 빠져 있었어요. 유입 경로가 아예 없던 셈이죠.

    왜 문제였나요?
    SNS 글만 보고 끝나면 블로그 방문자는 늘지 않습니다. 더 자세한 내용이 궁금한 사람도 찾아올 방법이 없고요.

    어떻게 고쳤나요?
    블로그를 먼저 발행해서 주소를 받은 다음, 그 주소를 스레드·페이스북·인스타 글 끝에 자동으로 붙이도록 순서를 바꿨습니다. 예약 발행도 마찬가지인데요, 블로그가 아직 안 올라간 상태면 실패시키지 않고 1분 뒤에 다시 시도하도록 했어요.

    3. 발행 직전에 잡은 버그 🐛

    발행 테스트 중에 아찔한 걸 하나 발견했습니다. 링크가 없을 때 ‘자세한 내용은 여기 👉 {link}’ 같은 자리표시자가 그대로 올라갈 뻔했어요. 실제 계정에 나가기 전에 잡아서 정말 다행이었습니다.

    4. 비용 새는 구멍을 막았다 💸

    네 번째는 비용 관리였습니다. AI 글 생성 기능이 있는데, 데스크톱 앱과 예약 발행에서는 사용량 차감이 안 되고 있었어요.

    왜 문제였나요?
    사용자는 무료로 쓰고, 저는 API 비용만 계속 나가는 구조였습니다. 이건 지속 가능하지 않죠.

    어떻게 고쳤나요?
    두 곳 모두 크레딧 차감 로직을 붙였고, 잔액이 없으면 AI를 부르기 전에 미리 막도록 했습니다. 다만 예약 발행은 AI 없이도 기본 변환으로라도 나가게 해뒀어요.

    5. 앱에서 스레드·인스타 등록이 안 됐다 📱

    다섯 번째, 웹에서는 스레드와 인스타그램 계정을 등록할 수 있는데 앱에는 ‘준비 중’이라는 표시가 그대로 남아 있었습니다. 기능은 이미 다 만들어졌는데 문만 안 열어둔 셈이었어요. 오늘 열어뒀습니다.

    6. 크레딧 사용 로그를 만들었다 📊

    마지막으로 관리자 화면에 크레딧 사용 로그를 추가했습니다. 누가 언제 무엇으로 얼마를 썼는지 안 보이면, 정산도 문의 대응도 제대로 할 수 없거든요. 사용자 화면에도 본인 사용 내역을 볼 수 있게 붙여뒀습니다.

    마무리 ✨

    오늘 하루는 화려한 신기능보다, 이미 ‘된다’고 생각했던 것들의 빈 곳을 메운 날이었습니다. 자동 업데이트는 진짜 자동이 되었고, SNS 글에는 블로그 링크가 붙었고, 비용 누수는 막았고, 숨겨뒀던 기능은 열었고, 사용 내역은 보이게 만들었어요.

    서비스 운영이란 게 이런 거구나 싶습니다. 새로운 걸 계속 만드는 것도 중요하지만, 이미 만든 것들이 제대로 돌아가는지 점검하고 다듬는 시간도 꼭 필요하더라고요. 오늘 같은 날이 쌓여야 서비스가 탄탄해지는 것 같습니다 😊