Table of contents
원문: Darragh ORiordan, "A retrospective on mentoring four new developers"
사진: Sergi Kabrera
작년 말 저는 오클랜드에서 한 학생 팀이 비영리 단체를 위한 프로토타입을 만드는 것을 기꺼이 도왔습니다. 비영리 단체는 더 많은 기금을 모금하고 그들의 계획에 대한 피드백을 받기 위해 프로토타입이 필요했죠.
저는 대규모 조직에서 팀을 운영하며 주니어 개발자들을 멘토링하는데 도움을 준 적이 있습니다. 그때는 조직의 지원, 도구, 프레임워크와 시스템을 이용할 수 있었기 때문에 훨씬 쉬웠죠. 이 프로젝트에서 학생 팀들은 백지상태로 시작했으며 후원자와 소통하는 방법부터 소프트웨어를 호스팅하는 방법까지 모든 것을 결정해야 했습니다.
이 과정에서 배운 것들과 저지른 실수를 기록하여 다음번에 새로운 개발자들을 도울 수 있는 체계를 만들고 싶었습니다!
경력은 없어도 열정이 넘쳐요!
총 네 명의 학생이 두 팀으로 나뉘었습니다. 다들 마지막 학년이었고 수업 과제로 몇 가지 웹 프로젝트를 만든 적이 있었죠. 한 명은 외부에 공개된 웹사이트를 관리하고 있었지만 나머지는 클라이언트나 고객과 일해본 적이 없었습니다. 처음 학생들을 만났을 때 저는 그들의 긍정적인 태도에 완전히 감동받아 바로 도움을 주기로 결심했죠.
팀 전체가 소프트웨어 개발에 열정적이고 의욕이 넘쳤습니다. 비영리 프로젝트에서 작업하는 것을 선택할 정도로 지역 사회를 생각하기도 했고요. 다들 강한 추진력과 직업윤리를 가지기도 했죠. 대학과 이 프로젝트 외에도 각자 시간제 근무를 하나(몇몇은 두 개씩) 병행하고 있었으니까요.
저는 이 프로젝트에 주당 약 4시간 정도의 시간을 할애하여 일종의 기술 컨설턴트로 활동했습니다. 제 역할은 크게 다음의 두 가지였습니다.
후원자들이 작동하는 프로토타입을 얻을 수 있도록 돕기
학생들이 좋은 성적을 받도록 돕기
저는 몇 가지 모범 사례가 잘 마련되어 있는지 확인하며 몇몇 기술적 선택을 지도했습니다. 또한 학생들이 무언가 정말 막힐 때 한두 번 도움을 주기도 했습니다만 그런 경우는 드물었습니다. 다들 구글링하며 문제를 파악하는 데 능숙했거든요.
범위와 기대치 설정
후원자들은 3개월 안에 가능한 한 많은 작업이 완료되길 바랐고 학생들은 개발 시간에 대해 매우 낙관적이었습니다. 제가 준 가장 첫 번째 도움은 개발팀은 물론 후원자에게도 현실적인 기대치를 설정하고 범위를 제한하는 것이었습니다.
후원자들은 엑셀을 이용하여 각 기능 항목에 “필수” 및 “선택 사항” 태그가 붙은 종합적인 사양 문서를 만들었습니다. 해당 제품은 Shopify같은 성숙한 서비스에서나 기대할 수 있는 모든 고객 및 관리 기능을 갖춘 마켓플레이스가 될 예정이었죠. 학생들도 3개월 주기 안에 대부분의 서비스를 완료하는 데에 동의했습니다.
새로운 개발자들로 이루어진 팀으로는 현실적인 목표가 아니라는 생각이 들었죠.
테스트할 가장 중요한 기능을 파악하고 우선순위별로 정렬하기 위해 몇 가지의 린(Lean) 원칙을 적용했습니다. 이렇게 도출된 제한된 기능 목록은 완전한 기능을 갖춘 마켓플레이스를 만들기보다는 비영리 단체를 다음 단계로 끌어올리기 위한 것이 되었죠.
당신의 개발팀이 만들어진 지 정말 얼마 되지 않은 경우 그들은 자신들이 고품질 소프트웨어 기능을 제공할 수 있는 능력이 충분히 있다고 낙관적으로 생각할 것입니다. 일반 개발자의 낙관론보다 훨씬 더 그렇죠:) 지킬 수 있는 약속을 하되 항상 그보다 더 해내고자 노력하는 자세를 알려주는 방식으로 도와주세요.
제가 본 바로는 개발팀이 연구 및 인프라 구축이나 툴링 설정, CI/CD 등 시작하기 전에 필요한 모든 것들을 잘 고려하지 않는 것 같습니다. 이러한 작업은 애플리케이션 기능을 만드는 것을 제외하고도 많은 시간을 잡아먹을 것입니다.
다음번에는 애초에 요구 사항과 품질 기대치에 대해 더 구체적으로 말해야겠습니다. 팀과 후원자가 최종적으로 제공될 결과물에 대해 명확히 합의할 수 있게 말이죠.
의사소통
성숙한 조직에서 이루어지는 것과 같은 의사소통 표준은 없을 것이기 때문에 직접 설정해야 합니다. 프로젝트 후원자들은 매주 학생들과 모여 진행 상황을 공유하길 바랐고 이는 완벽했죠. 처음에는 Skype와 채팅을 통해 회의를 조직했지만 곧 정기적으로 예정된 구글 미팅으로 변경했습니다. 약 2주마다 후원자들과 학생들이 대학에서 직접 만나 진행 상황을 검토했죠.
또한 Slack에서도 많은 의사소통이 이루어졌습니다. 후원자들이 포함되지 않은 별도의 #tech 채널이 있었죠. 후원자의 의견이 필요해 훨씬 맥락이 적은 #general 채널로 옮겨서 진행했던 논의들도 있었는데 전체 논의를 볼 수 있었다면 작업과 진행 상황 및 복잡성에 대해 더 좋은 생각을 떠올릴 수도 있었을 것 같네요.
이와 같이 작은 그룹에서는 모두가 #tech 채널에 들어가 있는 것이 좋을 수도 있겠습니다.
선택적으로 참여할 수 있는 화상 회의 링크와 함께 정기 회의를 설정하세요. (가능하다면 그냥 Google Calendar를 사용하세요.) Skype는 인원을 조직하는데 그리 적합하지 않습니다.
(Slack이나 Discord 같은) 채팅방을 설정하세요.
짧은 프로젝트에서는 “tech” 채팅들을 별도로 분리하지 마세요. 시간은 곧 금이니 모두가 모든 채팅을 볼 수 있도록 하세요!
기술
대부분의 웹 프로젝트에는 소스 제어, 호스팅, 백엔드 기술, 프론트엔드 기술 및 데이터 저장소가 필요합니다. 저는 기술을 결정하기 전에 조사를 해보라고 제안했고 학생들은 다음과 같은 기준에 따라 기술들을 살펴보았습니다.
곧 졸업해야 하기 때문에 실제 수요가 있는지
이미 경험해 본 적이 있는지
온라인에서 얻을 수 있는 도움은 어떤 것이 있는지
학생들은 이미 .NET으로 작업을 조금 다뤄본 적이 있었고 JavaScript를 꼭 사용하고 싶어 했습니다. 따라서 논의 초기에는 .Net Core 백엔드와 React 프론트엔드를 사용하는 게 어떻겠냐는 말이 오고 갔습니다.
이후 그들은 .NET Core가 자신들에게 적합하지 않다고 빠르게 결정했고 Node.js와 React를 사용하여 전체적으로 JavaScript를 사용할 것이라고 했습니다. .NET Core를 사용하지 않게 된 것에는 큰 이유가 없다고 생각합니다. 그냥 그쪽을 선호한 것일 뿐이었죠. 둘 다 잘 작동했기에 이 부분은 별로 신경쓰지 않았습니다.
또한 학생들은 MongoDB를 사용하고 싶어 했습니다. 많은 튜토리얼에서 사용되는 것을 본 모양이지만 저는 “스키마가 없는(Schema-less)” 데이터베이스가 훈련되지 않은 새로운 팀과 잘 어울릴 것 같지 않았습니다. Heroku가 무료 Postgres 인스턴스를 제공하는 것을 보고 Postgres와 마이그레이션을 지원하는 ORM을 사용할 것을 제안했습니다. 모든 사람이 항상 스키마의 정확한 복사본을 복원할 수 있도록 말이죠. 이 결정은 이후 우리를 몇 번이나 구했습니다.
저는 다른 여러 스타터 프로젝트를 엮어 만든 작동하는 스타터 프로젝트를 학생들에게 제공하여 시간을 절약하려 했습니다. 해당 프로젝트는 다음과 같은 요소를 가지고 있습니다.
GitLab을 통한 CI/CD
Heroku를 통한 배포
React 컴포넌트 예시
Node.js REST API 예시
기본 구조
로컬 개발을 위해 도커라이즈된(Dockerized) Postgres
마이그레이션과 초기 값이 설정된 Sequelize 라이브러리
Postgres 세션 스토어
스타터 프로젝트는 이 링크(https://gitlab.com/darragh.oriordan/starter)에서 보실 수 있습니다. 이후 TypeScript, 수많은 테스트와 GraphQL(Apollo)를 추가했습니다.
당시 GitHub에는 CI/CD가 없었고 무료 비공개 저장소도 없었기 때문에 GitHub 대신 GitLab을 사용했습니다. 지금은 둘 다 사용 가능하죠. 학생들은 전에 브랜칭 모델을 사용해본 적이 없었기 때문에 GitFlow패턴을 고려해보도록 했습니다. master를 보호 브랜치로 만들어 코드를 추가하기 전 PR을 하도록 했죠. Heroku는 master에서 자동으로 배포되게 했고요.
처음에는 몇 가지 기준을 설정하기 위해 제가 코드 리뷰를 몇 번 했고 이후에는 학생들끼리 코드 리뷰를 하도록 제안하였습니다. 실제로 이루어지지는 않았던 모양이지만 큰 프로젝트는 아니었으니까요. 리뷰를 강제하고 싶다면 리뷰 승인을 병합의 필수 요건으로 만드세요.
타입 검사 시스템도 추가하지 않았고 자동화 테스트 예제도 추가하지 않았습니다. 그래서 최종 제품에도 이들은 없었습니다. 테스트 누락과 기본적인 타입 오류로 인해 뒤로 돌아가는 경우도 많았죠.
전혀 작동하지 않는 경우가 아니라면 팀이 알아서 기술을 선택하도록 하세요.
팀의 경험 수준과 나중에 문제를 해결할 개인 시간에 맞춰 합리적인 가드레일을 제공하세요.
PaaS는 IaaS보다 훨씬 쉽습니다. 팀이 유용한 기능을 즉시 개발할 수 있게 해 줄 겁니다.
다음번에는 초기 코드베이스에 일반적인 소프트웨어 기능성 관련 예시를 더 추가할 것입니다. 예를 들어 단위 테스트, E2E 테스트, 코드 구조 같은 것들 말입니다. 배울 수 있는 좋은 예제가 있을 때 팀이 무엇을 만들 수 있는지 놀라게 될 수도 있습니다.
모든 학생이 강력한 개발용 컴퓨터를 가지고 있는 것은 아니므로 이 점을 고려하세요. 전체 Visual Studio는 학생용 노트북에서 느릴 수 있기 때문에 VS Code가 더 좋습니다. 학생이 Windows Professional 라이센스를 가지고 있지 않다면 “완전한” Windows Docker를 실행할 수 없으며 Docker 실행을 위해 별도로 VM을 실행해야 합니다.
마이그레이션이나 ORM, 소스 제어 브랜칭을 해본 적이 없을 수도 있으므로 그런 인원을 찾아 설명해줘야 합니다.
CI는 제가 강제한 요소 중 가장 가치 있는 것 중 하나였습니다. 팀원 개인의 컴퓨터에서는 작동하지만 CI 서버에서는 고장난 빌드가 너무 많았습니다. 꼭 CI를 적용하세요!
스타터를 프론트엔드와 백엔드 프로젝트로 나누었지만 결국 하나의 단위였습니다. 어쨌든 보통 함께 배포되었기 때문에 혼란스럽게 보일 수도 있었다는 생각이 드네요. 예를 들어 세 개의 package.json이 있었고 주어진 패키지를 올바른 위치에 설치하려면 올바른 디렉토리에 있어야 했다는 점이라든가 말이죠.
인프라
학생들은 대학의 비공개 클라우드를 사용하여 애플리케이션을 호스팅할 예정이었습니다. 직접 설정하여 사용할 수 있는 텅 빈 서버가 제공되었겠죠. 서버에 대한 접근은 대학 내부 네트워크에서만 가능했을 겁니다. 심지어 HTTP도 말이죠. 이런 제약과 짧은 기간을 고려한 결과 저는 다음과 같은 이유로 Heroku를 제안했습니다.
서버 관련하여 설정할 것이 아무것도 없음
프로덕션이 아니거나 스테이징 상태에서는 돈이 들지 않음
dpl을 통한 잘 알려진 배포 패턴이 존재함
후원자들이 언제든 인터넷을 통해 진행 상황을 볼 수 있음
후원자들이 언제든 고객에게 제품을 보여줄 수 있음
제품 개발
이터레이션은 잘 작동했습니다. 팀은 자신들이 정한 시간 내에 완료해야 할 작업 단위가 있었고 마스터/스테이지 환경은 항상 사용 가능한 상태로 유지되었습니다. 후원자들은 약 3주 차부터 제품을 확인하였으며 제품은 학생들이 기능을 통합해 가며 점진적으로 개선되었습니다. 후원자들은 학생들을 위한 피드백 작업에 많은 시간을 투자했고 이 모든 피드백은 학생들이 선별하여 수정하거나 제외시켰습니다.
학생들은 인증(Auth0)과 결제(Stripe)를 위해 라이브러리를 사용했습니다. 정말 효과적이었죠. 맞춤형 솔루션을 개발하는 데 들었을 몇 주간의 작업을 절약할 수 있었습니다. 이메일 사본 작성, 이메일 전송, 백엔드와 프론트엔드 및 데이터베이스에 인증을 연동하는 데에는 꽤 많은 작업이 더 필요했지만요. 결제는 원활했습니다.
팀에 디자이너가 없어 사이트가 전문적으로 보이지는 않았습니다. 제 생각에 이는 큰 문제였습니다. 후원자들이 가장 먼저 해야 할 일은 디자이너와 함께 작업하는 것이라고 제안했어야 했어요. 이렇게 하면 후원자들이 잠재 고객들에게 보여줄 수 있는 멋진 종이 기반 프로토타입을 제공할 수 있었을 겁니다. 프로젝트 전반에 걸친 “이러면 어떨까”나 “이게 될까” 같은 논의를 줄일 수 있었을 텐데 말이죠.
모바일 지원은 데스크탑 레이아웃 이후에 추가되었습니다. 이 때문에 레이아웃을 다시 작업하는 데 많은 시간이 걸렸습니다. 모바일 우선 접근 방식을 제안했어야 했는데요. 요즘 많은 사이트에서 최소한 60-70%의 모바일 사용량을 보이고 있으니 그렇게 했어야 했습니다. 제약 조건을 정하고 시작하게 될 수도 있었겠죠. 어차피 디자이너라면 이런 문제를 더 일찍 눈치챘을 것입니다. 그러니 먼저 디자이너를 고용하세요:)
학생들이 디버깅 경험이 없어서 가끔 도와줘야 했어요. 디버깅은 신입 주니어 개발자들이 막히기 전에 미리 점검해볼 수 있는 부분일 것입니다. 콘솔 로그를 읽고 소스 파일에서 특정 줄을 찾는 방법, 중단점을 설정하는 방법 같은 것들 말이죠. 모듈에서 모든 코드를 제거하고 메서드가 다시 중단될 때까지 하나씩 다시 추가하는 방법도 가르쳤죠:)
코딩하기 전에 디자인을 먼저 하세요. 아니면 기존 마켓플레이스를 먼저 모방하는 대신 후원자가 마켓플레이스를 선택하고 팀이 이를 가능한 한 많이 베끼도록 하세요. 그전에 좋은 디자인이 먼저 있다면 가장 좋겠지만요.
SaaS 제품에는 사용하기 굉장히 쉬워 보이는 매우 간단한 예제가 있는 경우가 많습니다. 실상 이런 예제를 당신의 제품과 통합하려면 상당한 작업을 해야 할 가능성이 높습니다. SaaS에 추가할 구성과 콘텐츠는 여전히 시간을 잡아먹을 것이고요.
모바일 레이아웃을 조기에 고려해야 합니다.
후원자들이 고객에게 종이 기반 모형을 가져가 피드백을 받았는지 확인하세요.
개발자에게 디버깅하는 방법을 조기에 가르치세요.
결과는 좋았지만...
학생들은 처음에 합의한 굵직한 기능들을 모두 완성했습니다. 프로젝트를 제시간에 완료하기 위해 몇 가지 작은 타협이 있었지만요. 최종 제품에는 몇 가지 버그도 있었습니다. 아직 어떤 종류의 고객 피드백이 있었는지는 듣지 못했지만, 디자인 면에서 고객들이 정말 매끄러운 경험을 기대했다면 좋지 않았을지도 모르겠습니다.
하지만 학생들은 그 프로젝트로 반에서 가장 좋은 점수를 받았으니 그것만으로도 저에게는 큰 성공이 되었죠.
모든 소프트웨어 프로젝트와 마찬가지로 여기에도 같은 주요 문제가 전반적으로 나타났습니다.
코딩하기 전에 솔루션이 문제를 해결하는지 확인하세요. (훌륭한 디자인과 UX가 도움이 될 것입니다.)
대부분의 기술 선택에는 장단점이 있을 것입니다. 성가신 것들을 견디는 자세도 필요하죠.
결국 CI/CD, 자동화된 테스트, 정적 타입, 이해관계자의 피드백과 함께 하는 반복 개발 같은 좋은 관행을 따르는 것은 항상 가치 있는 일입니다. 짧은 프로젝트라도 초기에 들인 노력에 보답해 줄 겁니다.
주니어 개발자 팀을 맡고 있는 시니어 개발자나 리더에게 추천하고 싶은 팁이 있나요?
새로운 개발자 시절에 당신에게 도움이 되었던 것을 기억하시나요?
알려주세요!