Chanje Park

요즘 업계 돌아가는 분위기가 영 심상치 않죠. 고민이 많으실 것 같습니다. 하지만 항상 시대가 바뀌어도 적응하고 살아남는 사람은 존재하기 마련이고, 그렇게 세상이 발전해온 것 같아요.

1. AI 툴의 발전으로 코딩 자체의 허들이 낮아진 지금, 해커톤 같은 외부 활동을 통해 개인(혹은 그룹) 프로젝트 경험을 우선으로 하고, 코딩테스트 대비 목적으로만 PS를 하는 게 취업에 더 유리하다고 생각하시나요? 아니면 여전히 PS(알고리즘)에 중점을 두면서, 별개로 해커톤을 간간이 나가는 게 나을까요?

만약 저라면 해커톤보다는 혼자서 직접 서비스를 만들어보는 경험을 더 추천할 것 같습니다. 아무튼 zero to one 경험은 매우 중요합니다. 거기서 얻는 것들이 많거든요. 근데 해커톤은 팀 단위로 하다보면 책임이 분산되는 경우가 많죠. 그러다 보니 본인의 scope 안에서만 배우게 되는게 있습니다. 그러니 혼자서 시작해보세요.

저는 학교다닐 때 에브리타임 이전에 크누타임이라는 서비스를 만들었었습니다. 모의시간표 및 강의평가 서비스였는데, 꽤 많은 학우들이 이용을 했어요. 저 혼자 기획부터 배포까지 과정을 겪으면서 정말 많이 배웠습니다. 하드 날려먹어서 복구하러 간 적도 있고요 ㅎㅎ 아무튼, 나중에 업무를 할 때도 이 경험은 중요합니다. 왜냐면 같이 일하는 팀원의 입장을 고려할 수 있는 시야가 생기거든요.

결국은 문제 해결이 PS의 본질이라고 봅니다. 그런 측면에서 저는 혼자서 서비스를 만들어 보고, 특히 만드는 것에서 그치지 않고 실제 사용자들을 받으면서 발생하는 트러블도 해결하는 경험도 매우 중요하다고 생각해요. 제가 스타트업을 창업하면서 직원들을 채용할 때, 직접 본인이 만들고 서비스한 경험을 가진 분들을 주목했습니다. 물론 ICPC 참여 경험도 무조건 가산점이 있죠. 해커톤이 무용하다고 주장하려는 건 아닌데, 팀워크를 배울 수는 있겠지만... 그것도 학부생들끼리니 좀 무의미한 경험인 것 같다는 생각은 들어요.

2. 제가 입대를 계획하고 있습니다. 선배님께서 다시 그 시절로 돌아가신다면, 군대라는 환경에서 어떤 공부나 활동을 하는 것이 가장 가성비 좋고 유익하다고 생각하시는지 궁금합니다.

아쉽게도 저는 몸이 안좋아서 군대를 가지는 않았습니다만, 보통 다른 분들은 자격증 공부도 하시는 걸로 알고 있습니다. 요즘은 중요성이 좀 떨어진 것 같긴 하지만 정보처리기사같은 자격증은 유의미하다고 생각합니다. 무엇보다도 내가 하고 싶은것이 뭔가를 정말 깊이 고민해보는 시간을 가지는 건 중요하다고 생각해요. 다른 사람의 말에 휩쓸리면 이도 저도 아닌 커리어를 가지게 될 확률이 매우 높습니다.

소위 말하는 메타인지, 본인의 강점과 단점이 무엇인지. 내가 무엇을 좋아하는지를 틈틈히 고민해보세요. 그러면 앞으로의 커리어를 어떻게 가져가야 할지에 대한 분명한 *기준*이 생길 거라 생각합니다. 정말로 커리어를 어떻게 가져가야 할지에 대한 정답은 없습니다. 다만 그 방향을 꾸준히 오래 지속할 수 있는지가 중요한듯 해요. 그러기 위해서는 내가 좋아하고 잘 할 수 있는 방향을 선택하는게 합리적이겠죠.

3. 프로젝트를 할 때 처음부터 끝까지 온전히 제 힘으로 로직을 짜내는 과정에 집중해야 할까요? 아니면 AI 툴을 적극적으로 활용하며 전체적인 구조와 흐름을 익히는 '바이브코딩' 방식만으로도 충분한 학습이 될까요?

남들이 해 놓은 best practice를 익히는 데는 Agentic Coding이 꽤 좋은 도구가 될 수 있다고 생각해요. 저는 어릴 때 네이버 소스보기를 하면서 어떻게 웹사이트를 만들어야 하는지 익혔습니다. 결국 모든 창작은 모방에서 시작되는 것이거든요. 아주 뛰어난 천재가 아닌 한, 특히 이쪽 업계에서는 오픈소스 문화가 활성화 되어 있어 모든 것을 직접 만들 필요가 없는(소위 말해, 바퀴를 재발명할 필요가 없는) 곳이기도 하니까요.

다만 남의 코드를 참조하던, LLM을 쓰던지 간에, 모든 한 줄 한 줄을 정확히 이해하는 건 매우 중요하다고 생각해요. 만들어 둔 결과물에서 이게 어떻게 동작하는 건지 물어보고, 본인이 직접 변주도 해보고 반영하고 어떻게 돌아가는지 보고, 그 과정을 반복하는거죠. 저는 이런 경험으로 오픈소스를 가져다가 제가 원하는 대로 커스터마이징 하는 경험으로 프로그래밍을 시작했는데 이해도 잘 되고 도움이 정말 많이 되었습니다. 만약 처음부터 프로젝트를 만드는게 부담스럽다면 github에서 잘 만들어진 오픈소스를 가지고 분석하는 것부터 시작해보셔도 좋을 것 같아요. 너무 큰 프로젝트는 소화하기 어려우니 아주 간단한 것부터 시작해보세요.

Claude Code나 Codex와 같은 에이전틱 코딩의 등장으로 비전공자도 손쉽게 앱을 만들어낼 수 있는 시대가 되었다. 기존 현업 프로그래머에게는 스스로를 증명해야 할 허들이 더욱 높아진 셈이다. 반면 그로 인한 기술 부채가 늘어나는 것 또한 자명하다. 간단한 취미용 앱은 몇 마디 문장만으로 뚝딱 만들어낼 수 있지만, 프로덕션에 올라갈 복잡한 프로젝트라면 이야기는 달라진다.

나는 기존에 경험해본 적 없는 도메인에서, 낯선 프레임워크와 언어로 새 프로젝트를 맡게 되었다. 잘 안되면 어쩌나 하는 걱정이 컸지만, 착수하기 전 어떻게 구조를 설계할지 충분히 준비했고, 아무런 파일 없이 시작한 지 3개월이 지난 지금은 안정적인 환경에서 개발 공정이 이루어지고 있다.

어떻게 가능했을까? 핵심은 이것이다. LLM은 입력에 대해 가장 그럴싸한 출력을 패턴 기반으로 찾아낸다. 따라서 LLM이 우리의 의도를 명확하게 이해할 수 있는 환경을 만들고, 이를 개발의 모든 프로세스에 녹여내야 한다. 지금 내가 이 방식을 어떻게 운용하고 있는지를 회고 겸 정리해본다.

아키텍처의 중요성

에이전틱 코딩을 하는 사람들에게서는 ‘마크다운이 곧 언어다’라는 표현이 널리 쓰인다. 예전에는 “talk is cheap, show me the code”가 덕목이었지만, 이제는 “code is cheap, show me the talk”이 주류가 되었다. 내가 모르는 언어라도 정확한 시나리오와 기술 스택, 데이터 흐름을 정의해두면 LLM은 구현해낼 수 있다.

LLM을 다루면서 가장 크게 느낀 것은 객관적인 지침이 매우 중요하다는 것이다. 예를 들어 테스트 코드를 작성할 때 네이밍 컨벤션이 적당한지는 그때그때 LLM의 기분에 따라 달라진다. 주관적인 개념을 항상 일관된 결과로 출력하는 것은 현 시점에선 불가능하다.

그래서 아키텍처 문서는 더욱 중요해진다. 프로젝트를 맡은 후 두 달 가까이를 아키텍처 문서의 완성도와 정합성을 끌어올리는 데에만 집중했다. 특히 모든 문서에서 일관된 용어를 사용하고 모호한 표현이 끼어들지 않도록 하는 것이 핵심이다. LLM이 최대한 객관적으로 판단하고 작성할 수 있게 하기 위해서다. 오랜 시간이 걸렸지만 지금 돌아보면 여기에 시간을 충분히 들인 것이 탁월한 선택이었다.

사실 이전에 MVP를 만들 때는 아키텍처 정의 없이 바이브 코딩으로 무작정 시작했다. 하지만 확장 단계에서 한계에 부딪혔다. 전체 구조를 뜯어고치는 과정에서, 쏟아지는 에러와 틀어진 정합성을 수습하는 것은 너무 어려운 일이었고, 차라리 새로 만드는 게 낫다는 결론에 이르렀다. 이런 실패를 경험하고 나서 코드를 작성하기 전에 충분한 기획이 필요하다는 것을 이해했다.^[1]

우선 아키텍처를 별도의 git repository로 만들고 지침을 먼저 세웠다. 마크다운 100%로 구성하고, 실제 구현과 코드 스니핏을 담지 않기로 했다. 여기에 초기 몇 가지 시나리오를 담았다. README.md와 기본 폴더 구조를 잡은 다음, 필요한 내용을 별도 문서로 만들어 하나씩 구현했다.

아키텍처 문서에는 각 구성 요소의 제약사항과 스펙, 데이터베이스 스키마, 에러 핸들링과 같은 정책, API나 컨벤션과 같은 프로토콜, 시나리오 등을 마크다운으로 정의한다. 주요 흐름은 mermaid diagram로 설계한다. 글보다 흐름을 명확히 표현할 수 있고 LLM이 쉽게 이해하며 사람이 직접 보기에도 편하기 때문이다.

이 문서들을 디테일하게 그리고 정합성 있게 만들고 나서 본격적으로 작업을 시작했다. 처음에는 문서를 과도하게 작성하는 것이 사전 컨텍스트를 커지기 해서 과도하게 토큰을 소모하는 것이 아닐까 걱정했다. 하지만 계층별로 폴더를 관리하고 각 폴더에 명확한 규칙을 주입하면 생각보다 토큰 소모가 크지 않았다. 또한 마크다운 내 링크를 통해 중복 내용을 최대한 정리하는 것도 중요했다.

리뷰의 중요성

아키텍처 문서든 코드든, 모든 커밋 전에 unstaged changes를 빡세게 리뷰한다. 실제 구현에 걸리는 시간이 1이라면, 리뷰하고 수정하는 데 걸리는 시간은 5~6이 된다. 그렇기에 vibe coding에 비해 각 과정을 진행하는데 훨씬 오래 걸린다.

주로 아래와 같은 것들을 커맨드로 만들어 리뷰한다:

1. 일관성 체크: 아직 커밋되지 않은 항목들에 대해 용어 일관성, 프로토콜 정합성, 시나리오 정합성, 정책 충돌, 모호한 표현을 전수 점검한다. 각 항목별로 서브에이전트를 만들어 결과를 취합해 보고받는다.
2. CONTRIBUTING 체크: CONTRIBUTING.md에는 LLM이 작업할 때 지켜야 할 작업 수칙을 정의해두었다. 예를 들어 근거없는 내용 금지, 중복 표현 금지, 구현 관심사 포함 금지와 같은 것들이 있는데. 이런 컨텍스트를 줘도 LLM이 말을 듣지 않는 경우가 잦기 때문에, 사후 검증을 통해 유효한 이슈가 없을 때까지 리뷰를 반복한다.
3. 이슈 필터링: 위 커맨드들이 보고한 이슈들을 다시 걸러내는 커맨드를 연이어 실행한다. 각 이슈에 대해 a) valid issue인지, false positive인지 판정, b) 우선순위를 P0/P1/P2로 분류하며 c) 판단 근거 d) valid issue인 경우 수정 방향을 제안하고 이 결과를 취합한다.
4. 코드 필터링: 코드에는 위와 유사한 별도의 커맨드를 만들어 추가로 아래 두 가지를 false positive로 판단한다:
   1. 확률×영향의 규모: 예를 들어 몇 년에 한 번 일어날 것이라 추정되는, 아주 예외적인 상황에서 그 영향이 미미하다고 판단할 수 있는 이슈는 false positive로 처리한다. 이를 처리함으로서 발생하는 오버헤드가 더 크기 때문이다.
   2. 의도적 설계: git blame/log로 이슈 코드의 이력을 확인하여, 단순화나 성능을 위해 의도적으로 허용한 케이스는 false positive로 처리한다. 보통 이러한 이슈는 계속해서 필터링에 걸러지는 경우가 많다.

아키텍처와 코드의 결합

지금은 코드 repository 내에 아키텍처를 submodule로 가져와 관리하고 있다. 다소 번거롭지만 이렇게 구성하면 몇 가지 장점이 있다:

• 아키텍처 문서를 별도로 관리할 수 있다. 리뷰 범위를 한정할 수 있고, 변경사항의 추적이 용이하다.
• 내가 맡은 프로젝트는 여러 클라이언트로 배포되는데, 각각의 프로젝트에 동일한 아키텍처 문서를 SSoT(Single Source of Truth)로 지정할 수 있다.
• 코드베이스가 마음에 들지 않으면 다 날려버릴수도 있다. 아키텍처가 남아있으니 언제든 다시 시작할 수 있고, 개선점을 보완하면 더 나은 출발이 가능하다.

물론 이러한 구조의 단점도 있다:

• submodule을 업데이트 할 때마다 참조하는 repository에서도 포인터를 업데이트 후 커밋해야 한다.
• 구현하다 보면 아키텍처에 정의되지 않았거나 모호한 케이스를 다뤄야 할 때가 있다. 이때는 우선 코드를 의도에 맞게 구현하고, 아키텍처에서 바꿔야 할 사항을 TODO로 넘긴다. 그리고 코드에는 ARCH-GAP 주석을 달아둔다. 아키텍처에서 TODO를 해결한 다음 코드의 ARCH-GAP과 비교하여 제대로 반영되었는지 파악한다.

이러한 작업을 반복함으로써 아키텍처와 코드의 갭을 줄여나가고 있다. 다소 번거롭지만 이렇게 아키텍처의 정합성과 정확도를 높여가는 것이 안정적인 개발에 많은 도움이 된다.

루틴 만들기

지금까지 정의한 작업 방식을 일관적이고 반복되게 사용하고 있다. 각 단계를 루틴화하면 다음과 같다:

1. 작업 선별: TODO에서 지금 해야 할 일을 고른다. 작업 단위는 Phase와 Slice로 나눈다. Phase는 Epic/Story에 대응하고, Slice는 Phase를 달성하기 위한 실행 단위다. 예를 들어 어떤 기능을 구현하기 위해 프로토콜 정의 → 서버 로직 작성 → 클라이언트 보완의 3개 Slice로 나눌 수 있다. Slice가 충분히 구체화되어 있지 않을 때는 LLM이 아키텍처 문서와 기존 코드베이스를 기반으로 Slice 분리 작업을 먼저 수행한다.
2. 계획 수립: 해당 Slice를 어떻게 완수할지의 계획을 작성한다.
3. 구현: TDD 기반의 Red → Green → Refactor 방식으로 코드를 작성한다.
4. 아키텍처 정합성 체크: 작성된 코드가 아키텍처와 일치하는지를 확인하고, 이슈가 있으면 수정 후 재확인을 반복한다.
5. 코드 리뷰: 여러 커맨드를 이용하여 엣지 케이스와 모호한 부분을 발견하고 valid issue인지 평가한다. 이슈가 있다면 수정 후 반복한다.
6. E2E 테스트: 필요한 경우 실제로 돌려보며 발생하는 이슈를 해결한다.
7. 1로 돌아가 다음 작업을 선별한다.

이 루틴을 반복하면서 일관적인 개발 페이스를 유지할 수 있게 되었다.

결국 판단은 사람이 한다

어떠한 이슈를 마주했을 때 고칠지 말지, 어떻게 고칠지는 사람이 판단한다. LLM도 실수하고 잘못된 판단을 할 수 있기 때문이다. 그래서 나는 또한 --dangerously-skip-permissions 같은 파라미터를 쓰지 않는다. 보수적일 수 있지만, 아키텍처든 코드든 모든 커밋은 최종적으로 내가 직접 리뷰하며 궁금한 것과 해결되지 않은 것은 짚고 넘어간다.

그래야만 나중에 실제로 문제가 터졌을 때 원인을 빠르게 파악하고 LLM에 적절한 지침을 내릴 수 있기 때문이다. 나는 내가 통제할 수 없는 일이 프로젝트에서 일어나는 것을 원하지 않는다. 그렇게 되지 않도록 관리하는 것이 LLM을 사용하는 나의 책임이다.

LLM과 함께 문제를 정의하고 해결하는 과정에서 CS 전공 지식을 갖추는 것은 불필요한 시행착오로부터 우리를 구원한다는 것을 경험했다. 그렇기에 아무리 에이전틱 코딩이 발전한다 해도, 경험과 직관을 가지고 있는 리뷰어가 없이는 성공적인 프로젝트가 완성될 수 없다는 확신을 갖게 되었다.

[1] 물론 이 방식은 일종의 워터폴 구조라 프로젝트의 성격에 따라 맞지 않을 수 있다. 명확한 목표가 있어서 가능한 방식이었다. 처음부터 모든 걸 정하지 않더라도 아키텍처를 점진적으로 확장하면서 개발하는 방식도 충분히 가능할 것이라고 생각된다.

잘한 일과 결정들

• 가능성이 없는 것에 집착하지 않고 미련 없이 빠르게 내려놓은 점
• 쉬는 동안 가족과 주변 사람들에게 더 자주 더 깊이 시간을 쓴 점
• 삶의 안정을 되찾고 다시 일에 집중할 수 있는 기회를 얻은 점
• 조깅을 시작한 점 (안색이 좋아졌다는 말을 자주 들었다)
• 디딤씨앗통장 정기후원을 시작한 점

아쉬운 일과 결정들

• 휴식에 집중한 나머지 자기개발에 충분히 시간을 쓰지 못한 점
• 결정을 미루다가 더 비싼 값을 치르게 된 점

올해의 글

• 4개월간의 게임 개발 회고

올해의 사진

올해의 책

• 지적 행복론, 리처드 이스털린 지음

올해의 음악

• BIRDS OF A FEATHER - Billie Eilish

올해의 영화

올해의 애니메이션

• 에반게리온 TV판

어릴 때는 관심에 목말랐다. 그 갈급함이 깊은 몰입을 가능하게 했다. 나이가 드니 어느새 그런 욕망이 무의미하다는 걸 깨달아버렸다. 지금은 가정과 마음의 평화를 지켜야 한다는 책임감이 나를 움직이고 있다.

나는 남들과 달리 특별한 열망이 있다고 믿어왔다. 그런데 이제는 딱히 다를 것도 없어졌다. 강한 비전을 품고 스스로 동기를 부여하며 앞으로 나아가는 사람들을 보면 경이로움이 느껴진다. 나도 평범해진 걸까, 아니면 아직 새로운 내면의 동기를 찾지 못한 걸까.

올해는 그런 동기를 끝내 찾지 못했다. 찾아보려 했지만 좋은 결과를 얻지 못했다. 내년에는 나를 휘몰아칠 수 있는 새로운 계기를 만나보고 싶다.

인생의 큰 결정을 앞두고 어떻게 하면 덜 후회할 수 있을지 고민하고 있다. 그런데 사실, 어떤 결정을 내려도 나는 결국 후회할 것이다. 그렇다면 질문을 바꿔야 한다. 어떤 후회를 감수할 수 있는가.

우리는 모두 무덤에 들어가기 전에 후회라는 감정을 마주할 것이다. 어떤 후회가 그나마 덜 마음 아플지를 생각해보는 수밖에 없다. 후회가 꼭 나쁜 감정만은 아니다. 후회를 통해 지난 선택을 돌아보고, 앞으로 더 나은 삶을 살아가는 교훈을 얻을 수 있다.

수많은 후회를 해왔고, 앞으로도 그럴 것이다. 후회라는 감정을 잘 받아들이고 다스리는 법을 익혀야겠다는 생각을 한다.

올해 4월, 한동안 개발해 왔던 웹 게임 서비스를 종료했다. 그리고 이번 주, 게임제작업 허가증을 반납하기 위해 구청에 다녀왔다. 관련 문서를 정리하다 보니, 그동안 등록부터 심의까지 겪었던 과정이 정리되어 있었고, 그냥 버리기엔 아깝고 누군가에게 분명히 도움이 될 수 있겠다는 생각이 들어 공유한다.

1인 인디 웹 게임을 개발하려는 사람들을 위해서 실제로 사업자를 등록하고 심의까지 받기 위해 어떤 과정을 거쳤는지 차근차근 정리해 보았다. 아래 내용은 본인이 진행했던 당시 기준으로, 현재 상황과 다를 수 있으니 실제 진행 전 반드시 최신 정보를 다시 확인하길 권한다.

1단계: 사업자등록 및 비상주사무실 등록

개인사업자 등록을 위해 가장 먼저 필요한 것은 사업자 주소다. 실제 업무 공간이 아니라 주소지만 임대하는 비상주사무실 서비스를 이용하면 좋다. 1년 단위로 임대하고 우편 수신 및 한정된 시간의 회의실 사용을 제공해주는 곳을 골랐다. 

사무실을 선택할 때 한 가지 더 체크할 점은 과밀억제권역 여부다. 과밀억제권역 이외의 지역에서 창업하는 경우 법인세와 소득세가 감면되는 혜택이 있기 때문이다. 다만 실 거주지와 주소지가 지나치게 다를 경우 세무조사 등의 리스크가 있어, 가까운 곳에 사무실을 두기로 했다. 대략 1년에 20만원 내외의 비용으로 사무실을 구할 수 있다.

비상주사무실 계약 후에는 사업자 등록을 하면 된다. 게임 개발의 경우 간이과세자가 불가능하므로 일반과세자로 등록하여야 한다. 청년창업 감면 혜택도 받을 수 있는지 함께 검토해 보면 좋다. 참고1 참고2 참고3

사업자등록은 홈택스로 진행할 수 있고, 사업자 등록 시 업종은 아래와 같이 추가하였다.

• 주업종: 722001 - 온라인게임소프트웨어개발및공급업
• 부업종: 525101 - 전자상거래소매업, 722005 - 컴퓨터 프로그래밍 서비스업

창업기업 확인시스템에 등록할 수도 있는데, 이는 공공 조달을 위해 필요한 것으로 굳이 등록할 필요는 없다. 참고1 참고2

또한, 다양한 창업지원사업이 진행중이므로 사업자 등록을 할 때 요건을 잘 맞추면 사업 초기에 많은 도움을 받을 수 있다.

2단계: 사업자 명의 통장 개설

개인사업자는 카카오뱅크에서 간단히 개설할 수 있다. 개인사업자용 체크카드까지 함께 발급해 두면 추후 비용 처리할 때 편리하다. 참고

3단계: 통신판매업, 게임제작업 신고

온라인 결제를 받기 위해 구청에서 통신판매업 신고를 해야 한다. 이 때 구매안전서비스 비적용 대상 확인서를 발급받아 신고 시 같이 제출한다. 디지털 상품은 에스크로 적용 대상이 아니기 때문이다.

게임제작업과 통신판매업은 매년 1월에 등록면허세가 발생한다. 비용은 서울 기준 약 4만원 정도. 통신판매업의 경우 거래횟수가 연간 50회 미만이거나 간이과세자면 면제를 받을 수 있다. 4분기에 제작업을 등록하면 그 다음해에 또 면허세를 내야하니 불리하다.

4단계: 게임 심의받기

게임 심의를 할 수 있는 기관은 게임콘텐츠등급분류위원회(GCRB)와 게임물관리위원회(GRAC)가 있다. 원래는 GRAC에서 모든 심의를 담당하다가, 2014년에 청소년 이용불가 게임 및 아케이드 게임은 GRAC에서, 그 외의 게임물은 GCRB로 민간 이양되었다. 그래서 GCRB에 신청을 하기로 했다.

우선, 중소기업의 경우 50% 심의비용을 감면받을 수 있는 제도가 있으므로, 이 서류를 심의 신청하기 전에 먼저 홈페이지에서 제출하고 승인을 받는다. 심의를 신청하고 감면 서류를 제출하면 적용이 안 되니 주의. 참고로 홈페이지는 공인인증서로 로그인이 필요하므로, 별도의 프로그램 설치 없이는 사이트를 이용할 수 없다. 식탁보를 사용하여 가상 환경에서 심의를 신청하였다.

웹게임의 경우 오픈마켓이냐, 아니면 PC 온라인게임이냐에 따라 심의비가 대략 10배 차이가 난다. 처음 GCRB에서는 원론적으로 PC에서 이용할 수 있는 게임이라면 PC 온라인게임으로 진행해야 한다고 안내받았다. 이 경우 PC 온라인게임, 네트워크, 1군, 한글 기준 50% 감면받아 심의비용은 118만원.

게임 용량은 클라이언트 빌드 용량을 기준으로 한다. 따라서 next build로 만들어진 빌드를 압축하여 해당 용량으로 계산하였다.

필요한 서류는 아래와 같다.

1. 이용가능계정 준비: 초보자 / 중급자 / 상급자 기준에 따라 더미 캐릭터를 만들고, 해당 캐릭터의 접속에 필요한 아이디와 비밀번호를 기입한다. 해당 계정으로 담당자가 로그인을 상시 진행할 수 있어야 한다. 사후심의에도 활용되기 때문에 심의가 끝나도 계정은 남아있어야 한다.
2. 게임물내용설명서: 게임의 주요 줄거리(시나리오) 요약, 주요 캐릭터, 주요 아이템 등에 대한 설명(아이템 리스트 및 아이템 조합시스템 포함), 게임조작방법, 전투장면 등 주요 게임진행장면의 설명 및 스크린샷, 대사집(스크립트 파일), 단축키(Hotkey), 점수획득방법에 관한 내용 등이 상세하게 포함되어야 한다. 이 내용들은 홈페이지를 통해 공개될 수 있다고 하나, 사실상 아케이드 게임물에 대해서만 공개되는걸로 보인다. 또한 비공게 게임물 내용설명서를 통해서 민감한 사항은 별도로 전달할 수도 있다.
3. 실행 가능한 게임물: 관련 프로그램 빌드 파일을 첨부하면 되는데, 웹게임이라 그냥 빌드 압축해서 넣었다. 실제 접속은 웹으로 하였다.
4. 게임물의 주요 진행과정을 촬영한 동영상: 30분 내외의 분량으로 게임의 주요 내용을 스크린 캡쳐하여 보냈다. 특히 폭력적 표현, 이용자간 대결 등 심의에 영향을 줄 수 있는 부분이 포함되어야 한다. 포함하지 않으면 보완요청이 온다.
5. 게임물제작업등록증 또는 게임물배급업등록증
6. 심의 수수료 무통장 입금증 사본: 신용카드로도 결제 가능하다.
7. 초상권 및 라이선스 관련 서류

작성은 초안 상태로 유지할 수 있으니 틈틈히 저장해두면 좋다. 

5단계: 게임 심의 보완요청 대응

여튼 처음에는 청소년 이용불가 게임물이라는 생각은 전혀 하지 않고 GCRB를 통해서 심의를 넣었는데, 담당자로부터 사전 연락을 받았다. 게임 내 거래소 시스템을 문제 삼고 넘어진 것이다. 유료 재화로 이용할 수 있는 거래소는 청소년이용불가 요소에 해당되니 GCRB가 아닌 GRAC에 심의를 받는것이 더 좋을 것 같다는 것이었다. 프로세스를 계속 진행할 수 있지만, 아마도 심의가 거부될 것이고 그러면 심의 비용을 돌려받지 못할 것이라는 조언을 들었다.

담당자는 우리 게임 내의 시스템이 리니지M 같이 다이아로 거래소를 이용할 수 있는 시스템과 유사한 것으로 판단한 듯 하다. 게임의 기획은 게임 내 획득할 수 있는 골드를 이용하여 사용자들이 유료로 결제할 수 있는 아이템을 구매할 수 있다는 것이었는데, 조금이라도 거래 시스템에 유료 재화가 연관될 가능성이 있으니 청불이 맞다는 논리다. 우리 게임은 유료 재화가 아닌 유료 아이템의 거래였고, 이게 유료 재화(다이아)와 같은 것인지? 상당히 융퉁성이 없다고 느꼈다.

다만 실제 심의에 들어가기 전에는 심의비용을 100% 환불받을 수 있어서, 이 점을 미리 알려주신 것은 고마웠다. GCRB의 심의를 취소한 다음 다시 GRAC에 심의를 넣었고, 거래소 시스템이 없으면 간소화 제도를 통하여 자체심의도 가능했지만 결국 일반 심의를 받게 되었다.

그런데 아무리 생각해도 심의 비용이 너무 비싼것 같아서, GRAC에서 심의할 때는 웹 뿐만 아니라 모바일에서도 접근할 수 있는 점을 어필하였다. 결국 오픈마켓(기타)로 심의를 진행하였고, PC게임 대비 약 10% 정도의 가격에 심의를 받을 수 있었다.

일반 심의 제도를 간략히 설명하자면 게임사에서 심의요청 서류와 함께 영상을 제출하면, 매주(또는 격주)마다 게임심의위원회가 열리고, 높으신 분들 여럿이 앉아 그동안 들어온 신청 내역을 쭉 돌려보면서 다과와 함께 2시간 정도 심의하는 시간을 가진다고 한다. 이 분들의 심의 포맷은 사실상 정형화되어 있고(연구원이 게임 개요 설명→등급에 영향가는 요소 확인→등급 논의→등급결정), 여기에 최대한 짜맞추기 위해 담당 심사관과 게임사가 실무적으로 소통하게 되는데, 심의 과정에서 최대한 ‘기존 심의가 이루어진 레퍼런스’에 우리 게임의 시스템을 최대한 어거지로 가져다 맞추려는 인상을 많이 받았다.

그들에게 있어 웹게임은 10년 전 한창 유행하였던 중국 등지에서 개발된 방치형 게임들을 의미하는 것이었고, 다이아, 보화 등의 재화를 이용하는 뭐 그런 수준이었다. 웹게임의 기획과 컨셉이 그런 게임들과는 완전히 달랐지만, 심의를 최대한 앞당겨서 편하게 받기 위해서는 기존 게임들과 비슷하게 갈 수 밖에 없었다. 심의 요청을 넣고, 보완요청을 받아 대응하고 하는 과정들이 굉장히 지지부진하였고, 언제 통과가 될 지 모르는 연옥에 빠진 것 같은 느낌이라 최대한 빠르게 여기에서 탈출하고 싶었다.

특히 웹게임의 경우 NFT 등의 사태로 꽤 홍역을 치룬 모양이었다. 그래서 ‘환금성’이 있는지 등에 대해 굉장히 민감하게 대응하는 것을 관찰할 수 있었다. 마지막까지 보완요청으로 나를 괴롭혔는데, 만약 이 게임에서 그런 요소가 생기면 내가 민형사적 책임을 모두 지겠다는 일종의 각서(?)까지 작성하고 나서야 심의를 받을 수 있었다. 물론 청소년이용불가로 판정을 받았다.

6단계: 결제대행 및 본인인증 서비스 신청

게임을 유지하기 위해서는 최소한의 수익이 필요하다. 사용자에게 결제를 받기 위해서 결제대행 서비스가 필요하고, 또한 청소년이용불가 게임물이 되면 본인인증도 받아야 한다. 우선 본인인증의 경우 대부분 다날 휴대폰 인증을 도입하는데, 비용이 제법 든다. 토스에서도 본인인증 서비스를 제공한다. 본인의 경우 포트원을 이용하여 결제대행 서비스를 도입하였고, 사용료는 처음에 선납으로 일부 입금 후, 결제 건당 차감되는 방식으로, 선납한 비용을 모두 소진하게 되면 다시 충전해서 사용하면 된다.

결제대행은 페이플을 사용하였다. 김대표님과 이전부터 오랜 기간동안 거래하였고, 다소 투박한 감이 있지만 같은 스타트업으로서 굉장히 초기 기업의 편의를 많이 봐주시고 이해해주시는 곳이다. 페이플을 이용하여 단건 결제 뿐 아니라 정기결제도 이용할 수 있다. 기본적으로 결제대행을 받기 위해서는 하단에 사업자 정보 표시, 결제 플로우에 대한 설명 자료가 필요하고, 데모로 담당자가 직접 결제할 수 있는 환경을 갖춰야 한다. 특정 아이디에만 결제 UI를 띄우는 방식으로 사전 심사에 대응할 수 있다.

7단계: 게임물 수정신고

원칙적으로 게임을 패치할때마다 GRAC에 수정신고를 해야 한다. 어떤 내용이 바뀌었는지, 변경된 내용 중 다시 재심의를 받아야 할 부분이 있는지 등을 검토하는 단계이다. 물론 수정신고 전에 담당자와 실무 통화를 통해 이러한 내용이 문제가 될 소지가 있는지를 상담받을수도 있다. 어쨌거나 빠른 패치가 필요한 상황에서 수정신고는 1인 개발자에게는 꽤 부담이었다. 사전에 게임물 수정신고를 받고, 문제가 없으면 패치를 진행하는 것이 원칙인데, 사후 신고도 릴리즈 후 24시간 이내에는 가능하다고 한다.

마치며

1인 개발자가 게임 서비스를 정식으로 런칭하는 과정은 생각보다 복잡하고 오랜 시간이 걸린다. 특히 게임 심의 과정은 예상치 못한 변수가 많으니, 이 점을 감안하여 일정을 계획하는 것이 중요하다. 가장 좋은 방법은 청불/아케이드가 아닌 게임을 만들어 구글 플레이나 앱스토어와 같은 자체등급분류사업자의 심의를 받는 것이다. 그러면 이런 복잡한 과정을 겪을 필요가 없다.

이 글이 같은 길을 걷는 분들께 조금이나마 도움이 되길 바란다.

여기서 일컫는 ‘성장부채’란, 직원의 성장을 위해 회사가 선제적으로 부담한 비용·시간·복잡성이, 회사의 성장을 저해하거나 위험을 증가시키는 상황을 말한다. 직원의 성장이라는 ‘미래 가치’가 실현되지 않으면, 그 부담은 온전히 회사의 부채로 남게 된다.

2020년 초, 스타트업에 유동성이 넘치고 개발자 시장이 과열되던 시기, 많은 창업자들이 공통적으로 빠졌던 함정이 있었다. 바로 ‘개발자의 성장’이라는 명분이다.

많은 회사들이 우수한 개발자들을 채용하기 위해 높은 연봉과 스톡옵션은 물론, ‘성장할 수 있는 환경’을 제공하기 위해 과도한 투자를 해왔다. 조직과 구성원이 함께 성장한다면 이상적이지만, 실제로는 직원만 성장하고 회사는 성장하지 못한 채 비용만 떠안고 결국 무너진 사례가 적지 않았다.

단일 베어메탈 서버로도 충분한 서비스임에도 굳이 복잡한 클라우드 인프라와 쿠버네티스, 마이크로서비스, GraphQL 등을 도입하거나, 실무적으로 필요 없는 기술을 이력서 한 줄을 위해 적용하는 일이 흔했다. 이렇게 늘어난 인프라의 복잡성은 퇴사 후 유지보수 부담으로 이어져, 회사 입장에서는 투자 대비 효과가 미미할 수밖에 없었다.

회사는 자본을 투입해 이익을 창출하고 이를 주주에게 분배하기 위해 존재한다. 그러나 많은 조직은 ‘좋은 개발자’를 판단하는 기준 자체가 어긋나있었다. 다양한 언어와 프레임워크 경험, 미세한 성능 개선, 그리고 기술적 완성도만을 강조하기보다, 자신의 기여가 실제로 회사의 매출을 증대시키고 비용을 절감하는 데 어떤 영향을 미쳤는가를 중심에 두었어야 했다.

그동안 수많은 경영진이 직원 성장이라는 명분 아래 과도한 시간과 비용을 투입했으나, 그에 상응하는 성과는 돌아오지 않았다. 값비싼 교훈이었다. 지금은 다행히도 AI 코딩 어시스턴트의 발전으로 인력 효율은 개선되었지만, 오버엔지니어링을 비롯하여 인프라에 과잉 투자하는 비효율이 여전히 곳곳에 남아 있다.

반대로, 지금 새롭게 시작하는 조직들은 인력 구성과 인프라 모두 ‘제로 베이스’에서 설계할 수 있다는 점에서 매우 유리하다. 단순하고 최소한의 기술 스택으로 시작하여, 실제 유저가 원하는 가치를 더 빠르게 검증한 뒤에만 확장하면 된다. 가장 중요한 점은, MVP를 지나 사업이 본궤도에 오른 후에도 기술적 결정의 근거에는 ‘지금 정말 필요한지’를 기준삼아야 한다는 것이다.

돌이켜보면, 회사를 무너뜨리는 것은 기술부채보다 성장부채인 경우가 훨씬 많았다. 기술은 시간이 지나면 자연스럽게 낡고 부채가 쌓이지만, 그것만으로 회사가 쉽게 망하지는 않는다. 반면 성장부채는 비용을 증가시키고 속도를 느리게 만들며, 회사의 에너지에 돌이킬 수 없는 피해를 입힌다.

Hacker News 읽다가 생각해 볼 점이 많아서 가져온 글.

슬랙이 비영리 단체에 과도한 요금을 청구하였고, CEO가 이를 실수라고 사과하며 요금 청구를 취소하였다. 상황이 수습된 이후에도 회사에 쏟아지는 비난에, 운영자는 아래와 같이 댓글을 달았다.

https://news.ycombinator.com/item?id=45293388

As long as I'm going on about this I want to repeat what I said in the cousin comment (https://news.ycombinator.com/item?id=45293388): the distinctive quality of internet indignation is unprocessed, opportunistic rage: unprocessed because it is pre-existing in a person (<-- and we all have this) for whatever original reasons that haven't been metabolized yet; opportunistic because it waits for justifiable occasions to lash out, and then lashes out with vengeance. This is not a great way to handle one's rage—it's a recipe for repetition instead of growth. How do I know that? I know it by self-observation, and I believe that anyone who wants to can know it by self-observation.

It's particularly important to know this in a group context. When a group joins together to vent rage—because an occasion justifies it, even though the driver in each person may be very different—that's when a group turns into a mob. This happens easily because it happens without awareness and no one intends it. This is when we become our ugliest, so we should pay attention to signs of it in ourselves and in our groups, and learn to respond differently. Not easy, of course, but a good use to put an internet forum to!

1. 인터넷에서 일어나는 분노의 특징은 가공되지 않은 기회주의적이라는 것이다.
2. 분노는 우리 내부에 이미 존재하며, 정당화될 상황이 오면 복수심에 불타며 분출된다.
3. 이는 분노를 다루는 좋은 방법이 아니다. 성장이 아닌 반복을 초래하는 방식이다.
4. 특히 집단적 맥락에서 이를 인지하는 것이 중요하다.
5. 집단이 분노를 표출하기 위해 모일 때 - 각자의 동기는 다를 수 있지만 계기가 정당화하기 때문에 - 그들은 폭도로 변한다.
6. 이는 어떠한 인식 없이, 누구도 의도하지 않은 채 쉽게 발생한다.
7. 이때 우리의 가장 추악한 모습이 드러나므로, 자신과 집단 내에서 이런 징후를 주의 깊게 살피고 다른 방식으로 대응하는 법을 배워야 한다.

즉, 단 하나의 기사나 트윗이 수천 명의 억눌린 좌절감을 배출하는 밸브 역할을 할 수 있다는 것이다.

인터넷이 끝없는 ‘기회’(새로운 논란)를 제공하기 때문에 이 순환은 스스로 지속되며, 사람들은 화낼 대상을 기다리기 시작한다. 분노가 과시적 행위가 될 때, 사람들은 종종 주목이나 소속감을 위해 분노를 과장한다. 외부인은 '적'이 되고, 내부인은 순수함으로 보상받으며, 반대 의견은 처벌받는다.

이 지점에서 공동체는 르네 지라르가 희생양 메커니즘이라 부른 상태로 빠져들 수 있다. 질서를 회복하기 위해 희생할 대상을 찾는 것이다. 군중에 합류하여 분노를 표현하기 전에, 우리 스스로 이 감정이 실제보다 과도한 것인지 인식할 필요가 있다.

내 주변의 사례들만 모아봐서 확증편향일 수도 있지만, CS 전공이신 분들이 성공했던 방법들을 관찰하면 이렇다:

• 대학 다닐 때 모의 시간표 서비스를 만들었었다(에브리타임 같은 서비스다). 10년 전에 대학마다 비슷한 서비스들을 만들었던 분들을 따라가 보면 대부분 잘 되어 있다.
• PS를 꾸준히 그리고 잘하시는 분들은 대부분 좋은 회사에 다니고 있다. 당시에 우리 대학에는 그런 동아리가 없어져서 내가 직접 만들어 함께 공부했었는데, 나는 비록 리저널 참가상에 그쳤지만, 월파에 나가셨거나 리저널에서 상위권에 입상하신 분들은 무수히 많은 회사에서 스카우트를 받기도 하고, 스타트업을 만들어 수천억 규모의 가치를 인정받고 있다.
• 음지의 영역이지만, 게임 핵 제작이나 프리서버를 만들고, 리버스 엔지니어링을 깊게 파신 분들도 톱이 되어 있다. 이제는 법적으로 금지되어 있지만, 다른 영역으로 넘어가서 역시나 승승장구하고 있다.

기본적으로 컴퓨터를 좋아해야 하고 이걸로 할 수 있는 익숙하고 인접한 분야들을 꼽자면 웹 개발, PS, 그리고 게임 관련된 영역인 것 같다. 여기서 찍먹해 보고 끝내는 게 아니고, 정말 더 깊게 파서 뭐라도 결과를 만들어 낸 분들이 10년 지나고 보니 대부분 잘 되어 있었다.

이런 사례들에서 공통으로 관찰할 수 있는 점은 성공을 위해서는 인정욕구와 집요함이 필요하다는 것이다. 우리가 모두 태어나면서 서로 비슷한 에너지의 총량을 가지고 있다고 치면, 이걸 어떻게 배분할 것인가의 문제이다. 어떤 문제를 포기하지 않고 집요하게 마주하는 경험을 바탕으로, 사람들에게 서비스를 제공하고 인정받는 피드백 루프를 통해서 지속적으로 선순환되고 강화하는 경험을 하다 보면 굉장한 몰입과 자극을 얻을 수 있다.

특히 소프트웨어는 다른 산업과 달리 유통하는 데 별다른 라이선스가 필요하지 않으므로, 진입 장벽이 굉장히 낮은 편이다. 나는 최대한 어린 나이에 하루라도 빨리 본인만의 소프트웨어를 만들어서 - 플랫폼이 무엇이든 간에 - 고객의 피드백을 듣고 강화하는 경험을 해 보기를 강력히 권장한다. 결과적으로 자신의 내공이 깊게 만들어지는 것을 발견할 수 있을 것이다.

우물 밖으로 나와보니 느끼는 건, 생각보다 남이 시키는 대로 살아가는 사람들이 많다는 것이다. 교수님의 커리큘럼에 맞춰 공부만 하다 보면 스스로 뛰어난 결과를 만들어낼 가능성은 매우 낮다. 조금이라도 일찍, 남들과는 달리 생각하고 스스로 가치를 만들어낼 수 있는 역량을 갖추는 것이 매우 중요하다고 생각한다. 시대의 변화와 상관없이.

사업을 구상할 때, 의외로 많은 창업자들이 비즈니스의 구조적인 한계를 고려하지 않는다는 점을 알게 되었다. 지속 가능한 비즈니스를 만들어내기 위해서는 처음부터 이 한계를 분명하게 인식하고 적절한 보완책을 마련하는 것이 매우 중요하다. 그러기 위해서는 사업의 본질을 명확히 정의할 필요가 있다.

사업의 본질

회사가 존속하기 위해서는 수익이 필요하다. 다시 말해서, 무엇을 만드는지, 운영하는지보다 어떻게 수익을 창출하는지가 사업의 본질을 정의한다.

생각보다 많은 창업자들은 ‘무엇을 만드는 것’에 초점이 맞춰져 있다. 아무리 창의적이고 기발한 아이디어를 생각한다고 하더라도, 수익으로 전환될 수 없다면 이는 비즈니스라 할 수 없다. 구체적인 수익 창출 계획이 구상되어야만 진정한 의미의 사업이라고 할 수 있다.

예를 들어 온라인 커뮤니티 서비스를 생각해 보자. 이 사업의 주요 매출원이 광고라면, 이 비즈니스의 본질은 광고 매체이다. 이때 중요한 것은 커뮤니티가 얼마나 양질의 타겟 고객을 보유하고 있는지, 그리고 얼마나 많은 트래픽과 유효 클릭이 발생하는지이다.

커뮤니티에 붙는 다른 부차적인 기능들은 이 핵심 모델을 강화하지 못한다면 그다지 중요하지 않다. 많은 창업자는 이 부차적인 기능들이 다른 서비스와의 차별화를 제공하고 비즈니스에 도움이 될 것이라 오해하는 경우가 많다.

구조적인 한계

사업의 본질을 정확히 파악했다면, 그다음으로는 이 비즈니스가 ‘지속 가능한’ 상태로 나아갈 수 있는지를 검토해야 한다. 검토하는 과정에서 많은 사업이 직면하는 구조적인 한계가 드러나는데, 대표적인 예시를 들자면 다음과 같다.

공급 의존성 문제

많은 비즈니스는 특정 서비스나 거래처에 지나치게 의존한다. 이렇게 외부 요소에 의존하는 비즈니스는 그들의 정책 변화에 취약해질 수밖에 없다.

• 퍼스트 파티가 서드파티의 기능을 흡수하여 서드파티가 더 이상 필요하지 않게 되는 경우
• 알고리즘의 변경으로 노출 빈도가 줄어들게 되어 트래픽의 감소 등, 큰 타격을 입게 되는 경우
• 앱스토어 정책 변경으로 인앱 결제 수수료가 상승하여 이익이 감소하는 경우

유닛 이코노믹스 문제

단위당 비용이 수익보다 큰 구조는 장기적으로 지속할 수 없는 비즈니스가 된다.

• 고객 획득 비용이 평생 가치를 초과하는 경우: 많은 창업자는 플랫폼이 성장하면서 고객 획득 비용을 통제하고 평생 가치를 더 늘릴 수 있다고 주장하지만, 극소수의 스타트업만이 이를 해결하는 것을 볼 수 있다.
• 가격 협상력이 없는 상황에서 서비스를 제공하기 위한 원가를 통제할 수 없는 경우: 예를 들어 클라우드/서버 비용은 어느 정도 다양한 대안이 있고 마이그레이션이 수월한 편이지만, 사용 중인 AI 모델의 비용은 아직 품질의 격차가 상당한 부분이 있어 통제하기가 어렵다.

기존 이해관계자와의 충돌

진출하려는 산업 내 기존 카르텔이나 강력한 이해관계자가 있는 경우에는 이를 뚫고 성장하는 것이 매우 어렵거나 불가능하다. 택시 산업, 금융권 규제, 의료 서비스뿐만 아니라, 우리가 인지하지 못하는 여러 가지 크고 작은 산업에서 이러한 충돌은 필연적이다.

가치 인식 문제

이는 특히 중개 플랫폼에서 흔히 발생하는 문제이다. 소비자는 공급자와의 연결만을 가치로 인식하여, 플랫폼이 제공하는 서비스의 가치가 없다고 생각하게 되는 경우가 많다.

대부분의 플랫폼 비즈니스는 단순하게 양쪽을 찾아주고, 거래를 보증해 주는 역할만을 제공하는 것으로 서비스를 시작하게 된다. 이후 서비스의 규모가 늘어나거나 고도화를 진행하는 과정에서 서비스를 제공하는 비용이 늘어나고, 비용 증가를 상쇄하기 위해 추가적인 수익 모델이 개발된다.

그러나 사용자들이 처음 인식한 가치와 큰 차이를 느끼지 못했음에도 불구하고(사용자별로 이 차이를 인식하는 수준이 다르다는 문제도 있음), 본질적인 가치에 지불해야 하는 비용이 증가했다고 인식한다면, 결국 플랫폼에 대한 부정적인 이미지가 생기게 된다.

그래서 대부분의 플랫폼은 수수료 또는 추가 수익모델을 개발하기보다 GMV(거래 규모)를 늘리는 방식의 간접적인 접근을 시도하는데, 이를 위해 무리한 프로모션이나 마케팅을 집행하다 보면 큰 적자를 보게 되는 결과를 맞이하게 된다.

극복하기 위한 전략

구조적인 한계를 발견했다고 해서 구상한 사업을 진행할 이유가 사라지는 것은 아니다. 모든 비즈니스는 어떠한 형태로든 구조적인 한계를 가지고 있다. 특히 요즘같이 초연결된 사회에서는 이러한 한계가 더욱 부각되고 있다. 중요한 것은 이 한계를 인식하고 대응할 방법을 마련하는 것이다. 그럼에도 마땅한 대책이 보이지 않는다면, 그때는 다른 기회를 모색해 보아야 할 수도 있다.

구조적인 한계를 극복하기 위한 전략으로는 여러 방법이 존재한다.

• 공급망 다변화: 단일 공급원이나 채널, 서비스에 의존하지 않고 다양한 옵션을 확보하는 노력을 게을리하지 않는다.
• 수익 모델 다각화: 하나의 수익원에만 의존하지 않고 여러 수익 모델을 개발해야 한다. 중요한 것은 구조적인 문제가 발생한다고 판단하였다면 사용자들이 제공받는 가치에 대한 인식이 굳어지기 전에 수익 모델 다각화를 빠르게 시작하는 것이 좋으며, 이를 개선할 기회를 더 많이 확보할 수 있다.
• 탈출 플랜 수립: 사업이 예상대로 진행되지 않을 경우를 대비하여 대표 개인과 회사에 발생할 수 있는 법률적, 재무적인 리스크에 대한 대비 계획을 미리 세워두는 것을 권장한다. 특히 실패에 대한 관용이 낮은 환경일수록 이러한 계획을 수립하는 것은 더욱 필요하다.

마지막으로 나의 경험을 공유하고자 한다. 나는 회사를 운영하면서 많은 금액의 투자를 받았지만, 이 자금을 공격적으로 사용하지 않고 신중하게 관리하기 위해 노력했다. 내가 영위하는 비즈니스 구조상 인지하지 못한 어떤 문제가 발생하였을 때 이를 해결하기 위한 준비금이 필요했기 때문이다.

당시 회사가 잘 되었을 때 다른 회사를 인수하거나, 대규모 인력 채용, 시설 투자에 대한 욕심이 생길 때가 있었다. 하지만 항상 비관적인 경우를 생각하며 신중하게 결정하려고 노력했다. 그리고 내가 생각했던 최악의 경우보다 더욱 최악의 일은 항상 일어났고, 어쩔 수 없이 회사를 정리하게 되었지만, 그런대로 안전하게 사업을 정리할 수 있었다.

그렇게 보수적이고 비관적으로 바라봤음에도 내가 예상하지 못한 비용은 항상 발생했다. 하다못해 사무실을 정리하고 수억을 들여 만든 인테리어를 정리하는 데도 큰 비용이 필요했다. 이 경험은 다음 사업을 할 때 반드시 내가 감당할 수 있는 규모 안에서만 운영해야겠다는 중요한 교훈이 되었다.

나도 여기에 기여하지 않았다고 말할 수 없어 조심스럽지만, 이전에 비해 인터넷이 너무나 유독해졌음을 느낀다.

내가 처음 인터넷을 접했을 때는 이 공간이 생경했고, 모두가 화면 너머에 실제 사람이 있음을 인지하던 시절이었다. 그리고 적어도 자정작용이 있었다. 규범이 있었고 최소한의 예의와 존중 위에서 커뮤니티가 형성되었다.

이런 분위기에 균열이 생긴 첫 번째 요인은 익명 커뮤니티의 활성화다. 익명 커뮤니티가 '솔직함'을 무기로 하고 의견 개진에 부담을 줄인 점이 매력이 되어 급속히 성장했다. 그리고 페이지랭크를 등에 업고 구글 등의 검색엔진을 통한 SEO로 커뮤니티에는 더욱 큰 가치가 생겨 지금도 한국 인터넷 문화의 한 축을 담당하고 있다.

다음 요인은 파편화와 알고리즘이다. 이전에는 다 같이 모인 공간에서 조금은 불편하더라도 사회적 합의에 의해 정해진 룰 위에서 자정작용이 이루어졌다. 심지어 기술이 낙후되어 차단 기능 자체도 없었다. 좋든 싫든 글을 봐야 했고, 운영자가 제재하는 수준이었다.

하지만 이제는 차단 기능이 없는 커뮤니티를 찾기 힘들다. 모두가 본인이 듣고 싶은 글만 보고 챔버 효과로 그들의 목소리는 강화된다. 많은 시간을 가진 사람이 기억과 기록을 본인의 의도에 맞게 조작하고, 사람들은 그것을 진실로 여긴다.

이러한 기술들은 체류 시간과 활성 지표를 향상시키고, 기업의 수익화를 극대화하는 데 도움이 된다. 역설적이게도 기술이 편리해짐으로써 유저들간의 기본적인 존중과 예의는 찾아보기 어렵게 되었다. 인터넷 공간에서만 일어난 일이 사회에 영향을 미치고 대중의 생각을 잠식한다. 이제는 카페에 올라온 누가 쓴 지도 모르는 글이 지상파 뉴스의 한 꼭지를 장식한다.

생면부지의 사람들을 혐오하는 의견이 허구한날 올라오며, '좋아요'의 숫자로 이전같으면 그냥 헛소리로 치부될 의견마저도 설득력을 얻게 된다. 다들 스크린 뒤에 사람이 있다는 걸 잊은 것 같다.

이 문제를 어떻게 해결할 수 있을까? 이전으로 돌아갈 수는 없다. 사실은 그래서 마땅한 답은 없고 이 문제는 인터넷이 사라지기 전까지는 안고 갈 수밖에 없다.

개인의 힘으로 이 문제를 해결하는 것은 불가능하다. 대신 이 문제가 나에게 영향을 주지 않게 할 수는 있다. 다시 온라인에서 탈출해 오프라인으로 회귀하는 게 현실적인 대안이 될 수 있다. 편향된 사고를 가질 수 있어 차단 기능을 쓰는 것은 싫어하지만, 의견의 다름과 상관없이 기본적인 예의를 지키지 않는 이들은 차단한다.

AI가 중간 버퍼의 역할을 해준다는 것에 놀라움을 느끼기도 한다. 내 생각을 굳이 익명의 타인과 공유하며 상처를 받지 않아도, 대중의 생각을 필터링하여 나에게 알려주는 AI 에이전트와 대화하는 것이 훨씬 유익하고 감정 소비도 덜하다.

오랫동안 인터넷 위에서 비즈니스를 해왔던 나로서는 너무나 안타까운 일이지만, 이젠 모니터 밖으로 시야를 돌려 새로운 기회를 찾을 때가 된 것 같다. 이대로 가다간 나마저 미쳐버릴 수도 있으니까.