내가 만든 서비스를 내가 쓰다가, "이거 당연히 이렇게 되어야 하는데?"라고 생각한 게 있었다. 구현을 시키기 전에 습관처럼 "먼저 구조부터 확인하고 멈춰"라고 했다. 돌아온 답이 내 직감이 틀렸다고 알려줬다. 그대로 시켰으면 잘못된 설계를 아주 정확하게 구현할 뻔했다.
관심사를 "별"로 만들어 모으는 커뮤니티를 혼자 만들고 있다. 별에는 이름과 태그가 있다. 얼마 전 별 이름 수정 기능을 붙였는데, 쓰다 보니 태그는 못 고친다는 걸 알았다.
그리고 바로 이렇게 생각했다.
별 이름이 바뀌면 태그도 같이 바뀌어야 하는 거 아닌가?
당연해 보였다. 내 화면의 "여행" 별은 태그도 "여행"이었다. 하나처럼 보였다. 이름 고치면 태그도 따라가는 게 자연스럽지.
바로 시키지 않고 먼저 물었다. "태그 구조가 어떻게 돼 있는지 확인하고, 결과랑 제안만 보고하고 멈춰."
돌아온 답:
tags 테이블 + 정션 두 개(star_tags, post_tags)로 되어 있다.이미지 불러오는 중…
그럼 왜 내 화면에선 이름과 태그가 같았나. 가입할 때 관심사를 하나 받아서 이름에도 태그에도 똑같이 넣어주기 때문이었다. 초기값의 우연이었다. 나는 그 우연을 보고 "둘이 연결돼 있다"고 읽었다.
그리고 결정적인 한 마디가 따라왔다.
자동 연동은 하면 안 됩니다. 이름과 태그는 목적이 다릅니다.
이 둘을 묶으면? "여행" 별을 "세계여행 로그 ✈️"로 고치는 순간 태그도 바뀌고, "여행"으로 검색하던 사람은 이 별을 못 찾게 된다. 사용자는 표시 이름만 고친 줄 안다. 발견성이 사라진 걸 모른다. 알려주지도 않는다.
내 직감대로 구현했으면 정확히 이 동작을 만들었을 것이다. 그리고 한참 뒤에 "왜 내 별이 검색에 안 잡히지?" 하고 다시 파고들었겠지.
감사에서 부수적으로 확인된 것. 내가 우려한 부작용 중 없는 게 있었다.
별 태그를 바꾸면 그 별의 글들 태그가 대량으로 바뀌는 게 아닐까 싶었다. 아니었다. 글 태그는 별 태그와 독립이라 서로 영향이 없다. 연결도 안전했다 — 사람 사이 연결은 태그가 아니라 별 ID로 걸려 있어서, 태그를 어떻게 바꿔도 기존 관계가 끊기지 않았다.
즉 걱정의 절반은 실체가 없었고, 정작 진짜 위험(발견성 소실)은 내가 생각도 못 한 쪽에 있었다.
자동 연동은 버리고, 태그를 직접 편집하게 했다. 이름과 태그를 각각 따로 고친다.
부작용이 아예 없진 않다. 태그를 지우면 그 태그로 오던 유입이 끊긴다. 하지만 사용자가 직접 지운 것이라 결과를 예상할 수 있다. 이름을 고쳤는데 태그가 몰래 바뀌는 것과는 질이 다르다.
다만 내 직감이 완전히 헛것은 아니었다. 별의 주제 자체가 바뀌는 경우가 있다. "여행" 별을 "등산"으로 고쳤는데 태그가 "여행"이면, 이제 태그가 거짓말을 한다. 그래서 이름 수정 직후에 "주제가 바뀌었다면 태그도 확인해보세요"라는 가벼운 안내를 띄운다. 자동으로 바꾸진 않고, 통제는 사용자에게, 잊지만 않게.
AI에게 코딩을 맡기면서 굳어진 습관이 하나 있다. 바로 시키지 않고 먼저 물어보는 것.
이번에 한 건 "태그도 같이 바뀌게 해줘"가 아니라 "구조부터 확인하고 결과만 보고 멈춰"였다. 그랬더니 내 전제가 틀렸다는 답이 왔다. 바로 시켰다면? 아마 잘 구현됐을 것이다. 요구대로 정확하게. 잘못된 요구를 잘 구현한 결과물이.
이게 AI로 개발할 때 진짜 리스크 같다. 못 만드는 게 아니라, 내가 잘못 생각한 걸 너무 잘 만들어주는 것.
그리고 이 일에서 AI가 잘한 건 코드를 쓴 게 아니었다. 스키마를 읽고 내 전제를 반박한 것이었다. 나는 화면에 보이는 표면(이름과 태그가 같아 보임)을 패턴으로 읽었고, AI는 구조를 읽었다. 사람이 표면을 보고 AI가 구조를 보는 이 분업이, 요즘은 코드 생성보다 더 쓸모 있게 느껴진다.
혼자 만드는 관심사 커뮤니티를 개발하며 겪은 일들을 기록합니다. → galaxyconstellate.com