크래프톤 웹 집중개발캠프를 마치며

노성준·2026년 8월 14일

크래프톤 경기대학교 웹 집중개발캠프 WIL

방학을 그냥 보내기보다는 개발에 집중하며 알차게 보내고 싶었고, 팀 프로젝트를 통해 포트폴리오로 남길 수 있는 결과물을 만들어보고 싶었다.

무엇보다도 크래프톤이라는 이름에서 오는 기대가 컸다.

그렇게 경기대학교에서 진행된 웹 집중개발캠프에 참여하게 되었고, 2주 동안 개인 프로젝트, 클론코딩, 마지막 팀 프로젝트까지 빠르게 경험하게 되었다.

기간은 짧았지만 단순히 기능을 구현하는 것뿐만 아니라, 사용자가 서비스를 이용할 때 어떤 느낌을 받는지와 팀원들과 하나의 결과물을 만들기 위해 어떻게 협업해야 하는지를 많이 생각해볼 수 있었던 시간이었다.


캠프에서의 생활

개발 이야기에 들어가기 전에 캠프 생활 자체가 굉장히 만족스러웠다.

기숙사동과 교육동이 거의 붙어 있어서 건물 사이를 이동하는 데 체감상 5초 정도밖에 걸리지 않았다. 대부분의 생활을 실내에서 할 수 있었고, 한여름이었지만 에어컨도 잘 나와 개발에 집중하기 좋은 환경이었다.

기숙사 방도 깨끗했고 따뜻한 물도 잘 나왔다.

하루 대부분을 교육동에서 개발하다가 잠깐 씻거나 쉴 일이 있으면 바로 기숙사로 갈 수 있다는 점도 생각보다 굉장히 편했다.

식사와 카페

한 끼가 약 8천 원 정도였는데 가격에 비해 잘 나오는 편이라 만족스러웠다.

카페 가격도 저렴했다.

아이스티는 약 2천 원, 스무디도 3~4천 원 정도라 하루 종일 개발하다가 음료가 필요할 때 부담 없이 이용할 수 있었다.

짧은 기간 동안 거의 캠퍼스 안에서 생활하다시피 했는데, 시설과 생활환경이 좋았던 덕분에 개발에만 집중하기 좋은 환경이었다.


1주차 - 오랜만에 직접 해본 손코딩

첫 번째 프로젝트에서는 개인 홈페이지를 제작했다.

사용한 기술은 다음과 같다.

  • HTML
  • CSS
  • JavaScript
  • Flask
  • MongoDB

사이트의 컨셉은 GeoCities 같은 오래된 인터넷 개인 홈페이지였다.

요즘처럼 정돈되고 깔끔한 웹 디자인보다는 강한 색상, 우주 배경, 작은 메뉴와 여러 장식 요소가 섞여 있는 고전적인 인터넷 분위기를 만들어보고 싶었다.

개인적으로 이런 고전적인 웹 디자인을 좋아해서 단순히 기능을 구현하는 것보다 사이트의 분위기를 만드는 과정 자체가 재미있었다.

AI 없이 직접 구현해보기

프로젝트 기간은 약 3일이었다.

이번 프로젝트에서는 의도적으로 AI의 도움을 거의 받지 않고 직접 코드를 작성했다.

요즘은 개발할 때 자연스럽게 AI를 활용하는 경우가 많지만, 짧은 개인 프로젝트까지 대부분 AI에게 맡기면 직접 구현해보는 의미가 줄어들 것 같았다.

그래서 HTML 구조부터 CSS, JavaScript까지 하나씩 직접 작성했다.

오랜만에 코드를 직접 작성하고 화면을 새로고침할 때마다 조금씩 내가 원하는 모습에 가까워지는 과정을 경험하니 생각보다 재미있었다.

이번 프로젝트는 완전히 새로운 기술을 배우는 것보다는 웹의 기본 구조를 다시 직접 다뤄보는 시간에 가까웠다.


2주차 - OP.GG 클론코딩

다음 프로젝트에서는 OP.GG 클론코딩을 진행했다.

구현한 기능은 다음과 같다.

  • 메인 UI
  • 로그인
  • Riot API 연동
  • 소환사 검색
  • 전적 검색
  • 반응형 UI

처음 OP.GG 메인 화면만 봤을 때는 비교적 단순한 사이트처럼 느껴졌다.

하지만 실제로 구현해보니 생각보다 신경 써야 하는 부분이 굉장히 많았다.

생각보다 어려웠던 반응형

가장 기억에 남는 부분은 반응형 UI였다.

처음에는 화면 크기에 따라 요소의 크기를 줄이거나 위치를 조금 바꾸는 정도라고 생각했다.

하지만 실제로 구현해보니 카드의 크기, 텍스트 크기, 간격, 버튼 위치, 요소가 줄바꿈되는 시점까지 세세하게 조정해야 했다.

이 과정을 통해 기능적으로는 동일한 사이트라도 작은 반응이 없으면 화면이 굉장히 밋밋하게 느껴질 수 있다는 것을 알게 되었다.

버튼 하나가 어떻게 반응하고, 화면 크기에 따라 요소가 어떻게 변하는지가 사용자가 느끼는 서비스의 완성도에 생각보다 큰 영향을 준다는 점이 인상적이었다.

그리고 이 경험은 마지막 팀 프로젝트를 만들 때도 그대로 이어졌다.


마지막 팀 프로젝트 - DECK MAYHEM

마지막 프로젝트에서는 3명이 한 팀이 되어 웹 기반 카드 로그라이크 게임인 DECK MAYHEM을 제작했다.

게임 아이디어는 내가 처음 제안했다.

개인적으로 좋아하는 게임인 Balatro에서 영감을 받아 웹에서도 플레이할 수 있는 카드 게임을 만들어보면 재미있겠다는 생각으로 시작했다.

👉 DECK MAYHEM 플레이하기

MVP부터 직접 만들기

프로젝트 초반에는 내가 먼저 MVP를 제작해 전체적인 게임 구조를 잡았다.

이후 팀원들과 기능을 나누고 필요한 부분을 서로 채워가면서 게임을 완성해갔다.

내가 주로 담당한 부분은 다음과 같다.

  • 홈 화면
  • 실제 플레이 화면
  • 카드 UI
  • 카드 선택 및 반응
  • 화면 전환
  • 효과음
  • 플레이 과정에서의 시각적 피드백

기능 자체를 구현하는 것도 중요했지만, 이번 프로젝트에서는 특히 사용자가 플레이할 때 어떤 느낌을 받을 것인가를 많이 고민했다.

기능만 작동한다고 재미있는 것은 아니었다

OP.GG 클론코딩을 하면서 UI에 적절한 반응이 없으면 화면이 상당히 밋밋하게 느껴진다는 것을 경험했다.

그래서 DECK MAYHEM에서는 카드에 마우스를 올렸을 때 어떻게 움직일지, 선택했을 때 어떤 반응을 보여줄지, 버튼을 눌렀을 때 어떤 소리가 나야 자연스러울지 계속 고민했다.

단순히

클릭 → 점수 계산

으로 끝나는 것이 아니라,

카드 선택 → 시각적 반응 → 효과음 → 결과 표시

가 자연스럽게 이어져야 플레이어가 재미를 느낄 수 있다고 생각했다.

특히 카드 게임은 반복적인 행동이 많기 때문에 작은 반응 하나가 플레이 경험에 큰 영향을 준다고 느꼈다.

화면 전환에서도 연속감을 만들고 싶었다

홈 화면에서 게임 화면으로 넘어가거나 플레이 중 다음 단계로 넘어갈 때 화면이 단순히 끊기듯 바뀌면 하나의 게임을 계속하고 있다는 느낌이 줄어든다고 생각했다.

그래서 화면과 화면 사이의 연결이 최대한 자연스럽게 느껴지도록 구성하려고 했다.

이번 프로젝트를 진행하면서 동작하는 화면과 사용하고 싶은 화면 사이에는 생각보다 큰 차이가 있다는 것을 많이 느꼈다.


새벽까지 안자고 게임하신분도 있었다!


개발하면서 어려웠던 점

1. 계속 꼬였던 카드 UI

가장 많이 고생했던 부분 중 하나는 카드 UI 배치였다.

게임 상태와 선택 상태에 따라 카드 위치가 계속 달라지다 보니 예상하지 못한 상황에서 카드의 위치가 이상하게 배치되는 경우가 많았다.

카드 게임에서는 카드의 위치 자체가 플레이 경험에 영향을 주기 때문에 계속 수정할 수밖에 없었다.

2. 팀원 코드와 합치는 과정

각자 기능을 개발하면서 같은 파일이나 비슷한 부분을 수정하는 경우가 있었고, 코드를 합치는 과정에서 충돌이 발생하기도 했다.

이 과정에서 Git을 단순히 코드를 저장하는 도구로 사용하는 것과 실제 협업 도구로 사용하는 것은 많이 다르다는 것을 느꼈다.

누가 어떤 기능을 작업하고 있는지 공유하고, 같은 부분을 동시에 수정하지 않도록 조율하는 것이 중요했다.

3. 특수 카드 로직

특수 카드의 효과도 생각보다 복잡했다.

여러 효과가 동시에 적용되면서 하나의 기능을 수정하면 다른 기능에 영향을 주는 경우가 있었다.

이 부분을 구현하면서 처음부터 상태와 기능의 구조를 잘 설계하는 것이 중요하다는 점을 느꼈다.

4. 결국 포기한 모바일 버전

모바일 대응도 시도했지만 실제로 구현해보니 카드 배치나 상점 화면처럼 넓은 공간을 전제로 만든 UI가 많아 단순히 크기만 줄이는 방식으로는 해결하기 어려웠다.

프로젝트 기간도 약 3일 정도로 짧았다.

결국 모바일까지 어설프게 구현하기보다는 PC 버전의 완성도를 높이는 편이 낫다고 판단했고 모바일 대응은 포기했다.

아쉬운 부분이었지만 짧은 시간 안에서 무엇을 포기하고 무엇을 완성할지 결정하는 것 역시 개발의 일부라는 것을 느꼈다.


Codex를 사용하면서 느낀 점

이번 캠프에서는 AI 도구로 Codex를 적극적으로 사용했다.

처음에는 단순히

이 부분을 이렇게 바꿔줘.

정도로 요청하는 경우가 많았다.

작은 기능에서는 어느 정도 잘 작동했지만 프로젝트가 커질수록 문제가 생기기 시작했다.

내가 수정해달라고 하지 않은 부분까지 함께 변경하면서 기존에 정상적으로 작동하던 기능에 문제가 생기는 경우도 있었다.

더 큰 문제는 처음에는 왜 문제가 발생했는지 나 역시 정확히 설명하지 못했다는 점이었다.

AI를 잘 사용하려면 결국 내가 이해해야 했다

AI에게 정확한 지시를 내리려면 먼저 해당 기능이 어떤 방식으로 동작하는지 내가 이해해야 했다.

어떤 파일이 연결되어 있고, 어떤 상태가 어디에서 변경되고, 어떤 로직 때문에 문제가 발생했는지를 알아야

이 파일의 이 부분만 수정하고 다른 로직은 건드리지 마.

처럼 더 구체적인 지시를 할 수 있었다.

결과적으로 AI를 사용하면서 오히려 관련 기술이 어떻게 동작하는지 더 찾아보고 공부하는 경우도 생겼다.

이번 경험을 통해 AI는 단순히 코드를 대신 작성해주는 도구라기보다는 개발자가 문제를 정확하게 이해하고 있을 때 훨씬 강력하게 활용할 수 있는 도구라는 생각이 들었다.


협업에서 느낀 소통의 의미

캠프에서는 서로 다른 팀원들과 프로젝트를 진행했고 전체적으로 반 분위기가 정말 좋았다.

대부분 서로 친하게 지내서 의견을 이야기하거나 대화하는 것 자체에 어려움은 거의 없었다.

역할도 처음부터 완전히 나누기보다는 필요한 부분을 서로 이야기하고 각자가 할 수 있는 부분을 채워가는 방식으로 진행했다.

친하게 지내는 것과 협업을 잘하는 것은 달랐다

캠프에 들어오기 전에는 스스로 사람들과 소통을 잘하는 편이라고 생각했다.

하지만 며칠 동안 하루 종일 붙어서 하나의 프로젝트를 같이 만들어보면서 소통을 잘한다는 말의 의미를 조금 다르게 생각하게 되었다.

단순히 서로 친하게 지내고 편하게 이야기하는 것만이 소통은 아니었다.

누가 어떤 업무를 하고 있는지 공유하고, 역할을 적절하게 나누고, 같은 부분을 동시에 수정하지 않도록 조율하는 것 역시 협업에서 중요한 소통이었다.

결국 업무를 잘 나누는 것 자체도 소통의 일부라는 생각이 들었다.

앞으로 팀 프로젝트를 할 때는 사람들과 잘 지내는 것뿐만 아니라 서로의 작업이 충돌하지 않도록 역할과 상황을 명확하게 공유하는 능력도 더 키우고 싶다.

Git Issue의 중요성

이번 프로젝트를 진행하면서 Git Issue를 작성하는 것의 중요성도 느꼈다.

여러 명이 동시에 개발하다 보니 누가 어떤 문제를 해결하고 있는지, 현재 무엇이 남아 있는지를 말로만 공유하기에는 한계가 있었다.

Issue를 통해 문제를 정리하면 다른 팀원도 현재 상황을 쉽게 이해할 수 있고 이후 해야 할 작업도 훨씬 명확해졌다.

앞으로 다른 프로젝트를 진행할 때도 Issue를 단순한 기록이 아니라 팀원 간 작업 상황을 공유하는 도구로 활용해야겠다고 생각했다.


마지막 날

마지막 팀 프로젝트는 약 3일 정도밖에 시간이 없었다.

처음 아이디어를 정하고 MVP를 만든 뒤 기능을 추가하고 오류를 수정하다 보니 시간이 정말 빠르게 지나갔다.

마지막 날에는 기숙사 방에도 제대로 들어가지 못하고 계속 게임을 만들었다.

결국 EC2에 게임을 올리고 실제로 접속되는 것을 확인한 뒤 그대로 의자에서 뻗었다.

지금 보면 조금 웃긴 사진이지만 개인적으로 이번 캠프에서 가장 기억에 남는 순간 중 하나다.

짧은 시간 안에 팀원들과 하나의 결과물을 완성하기 위해 끝까지 개발했고, 실제로 배포된 게임을 확인했을 때의 만족감도 컸다.


2주를 마치며

처음에는 개인 홈페이지를 직접 손코딩하는 것으로 시작했다.

그다음 실제 서비스를 분석하며 OP.GG를 클론코딩했고, 마지막에는 내가 직접 아이디어를 제안하고 팀원들과 웹 게임을 만들어 배포까지 해볼 수 있었다.

단 2주 동안 꽤 많은 경험을 했다.

기술적인 부분도 많이 배웠지만 이번 캠프를 통해 가장 크게 달라진 부분은 개발을 바라보는 방식이었다.

기능이 정상적으로 동작하는 것만으로는 충분하지 않았고, 사용자가 그 기능을 어떻게 느끼는지도 중요했다.

AI를 사용하면 무조건 개발이 빨라지는 것도 아니었고, 오히려 AI를 제대로 활용하기 위해서는 내가 더 정확하게 기술을 이해해야 했다.

또한 팀 프로젝트에서의 소통은 단순히 사람들과 잘 지내는 것이 아니라 역할을 분배하고 서로의 작업이 충돌하지 않도록 조율하는 것까지 포함한다는 것도 알게 되었다.

가장 아쉬웠던 점

가장 아쉬웠던 점은 역시 기간이 너무 짧았다는 것이다.

특히 마지막 팀 프로젝트는 실제 개발할 수 있는 시간이 약 3일 정도밖에 되지 않아 구현하고 싶었던 기능을 모두 완성하기에는 시간이 부족했다.

프로젝트에 익숙해지고 팀원들과 개발 방식이 맞아가기 시작할 즈음 캠프가 끝난다는 느낌이 들었다.

모바일 버전이나 일부 게임 시스템처럼 조금 더 다듬고 싶었던 부분도 많이 남았다.

하지만 프로젝트 기간만 아쉬웠던 것은 아니었다.

2주 동안 거의 매일 같은 공간에서 개발하고, 밥을 먹고, 쉬는 시간마다 이야기를 나누다 보니 반 사람들과 생각보다 많이 가까워졌다.

전체적인 분위기도 정말 좋았고 프로젝트가 아니더라도 같이 있는 시간이 재미있었다.

그래서 마지막 날에는 캠프가 끝난다는 것 자체가 생각보다 많이 아쉬웠다.

처음에는 2주라는 시간이 꽤 길게 느껴졌는데, 막상 마지막 날이 되니 조금만 더 있었으면 좋겠다는 생각이 들 정도로 빠르게 지나갔다.


마무리

방학 동안 개발에 집중해보고 싶다는 생각으로 시작한 캠프였지만 기대했던 것보다 훨씬 많은 경험을 얻을 수 있었다.

개인 개발, 클론코딩, API 연동, 팀 프로젝트, Git 협업, AI 활용, 게임 UI와 UX에 대한 고민, 그리고 실제 배포까지 짧은 기간 안에 경험했다.

특히 마지막 프로젝트에서는 단순히 웹사이트를 만드는 것을 넘어 사용자가 어떻게 하면 조금 더 재미있게 느낄 수 있을까를 계속 고민하면서 개발할 수 있었다는 점이 가장 기억에 남는다.

그리고 개발 외적으로도 좋은 사람들과 2주 동안 함께 생활하고 프로젝트를 진행한 경험 자체가 오래 기억에 남을 것 같다.

앞으로 프로젝트를 진행할 때도 단순히 기능을 구현하는 데에서 끝내지 않고,

사용자가 어떻게 느낄지,
팀원들과 어떻게 효율적으로 협업할지,
그리고 AI를 어떻게 올바르게 활용할지

까지 함께 고민하면서 개발하고 싶다.

profile
비기너

0개의 댓글