JD: 장우준

Simploy: 배포가 이렇게 간단할 수 있다고?

Jundev76 — Fri, 11 Jul 2025 14:29:09 +0900

한 번 사용해보세요 :❘)

배포, 왜 이렇게 복잡한가?

개발자라면 누구나 한 번쯤 겪어봤을 상황이 있습니다. 코드는 완성했는데 배포하는 과정이 너무 복잡해서 막막한 순간 말이에요. 특히 개인 프로젝트나 소규모 팀에서 일할 때는 더욱 그렇습니다.

대형 CI/CD 도구들은 기능이 풍부하지만 설정이 복잡하고 무겁습니다. Jenkins는 설치부터 설정까지 상당한 시간이 걸리고, GitHub Actions는 private repository에서 사용하려면 비용이 발생합니다. GitLab CI는 좋지만 개인 프로젝트에는 과한 느낌이죠.

그렇다고 매번 수동으로 파일을 전송하고 서버에 접속해서 명령어를 실행하는 것도 비효율적입니다. 실수로 잘못된 명령어를 입력하거나 파일을 빼먹는 경우도 종종 발생하죠.

이런 고민 끝에 저는 Simploy라는 라이브러리를 만들게 되었습니다. "Simple Deploy"의 줄임말로, 이름 그대로 간단한 배포를 목표로 합니다.

Simploy란 무엇인가?

Simploy는 개인 프로젝트나 소규모 팀을 위한 초간단 CI/CD 배포 도구입니다. 복잡한 설정 없이 SSH를 통해 원격 서버에 파일을 전송하고 명령어를 실행할 수 있습니다. 환경 분리와 비밀 정보 관리도 지원하면서, 정말 필요한 기능만 담았습니다.

핵심 아이디어는 간단합니다. 설정 파일 하나로 파일을 서버에 전송하고 몇 개의 명령어를 실행하는 것. 복잡한 파이프라인이나 컨테이너 오케스트레이션 같은 고급 기능은 제외하고, 실제로 자주 사용하는 기본적인 배포 기능에만 집중했습니다.

Simploy의 주요 특징

1. 극도로 간단한 설정

Simploy의 가장 큰 특징은 설정의 단순함입니다. JSON 형태의 설정 파일을 사용해서 누구나 쉽게 이해할 수 있습니다. 복잡한 YAML 문법이나 특별한 DSL을 배울 필요가 없죠.

{
  "environments": {
    "dev": {
      "servers": [
        {
          "name": "web",
          "ssh": {
            "host": "${DEV_WEB_HOST}",
            "port": 22,
            "user": "${DEV_WEB_USER}",
            "password": "${DEV_WEB_PASSWORD}"
          },
          "localPath": ".",
          "remotePath": "/home/ubuntu/app",
          "transferIgnores": ["node_modules", ".git", ".env"],
          "shell": [
            "cd /home/ubuntu/app",
            "npm ci",
            "npm start"
          ]
        }
      ]
    }
  }
}

이 설정만 봐도 무엇을 하는지 직관적으로 이해할 수 있습니다. 로컬의 현재 디렉터리를 서버의 특정 경로로 전송하고, 그 후에 필요한 명령어들을 실행하는 것입니다.

2. 환경 분리와 다중 서버 지원

실제 개발 환경에서는 개발, 스테이징, 프로덕션 환경을 분리해서 관리하는 것이 일반적입니다. Simploy는 이런 환경 분리를 자연스럽게 지원합니다.

{
  "environments": {
    "dev": {
      "servers": [...]
    },
    "staging": {
      "servers": [...]
    },
    "production": {
      "servers": [...]
    }
  }
}

각 환경마다 여러 서버를 설정할 수 있어서, 로드 밸런싱을 위해 여러 대의 서버에 동시에 배포하는 것도 가능합니다. 예를 들어, 프로덕션 환경에서 웹 서버 여러 대에 순차적으로 배포할 수 있습니다.

3. 보안을 고려한 비밀 정보 관리

개발할 때 가장 신경 쓰이는 부분 중 하나가 비밀 정보 관리입니다. 서버 비밀번호, API 키, 데이터베이스 접속 정보 등을 코드에 하드코딩할 수는 없으니까요.

Simploy는 이 문제를 simploy.private.json 파일로 해결합니다. 이 파일에 모든 비밀 정보를 저장하면, 자동으로 .gitignore에 추가되어서 Git 저장소에 실수로 커밋되는 것을 방지합니다.

{
  "DEV_WEB_HOST": "your.dev.server.com",
  "DEV_WEB_USER": "ubuntu",
  "DEV_WEB_PASSWORD": "your-secure-password",
  "PROD_DB_PASSWORD": "super-secret-password"
}

설정 파일에서는 ${변수명} 형태로 변수를 참조할 수 있어서, 비밀 정보와 일반 설정을 깔끔하게 분리할 수 있습니다.

4. 즉시 사용 가능한 npx 지원

요즘 개발 트렌드를 보면 전역 설치를 피하고 npx를 사용하는 경우가 많습니다. Simploy도 이런 트렌드를 반영해서 npx를 통한 즉시 사용을 지원합니다.

# 전역 설치
pnpm add -g simploy
simploy init
simploy deploy --env dev

# 또는 npx로 바로 사용
npx simploy init
npx simploy deploy --env dev

전역 설치 없이도 바로 사용할 수 있어서, 새로운 프로젝트를 시작할 때 빠르게 배포 환경을 구축할 수 있습니다.

5. 스마트한 파일 전송

Simploy는 파일 전송 시 여러 최적화 기능을 제공합니다. transferIgnores 옵션으로 불필요한 파일들을 제외할 수 있고, remoteIgnoresWhenClean 옵션으로 서버에서 삭제하지 않을 파일들을 지정할 수 있습니다.

{
  "transferIgnores": ["node_modules", ".git", ".env", "*.log"],
  "remoteIgnoresWhenClean": [".env", "uploads/"]
}

이렇게 하면 필요한 파일만 전송해서 속도를 높이고, 서버의 중요한 파일들은 보호할 수 있습니다.

실제 사용 시나리오

개인 블로그나 포트폴리오 사이트

Next.js, Nuxt.js, React 등으로 개발한 개인 사이트를 VPS에 배포할 때 Simploy를 사용하면 매우 편리합니다. 빌드부터 배포까지 모든 과정을 자동화할 수 있고, 글 하나 수정할 때마다 간단한 명령어 하나로 배포할 수 있습니다.

프로토타입 개발

빠른 프로토타입 개발 시에는 복잡한 CI/CD 파이프라인을 구축할 시간이 없습니다. Simploy를 사용하면 몇 분 만에 배포 환경을 구축하고, 팀원들과 프로토타입을 공유할 수 있습니다.

클라이언트 프로젝트

프리랜서나 에이전시에서 클라이언트의 서버에 직접 배포해야 하는 경우가 많습니다. 클라이언트마다 서버 환경이 다르지만, Simploy의 설정 파일만 수정하면 쉽게 대응할 수 있습니다.

소규모 팀 프로젝트

스타트업이나 소규모 팀에서는 리소스가 제한적이라 복잡한 DevOps 도구를 도입하기 어렵습니다. Simploy는 최소한의 설정으로 팀 전체가 일관된 배포 프로세스를 사용할 수 있게 해줍니다.

사용법 가이드

1. 설치 및 초기화

# 전역 설치 (권장)
npm install -g simploy

# 프로젝트 초기화
simploy init

simploy init 명령어를 실행하면 두 개의 파일이 생성됩니다:

simploy.json: 메인 설정 파일
simploy.private.json: 비밀 정보 파일 (자동으로 .gitignore에 추가)

2. 설정 파일 편집

생성된 설정 파일들을 프로젝트에 맞게 수정합니다. 서버 정보, 배포 경로, 실행할 명령어 등을 설정하면 됩니다.

3. 배포 실행

# 개발 환경에 배포
simploy deploy --env dev

# 프로덕션 환경에 배포
simploy deploy --env production

배포 과정에서 진행 상황이 실시간으로 표시되고, 문제가 발생하면 어떤 단계에서 실패했는지 명확하게 알 수 있습니다.

다른 배포 도구와의 비교

vs GitHub Actions

GitHub Actions: 강력한 워크플로우 엔진, 다양한 통합 지원, 하지만 private repo에서는 유료
Simploy: 간단한 설정, 즉시 사용 가능, 완전 무료, 하지만 기능이 제한적

vs Jenkins

Jenkins: 매우 강력하고 확장 가능, 하지만 설치/설정이 복잡하고 리소스 사용량이 많음
Simploy: 설치 없이 바로 사용, 최소한의 설정, 하지만 고급 기능 부족

vs Docker + Docker Compose

Docker: 환경 일관성, 확장성, 하지만 학습 곡선이 있고 설정이 복잡
Simploy: 기존 서버 환경 그대로 사용, 즉시 적용 가능, 하지만 환경 일관성은 떨어짐

설치 및 사용

# 전역 설치
npm install -g simploy

# 또는 npx로 바로 사용
npx simploy init
npx simploy deploy --env dev

GitHub: https://github.com/JunDev76/simploy
npm: https://www.npmjs.com/package/simploy

여러분의 배포 과정이 조금이라도 편해졌으면 좋겠습니다. 사용해보시고 피드백이나 개선 아이디어가 있으시면 언제든 GitHub에서 공유해 주세요!

학교 정부회장 토론회를 TV 방송처럼: 2주간의 준비 과정

Jundev76 — Fri, 11 Jul 2025 08:38:52 +0900

012

2025년 제40대 정부회장 후보 정책 토론회 중계 준비 기록

개요

2025년 6월 11일에 진행된 제40대 정부회장 후보 정책 토론회의 방송을 담당했다. 작년과 달리 충분한 준비 시간을 확보할 수 있어서 여러 기술적 개선사항을 적용해볼 수 있었다. 이 글에서는 준비 과정에서 시도한 것들과 실제 방송에서 겪었던 문제점들을 정리해보려 한다.

작년을 돌아보며

작년 토론회를 떠올리면 지금도 아찔하다. 그때는 방송부원들 중에서 유튜브 스트리밍을 할 수 있는 사람이 나밖에 없어서, 토론회 전날 밤에야 급하게 준비를 시작했다. 카메라 한 대, 사무용 컴퓨터 하나, 그리고 떨리는 마음으로 진행했던 그 방송은 솔직히 많이 아쉬웠다.

화면은 단조로웠고 프레임은 불안정적이었고, 음질도 좋지 않았다. 후보자들이 핸드마이크를 들고 발언하면 그 소리가 스피커로 나오고, 그걸 다시 카메라 마이크로 받는 방식이었으니 음질이 좋을 리가 없었다. 게다가 카메라 앵글도 한정적이어서 토론의 긴장감이나 역동성을 제대로 전달하지 못했다는 생각이 들었다.

그래서 올해는 방송부 활동을 하면서 계속 마음 한구석에 '제대로 된 토론회 중계를 해보고 싶다'는 생각을 품고 있었다. 마침 올해는 2주 정도의 준비 시간을 확보할 수 있어서 여러 가지 시도해볼 수 있었다.

작년 대비 개선사항

1. 카메라 구성의 대대적 변화

가장 큰 변화는 카메라 구성이었다. 작년 1대에서 4대로 늘리면서 완전히 다른 차원의 방송이 가능해졌다.

우선 하드웨어적으로 해결해야 할 문제들이 많았다. 맥북 하나로 4개의 카메라 신호를 동시에 받으려면 포트가 부족했다. 그래서 썬더볼트 허브를 구입해서 포트를 확장했고, 각 카메라 신호를 받기 위한 캡처보드도 추가로 준비했다.

카메라 배치도 고민이 많았다. 토론 테이블을 중심으로 각 후보자를 개별로 잡을 수 있는 앵글, 전체를 볼 수 있는 와이드 앵글, 그리고 질문자석을 잡을 수 있는 앵글까지 고려해서 위치를 정했다. 리허설을 몇 번 해보면서 최적의 배치를 찾아갔다.

카메라가 늘어나면서 할 수 있게 된 것들이 정말 많았다. 각 후보자별로 전용 카메라를 할당할 수 있어서 발언할 때의 표정이나 제스처를 놓치지 않고 포착할 수 있었다. 특히 2분할 화면 구성이 가능해진 게 큰 변화였다. 한 후보자가 발언할 때 상대방의 반응도 동시에 보여줄 수 있어서 토론의 긴장감이 훨씬 생생하게 전달됐다.

주도권 토론 구간에서는 이 멀티 카메라 구성이 정말 빛을 발했다. 공격하는 쪽과 방어하는 쪽의 표정을 동시에 잡을 수 있어서 마치 TV 토론 프로그램을 보는 것 같은 몰입감을 만들어낼 수 있었다. 진짜 방송 같았다!

2. 오디오 시스템의 혁신

두 번째 큰 변화는 마이크 시스템이었다. 기존의 핸드마이크 방식은 여러 문제가 있었다. 후보자들이 마이크를 직접 들고 있어야 해서 제스처가 제한적이었고, 스피커로 출력된 소리를 카메라 마이크로 다시 받는 방식이라 음질도 좋지 않았다. 게다가 하울링 위험도 항상 있었다.

이번에는 각 후보자에게 개별 핀마이크를 제공하기로 했다. 여러 제품을 알아보다가 앱코 핀마이크를 선택했는데, 가격 대비 성능이 좋고 안정성도 괜찮다는 리뷰들을 보고 결정했다. 4개를 주문해서 각자 전용으로 사용할 수 있게 했다.

(핀마이크 장착 테스트 장면)

핀마이크 도입으로 얻은 효과는 예상보다 훨씬 컸다. 우선 음질이 확연히 개선됐다. 입과 마이크 사이의 거리가 일정하게 유지되니까 볼륨도 안정적이었고, 주변 소음도 훨씬 적게 들어왔다. 후보자들도 양손을 자유롭게 사용할 수 있어서 더 자연스럽게 의견을 표현할 수 있었다고 했다.

시각적으로도 훨씬 깔끔해졌다. 핸드마이크가 화면을 가리지 않으니까 후보자들의 표정과 제스처가 더 잘 보였다. 특히 클로즈업 화면에서는 그 차이가 확실히 드러났다.

3. 자동 마이크 제어 시스템 구현

핀마이크를 도입하면서 생각지도 못했던 부가 효과가 있었다. 바로 시간 제한에 따른 자동 마이크 제어 시스템을 구현할 수 있게 된 것이다.

기존에는 소리가 스피커를 통해 들어가서, 시간이 지나도 자동으로 마이크를 끌 방법이 없었다. 하지만 핀마이크는 OBS 믹서를 통해 개별 제어가 가능했다. 그래서 발언시 시간을 관리해줄 담당과, 패널 그리고 웹소켓을 이용한 자동 개폐 시스템을 구현할 수 있었다.

4. 조명과 기타 세팅

카메라와 오디오만큼 중요한 게 조명이었다. 기존에는 홀의 기본 등에만 의존했는데, 이번에는 추가 조명 장비를 준비했다.

조명 하나로도 화면 품질이 확실히 달라졌다. 얼굴이 더 선명하게 보이고, 그림자도 줄어들어서 전체적으로 훨씬 전문적인 느낌이 났다.

배경 세팅도 신경을 썼다. 토론회답게 깔끔하고 격식 있는 분위기를 만들기 위해 배너와 테이블 세팅에도 시간을 투자했다. 작은 디테일들이지만 전체적인 완성도를 높이는 데 도움이 됐다.

방송 중 발생한 문제점들

1. 예상치 못한 인터넷 문제

방송이 한창 진행되고 있던 중에 갑자기 스트리밍이 끊어졌다. 처음에는 내 설정 문제인 줄 알고 급하게 확인해봤는데, 교내 인터넷 자체에 문제가 생긴 것이었다. 다른 학생들도 인터넷이 안 된다고 하더라.

그 순간 정말 당황스러웠다. 토론은 계속 진행되고 있는데 방송이 나가지 않고 있었으니까. 다행히 1-2분 만에 인터넷이 복구돼서 바로 스트리밍을 재시작할 수 있었지만, 그 짧은 시간 동안 시청자들이 많이 이탈했을 것 같아 아쉬웠다.

이 일을 겪고 나서 백업 계획의 중요성을 느꼈다. 앞으로는 모바일 핫스팟이나 별도의 인터넷 연결을 준비해둬야겠다는 생각이 들었다. 아니면 아예 녹화와 스트리밍을 병행해서 문제가 생기면 녹화분이라도 나중에 올릴 수 있도록 하는 것도 좋을 것 같다.

2. 핀마이크 채널 문제

전체 방송 중에서 가장 아찔했던 순간은 여부회장 토론 때였다. 한 후보자의 핀마이크에서 갑자기 지지직거리는 노이즈가 나오기 시작했다. 처음에는 일시적인 문제인 줄 알았는데, 계속 지속되면서 방송에서도 그 소리가 들려버렸다.

급하게 원인을 파악해보니 핀마이크 착용 과정에서 채널이 바뀌어버린 것 같았다. 리허설 때는 모든 채널이 정상 작동했는데, 본 방송에서 이런 일이 생기니까 정말 예상치 못한 일이었다.

그 순간 머릿속이 하얘졌다. 토론은 계속 진행되고 있는데 한 후보자의 소리만 이상하게 들리고 있었으니까. 일단 침착하게 오디오 믹서를 확인하면서 각 후보자의 마이크 채널을 하나씩 바꿔가며 테스트해봤다. 다행히 몇 초 만에 정상 채널을 찾을 수 있었고, 깨끗한 소리로 복구할 수 있었다.

하지만 그 짧은 시간 동안 해당 후보자가 불편했을 것 같아 정말 미안했다.

이 일을 겪고 나서 오디오 장비에 대한 사전 체크를 더 꼼꼼히 해야겠다고 생각했다. 채널 고정이 제대로 됐는지 여러 번 확인하고, 백업 채널도 미리 준비해둬야겠다. 그리고 혹시나 하는 상황에 대비해서 즉석에서 문제를 해결할 수 있는 매뉴얼도 필요할 거 같다.

3. 멀티태스킹의 어려움

4개 카메라와 여러 오디오 채널을 동시에 관리하면서 느낀 것은 멀티태스킹의 어려움이었다. 화면 전환 타이밍을 맞추고, 오디오 레벨을 확인하고, 스트리밍 상태를 모니터링...

특히 토론이 열띠게 진행될 때는 화면 전환 타이밍을 놓치기 쉬웠다. 누가 발언할지 예측하기 어려운 순간들이 있었고, 그럴 때마다 급하게 카메라를 전환해야 했다. 몇 번은 전환이 늦어져서 발언 초반 부분을 놓친 적도 있었다.

이런 경험을 통해 느낀 것은 방송 진행자와 기술 담당자를 분리하는 게 좋겠다는 생각이었다. 아니면 최소한 카메라 전환만이라도 담당할 보조 인력이 있으면 훨씬 수월할 것 같다.

4. 예상보다 높은 시스템 부하

맥북으로 4개 카메라를 동시에 처리하면서 스트리밍까지 하니까 시스템 부하가 예상보다 높았다. 중간중간 팬 소리가 크게 나고 발열도 심했다. 다행히 방송이 중단되지는 않았지만, 조금 더 길었다면 문제가 생겼을 수도 있겠다는 생각이 들었다.

앞으로는 더 높은 사양의 장비를 사용하거나, 아니면 처리 부하를 분산시킬 수 있는 방법을 고민해봐야겠다. 외부 캡처 장비를 사용해서 인코딩 부하를 줄이는 것도 하나의 방법일 것 같다.

준비 시간의 중요성

물론 하루 이틀 정도의 시간만 있어도 어느 정도의 방송을 구현할 수는 있을 것이다. 하지만, 이번 경험을 통해서 2주간의 준비 기간이 얼마나 중요한지 다시 한번 느꼈다. 작년의 하루 준비와는 차원이 다른 결과를 만들 수 있었다. 특히 새로운 장비를 도입할 때는 충분한 테스트 시간이 필요하다는 것을 깨달았다.

다만 준비를 아무리 철저히 해도 예상치 못한 문제는 생길 수 있다는 것도 배웠다. 중요한 것은 그런 상황에서 빠르게 대응할 수 있는 능력과 백업 계획을 세워두는 것이다.

앞으로의 개선 방향, 만약 다시 하게 된다면

백업 인터넷 연결을 준비하고, 오디오 장비의 안정성을 높이기 위한 체크 시스템을 구축해야겠다. 특히 핀마이크 채널 문제 같은 경우를 대비해서 실시간 모니터링 시스템을 만들어보고 싶다.

리허설 횟수를 늘리고, 각 장비별로 체크리스트를 만들어서 빠뜨리는 부분이 없도록 해야겠다. 특히 오디오 장비는 본 방송 직전까지도 여러 번 확인하는 것이 좋을 것 같다.

기본적인 안정성이 확보되면 몇 가지 새로운 기능들도 도입해보고 싶다. 실시간 자막 시스템이나 시청자 참여 기능 같은 것들을 고려하고 있다. 화면 그래픽 요소도 추가해서 더 전문적인 느낌을 만들어보고 싶다.

다음번에는 혼자가 아닌 팀으로 진행해보고 싶다. 팀원들과 함께 역할을 나누어서 각자 전문 분야를 맡도록 하면 더 완성도 높은 방송을 만들 수 있을 것 같다.

정리

2주간의 준비를 통해 작년보다는 훨씬 안정적이고 완성도 높은 방송을 진행할 수 있었다. 멀티 카메라 시스템으로 시청 경험이 크게 개선됐고, 핀마이크 도입으로 음질과 후보자 편의성이 향상됐다. 자동 마이크 제어 시스템 같은 새로운 기능도 성공적으로 구현할 수 있었다. 조명 장비 추가로 화면 품질도 한 단계 높일 수 있었다.

하지만 동시에 예상치 못한 기술적 문제들도 경험했다. 교내 인터넷 문제로 인한 방송 중단, 핀마이크 채널 문제 등은 사전 준비만으로는 완전히 방지하기 어려운 일들이었다. 이런 경험을 통해 백업 계획의 중요성과 실시간 대응 능력의 필요성을 절실히 느꼈다.

방송은 결국 시청자와 출연자 모두에게 좋은 경험을 제공하는 것이 목표다. 화려한 기술이나 멋진 효과도 중요하지만, 그보다는 안정적이고 신뢰할 수 있는 방송이 더 중요하다는 것을 이번에 배웠다.

그래도 전체적으로는 만족스러운 결과였다. 작년의 아쉬움을 많이 해소할 수 있었고, 방송부 활동을 하면서 쌓아온 실력을 제대로 발휘할 수 있는 기회였다.

다음 토론회에서는 이번 경험을 바탕으로 더 안정적이고 완성도 높은 방송을 만들어보고 싶다. 기술적 안정성을 확보하면서도 새로운 도전을 멈추지 않는, 그런 방송을 목표로 하고 있다.

이 포스트에서 다루지 못한 자동 마이크 제어 시스템의 구현 과정은 다음 글에서 자세히 다룰 예정입니다. 구체적인 코드와 설정 방법, 그리고 시행착오 과정까지 모두 공유해보겠습니다.

긴 글 읽어주셔서 감사합니다.

README.md - 장우준

Jundev76 — Fri, 13 Jun 2025 10:17:15 +0900

드디어 기술 블로그의 첫 포스팅을 올리게 되었네요. 사실 블로그를 처음 써보는 거라 어떻게 시작해야 할지 고민이 많았어요. 그래도 첫 글로는 간단한 자기소개와 함께 지금까지의 개발 여정을 풀어보려고 합니다.

블로그를 시작한 이유

현재 학생 개발자로 살아가면서 정말 많은 것들을 경험하고 있어요. 새로운 기술을 배우고, 프로젝트를 만들고, 때로는 엄청난 삽질도 하면서 말이죠. 이런 경험들이 쌓이다 보니 어딘가에 기록해두고 싶다는 생각이 들었습니다.

나중에 제가 다시 봐도 재밌을 것 같고, 혹시 비슷한 길을 걷고 있는 다른 분들에게도 조금이나마 도움이 될 수 있지 않을까 하는 마음에서요.

앞으로 이 블로그에서는 제가 만든 프로젝트들, 새로 배운 기술들, 그리고 개발하면서 겪은 크고 작은 경험들을 차근차근 기록해나갈 예정입니다.

프로그래밍과의 첫 만남

제가 본격적으로 텍스트 코딩을 시작한 건 2020년이었어요. PocketMine-MP로 나만의 마인크래프트 서버를 만들어보고 싶었거든요. 그 전까지는 블록 코딩 정도만 해봤는데, 이때부터 진짜 프로그래밍의 세계에 빠져들기 시작했습니다.

때마침 코로나 시기라 온라인 수업이 많았는데, 수업 영상 빨리 보고 과제 후딱 끝내고 나서 코딩하는 시간이 많았어요. 머릿속에 있던 아이디어들이 실제로 돌아가는 걸 보면서 정말 신기했습니다. '이런 게 가능하다고?!'라는 생각이 매일 들었죠.

학교의 '컴퓨터 담당'이 되기까지

학교에서는 늘 '컴퓨터 잘하는 학생'으로 불렸어요. 뭔가 컴퓨터에 문제가 생기면 선생님들이 저를 부르셨는데, 이런 트러블슈팅이 진짜 재밌었습니다. 문제를 해결해드릴 때의 그 뿌듯함이란...

초등학교부터 고등학교까지 쭉 방송부에서 엔지니어로 활동했는데, 이 경험이 IT와 미디어가 얼마나 밀접하게 연결되어 있는지 깨닫게 해줬어요. 특히 라이브 방송할 때마다 기술적인 지식이 계속 늘어나는 게 느껴졌습니다.

선생님들이 핸드폰으로 간신히 하시던 라이브 스트리밍을 제대로 된 프로그램으로 바꿔드리고, 학교 방송부 기술력을 업그레이드시켜나가는 과정이 정말 보람찼어요.

마인크래프트 서버 운영, 그 뜨거웠던 시절

2020년부터 2023년까지는 마인크래프트 서버 운영에 완전히 빠져있었습니다. 지금 생각해보면 좀 그리운 시기예요. 이때 제 프로그래밍 실력이 폭발적으로 늘었던 것 같습니다.

그중에서도 가장 기억에 남는 건 '크로스팜(crsbe.kr)'이라는 서버입니다. 운이 정말 좋게도 수만 명의 분들이 즐겨주셨는데, PHP로 플러그인을 개발해서 마인크래프트가 마인크래프트 같지 않을 정도로 완전히 바꿔놓았어요.

서버용 웹사이트도 만들어보고, 소켓으로 서버끼리 연결도 해보고, MySQL로 여러 서버 데이터도 관리해봤습니다. 정말 재밌어서 시간 가는 줄도 몰랐어요. 지금도 그때가 그립네요.

구글링으로 배운 개발

사실 저는 책이나 강의로 체계적으로 배운 게 아니라, 그냥 필요한 것들을 구글링하면서 배웠어요. 지금 막힌 문제의 해결책이나 더 나은 방법을 찾으면 바로 적용해보는 식으로 말이에요.

지금 생각해보면 체계적으로 배우지 못한 게 아쉽기도 하지만, 나름 이런 방식의 장점도 있었던 것 같습니다. React가 뭔지도 모르고 HTML, CSS, JS, PHP 조합으로만 거의 2년 동안 웹을 만들었는데, 지금은 React가 훨씬 편하지만 그때 바닐라 웹을 안 했다면 웹의 기본 원리를 제대로 모르고 넘어갔을 것 같아요.

그래서 지금도 React로 바로 시작하는 건 별로 추천하지 않습니다.

현재 진행 중: Wordie 프로젝트

요즘은 Wordie(워디)라는 AI 기반 영어 학습 플랫폼을 열심히 만들고 있어요. 단어 학습을 기본으로, 영어 지문 사진을 찍으면 내신 영어에 맞게 분석해주는 기능 등을 넣을 예정입니다.

LLM과 프롬프트 엔지니어링을 활용해서 개발하고 있고, 제 첫 번째 앱스토어 승인도 받아봤어요. 이것도 나름 뿌듯한 경험이었습니다.

아직 20%도 안 됐지만 꾸준히 열심히 만들고 있고, 이제는 수능 공부까지 확대해보려고 해요. 언젠가 많은 학생들이 제 앱으로 영어 공부를 더 쉽게 할 수 있는 날이 왔으면 좋겠네요.

AI 시대의 개발

2022년 말 ChatGPT가 나왔을 때 정말 충격이었어요. 컴퓨터랑 대화가 된다니!

지금 2025년에는 Cursor를 엄청 애용하고 있습니다. 머릿속에서 구조만 대충 그려놓으면 개발 속도가 미친 듯이 빨라져요. 1인 개발이 정말 쉬워질 것 같은데, AI 발전이 기대되면서도 한편으로는 좀 무섭기도 하네요.

마무리하며

더 다양한 이야기들은 앞으로 차차 풀어나가겠습니다.

이렇게 제가 지금까지 해온 것들을 쭉 적어보니까 뭔가 싱숭생숭하네요. 제 학생 개발자 시절의 이런저런 경험들과 성장 과정이 누군가에게는 도움이 되고, 저한테는 좋은 기록이 되었으면 좋겠어요.

앞으로 열심히 작성해보겠습니다.