Extended FAQ ko KR

확장된 자주 묻는 질문(FAQ)

저희 확장 FAQ에서는 좀 더 흔하지 않은 질문과 답변을 다룹니다. 좀 더 일반적인 사항은 대신 저희 기본 FAQ 를 참고해주세요.

---

ASF는 누가 만들었나요?

ASF는 Archi 가 2015년 10월에 만들었습니다. 혹시 궁금하실까 봐 말씀드리면, 저도 여러분과 마찬가지로 Steam 사용자 입니다. 게임을 하는 것 외에도, 저는 제 실력과 열정을 발휘하는 것을 좋아하며, 그 결과물을 바로 지금 확인하실 수 있습니다. 여기에는 대기업도, 개발자 팀도, 이 모든 것을 감당할 100만 달러의 예산도 없습니다 - 그저 고장 나지도 않은 것을 고치고 있는 저 한 사람뿐입니다.

다만 ASF는 오픈소스 프로젝트이며, 여기서 보시는 모든 것을 제가 혼자 만든 것은 아니라는 점을 아무리 강조해도 지나치지 않습니다. 저희에게는 거의 전적으로 다른 개발자들이 개발하고 있는 다른 ASF 프로젝트도 몇 가지 있습니다. 핵심 ASF 프로젝트조차도 이 모든 것을 가능하게 하는 데 도움을 준 많은 기여자(contributor) 들이 있습니다. 그뿐만 아니라, 특히 GitHub, JetBrains, Crowdin 과 같은 여러 제3자 서비스도 ASF 개발을 지원하고 있습니다. ASF를 가능하게 한 훌륭한 라이브러리와 도구들도 잊어서는 안 됩니다. 저희가 IDE로 사용하는 Rider(특히 ReSharper 확장 기능을 정말 좋아합니다)와, 그리고 무엇보다도 이것 없이는 ASF가 애초에 존재할 수 없었을 SteamKit2 가 있습니다. 제가 여기서 하는 모든 일을 지원해주시는 스폰서 와 여러 후원자분들이 없었다면 ASF는 오늘날의 모습을 갖추지 못했을 것입니다.

ASF 개발에 도움을 주신 모든 분께 감사드립니다! 여러분은 정말 멋집니다 ❤️.

---

ASF는 애초에 왜 만들어졌나요?

ASF는 Steam 클라이언트와 같은 외부 종속성 없이 완전 자동화된 Linux용 Steam 파밍 도구가 되는 것을 주된 목적으로 만들어졌습니다. 실제로 이는 여전히 ASF의 주된 목적이자 핵심입니다. 그때 이후로 ASF에 대한 제 구상이 바뀌지 않았고, 저는 2015년 당시와 정확히 같은 방식으로 지금도 사용하고 있기 때문입니다. 물론 그동안 정말 많은 변화가 있었고, ASF가 얼마나 발전해왔는지 보게 되어 매우 기쁩니다. 이는 대부분 사용자분들 덕분입니다. 저 혼자만을 위한 것이었다면 지금 기능의 절반도 만들지 않았을 테니까요.

ASF는 애초에 다른 유사한 프로그램, 특히 Idle Master 와 경쟁하기 위해 만들어진 것이 아니라는 점을 짚어두고 싶습니다. ASF는 데스크톱/사용자용 앱으로 설계된 적이 한 번도 없었고, 지금도 마찬가지입니다. 위에서 설명한 ASF의 주된 목적을 분석해보면, Idle Master가 이와 정반대 에 해당한다는 것을 알 수 있습니다. 오늘날에는 분명 ASF와 유사한 프로그램을 찾을 수 있지만, 당시에는 (그리고 지금도) 제게 충분히 만족스러운 것이 없었기에, 제가 원하는 방식으로 직접 소프트웨어를 만들었습니다. 시간이 지나며 사용자들은 주로 견고함, 안정성, 보안성, 그리고 그동안 제가 개발해온 모든 기능들 때문에 ASF로 옮겨왔습니다. 오늘날 ASF는 그 어느 때보다 뛰어납니다.

---

좋아요, 그럼 함정이 뭔가요? ASF를 공유함으로써 당신이 얻는 것은 무엇인가요?

함정은 없습니다. 저는 제 자신을 위해 ASF를 만들었고, 유용하게 쓰이길 바라는 마음으로 나머지 커뮤니티와 공유했습니다. 이는 1991년 리누스 토르발스가 자신의 첫 Linux 커널을 공유 했을 때와 정확히 같은 일입니다. 숨겨진 악성코드, 데이터 마이닝, 암호화폐 채굴, 혹은 저에게 금전적 이익을 발생시키는 그 어떤 활동도 없습니다. ASF 프로젝트는 전적으로 당신과 같은 만족한 사용자분들이 자발적으로 보내주신 후원금으로 유지됩니다. 제가 사용하는 것과 정확히 동일한 방식으로 ASF를 사용하실 수 있으며, 마음에 드신다면 제가 하는 일에 대한 감사의 표시로 언제든 커피 한 잔을 사주셔도 좋습니다.

저는 또한 ASF를 기술, 프로젝트 관리, 코드 그 자체 등 어떤 면에서든 항상 완벽함과 모범 사례를 추구하는 현대적인 C# 프로젝트의 완벽한 예시로 활용하고 있습니다. 이것이 제가 생각하는 "제대로 된 방식"의 정의이며, 혹시라도 제 프로젝트에서 유용한 것을 배우실 수 있다면 그것만으로도 저는 더욱 기쁠 것입니다.

---

ASF를 실행하자마자 제 계정/아이템/친구/(...)을 모두 잃었어요!

통계적으로 말하자면, 슬프지만 어쩔 수 없이, ASF를 실행한 직후 교통사고로 사망하는 사람이 최소 한 명은 반드시 있을 것입니다. 차이가 있다면, 제정신인 사람이라면 아무도 그것을 ASF의 탓으로 돌리지 않겠지만, 어떤 이유에서인지 자신의 Steam 계정에 비슷한 일이 일어났다는 이유만으로 ASF를 탓하는 사람들이 있다는 것입니다. 물론 그런 논리를 이해할 수는 있습니다. 어쨌든 ASF는 Steam 플랫폼 내에서 동작하기 때문에, 자신이 실행한 소프트웨어가 그 일과 조금이라도 관련되어 있다는 증거가 전혀 없어도 자연스럽게 사람들은 자신의 Steam 관련 자산에 일어난 모든 일을 ASF 탓으로 돌리게 됩니다.

**FAQ**와 위 질문 에서도 언급했듯이, ASF에는 악성코드, 스파이웨어, 데이터 마이닝, 그 밖의 잠재적으로 원치 않는 활동이 전혀 없으며, 특히 민감한 Steam 정보를 유출하거나 사용자의 디지털 자산을 가로채는 일이 없습니다. 만약 이런 일이 실제로 발생했다면, 저희로서는 그 손실에 대해 유감을 표하는 것 외에는 할 수 있는 것이 없으며, 복구 과정에 도움을 줄 수 있는 Steam 지원팀 에 문의하실 것을 권장합니다 - 저희는 어떤 방식으로도 그 일에 대한 책임이 없으며 양심에 거리낄 것이 없기 때문입니다. 그렇지 않다고 믿으신다면 그것은 개인의 판단이며, 더 이상 설명하는 것은 의미가 없습니다. 위에서 제시한 저희 주장을 객관적이고 검증 가능한 방식으로 확인할 수 있는 자료로도 설득되지 않으셨다면, 여기서 저희가 무엇을 더 적어도 마찬가지일 것입니다.

다만, 위 내용이 ASF를 상식 없이 사용한 본인의 행동 이 보안 문제를 야기할 수 없다는 뜻은 아닙니다. 예를 들어, 저희 보안 가이드라인을 무시하고 ASF의 IPC 인터페이스를 인터넷 전체에 노출시킨 뒤, 누군가 침입해 모든 아이템을 훔쳐갔다는 사실에 놀랄 수도 있습니다. 사람들은 늘 이렇게 하는데, 도메인이나 자신의 IP 주소와의 연결이 없으면 아무도 자신의 ASF 인스턴스를 절대 찾아내지 못할 것이라고 생각합니다. 지금 이 글을 읽고 있는 이 순간에도, 무작위 IP 주소를 포함해 웹을 크롤링하며 취약점을 찾아내는 완전 자동화된 봇이 수천 개, 혹은 그 이상 존재하며, 상당히 인기 있는 프로그램인 ASF 역시 이들의 표적이 됩니다. 저희는 이미 그런 어리석음으로 인해 "해킹"당한 사람들을 충분히 봐왔으니, 그들과 같은 대열에 합류하는 대신 그들의 실수에서 배우고 더 현명하게 대처하시기 바랍니다.

PC 보안에 대해서도 마찬가지입니다. 네, PC에 악성코드가 있으면 ASF의 모든 보안 요소가 무의미해집니다. 악성코드는 ASF config 파일이나 프로세스 메모리에서 민감한 정보를 읽어낼 수 있고, 심지어 ASF가 평소라면 하지 않을 동작을 하도록 영향을 줄 수도 있기 때문입니다. 아니요, 의심스러운 출처에서 받은 그 마지막 크랙은 누군가 말했던 것처럼 "오탐(false positive)"이 아닙니다. 그것은 다른 사람의 PC를 장악하는 가장 효과적인 방법 중 하나이며, 사람들은 스스로를 감염시키면서도 그 방법을 안내해주는 지시까지 그대로 따르니, 참으로 흥미로운 일입니다.

그렇다면 ASF를 사용하는 것은 완전히 안전하고 모든 위험에서 자유로운가요? 아니요, 그렇게 말한다면 저희는 위선자 무리가 될 것입니다. 모든 소프트웨어에는 보안 관련 문제가 있기 마련이기 때문입니다. 많은 기업들이 하는 방식과 달리, 저희는 보안 권고문(security advisories) 에서 최대한 투명하게 공개하려 노력하고 있으며, ASF가 보안 관점에서 원치 않는 상황에 어떤 식으로든 기여할 수 있는 가상의 상황이라도 발견하는 즉시 이를 공지합니다. 예를 들어 CVE-2021-32794 가 바로 이런 경우였습니다. ASF 자체에 보안 결함이 있었던 것은 아니었지만, 사용자가 실수로 보안 결함을 만들어낼 수 있는 버그가 있었습니다.

현재까지 ASF에는 알려진, 패치되지 않은 보안 결함이 없습니다. 그리고 이 프로그램을 사용하는 사람이 점점 늘어나면서 화이트햇 과 블랙햇 모두 소스 코드를 분석하고 있는데, 발견 가능한 보안 결함의 수는 유한하기 때문에 전체적인 신뢰도는 시간이 지날수록 오히려 높아지고 있습니다. 그리고 무엇보다 보안을 최우선으로 하는 프로그램인 ASF는 결함을 찾아내는 것을 결코 쉽게 만들어주지 않습니다. 저희의 선의와는 별개로, 항상 침착함을 유지하고 ASF 사용에서 비롯되는 것을 포함해 잠재적인 보안 위협을 항상 경계하실 것을 권장합니다.

---

다운로드한 파일이 정품(진짜)인지 어떻게 확인하나요?

GitHub 릴리스의 일환으로, 저희는 Debian 이 사용하는 것과 매우 유사한 검증 절차를 활용합니다. 모든 공식 릴리스에는 zip 빌드 자산 외에도 SHA512SUMS와 SHA512SUMS.sign 파일이 함께 제공됩니다. 원하는 zip 파일과 함께 이 파일들도 검증 목적으로 다운로드하세요.

먼저, SHA512SUMS 파일을 사용하여 선택한 zip 파일의 SHA-512 체크섬이 저희가 직접 계산한 값과 일치하는지 확인해야 합니다. Linux에서는 이 목적으로 sha512sum 유틸리티를 사용할 수 있습니다.

$ sha512sum -c --ignore-missing SHA512SUMS
ASF-linux-x64.zip: OK

Windows에서는 powershell로 이를 수행할 수 있지만, SHA512SUMS와 수동으로 비교 확인해야 합니다:

PS > Get-Content SHA512SUMS | Select-String -Pattern ASF-linux-x64.zip

f605e573cc5e044dd6fadbc44f6643829d11360a2c6e4915b0c0b8f5227bc2a257568a014d3a2c0612fa73907641d0cea455138d2e5a97186a0b417abad45ed9  ASF-linux-x64.zip


PS > Get-FileHash -Algorithm SHA512 -Path ASF-linux-x64.zip

Algorithm       Hash                                                                   Path
---------       ----                                                                   ----
SHA512          F605E573CC5E044DD6FADBC44F6643829D11360A2C6E4915B0C0B8F5227BC2A2575... ASF-linux-x64.zip

이 방법으로 SHA512SUMS에 기록된 내용이 실제 파일과 일치하며 변조되지 않았음을 확인할 수 있었습니다. 다만, 이것만으로는 비교 대상으로 사용한 SHA512SUMS 파일이 실제로 저희로부터 나온 것임이 아직 증명되지는 않습니다. 이를 검증하는 방법에는 두 가지가 있습니다.

첫 번째 방법이자 ASF가 자동 업데이트 과정에서 사용하는 방법은, https://asf.JustArchi.net/Api/Checksum/{Version}/{Variant} URL을 방문해 저희 백엔드 서버에 요청을 보내는 것입니다. 이때 {Version}은 6.1.4.3과 같은 ASF 버전 번호로, {Variant}는 generic이나 linux-x64와 같이 선택한 ASF variant로 바꿔서 입력하면 됩니다. JSON 응답에서 체크섬을 확인할 수 있으며, 이를 SHA512SUMS 및/또는 ASF zip 파일 아티팩트와 비교하면 됩니다. 저희 서버는 현재 stable 및 pre-release 버전의 ASF에 대해서만 체크섬을 제공합니다. 기존 ASF들이 업데이트를 고려할 대상은 오직 이 버전들뿐이기 때문입니다.

{
  "Result": "f605e573cc5e044dd6fadbc44f6643829d11360a2c6e4915b0c0b8f5227bc2a257568a014d3a2c0612fa73907641d0cea455138d2e5a97186a0b417abad45ed9",
  "Message": "OK",
  "Success": true
}

두 번째 방법은 함께 제공되는 SHA512SUMS.sign 파일을 활용하는 것으로, 이 파일에는 SHA512SUMS의 진위를 증명하는 디지털 PGP 서명이 들어 있습니다. 빌드 아티팩트와 서명 모두 빌드 과정의 일부로 생성되기 때문에, GitHub이 침해당한 경우에는 무결성을 보장하지 못합니다 (그래서 저희는 검증을 위해 별도의 독립적인 서버를 활용합니다). 하지만 알 수 없는 출처에서 ASF를 다운로드했고 GitHub이 전혀 침해당하지 않았음을 확인하려는 것이 아니라, 저희 GitHub 릴리스 과정에서 생성된 유효한 아티팩트인지만 확인하고자 하는 경우에는 이 방법으로 충분합니다.

이를 위해 **Linux**와 Windows 양쪽 모두에서 gpg 유틸리티를 사용할 수 있습니다 (Windows에서는 gpg 명령어를 gpg.exe로 변경하세요).

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Mon 02 Aug 2021 00:34:18 CEST
gpg:                using EDDSA key 224DA6DB47A3935BDCC3BE17A3D181DF2D554CCF
gpg: Can't check signature: No public key

보시다시피, 이 파일에는 실제로 유효한 서명이 있지만 출처는 알 수 없는 상태입니다. 완전한 검증을 위해서는, 저희가 SHA-512 체크섬 서명에 사용하는 ArchiBot의 공개 키(public key) 를 가져와야 합니다.

$ curl https://raw.githubusercontent.com/JustArchi-ArchiBot/JustArchi-ArchiBot/main/ArchiBot_public.asc -o ArchiBot_public.asc
$ gpg --import ArchiBot_public.asc
gpg: /home/archi/.gnupg/trustdb.gpg: trustdb created
gpg: key A3D181DF2D554CCF: public key "ArchiBot <ArchiBot@JustArchi.net>" imported
gpg: Total number processed: 1
gpg:               imported: 1

마지막으로, SHA512SUMS 파일을 다시 한번 검증할 수 있습니다:

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Mon 02 Aug 2021 00:34:18 CEST
gpg:                using EDDSA key 224DA6DB47A3935BDCC3BE17A3D181DF2D554CCF
gpg: Good signature from "ArchiBot <ArchiBot@JustArchi.net>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 224D A6DB 47A3 935B DCC3  BE17 A3D1 81DF 2D55 4CCF

이로써 SHA512SUMS.sign이 검증 대상이었던 SHA512SUMS 파일에 대해 저희의 224DA6DB47A3935BDCC3BE17A3D181DF2D554CF 키로 서명한 유효한 서명을 담고 있음이 확인되었습니다.

마지막 경고가 왜 나오는지 궁금하실 수 있습니다. 저희 키를 성공적으로 가져오기는 했지만, 아직 이를 신뢰하기로 결정하지는 않은 상태입니다. 이는 필수는 아니지만, 이 부분도 함께 다뤄보겠습니다. 일반적으로 이는 다른 채널(예: 전화, SMS)을 통해 키가 유효함을 확인한 뒤, 이를 신뢰하기 위해 자신의 키로 해당 키에 서명하는 과정을 포함합니다. 이 예시에서는, 원본 키가 ArchiBot의 프로필 에서 나온 것이므로 이 위키 항목 자체를 그런 (매우 취약한) 다른 채널로 간주할 수 있습니다. 어쨌든 여기서는 이미 충분한 확신을 가지고 있다고 가정하겠습니다.

먼저, 아직 없다면 본인의 개인 키(private key)를 생성 하세요. 간단한 예시로 --quick-gen-key를 사용하겠습니다.

$ gpg --batch --passphrase '' --quick-gen-key "$(whoami)"
gpg: /home/archi/.gnupg/trustdb.gpg: trustdb created
gpg: key E4E763905FAD148B marked as ultimately trusted
gpg: directory '/home/archi/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/archi/.gnupg/openpgp-revocs.d/8E5D685F423A584569686675E4E763905FAD148B.rev'

이제 저희 키를 신뢰하기 위해 본인의 키로 서명할 수 있습니다:

$ gpg --sign-key 224DA6DB47A3935BDCC3BE17A3D181DF2D554CCF

pub  ed25519/A3D181DF2D554CCF
     created: 2021-05-22  expires: never       usage: SC
     trust: unknown       validity: unknown
sub  cv25519/E527A892E05B2F38
     created: 2021-05-22  expires: never       usage: E
[ unknown] (1). ArchiBot <ArchiBot@JustArchi.net>


pub  ed25519/A3D181DF2D554CCF
     created: 2021-05-22  expires: never       usage: SC
     trust: unknown       validity: unknown
 Primary key fingerprint: 224D A6DB 47A3 935B DCC3  BE17 A3D1 81DF 2D55 4CCF

     ArchiBot <ArchiBot@JustArchi.net>

Are you sure that you want to sign this key with your
key "archi" (E4E763905FAD148B)

Really sign? (y/N) y

이렇게 하면 완료입니다. 저희 키를 신뢰한 뒤에는 검증 시 gpg가 더 이상 경고를 표시하지 않아야 합니다:

$ gpg --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Mon 02 Aug 2021 00:34:18 CEST
gpg:                using EDDSA key 224DA6DB47A3935BDCC3BE17A3D181DF2D554CCF
gpg: Good signature from "ArchiBot <ArchiBot@JustArchi.net>" [full]

본인의 키로 저희 키에 서명하고 나면 신뢰 표시가 [unknown]에서 [full]로 바뀌는 것을 확인할 수 있습니다.

축하합니다, 다운로드한 릴리스가 변조되지 않았음을 검증하셨습니다! 👍

---

4월 1일인데 ASF 언어가 이상하게 바뀌었어요, 무슨 일인가요?

추카추카! 만우절 이스터에그 발견 성공!!! 커스텀 CurrentCulture 옵션을 설정하지 않았다면, 4월 1일에 ASF는 실제로 시스템 언어 대신 LOLcat 언어를 사용합니다. 혹시 이 동작을 비활성화하고 싶다면, CurrentCulture를 대신 사용하고 싶은 로케일로 간단히 설정하면 됩니다. 참고로, CurrentCulture를 qps-Ploc 값으로 설정하면 이 이스터에그를 날짜와 무관하게 항상 활성화할 수도 있습니다.