다음 리뷰를 고르다가, Geek Story의 방향을 다시 생각했다

다음에 무엇을 리뷰할까

첫 리뷰 다음에 다룰 대상으로 Drifty(드리프티)를 골랐다. 윈도우 버전이 나오기 전부터 사용해 온 서비스다. 꾸준히 사용해 온 만큼 실제 경험을 바탕으로 쓸 이야기가 있다고 생각했고, Geek Story에서 꼭 한 번 리뷰해보고 싶었다.

다음 리뷰를 준비하면서 첫 리뷰와는 조건이 다르다는 것을 생각하게 됐다. Filee는 소스코드를 읽을 수 있는 오픈소스였지만, Drifty는 오픈소스가 아니었다. 첫 리뷰의 구성을 그대로 가져올 수는 없었다.

Filee의 코드를 따라가는 데 시간이 오래 걸렸다

Filee 리뷰에서는 소스와 프로젝트 문서를 따라가며 동작을 뒷받침하는 구조를 살펴봤다. 변환 경로 탐색과 작업 큐, 각 구성요소의 책임을 읽고 설계의 의미와 한계를 정리하는 데 많은 비중을 뒀다. 사용 장면도 담았지만, 글의 중심은 코드와 문서 분석이었다. 실제 변환 결과의 품질이나 안정성은 별도로 확인해야 할 부분으로 남았다.

소스가 공개돼 있다고 분석이 쉬운 것은 아니었다. 나도 모르는 부분이 많았고, 코드를 읽고 이해하는 데 시간이 오래 걸렸다. 내용을 설명하려면 먼저 내가 이해해야 했기에 글을 쓰는 과정도 힘들었다.

Geek Story에서는 직접 써본 서비스가 어떤 도구인지, 무엇이 좋았고 왜 눈길이 갔는지를 소개하고 싶었다. Filee에서는 구현을 깊게 살펴보는 쪽으로 글이 이어졌다. 그 과정에서 배운 것도 있지만, 같은 방식으로 계속 리뷰할 수 있을지는 다시 생각해야 했다.

Drifty에서는 직접 확인할 수 있는 것을 근거로

Drifty에서는 Filee처럼 소스코드를 따라가며 내부 구조를 분석할 수 없었다. 대신 내가 사용하면서 알게 된 서비스의 특징과 좋았던 점, 처음 관심을 갖게 된 이유를 중심으로 쓰려 했다.

사용 소감에 더해 성능 테스트도 해볼 수 있지 않을까 생각했다. 하지만 어떤 방식으로 테스트할지는 아직 모르겠다. 비슷한 프로그램으로 무엇이 있는지부터 잘 몰라, 비교 대상과 기준도 정하지 못했다. 현재로서는 테스트를 하겠다는 확정된 계획보다, 사용 경험 외에 어떤 근거를 더 담을 수 있을지 고민하는 단계다.

Filee에서 코드로 확인한 구조와 Drifty를 사용하거나 테스트해서 확인할 동작은 근거가 다르다. 소스를 읽었다고 실제 성능까지 확인한 것은 아니고, 사용 중 빠르게 느껴졌다고 내부 구현의 이유까지 알 수 있는 것도 아니다. 각 리뷰에서 무엇을 확인했는지 구분해서 보여줘야 한다.

Geek Story는 어떤 리뷰를 다루려는가

이 차이를 생각하다 보니 Geek Story가 리뷰를 다루는 방식에도 질문이 생겼다. 코드와 문서를 분석한 글, 사용 경험을 정리한 글, 성능을 테스트한 글을 모두 리뷰라고 부를 수 있다. 하지만 독자가 각 글에서 기대할 수 있는 내용과 확인된 범위는 서로 다르다.

첫 리뷰의 구성을 앞으로 모든 글의 기준으로 삼아도 될까? 소스가 공개된 프로젝트와 직접 사용하는 서비스를 같은 항목으로 평가하는 것이 적절할까? 특정 작업에서 얻은 만족을 제품 전체에 대한 평가처럼 전달하고 있지는 않을까?

특히 내가 계속 쓰는 도구를 고르면 리뷰 대상부터 내 취향이 반영된다. 오래 사용했다는 사실은 구체적인 경험을 쓸 수 있는 바탕이지만, 평가가 균형 잡혔다는 근거가 되지는 않는다. 좋았던 점과 아쉬웠던 점 모두 어떤 상황에서 그렇게 느꼈는지 설명해야 하고, 내게 잘 맞았던 조건이 다른 사람에게도 적용되는지 살펴봐야 한다.

Geek Story에서 리뷰를 다룬다면 이런 차이를 독자가 알아볼 수 있어야 한다고 생각했다. 무엇을 직접 확인했고 무엇을 문서나 코드에서 읽었는지, 어떤 환경과 범위에서 판단했는지 글 안에서 드러내야 한다. 분석과 사용 경험을 어떻게 구분해 보여줄지, 서로 다른 범위의 리뷰에 같은 평점 기준을 적용해도 되는지도 다시 고민할 부분이다.

아직 기준을 모두 정한 것은 아니다. 다만 리뷰를 더 쉽게 쓰는 방법을 찾는 것과 함께, 독자가 그 글의 판단을 어디까지 받아들일 수 있는지 설명하는 방법도 찾아야 한다.

우선 내가 사용한 경험부터

Drifty 리뷰에서는 다음 내용을 담으려 한다.

• 어떤 서비스이고, 왜 처음 눈길이 갔는가?
• 어떤 상황에서 사용했고, 무엇이 좋거나 불편했는가?
• 그 경험과 결과를 바탕으로 어떤 사람에게 권할 수 있는가?

우선 좋았던 점과 불편했던 점을 실제 사용 상황과 함께 정리하려 한다. 그 과정에서 더 확인하고 싶은 질문이 생기면 비교나 측정이 도움이 될지 살펴볼 생각이다. 테스트를 넣기 위해 비교 대상을 억지로 고르거나, 체감만으로 성능이 더 좋다고 쓰지는 않으려 한다. 측정을 하게 된다면 조건과 결과를 사용 소감과 구분해 남겨야 한다.

소스가 없는 상태에서 확인하지 못한 내부 구조를 추정해 설명하기보다, 직접 확인한 동작과 결과 안에서 판단하려 한다. 특정 환경에서 얻은 결과를 서비스 전체의 성능이나 안정성으로 확대하지 않는 것도 필요하다.

후보를 찾는 곳도 넓혀보기

리뷰 후보를 찾는 방법으로 Product Hunt도 생각했다. 새로 올라온 제품을 살펴보고, 관심 가는 도구를 직접 사용해보면 글감이 생길 것 같았다.

다른 발견 경로도 함께 살펴봤다. GeekNews에서 관심 있는 도구를 만나거나, AlternativeTo에서 지금 쓰는 앱의 대안을 찾아볼 수 있다. BetaList와 Show HN도 후보를 찾는 데 참고할 수 있겠다.

이곳들은 후보를 발견하는 출발점으로 활용하려 한다. 순위가 높거나 새로 나왔다는 이유만으로 리뷰할 필요는 없다. 내 작업에 써볼 이유가 있고, 핵심 기능을 직접 경험할 수 있는지가 먼저다.

기존에 쓰던 도구의 대안을 시험해보는 것도 좋은 출발점일 것 같다. 익숙한 작업을 새 도구로 해보면 무엇이 달라졌는지 이야기하기가 더 자연스럽다.

방향을 바꾸는 과정도 기록하기

아직 새로운 방식으로 여러 편을 써보고 확인한 것은 아니다. Drifty 리뷰에서는 먼저 왜 관심이 갔고 실제로 어떻게 사용했는지를 구체적으로 설명해보려 한다. 성능 테스트를 포함할지와 어떤 방법이 적절할지는 아직 열어두고 있다. 그 과정이 코드 분석 중심의 첫 리뷰보다 지속하기 쉬운지도 살펴볼 생각이다. 아직 작성 부담이 줄었다거나 새로운 방식이 더 낫다는 결론을 내린 것은 아니다.

그 결과를 바탕으로 Geek Story의 소개와 리뷰 기준도 다듬을 생각이다. 이번 글에는 기준을 확정하기에 앞서 방향을 다시 고민하게 된 과정을 남겨둔다.