직접 소유한 Nextcloud 서버로 Google Drive를 대체하는 방법

클라우드 스토리지는 대부분의 사람이 한 회사에 넘기는 것 중 가장 내밀한 물건이다. 문서가 아니라 — 사진, 신분증 스캔본, 세금 신고서, 모든 것이 담긴 휴대폰의 백업 말이다. 그것은 이의 제기도 받아주지 않는 자동화된 시스템이 정지시킬 수 있는 계정 안에, 업로드한 것을 스캔하는 서버 위에, 몇 년 전 인증해 두었고 이제 와서 떼어낼 수도 없는 신원에 묶인 채 놓여 있다. 사람들은 대개 최악의 순간에 이 구조의 실체를 발견한다 — 보통은 잠긴 계정 하나가 20년치 가족사진을 함께 끌고 사라질 때다. Nextcloud는 오픈소스로 내놓는 답이다: 똑같은 동기화 클라이언트, 똑같은 휴대폰 앱, 똑같은 공유 링크 — 다만 당신이 대여한 머신 위에서 돌아가고, 그 누구도 색인하지 않는 파일을 담고 있을 뿐이다. 설치 자체는 반나절이면 끝난다. 떠나온 곳보다 실제로 나은지를 가르는 것은 그 밑에 놓인 디스크이며, 거의 모든 튜토리얼이 틀리게 설명하는 암호화 질문이다.

Nextcloud가 실제로 대체하는 것

Nextcloud는 단일 앱이라기보다, 일반 소비자용 클라우드 계정이 하는 일 대부분을 우연히 커버하게 된 작은 스위트에 가깝다. 그 폭넓음이야말로 셀프 호스팅할 가치가 있는 이유다: 서비스 하나를 셀프 호스팅 버전으로 바꾸는 일은 유지 관리 수고에 비해 거의 남는 게 없지만, 다섯 개를 서버 하나로 바꾸는 일은 대개 그렇지 않다.

• 파일 동기화와 공유, 이것이 핵심이다. Windows, macOS, Linux용 데스크톱 클라이언트, 두 모바일 플랫폼용 앱, 그리고 웹 인터페이스까지 — 폴더 하나를 끌어다 놓으면 어디에나 나타나는, 이미 익숙한 그 동작 그대로다.
• 휴대폰에서의 사진 백업. 자동 카메라 업로드, 앨범, 얼굴 그룹화까지 지원한다. 대부분의 사람에게 이것이 데이터에서 단연 가장 큰 몫을 차지하며, 디스크 용량을 제대로 산정해야 하는 이유이기도 하다.
• 공개 표준인 CalDAV와 CardDAV를 통한 캘린더와 연락처. 모든 휴대폰이 기본적으로 이 프로토콜을 지원하므로, 동기화를 위해 별도의 서드파티 앱이 필요 없다.
• 추가로 설치할 수 있는 오피스 스위트를 통한 협업 문서 작성. 스프레드시트와 텍스트 파일을 다른 어디로도 보내지 않고 브라우저 안에서 그대로 편집할 수 있다.
• 비밀번호, 만료일, 업로드 전용 드롭 폴더를 설정할 수 있는 공개 공유 링크. 대개 큰 첨부 파일을 이메일로 보내던 습관을 끝내주는 기능이다.
• 서버 측 버전 관리와 휴지통. 덮어써진 파일이나 잘못된 동기화도 백업까지 가지 않고 복구할 수 있다.

이 경계는 분명히 짚고 넘어갈 가치가 있다. 셀프 호스팅을 둘러싼 마케팅은 좀처럼 이 이야기를 하지 않기 때문이다. Nextcloud는 통제권과 프라이버시를 준다. 대형 클라우드 업체 수준의 내구성은 주지 않는다 — 그런 회사들은 데이터를 여러 대륙에 걸쳐 복제하지만, 대여한 서버 한 대는 디스크가 아무리 좋아도 그렇게 하지 않는다. 파일이 공짜가 되는 것도 아니다: 어느 쪽이든 스토리지 비용은 내야 하며, 다만 그 상대가 당신의 이름을 물었던 곳이 아니라 물은 적 없는 호스트로 바뀔 뿐이다. 셀프 호스팅은 남의 신뢰성을 자신의 통제권과 맞바꾸는 거래이며, 그 신뢰성 쪽을 진지하게 떠맡을 때에만 좋은 거래가 된다.

당신이 곧 스토리지 제공업체가 된다

그것이 셀프 호스팅의 정직한 대가이며, 마이그레이션 후보다 마이그레이션 전에 이해해 두는 편이 훨씬 낫다. 아무도 당신의 가동 시간을 지켜봐 주지 않고, 아무도 당신의 사진 사본을 갖고 있지 않으며, 오늘 아침 꼭 필요했던 파일에서 동기화 클라이언트가 충돌을 알리는 바로 그 순간 전화 저편에서 받아줄 지원팀도 없다.

• 백업은 당신의 몫이며, 선택 사항이 아니다. RAID 어레이는 디스크 하나가 죽어도 살아남지만, 삭제된 폴더나 잘못된 업그레이드, 동기화된 디렉터리를 훑고 지나간 랜섬웨어에는 살아남지 못한다. 버전 관리와 휴지통은 편의 기능일 뿐 백업이 아니다.
• 가동 시간도 당신의 몫이다. 서버에 닿지 못한 동기화 클라이언트는 변경 사항을 조용히 대기열에 쌓아 두었다가 나중에 따라잡으므로 그 자체는 너그러운 편이지만, 고객에게 보낸 공유 링크는 박스가 다운된 동안에는 죽은 링크다.
• 업데이트도 당신의 몫이며, Nextcloud는 이를 상당히 빠른 주기로 내놓는다. 공인 IP 위에서 당신의 삶 전체를 담고 있는 PHP 애플리케이션이므로, 패치를 한가한 달까지 미뤄도 되는 일이 아니다.
• 용량을 지켜보는 것도 당신의 몫이다. 모든 사진을 자동으로 업로드하는 휴대폰은 넉넉하게 잡아 둔 디스크조차 계획에 없던 시점에 채워버리며, 가득 찬 디스크는 그저 멈추는 데서 그치지 않고 데이터를 손상시킨다.
• 복구도 당신의 몫이다. 복원은 데이터베이스와 파일 트리를 같은 시점 기준으로 함께 되돌리는 일을 뜻한다. 둘 중 하나만 복원하면, 존재하지 않는 파일 목록을 멀쩡히 보여주는 인터페이스가 만들어질 뿐이다.

이 중 어느 것도 일단 갖춰 놓으면 무겁지 않다. 한 달에 몇 분, 그리고 처음에 신중하게 들이는 반나절이면 되며, 이는 셀프 호스팅하는 어떤 서비스에나 필요한 것과 같은 규율이다 — 다를 뿐이라면, 이번에는 잃으면 가장 아까울 것들을 담고 있다는 점이다. 이미 직접 호스팅하는 웹사이트를 거쳐 왔다면, 낯설 것은 하나도 없다.

머신 크기 정하기: 애플리케이션이 아니라 데이터에 예산을 맞춰라

Nextcloud 자체는 가벼운 PHP 애플리케이션이다. 여기서 벌어지는 크기 산정 실수는 거의 다 애플리케이션 기준으로 예산을 잡고, 이 작업의 본질이 계속 불어나는 데이터를 담는 것이라는 사실을 잊는 데서 비롯된다. 처음부터 형태를 제대로 잡아 두어라. 파일 트리와 데이터베이스를 나중에 다른 머신으로 옮기는 일은 셀프 호스팅에서 가장 유쾌하지 않은 오후이기 때문이다.

• 스토리지는 어떤 플랜을 골라야 하는지를 결정짓는 요소이며, 오늘 기준 파일 용량의 대략 두 배가 필요하다. 버전 관리는 변경된 파일의 예전 사본을 보관하고, 휴지통은 삭제된 항목을 보존 기간 동안 담아 두며, 생성된 썸네일과 미리보기는 사진 라이브러리 위에 얹히는 무시할 수 없는 비율을 차지한다.
• 메모리는 작동 여부가 아니라 사용 체감을 좌우한다. 2 GB로도 1인용 인스턴스는 돌아가고, 휴대폰 업로드가 계속 돌아가는 가정용이라면 4 GB가 여유롭고, 오피스 스위트와 몇몇 동시 사용자가 얽히기 시작하면 8 GB 이상이 중요해진다.
• CPU는 거의 항상 놀고 있다가, 짧은 순간 아주 중요해진다 — 가져온 사진 라이브러리에 대한 첫 미리보기 생성 작업과 즉석에서 이루어지는 문서 변환이, 여유를 남겨 둘 가치가 있는 순간의 스파이크다.
• 데이터베이스는 빠른 스토리지를 필요로 하지만, 파일 쪽은 딱히 그렇지 않다. 메타데이터 작업은 데이터베이스에 끊임없이 부하를 주는 반면 파일 트리는 대체로 순차적인 읽기·쓰기이므로, 작은 NVMe 루트 디스크와 대용량 스토리지를 나란히 두는 쪽이 느린 대용량 볼륨 하나보다 더 나은 구성이다.
• 여기서는 전송량이 무제한이지만, 기존 라이브러리를 처음 업로드하는 일은 정말로 큰 일회성 작업이다. 예상치 못하게 맞닥뜨리지 말고 아예 하룻밤 동안 돌아가도록 계획해 두어라.

실제로는 얼마나 저장하고 있느냐에 따라 두 갈래로 갈린다. 수백 기가바이트 이하 — 문서, 소박한 사진 라이브러리, 한두 사람 — 라면 4 vCPU EPYC, 8 GB DDR5 ECC, 120 GB Gen4 NVMe를 갖춘 월 $13.99의 VPS-8이면 빠르고도 차고 넘친다. 카메라 롤이 있는 휴대폰이 그림에 들어오는 순간 용량이 모든 것을 좌우하는 질문이 되고, 그때는 NVMe에 돈을 낼 이유가 없다: 스토리지 서버는 월 $7.99부터 RAID-6 구성으로 1 TB를 주고, 월 $22.99의 STO-4는 4 TB를 준다 — 어떤 VPS와도 격이 다른 여유이며, 테라바이트당 가격은 그 일부에 지나지 않는다. 가정 전체나 소규모 팀의 자료를 그 이상으로 통합한다면, 월 $64부터인 전용 서버가 2 × 1 TB NVMe로 속도와 공간을 동시에 주어 계산이 우스꽝스러워지지 않는다.

단계별 안내: 새 서버에서 실제로 동작하는 동기화까지

1. 01서버를 배포하고 먼저 하드닝하기파일이 단 하나라도 올라가기 전에 Debian이나 Ubuntu 박스에 키 전용 SSH와 기본 차단 방화벽부터 갖춰라. 머신이 아직 텅 비어 있고 볼 것 없을 때 해 두어라.
2. 02도메인을 서버로 연결하고 인증서를 발급받기Nextcloud 클라이언트는 일반 HTTP로는 동기화를 거부하며, 이는 당연한 일이다. 인증서가 발급되려면 먼저 호스트네임이 그 머신을 가리켜야 하는데, 이 순서를 거꾸로 하는 것이 설치 실패의 압도적으로 가장 흔한 원인이다.
3. 03설치 방식을 정하고 그대로 밀고 나가기컨테이너 이미지는 가장 빠른 길이면서 업데이트를 유지하기도 가장 쉽다. 웹 서버와 데이터베이스에 직접 설치하면 튜닝을 더 세밀하게 통제할 수 있다. 둘 중 하나를 골라라 — 둘을 섞어 쓰는 것이 업그레이드를 고장 내는 지름길이다.
4. 04SQLite 대신 제대로 된 데이터베이스 쓰기SQLite는 딱 한 사람이 별다른 일 없이 쓸 때만 버티며, 두 클라이언트가 동시에 동기화하는 순간 무너진다. 설치 시점에 MariaDB나 PostgreSQL을 선택하라, 나중에 전환하는 것은 유쾌하지 않은 마이그레이션이기 때문이다.
5. 05메모리 캐시를 추가하고 백그라운드 작업 설정하기잠금과 캐싱에는 Redis를, 백그라운드 작업에는 브라우저가 트리거하는 기본 방식 대신 시스템 수준의 cron을 사용하라. 이를 건너뛰는지 여부가 어떤 셀프 호스팅 인스턴스는 굼뜨게, 어떤 것은 즉각적으로 느껴지게 만드는 이유다.
6. 06무엇을 옮기기 전에 업로드 한도부터 올려두기기본값은 작은 파일 기준으로 맞춰져 있어 동영상이나 디스크 이미지는 거부한다. 웹 서버와 PHP 설정에서 한도를 먼저 고쳐 두어라, 그러지 않으면 첫 대용량 업로드가 90퍼센트 지점에서 실패한다.
7. 07파일은 한 번에 의도적으로 옮기기데스크톱 클라이언트에서 기존 라이브러리를 업로드하거나, 파일을 제자리에 복사해 넣은 뒤 스캔을 실행하라. 누군가 이 인스턴스에 의존하기 전에, 하룻밤 사이에 단 한 번으로 끝내라.
8. 08클라이언트를 연결한 다음, 같은 날 백업까지 설정하기데스크톱 동기화, 휴대폰 자동 업로드, 캘린더와 연락처까지. 그런 다음 백업을 설정하고 실제로 테스트하라 — 복원 경로 없이 운영 중인 인스턴스는 카운트다운이나 다름없다.

암호화: 실제로 당신을 보호하는 것과, 그런 것처럼 들리기만 하는 것

회사가 당신의 파일을 읽을 수 있다는 이유로 소비자용 클라우드를 떠나온 것이라면, 이 절이 가장 중요하다. 그리고 대부분의 가이드가 여기서 틀린다. Nextcloud에는 서버 측 암호화라는 기능이 있다. 켜기만 하면 답을 찾은 것처럼 느껴진다. 하지만 대개는 그렇지 않으며, 왜 그런지 이해해 두면 암호화가 아예 없는 것보다 더 나쁜 거짓 안전감에서 벗어날 수 있다.

• 서버 측 암호화는 키를 서버에 둔다. 애플리케이션이 당신에게 파일을 내주려면 스스로 복호화할 수 있어야 하므로, 실행 중인 머신에 접근할 수 있는 사람은 그 머신이 가진 모든 것을 갖게 된다. 이는 도난당한 디스크나 신뢰할 수 없는 외부 스토리지 백엔드로부터는 보호해 주지만, 침해당한 서버나 그 운영자로부터는 보호해 주지 않는다.
• 종단간 암호화가 진짜다. 다만 의도적으로 제한되어 있다. 특정 폴더에 대해 클라이언트에서 암호화하므로 서버는 정말로 그 내용을 읽을 수 없다 — 그리고 그만큼, 그 콘텐츠에 대해서는 웹 인터페이스도, 미리보기도, 서버 측 검색도, 공개 공유 링크도 쓸 수 없다는 뜻이기도 하다.
• 서버의 전체 디스크 암호화는 전원이 꺼진 머신을 보호한다. 실행 중인 서버는 볼륨이 마운트되어 있고 키가 메모리에 올라와 있으므로, 이는 전원이 꺼진 박스를 폐기하거나 물리적으로 압수당하는 경우를 방어할 뿐 그 이상은 아니다.
• 업로드 전에 암호화하는 것이야말로 대부분의 사람이 실제로 원하는 방식이다. 폴더를 로컬에서 암호화하고 암호문만 동기화하는 도구를 쓰면, 밑에서는 평범한 Nextcloud가 돌아가면서도 진짜 기밀성을 얻을 수 있다 — 대신 그 폴더에 대한 미리보기와 브라우저 접근은 포기해야 한다.
• 전송 구간 암호화는 저장 암호화가 아니다. HTTPS는 이동 중인 파일만 보호할 뿐 저장된 파일은 전혀 보호하지 않으며, 이 둘을 혼동하는 것이 이 주제 전체에서 가장 흔한 오해다.

대부분의 사람에게 정직한 답은 절충안이다. 인스턴스는 평소처럼 운영하라 — 어차피 당신의 서버이고, 미리보기와 검색과 공유 링크의 편리함이야말로 그냥 암호화된 아카이브를 쓰지 않는 이유 전부다. 그런 다음 진짜로 민감한 소수의 파일 — 서류, 키, 최악의 해에 진짜로 중요해질 것들 — 을 골라, 그것들이 디스크에 닿기 전에 클라이언트 측에서 암호화하라. 그러면 어중간한 타협 하나가 둘 다인 척하는 대신, 쓸 만한 클라우드와 진짜 금고를 동시에 갖게 된다.

기본 설치가 그대로 남겨두는 신원 유출

Nextcloud는 당신의 파일을 읽던 회사를 없애준다. 다만 그것만으로는 서버를 한 사람에게 연결 짓는 나머지 모든 것을 없애주지는 못한다 — 그리고 그 대부분은 스토리지와는 무관하게 느껴지는 단계에서 비롯된다.

• 도메인. 공개 WHOIS 정보가 가려져 있어도 등록기관은 당신의 신원을 보관하고 있으며, 이름을 유지하려면 실제로 작동하는 연락처 주소가 필요하다. 호스트네임은 셀프 호스팅한 서비스가 소유자에게로 추적되는 단연 가장 흔한 경로다.
• 인증서 투명성. 인증서가 발급되는 순간, 정확한 호스트네임이 누구나 검색할 수 있는 공개 로그에 게시된다. 비공개일 거라 생각했던 서브도메인 — cloud.something, files.something 같은 — 이 타임스탬프까지 찍힌 채 전 세계에 공지된다.
• 호스트. 서버를 본명으로 된 카드로 구매했다면, 그 위에서 무엇이 돌아가든 머신은 당신의 본명으로 남아 있다. 이는 첫 파일이 생기기 훨씬 전, 가입 시점에 이미 결정된다.
• 모바일 푸시 알림. 공식 앱은 기본적으로 플랫폼 제공업체의 푸시 서비스를 통해 알림을 전달하므로, 당신의 파일은 가지 않아도 인스턴스에 대한 메타데이터는 Google이나 Apple에 도달한다.
• 사진 메타데이터. 이미지에는 GPS 좌표와 기기 식별자를 포함한 EXIF 데이터가 담겨 있다. 카메라 롤을 자신의 서버로 옮긴다고 해서 이것이 지워지지는 않는다 — 그저 당신이 통제하는 곳으로 옮겨질 뿐이며, 그편이 낫기는 해도 제거하는 것과 같지는 않다.
• 외부 연동. 페더레이션 공유, 원격 스토리지 백엔드, 메일 알림, 앱스토어 업데이트 확인 모두 이 머신에서 밖으로 연결을 시도하며, 이들 각각이 당신의 서버를 보는 제3자다.
• 서버 로그. 당신 자신의 로그가 모든 동기화마다 IP 주소와 사용자 에이전트를 기록한다. 자신의 머신에서는 그것으로 괜찮다 — 다만 그 머신이 압수되는 순간, 그 로그는 당신 자신의 행적에 대한 증거가 된다.

이런 것들을 닫아 두는 일은 특별할 것 없는 평범한 작업이다. 암호화폐를 받고 최소한의 정보만 수집하는 등록기관을 골라라. 머신은 당신이 누구인지 물은 적 없는 호스트에 두고 암호화폐 잔액으로 결제하라 — Bitcoin은 익명이 아니라 가명(pseudonymous)일 뿐이므로, 그것이 신경 쓰인다면 Monero로 충전하는 것이 온체인 흔적을 끊는 방법이다. 메타데이터가 신경 쓰인다면 푸시 알림을 끄고, 그에 따르는 동기화 지연은 감수하라. 그리고 이 인스턴스가 오직 당신과 몇몇 신뢰하는 사람만을 위한 것이라면, 아예 인터넷 전체에 노출하지 마라: WireGuard 터널 뒤에 두고 그 터널을 통해서만 응답하게 하라 — 이렇게 하면 공개 로그인 페이지를 노리는 공격 전체가 통째로 사라진다.

이전 이후에도 멈추지 않게 유지하기

1년 동안 문제없이 작동해 온 파일 서버는, 1년 동안 아무도 들여다보지 않은 파일 서버이기도 하다. 짧은 루틴 하나가 그런 상태와, 애초에 지키려고 만든 것을 잃어버리는 상태 사이의 차이를 만든다.

• 데이터베이스와 파일 트리를 같은 시점 기준으로 함께 백업하라. 짝이 맞는 데이터베이스 없이 파일만 백업하면, 복원했을 때 텅 비어 보이는데 고아 파일로 가득한 인스턴스가 된다.
• 서버에 있지 않은 사본을 하나 갖고 있어라. 같은 머신에 있는 스냅샷은 디스크 장애 하나만 견딜 뿐이다 — 침해도, 어디로든 동기화되어 버리는 실수로 인한 삭제도, 계정 분실도 견디지 못한다.
• 아무 문제도 없을 때, 한 번은 일부러 복원을 해 보아라. 테스트해 보지 않은 사진 라이브러리 백업은 당신의 추억에 대한 가설일 뿐이다.
• 업데이트는 프로젝트의 일정에 맞춰라, 그리고 메이저 버전을 절대 건너뛰지 마라. Nextcloud는 한 번에 메이저 릴리스 하나씩만 업그레이드하도록 되어 있으며, 두 단계를 한꺼번에 건너뛰면 직접 손으로 풀어내야 하는 마이그레이션이 된다.
• 여유 공간을 실질적인 여유를 두고 지켜보라. 업그레이드는 작동할 공간이 필요하며, 데이터베이스 마이그레이션 도중 디스크가 가득 차는 것이야말로 평범한 업데이트가 복원 작업으로 바뀌는 방식이다.
• 백그라운드 작업이 실제로 돌아가고 있는지 확인하라. 미리보기 생성, 휴지통 정리, 버전 정리가 모두 거기에 달려 있으며, 조용히 고장 난 cron은 몇 달 뒤 원인 모를 디스크 가득 참으로 나타난다.

하는 김에 외부 점검도 하나 추가해 두어라 — 외부에서 로그인 페이지를 가져와서 응답이 멈추면 알려주는 정도의 모니터만 있어도, 대기 중인 동기화 클라이언트가 알아채기 전에 인스턴스가 다운되었음을 알 수 있다. 그리고 머신 자체는 새 VPS에서 보내는 첫 10분이 설명하는 그대로 다루어라, 당신이 가진 모든 문서를 쥐고 있는 박스에 걸린 판돈은 돈을 쥐고 있는 박스보다 결코 낮지 않기 때문이다.

실제 파일이 사라지는 실수들

• 기본값이라는 이유만으로 SQLite에 설치했다가, 두 기기가 동시에 동기화하는 첫 순간 잠겨버리는 것을 지켜보는 경우.
• 휴지통과 파일 버전을 백업으로 여기다가, 동기화 클라이언트가 삭제를 어디에나 퍼뜨리는 날 그것이 백업이 아니었음을 깨닫는 경우.
• 백업을 설정하기도 전에 사진 라이브러리 전체를 옮겨 놓고, 유일한 사본이 대여한 머신 위에만 있는 상태로 한 달을 사는 경우.
• 서버 측 암호화를 켜 놓고는 이제 파일이 호스트로부터 비공개라고 결론 내리고, 그 믿음에 따라 행동하는 경우.
• 버전, 휴지통, 미리보기를 위한 여유는 전혀 두지 않은 채, 오늘 기준 파일 용량에 맞춰 디스크 크기를 정하는 경우.
• 메모리 캐시와 백그라운드 작업 설정을 건너뛰고서, 느리게 느껴지는 인스턴스를 하드웨어 탓으로 돌리는 경우.
• 업로드 한도를 기본값 그대로 두었다가, 마이그레이션 도중 큰 파일이 조용히 실패한다는 것을 알게 되는 경우.
• 인스턴스를 1년 동안 손대지 않고 두었다가, 한 번의 업그레이드로 메이저 버전 두 단계를 한꺼번에 건너뛰는 경우.
• 다른 모든 것은 제대로 해놓고, 정작 서버 대여와 도메인 등록은 본명으로 하는 경우.

Nextcloud는 일상에서 정말로 중요한 부분에서 자신이 대체하는 상용 제품과 진짜로 맞먹는, 몇 안 되는 셀프 호스팅 프로젝트 중 하나다 — 동기화는 그냥 되고, 휴대폰 앱도 그냥 되며, 일주일이 지나면 차이를 더는 눈치채지 못하게 된다. 설치에는 반나절, 마이그레이션에는 하룻밤이면 된다. 그러고 나면 남는 것은 당신이 가진 모든 파일이, 당신에게만 답하는 머신 위에, 암호화폐 잔액으로 비용을 치른 채, 당신의 이름을 물은 적 없는 호스트 위에 놓여 있는 상태다. 디스크는 지금의 데이터가 아니라 앞으로 될 데이터에 맞춰 크기를 정하고, 진짜로 필요한 작은 일부만 클라이언트 측에서 암호화하며, 백업은 필요해진 다음이 아니라 필요해지기 전에 갖춰 두어라.