<div id="readability-page-1" class="page"><div><article><img src="https://get6.github.io/blog/external/b236daddcb30f501b5d931f3b9384ef2.webp" alt="photo by Cosmic Timetraveler(https://unsplash.com/@cosmictimetraveler?utm_source=templater_proxy&amp;utm_medium=referral) on Unsplash">
새 회사에 합류하기로 했을 때, 막상 첫 출근까지 뭘 준비해야 할지 막막할 때가 많죠. 익숙하지 않은 언어를 쓰거나, 도메인이 낯설거나, 팀 문화를 모를 때는 더 그래요. 합류가 정해진 시점부터 첫 한 달까지, 개발자가 미리 챙겨두면 적응이 훨씬 수월해지는 것들을 정리해봤어요.
<h2 id="먼저-내-포지션을-한-문장으로-정의해요">먼저 내 포지션을 한 문장으로 정의해요<a href="#먼저-내-포지션을-한-문장으로-정의해요">#</a></h2>
입사가 정해지면 가장 먼저 할 일은 "이 팀에서 내가 어떤 역할을 맡는가"를 스스로 정리하는 거예요. 직무 기술서에 적힌 직함 말고, 실제로 어떤 가치를 만들어낼지를 한 문장으로 정의해보세요.
예를 들어 백엔드와 프론트엔드 사이를 잇는 풀스택 브릿지 포지션이라면, 구체적인 업무는 이렇게 쪼개볼 수 있어요.
<table>
<thead>
<tr>
<th>역할</th>
<th>구체적 업무</th>
</tr>
</thead>
<tbody>
<tr>
<td>API 계약 정의</td>
<td>OpenAPI/Swagger 스펙 작성, Request/Response DTO 설계</td>
</tr>
<tr>
<td>인터페이스 조율</td>
<td>프론트가 필요한 데이터 구조와 백엔드 도메인 모델 간 변환</td>
</tr>
<tr>
<td>통합 테스트</td>
<td>API 동작 검증, E2E 시나리오 작성</td>
</tr>
<tr>
<td>도메인 분석</td>
<td>비즈니스 로직 설계, 이해관계자 요구사항 정리</td>
</tr>
</tbody>
</table>
이렇게 역할을 미리 쪼개두면, 입사 후 어떤 일에 시간을 써야 할지 헷갈리지 않아요. 면접 때 들은 기대치와 내가 정의한 역할이 어긋난다면, 그것부터 확인하는 게 좋고요.
<h2 id="새-언어스택은-읽을-수-있는-수준부터">새 언어·스택은 "읽을 수 있는 수준"부터<a href="#새-언어스택은-읽을-수-있는-수준부터">#</a></h2>
회사가 쓰는 언어나 프레임워크가 낯설다고 너무 겁먹을 필요는 없어요. 입사 초반에 필요한 건 밑바닥부터 다 만드는 능력이 아니라, 코드 리뷰를 따라갈 수 있는 읽기 능력이거든요.
목표를 이렇게 두 단계로 잡아보세요.
<ol>
<li>읽기 가능한 수준 — 팀의 코드 리뷰에 의견을 보탤 수 있을 정도</li>
<li>고치기 가능한 수준 — 간단한 버그 픽스나 필드 추가를 직접 할 수 있을 정도</li>
</ol>
예를 들어 Java를 쓰다가 Kotlin 기반 팀에 합류한다면, 핵심 문법 차이부터 빠르게 훑는 게 효율적이에요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="kotlin" data-theme="github-dark-dimmed"><code data-language="kotlin" data-theme="github-dark-dimmed">// 1. Data Class — 불변 모델을 간결하게
data class Reserve(
 val id: Long,
 val doctorId: Long,
 val startTime: LocalDateTime
)
 
// 2. Null Safety
val name: String? = null
name?.length ?: 0 // Elvis 연산자: null이면 0
name!!.length // Non-null 단언 (위험하니 지양)
 
// 3. 확장 함수
fun String.toSlug() = this.lowercase().replace(" ", "-")
 
// 4. 스코프 함수
reserve.let { println(it.id) }
reserve.apply { status = "CONFIRMED" }
reserve.also { log.info("Created: $it") }
 
// 5. When (switch 대체)
when (status) {
 "PENDING" -&gt; handlePending()
 "CONFIRMED" -&gt; handleConfirmed()
 else -&gt; handleDefault()
}</code></pre></figure>
<h3 id="학습-순서를-시간-단위로-쪼개요">학습 순서를 시간 단위로 쪼개요<a href="#학습-순서를-시간-단위로-쪼개요">#</a></h3>
막연히 "공부해야지"보다, 시간과 공식 리소스를 함께 적어두면 실제로 끝까지 가게 돼요.
<table>
<thead>
<tr>
<th>순서</th>
<th>내용</th>
<th>시간</th>
<th>리소스</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>언어 기본 문법</td>
<td>2시간</td>
<td><a href="https://kotlinlang.org/docs/basic-syntax.html" rel="noopener noreferrer" target="_blank">Kotlin Basic Syntax</a></td>
</tr>
<tr>
<td>2</td>
<td>기존 언어와 비교</td>
<td>1시간</td>
<td><a href="https://kotlinlang.org/docs/java-to-kotlin-guide.html" rel="noopener noreferrer" target="_blank">From Java to Kotlin</a></td>
</tr>
<tr>
<td>3</td>
<td>프레임워크 튜토리얼</td>
<td>4시간</td>
<td><a href="https://spring.io/guides/tutorials/spring-boot-kotlin/" rel="noopener noreferrer" target="_blank">Spring Boot + Kotlin</a></td>
</tr>
<tr>
<td>4</td>
<td>비동기·동시성 기초</td>
<td>2시간</td>
<td><a href="https://kotlinlang.org/docs/coroutines-basics.html" rel="noopener noreferrer" target="_blank">Coroutines basics</a></td>
</tr>
</tbody>
</table>
여기서 한 걸음 더 나아가, 회사 스택에서 자주 쓰는 표준 패턴 한두 개를 미리 따라 써보는 것도 좋아요. 레이어 구조가 손에 익으면 실제 코드베이스를 처음 열었을 때 훨씬 덜 낯설거든요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="kotlin" data-theme="github-dark-dimmed"><code data-language="kotlin" data-theme="github-dark-dimmed">// Controller — 요청을 받아 서비스로 위임
@RestController
@RequestMapping("/api/reserves")
class ReserveController(
 private val reserveService: ReserveService
) {
 @GetMapping("/{id}")
 fun getReserve(@PathVariable id: Long): ResponseEntity&lt;ReserveDto&gt; =
 reserveService.findById(id)
 ?.let { ResponseEntity.ok(it.toDto()) }
 ?: ResponseEntity.notFound().build()
}
 
// Service — 비즈니스 로직과 트랜잭션 경계
@Service
@Transactional(readOnly = true)
class ReserveService(
 private val reserveRepository: ReserveRepository
) {
 fun findById(id: Long): Reserve? = reserveRepository.findByIdOrNull(id)
 
 @Transactional
 fun create(request: CreateReserveRequest): Reserve {
 // 검증 로직
 return reserveRepository.save(request.toEntity())
 }
}</code></pre></figure>
<h2 id="첫-한-달의-온보딩-로드맵을-그려요">첫 한 달의 온보딩 로드맵을 그려요<a href="#첫-한-달의-온보딩-로드맵을-그려요">#</a></h2>
입사 후 무엇을 할지 미리 단계로 나눠두면, 첫날부터 헤매지 않아요. 주차별 체크리스트로 만들어두는 걸 추천해요.
<h3 id="1주차-환경-세팅과-코드-파악">1주차: 환경 세팅과 코드 파악<a href="#1주차-환경-세팅과-코드-파악">#</a></h3>
<ul>
<li> 로컬 개발 환경 구축 (IDE, DB, Docker 등)</li>
<li> 프로젝트 구조 파악 (패키지 구성, 레이어 구조)</li>
<li> 도메인 용어 정리 문서화</li>
<li> 기존 API 엔드포인트 목록 파악</li>
<li> DB 스키마 분석</li>
</ul>
<h3 id="2주차-첫-기여">2주차: 첫 기여<a href="#2주차-첫-기여">#</a></h3>
<ul>
<li> 작은 버그 수정 또는 API 응답 필드 추가</li>
<li> 코드 리뷰 참여 시작</li>
<li> 팀 컨벤션 파악 (코드 스타일, 커밋 메시지, PR 규칙)</li>
</ul>
<h3 id="한-달-후-목표">한 달 후 목표<a href="#한-달-후-목표">#</a></h3>
<ul>
<li> 독립적으로 작은 기능 추가 가능</li>
<li> 도메인 로직 설계에 참여</li>
<li> 다른 팀과 인터페이스(API 스펙 등) 협의 주도</li>
</ul>
첫 기여는 작을수록 좋아요. 거창한 기능보다 필드 하나 추가하는 PR을 먼저 올려보면, 팀의 리뷰 문화와 배포 흐름을 자연스럽게 익히게 되거든요.
<h2 id="가진-강점을-빨리-증명해요">가진 강점을 빨리 증명해요<a href="#가진-강점을-빨리-증명해요">#</a></h2>
새 환경에서는 위축되기 쉽지만, 입사 전부터 쌓아둔 강점이 분명히 있을 거예요. 그걸 초반에 자연스럽게 드러내면 신뢰를 빠르게 얻을 수 있어요.
특히 도메인을 미리 분석해 둔 내용은 강력한 무기예요. 면접이나 사전 조사 과정에서 파악한 기존 시스템의 한계, 개선 아이디어 같은 걸 정리해두면, 합류 직후 자연스럽게 공유할 수 있어요.
<blockquote>
"기존 시스템을 살펴봤는데, 이 검증 쿼리가 3단 조인이라 복잡하더라고요. 테이블을 직접 연결하면 단순화될 것 같아요."
</blockquote>
이렇게 구체적인 관찰을 들고 들어가면, 단순히 시키는 일을 받는 사람이 아니라 함께 문제를 푸는 동료로 자리잡기 쉬워요. 다만 입사 첫날부터 모든 걸 바꾸려 들기보다, 먼저 맥락을 충분히 듣고 제안하는 순서가 좋아요.
<h2 id="입사-전-미리-확인해두면-좋은-것들">입사 전 미리 확인해두면 좋은 것들<a href="#입사-전-미리-확인해두면-좋은-것들">#</a></h2>
계약서에 사인하기 전이나 첫 출근 전에, 다음 항목들을 확인해두면 입사 후 당황할 일이 줄어요.
<ul>
<li> 코드 리뷰 문화가 있는지</li>
<li> 온보딩 기간에 기대하는 것</li>
<li> 프론트엔드 버전과 상태관리 방식 (Redux? Zustand? React Query?)</li>
<li> 테스트 커버리지 기준이 있는지</li>
<li> 원격 근무 가능 여부</li>
<li> 커뮤니케이션 도구 (Slack, Teams 등)</li>
</ul>
이런 질문은 면접 막바지나 처우 협의 단계에서 물어보기 딱 좋아요. 회사가 일하는 방식을 미리 알수록, 첫날의 적응 비용이 줄어들거든요.
<h2 id="마무리">마무리<a href="#마무리">#</a></h2>
입사 준비의 핵심은 "첫 출근 전에 적응 비용을 최대한 미리 치러두는 것"이에요. 내 역할을 한 문장으로 정의하고, 새 스택을 읽을 수 있는 수준까지 끌어올리고, 온보딩 로드맵과 강점 카드를 손에 쥐고 들어가면, 첫 한 달이 훨씬 가벼워져요. 완벽하게 준비하려고 미루기보다, 지금 할 수 있는 작은 준비부터 하나씩 체크해보세요.
<hr>
<blockquote><div>A man who doesn't trust himself can never really trust anyone else.</div>— Cardinal Retz</blockquote></article></div></div>

이때의 나

sunhwang

새 회사에 합류하기로 했을 때, 막상 첫 출근까지 뭘 준비해야 할지 막막할 때가 많죠. 익숙하지 않은 언어를 쓰거나, 도메인이 낯설거나, 팀 문화를 모를 때는 더 그래요. 합류가 정해진 시점부터 첫 한 달까지, 개발자가 미리 챙겨두면 적응이 훨씬 수월해지는 것들을 정리해봤어요. 먼저 내 포지션을 한 문장으로 정의해요 입사가 정해지면 가장 먼저 할 일은 "이...

새 회사 입사 전, 개발자가 준비하면 좋은 것들

댓글