“돌아간다”는 사실이, 더 이상 충분하지 않다고 느꼈을 때
개발편 1까지의 INSK는 분명히 '돌아가는' 서비스였다.
인증이 있었고, 자동화된 뉴스 수집 파이프라인이 있었고, 배포와 캐시까지 얹혀 있었다. 겉으로 보기엔 부족함이 없어 보였다.
하지만 직접 쓰기 시작하면서, 그리고 다른 사람의 입장에서 다시 바라보면서 한 가지가 계속 걸렸다.
이 서비스는 ‘누구를 위한 서비스인가?’라는 질문에 답하지 못하고 있었다.
기능은 많았지만, 흐름은 없었다.
기술적으로 가능한 것들을 하나씩 붙여 나가다보니, 사용자가 실제로 무엇을 기대하는지는 뒤늦게 생각하고 있었다.
기능 중심 개발의 한계가 드러난 순간
가장 먼저 느낀 문제는 진입 지점이었다.
로그인을 하고 나면 사용자는 무엇을 해야 하는지 바로 알기 어려웠다. 키워드, 기사, 점수, 추천 기능은 있었지만 '왜 이게 나에게 필요한지'가 드러나지 않았다.
그제서야
지금까지의 개발은 “구현할 수 있는 것”을 기준으로 쌓아 올린 구조였고,
“사용자가 어떤 순서로 이 서비스를 쓰는지”를 고려하지 않았다는 것을 깨닳았다.
그래서 방향을 바꿨다.
기존 구조 위에 기능을 더 얹는 대신, 사용자 기준으로 전부 다시 잘라보기로 했다.
다시 정의한 기준: 사용자 흐름부터
개발편2에서 가장 먼저 한 일은 기능 추가가 아니었다.
“사용자가 처음 접속했을 때부터, 이 서비스를 떠날 때까지 어떤 흐름을 타야 하는가”를 다시 그리는 일이었다.
그 결과 몇 가지 원칙이 생겼다.
-
인증은 단순한 보안 기능이 아니라, 개인화의 출발점이어야 한다
-
키워드는 설정 화면이 아니라, 이 서비스의 필터 엔진이어야 한다
-
뉴스 수집과 분석은 보여주는 기능이 아니라, 뒤에서 조용히 돌아가는 엔진이어야 한다
-
점수와 추천은 설명 없이도 납득 가능한 결과여야 한다
이 기준에 맞지 않는 기능들은 과감하게 밀어냈고, 남길 기능들만 다시 설계했다.
사용자 중심으로 다시 정리된 기능들
이 과정에서 INSK는 v3.0 구조로 정리됐다.
중요한 건 “기능이 늘었다”가 아니라, 각 기능이 맡은 역할이 명확해졌다는 점이다.
사용자는 로그인과 동시에 자신의 부서와 키워드를 기준으로 개인화된 서비스를 이용할 수 있다. 키워드는 단순 입력 값으로 쓰이는 것은 아닌, 이후 모든 기사 필터링과 점수 계산의 기준이 되도록 했다. AI 기반 키워드 추천은 선택사항으로 두되, 승인 과정을 거쳐야만 실제 서비스에 반영되도록 했다. 무분별한 자동화는 오히려 신뢰를 해친다고 판단했기 때문이다.
뉴스 수집과 분석 파이프라인은 여전히 서비스의 핵심이지만, 더 이상 전면에 드러나지 않게 했다.
사용자가 “분석 버튼”을 누르지 않아도, 내부에서는 자동으로 요약·분류·중복 제거·점수 계산이 이루어진다. 이 기능은 보여주기 위한 기능에서, 쓰이기 위한 기능으로 역할이 바뀌었다.
기사 조회 역시 마찬가지다.
목록과 상세 화면에서 사용자는 점수, 요약, 인사이트를 자연스럽게 소비할 뿐, 그 점수가 어떻게 계산됐는지를 알 필요는 없다. 좋아요/싫어요와 간단한 피드백만으로도 추천 결과에 영향을 줄 수 있도록 설계했다.
부서별 Top5 기능은 이 흐름의 결과물이다.
개별 사용자의 키워드를 넘어, 조직 단위로 “지금 이 부서가 봐야 할 뉴스”를 한 번에 보여주기 위한 장치였다. 기능을 추가했다기보다, 서비스의 목적을 한 줄로 요약한 화면에 가깝다.
기능 구현 이후, 남아 있던 불안
여기까지 오고 나서야, INSK는 처음으로 “서비스처럼 보이는 형태”를 갖추게 됐다.
기능 구현을 모두 마친 뒤, 한동안은 이 구조를 그대로 두고 써봤다.
큰 문제 없이 돌아갔고, 원하는 결과도 나왔다.
LLM 호출 비용은 아직 감당 가능한 수준이었고, 트래픽도 크지 않았다.
그래서 지금 구조가 꽤 괜찮다고 생각했다.
이 시점까지는 '여기서 더 손볼 이유가 있을까' 라는 생각이 들어서 완성됐다고 판단했었다.
다만 그 판단이 실제 운영을 전제로 한 결론인지,
아니면 아직 문제가 드러나지 않았을 뿐인 상태인지는 구분하기 어려웠다.
잘 작동하는 구조였지만, 그 판단 기준이 전부 개발자 입장이었기 때문에 고려하지 못한 측면이 있을 것이라고 생각했다.
특히 불안했던 건, 중요한 결정 대부분이 경험이 아니라 가정 위에 서 있다는 점이었다.
요약과 분류는 이 정도 호출 빈도면 충분할 거라 생각했고,
동시 요청 역시 나중에 오면 그때 고민하자며 넘겨왔다.
지금 당장은 아무 일도 일어나지 않았지만, 그게 구조가 안전하다는 증거는 아니었다.
이 상태로 더 기능을 얹는 건 의미 없다고 느꼈다.
다음 단계로 가려면, 무엇을 더 만들 것인지 보다
“지금까지 당연하게 둔 전제 중 무엇이 틀렸는가”를 먼저 확인해야 했다.
그래서 다시 외부의 시선을 요청했다.
기능 설명이 아니라, 구조 전체를 놓고 실제로 이 프로젝트를 굴릴 수 있겠는지를 묻고 싶었다.
SK 초청 시 만나뵙고 피드백을 받았던 개발자님께 다시 연락을 드렸다.
그리고 며칠 후 돌아온 피드백은,
내가 안정적이라고 믿고 있던 이 구조가
운영 관점에서는 아직 검증되지 않은 선택들의 집합에 가깝다는 점을 정확히 짚고 있었다.
이제 다음 단계에서는 기능을 추가하지 않고,
이 구조를 가능하게 만든 전제부터 하나씩 부숴보려 한다.
개발편 3에서 이어진다.
INSK_V3
github : https://github.com/gm-15/INSK
시연영상 : https://youtu.be/WlKGbvbxHik
