python3 -m http.server는 정말 편합니다. 하지만 파일 하나 빠르게 띄우는 수준을 넘어서면 금방 한계가 드러납니다. HTTPS가 필요하고, 인증이 필요하고, 업로드나 WebDAV가 필요하고, 더 나아가 여러 프로토콜을 함께 열어야 하면 즉시 다른 도구를 찾게 됩니다. goshs는 바로 그 지점을 겨냥한 도구입니다. 단일 바이너리 하나로 파일 서버, 인증, TLS, 여러 프로토콜, 공유 링크, 콜백 기능까지 묶어 놓은 Go 기반 서버입니다. README

Sources

goshs의 핵심 아이디어: “Apache까지는 무겁고, http.server는 너무 가볍다”

README의 첫 문장은 이 프로젝트의 포지션을 잘 드러냅니다. 파일을 옮기거나 빠르게 HTTPS 서버를 세워야 하는 순간, python3 -m http.server로는 부족하지만 Apache를 구성하기도 부담스럽다는 문제의식입니다. goshs는 이 중간 지점을 단일 실행 파일 하나로 메우려 합니다. README

flowchart TD
    A["간단한 파일 공유 필요"] --> B{"어느 정도 기능이 필요한가?"}
    B -->|아주 단순| C["python3 -m http.server"]
    B -->|TLS/인증/업로드/여러 프로토콜| D["goshs"]
    B -->|대규모 웹서버 구성| E["Apache/Nginx 등"]

    classDef simpleTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef middleTone fill:#c0ecd3,stroke:#5aa978,color:#333
    classDef heavyTone fill:#fde8c0,stroke:#c59a45,color:#333
    class A,B simpleTone
    class C simpleTone
    class D middleTone
    class E heavyTone

즉 goshs는 “작지만 기능 많은 임시 서버"라는 위치를 차지합니다. 설치와 실행은 가볍게 유지하면서, 실전에서 자주 필요한 옵션은 넓게 챙긴 것이 특징입니다.

하나의 바이너리 안에 들어간 것들

README를 보면 goshs는 단순 HTTP 파일 서버가 아닙니다. HTTP/S, WebDAV, SFTP, SMB, LDAP/S, basic auth, certificate auth, self-signed 및 Let’s Encrypt TLS, IP whitelist, file-based ACL, share link, webhook, JSON API, mDNS, localhost.run tunnel 같은 기능을 포함합니다. README

flowchart TD
    A["goshs single binary"] --> B["HTTP/S"]
    A --> C["WebDAV"]
    A --> D["SFTP"]
    A --> E["SMB"]
    A --> F["LDAP/S"]
    A --> G["TLS/Auth"]
    A --> H["Share links"]
    A --> I["Webhook/API"]
    A --> J["DNS/SMTP callback"]

    classDef coreTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef featureTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A coreTone
    class B,C,D,E,F,G,H,I,J featureTone

이 구성을 보면 goshs가 단순 “파일 올리고 받는 서버"가 아니라, 파일 전달·프로토콜 실험·운영 편의 기능을 한 번에 묶은 툴박스 에 가깝다는 것을 알 수 있습니다.

파일 서버 관점에서 보면: 업로드, 다운로드, 공유, 인증이 한 세트다

가장 무난한 사용 시나리오는 파일 서버입니다. README는 drag & drop 업로드, POST/PUT 업로드, 삭제, bulk ZIP, QR code 생성, token-based share link, download limit, time limit 같은 기능을 제공합니다. README

flowchart TD
    A["파일 공유 작업"] --> B["다운로드"]
    A --> C["업로드"]
    A --> D["삭제/정리"]
    A --> E["공유 링크"]
    A --> F["인증/TLS"]
    E --> G["시간 제한"]
    E --> H["다운로드 횟수 제한"]

    classDef taskTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef controlTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A,B,C,D taskTone
    class E,F,G,H controlTone

이 조합이 중요한 이유는 실제 파일 전달 작업이 생각보다 빨리 운영 문제로 넘어가기 때문입니다. “파일 하나 잠깐 열자"로 시작해도 곧 “외부에 보내야 하니 HTTPS가 필요하다”, “아무나 받으면 안 되니 인증이 필요하다”, “다운로드 횟수를 제한하고 싶다"는 요구가 따라옵니다.

goshs가 진짜 편한 이유: 설치 경로가 매우 넓다

README를 보면 설치 경로가 매우 폭넓습니다. curl|sh, go install, Kali/Parrot 패키지, Arch AUR, BlackArch, Alpine, Snap, Fedora COPR, openSUSE, Nix, Homebrew, Scoop, winget, Chocolatey, Docker, GitHub Releases까지 제공합니다. README

이 의미는 단순히 “설치 명령이 많다"가 아닙니다. 사용 환경이 제각각인 개발자, 보안 실습 환경, 리눅스 배포판, macOS, Windows에서 똑같은 도구를 바로 가져다 쓸 수 있다 는 뜻입니다.

flowchart TD
    A["goshs 배포 방식"] --> B["패키지 매니저"]
    A --> C["Go install"]
    A --> D["curl | sh"]
    A --> E["Docker"]
    A --> F["GitHub release binary"]
    B --> G["Linux/macOS/Windows 다양하게 지원"]

    classDef distTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef methodTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A distTone
    class B,C,D,E,F,G methodTone

단일 바이너리 툴의 강점은 결국 “필요한 순간 바로 쓸 수 있느냐"입니다. goshs는 이 점을 상당히 신경 쓴 프로젝트로 보입니다.

왜 Go로 만들었는가

저장소 메타데이터를 보면 이 프로젝트는 Go로 작성되어 있습니다. GitHub API 기준 기본 언어는 Go이고, 저장소 설명도 single-binary file server를 강조합니다. Go는 정적 바이너리 배포, 네트워크 서버 작성, cross-platform release, concurrency 처리에 유리하기 때문에 이런 도구와 궁합이 좋습니다. GitHub API metadata

flowchart TD
    A["Go 선택"] --> B["단일 바이너리 배포 쉬움"]
    A --> C["네트워크 서버 작성 적합"]
    A --> D["여러 OS 배포 쉬움"]
    A --> E["동시 연결 처리 유리"]

    classDef goTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef benefitTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A goTone
    class B,C,D,E benefitTone

즉 goshs의 “무엇이든 한 파일로 들고 다닌다"는 느낌은 구현 언어 선택과도 잘 맞아떨어집니다.

이 프로젝트가 특히 다른 점: 협업/실습/보안 도구가 같이 들어 있다

README에는 일반 파일 서버 기능 외에 DNS server, SMTP server, redirect endpoint, webhook, rev shell catcher, NTLM hash capture, LDAP credential capture 같은 기능도 나옵니다. README

이 부분은 분명히 보안 실습, CTF, red team, penetration testing 문맥에서 유용한 기능들입니다. 저장소 topic에도 red-teaming, penetration-testing, offensive-security, ctf가 포함되어 있습니다. GitHub API metadata

다만 이 기능들은 오남용 여지가 있으므로, 합법적이고 승인된 보안 실습, 자체 환경 테스트, 교육 목적에서만 다뤄야 합니다. 여기서는 사용 절차를 상세히 다루지 않고, 프로젝트의 성격을 설명하는 수준에 머무는 것이 적절합니다.

flowchart TD
    A["goshs 기능군"] --> B["개발/파일 공유"]
    A --> C["운영 편의"]
    A --> D["보안 실습/CTF"]
    B --> E["HTTP/S, WebDAV, 업로드, 공유"]
    C --> F["TLS, auth, ACL, webhook, tunnel"]
    D --> G["프로토콜/콜백/캡처 기능"]

    classDef devTone fill:#c0ecd3,stroke:#5aa978,color:#333
    classDef opsTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef secTone fill:#fde8c0,stroke:#c59a45,color:#333
    class A opsTone
    class B,E devTone
    class C,F opsTone
    class D,G secTone

이 점 때문에 goshs는 일반 개발자 도구이면서 동시에 offensive security 쪽에서 관심을 받을 수 있는 경계형 툴입니다.

python3 -m http.server 대체재라는 말의 진짜 의미

README는 goshs를 python3 -m http.server 대체재로 부릅니다. README 이 말을 곧이곧대로 “완전히 같은 범주의 더 좋은 버전"으로 이해하면 조금 부족합니다. 사실 goshs는 훨씬 큰 범위를 커버합니다.

flowchart TD
    A["python3 -m http.server"] --> B["빠른 정적 파일 서빙"]
    C["goshs"] --> D["정적 파일 서빙"]
    C --> E["HTTPS/TLS"]
    C --> F["인증"]
    C --> G["여러 프로토콜"]
    C --> H["업로드/공유/웹훅"]
    C --> I["운영/실습 확장 기능"]

    classDef pyTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef goshsTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A,B pyTone
    class C,D,E,F,G,H,I goshsTone

즉 “간단한 한 줄 서버"라는 UX는 유지하되, 실전에서 곧바로 부딪히는 요구사항을 더 많이 감당하도록 확장한 도구라고 보는 편이 정확합니다.

어떤 사람에게 특히 맞을까

README만 봐도 대상 사용자는 꽤 분명합니다.

  • 빠르게 안전한 파일 공유를 해야 하는 개발자
  • HTTPS, 인증, 공유 링크까지 한 번에 필요한 운영자
  • 여러 프로토콜을 테스트하거나 실습하는 보안 엔지니어/교육 환경
  • 단일 바이너리 기반 툴을 선호하는 사용자
flowchart TD
    A["goshs가 잘 맞는 사용자"] --> B["개발자"]
    A --> C["운영자"]
    A --> D["보안 실습 환경"]
    A --> E["CTF/교육"]
    B --> F["파일 공유/업로드/HTTPS"]
    C --> G["인증/TLS/공유 링크"]
    D --> H["프로토콜 실험"]
    E --> I["간편한 셋업"]

    classDef userTone fill:#c5dcef,stroke:#5b7fa6,color:#333
    classDef fitTone fill:#c0ecd3,stroke:#5aa978,color:#333
    class A,B,C,D,E userTone
    class F,G,H,I fitTone

반대로 단순 정적 파일 한 번 띄우는 것이 전부라면 여전히 Python 내장 서버나 간단한 다른 도구가 더 충분할 수 있습니다.

실전 적용 포인트

첫째, goshs는 “무조건 대체” 도구라기보다 “요구사항이 하나만 더 생기면 내장 서버 대신 꺼낼 도구"에 가깝습니다.

둘째, 기능이 많은 만큼 기본 사용 시에도 어떤 포트, 어떤 인증, 어떤 프로토콜을 열고 있는지 명확히 알아야 합니다. 단일 바이너리의 편의성이 곧 설정 단순성을 의미하지는 않습니다.

셋째, 보안 실습용 기능은 합법적이고 승인된 환경에서만 다뤄야 합니다. 일반 파일 공유 목적과 offensive security 목적을 혼동하면 안 됩니다.

넷째, 팀에서 반복적으로 파일 전달/수집/공유가 일어난다면 HTTPS, basic auth, time-limited share link 같은 운영 기능의 체감 가치가 큽니다.

다섯째, 단일 바이너리 툴은 배포가 쉽지만, 그래서 더더욱 어떤 기능이 기본 활성화인지 문서를 먼저 읽고 들어가는 습관이 중요합니다.

핵심 요약

  • goshs는 Go로 만든 단일 바이너리 파일 서버이며, python3 -m http.server보다 더 많은 실전 요구를 커버하려는 도구입니다. README
  • HTTP/S, WebDAV, SFTP, SMB, LDAP/S, TLS, 인증, 업로드/삭제, 공유 링크, 웹훅, JSON API 등을 포함합니다.
  • 설치 경로가 매우 넓어 Linux, macOS, Windows, Docker, 패키지 매니저 환경에서 바로 쓸 수 있습니다.
  • 단순 파일 공유를 넘어 운영 편의와 여러 프로토콜 실험까지 하나의 실행 파일로 묶은 것이 특징입니다.
  • 일부 기능은 보안 실습/CTF/레드팀 문맥에서 유용하지만, 오남용 가능성이 있으므로 합법적이고 승인된 환경에서만 다뤄야 합니다.

결론

goshs의 매력은 “기능이 많다"보다 “필요한 순간 바로 꺼내 쓸 수 있는 단일 바이너리"라는 점에 있습니다. 내장 서버의 가벼움과 실전 기능의 넓이를 동시에 잡으려는 시도라고 볼 수 있습니다.

그래서 이 프로젝트를 볼 때 중요한 질문은 “이게 Python 내장 서버보다 좋은가?“가 아니라, “내가 필요한 실전 기능을 얼마나 빠르게 한 파일로 가져올 수 있는가?” 입니다. 그 질문에 자주 “TLS도 필요하고, 인증도 필요하고, 업로드도 필요하고, 가끔은 여러 프로토콜도 필요하다"라고 답한다면, goshs는 꽤 설득력 있는 선택지입니다.