해킹 사건이 발생한 직후 초기 대응의 하나로 데이터를 모두 백업한 뒤 위키 서버를 임시 폐쇄했었다. 그로부터 며칠간 위키 복구를 간절히 바라는 사용자들을 뒤로한 채 미션을 할 수밖에 없었다.
글의 이해를 위해 현시점의 위키 문서의 저장 방식을 간략히 소개한다.
위키 문서의 본문은 MD 파일 문법에 맞게 작성되어 저장된다. 아래는 폴라(6기) 문서 본문의 일부다.
# 프로필
/1709018891180+-+%EC%9E%A5%EC%9C%A0%EC%A7%84.jpg)
<table>
<tr>
<th>닉네임</th>
<td>폴라</td>
</tr>
<tr>
<th>생일</th>
<td>12월 99일 (본인 주장)</td>
</tr>
<tr>
<th>소속/기수</th>
<td>백엔드 6기</td>
</tr>
<tr>
<th>MBTI</th>
<td>ENTP</td>
</tr>
</table>
# 정보
## 브리조의 완성 조건
위키 사이트는 이를 적절히 브라우저에 렌더링하는 형태로 동작한다.
위키 복구를 위해서는 다음 세 가지 서비스의 복구가 필요했다.
EC2의 경우 단순히 서버고 몇 가지 간단한 프로그램들만 설치해서 사용하기 때문에 조금 귀찮을 뿐 다시 처음부터 세팅할 수 있었다. 필요한 데이터가 이미 개발자의 노트북에 존재했기 때문이다.
반면, S3와 RDS는 백업 작업이 필요했다. 필요한 데이터가 모두 기존 서비스 내부에만 존재했기 때문이다.
최종적으로 정해진 백업 및 복구 시나리오는 다음과 같다.
백업하는 방법은 여러 가지가 있겠지만, 가장 단순한 방법은 데이터베이스와 테이블의 DDL을 추출하고, 현재 테이블의 모든 데이터를 INSERT 쿼리 형태로 변환하여 파일로 저장하는 방법이다. 그리고 이러한 기능을 보통 DBMS에서 제공한다. 위키 데이터 백업도 이를 이용해 수행했다.
이 역시 많은 방법이 있겠지만, 단순히 모든 이미지를 다운받으면 된다. 다만, 복구를 위해서는 고민해야 하는 부분이 몇 가지 있다.
/1709018891180+-+%EC%9E%A5%EC%9C%A0%EC%A7%84.jpg)
앞서 서술한 대로, 위키 문서 내 이미지는 위와 같이 링크 형태로 문서와 이미지를 연결한다. 따라서, 이미지를 복구할 때 단순히 이미지를 업로드하는 것이 끝이 아니라, 문서 내 링크도 새로운 링크로 변경해야 한다. 만약, 이미지 링크가 무작위로 할당된다면 단순 반복 작업이 될 뻔했으나, S3는 폴더 구조를 반영하기 때문에 폴더 구조를 유지할 경우 링크의 호스트 주소만 변경하는 작업으로 가능하다고 추론했다.
정말 그 누구도 위키 복구 과정에서 어려움이 있을 것이라 예상하지는 않았다. 인생사 새옹지마라는 고사성어처럼, 문제는 생각지 못한 곳에서 발생했다.
모든 작업을 마치고, 문서들을 확인했다. 그런데 왜인지 문서들의 이미지가 전부 깨져서 보이지 않았다.
처음 문제를 파악했을 때, S3의 설정이 잘못되어 이미지를 조회할 수 없는 것으로 생각했다. 이를 확인하기 위해서 S3 콘솔을 통해 이미지의 링크를 직접 눌러서 확인해 보았다. 그랬더니 아래 이미지처럼 Access Denied 가 발생하고 있다는 것을 알았다. 아래 이미지는 실제 당시 사진이 아닌, 구글링을 통해 가져온 사진이다.
이미지를 누구나 볼 수 있어야 하고, 그러기 위해서는 이에 대한 권한을 Public으로 설정할 필요가 있었다. 구글링의 검색 결과대로 설정하니 사진을 볼 수 있었다.
그런데, 여전히 위키에서 이미지가 안 보였다! 그래서 위키 사이트의 img 태그의 src 속성을 확인해 봤다. NoSuchKey 오류가 발생하는 것을 확인할 수 있었다.
이 오류는 말 그대로 파일에 대응되는 키가 없다는 뜻이다. URL에 뭔가 문제가 있다는 뜻이다. 아무리 봐도 URL이 정상적으로 보였기 때문에, S3 콘솔의 이미지 링크를 눌러보았다.
이미지가 안 보이는 것은 그저 렌더링 문제고, 정상적으로 이미지가 보인다. 두 사진 속 주소창을 자세히 보면 정상적으로 보이는 링크에는 URL 인코딩이 보이고, 위는 보이지 않는다. 따라서, 문제의 원인이 인코딩에 있다고 생각했다. 그리고 간단한 실험으로, 주소창에서 폴라%286기%29 이 부분만 따로 복사해서 수정했더니 여전히 안보였다.
아니 이게 무슨 일인가? 이 시점에서 주소창에 보이는 것이 아니라, 직접 문자열을 적어서 비교해 보기로 했다.
보이는 주소
https://wooteco-crew-wiki.s3.ap-northeast-2.amazonaws.com/
%E1%84%91%E1%85%A9%E1%86%AF%E1%84%85%E1%85%A1
(6%E1%84%80%E1%85%B5)/
%E1%84%8B%E1%85%AA%E1%86%BC%E1%84%84%E1%85%A1_
%E1%84%91%E1%85%A9%E1%86%AF%E1%84%85%E1%85%A1.png
안 보이는 주소
https://wooteco-crew-wiki.s3.ap-northeast-2.amazonaws.com/%ED%8F%B4%EB%9D%BC%286%EA%B8%B0%29
/%EC%99%95%EB%94%B0_%ED%8F%B4%EB%9D%BC.png
주소창에 한글 등의 문자들은 디코딩되어서 표현된다. 따라서 문제의 원인이 URL 인코딩에 있다는 확신을 했고, 확인차 URL 디코딩 해주는 사이트에서 위 두 주소를 디코딩해 보았다.
먼저 보이는 주소를 디코딩 해봤다.
“폴라(6기)/왕따_폴라.png” 로 디코딩 된다. 다음은 안 보이는 주소를 디코딩 해봤다.
“폴라(6기)/왕따_폴라.png” 로 디코딩 된다.
세종대왕께서 만드신 자랑스러운 우리 한글은 다른 문자들과는 다르게 독창적인 구조로 되어 있다. 바로 초성, 중성, 종성이다. 한글을 데이터로 표현할 때 이를 이용해 표현한 것을 조합형, 완성된 하나의 음절인 ‘폴’, ‘라’ 등에 바로 코드를 대응시키는 방식이 완성형이다. 이와 관련된 것보다 자세한 설명은 Naver D2의 글을 보자.
유니코드에서는 한글의 조합형과 완성형을 모두 지원한다. 유니코드의 각 코드는 동일한 byte기 때문에 조합형으로 표현한 것이 더 용량이 크다. 이 점에서 접근이 안 되는 주소가 조합형으로 표현한 것으로 추측했고, 주소에서 “6기”의 “기”에 대응되는 부분인 %E1%84%80%E1%85%B5 를 이용해 확인했다.
‘%’를 기준으로 앞의 3부분은 ‘ㄱ’으로, 나머지 부분은 ‘ㅣ’로 디코딩되는 것을 확인할 수 있었다.
결론적으로 현재 데이터베이스에는 완성형으로 S3에는 조합형으로 저장되어 있기 때문에 발생하는 문제였다. 할 수만 있다면 가장 간편한 해결책은 S3에 완성형으로 이미지를 저장하는 것이었다.
컴퓨터를 쓰다 보면, 한글이 문제가 되는 경우가 가끔 있다. 바로, 맥과 윈도우 사이에서 파일을 주고받을 때 문제다.
구글에 바로 나오는 이 문제는, 윈도우와 맥의 한글 표현 방식의 차이점 때문이다. 맥에서는 조합형과 완성형 모두 지원하지만, 윈도우는 완성형만 지원한다. 따라서, 맥에서 조합형으로 작성된 파일을 윈도우에서는 완성형과 동일하게 해석해 화면에 표시하기 때문에 자음과 모음이 모두 분리되어 표시되는 것이다.
복구를 담당한 백엔드 개발자 모두 맥북을 쓰기 때문에, 자연스럽게 맥북에서 S3에 이미지를 업로드했다. 만약 Mac OS는 조합형이 기본이기 때문에 S3에 조합형으로 업로드된 것이라면, 윈도우에서는 완성형을 사용하기 때문에 윈도우에서는 완성형으로 업로드될 것으로 생각했다. 그리고, 모든 이미지를 삭제한 뒤에 윈도우를 사용하고 있는 프론트 개발자 컴퓨터에서 업로드를 했더니
드디어 위키 페이지에서도 이미지가 보이게 되었다. 맥북 쓰지 마!!