소프트웨어 엔지니어 가이드북

기술 기업의 유형

빅테크, 중대형 기술 기업, 스케일업, 유니콘, 스타트업, 기술 부서가 있는 비기술 전통 기업, 기술 중심의 전통 기업, 벤처 투자를 받지 않은 소규모 기업, 공공부문, 비영리 단체, 컨설팅, 아웃소싱 기업 및 개발 에이전시, 학계 및 연구소

 

개발 기여자 직군 레벨 순서 : 소프트웨어 엔지니어 -> 시니어 엔지니어 -> 스태프/수석 엔지니어

매니저 직군 레벨 순서 : 매니저(스태프/수석 엔지니어와 동급)->디렉터(이사)->엔지니어링 부문 부사장->CTO

 

보상 티어

티어 1 : 지역 시장 기업

티어 2 : 지역 시장 상위 기업

티어 3 : 권역/글로벌 시장 상위 기업

 

일을 잘해라, 중요 일을 맡아라, 내가 한 일을 사람들에게 알려라, 작업 일지를 작성해라

 

피드백 시 : 상황과 그 영향에 초점을 맞춰 관찰, 이렇게 하라고 말하지 말기, 본인이 스스로 해결책을 찾도록, 부정적/건설적인 피드백은 직접 대면해 전달하자. 처음부터 상대방의 편임을 분명히 하자. 피드백은 내 시점의 관찰일 뿐, 무시해도 좋다는 점을 분명히 한다. 토론을 긍정적으로 마무리하자. 

 

매니저를 아군으로 만드는 법 : 정기적인 1:1 미팅을 갖자. 매니저가 알 거라 짐작하지 말고 모두 말하자. 매니저의 목표도 이해하자. 합의된 내용을 완수하고, 못했다면 상황을 공유하자. 업무 성과를 인정받자.

 

페이스 조절 하는 법 : 

스트레칭 - 새로운 것을 빠르게 배워 빠르게 적용하는 업무를 말함. 다만, 번아웃이라는 역효과가 나타날 수 있음. 

실행 - 일반적인 업무를 말함. 가장 잘 처리하는 방법은 자신이 잘하는 언어/프레임워크로 합리적인 일정에서 프로젝트를 코딩하는 것.

관성 - 자신의 능력보다 더 적은 양과 낮은 품질의 작업을 의미. 힘든 프로젝트를 마친 후 일시적으로 단기간 휴식을 취하거나, 다른 일을 따라잡거나, 정신적인 휴식을 취하는 데 좋다. 다만, 길어지면 좋지 않다.

위 세 가지를 적절히 섞어가 장기적인 성장을 위해 노력하고 번아웃을 방지하자.

 

성과 평가 :

빠른 준비 : 상황 파악 및 목표 설정 - 가장 중요한 요소의 파악과 이해, 

성과 평가에 대한 중요한 세부 정보를 수집하자. 최종 결정권자, 성과 평가 주체, 평가 시점, 공정한 성과 평가를 위한 조언 등

성과 기록하기 - 격주로 성과를 기록하자, 완료한 프로젝트를 정리해두고, 칭찬을 스크린숏으로 찍어두는 등 성과를 입증할 수 있는 증거를 남기자.

매니저와 진행 상황을 공유하자. 매니저가 내가 한 일을 잘 모를 수도 있다. 

다른 사람을 돕자. 코드 리뷰, 피드백 제공, 자료 조사의 지원, 다른 팀의 어려운 문제 해결 등 도움의 손길을 내밀자.

다른 사람을 도우면 흔적을 남기자. 적어도 매니저에게는 눈에 띄도록 하자.

가끔씩 구체적인 피드백을 요청하자. 상황별로 유용하게 받자, 회의 진행이나 운영 중 장애 해결, 큰 청중 앞에서의 프레젠테이션, 새로운 프로젝트 제안 등 

자기 평가서를 미리 작성해서 매니저에게 전달하자. 무엇을 어떻게, 기존 목표와 결과, 역량 증명, 동료의 피드백, 칭찬과 긍정적인 피드백 등을 요약 문서로 정리한다.

매니저의 편견이 성과 평가에 영향을 미칠 수 있다. 성과 평가 기간을 거치고 나면 매니저가 어느 부류에 속하는지 파악할 수 있기 때문에 이를 보고 그 이후의 계획을 또 세우자.

수십 년에 걸친 커리어의 관점에서 개별적인 성과 평가는 큰 의미를 가지지 않는다. 물론 중요하긴 하지만 지나치게 집착하지 말고 장기적인 관점을 유지하자.

 

승진은 어떻게 결정되는가?

다음 직급의 기대치에 부합하는 성과를 내는 사람, 영향력이 있는 사람, 예산 증액이 가능한 경우가 있다.

승진 절차의 유형으로는

비공식적 승진 절차, 약식 승진 절차, 엄격한 승진 절차 등이 있다. 

 

터미널 레벨은 여러 기술에서 흔히 사용하는 개념이다. 이는 기업이 소프트웨어 엔지니어가 도달하기를 기대하는 직급으로, 일종의 상한선이다. 터미널 레벨이 있는 회사는 '승진하지 못하면 떠나는' 문화가 있어 엔지니어가 해당 직급에 맞는 능력을 갖추도록 밀어붙인다. 터미널 레벨은 보통 시니어 엔지니어 직급으로 설정된다. 터미널 레벨에 오른 엔지니어에게 바라는 사항은 다음과 같다.

1. 자율적인 업무 처리

2. 스스로의 한계를 극복

3. 팀의 성공을 위한 노력, 후배 팀원에 대한 지원 및 멘토링

 

빅테크에서의 승진

빅테크는 기본급, 보너스, 주식 보상에 대한 관점이 다르다.

성과에 따른 보상이 일반적이다. 최고 성과를 낸 직원들은 종종 평균 보너스의 5~10배에 달하는 거액의 보너스를 받는다.

기업마다 승진 기준이 있지만, 대부분 최소 12개월 이상 해당 직책에 재직해야 하며, 일부 회사는 최고 성과자만 승진 후보로 추천하도록 규정하고 있다.

낮은 직급에서 최고 성과를 내는 직원이 다음 직급에서 평균 성과자보다 더 많은 보수를 받기도 한다. 

초고속 성장 기업에는 승진의 기회가 많다. 다만 회사가 성숙해질수록 이런 기회는 줄어들고, 문제도 복잡해지며, 걸리는 시간도 길어진다.

빅테크에서 승진 및 성과 평가가 영향력 중심적으로 진행되면 승진 지향 개발이라는 불행한 결과를 초래한다. 

 

승진을 위한 조언

현실적으로 생각하자. 기대 이상의 성과를 거두었는가? 그렇지 않았다면 승진 가능성이 거의 없다.

승진 절차를 이해하자. 누가 추천하고, 누가 결정하며, 기준은 무엇인지

자기 평가를 하자.

동료로부터 피드백을 받자. 본인의 개선점 등에 대해서 말이다.

다음 직급의 멘토를 찾자. 1:1로 만나서 조언, 피드백을 요청하자.

 

업무 정리하기

업무를 잘 수행하는 정도로는 충분하지 않으며, 다른 사람과 협력하고 많은 사람에게 내가 하는 업무 내용을 알려야 한다.

코드, 디자인 문서, 회고, 코드 리뷰 같은 결과물을 만들면서 매일 업무를 완수하자.

대부분의 조직에서는 직급이 높아질수록 업무의 초점은 생산이 아닌 정리와 게시로 옮겨간다. 

 

승진에 집착하지 말자. 승진만이 유일한 관심사로 보이지 않도록 하자. 

본인보다 한 단계 낮은 사람을 멘토링해보자. 일부 팀원에게 승진을 위해 노력하고 있다는 사실을 공유하자. 도와줄 가능성이 높다.

 

제품 지향적 엔지니어 : 

제품 아이디어와 의견을 제시하는 적극성 - 주어진 사양을 구현하는 데 만족하지 않고 대안을 생각하고 매니저에게 제시한다.

비즈니스, 사용자 행동 및 관련 데이터에 대한 관심 - 사용자가 제품에 대해 어떻게 느끼고 사용하는지 공감한다.

호기심과 깊은 관심 - 왜 이기능은 만들면서 다른 기능은 만들지 않는가? 같은 질문을 던진다.

엔지니어가 아닌 다른 분야의 동료들과 이야기를 나눈다. 그들이 하는 일과 이유를 알기를 좋아한다.

빠른 제품 검증 주기 - 프로덕션이 적용되기 전에 창의적인 방법으로 조기 피드백을 받는다.

제품에 대한 주인의식 - 시작과 끝을 모든 영역에 깊게 관여한다.

 

제품 지향적 엔지니어가 되는 법 :

비즈니스 모델은 무엇이고, 수익은 어떻게 창출되며, 가장 수익성이 높고 가장 빠르게 확장되는 분야는 어디이며 그 이유는 무엇인가 등의 기업 성공 방법과 이유를 이해하자.

사용자 조사, 고객 지원 및 관련 활동에 참여하자. 

 

플랫폼 팀 예시 :

스케일업의 인프라 팀 - 사내 플랫폼에서 다른 팀에 컴퓨팅 및 스토리지 리소스를 제공하거나 팀이 클라우드 환경을 이용할 수 있도록 지원한다.

빅테크 기업의 결제 플랫폼 팀 - 결제 기능을 제품에 통합할 수 있는 내부 SDK를 제공한다. 이 결제 플랫폼을 결제 제공업체와 연동해 다른 내부 팀에서는 별도의 작업을 수행할 필요가 없다.

대부분 기업의 CI/CD팀 - 지속적 통합, 배포를 주관하고 관리. 이들은 자동화된 테스트, 정적 소프트웨어 분석 및 기타 소프트웨어 품질을 높이기 위한 개발 방법론을 추진하고 피드백을 제공한다.

 

플랫폼 팀에서 일할 때의 장점 : 

인프라 플랫폼 팀은 복잡한 엔지니어링 과제가 쌓여 있지만 다른 장점이 많다.

매니저 없이 엔지니어가 모든 것을 운영하는 경우가 많아서 새로운 엔지니어링 아이디어를 도입하는 등 엔지니어링 자유도가 크다.

플랫폼 팀은 고객과 조금 더 멀리 떨어져 있기에 압박을 덜 받는다.

플랫폼 팀은 업무 특성상 시니어급 이상 엔지니어가 더 많다. 경험 많은 사람과 함께 일하기를 즐기는 엔지니어는 꿀이다.

 

단점 : 

제품 팀과 다르게 비즈니스 기여도를 정의하기 어렵다.

사용자와 멀어지는 것도 단점이다.

 

평시와 전시

평시 : 평화로운 시기란 기업이 핵심 시장에서 경쟁사 대비 큰 우위를 점하고 있어 시장이 성장하고 있는 시기

전시 : 기업이 임박한 생존 위협에 맞서 싸워야 함. 

 

전시 모드의 자세 :

완벽한 품질보다 충분히 좋은 품질로 신속하게 작업을 완료한다.

더 빨리 일하는 데 도움이 된다면 분쟁을 두려워하지 말자. 

내 편을 만드는 데 너무 신경 쓰지 말고 작업을 완료하는 데에만 집중하자.

잘해야만 직업을 잃지 않을 것처럼 일하자.

 

평시 모드의 자세 : 

고품질로 작업을 완료하자.

분쟁은 피하자.

협업 팀마다 내 편을 만들자

비즈니스에 도움이 되는 장기적인 계획에 집중하자.

느리고 꾸준한 페이스로는 너무 느려질 수 있으니 가끔씩 기어를 바꾸자.

평시에 업무에서 지루함을 느끼는 건 위험 신호다.

 

모드 전환 : 

창업 - 전시 모드

투자 유치 단계 - 전시 모드

투자 유치 후 - 잠시 평온한 시기

투자 유치 라운드 사이 - 모금액이 부족해지거나 경쟁자가 나타나면 다시 전쟁 시작

기업 공개 1년 전 - 전시 모드

기업 공개 이후 - IPO가 성공하고 주가가 상승하면 보통 평시로 전환한다.

상장 기업 단계 - 시간이 지남에 따라 좋은 성과를 내는 비즈니스는 평시 모드에서 운영하려는 경향이 강하다.

 

스케일업은 초기 단계를 지나 시장 확장에 주력하는 벤처 투자를 받은 스타트업을 말한다. 스케일업은 시리즈 B, C, D 이상의 자금 조달 단계에 있는 기업이지만 주식 시장에 상장되지 않아 주식이 공개적으로 거래되지 않은 기업이다. 보통 전시로 운영된다.

빠르게 성장하는 기업의 경우 재직 기간이 1년이 안 되는 직원이 50% 이상을 차지하는 경우가 많다.

이런 기업에서는 장기근속 엔지니어를 선호하는 경호가 있다.

많은 기업이 채용에는 많은 시간을 투자하지만 온보딩에는 상대적으로 적은 노력을 기울인다.

비용 센터보다 수익 센터에서 일해야 한다.

플랫폼 팀이 있는 경우는 거의 없고 제품 팀이 대부분의 작업을 수행한다.

스타트업은 직원을 해고할 가능성이 가장 높고 파산할 가능성도 가장 높다.

자율성을 최대한 활용하자. 대부분의 스타트업에서는 허락을 받지 않고 일을 처리한 후 나중에 용서를 구하는 경우가 많다.

창업자에게 내 업무를 이야기하자.

 

적극적으로 구직 활동을 할 때는 채용 공고를 검색하고 적어도 구인 메시지에 응답하는 등 프로세스에 적극적으로 임하자. 링크드인 프로필에 구직 중이라는 표시를 하고, 리크루터 및 기업 채용 담당자에게 새로운 일자리를 찾고 있음을 밝히고, 어떤 일자리를 원하는지 적절한 아이디어를 가지고 있어야 한다.

 

직급이 높을수록 근속 기간이 중요하다. 

그만두기 전에 무엇을 남기고 떠날지 생각하자. 

 

초기 심사 :

소프트 스킬은 리크루터나 채용 매니저와의 초기 대화에서 확인한다.

면접에 대한 의지 - 서류는 훌륭한 지원자라도 면접 과정에 대한 의지가 있을까? 그저 호기심으로 지원한 지원자는 면접에 의지가 없는 경우도 있다.

효율적인 이력서 작성하기 - 이력서의 목표는 면접 담당자가 지원자와 첫 통화를 하도록 설득하는 것이다. 자신의 경력을 자세히 설명하는 것이 목표가 아니다.

리쿠르터나 채용 매니저가 듣고 싶어 하는, 자신이 지원하는 직책과 관련된 경험을 강조해 작성한다.

같은 이력서를 모든 기업에 보내지 말고 지원하는 기업과 직책에 맞는 이력서를 따로 만들자. 대신 '마스터' 버전을 만들어서 매번 수정하는 편이 좋다.

한눈에 들어오는 템플릿을 사용하자. 리크루터나 채용 매니저가 이력서를 쉽게 볼 수 있어야 한다. 화려한 형식과 2열 레이아웃은 피하는 것이 좋다. 

결과, 영향력, 수치로 강조하자. 업무의 영향력을 숫자로 정의하는 것이 이상적이다. 가능한 한 구체적으로 성과를 제시하자.

 

기술 면접 : 

충분한 기술력을 갖추고 있는가? 핵심 기술 개념에 대한 최신 정보를 파악하고 있으며, 실무경험이 충분한가?

코딩에 대한 실무 경험이 충분한가. 지원자가 코딩에 얼마나 능숙한지는 검증하지 않고는 알기 어렵다. 코딩 과제를 진행해 이를 확인한다. 

자주 사용되는 몇 가지 방법 - 

대화형 코딩 면접 - 라이브, 화상 통화를 통해 소프트웨어 엔지니어인 면접관과 지원자가 대화하면서 즉석에서 코드를 작성해 문제를 해결

과제형 코딩 면접 - 비동기식 코딩 과제로, 지원자가 과제를 숙제처럼 제출한다. 시간 제한을 두는 경우도 있고 지원자가 소요 시간을 결정하기도 한다.

기타 평가 방식 - 일부 기업 면접관이 코딩 없이 기술 개념에 대해 질문하고 토론하는 동기식 면접을 선호한다. 지원자에게 기술적인 퀴즈를 풀게 하고, 지원자와 함께 디버깅 세션을 진행하기도 한다.

 

기술 면접 준비하는 법 :

가장 쉬운 방법은 리크루터에게 어떤 형식인지 준비 과정에 필요한 조언을 요청하는 것. 기술 면접을 위한 준비 자료를 보내줘 지원자가 대비할 수 있도록 한다.

챌린지가 어떻게 평가되는지 이해하자. 기능, 코드 품질, 테스트 중 무엇이 더 중요할까? 언어 선택이 중요한가? 평가 전에 이런 내용을 알아보자.

대화형 면접이라면 면접관에게 질문을 하자. 자신의 사고 과정을 공유하고 때때로 피드백을 구하면 긍정적으로 비칠 수 있다.

과제형 코딩 과제는 기한을 설정하자.

시간을 투자하기 전에 자세한 피드백이 제공되는지 확인한다. 시작하기 전 리크루터에게 불합격되더라도 서면으로 피드백을 받을 수 있는지 물어보자. 피드백받을 가능성이 높아진다.

 

현장 면접 : 

코딩 면접 - 지원자의 코딩 및 디버깅 능력을 검증한다. 알고리즘 면접이나 실제 코딩 과제를 해결하는 방식이다.

시스템 설계 면접 - 아키텍처 인터뷰라고도 한다. 엔지니어가 비즈니스 요구사항에 맞는 시스템을 처음부터 잘 설계할 수 있는지, 확장 문제에 어떻게 대응할 수 있는지 역량을 확인한다.

분야별 심층 면접 - 해당 직무 핵심 기술에 얼마나 능숙한지 파악한다. 예를 들어 백엔드 엔지니어 면접은 분산 시스템과 Go언어에 대한 지식을, iOS엔지니어 면접은 스위프트와 고급 모바일 애플리케이션 개발 주제에 대해 질문할 수 있다. 

채용 매니저 인터뷰 - 인성 면접이라고도 한다. 의지, 갈등처리, 어려운 상황 대처법, 기업의 핵심 가치를 알고 '기여할 수' 있는가 등을 확인한다. 

바 레이저 면접 - 아마존, 우버 같은 빅테크 기업에서만 실시하는 특별한 면접이다. 장기근속 엔지니어나 매니저가 주로 진행하며 지원자가 해당 지급의 기준을 높일지 여부를 판단한다. 대개 기술, 디자인, 행동, 문화 면접이 혼합된 형태로 진행한다.

기타 면접 유형 - 충분한 휴식을 취하고 차분한 마음으로 새로운 것을 배우기 위한 연습이라고 생각하는 것이 좋다.

 

스태프 또는 그 이상 직급의 경우, 면접 프로세스는 조금 더 맞춤형으로 진행된다. 도메인 분야 심층 면접(결제, 모바일 또는 분산 시스템과 같은 분야의 채용 시에는 지원자의 전문성을 검증하기 위해 거의 항상 진행한다), 프로덕트 매니저 면접(지원자가 제품 담당자들과 얼마나 잘 협력할 수 있는지 평가), 임원급 면접(바 레이저 면접이나 채용 매니저 면접 대신 진행한다), 2차 시스템 설계 면접(스태프 이상 직급 엔지니어가 진행)

 

새 직장 적응 :

계약서 사인 후 입사 기간이 길다면, 미래의 매니저에게 입사 전에 먼저 연락을 취해 뭘 준비해야 하는지 알아보자.

입사 초기부터 업무 일지/과시용 문서를 작성하자. 이는 온보딩 과정을 회고하는 데 도움이 되고, 매니저와의 1:1 미팅, 성과 검토 및 승진에 훌륭한 자료로 활용된다.

매주 일지를 쓰자. 처음 몇 달 동안, 매주 배운 것과 이해하지 못한 것을 세가지씩 적는다.

첫 달, 3개월, 6개월 동안의 목표를 명시해 매니저와 공유하자.

 

소규모 기업에서의 온보딩 :

가장 높은 직금의 사람을 가능한 한 일찍 만나보자.

일이 어떻게 돌아가는지 짐작하지 말고 물어보자. 

첫 주에 무언가를 완성하는 것을 목표로 삼자. 소규모 기업에선 막을 리 없다.

 

큰 기업으로 온보딩 :

지정해주지 않더라도 온보딩 버디를 구하자. 온보딩 버디는 업무에 적응하는 데 도움을 줄 준비가 되어 있는 팀원이어야 한다.

새로운 내용을 모두 기록하는 치트 시트 문서를 작성하자. 기업에서 사용하는 약어의 의미, 빌드 명령어, 주요 리소스에 대한 북마크 등을 정리하자.

기업의 기술 스택에 익숙해지자. 새로 사용하게 될 언어나 프레임워크를 익히자.

 

시니어급 이상의 직급으로 온보딩 :

같은 직급의 동료와 소통하자.

팀의 코드베이스에서 생산성을 높이고 이를 직접 사용해보는 것을 우선시하자.

현재 및 미래의 프로젝트와 팀의 우선순위를 이해하자. 

장애 관련 회고 문서를 찾아 훑어봄으로써 문제 영역을 파악하고, 유사한 문제가 발생했을 때 당황하지 않도록 하자.

알아두면 도움될 엔지니어링 팀 목록을 작성하자.

 

스태프 이상의 역할로 온보딩 :

먼저 팀원들을 만나 친근한 인상을 남기자

같은 직급의 동료 엔지니어들도 일찍 만나자.

제품 담당자들과 시간을 보내 현재 고민과 계획을 파악한다.

 

2부

초급 소프트웨어 개발자에 대한 일반적인 기대치

범위 - 단위 작업 또는 소규모 프로젝트

지침 - 몇 가지 지침에 따라 작동

업무 완수하기 - 막혔을 때 도움 요청

주도권 잡기 - 항상 예상되는 것은 아니고, 한다면 보너스

소프트웨어 개발 - 팀 개발 관행에 따름

소프트웨어 아키텍처 - 팀 관행을 따르고 디자인에 대한 피드백을 구함

엔지니어링 모범 사례 - 현장의 모범을 따름

협업 - 팀의 다른 개발자

멘토링 - 멘토링을 요청

학습 - 배움에 대한 열망

일반적인 업계 경력 - 0년 - 5년

 

가장 중요한 업무에 집중하기 

이번 주에 단 한 가지 일만 할 수 있다면 뭘 할 수 있을지에 대답

항상 최우선 과제를 완료하는 습관 만들기 

거절하는 법 배우기 - 가장 쉬운 방법은 "네, 저도 도와드리고 싶지만..."으로 시작하는 것

막힌 부분 풀기 :

막힌 상태 인식하기 - 30분 이상(길어야 1시간) 이 지나도 의미 있는 진전이 없다면 스스로 막힌 상태임을 인정해야 한다.

막힌 상태 뚫는 법 - 다른 사람에게 도움을 요청하는 것이다. 하지만 도움을 청할 사람이 없다면 러버덕을 이용한다. 러버덕은 고무 오리인데 물건 또는 자신에게 문제를 설명하고, 이미 시도해 본 접근 방식을 설명한다. 문제를 말로 풀어나가다 보면 때때로 새로운 해결책이 떠오른다. 또한 종이에 문제를 스케치하여 시각화하면 다른 방법이 떠오르기도 한다. 막힌 기술에 대한 공식 문서와 참고 자료를 읽는다. 설계되지 않은 방식으로 사용하고 있지는 않은지 확인한다. AI 도구를 이용한다. 이미 시도한 해결 방법을 입력 후 AI 도구가 제안하는 방식을 확인하자. 온라인에서 비슷한 문제를 검색한다. 사람에 따라 같은 문제에 대해 다른 용어를 사용할 수 있으므로... 또한 프로그래밍 Q&A 사이트에 질문하는 것도 방법이고, 머리를 비울 수도 있다. 최종 방법으로는 처음부터 다시 시작하거나 모든 변경 사항을 취소한다.

지원을 받아 문제 해결하기

다른 사람을 기다리느라 진행하지 못할 때도 있다. 

 

원만하게 상대의 상급자에게 보고하는 법 :

다른 사람이 진행을 막고 있다면 상급자에게 보고할 필요가 있다. 

여기서 상급자란 요청에 응답하지 않는 사람의 매니저나 그 위 직급을 말한다.

이런 보고는 업무 처리 속도를 높이지만, 부주의하게 사용하면 관계를 해칠 수도 있다.

상대의 상급자에게 보고해 문제를 해결할 때는 개인적인 관계를 해치지 말자. 

상급자를 통한 소통이 필요한 상황의 접근법

1. 설명하기 : 먼저 도움이 필요한 이유를 설명하고 그 중요성을 이해할 정보를 제시

2. 물어보기 : 아무런 변동이 없다면 이유를 확인하자.

3. 경고하기 : 그래도 아무일도 일어나지 않으면 상급자에게 보고할 가능성을 언급한다.

4. 상급자에게 보고하기 : 그래도 아무 일도 일어나지 않으면 내 매니저나 상대 매니저, 혹은 둘 모두에게 작업 진행을 요청한다.

 

막혔을 때 실전 대응법

계획 단계

해야할 일이 명확하지 않음, 누구에게 문의할지 모름

구현 단계

언어나 프레임워크를 처음 사용함, 오류 메시지를 이해할 수 없고, 검색해도 찾을 수 없음, 도구, 프레임워크, 코드 구조 등이 어떻게 작동하는지 이해가 안 됨, 빌드 문제, 다른 팀/서비스에 대한 종속성 문제, 접근 권한 문제, 문서에 오해의 소지가 있음, 시스템 장애

테스팅

테스트가 불규칙적으로 실패함, 재현할 데이터가 없음, 테스트가 너무 느림

코드 리뷰

코드 리뷰 대기, 병합 충돌

배포

접근 권한 문제, 배포가 너무 느림

운영 시스템 및 유지 관리

재현할 수 없는 버그, 시스템 문제를 디버깅할 로그가 충분하지 않음, 시스템 장애

 

작은 단위로 작업 쪼개기

스토리, 작업, 하위 작업에 대해 생각하기

작업을 세분화하다 보면 헤매기 쉽다. 

출시를 더 빠르게 하는 작업 우선순위 지정

작업 추가, 제거, 변경을 두려워하지 말자 

 

작업 소요 시간 추정

'얼마나 걸릴까요?' 많은 소프트웨어 개발자가 두려워하는 질문이다. 작업 시간 추정을 잘하는 유일한 방법은 해보는 것이다.

이전에 수행한 작업은 가장 쉽게 추정이 가능하다. 

이전에 수행해보지 않았던 작업은 보통 7가지 범주로 나누고 추정한다.

1. 동료의 작업과 유사한 작업 : 이들과 상의해서 추정하자. 처음 시도하는 작업인 만큼 시간을 더 길게 잡는 편이 좋다.

2. 리팩터링 : 타임박스 작업을 적용할 수도 있다. 타임박싱이란 작업에 기간을 할당하고 그 기간 동안만 작업하고 그 이상은 하지 않는 것이다.

3. 잘 아는 기술을 사용하는 작업

4. 잘 아는 기술로 잘 모르는 시스템을 통합 : 먼저 프로토타입을 제작하고 다른 시스템이나 API를 테스트하는 간단한 개념 증명을 한 후 추정, 최악의 경우를 감안한 추정치도 제공하자. 

5. 잘 모르는 성숙도 높은 기술로 간단한 결과물을 구축 : 해당 기술을 사용해본 엔지니어에게 문의

6. 잘 모르는 새로운 기술로 간단한 결과물을 구축 : 새로운 기술로 PoC를 수행한 다음, 그 기술을 사용할 수 있다는 확신이 든 뒤 추정하길 바람

7. 익숙하지 않은 신기술로 복잡한 결과물을 구축하고 잘 모르는 시스템과 통합 : 프로토타이핑, 작업의 세분화를 통해 정복하자.

 

멘토 찾기 :

여기서 멘토란 나에게 가르침을 줄 여러 명의 그룹으로 생각하자.

직장 내에서 의지할 수 있는 멘토를 찾는 것을 목표로 하자.

 

멘토로 구성된 기술 부족 : 

사람 한 명에게서만 배우기 보다는 다양한 멘토로 구성된 부족에 배우는 것이 훨씬 좋다고 주장한다. 친밀감이 높은 전담멘토를 구하는 것도 좋음. 이전에 교류한 적이 있거나 자신이 존경하고 자신의 목표와 일치하는 일을 하는 사람에게 연락해라

일시적인 1:1 미팅으로 멘토해도 좋음

인터넷 멘토도 좋음

 

선의 통장 : 

모든 사람에게는 선의 통장이 있다 - 다른 사람을 도우면 선의 통장 잔고가 늘어난다. 도움을 청하면 그 잔고는 줄어든다. 선의 통장 잔고를 너무 빨리 소진하지 말자. 도움을 요청하기 전에 가장 일반적인 디버깅 및 정보 수집을 수행하자. 팀에서 관리하는 코드로 소스 코드 기록과 최근 커밋 기록을 살펴보자. 

선의 통장 잔고를 정기적으로 채워 넣자 - 다른 사람에게 도울 의지가 있음을 알리자. 함께 앉아 문제 해결을 돕자. 전문 지식을 공유해 다른 사람의 업무를 더 쉽게 만들어주자. 누군가의 도움으로 문제를 해결했다면, 팀 내에서 공개적으로 감사를 표하자.

가능하면 혼자 작업하지 않기 - 프로젝트 버디를 배정하기로 결정해라. 매일 함께 체크인하고, 계획을 검토하고, 코드 리뷰를 하는 등의 작업을 함께 할 수 있다. 

 

솔선 수범하라 :

불분명한 사항을 문서화한다 - 문서를 팀에 공유하자. 향후 팀원이나 신규 입사자에게도 도움이 될 수 있다.

조사에 자원한다

팀에서 사용할 흥미로운 도구나 프레임워크를 조사한다 - 이걸 사용하면 안 된다는 결론이 나와도 팀원들은 당신이 자신의 역할을 넘어 더 많은 것을 배우기 위해 모험하고 있다는 것을 알게 될 것이다.

매니저와 예정된 프로젝트에 대한 이야기를 나눈다.

가장 중요한 점은 할당된 업무를 먼저 끝낸다는 전제하에 새로운 일을 맡아야 다른 사람이 여러분을 생산적인 사람으로 본다. 

 

유능한 소프트웨어 엔지니어로 성장하려면 매일 코딩을 해야 한다. (코드 카타를 이용)

코드를 많이 읽자. 사용 중인 언어와 유사한 언어로 이루어진 오픈소스 코드를 읽는 것도 훌륭한 방법이다.

자동화된 테스트, 지속적 통합(CI), 지속적 배포(CD) 같은 프로세스를 누락하지 말자

DRY원칙을 잘 지키자. (Don't repeat yourself라는 뜻). 코드를 복사해 붙여 넣지 말자. 대신, 재사용할 필요가 있다면 단일 책임 원칙을 따르도록 코드를 리팩터링 하자.

주석에는 방법이 아닌 이유를 설명하자. 그 코드가 없었다면 정상적이지 않은 코드 경로를 따라가 시스템이 다운되는 이유 같은 정보가 포함될 수 있다.

프로그래밍 언어를 완전히 익힌다는 것은 어느 수준일까? 메모리 관리와 가비지 컬렉션이 어떻게 작동하는지, 코드가 어떻게 컴파일되는지, 성능에 영향을 주는 요소는 무엇인지 등 언어의 내부를 더 깊이 들여다보고 이해할 수 있는 수준이다.

 

숙련된 개발자의 디버깅을 살펴보자

 

커맨드 라인에 익숙해지자. 디렉터리 탐색, 내용 나열, 스크립트 실행, 파일 내용 검색, 환경 변수 설정 같은 일반적인 커맨드라인 명령어에 익숙해지자.

특히 정규식을 충분히 익혀두자. 대량 편집, 이름 바꾸기를 할 때 유용하다.

 

개인용 생산성 치트 시트를 만들자. 빈 문서로 시작해 도구의 이름과 기능에 대한 간단 설명, 링크, 명령어, 기타 메모를 추가하자.

 

코드를 수정하고 내용을 설명하는 풀 리퀘스트를 제출하는 경우가 많다. 규모를 작게 하고 수행단위로 작게 나누자.

풀리퀘스트를 보낼 때는 왜와 무엇을 을 요약하자. UI를 변경하면 이미지를 첨부한다. 후속작업이 있을 것 같으면 명시하자.

 

코드 리뷰를 기다리지 말고 요청하자.

 

소프트웨어 엔지니어링은 단순히 코드를 작성하는 행위(소프트웨어 개발자)에 더하여, 시간의 흐름에 발맞춰 한 조직이 그 코드를 구축하고 유지 보수하는 데 이용하는 모든 도구와 프로세스를 포괄한다.

 

복잡한 문제를 해결했다면 주간 회의 중에 팀원들에게 알려주자.

어떤 작업이었고 왜 어려웠는지, 이 작업은 얼마나 중요하고 복잡한지, 그 과정에서 내가 어떤 노력을 했는지 설명해야 한다.

 

확실히 약속할 수 있는 양을 파악하고 너무 많은 것을 약속하지 않는 현명한 판단이 필요하다. 

 

장애가 되는 요소를 조기에 알리고 절충안을 제시하자.

프로젝트 범위를 줄여 당장 해당 장애물을 극복할 필요가 없도록 하자.

중요하지 않은 일이라면 거절하자.

 

계획 수립 단계부터 QA담당자를 참여시키고 함께 테스트 계획을 수립하자. QA 엔지니어는 특이한 엣지케이스와 발견하기 어려운 버그를 찾아내는 감각이 뛰어나다. QA 엔지니어에게 배우는 것도 좋다.

 

생산적인 소프트웨어 엔지니어는 매일 코드를 출시할 수 있다.

 

팀원이 막혀 있는 상황인데 본인이 먼저 버그를 발견하면 이를 바로 지적하지 말고 스스로 막힌 부분을 뚫는 방법을 익히게 돕자.

 

좋은 코드 리뷰는 이해하기 어려운 코드, 모호한 이름, 주석 처리된 코드, 테스트되지 않은 코드, 간과된 엣지케이스 등 개선해야 할 사항을 지적한다. 

 

경험이 부족하면 본인이 시니어 엔지니어라고 해도 스태프나 수석 엔지니어에게 짝이 되어달라고 요청하는 것을 두려워하지 말자.

 

효과적인 멘토링은 문제를 해결하지 않고, 멘티가 스스로 문제를 해결하도록 해 성장을 돕는 것

 

피드백을 제공하기 전에 먼저 질문을 하자. ~하는 방법은 생각해 보셨나요? 이런 식으로.

 

팀 관계도에서 자신의 팀과 연결된 팀의 최소한 한 명씩이라도 만나보자. 얼마나 오래 근무했는지, 어떤 역할을 맡았는지, 어떤 기술을 사용하는지 등, 나중에 빠른 문의에 도움이 된다.

 

RFC : 직장에서 의견 요청 문서

ADR : 디자인 문서 또는 아키텍처 결정 기록

다른 팀의 RFC를 읽는 것만으로 다른 팀의 업무 방식에 대해 많이 배울 수 있다. 본인이 기여할 능력이 있고 관심이 가는 RFC가 있다면 해당 팀과 연락을 취해 인맥을 쌓을 수 있다.

 

명령형, 선언형, 함수형 언어에는 각각 다른 사고방식이 필요하다. 명령형 언어에서 함수형 또는 선언형 언어로 전환하는 것은 어려울 수 있지만, 그렇게 함으로써 이해의 폭과 사용할 수 있는 도구의 범위를 넓힐 수 있다.

 

인프라의 작동 방식은 다재다능한 시니어 엔지니어에게 필수 지식이며, 작동 방식을 알아가는 과정 그 자체로 흥미롭다.

 

기술 부채는 시간이 지남에 따라 시스템에서 소프트웨어 개발 비용이 증가하는 상황으로, 코드가 쌓여 복잡해진 상황에 발생한다.

기술 부채는 대출과 특성이 비슷하다. 현명하게 사용하면 발전을 가속화하지만, 잘못 사용하면 유지 비용이 많이 든다. 파산도 존재하는데, 전체 코드 베이스를 삭제하고 새로 작성하는 편이 낫겠다고 판단되는 시점이 바로 그 순간이다.

스타트업들은 초기에 기술부채가 많다.

 

프로젝트 시작 전에 테스트 계획, 롤아웃 계획, 마이그레이션 계획 등의 문서를 작성하면 유용하다.

 

릴리즈 노트에는 어떤 고객이 작업의 영향을 받게 될지 요약하거나 출시된 모든 기능의 영향을 정리하기만 하면 된다. 

 

좋은 온보딩 문서의 구성 요소는 다음과 같다.

시스템에 대한 큰 그림, 시스템 수정 방법, 테스트 방법, 배포 방법, 모니터링 방법, 알림 방법, 디버깅 방법

 

테스트의 방법은 크게 세 가지다.

1. 모든 시나리오와 엣지케이스를 수동으로 확인한다.

2. 모든 시나리오와 엣지케이스를 자동으로 검증한다.

3. 프로덕션 환경에서 소프트웨어가 어떻게 작동하는지 모니터링하고 오작동을 감지한다. 문제가 발견되면 팀은 자동화된 테스트를 구축해 CI/CD 시스템에 추가한다.

 

단위 테스트 : 가장 간단한 테스트, 유닛이라고 불리는 격리된 컴포넌트를 테스트, 메서드 또는 클래스의 동작을 테스트함.

통합 테스트 : 여러 유닛을 한 번에 테스트하는 더 복잡한 단위 테스트

 UI 테스트 : 테스트가 직접 버튼을 눌러보며 테스트

성능 테스트 : 시스템의 지연 시간 또는 응답성을 측정하는 테스트

부하 테스트 : 특정 부하에 시스템이 적절하게 작동하는지 확인, 전용 테스트 인프라를 설정하거나 실제 프로덕션 요청을 일부러 지연시킨 뒤 일부러 쌓아놓고 한 번에 서버에 보내는.., 아니면 인프라를 일부러 1/10으로 줄여 현재 트래픽을 잘 처리하는지 확인한다.

카오스 테스트 : 일부러 성능을 저하시켜 시스템이 어떻게 반응하는지 관찰(넷플릭스에서 카오스 몽키 오픈소스 뿌림)

스냅숏 테스트 : 테스트 출력을 미리 기록된 출력과 비교

크기 테스트 : 번들의 크기가 특정 크기 이상으로 증가하면 알림을 보내도록

스모크 테스트 : 원래 하드웨어 테스트에서 유래함. 보드에서 연기 나면 그 보드는 더 이상 테스트해 볼 필요가 없다는.. 

새너티 테스트 : 릴리즈 전에 앱이 예상대로 작동하는지 확인하는 수동 테스트 모음.

 

요새는 프로덕션 환경에서 테스트하는 게 인기 있다.

더 적은 개발 환경 수(테스트 환경의 수)로 테스트할 수 있어서 비용 관점에서 좋다.

 

자동화된 테스트는 회귀 오류 포착 등에 유의하지만 이만한 테스트 코드 작성 시간이 길어지고.. 테스트 코드가 많아지면 테스트 스위트 실행 속도가 느려지고 앱이 올바르게 작동해도 네트워크 지연 때문에 테스트가 실패할 수도 있는 단점이 있다.

 

RFC를 작성하고 배포하는 전반적 목적은 중요한 피드백을 조기에 받아 프로젝트를 완료하는 데 걸리는 시간을 단축하는 것

아키텍처 문서는 RFC와 달리 피드백을 위한 의도가 거의 없이 의사결정을 기록하기 위해 작성된다.

RFC로 프로젝트 진행 방식에 대해 팀끼리 합의를 할 수 없었다면 서로 프로토타입을 만들어보면서 갈등을 해결한다.

그리고 프로토타입은 확신을 가지고 계획을 세우는 데 정보가 충분하지 않은 상황에서 요긴하게 쓰인다. 예를 들어, 타사 API와 통합해야 하지만 방법을 잘 모르겠다면 타사 API를 호출하고 작동 방식을 제안하는 일회용 프로토타입을 만들자. 

 

주요 관계자가 서면 제안서에 동의하도록 하자. 아이디어를 발표해 피드백을 요청하고, 이를 문서에 반영하자. 그런 다음 그들의 의견이 고려됐다는 사실을 알리면 거의 확실하게 당신의 접근 방식을 지지할 것이다.

 

대부분의 사람과 기업은 날짜 중심이기에 기간 추정이 매우 중요하다.

 

프로젝트에 투입되는 인력, 타임라인, 범위는 모두 연결되어 있다. 하나가 바뀌면 적어도 다른 하나가 따라서 바뀌어야 한다.

 

일을 진행하기 전에 이해관계자에게 정확히 무엇이 필요한지 알려주자. 근본적인 질문에 대한 답이 나오지 않은 상태에서 작업을 시작하는 것은 팀, 회사, 본인 모두에게 해가 된다. 해야 할 일과 그 이류를 명확하게 파악하고 그것이 명확할 때만 작업을 시작하자.

 

프로젝트의 적절한 마무리는 훌륭한 킥오프만큼 중요하다. 완료의 의미를 처음부터 명확히 설정하고, 회고를 한다. 모든 팀원과 의미 있는 도움을 준 모든 사람을 칭찬하자. 그리고 축하 행사를 진행한다. 

실패한 프로젝트더라도 긍정적으로 마감하자. 부분적으로 성공한 부분이 있으면 공유하자. 

 

탐색적 테스트를 사용해 보자. 고객이 제품을 어떻게 사용할지 시뮬레이션해 에지케이스를 파악한다. 보통 이는 전담 QA팀이 수행하지만 없는 기업은 벤더를 고용한다.

카나리아 테스트라는 용어는 광부들이 유독 가스를 감지하기 위해 유독 가스에 민감한 카나리아를 탄광에 두는 관행에서 유래했다. 카나리아의 울음소리가 멈추면 경고 신호인 셈

이를 소프트웨어 테스트에 적용하면 소수의 사용자 기반에 코드 변경 사항을 배포한 다음 이 배포 상태 신호를 모니터링해서 문제를 확인한다. 

또는 기능 플래그를 이용해서 새 버전 코드를 사용자 일부 집합에 한하여 사용할 수 있게 한다. 다만, 완료된 기능 플래그의 삭제는 완벽히 해야 한다.

단계적 배포는 특정 지역에서 몇 퍼센트씩 점차 증가시키다가 전 세계로 확장시키는 방법이다.

안정성을 높이는 강력한 방법은 코드를 망가뜨리는 것 같으면 자동 롤백하는 것이다.

사고를 추적하고 그 영향을 측정하자. 지난 1개월 동안 또는 3개월 동안 발생한 서비스 장애 횟수를 아는지에 대한 질문에 대답을 못하면 시스템이 얼마나 안정적인지 모르고 있다는 뜻이다.

위험한 배포의 수행 여부를 오류 예산에 사용해 결정하자.

 

업스트림 종속성 : 팀이 작업할 때 의존하는 팀

다운스트림 종속성 : 팀의 작업에 의존하는 팀

전략적 이해관계자 : 지속적으로 정보를 공유해 업스트림 종속성 때문에 막힌 문제를 해결하는데 도움을 줄 사람 또는 팀

업스트림 및 다운스트림 이해관계자 개념을 알아두면 서비스를 수정할 때 유용하다.

 

직함과 역할은 다르다. 직함은 그 소유자에게 합리적인 기대치를 부여한다. 예를 들어 신입 소프트웨어 엔지니어라던가 스태프 엔지니어 등이 있다.

역할은 담당자, 회의 진행자 등, 임시적인 경우가 많다.

 

프로세스는 더하지 말고 줄이자.

가치가 의심스러운 프로세스가 보이면 제거를 고려하자.

테크리드의 주요 역할은 팀원이 할 일에 집중하도록 돕는 것이다.

반복적인 확인이 팀원들에게 자주 할 일을 상기시키는 방법 중 하나다.

 

북극성은 팀이나 제품의 비전을 칭하는 용어로, 팀이나 제품이 도달해야 할 목표로 안내하는 역할을 한다. 

KPI는 핵심 성과 지표의 약자로, 해당 영역의 진행 상황을 정량화하는 척도다.

OKR은 목표와 핵심 결과를 의미하는 약자로, 기술 기업에서 목표를 설정하고 측정하는 데 매우 인기 있는 접근 방식이다.

 

제품에 대한 SWOT 분석 생성 : SWOT는 강점, 약점, 기회, 위협의 약자다. 이는 제품과 그 제품 시장의 비즈니스 환경을 설명하는 계획 문서다. 이 네 가지 영역을 조사해 문서를 작성하고 피드백을 받자.

 

전략회의에 참여하면 비즈니스에 대한 이해의 폭을 넓힐 수 있다.

 

스태프 엔지니어의 풀리퀘스트는 일부 엔지니어가 보고 배울 수 있으니 스태프 엔지니어가 되면 본보기를 보여줄 수 있는 풀리퀘스트를 작성하자.

갈매기식 관리라는 말이 있는데, 위에 있던 사람이 나타나 작업물에 똥을 싸는 관리방식을 말한다. 다된 밥에 재 뿌리기.. 이런 짓을 하지 않는 스태프 엔지니어가 되자.

실험 후 소독이란 목적을 달성한 기능 플래그의 제거를 의미한다.

 

모노레포는 플랫폼 전반의 모든 소스 코드가 하나의 큰 리포지터리에 있는 경우를 말한다.

서비스 또는 마이크로서비스를 구축하는 회사에서는 서비스가 정신없이 확장되는 문제를 해결하기 위해 서비스 카탈로그를 이용한다. 서비스 카탈로그는 팀 소유의 서비스를 등록하고 엔지니어가 검색하는 포털이다.

 

어떤 시스템에도 PII가 안전하지 않게 저장되지 않도록 무슨 데이터가 어떻게 기록되는지 정기적으로 검토하는 것이 좋다.

 

최고의 로그 작성법

1. 언제, 어디서, 어떻게 일어난 일인지 정확한 정보를 제공한다.

2. 수동, 반자동, 자동 분석에 모두 적합하다.

3. 데이터를 생성한 애플리케이션이 없어도 분석 가능하다.

4. 시스템 속도 저하가 없다.

5. 증거로 사용할 때 신뢰성 입증 가능하다.

 

기록할 이벤트

1. 인증/승인 결정(로그오프 포함)

2. 시스템 액세스, 데이터 액세스

3. 시스템/애플리케이션 변경(특히 권한 변경)

4. 데이터 변경: 추가/수정/삭제

5. 잘못된 입력(악성코드/위협 가능성)

6. 리소스(메모리, 디스크, CPU, 대역폭, 기타 물리적 논리적인 한계가 있는 것)

7. 상태/가용성 : 시작/종료, 장애/오류, 지연, 백업 성공/실패

 

기록할 내용

1. 타임스탬프 및 타임존(언제)

2. 시스템, 애플리케이션 또는 구성 요소(위치), 관련 당사자의 IP 및 동시 DNS 조회, 관련 시스템의 이름/역할 (어떤 서버인지), 로컬 애플리케이션의 이름/역할(무슨 서버)

3. 사용자(누구)

4. 행동(무엇)

5. 상태(결과)

6. 우선순위(심각도, 중요도, 순위, 레벨)

7. 이유

 

모니터링 시 백분위수를 쓴다. 주로 50번째, 90번째, 95번째 백분위수를 본다.

p50은 평균 사용 사례를 잘 나타내는 값, p95(95번째 백분위수)는 성능 모니터링 시 특히 중요한 값으로, 응답 시간이 가장 나쁜 5%의 데이터 포인트를 나타낸다.

p99는 튀는 값으로 보고 허용하기도 한다.

 

런북은 항상 최신 상태로 유지해야 한다. 업데이트가 전혀 필요 없는 완벽한 알림 런북을 작성하는 것은 불가능하다. 알림 런북은 장애를 진단하는 데 필요한 세부 정보를 포함하고, 새로운 사고가 발생하거나 시스템이 변경될 때 마다 업데이트해야 한다.

 

온콜이란 대기 근무 상태를 의미한다. 온콜하면 보상 급여가 지불되는데 만약 온콜 엔지니어를 고용한 상태라면 온콜에 대한 추가보상이 없다.

온콜 번아웃을 조심해야 한다. 가장 무서운 건 밤을 새우거나 통상 업무도 동시 수행해야 한다는 점이다.

서비스 장애의 근본 원인을 파악하는 것은 최우선 순위가 아니다. 코드 변경 사항의 롤백 또는 롤백 계획 실행과 같이 시작할 수 있는 명백한 완화 단계가 있다면 이러한 단계를 먼저 수행하는 것이 맞다. 장애가 완화되면 원인을 파악할 충분한 시간이 주어진다.

 

아키텍처는 간단하게 시작하고 복잡한 전문 용어를 사용하지 말자. 또는 복잡한 아키텍처를 먼저 구상하고 효율적인 접근 방식으로 정제해 나가자.

스태프 엔지니어는 전문 용어를 알아야 한다.

소프트웨어 엔지니어링 관련 전문 용어 : 약한/강한 일관성, 멱등성, 라이트쓰루캐쉬, 역방향 프록시 등

비즈니스 전문 용어 : 발급 은행, 매입 은행, 결제 게이트웨이, PCI DSS, 인증/보류 등

각 회사의 내부 전문 용어도 이해하자

전문 용어와 새로운 언어는 모두 연습을 많이 할수록 자연스러워진다는 공통점이 있다. 

 

양방향 결정은 영향이 제한적이어서 쉽게 되돌릴 수 있는 결정을 말한다. A/B 테스트, 명명 등이 있다. 

단방향 결정은 대조적으로, 되돌리기 매우 어렵기 때문에 진지하게 고려한 후 변경해야 한다. 한 번 내린 결정은 되돌리기에는 너무 많은 비용이 든다. 프로그래밍 언어 선택, 프레임워크 선택, 클라우드와 인프라, RDBMS 등이 있다.

 

주니어 개발자 단계에서는 기본기를 탄탄히 다지는 것이 중요하다. 프로그래밍 언어, 알고리즘, 자료구조 등 기초적인 지식을 충실히 습득하고, 이를 실제 프로젝트에 적용하고 활용하는 능력을 키우자. 

시니어 개발자는 기술적 전문성과 함께 비즈니스에 대한 이해도를 높이는 것이 중요하다. 

 

콘웨이의 법칙 : 시스템을 만드는 조직은 그 조직의 의사소통 구조를 따라가게 된다. 즉, 조직 내 협력 구조를 벗어난 시스템 설계는 어렵다.