#들어가며

안녕하세요. 저는 쿠키런 킹덤의 4년차 클라이언트 프로그래머로 일하고 있는 박지선입니다.

제가 취업준비생 시절, 클라이언트 프로그래머가 무슨 일을 하는지 구체적으로 잘 알지 못했습니다.

검색 엔진에 찾아봐도,

“서버 프로그래머는 유저 데이터를 저장하는 서버를, 클라이언트 프로그래머는 눈에 보이는 게임을 구현하는 일을 합니다.”

와 같은 간단한 정의만 흔히 접할 수 있었죠.

하지만 실제 현업에서는 클라이언트 프로그래머가 하는 일은 이보다 훨씬 다양합니다.

• 눈에 보이는 게임을 구현하는 것 뿐만 아니라,
• 다른 직군과 누구보다 긴밀히 협업하고,
• 툴을 개발하거나,
• 리소스를 관리하고,
• 게임 엔진을 다루는 등

게임 개발 전반에 걸쳐 다양한 업무를 맡고 있습니다.

그래서 이 글에서는 클라이언트 프로그래머를 꿈꾸며 공부하는 취업 준비생 분들에게 조금이라도 도움이 되기를 바라는 마음으로, 제가 실제로 구현한 컨텐츠를 예시로 들어서 컨텐츠 개발 흐름을 따라 클라이언트 프로그래머가 어떤 일을 하는지 구체적으로 이야기해보려 합니다.

물론 회사나 팀마다 개발 문화와 방식이 다를 수 있기 때문에 이 글에서 소개하는 내용이 모든 게임 회사에 똑같이 적용되지는 않을 수 있습니다. 같은 팀 내에서도 쿠키 제작이냐, 전투 컨텐츠 제작이냐, 왕국 컨텐츠 제작이냐에 따라서 달라질 수 있습니다. 이 점 참고해서 하나의 실무 예시로 읽어주시면 감사하겠습니다.

#게임 회사의 조직 구조와 직무 소개

이야기를 하기에 앞서, 게임 회사에 어떤 직군이 있는지 잘 모르시는 분들을 위해 간단한 설명을 하고 넘어가겠습니다. 지금 설명드리는 직군들이 앞으로 나올 실무 예시에 등장하게 됩니다. 이 정도는 안다! 하시는 분들은 다음 챕터로 바로 넘어가시면 됩니다.

게임 개발팀에는 다양한 직군이 속해있습니다. 회사나 프로젝트에 따라 명칭이나 세부 구성이 다르겠지만, 보통 다음과 같은 직군으로 나뉩니다.

• PD (Project Director) : 프로젝트 전체의 방향성과 퀄리티를 총괄합니다.
• PM (Project Manager) : 프로젝트의 개발 관리와 출시, 운영에 이르는 모든 매니지먼트를 담당하며, 개발팀 외부 조직들과의 커뮤니케이션도 함께 맡고 있습니다.
• 서버 프로그래머 : 게임의 백엔드를 구축하고, 유저 데이터 관리 및 서버-클라이언트 간 통신을 담당합니다.
• 클라이언트 프로그래머 : 게임 구조를 설계하고, 여러 직군이 만든 리소스와 데이터를 게임 속에서 자연스럽게 연결해서 게임이 실제로 동작하도록 구현합니다.
• 스토리 : 게임의 전반적인 스토리부터 캐릭터를 포함한 서사 전반을 구성합니다. 쿠키런 킹덤에서는 데코 아이템, 패키지 상품, 이벤트 문구 등 게임 곳곳에 들어가는 모든 텍스트가 스토리 팀의 손을 거칩니다.
• 아트 : 스토리에 어울리는 컨셉과 캐릭터를 디자인하고, 게임에 사용되는 리소스를 제작합니다. 쿠키런 킹덤에서는 배경 아트, 캐릭터 아트, 일러스트 아트 세 팀으로 구성되어 있습니다.
• UIUX : 아트의 리소스와 기획서를 바탕으로 인터페이스와 유저 경험을 설계합니다. 프로젝트 내의 리소스를 관리하고 조립해서 프리팹을 제작하기도 합니다.

  💡 프리팹(prefab) 이란?

  Unity에서 재사용 가능한 오브젝트 템플릿을 의미합니다. 일관된 UI 구성이나 오브젝트 배치에 유용하게 사용됩니다.

• 이펙트 : 전투 연출이나 UI 효과 등 시각적인 효과를 제작합니다.
• 모션 : 캐릭터나 오브젝트에 생동감 있는 모션을 적용합니다.
• 기획 : 게임의 전반적인 시스템, 컨텐츠, 밸런스를 설계합니다. 쿠키런 킹덤에서는 왕국 컨텐츠 기획, 전투 컨텐츠 기획, 시스템 기획, 캐릭터 기획 네 팀으로 구성되어 있습니다.
• QA (Quality Assurance) : 기획 의도에 맞게 기능이 동작하는지 테스트하고, 유저의 실제 경험을 바탕으로 피드백을 제공합니다.

이처럼 하나의 게임을 만들기 위해 다양한 직군이 함께 긴밀히 협업하며 프로젝트를 완성해 나갑니다.

#업데이트와 업무 루틴

클라이언트 프로그래머의 업무를 어떻게 더 잘 설명할 수 있을까 고민하다가, 실무를 예시로 설명드리면 좋을 것 같아서 게임 업데이트와 업무 루틴을 따라 설명드리려 합니다.

쿠키런 킹덤을 꾸준히 플레이 해보셨다면 이 미니게임을 아실 수도 있을 것 같습니다. 2025년 6월 4일에 업데이트 되었던 ‘정글전사 쿠키의 베리베리 높이높이!’ 로 제가 작업했던 미니게임 컨텐츠입니다.

이 컨텐츠가 어떤 과정을 통해 개발되었는지를 한 번 돌아보도록 하겠습니다.

참고로 ‘점핑 플랫폼’이라는 명칭이 계속 등장할텐데, 이는 임의로 작업자들끼리 정한 개발 명칭입니다. 컨텐츠의 이름은 개발 후반부에 스토리 팀에서 IP 특유의 톤앤매너와 함께 시스템상의 직관성이 전달될 수 있게끔 작성해주십니다.

#📋 컨텐츠 결정

쿠키런 킹덤은 PD와 스토리팀, 아트팀을 중심으로 1년 단위로 대략적인 업데이트 플랜을 정해두는데요, 그 플랜에 맞춰서 이번 업데이트에 어떤 스토리가 들어갈 것인지, 어떤 컨텐츠를 넣을 것인지를 결정합니다.

이번 업데이트에 들어가는 비스트 에피소드 스토리에서 정글전사 쿠키가 나무에 올라 베리를 따는 장면이 등장했고 그걸 토대로 미니게임으로 만들기로 결정하였습니다.

#🤝🏻 상위방향성 & 상세기획 회의

이 회의들은 PD님과 기획팀이 주로 진행합니다. 컨텐츠에서 어떤 경험을 줄 지에 대한 방향성, 미니게임의 구성을 논의하는 회의입니다.

이 단계까지는 클라이언트 프로그래머의 개입이 크게 없습니다. 이런 컨텐츠가 들어갈 예정이구나 정도만 파악해서 담당자를 배정하거나 구현 가능성을 확인합니다.

여기서 말하는 구현 가능성이란 제작할 일정이 충분한지, 기술적으로 가능한지 체크하는 것을 말합니다.

#🏃🏻 킥오프 회의

앞에서 방향성을 정한 후 기획팀에서는 킥오프 기획서를 작성합니다. 킥오프 회의는 실무자들을 위한 회의로, 이 회의를 진행한 후 본격적으로 작업을 시작합니다. 회의에서는 기획자를 중심으로 서버&클라이언트 프로그래머, 아트, UIUX, 이펙트, 모션팀 모두가 참석해서 컨텐츠 구현을 위해 구체적인 스펙을 체크하고, 회의가 끝나면 PM팀에서 각 직군별로 작업 일정을 확인해서 조율해주십니다.

킥오프 회의에서의 클라이언트 프로그래머의 역할은 매우 중요합니다.

클라이언트 프로그래머는 데이터, 서버, 리소스 작업이 모두 완료된 이후에 건담을 조립하는 것처럼 작업을 하는데, 이 때 부품이 맞지 않아 조립을 못하는 일이 생기면 안 되겠죠. 그래서 미리 설계에 참여해서 리드해야 이후 작업에 차질이 없습니다.

다음과 같이 원하는 형태로 리소스를 제작해주시게끔 작업 방향성을 제시합니다.

아트 ⇒ “이 정도 사이즈의 이미지 리소스를 반복해서 사용할 예정이라 이렇게 제작 부탁드립니다.”

UIUX ⇒ “이런 구조로 프리팹 제작 부탁드립니다.”

이펙트 ⇒ “이 오브젝트는 Canvas가 아니라 WorldSpace에 들어갈 예정이니, UI 이펙트가 아닌 일반 이펙트로 제작 부탁드립니다.”

#💽 데이터 구조 회의

쿠키런 킹덤은 게임 데이터를 위해 엑셀을 사용합니다. 서버와 클라이언트가 모두 엑셀 데이터를 가져다 사용하기 때문에 어떤 식으로 엑셀에 데이터를 입력할 것인지 논의가 필요합니다.

새로운 컨텐츠를 위해 데이터 구조를 새로 설계해야 하는 상황에 주로 진행하는 회의입니다.

#🛠️ 툴 개발

본격적인 점핑 플랫폼 게임 개발을 시작하기에 앞서, 기획팀에게 맵 툴이 필요한 상황이 되어 툴을 개발하게 되었습니다.

이 툴은 정해진 규칙에 따라 맵 데이터를 랜덤으로 생성하고, 결과를 유니티 에디터를 통해 가시적으로 확인하며 플랫폼의 위치나 타입을 원하는 대로 조정할 수 있도록 만들어졌습니다.

기존에는 데이터를 하나하나 입력해가며 맵을 완성해야 했지만, 툴을 통해 클릭 한 번으로 랜덤 생성이 가능해졌고, 원하는 확률을 실시간으로 조정해 바로 결과를 확인할 수 있게 되었습니다.

툴 개발은 이렇게 단순한 편의 기능을 넘어, 프로젝트 전체의 개발 효율과 안정성을 높이는 클라이언트 프로그래머의 주요 업무 중 하나입니다.

지금은 점핑 플랫폼 게임을 위한 맵 툴 하나만을 예시로 들었지만, 쿠키런 킹덤에서는 이 외에도 수많은 툴들을 제작 및 사용하고 있습니다.

툴이 가져다주는 이점은 다음과 같습니다:

• 반복 작업 자동화: 수동으로 해야하는 반복 작업을 클릭 몇 번으로 처리할 수 있게 만들어줍니다.
• 실수 방지: 사람이 직접 작업하다 보면 실수가 생기기 마련인데, 툴을 통해 데이터나 리소스를 다룰 때 발생할 수 있는 실수를 미리 탐지할 수 있습니다.
• 협업 효율 향상: 작업자가 다른 직군에게 요청하지 않고도 스스로 테스트해볼 수 있어, 반복적인 커뮤니케이션 비용이 줄어듭니다.
• 밸런싱 용이: 데이터를 빠르게 수정하고 테스트할 수 있어, 밸런싱과 퀄리티 향상에 큰 도움이 됩니다.

#🏗️ 작업 시작

이제 본격적인 개발이 시작되었습니다.

숙련된 클라이언트 프로그래머라면, 서버나 데이터 작업이 이미 끝났다고 가정하고! 리소스도 다 준비됐다고 생각하고! 미리 코드를 구상해보며 작업을 진행할 수도 있지만, 보통은 다음과 같은 순서를 거칩니다.

직군별로 독립적으로 진행되는 작업이 있고, 아닌 작업이 있습니다. 간단하게 정리해보면 이렇습니다.

클라이언트 프로그래머는 이 과정에서 모든 직군과 끊임없이 소통하며 작업을 조율합니다.

각 직군의 작업이 완료되면, 그 결과물을 모아서 실제 게임 안에서 동작하도록 구현하는 것이 클라이언트 프로그래머의 역할입니다.

#1. 데이터 & 서버 작업

작업이 시작되면 일단 기획팀에서 가데이터 작업을 올려줍니다.

가데이터 작업이 완료되면 서버에서 작업을 시작해서, 작업 내용을 반영한 서버를 띄워줍니다. 이후 클라이언트 프로그래머는 서버에 접속해서 서버 작업에 문제가 없는지 확인합니다.

#2. 리소스 작업

리소스 작업은 데이터 및 서버 작업과는 독립적으로 진행됩니다.

먼저 아트팀에서 게임에 들어갈 리소스를 제작합니다.

이후 UIUX팀이 해당 리소스와 기획서를 바탕으로 UI/UX를 설계하고, 실제 Unity에서 사용할 수 있는 프리팹(prefab)을 조립합니다.

#3. 클라이언트 작업

필연적으로 클라이언트 프로그래머는 모든 직군의 작업이 완료되어야 작업을 끝마칠 수 있기 때문에 작업 순서 상 가장 마지막을 담당하고 있습니다.

앞에서 작업해주신 리소스, 서버, 데이터를 가지고 게임이 실제로 동작하도록 작업해줍니다. 기술적인 내용을 설명하는 글을 아니므로 자세한 작업 내용은 생략하도록 하겠습니다.

작업을 완료할 때 영상이나 캡쳐를 찍어서 리소스 제작자의 의도에 맞게 사용되었는지 확인해야 합니다.

작업을 하면서 같은 클라이언트 프로그래머끼리의 소통도 매우 중요합니다.

쿠키런 킹덤은 약 4년 반 동안 라이브 서비스를 이어오며 수많은 컨텐츠를 추가해왔고, 그만큼 프로젝트의 구조도 점점 깊고 복잡해졌습니다.

이런 기능이 필요하다 싶으면 80%는 이미 존재하는 기능입니다. 이미 구현된 기능을 모르고 또 추가하게 되면 코드가 중복되므로 불필요한 리팩토링이 이후 발생할 수 있습니다. 그래서 작업을 하면서 유사한 사례를 먼저 찾아보는 것이 중요합니다.

“이 기능, 이미 있을까요?”

“비슷하게 작업한 컨텐츠가 있을까요?”

”이 작업, 어떻게 하면 좋을까요?”

위와 같은 질문들이 실무에서는 클라이언트 프로그래머 사이에 거의 매일 오갑니다.

#📦 리소스 관리

개발 작업 마무리 단계에 해야하는 일이 있습니다.

바로 리소스 관리입니다.

리소스 관리를 어떻게 하는지 설명하기에 앞서, 쿠키런 킹덤에서는 Unity AssetBundle을 사용하고 있습니다.

AssetBundle이란, 게임 내 리소스를 따로 패키징해서 필요할 때 불러올 수 있도록 만든 Unity의 리소스 관리 시스템입니다.

AssetBundles - Unity 매뉴얼

앱의 용량이 크면 처음 다운로드 받을 때 오래 걸리기 때문에, 앱 자체는 가볍게 만들고 아래와 같은 타이틀 화면에서 추가적인 리소스를 다운받습니다.

작은 규모의 프로젝트에서는 리소스를 빌드에 포함시켜도 큰 문제가 없습니다. 하지만 게임이 점점 커지고 업데이트가 누적되면 빌드 크기가 심각한 이슈가 됩니다. 그렇게 되면 빌드 내 리소스를 전부 번들로 옮기는 작업을 해야합니다.

만약 빌드에 들어있는 리소스가 번들 리소스를 참조하게 되면 다음과 같은 이슈가 발생하게 됩니다. 리소스를 제대로 불러오지 못해서 흰색 네모박스로 보이는 이슈입니다.

최악의 경우 빌드를 다시 해서 업데이트를 다시 진행해야 하기 때문에 위와 같은 이슈를 방지하기 위해 클라이언트 프로그래머는 아래처럼 외부 리소스 참조 여부를 알려주는 툴을 제작해서 리소스를 관리합니다.

#↩️ 피드백 회의

마감 기간이 끝나면 해당 업데이트에 들어갈 모든 컨텐츠를 모아서 피드백 하는 회의가 있습니다. PD가 회의에 참여하여 구현이 처음 제시한 방향성대로 잘 되었는지, 더 필요한 부분은 없을지를 피드백 해주십니다.

이 회의 이후 3~4일 정도 피드백 반영 기간을 거치고, 본격적인 QA를 시작합니다.

#📝 QA & 빌드 제출

이제 QA팀의 작업이 본격적으로 시작됩니다.

QA팀이 컨텐츠 개발이 진행되는 동안 미리 해두었던 기획서 리뷰와 테스트 케이스를 토대로 테스트를 진행합니다.

• 기획서 리뷰 (인스펙션 작성)
  • 인스펙션 : 기획 문서를 바탕으로, 초기 문제점을 사전에 탐색하고 보완하는 질의응답 과정을 말합니다.
• TC(Test Case) 작성 : 인스펙션 내용을 반영한 기획서를 기반으로, 테스트 항목을 정리한 테스트 케이스(TC)를 작성합니다.
• 테스트 진행 : 테스트는 일반적으로 다음 순서로 진행됩니다 : 유니티 에디터 테스트 → 실제 기기 빌드 테스트
• 컨텐츠 플레이 및 피드백 제출

이 과정을 통해 실제 구현물이 기획 의도에 맞게 작동하는지 확인하고, 컨텐츠의 완성도를 높입니다.

클라이언트 프로그래머는 이 과정에서 발생한 피드백과 이슈를 수정하고, 다시 빌드하여 반영합니다.

QA 이후, 테스트를 마친 게임 빌드를 검수한 뒤 각 앱스토어(Google Play, Apple App Store 등)에 제출합니다.

#🪦 사후 관리

앱스토어에 제출했다고 끝난 것이 아닙니다. 이후에는 모니터링을 진행합니다.

#1. 라이브 이슈 수정

QA팀에서는 업데이트 이후에도 지속적으로 라이브 모니터링을 진행하고, 이슈가 나올 경우 원인을 확인해서 수정합니다.

리소스를 수정하는 것으로 고칠 수 있는 이슈는 패치를 진행하고, 코드를 수정해야 하는 이슈는 중요도에 따라 알려진 버그로 공지를 올리거나 빌드를 다시 해서 업데이트를 진행합니다.

#2. 메모리 관리

메모리 관련 이슈는 지금도 종종 저사양 기기를 사용하는 유저에게 발생하기 때문에, 지속적으로 모니터링해서 최적화를 해주어야 합니다. 모든 유저가 고사양 기기를 쓰는 것이 아니기 때문에, 저사양 환경에서도 원활하게 동작하도록 메모리 사용을 조절해야 합니다.

기기 사양에 따라 앱이 사용할 수 있는 메모리 양에 제한이 걸려있기 때문입니다.

예를 들어 iPhone 8이나 XR같은 일부 기기에서는 실행 중 앱이 사용할 수 있는 메모리가 약 2GB로 제한되어 있어서 이 이상으로 메모리를 사용할 경우 iOS는 메모리 보호를 위해 예고 없이 앱을 종료합니다.

게임이 안정적으로 실행되도록, 번들 리소스를 무제한으로 로드하지 않고 일정 시점마다 메모리에서 내리는 작업이 필요합니다.

위와 같은 로딩 화면을 띄워놓고 메모리 정리를 진행합니다.

주로 전투 화면에 진입하기 직전에 메모리를 정리하는데요, 전투 씬은 리소스를 많이 사용하는 씬이기 때문에 진입 직전에 사용하지 않는 리소스를 메모리에서 정리하여 여유 공간을 확보합니다.

#3. 리팩토링

작은 기술적 결함을 "시간이 없어서", "나중에 고치지 뭐" 하고 방치하다 보면, 그 문제가 점점 스노우볼처럼 굴러가 결국에는 팀 전체에 영향을 주는 큰 장애로 이어질 수 있습니다. 일명 기술 부채(Technical Debt)가 쌓인 것이죠. 이런 기술 부채를 예방하기 위해서는 리팩토링을 습관적으로, 꾸준히 진행하는 자세가 필요합니다.

지금은 아무 문제가 없어 보여도, 새로운 기능이 계속 추가되면서 코드의 복잡도는 점점 올라갑니다. 구조가 복잡해질수록 작은 수정이 큰 영향을 끼칠 수 있어, 어느 순간에는 리팩토링 없이는 손을 대기 어려운 지경에 이를 수 있습니다.

다만 리팩토링은 기능 변경을 동반하지 않더라도, 기존 동작에 영향을 주는 일이 자주 발생합니다. 따라서 리팩토링 전에 반드시 유관 부서와 협의하고, QA 및 PM 팀에 충분히 공유하여 리스크를 최소화해야 합니다. 또한 리팩토링 작업을 하는 사람은 테스트 코드를 짜두어 기존 기능이 잘 동작하는지 확인할 수 있어야 합니다.

#클라이언트 프로그래머가 되고 싶은 사람에게 하고 싶은 이야기

게임 클라이언트 프로그래머를 꿈꾸는 분들에게, 신입으로서 알아두면 좋은 기술과 실무에서 중요하게 여기는 태도를 소개드리고 싶습니다.

#✅ 신입으로서 알아두면 좋은 기술

신입으로서 알아야 하는 기술과 더불어, Unity 기반의 프로젝트에서 실무에 도움이 되는 기술들을 정리해보았습니다:

• 자료구조와 알고리즘 : 기본 중의 기본입니다. 면접에서도 자주 다뤄지는 만큼, 프로그래머라면 반드시 익혀야 합니다.
• 디자인 패턴 (Factory, Singleton, State, Observer 등) : 대규모 프로젝트에서 코드 유지보수성과 확장성을 높이기 위해 반드시 필요합니다.
• Git : 버전 관리는 팀 프로젝트의 기본입니다. Git을 통해 브랜치 개념을 이해하고, 충돌 해결이나 커밋 이력을 관리하는 능력은 실무에 필요합니다.
• Unity Profiler / Memory Profiler : GC 스파이크, 메모리 누수를 잡는 데에 핵심적인 도구입니다.

  GC 스파이크 (Garbage Collection Spike)란?

  C#에서 메모리 정리를 담당하는 Garbage Collector가 실행될 때, 게임 실행이 잠시 멈추는 현상을 말합니다. 큰 오브젝트 생성·삭제가 많으면 이 현상이 눈에 띄게 발생해, 프레임 드랍이나 끊김처럼 느껴집니다. 모바일 게임에서는 이를 최소화하는 것이 중요합니다.

• UniTask 라이브러리 : coroutine, task보다 훨씬 가볍게 동작하여 GC 부담을 줄이는 데 유리합니다. 비동기 처리를 자주 하는 모바일 게임에서는 필수적으로 사용됩니다.
• DOTween 라이브러리 : UI 애니메이션이나 연출 구현을 빠르게 도와주는 트윈 라이브러리입니다. 연출 퀄리티를 높이는 데 유용하면서도 사용이 간편합니다.

또한, 직접 게임을 처음부터 끝까지(출시까지) 만들어 본 경험만큼 좋은 포트폴리오는 없습니다. 출시한 게임이 있거나, 툴을 만들어 본 경험이 있다면 실무에 바로 도움이 되며, 팀에서도 높은 평가를 받습니다.

#🧠 실무에서 중요하게 여기는 태도

기술만큼 중요한 것이 ‘어떤 자세로 업무에 임하는가’입니다.

제가 현업에서 느낀, 클라이언트 프로그래머로서 중요한 자질들을 정리해보았습니다:

• 게임에 대한 애정과 몰입 : 게임을 좋아하는 사람은 결과물에 더 애정을 담게 됩니다. 결국 이런 마음가짐이 퀄리티와 디테일로 이어집니다.

• 끊임없이 배우려는 자세와 피드백을 수용하고 개선하는 마인드 : 기술은 계속 발전하기 때문에 끊임없이 배우려는 자세가 필요한 것 같습니다. 또 리뷰를 주고받는 일이 많다 보니, 방어적인 태도보다는 개선을 위한 수용력이 중요합니다.

• 끈기와 탐구심 : 실무에서는 ‘왜 이런 문제가 생겼는지’를 찾는 데 하루 이상 걸릴 때도 있습니다. 당장 눈에 보이지 않아도 포기하지 않고 끝까지 파고드는 태도가 필요합니다.

• 협업 중심 사고 : 클라이언트는 기획, 서버, 아트, UIUX, QA 등 모든 직군과 협업합니다. 타 직군의 흐름과 업무를 이해하려는 노력이 곧 원활한 개발로 이어집니다.

#마치며

제가 이 일을 하면서 가장 크게 느낀 건, 클라이언트 프로그래머는 게임을 살아 움직이게 만드는 사람이라는 점입니다. 그리고 그 과정에는 기술뿐 아니라, 소통, 문제 해결, 꾸준한 배움이 꼭 필요하다는 것도 함께 배웠습니다.

게임을 좋아하고, 계속 배우려는 마음이 있다면 누구든 이 일을 해낼 수 있습니다. 처음에는 부족할 수 있어도, 하나하나 익혀가다 보면 실력은 반드시 쌓이고, 언젠가 자신 있게 “나도 팀의 일원이다”라고 말할 수 있게 될 거예요.

지금 이 글을 읽고 있는 여러분이 그 첫걸음을 내딛고 있다면, 그 용기와 시작을 진심으로 응원하며, 이 글이 여러분의 여정에 작은 도움이 되기를 바랍니다.

읽어주셔서 감사합니다.

데브시스터즈는 최고의 인재를 찾고 있습니다.

자세한 내용은 채용 사이트를 확인해 주세요!

채용 바로가기