㈜넥슨

[넥슨컴퍼니] 2026 넥토리얼 for Game Programmer

마감됨인턴 (6개월, 수료 결과에 따라 정규직 전환 가능)신입학력무관경기 성남시 분당구 판교 (넥슨코리아)회사 내규에 따름

넥슨컴퍼니가 2026년 9월 7일까지 게임 프로그래머 지망 신입을 대상으로 6개월 인턴 후 정규직 전환을 목표로 하는 넥토리얼 프로그램 참가자를 모집합니다.

넥슨 넥토리얼 게임 프로그래머 자소서 가이드

문항이 묻는 것과 쓰는 순서를 정리했어요

📋 자소서 문항 뜯어보기

확인된 4개 · 공고 원문도 함께 확인해 주세요

📘문항이 4개인데 경험을 어떻게 나눠 쓸까같은 경험을 여러 문항에 쓰면 읽는 사람은 바로 알아봅니다 · 무료→

이 문항이 진짜 묻는 것
이 문항은 표면적으로 '지원 동기'와 '노력 과정'을 묻지만, 읽는 사람이 실제로 확인하려는 것은 두 가지입니다. 첫째, 지원자가 넥슨이라는 회사와 넥토리얼이라는 프로그램을 구체적으로 이해하고 선택했는지, 아니면 '게임 회사 인턴이라서 지원했다'는 수준인지를 구분하려 합니다. '넥슨이 좋아서'라고 쓰면 팬심으로 읽히고, '이 프로그램의 구조가 내 성장 방향과 맞아서'라고 쓰면 목적의식으로 읽힙니다. 둘째, '노력해온 과정'이라는 단어가 명시적으로 들어 있는데, 지원자 대부분이 결과물(포트폴리오, 수상 이력)만 나열하고 과정—즉 무엇이 막혔고 어떻게 돌파했는지—을 빠뜨립니다. 결과만 쓰면 절반만 답한 것입니다.

이런 실수가 많아요
① 지원 동기를 게임 팬 감상으로 채웁니다 → '어릴 때부터 넥슨 게임을 즐겨 했다'는 문장은 소비자 경험이지 프로그래머 지망 근거가 아닙니다. 읽는 사람은 게임을 좋아하는 사람이 아니라 게임을 만들 수 있는 사람을 찾고 있으므로, 이 방식으로 동기를 채우면 오히려 약합니다. ② '과정' 없이 결과물만 나열합니다 → 문항이 명시적으로 '노력해온 과정'을 요구하는데, 포트폴리오 제목과 수상 이력만 쓰면 절반만 답한 것입니다. 무엇이 어려웠고 어떻게 해결했는지가 빠지면 과정이 아니라 이력서가 됩니다. ③ 기술 스택을 목록으로 나열합니다 → 'C++, Unity, Unreal Engine을 다룰 수 있습니다'처럼 쓰면 어느 수준인지, 어떤 맥락에서 썼는지가 전혀 드러나지 않습니다. 기술은 어떤 문제를 풀기 위해 어떻게 사용했는지와 함께 써야 역량으로 읽힙니다. ④ 넥토리얼을 일반 인턴과 구분하지 않습니다 → '게임 프로그래머가 되고 싶어서 지원했습니다'는 어느 회사 어느 프로그램에도 붙일 수 있는 문장입니다. 이 프로그램의 구조나 방향이 자신의 목표와 어떻게 맞는지를 쓰지 않으면, 넥슨을 선택한 이유가 없는 것으로 읽힙니다. ⑤ 입사 후 방향을 막연한 포부로 마무리합니다 → '열심히 배우겠습니다'나 '회사에 기여하겠습니다'처럼 끝내면 지원자가 자신의 부족한 점을 인식하고 있는지, 이 프로그램에서 무엇을 얻으려는지가 전혀 보이지 않습니다. 구체성이 없는 포부는 성의 없이 읽힙니다.

안 좋은 문장 예시
“"저는 어릴 때부터 넥슨의 게임을 즐겨 하며 게임 프로그래머를 꿈꿔왔고, C++과 Unity, Unreal Engine을 공부하며 포트폴리오를 완성했습니다." — 이 문장은 동기(팬심)와 과정(기술 목록)을 한 줄에 압축했지만, 읽는 사람 입장에서는 소비자 경험과 도구 이름만 남습니다. 무엇이 막혔고 어떻게 돌파했는지가 없으므로 '과정'을 묻는 문항에 답하지 않은 것이며, 세 가지 기술을 나열했지만 어느 수준인지 어떤 맥락에서 썼는지가 전혀 드러나지 않아 오히려 약합니다.”

💡 1,000자 문항이므로 아래 배분을 기준으로 잡으세요. 「지원 동기 선언 100자 → 넥토리얼을 선택한 구체적 이유 200자 → 게임 프로그래머가 되기 위해 노력해온 과정 500자 → 입사 후 방향 200자」입니다. 과정 블록이 절반을 차지해야 문항 요구를 충족합니다. 지원 동기 선언(100자)에서는 '왜 게임 프로그래머인가'를 한 문장으로 압축하세요. 게임을 좋아한다는 감상이 아니라, 프로그래밍과 게임이 교차하는 지점에서 느낀 구체적인 순간을 한 줄로 담으면 됩니다. 넥토리얼를 선택한 이유(200자)는 이 프로그램의 구조—6개월 인턴 후 정규직 전환을 목표로 한다는 점(출처: 채용공고)—와 자신의 성장 계획이 어떻게 맞닿는지를 연결하세요. 단, 넥슨의 사업 구조나 타이틀 정보를 쓰려면 반드시 직접 확인하고 쓰세요(출처: 회사 홈페이지·공시). 과정 블록(500자)이 이 문항의 핵심입니다. 재료를 떠올릴 때는 다음 장면을 순서대로 꺼내세요. ① 처음 게임 프로그래밍을 시작한 계기가 된 장면 ② 막혔던 기술적 문제(렌더링 버그, 물리 충돌 오류, 성능 병목 등) ③ 그 문제를 해결하기 위해 찾아보거나 시도한 것들 ④ 해결 후 달라진 결과물이나 이해도. 이 네 장면을 시간 순서대로 이어 붙이면 '과정'이 됩니다. 공고가 C++, 게임 엔진, 문제 해결을 키워드로 명시하고 있으므로(출처: 채용공고), 이 세 가지 중 하나 이상이 과정 블록에 자연스럽게 등장하면 됩니다. 숫자는 기억나는 것만 쓰세요. 정확한 수치가 없다면 전후 비교로 대체하면 됩니다. 예를 들어 '프레임이 끊겼던 씬이 최적화 후 안정적으로 돌아갔다'처럼 상태 변화를 서술하는 것이 근거 없는 수치보다 오히려 신뢰를 줍니다. 수치가 있다면 '씬 로딩 시간을 4.2초에서 1.8초로 줄였다'처럼 맥락과 함께 쓰세요. 마지막 입사 후 방향(200자)은 넥토리얼 기간 동안 구체적으로 무엇을 익히고 싶은지를 쓰세요. '성장하고 싶다'는 선언이 아니라, 지금 자신에게 부족한 부분과 이 프로그램에서 채울 수 있는 부분을 연결하는 방식으로 마무리하면 됩니다.

이 문항이 진짜 묻는 것
이 문항은 표면적으로 프로젝트 소개를 요구하지만, 읽는 사람이 실제로 확인하려는 것은 '이 사람이 막혔을 때 어떻게 생각하고 움직이는가'입니다. 프로젝트 자체의 완성도나 규모보다, 문제를 인식하고 원인을 파악하고 해결책을 선택한 사고 과정이 드러나야 합니다. 문항이 명시적으로 '어려웠던 문제 → 해결 방법 → 결과'를 모두 요구하고 있으므로, 셋 중 하나라도 빠지면 절반만 답한 것입니다. '어려움'을 단순히 '힘들었다'는 감정으로 쓰면 기술 직군 지원자로서 오히려 약합니다. 어떤 기술적 판단이 틀렸는지, 어떤 구조적 한계에 부딪혔는지처럼 원인을 특정할 수 있어야 '문제를 분석하는 사람'으로 읽힙니다.

이런 실수가 많아요
첫째, 프로젝트 기능 목록을 나열하고 어려움으로 넘어가지 않는 경우입니다. '어떤 기능을 구현했는지'를 길게 쓰면 소개서처럼 읽히고, 정작 문항이 요구하는 문제 해결 과정이 뒤로 밀려 분량이 부족해집니다. 둘째, 어려움을 '시간이 부족했다' '처음 써보는 기술이라 낯설었다'처럼 상황 묘사로만 쓰는 경우입니다. 이렇게 쓰면 어떤 기술적 판단이 필요했는지가 보이지 않아, 게임 프로그래머로서의 사고 방식을 확인하기 어렵습니다. 셋째, 해결 방법을 '공식 문서를 찾아봤다' '팀원과 논의했다'처럼 행동만 쓰고 왜 그 방법을 택했는지를 생략하는 경우입니다. 행동 나열은 과정처럼 보이지만, 선택의 근거가 없으면 오히려 얕게 읽힙니다. 넷째, 결과를 '성공적으로 마쳤습니다' '좋은 경험이었습니다'로 마무리하는 경우입니다. 문항이 명시적으로 결과를 요구하는 만큼, 무엇이 달라졌는지를 구체적으로 쓰지 않으면 절반만 답한 것입니다. 다섯째, 팀 프로젝트에서 '우리 팀은'을 주어로 계속 쓰는 경우입니다. 읽는 사람은 팀의 성과가 아니라 지원자 본인이 어떤 판단을 내렸는지를 보려 하므로, 본인의 역할과 결정을 주어로 세워야 합니다.

안 좋은 문장 예시
“"저희 팀은 Unity를 활용하여 3인칭 액션 게임을 개발하였으며, 캐릭터 이동, 공격 판정, UI 구현 등 다양한 기능을 성공적으로 구현하였고, 발표 당일 시연도 무사히 마쳐 좋은 평가를 받았습니다." 이 문장은 프로젝트 소개와 결과를 한 문장에 압축했지만, 어려웠던 문제와 해결 과정이 완전히 빠져 있어 문항이 요구하는 세 가지 중 하나만 답한 것입니다. '성공적으로 구현'과 '좋은 평가'는 무엇이 어려웠고 어떻게 넘었는지를 전혀 보여주지 않아, 읽는 사람 입장에서는 지원자가 그 프로젝트에서 실제로 어떤 판단을 했는지 확인할 수 없습니다. 또한 주어가 '저희 팀'이어서 지원자 본인의 기여와 사고 과정이 보이지 않습니다.”

💡 1,000자 기준으로 분량을 다음과 같이 나누는 것을 권장합니다. 프로젝트 맥락 소개 150자 → 어려웠던 문제 정의 200자 → 해결 과정 450자 → 결과 및 배운 점 200자. 해결 과정에 가장 많은 자를 배분하는 이유는, 읽는 사람이 가장 오래 머무는 자리이기 때문입니다. 무엇을 쓸지 막혔을 때는 다음 장면을 떠올려 보세요. '처음 짠 코드가 특정 상황에서만 터졌던 순간', '팀원과 구조 설계 방향이 달라서 결정을 못 내렸던 회의', '성능이 기대치의 절반도 안 나와서 프로파일러를 처음 켰던 날', '레퍼런스가 없어서 직접 실험을 설계했던 과정' 중 하나라도 떠오른다면 그것이 소재입니다. 숫자는 정확하지 않아도 됩니다. 기억나는 수치가 있으면 쓰고, 없으면 '최적화 전후 프레임 드롭 빈도가 눈에 띄게 줄었다'처럼 전후 비교 형태로 쓰세요. 단, 숫자를 아예 쓰지 않으면 결과 문단이 추상적으로 읽히므로, 기간·시도 횟수·팀 규모 중 하나라도 넣는 것이 좋습니다. 해결 과정을 쓸 때는 '했습니다' 한 줄로 끝내지 말고, 왜 그 방법을 선택했는지, 다른 방법은 왜 버렸는지를 한 문장이라도 남기세요. 그 선택의 이유가 있어야 '판단력이 있는 사람'으로 읽힙니다. 프로젝트 규모나 결과물의 완성도를 걱정하는 분이 많은데, 수상 이력이나 배포 경험이 없어도 괜찮습니다. 문항이 요구하는 것은 '좋은 프로젝트'가 아니라 '문제를 다룬 경험'이기 때문입니다.

이 문항이 진짜 묻는 것
이 문항은 표면적으로 '반대 의견·피드백 경험'을 묻지만, 읽는 사람이 실제로 확인하려는 것은 '이 사람이 불편한 상황에서도 팀의 결과물을 위해 먼저 말을 꺼낼 수 있는가'입니다. 단순히 '의견을 말했다'고 쓰면 소극적 참여자로 읽히고, '어떻게 전달했고 상대가 어떻게 반응했으며 결과가 어떻게 달라졌는지'까지 쓰면 능동적 협업자로 읽힙니다. 문항이 명시적으로 '어떻게 행동했고'와 '무엇을 배웠는지' 두 가지를 요구하는데, 지원자가 가장 많이 빠뜨리는 자리가 바로 '배운 점'입니다—행동 서술에 집중하다 배운 점을 한 줄로 때우면 절반만 답한 것입니다. 게임 프로그래머 직무 특성상 코드 리뷰, 기술 방향 결정, 버그 원인 논쟁처럼 '기술적 판단이 충돌하는 장면'을 소재로 쓰면 직무 연결성이 훨씬 높아집니다.

이런 실수가 많아요
① 반대 의견을 '말했다'는 사실만 쓰고 전달 방식을 생략합니다 → 읽는 사람은 '어떻게 말했는지'를 통해 커뮤니케이션 방식을 판단하는데, 결과만 쓰면 그 판단 근거가 사라져 오히려 약합니다. ② 갈등이 원만하게 해결됐다는 결말에만 집중하고 '내가 틀렸거나 절충했던 부분'을 숨깁니다 → 문항이 명시적으로 '솔직한 피드백'을 요구하는 만큼, 내 의견이 100% 관철된 이야기보다 서로 조율한 이야기가 협업 역량을 더 잘 보여줍니다. ③ 직무와 무관한 소재(아르바이트 고객 응대, 동아리 행사 준비 등)를 씁니다 → 틀린 것은 아니지만, 게임 프로그래머 직무에서는 기술적 판단이 충돌하는 장면을 소재로 쓸 때 직무 이해도가 함께 전달되어 같은 분량으로 더 많은 정보를 줄 수 있습니다. ④ '배운 점'을 마지막 한 줄에 '소통의 중요성을 깨달았습니다'로 마무리합니다 → 문항이 명시적으로 '무엇을 배웠는지'를 요구하는데 이 자리를 추상적 교훈으로 채우면 절반만 답한 것이고, 읽는 사람 입장에서는 이 경험이 지원자에게 실제로 어떤 변화를 만들었는지 알 수 없어 오히려 약합니다. ⑤ 500자 안에 배경 설명을 너무 길게 씁니다 → 어떤 프로젝트였는지 설명하다 행동과 배운 점을 쓸 공간이 없어지는 구조인데, 500자에서 상황 설명이 200자를 넘으면 핵심인 '어떻게 행동했는지'가 압축되어 구체성이 사라집니다.

안 좋은 문장 예시
“"팀 프로젝트를 진행하면서 의견 충돌이 있었고, 저는 제 의견을 솔직하게 전달하여 팀원들을 설득하였고 결국 프로젝트를 성공적으로 마칠 수 있었으며 이를 통해 소통의 중요성을 배웠습니다." 이 문장은 '의견 충돌이 있었다'는 상황, '설득했다'는 결과, '소통이 중요하다'는 교훈을 모두 담고 있지만 세 가지 모두 추상적이어서 읽는 사람이 아무것도 확인할 수 없습니다. 문항이 명시적으로 요구하는 '어떻게 행동했는지'—어떤 근거로, 어떤 방식으로, 어떤 타이밍에 말했는지—가 완전히 빠져 있어 행동 서술이 없는 것과 같습니다. '소통의 중요성을 배웠습니다'는 500자 문항에서 가장 자주 나오는 마무리 문장이기도 해서, 이 문장이 있으면 배운 점 자리가 오히려 약점으로 읽힐 수 있습니다.”

💡 500자는 매우 짧기 때문에 분량 배분을 먼저 정하고 써야 합니다. 권장 구조는 다음과 같습니다: 상황 설정 80자(언제, 어떤 팀, 어떤 맥락) → 내가 전달해야 했던 반대 의견·피드백의 내용 100자 → 실제로 어떻게 행동했는지(전달 방식·타이밍·근거 제시) 200자 → 그 결과 팀이나 결과물이 어떻게 달라졌는지 70자 → 내가 배운 점 50자. 이 배분에서 '어떻게 행동했는지' 200자가 핵심 덩어리입니다—여기서 '말했다'로 끝내지 말고 '어떤 근거를 어떤 순서로 제시했는지'를 써야 행동이 구체적으로 보입니다. 소재가 떠오르지 않을 때는 다음 장면을 순서대로 떠올려 보세요: ① 팀 프로젝트에서 기술 스택이나 구현 방식을 결정할 때 내 의견이 달랐던 순간, ② 코드 리뷰에서 동료의 코드에 문제를 발견했지만 말하기 어색했던 순간, ③ 마감이 촉박한데 팀원이 잘못된 방향으로 가고 있다고 느꼈던 순간, ④ 교수나 팀장의 방향에 동의하지 않았지만 직급 차이 때문에 말하기 어려웠던 순간. 이 중 하나라도 '내가 먼저 말을 꺼낸' 경험이 있으면 그것이 소재입니다. 숫자는 기억나는 것만 쓰고, 정확하지 않으면 전후 비교로 대신하세요. 예를 들어 정확한 날짜나 수치가 기억나지 않으면 '방향을 바꾼 뒤 빌드 오류가 사라졌다'처럼 변화 자체를 서술하는 것이 억지로 숫자를 끼워 넣는 것보다 오히려 자연스럽습니다. 단, 팀 규모(3인 팀, 5인 팀)나 기간(2주 프로젝트, 한 학기 수업) 정도는 맥락을 빠르게 전달하므로 기억나면 넣는 것이 좋습니다. '배운 점' 50자는 추상적 교훈('소통이 중요하다는 것을 알았습니다')으로 채우면 공간 낭비입니다. '이 경험 이후 내가 실제로 바꾼 행동'을 한 문장으로 쓰면 배운 점이 살아납니다—예를 들어 '이후 코드 리뷰 때는 문제점을 먼저 말하기 전에 내 이해가 맞는지 질문부터 하게 됐습니다'처럼 행동 변화로 표현하세요.

이 문항이 진짜 묻는 것
이 문항은 표면적으로 '무엇을 할 수 있냐'를 묻지만, 읽는 사람이 실제로 확인하려는 것은 '그 역량이 게임 프로그래머 업무에 얼마나 가깝게 쓰였는가'입니다. 역량 이름만 나열하면 '알고는 있다'로 읽히고, 구체적인 문제 상황과 함께 쓰면 '실제로 써봤다'로 읽힙니다. 이 차이가 결정적입니다. 또한 문항이 '실제로 활용했던 사례'를 명시적으로 요구하고 있으므로, 사례 없이 역량만 설명하면 절반만 답한 것입니다. 공고 키워드인 C++·게임 엔진·AI 활용 중 자신이 가장 깊게 쓴 것 하나를 골라 집중하는 편이 여러 개를 얕게 나열하는 것보다 훨씬 강하게 읽힙니다.

이런 실수가 많아요
첫째, 역량을 여러 개 나열하고 사례는 각각 한 줄씩만 씁니다 → 500자 안에서 C++·Unity·AI를 모두 다루면 각 사례가 2~3줄에 그쳐, 읽는 사람이 '어느 것도 깊이 없다'고 느낄 수 있습니다. 하나를 골라 깊게 쓰는 것이 훨씬 강합니다. 둘째, '활용했다'는 말만 반복하고 어떻게 활용했는지를 빠뜨립니다 → 'Unity를 활용해 게임을 개발했습니다'는 사례가 아니라 결론입니다. 문항이 명시적으로 '실제로 활용했던 사례'를 요구하므로, 어떤 문제를 어떤 방식으로 풀었는지가 반드시 들어가야 합니다. 셋째, 결과를 '성공적으로 완료했습니다'로만 끝냅니다 → 신입에게 완성 여부보다 중요한 것은 그 과정에서 무엇을 배웠는지입니다. 결과 한 줄로 끝내면 역량의 깊이가 드러나지 않습니다. 넷째, AI 활용 경험을 'ChatGPT로 코드를 짰습니다'로만 씁니다 → 도구를 쓴 것과 도구를 활용해 문제를 해결한 것은 다르게 읽힙니다. AI를 어떤 판단 아래 어떻게 검증하며 썼는지를 함께 써야 역량으로 인정받을 수 있습니다. 다섯째, 학교 수업 과제를 사례로 쓰면서 맥락을 생략합니다 → 과제 경험 자체는 문제가 없지만, '○○ 수업 과제로 만들었습니다'에서 멈추면 어떤 기술적 도전이 있었는지 전혀 보이지 않습니다. 과제라도 기술적 문제와 해결 과정을 중심으로 서술해야 합니다.

안 좋은 문장 예시
“"저는 C++, Unity, Python, AI 도구 등 다양한 기술 스택을 보유하고 있으며, 여러 프로젝트에서 이를 활용하여 성공적으로 결과물을 완성한 경험이 있습니다." → 역량 이름만 나열되어 있고 어떤 문제를 어떻게 풀었는지가 전혀 없습니다. '다양한'과 '성공적으로'는 읽는 사람에게 아무 정보도 주지 않으며, 문항이 명시적으로 요구한 '실제로 활용했던 사례'가 빠져 있어 절반만 답한 것으로 읽힐 수 있습니다.”

💡 500자는 길지 않으므로 역량 하나에 집중하는 구조가 유리합니다. 권장 배분은 다음과 같습니다. 「역량 선언 50자 → 어떤 상황·문제였는지 100자 → 그 역량을 어떻게 적용했는지 250자 → 결과 또는 배운 점 100자」. 역량 선언은 '저는 C++을 자신 있게 씁니다'처럼 한 줄로 끊고, 나머지 450자를 사례에 쏟아야 합니다. 무엇을 쓸지 막힐 때는 다음 장면을 떠올려 보세요. ① 팀 프로젝트나 개인 프로젝트에서 버그나 성능 문제로 밤을 새운 적이 있다면 그 순간, ② 게임 엔진 에디터 안에서 직접 컴포넌트를 만들거나 셰이더를 건드린 경험, ③ ChatGPT·Copilot 등 AI 도구를 써서 코드 리뷰나 알고리즘 탐색을 한 경험, ④ 알고리즘 대회·과제·해커톤에서 특정 언어의 기능을 처음 제대로 이해한 순간. 이 중 하나라도 떠오르면 그것이 재료입니다. 숫자는 기억나는 것만 씁니다. 정확한 수치가 없다면 '프레임 드롭이 눈에 띄게 줄었다'보다는 '60fps 목표 대비 40fps에서 멈추던 문제를 오브젝트 풀링으로 개선했다'처럼 전후 비교 형태로 쓰세요. 수치를 부풀리면 면접에서 바로 드러나므로, 기억나는 범위 안에서만 씁니다. 공고가 C++·게임 엔진·AI 활용을 나란히 예시로 제시하고 있으므로(출처: 채용공고), 이 세 가지 중 자신이 실제로 가장 깊이 쓴 것을 고르면 됩니다. 셋 다 쓰려 하면 500자 안에서 모두 얕아집니다. 하나를 골라 '이 사람은 이것만큼은 제대로 써봤구나'라는 인상을 남기는 것이 목표입니다. 마지막으로, 사례의 결말은 '완성했다'보다 '이 경험으로 ○○의 한계를 알게 됐다'처럼 다음 학습 방향을 한 줄 붙이면 신입다운 성장 가능성을 자연스럽게 보여줄 수 있습니다.

🔑 이 공고에서 놓치기 쉬운 키워드

자소서에 이 단어들이 들어가 있는지 확인해보세요

게임 프로그래밍게임 엔진C++문제 해결AI 활용프로젝트 경험기술 스택협업 커뮤니케이션

🎓 이 직무에 도움 되는 자격증·역량

지금 준비해두면 다음 공고에도 쓸 수 있어요

정보처리기사

게임 프로그래머 직무의 기본 CS 지식을 공식적으로 증명하는 국가자격증으로, 신입 지원 시 기본 역량 지표로 활용됩니다.

Unity Certified Associate (게임 개발자)

Unity 엔진 활용 능력을 공식 인증하며, 공고에서 게임 엔진 역량을 명시적으로 요구하는 만큼 실무 준비도를 보여줄 수 있습니다.

Unreal Engine 관련 수료증 (에픽게임즈 공식 교육)

대형 게임사에서 Unreal Engine 사용 비중이 높아, 엔진 학습 이력을 공식 수료 형태로 제시하면 포트폴리오를 보완합니다.

TOPCIT (IT 역량지수)

소프트웨어 개발 전반의 실무 역량을 수치로 보여주는 시험으로, 게임 개발사 신입 지원 시 기술 역량 증빙 자료로 활용됩니다.

📊 이 회사, 실제로 몇 명이 일하나요?

공고에는 없는 정보예요. 국민연금공단이 공개한 사실입니다

(주)넥슨코리아

경기도 성남시 분당구 삼평동 · 응용 소프트웨어 개발 및 공급업

국민연금 가입자

4,236명

8월 신규 가입

28명

8월 자격 상실

60명

📐 같은 업종 사업장 13,787곳 중 상위 1% 규모예요 (이 업종 중앙값 7명)

업종 분류는 국민연금공단 기준이에요. 회사 규모가 곧 채용 규모나 근무 여건을 뜻하진 않아요.

이 두 숫자는 입사자·퇴사자 수가 아니에요.
국민연금 가입 자격이 생기거나 없어진 사람 수예요. 그래서 이런 경우가 함께 들어갑니다.

· 신규 가입에는 휴직 후 복귀처럼 다시 납부를 시작한 사람도 포함돼요
· 자격 상실에는 육아휴직·무급휴직 등으로 납부를 멈춘 사람도 포함돼요
· 회사에 계속 다니고 있어도 이 숫자에 잡힐 수 있다는 뜻이에요

또 지난달 고지 대상과 비교해 세는 방식이라, 실제 인원 변동과 한 달 정도 차이가 날 수 있어요.

국민연금에 가입한 근로자 기준이에요. 일용직·프리랜서·해외 법인 인원은 빠질 수 있어요. 이 자료는 가입자 3인 이상 법인사업장(개인사업장은 10인 이상)만 담고 있어요.

출처: 국민연금공단 「국민연금 가입 사업장 내역」 · 2026-08 기준

🏢 이 회사, 어떤 곳인가요?

지원동기와 면접 답변에 쓸 수 있는 공시 기반 정보예요

넥슨은 1994년 설립된 글로벌 게임회사로, 던전앤파이터·메이플스토리 등 30년 이상 서비스해온 자체 IP를 보유하고 있습니다. 2026년 기준 던전앤파이터 키우기·던전앤파이터 클래식·프로젝트 오버킬 등을 핵심 파이프라인으로 공개하며 글로벌 확장을 추진 중입니다. 2026년 캐피털 마켓 브리핑에서 AI 전략과 사업 구조 재편을 중장기 성장 방향으로 제시했습니다. 판교 본사를 중심으로 게임 프로그래밍 직군 채용을 꾸준히 진행하고 있습니다.

참고: company.nexon.com · theviewers.co.kr · blog.nexon.com

설립

2005년 10월

출처: 금융감독원 전자공시시스템(DART) 사업보고서 · 회사 개요는 공개된 웹 정보 요약회사 홈페이지 →

이 공고는 마감됐지만,

같은 직무의 다음 공고를 위해 지금부터 자소서를 다듬어두세요. 제출 전에 어디가 약한지 알면 준비가 빨라집니다.

가입 선물: 자소서 채점·쓰기 중 1회 + 모의면접 1회 무료 · 카드 등록 없이

채용 정보 제공: 잡코리아
문항 분석·키워드·자격증 정리는 인뷰AI가 작성한 내용입니다.

원본 공고 보기 →

🧰 지원서 쓰기 전에

로그인 없이 바로 쓰는 무료 도구 · 이용권 차감 없음

🔍자소서 AI 표현·클리셰 검사AI 티 나는 진부한 표현 찾기 🗣어학 점수 변환기TOEIC·토익스피킹·OPIc·TEPS 환산 🎓학점 변환기4.5 · 4.3 · 4.0 · 100점 환산 📅졸업·전역연도 계산기입학일·입대일로 바로 계산

이 페이지는 공개된 채용 정보를 요약·분석한 것이며, 지원 접수는 원본 채용 사이트에서 진행됩니다.
공고 정보 수정·게시 중단 문의: soohyeok@inviewjob.com · 인뷰랩스 (사업자등록번호 239-45-01331)
직업정보제공사업 신고번호: J1202020260020