[2026년 07월 27일 월요일] 최종프로젝트 (16)

• 컨디션: 그럭저럭..

오늘 한 일

✅ 개발자 커뮤니티에 구구레터 사용성 피드백 요청
✅ PRD v2.0 후속 확장 단계별 내용 리뷰
✅ PRD v2.0 서비스 정책에 튜터 피드백 반영

• 발신자 정보 노출 정책 구체화
• 개인정보 수집·이용 범위 정리
  ✅ 욕설·유해 표현 탐지 웹훅 구현 및 정책서 반영
  ✅ 최종 브로셔 본문 v1 리뷰
  ✅ PRD v2 튜터님 피드백 확인 및 반영 방향 정리
  ✅ 업무일지를 문제·판단·결과 중심으로 작성하는 방법 점검

---

정책서 수정

오늘은 구구레터의 정책과 운영 기능을 정리하고, 최종 산출물을 점검했다.

먼저 튜터님 피드백을 바탕으로 서비스 정책을 다시 살펴봤다. 기존 문서에서는 쪽지 작성자의 정보가 수신자에게 어떻게 노출되는지, 악성 쪽지가 들어왔을 때 어떤 방식으로 대응하는지가 충분히 구체적이지 않았다.

이를 보완하기 위해 발신자 정보 노출 정책을 정리했다.

구구레터에서는 카카오 계정 닉네임이 그대로 노출되는 것이 아니라, 사용자가 쪽지를 작성할 때마다 From 닉네임을 직접 입력한다. 수신자에게는 해당 닉네임만 보여주고, 이메일과 같은 계정 식별 정보는 노출하지 않는다. 다만 신고나 운영 대응이 필요한 경우를 대비해 서비스 내부에서는 발신 계정을 확인할 수 있도록 정책을 구분했다.

악성 메시지에 대한 운영 안전장치도 추가

쪽지가 저장된 이후 욕설, 모욕, 협박 등 사전에 정의한 표현을 규칙 기반으로 탐지하고, 의심되는 메시지가 발견되면 관리자 Slack 채널로 알림을 보내는 웹훅을 구현했다.

탐지됐다는 이유만으로 쪽지를 자동 삭제하거나 숨기지는 않는다. 규칙 기반 필터는 문맥을 완전히 이해할 수 없어 오탐과 미탐이 발생할 수 있기 때문이다. 최종 판단은 관리자가 원문과 앞뒤 맥락을 확인한 뒤 내리고, 문제가 있는 경우 수동으로 숨김 처리하도록 정리했다.

기존 정책서에는 금지어 필터가 MVP에 포함되지 않는다고 작성되어 있었지만, 실제 구현은 발송 전 차단이 아니라 발송 후 관리자 검토를 돕는 사후 모니터링에 가까웠다. 따라서 문서도 현재 구현 방식과 일치하도록 수정했다.

이 밖에도 PRD v2.0의 후속 확장 단계를 리뷰하고, 개인정보 수집 및 이용 범위를 수집 경로별로 구분했다. 최종 브로셔 본문을 검토하고, 개발자 커뮤니티에도 구구레터 사용성 피드백을 요청했다.

업무일지를 쓰는 방법을 다시 배웠다

오늘 가장 크게 남은 것은 기능이나 정책보다 업무일지를 작성하는 방식에 대한 생각이었다.

그동안 업무일지는 주로 오늘 무엇을 했는지 남기는 기록에 가까웠다.

• 정책서를 수정했다.
• 웹훅을 추가했다.
• 브로셔를 검토했다.
• PRD를 리뷰했다.

이렇게 적으면 당시에는 일을 많이 했다는 사실이 보인다. 하지만 시간이 지나 다시 보면 왜 그 일을 했는지, 어떤 문제를 발견했는지, 내가 무엇을 판단했는지는 거의 남아 있지 않는다.

오늘 업무일지를 더 잘 쓰는 방법을 정리하면서, 단순한 작업 목록보다 다음 흐름이 중요하다는 것을 알게 됐다.

• 어떤 상황과 문제가 있었는가
• 왜 해당 문제가 중요하다고 판단했는가
• 가능한 방법 중 무엇을 선택했는가
• 실제로 무엇을 실행했는가
• 그 결과 무엇이 달라졌는가
• 다음에는 무엇을 확인해야 하는가

예를 들어 오늘 한 일을 단순히 ‘욕설 필터링 웹훅 추가’라고 적으면 기술 작업 하나만 남는다.

하지만 실제 업무는 그보다 복잡했다.

외부에 공유되는 홈 링크를 통해 악성 메시지가 유입될 가능성이 있었고, 자동 차단은 정상적인 메시지까지 막을 위험이 있었다. 따라서 발송 자체를 막기보다 의심 메시지를 탐지해 관리자에게 전달하고, 사람이 맥락을 확인한 후 숨김 여부를 결정하는 방식을 선택했다. 이렇게 기록해야 문제와 판단, 실행 사이의 연결이 남는다.

이 방법을 조금 더 일찍 알았다면 좋았을 것 같다는 아쉬움이 컸다.
부트캠프를 진행하면서 정말 많은 일을 했다. 문제를 발견하고, 팀원들과 논의하고, 데이터를 다시 확인하고, 기능과 정책을 수정한 날도 많았다.

하지만 당시에는 결과물을 완성하는 데 급해서 작업명과 완료 여부만 기록한 경우가 많았다. 지금 이력서와 포트폴리오를 준비하려고 보니, 결과물은 남아 있어도 내가 어떤 판단을 했는지는 다시 기억을 더듬어야 한다.

‘PRD 작성’, ‘QA 진행’, ‘지표 설정’만으로는 내가 무엇을 고민했고 어떤 역할을 했는지 설명하기 어렵다.

특히 PM 이력서에서는 단순히 어떤 문서를 만들었는지가 아니라, 어떤 문제를 발견하고 어떤 기준으로 해결 방향을 정했는지가 중요하다. 그때의 판단을 제대로 남겨두지 않으면 실제로 많은 고민을 했더라도 나중에는 단순 작업 수행처럼 보일 수 있다.

이미 지나간 업무를 전부 다시 복기할 수는 없기 때문이다. 당시에는 너무 당연했던 맥락도 시간이 지나면 사라지고, 팀원들과 나눴던 대화나 선택하지 않은 대안도 점점 기억나지 않는다. 그래도 지금이라도 알게 된 것이 다행이라고 생각하려 한다.
앞으로는 업무를 완료한 뒤 한 줄이라도 다음 내용을 남기려고 한다.

어떤 문제를 보고, 무엇을 판단했고, 그 판단으로 무엇이 달라졌는가.

업무일지는 하루를 성실하게 보냈다는 것을 증명하는 기록만은 아니다.
나중의 내가 당시의 판단을 다시 이해할 수 있게 하고, 이력서나 포트폴리오에서 내 경험을 과장 없이 설명할 수 있게 만드는 자료다.

오늘은 특별히 큰 성과가 있었던 날은 아니었다. 정책과 문서를 점검하고, 이미 진행한 일을 정리한 하루에 가까웠다. 하지만 앞으로의 기록 방식을 바꿀 기준 하나를 얻었다.

조금 늦게 알았다는 아쉬움은 남지만, 이제부터는 한 일보다 그 일을 한 이유와 판단을 더 잘 남겨보려고 한다.