서론

내가 이 프로젝트의 아이디어를 얻게된 계기를 남기려 한다.

사건의 발단은 코드포스다.

코드포스 대회를 치다가 해시 저격을 당했다.
당한게 한두번이 아니였기 때문에 더 이상은 당하고만 있을 수 없다며 해시 충돌에 대해 열심히 공부하기 시작했다. 더 자세한 이야기는 여기서 확인할 수 있다.

글을 쓰기 위해 이코드 저코드 보면서 공부하던 도중,

어라 이거 이상한데,
파이썬 코드를 구경하다가 깨진 링크를 발견했다.

파이썬의 정수에서 해시 사용은 충돌이 발생할 가능성이 있고, 이 충돌을 발생시키는 데이터를 만드는 것은 어렵지가 않다. 결국 파이썬 정수에서 해시를 사용하려면 해시 랜덤화를 한다던가 문자열로 바꿔서 사용해야 한다.

그러다가 러스트 쓰면 해시 충돌이 없다는 바이럴을 보고 러스트 코드를 보기 시작했다.

어라 이거 이상한데,
러스트 코드를 구경하다 깨진 링크를 발견했다.

이 깨진 링크를 변경하는 PR을 올렸더니 리뷰어가 이런 답변을 주셨다.

이렇게 기여가 조금씩 쌓이다보니 이걸 자동으로 해주는 서비스가 없다는 것을 알았다.

찾아보니 링크가 유효한지 판단해주는 서비스는 몇몇 존재하기는 했다. 이 서비스에 대해 조사하던 중 러스트로 쓰여진 lychee라는 서비스를 알게되었고, 일단 러스트로 만들어졌다는 거에 호감도 10점을 먹고 lychee를 사용하며 테스트해 보기 시작했다.

로컬에 설치하고 사용해보는데,

어라 이거 이상한데,
자기네들 README.md 에도 깨진 링크가 있었다.

굉장히 아이러니 한 상황이다.

본론

이제 문제점은 찾았다. 이런 링크 체크 서비스가 있어도 단순히 올바르지 않다는 것만을 알려주기 때문에 누군가 변경하지 않는 이상 계속 실패한다. lychee에 GitHub 액션 리스트를 보면 link check CI가 계속 실패하고 있었다. 그리고 끝이였다. 실패했다는 것을 인지하기만 하고 그 실패를 해결하기 위한 액션이 취해지지 않았다.

문제 정의

문제는 명확해졌다. Repository에 있는 깨진 링크가 자동으로 업데이트 되지 않고 있다. 그럼 이 문제가 해결할 필요가 있는 문제인지 생각해보자.

이것을 참조하라는 의미로 링크를 달곤한다. 가끔 GPT에서도 답변을 할 때 자신이 참고한 레퍼런스 링크를 제공할 때가 있다. 그런데 이 링크도 깨진 경험이 종종있다. 그럴때마다 GPT가 답변해준 내용을 신뢰하기가 어려워진다.

깨진 링크는 아무런 정보를 제공해주지 않는다. 다시말해 깨진 링크는 해결할 필요가 있는 문제이다.

내가 만들고자 하는 서비스는 이 문제점을 해결하고자 한다. 단순히 링크가 유효한지 판단하는 것에서 멈추는 것이 아니라 깨진 링크를 올바른 링크로 변경해주는 작업을 하는 서비스다.

예상하고 있는 플로우다.

사용자가 GitHub Repository URL을 입력한다.
해당 Repository에 있는 파일에서 링크를 추출한다.
추출한 링크가 유효한지 파악한다.
유효하지 않은 링크를 대체할 올바른 링크를 찾는다.
찾은 링크로 변경하는 Pull Request를 달린다.

이게 이 프로젝트의 로직이다.

프로젝트의 아이디어를 정했으니 이제 이름을 정할 차례다.

이름의 유래

우리 서비스가 하는 핵심적인 기능은 Repository에서 링크 파싱, 링크 체크, 유효한 링크로 변경이다. 여기서 링크 체크라는 단어에서 아이디어를 얻었다. check는 체스에서 킹을 공격한다는 의미다. (장기에서는 장군)
체스를 이기기 위해서는 체크 메이트를 만들어야 한다. 체크를 당한 킹이 피할 곳이 없고 또 방어 불능 상태가 체크 메이트이다. 다시 말하면 다른 기물 다 던져도 체크 메이트만을 만들 수 있다면 된다. 그래서 많은 체스인들이 기물희생에 열광한다. 특히 이중에서 기물 점수가 제일 높은 퀸 희생에 소름 돋아하는데, 내 퀸을 주고 상대방의 킹을 취하는 전술이 바로 퀸희생 Sacrifice the Queen이다.

설명이 길어졌는데 정리해보자면,
링크 체크 서비스, 체스에서 체크는 체크 메이트를 만들기 위한 발판. 체크 메이트에서 퀸 희생은 굉장히 탁월한 수.

과대하게 해석해보면, 당신네들 Repository의 링크를 체크하기위해 퀸희생을 하라라는 의미다.

이스터에그(?)

프로젝트 아이디어는 꽤 오래전부터 구상하고 있었다. 그러나 작업을 하고 있진 않았는데, 아직 때가 아니라는 느낌이 들었기 때문이였다.

그러나 커피를 여러잔 마셔 잠 못드는 새벽, 누워서 핸드폰으로 GPT와 대화를 나누던 중 참지 못하고 레포를 만들어버렸다.

체스 컨셉에 맞춰 첫 커밋은 e4, e5로 체스의 근본적인 오프닝수의 기보로 적었다.

마치며

왜 말짱한 티스토리 블로그 냅두고 벨로그에 쓰냐?
이런 서비스 바이럴은 벨로그가 더 잘될 것 같다.

그런의미에서 많관부 https://github.com/reddevilmidzy/queensac