해킹 사건 그 이후..

위키 복구 대작전

해킹 사건이 발생한 직후 초기 대응의 하나로 데이터를 모두 백업한 뒤 위키 서버를 임시 폐쇄했었다. 그로부터 며칠간 위키 복구를 간절히 바라는 사용자들을 뒤로한 채 미션을 할 수밖에 없었다.

위키 문서의 구조

글의 이해를 위해 현시점의 위키 문서의 저장 방식을 간략히 소개한다.

위키 문서의 본문은 MD 파일 문법에 맞게 작성되어 저장된다. 아래는 폴라(6기) 문서 본문의 일부다.

# 프로필

![미리보기](https://wooteco-crew-wiki.s3.ap-northeast-2.amazonaws.com/%ED%8F%B4%EB%9D%BC(6%EA%B8%B0)
/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 : 데이터베이스 서비스

EC2의 경우 단순히 서버고 몇 가지 간단한 프로그램들만 설치해서 사용하기 때문에 조금 귀찮을 뿐 다시 처음부터 세팅할 수 있었다. 필요한 데이터가 이미 개발자의 노트북에 존재했기 때문이다.

반면, S3와 RDS는 백업 작업이 필요했다. 필요한 데이터가 모두 기존 서비스 내부에만 존재했기 때문이다.

최종적으로 정해진 백업 및 복구 시나리오는 다음과 같다.

기존 RDS에서 데이터 백업
기존 S3에서 이미지 백업
새로운 AWS 계정 생성 및 보안 설정
새로운 RDS 생성 및 데이터 복구
새로운 S3 생성 및 이미지 업로드
새로운 EC2 생성 및 설정

기존 RDS에서 데이터 백업

백업하는 방법은 여러 가지가 있겠지만, 가장 단순한 방법은 데이터베이스와 테이블의 DDL을 추출하고, 현재 테이블의 모든 데이터를 INSERT 쿼리 형태로 변환하여 파일로 저장하는 방법이다. 그리고 이러한 기능을 보통 DBMS에서 제공한다. 위키 데이터 백업도 이를 이용해 수행했다.

기존 S3에서 이미지 백업

이 역시 많은 방법이 있겠지만, 단순히 모든 이미지를 다운받으면 된다. 다만, 복구를 위해서는 고민해야 하는 부분이 몇 가지 있다.

![미리보기](https://wooteco-crew-wiki.s3.ap-northeast-2.amazonaws.com/%ED%8F%B4%EB%9D%BC(6%EA%B8%B0)
/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에 조합형으로 업로드된 것이라면, 윈도우에서는 완성형을 사용하기 때문에 윈도우에서는 완성형으로 업로드될 것으로 생각했다. 그리고, 모든 이미지를 삭제한 뒤에 윈도우를 사용하고 있는 프론트 개발자 컴퓨터에서 업로드를 했더니
미리보기
드디어 위키 페이지에서도 이미지가 보이게 되었다. ~~맥북 쓰지 마!!~~

깨달은 점

한글은 꼭 써야 하는 부분에만 쓰자. 괜히 알파벳으로 코드 짜는 것이 아니다.
1. 레벨 3 ~ 4에서 한글로 뭐 하자는 팀원 있으면 조용히 이 글을 보여주자.
컴퓨터에서 문자를 표현하기 위해 상당히 많은 작업을 하고 있다.

크루위키