신규 입사자의 전략적인 온보딩(with. Frontend)
익숙한 환경을 벗어나 취직이나 이직, 전직 등 다음 목적지를 향하다 보면 넓은 바다를 건너 미지의 대륙을 발견하는 듯한 기대와 열정을 느낄 수 있습니다. 모든 것이 두렵고 불안하지만 그만큼 흥미롭죠. 새로운 장소, 새로운 사람들과의 만남은 삶을 성장시키고 정신을 성숙하게 만드니까요.
신규 입사자로 돌아갈 때마다 저는 많은 생각에 도통 잠을 자질 못했습니다. 여러분들도 혹시, 이런 생각 하셨나요?
“앞으로 어떻게 해야하지… 일에 익숙해지지 못하면 어쩌나…”
새로운 환경에 놓인 우리는 나의 역할에 효과적으로 적응하기 위한 최소한의 준비와 전략이 필요합니다. 때로는 어렵고, 복잡하며 힘들지만 이를 통해 인정 받고 영향력을 발휘하거나 부드럽게 녹아들 수 있으므로 충분히 시도할만한 가치가 있죠.
이 글은 더 효과적으로, 더 빠르게 적응하는 저만의 전략을 설명합니다. 부디 도전을 목전에 둔 당신이 조금이나마 도움이 되면 좋겠습니다.
구성원들에게 인사하기
먼저 이걸 기억해주세요.
많은 인사, 많은 커피, 많은 대화.
여러분은 신규 입사자입니다. 새로운 환경의 목표는 무엇이며 이를 달성하기 위해 어떻게 움직이는지 아직 몰라요. 분위기도, 사람이나 업무도 모두 낯섭니다. 그런 상황에서 흔들리지 않고 직무 역량을 발휘하여 ‘잘’ 하는 것은 대단한 것이지만, 그렇게하지 못해도 전혀 잘못된 것이 아닙니다.
신규 입사자가 목숨 걸고 자신의 가치를 증명해야 하는 상황은 보통 없습니다. 오히려 실수해도 몰랐기 때문에, 해보지 않았기 때문에 이해 받을 수 있죠. 노력하는 자세를 주변에서 좋게 볼 순 있으나 그것만이 여러분의 가치를 증명하는 수단이 아님을 상기하면 좋겠습니다.
부담감을 조금 내려두세요. 신규 입사자를 포함한 모두가 컬처핏(Culture Fit, 기업 문화에 잘 맞는지를 평가하는 것)을 통해 핵심적인 가치나 방향성과 적합하다고 판단 된 사람들입니다. 그렇다면 “내가 이런 말을 해서 이상하다고 생각하면 어떻게 하지?” 와 같이 불안해하지 않고 이야기해도 돼요.
내가 속한 직군에 묶이는 것이 아니라 다양한 직군의 구성원과 편안하게 커피를 마시며(식사도 좋습니다) 담소를 나누다보면 사람들, 사건들 뿐만 아니라 팀이 무엇을 잘하고, 어떤 문제가 있으며, 어떻게 나아갔으면 좋겠는지 파악할 수 있습니다.
입사 첫 날, 나라는 사람을 더 많이 보여주기 위해서 이곳저곳 기웃기웃하고 최대한 인사를 먼저 건네려고 노력해보면 어떨까요?
“인사는 돈이 들지 않는 투자입니다.”
온보딩 기간 만큼은 많은 사람들과 대화하고 여러 팀의 환경, 구성원들의 상황을 듣는 것을 강하게 추천합니다. 억지로 만들거나 공감대가 맞아 생성되는 신뢰랑은 다르게, 팀 내에서 장기적인 인정과 신뢰를 이끌어내었던 것 같습니다.
만약 사람들과 이야기하는 게 부담된다면 문서나 회의록, 코드를 천천히 살펴보세요. 어떤 내용이 오갔고 무슨 목적으로 이런 맥락이 생겼는지 책을 읽듯 말입니다. 단, 궁금한 사항이 생긴다면 꼭 질문해야 합니다. 질문은 절대 창피한 행위가 아니며, 여러분의 역량이 폄하되지 않습니다. 질문을 통해 성장하고, 더 이해하고, 상대방의 의견을 들으며 “또 이런 시각도 있구나.” 하며 차츰 팀의 문화와 분위기에 감화될 수 있으니까요.
아이디어를 찾고 고민해보기
구성원들과 친해져서 얼굴도, 이름도 기억했다면 이제 업무에 깊이 파고들 차례입니다. 어떻게 하면 될까요?
신규 입사자는 가장 Fresh한 시각과 아이디어를 갖고 있습니다. 기존 구성원들과 다른 배경, 경험이 있어 팀을 새롭게 바라볼 수 있고, 놓칠 수 있는 부분이나 새로운 해결책을 발견할 수 있어요. 또한 팀에 대한 사전적인 편견이 없을 가능성이 높죠. 있는 그대로 보고 느끼기 때문에, 현재 시스템이나 프로세스에 대한 건설적이고 진솔한 피드백을 제공할 수 있습니다.
우선적으로 개선했으면 하는 부분을 적어봅시다. 만약 개발 코드가 엉망이라면… “코드가 이게 뭐야.” 같은 짧고 개인적인 소감이 아니라 이렇게 정리해보는 거에요.
“현재의 코드는 여러 문제가 있다. A라는 코드가 중복해서 나타나고, 상호 참조되는 의존성이 있으며 관리되지 않는 패키지로 인해 빌드 속도가 과도하게 느리다. 우리가 만약 상호 참조 의존 관계를 끊어내고, 중복 코드를 하나로 통일한 뒤 사용하지 않는 패키지는 제거하거나 통합한다면 빌드 속도가 크게 개선되어 제품팀의 실행 속도가 더 빨라질 것이다.”
전자와 후자의 차이라면 ‘다른 구성원을 설득할 수 있는가’ 입니다. 구체적인 예시, 논거를 토대로 이러한 문제가 있는데 이 문제는 앞으로의 실행에 큰 장애물이 될 것이니 우리는 이걸 해결해야 한다를 말했을 때, 구성원은 대부분 고개를 끄덕일 거에요.
자, 그럼 문제를 찾아내기 위해서 어떻게 해야 할까요? 이를 설명하기 전에 접근 방식을 하나 짚고 넘어가려고 합니다.
저는 대부분의 문제에 직면할 때 하향식 접근 방법(Top-Down Approach)과 상향식 접근 방법(Bottom-Up Approach)을 고려합니다. “더 효과적으로 적응하기” 위해서 우리의 언어를 일치시킬 필요가 있을 것 같네요. 상/하향식 접근 방법은 다양한 영역에서 그들만의 언어로 해석됩니다. 따라서, 여러분이 이 원칙을 몰라도 몸소 실천하고 있을 수 있습니다.
#하향식 접근 방식은 가장 큰 구조부터 해석해서 시스템적으로 이해하고 분해해 나가는 방법으로, 다음과 같은 장점이 있습니다.
- 시스템의 전체적인 개요를 파악하고 구조를 설계하는 데 도움이 됩니다.
- 고차원의 목표를 설정하고 계획을 수립하는 데 용이합니다.
- 비즈니스 목표와 요구사항을 고려하여 설계될 수 있습니다.
단일 컴포넌트 이전에 프로젝트 구조(인프라, 기술 스택 구성)를 미리 계획하여 정확하고 효율적으로 설계하는데 도움이 되는 접근 방식입니다.
#상향식 접근 방식은 작은 부분부터 출발하여 세부 구조를 이해하고 구축해 나가는 방법으로, 다음과 같은 장점이 있습니다.
- 가장 작은 부분부터 접근하므로 구조에 대해 깊게 이해할 수 있습니다.
- 가장 작은 분의 문제를 해결하거나 개선하면서 구체적인 해결책을 제시하고, 실질적인 결과물을 만들어 낼 수 있습니다.
일반적으로 함수 또는 모듈 단위의 작업을 시작하여 전체 시스템을 구축할 때 사용하는 접근 방식이죠. 아토믹 디자인 설계(Atomic Design System) 같은 느낌이라고 하면 잘 와 닿을 것 같습니다.
두 접근 방식을 적절히 활용하여 문제를 해결하는 게 효과적이라는 걸 명심하면 좋겠습니다. 이 장에서는 복잡하게 다루지 않고, 프론트엔드 개발자가 더 빠르게 적응하는 것에 초점을 맞추어 설명을 해볼게요.
프론트엔드 프로젝트를 하향식으로 분석하기
- 서비스 회사들은 주로 인기 있는 웹 프레임워크를 채택합니다. 그렇지 않을 경우에는 사이드 템플릿 엔진을 통해 클라이언트를 구현합니다. 어떤 도구를 사용하는지 확인하고, 각 프레임워크에 맞는 Best-Practice(Github Search Result), Boilerplate(Github Search Result)를 찾아보세요. 다양한 템플릿 코드와 구조의 차이가 있다면, 이러한 폴더 구조를 채택한 이유를 질문하세요. 프론트엔드 팀원들도 이 구조의 의도를 명확히 인지하지 못한다면, 이 구조가 작성될 때의 맥락이 끊겼다고 볼 수 있으며 개선할 여지가 있다고 생각할 수 있습니다.
- 여러 프로젝트 코드가 존재하거나, 외부 라이브러리(npm 또는 yarn)로 배포된 경우 package.json 파일의 의존성 목록을 확인하여 프로젝트 간 의존 관계를 분석하세요. 의존 관계는 단방향으로 유지하는 것이 가장 바람직한데, 상호 참조하거나 역참조가 발생하면 버전 종속성 등의 문제가 발생할 수 있기 때문입니다.
- 또한 package.json 내에서 중복되는 역할을 하는 라이브러리가 있는지 확인하세요. 예를 들어 axios와 ky 같은 비동기 통신 라이브러리 또는 formik과 react-hook-form 같은 유효성 검사 라이브러리가 함께 사용된다면 하나로 통합하는 것을 고려하세요. CSS-in-JS와 Zero-Runtime-CSS 등이 함께 사용될 경우도 동일합니다.
{
"dependencies": {
// 관련 코드(interceptor, constants, wrapping method 등) 찾아 공통화하기
"axios": "^0.21.1",
"ky": "^0.25.0",
// 사용자 입력 폼 컴포넌트를 비교하고 대체하기
"formik": "^3.2.9",
"react-hook-form": "^7.21.0",
// 컴포넌트가 어떻게 사용되는지 확인하고 스타일링 도구 통일하기
"emotion": "^11.1.4",
"tailwindcss": "^3.1.4"
}
}- 프로젝트 내의 개발자 경험(Developer eXperience)을 고려한 설정을 확인하세요. ESLint, StyleLint, Prettier, Lint-staged, husky 등이 파편화되어 있다면 프로젝트 레벨로 구성하는 것이 좋을지, Root 레벨에서 구성하는 것이 좋을 지 고민해보세요. 일반적으로 ESLint, StyleLint, Prettier 스크립트를 프로젝트에서 사용한다면 모든 의존성을 명시해줘야 합니다.
- 추가적으로 명확하지 않은 기준에 따라 rule이 관리된다면 개선할 수 있는 방안을 고민해보세요. 예를 들어 타입스크립트의 경우 any를 허용하거나, 개인적으로 사용하는 rule이 커밋되는 상황이 있습니다. 동일한 규칙이 파편화 되어 있다면 원인을 찾아 봅시다.
// 어디를 수정해야 할까요?
// root/package.json
{
"scripts": {
"lint:fix": "eslint . --fix",
"format": "prettier --write .",
"prepare": "husky install"
},
"devDependencies": {
"eslint": "^6.32.0",
"eslint-config-prettier": "^6.2.0",
"eslint-plugin-prettier": "^6.0.1",
"husky": "^7.0.1",
"lint-staged": "^12.0.0",
"prettier": "^2.5.0"
}
}
// root/apps/auth/package.json
{
"scripts": {
"lint:fix": "eslint . --fix",
"format": "prettier --write .",
},
"devDependencies": {
"eslint": "^7.1.0",
"eslint-config-prettier": "^8.3.0",
"eslint-plugin-prettier": "^4.0.0",
"husky": "^7.0.1",
"lint-staged": "^12.0.0",
"prettier": "^3.5.0"
}
}- 프로젝트의 용량과 파일 개수를 파악하는 것도 좋습니다. 의존성을 설치하지 않은 상태에서 프로젝트의 용량이 많다면(yarn berry PnP는 제외), 정적 리소스를 프로젝트 내에서 관리하지 않는지 확인하세요. 정적 리소스는 CDN을 사용하거나 내부 서버를 구축하여 사용하는 것이 좋습니다.
- 프로젝트 구조의 전반적인 상황을 파악한 뒤, 프로젝트를 개발 환경에서 실행해보세요. 프로젝트 코드가 어떻게 빌드되고 실행되는지, 앱의 진입점(Vite-React-App의 경우 main.tsx)이 어디인지, 어떤 코드가 앱 전반에서 중요한 역할을 하는지 확인하세요.
- PR 및 코드 리뷰, Label과 Assignee 규칙 등을 확인하세요. 더 나은 안정성과 생산성을 위한 구현 가이드가 있는지 확인하고, 이에 맞게 리뷰를 진행하고 개선점을 제안하세요.
- 현재 프로젝트에 연관된 외부 계정이 있는지 확인하세요. 데이터 센터, Private Repository, NPM 등의 계정을 확인하고, 퇴사한 인원이나 더 이상 필요하지 않은 계정은 삭제 요청하세요.
- 배포 프로세스를 확인하세요. 어떤 플랫폼을 사용하는지, 마지막으로 수정된 일자의 기준은 언제인지, 사용 중인 라이브러리의 stable한 최신 버전이 무엇인지 비교한 뒤, 릴리즈 노트를 확인하고 충분한 테스트를 거쳐 개선 가능한 부분을 적용하세요.
- 프로젝트 코드 이외에도 Figma, Zeppelin 등에서 디자이너가 작업한 디자인과 실제 서비스를 비교하면서 컴포넌트의 구성, 위치, 역할 등을 확인하세요. 이렇게 디자이너와 협업하면 추후 서비스 개발 시 큰 도움이 됩니다.
- Sentry, Datadog, Kibana 등의 에러 모니터링 도구를 확인하여 에러 발생 빈도와 가장 빈번하게 발생하는 에러를 중점적으로 조사하세요. 브라우저 스펙에 따라 해결 가능한 가벼운 문제를 찾아 개선하면 도움이 됩니다.
- 데이터 적재 또는 A/B 테스트가 있다면, 사용 중인 데이터 적재 플랫폼으로 들어가서 중요한 지표를 확인하거나 가이드를 요청하세요. 제품팀이나 세일즈팀이 어떻게 일하는지 이해하고, 제품을 어떻게 발전시킬 수 있는지 시각적으로 공감할 수 있는 기회입니다.
프론트엔드 프로젝트를 상향식으로 분석하기
- 코드의 양이나 코드 히스토리가 많을 경우 프로젝트 분석은 쉽지 않습니다. 이때는 분석 범위를 좁히기 위해 가장 ‘많이 사용될 것으로 예상되는 폴더’에 중점을 두어야 합니다. 대부분의 경우 이러한 폴더들은 core, feature, pages, components, common 등의 네이밍을 사용하며, root 또는 1-depth에 위치하기 때문에 해당 폴더의 코드를 천천히 분석해보는 것이 중요합니다.
- 만약 import 경로가 다르지만 이름이 같은 변수나 함수가 있다면 에디터/IDE의 도움을 받아 검색해보세요. 중복된 이름의 파일이 여러 개 있을 경우 제거하거나 통합할 수 있는지 확인하고, 작은 단위부터 개선해나가야 합니다.
- 자주 사용되는 코드를 그룹화하고 역할을 부여할 수 있는지 확인합니다. 모노레포를 사용하거나 프로젝트 코드가 분산되어 있다면, 공통으로 사용되는 코드나 컴포넌트를 묶어 배포해보세요. 이를 통해 버전을 효과적으로 제어할 수 있고, 사용자에게 일관된 경험을 제공할 수 있습니다.
- 가장 효과적인 방법은 실제 개발 구성원들의 의견을 듣는 것입니다. 어떤 문제가 있는지, 어떤 부분을 개선하면 좋을지를 공개적인 자리에서 질문하고 다양한 의견을 수렴합니다. 그리고 문제의 크기가 작은 것부터 차근차근 해결해나가는 것이 좋습니다. 익숙해지면 점진적으로 개선해보세요.
- 코드를 하나씩 살펴보면서 클린 코드나 클린 아키텍처 관점에서, 또는 여러 개발 원칙(SOLID, KISS, YAGNI, DRY, LoD 등)을 잘 준수했는지 직접 리뷰하거나, 페어 프로그래밍 또는 몹 프로그래밍을 통해 다른 개발자와 함께 리뷰하는 것도 좋은 방법입니다.
여기까지, 어떻게 새로운 환경에 빠르게 적응하고 프로젝트를 효과적으로 분석할 수 있을지 저만의 방법을 기록한 글이었습니다. 길게 작성되고 모두 주관적인 내용이지만 이 글을 보시는 당신이 조금이나마 도움이 되었으면 좋겠습니다.
29CM의 경우 문제 식별, 해결, 업무 및 협업 방식과 평가까지 29CM WAY가 강조되기 때문에 팀의 성향을 빠르게 파악하여 다음 스텝을 생각할 수 있습니다. 예를 들어 어떻게 하면 더 ‘빠른 실행’일지, UI/UX적으로 ‘고객 집중’일지 고민할 수 있죠.
구성원들과 함께 문제를 발굴하고 해결해 나가는 과정을 함께하면 개인의 성장과 더불어 새로운 환경에도 쉽고 빠르게 적응할 수 있을 겁니다.
여러분은 어떤 구성원이 되고 싶으신가요?
29CM CAREER
함께할 동료를 찾습니다.
29CM는 ‘고객의 더 나은 선택을 돕는다’라는 미션으로 출발했습니다. 우리는 우리만의 방식으로 콘텐츠를 제공하며, 브랜드와 고객 모두에게 대체 불가능한 커머스 플랫폼을 만들어가고 있습니다. 이 미션을 이루기 위해 우리는 흥미로우면서도 복잡한 문제들을 해결하고 있습니다. 만약 우리와 함께 이 문제들을 해결해 보고 싶다면, 주저하지 말고 29CM에 합류하세요!
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr/
📌채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해 주세요!
