새 팀과 새 시스템에서 빠르게 Ramp Up 하는 방법
Source: Dev.to
저는 5개 회사와 20개 이상의 프로젝트에서 15 년 경력을 쌓은 소프트웨어 엔지니어입니다. 시간이 지나면서 저는 빠르게 적응할 수 있는 반복 가능한 방법을 찾았습니다—표면적인 이해에 머무르지 않고 실제 기여로 이어지는 방법입니다.
이 글에서는 그 접근 방식을 공유하겠습니다.
빠르게 적응하는 방법
새 시스템에 따라잡고 새로운 팀원으로서 성과를 높이는 데 도움이 되는 세 가지 핵심 습관이 있습니다.
1. 멘탈 모델 구축

시스템을 이해하려면 멘탈 모델이 필수적입니다. 이는 시스템이 전체적으로 어떻게 작동하는지에 대한 내부적인 그림을 의미합니다.
아키텍처 다이어그램이나 시스템 설계 문서와 비슷하지만, 2차원 스케치에 그치지 않습니다. 멘탈 모델은 다차원적이며, 코드, 인프라, 프로세스, 사람, 실제 동작을 하나의 일관된 그림으로 연결합니다.
이 모델을 만들고 다듬기 위해서는 시스템에 영향을 주는 모든 요소—아키텍처, 내부·외부 구성 요소, 사용자, 워크플로, 이해관계자의 가정—에 대해 배워야 합니다. 생각보다 많은 작업이며, 실제로도 그렇습니다.
팁: 아무도 시스템 전체를 즉시 이해하지 못합니다. 처음에는 멘탈 모델이 사실상 빈 페이지이지만, 이는 현실을 반영합니다: 아직 모른다는 뜻이죠. RPG 지도처럼 탐험하면서 한 단계씩 채워 나가면 됩니다.
가장 중요한 습관은 현재 자신이 이해하고 있는 부분과 아직 불분명한 영역을 인식하는 것입니다.
도움이 되는 연습 중 하나는 현재 이해를 바탕으로 아키텍처 다이어그램을 그려보는 것입니다. 멘탈 모델을 검증하고 검토하는 좋은 방법이죠. 저는 전 동료가 온보딩 과정에서 이 방식을 사용한 것을 보고 효과를 확인했습니다. (솔직히 많은 팀에서 아키텍처 다이어그램이 오래되었거나 존재하지 않기 때문에, 여러분이 만든 버전이 다른 사람들에게도 도움이 될 수 있습니다.)
멘탈 모델은 절대 “완성”되지 않습니다. 시스템은 변하고, 코드 외부의 실제 프로세스가 전체 동작에 영향을 미치므로 지속적으로 업데이트해야 합니다.
마지막으로 공통 시스템 유형에 대한 일반적인 멘탈 모델을 구축할 수도 있습니다—예를 들어 웹 애플리케이션, 모바일 앱, 전체 텍스트 검색 엔진, 데이터 동기화 시스템, 비즈니스 도메인 등. 특정 시스템에 대한 견고한 모델을 만든 뒤 이를 일반화하면, 향후 유사한 시스템을 이해하고 작업하는 것이 훨씬 쉬워집니다.
2. “알 수 없는 것” 식별하기
멘탈 모델을 구축하면서 다음과 같은 질문을 하게 됩니다:
- 이 컴포넌트는 무엇을 하나요?
- 시스템의 이 부분에서는 무슨 일이 일어나나요?
- 어떤 서비스가 서로 통신하나요?
이 질문을 할 수 있게 되는 순간, 알 수 없는‑알 수 없는(Unknown‑Unknown) 가 알 수 있는‑알 수 없는(Known‑Unknown) 로 바뀝니다.
알 수 없는‑알 수 없는와 알 수 있는‑알 수 없는는 프로젝트·리스크 관리에서 흔히 쓰이는 용어이며, 알 수 있는‑알 수 있는(Known‑Known)·알 수 없는‑알 수 있는(Unknown‑Known) 도 함께 언급됩니다. 이러한 구분은 흔히 럼스펠드 매트릭스(Rumsfeld Matrix) 라고 불립니다.

새 프로젝트에 합류하면 알 수 없는‑알 수 없는 로 가득합니다. 첫 번째 과제는 이를 알 수 있는‑알 수 없는 로 전환하는 것입니다. “이건 나에게 새롭고, 뭘 의미하는지 모른다” 라는 생각이 떠오를 때 바로 일어납니다.
알 수 있는‑알 수 없는 가 알 수 있는‑알 수 있는 로 바뀌는 시점은 해당 내용을 배우게 될 때이며—보통 누군가에게 물어보거나 적절한 키워드로 문서를 검색할 때—입니다. 이 흐름은 새로운 지식을 습득하는 일반적인 경로입니다.
멘탈 모델을 구축하는 것이 가장 효과적인 도구 중 하나인데, 이는 알지 못했던 부분을 눈에 보이게 만들기 때문입니다.
3. 무지를 드러내기 (Working Out Loud!)
알 수 있는‑알 수 없는 목록이 생기면 이를 명시적으로 표현하세요. 팀원과 이해관계자에게 질문하십시오.
일부 사람들은 이 단계에서 주저합니다. 질문이 너무 기본적이라거나, 누군가의 작업을 방해할까 걱정하거나, 다른 사람들이 자신을 무능하다고 생각할까 두려워할 수 있습니다.
그렇게 생각하지 마세요.
새로운 사람이라는 사실을 숨길 필요 없습니다. 오히려 숨기면 오히려 더 오래 걸립니다.
팀에 잘 관리된 지식 베이스가 있다면 먼저 그곳을 검색해 보는 것이 좋습니다. 하지만 질문을 공개적으로 드러내는 것도 중요한 행동입니다.
Source: …
d concerns is still one of the fastest ways to learn.
내 경험에 따르면, 질문을 하는 것은 모르는 것을 명확히 하는 것 이상의 효과가 있습니다. 질문은 팀원들과 소통할 수 있는 기회를 만들기도 합니다. 새로운 구성원으로서 팀원 및 기타 이해관계자와 관계를 구축하는 것은 시스템 자체를 배우는 것만큼이나 중요합니다—그리고 신규 입사자 기간은 이러한 관계를 구축할 수 있는 보너스 시간입니다.
팀원들이 당신이 질문을 하고 빠르게 배우는 모습을 보면, 당신의 “알지 못하는 것”이 줄어드는 것을 눈치채게 되고, 그 과정에서 신뢰를 얻을 가능성이 높아집니다.
모르는 것을 솔직하게 밝히고, 드러내세요. 질문을 통해 더 빨리 배우고 주변 사람들과 강한 관계를 구축하세요.
이 접근법은 흔히 “Working Out Loud” 라고 불립니다.
The 5 Elements of Working Out Loud – John Stepper

Source: Working Out Loud – J. Stepper’s Method to Raise Cooperation and Relationship
질문, 우려 사항, 현재 작업 및 진행 상황을 주저 없이 가시화하세요. “Working Out Loud”는 여러분이 충분히 적응한 뒤에도 여전히 높은 효과를 발휘합니다—팀이 더 잘 협업하고 더 빠르게 움직이도록 돕기 때문입니다.
결론
이러한 습관—정신 모델을 구축하고, 알 수 없는 부분을 식별하며, 자신의 무지를 드러내는—을 실천하면 새로운 시스템을 더 빠르게 이해하고, 의미 있는 기여를 할 수 있도록 더 빨리 적응할 수 있습니다.
동료 신입 사원들을 돕고 싶다면, 그들의 관점에서 같은 접근 방식을 적용하면 됩니다.
앞으로 AI가 우리 질문의 많은 부분에 답을 줄 것이지만, 소프트웨어 엔지니어링은 여전히 우리의 정신 모델과 이해관계자와의 강한 관계를 필요로 합니다. 우리가 엔지니어링 작업을 하는 한, 이 접근 방식은 계속해서 중요할 것입니다.
행복한 엔지니어링!