Project
프로젝트란 무엇일까?
프로젝트에 오신 수강생 여러분 환영합니다! 프로젝트를 시작하기에 앞서, 몇 가지 중요한 사항을 전달하겠습니다.
여러분들이 생각하시는 프로젝트는 무엇이라고 생각하시나요? 단어만 놓고 본다면 굉장히 거창하고 멋있어보이지 않나요?
프로젝트는 정해진 기한안에 일정한 목적을 달성하기 위한 업무입니다.
프로젝트는 크게 시작하고, 계획하고, 실행하고 점검하고, 3가지 과정을 거치고 마무리됩니다.
이 과정에서 팀원들과 함께 고민하고 끊임없이 반복해서, 여러분들의 기술지식을 적용하는 시간이 프로젝트 섹션이라고 생각해주시면 됩니다.
프로젝트의 목표
여러분들께서는 총 3개의 프로젝트를 경험하게 됩니다.
첫 번째 프로젝트의 목표는 다음과 같습니다.
- 프로젝트에 대한 기본적인 이해도를 높입니다.
- 프로젝트에서 필요한 Github 이해도를 높입니다.
- 프로젝트에 대한 문서작성 능력을 향상 시킵니다.
- 팀 커뮤니케이션 이해도를 높입니다.
두 번째, 세 번째 프로젝트의 목표는 다음과 같습니다.
- 프로젝트에 대한 필요한 기획을 하고, 협업을 경험합니다.
- 학습한 기술 스펙을 프로젝트에 적용해봅니다.
- 협업에 대한 커뮤니케이션 능력을 향상 시킵니다.
- 프로젝트에서 발생하는 이슈를 파악하고 문제를 해결하는 능력을 향상 시킵니다.
- 취업에 필요한 포트폴리오로서의 기본적인 웹 서비스를 제작해봅니다.
지금까지는 프로젝트에서 기본적으로 알아야 하는 내용에 대해 학습해보았습니다. 이후에 나오는 내용을 자세히 학습해볼까요?
Step 1 - 프로젝트 준비 (Project Wiki)
Pre-Project 개요
안녕하세요! 여러분~! 여기서는 Pre-Project 전체 개요를 설명 해드립니다.
내용을 잘 숙지해서, 원활한 Pre-Project를 진행 하시길 바랍니다.
Pre-Project가 필요한 이유
Pre라는 단어에서 유추할 수 있듯이, 본격적인 프로젝트를 시작하기 전에 전반적으로 미리 학습하는 시간입니다. 아직 여러분들께서 프로젝트에서는 무엇을 해야할지, 어떤 내용을 다뤄야할지 짐작하기 어렵기 때문에 그 부분을 저희가 제공 해드리는 콘텐츠를 통해서 학습해주시면 됩니다.
조금 더 프로젝트에 녹여서 설명을 드리자면, 지금까지 여러분들께서 학습한 내용을 바탕으로 실전 개발 업무를 미리 체험하실 수 있는 섹션입니다.
처음부터 하나씩 학습 하면서, 프로젝트에 대한 이해도를 조금씩 올려주시면 좋겠습니다.
이제는 협업이 중요한 시점
무엇보다 프로젝트는 수강생이 함께 만나서 진행하는 특별한 섹션 입니다. 기존에는 각 학습공간에서 각자 학습을 진행했다면, 이제는 서로가 프로젝트에서 처음 만나서 협업을 익혀 나가는 단계입니다.
그렇기 때문에, 기존에 학습 했던 활동보다 더더욱 협업에 대한 능력치를 상향시킬 수 있는 좋은 기회입니다.
여러분들께서 실제 현업에서 진행하는 프로젝트는 디자인, 기획자, 마케터 등 다양한 직무의 사람들과 협업을 수도 없이 경험할 예정입니다. 그 전에 개발단계에서 각 개발포지션에 있는 사람들과 먼저 협업하는 단계를 통해 익숙해지는 시간이 되셨으면 좋겠습니다.
협업에서 발생할 수 있는 수강생 사례
여러분들께 실제 과거 수강생 사례를 통해서, 협업에 대한 이해도를 올리고자 하단에 두가지 사례를 가져왔습니다. ’우리는 그러지 않을꺼야~’ 쉽게 생각할 수 있지만, 어쩌면 발생할지 모르는 상황을 미리 인지하고 대비하는 것도 프로젝트 진행에 많은 도움이 될 것입니다.
사례1 : 오버 커뮤니케이션을 지향해주세요.
실제 수강생 사례입니다. 프론트엔드, 백엔드 담당이 나눠지고 각자 태스크를 나눈 뒤 이들은 최종 발표 이틀 전까지 단 한차례 만남 없이 개인 작업만 진행하고 최종 발표 이틀 전 Merge를 하기 위해 모였습니다. 결과는 어땠을까요~? 예상이 가시나요~?
결과는 Merge하는 순간 4개의 작업들이 모두 충돌해서 결과물을 만들어 내지 못했습니다. 물론 위의 사례는 극단적인 예시라고 보여집니다. 하지만 수강생들 사이에서 충분히 발생할 수 있는 문제점이기도 합니다.
그만큼 현재 상황을 지속적으로 공유하면서 프로젝트에 대한 이야기를 ‘넘치도록' 많이 하는게 중요합니다.
사례2 : 협업도 기본적인 예의는 필수입니다.
실제 수강생 사례입니다.
한 프로젝트 팀에서 좋은 팀워크를 위해 서로가 나이를 공개하고, 호칭을 편하게 진행 한 팀이 있었습니다.
호칭이 편하다 보니까, 프로젝트가 지나면 지날 수록 커뮤니케이션 과정에서 과격한 언행, 비방이 잦았습니다. 결국, 프로젝트 회의 도중 욕설이 난무하면서 프로젝트 절반이 지난 시점 중단되는 사태가 발생했습니다.
서로에 대한 감정적으로 상한 상태여서 프로젝트가 제대로 진행 되지 못했고, 결국 결과물이 나오지 못했습니다.
프로젝트에서 친목은 수강생분들께서 선택할 수 있습니다. 하지만 최소한의 예의를 지켜주는 것은 필수입니다.
팀 프로그래밍 기조
팀 프로젝트의 목적
우리는 앞서 프로젝트가 무엇인지, 프로젝트를 어떻게 진행하는 건지 학습 했습니다.
프로젝트를 진행하는데 가장 중요한 구성 요소로서 **‘팀'**과 **‘팀원'**이 있는데요.
우리는 프로젝트를 왜 혼자가 아니라, 팀원들과 함께, 팀이 되어 일하는 걸까요?
여기, **Software Developmet: Why Teamwork Is Conductive to a Thriving Work Environment (소프트웨어 개발: 팀 워크가 더 발전적인 업무 환경에 도움이 되는 이유)**의 아티클을 한번 함께 볼까요?
In Software Development, Teams that Work Together Closely Over Extended Period Found to Be More Efficient. 소프트웨어 개발 업계에서는 오랜 기간동안 긴밀하게 협력하는 팀들이 훨씬 더 효율적인 것으로 나타났다.
팀으로써 ‘잘’ 일하는 것은 누구에게나 매우 중요한 능력이지만, 높은 수준의 기술을 효과적이고 효율적으로 활용해야하는 소프트웨어 개발자에게는 더더욱 중요합니다. 소프트웨어 개발자들이 그들 개인의 장점과 강점을 결합 했을 때 비로소 ‘혁신’이 일어납니다.
다양한 경험과 능력을 가진 개발자들이 협업하는 팀이 올바르게 나아가면, 셀 수 없이 많은 장점들이 생깁니다. 그 중 몇 가지 대표적인 장점을 소개합니다.
1) Increased Efficiency (효율성 향상)
팀은 기능을 갖춘 제품을 완성한다는 공동의 목표를 향해 함께 노력합니다. 협업의 궁극적인 목적은 공통의 문제를 해결하는 동시에 팀원 개개인이 맞닥뜨리는 문제 또한 효과적인 솔루션을 찾기 위해 협력한다는 점입니다. 팀원들이 서로 격려하고 돕는다면 제작 시간을 단축하고 실수를 방지할 수 있습니다.
2) Enhanced Creativity (창의성 향상)
‘오픈 커뮤니케이션’과 협업은 학습의 기회와 창의성을 높이는데 매우 도움이 됩니다. 팀 동료들이 자신을 표현하는데 편안함을 느낄 때, 보다 효과적으로 새로운 아이디어, 개념, 프로세스의 도입으로 이어진다는 연구 결과가 있습니다. 이는 개인이 혼자서 작업 할 때는 떠오르지 않을 수 있는 최종적 아이디어나 결과에 혁신과 변화를 일으킬 수 있는 매우 중요한 요소 입니다.
3) Strengthened Innovation (강화된 혁신)
창의성을 적극적으로 도모하고 환영하는 팀은 시장에서 주목할 만한 주요 혁신을 창출할 가능성이 더 높습니다. 소프트웨어 개발자가 효과적으로 협업 할 때 그 팀은 회사에서 원하는 바를 기대에 부응하게, 또는 오히려 요구사항을 충족하는 이상으로 초과하는 제품을 제공할 수 있습니다.
이 칼럼에서 이야기 하듯이, 우리는 개인이 일할 때 보다 팀원과 ‘한 팀’으로 일할 때 훨씬 더 큰 시너지와 결과를 기대할 수 있습니다.
모든 소프트웨어 개발자는 보다 더 효과적으로 함께 일할 수 있는 동료 개발자를 원합니다. 개인의 발전을 도모하며 팀의 성과 또한 기대할 수 있는 인재를 원합니다.
우리가 팀으로 일 해야하는 이유, 협업에 능해져야하는 이유, 동료와, 팀과의 소통에 익숙해져야하는 이유는 이 정도면 충분한 것 같은데요.
여러분도 그렇게 생각하시나요?
그러면 이제부터는 어떻게 하면 좋은 동료, 함께 일하고 싶은 동료, 협업에 능한 개발자가 될 수 있을지 뒤에서 조금씩 더 자세히 설명 드릴게요!
참조 : Software Development: Why Teamwork Is Conducive to a Thriving Work Environment
팀 매칭 기조
진행하는 프로젝트 팀 매칭은 ‘랜덤’ 으로 진행됩니다.
왜 랜덤으로 매칭이 되어야 할까요?
현업과 비슷한 환경을 제공합니다
여러분들이 개발자가 된 행복한 상상을 한번 해볼까요? 설레는 마음으로 회사에 입사를 하는 날 여러분들과 함께 일하는 동료가 누구인지, 그 동료들이 어떠한 사람인지 알 수 없습니다. 마치 학교 입학 후 배정 된 반에 들어가 처음보는 친구들과 학교생활을 해야하는 느낌과 유사합니다. 조금 공감이 되시나요?
여러분들이 학습과정의 마지막을 최대한 현업과 비슷하게 느껴볼 수 있는 환경을 경험 시켜드리기 위함입니다.
최선의 선택을 고려해 팀 배정을 합니다.
현재 많은 수강생들이 프로젝트 단계에 진입했습니다. 모든 구성원들의 원하는 부분을 맞춰서 팀 배정을 하기에는 어떤 가능성도 모든 구성원이 만족하기에는 어렵습니다.
누군가는 성향이 잘 맞는 팀원들과 팀이 되었고, 그렇지 않은분들도 계실겁니다. 그래서 아래에 있는 내용과 같은 이유로 내부에서 최선의 선택을 통해 팀 배정을 합니다.
결국 여러분들께서는 다양한 상황과 협업 성향을 경험해 볼 수 있습니다. 이러한 팀 매칭을 통해 여러분들께 어떠한 경험을 제공할 수 있는지는 하단의 내용을 통해 확인해주세요.
프로젝트 = 하드스킬 + 소프트스킬
결국, 주니어개발자는 회사에서 요구하는 사항을 수용하고 팀원들과 얼마나 소통을 원활하게 해서 개발을 할 수 있는지가 중요한 요소입니다. 그렇기 때문에, 주니어 개발자한테 하드스킬보다 소프트스킬을 중요시하는 곳이 훨씬 많습니다.
하지만, 지금까지 하드스킬 중심의 학습을 해오셨습니다. 앞으로 하시게 될 프로젝트는 앞에서 했던 섹션들과 다르게 소프트스킬에 대한 역량을 최대치로 끌어올릴 수 있는 시간입니다.
프로젝트 섹션에서는 하드스킬과 소프트스킬을 적절히 잘 활용하는게 중요합니다.
프로젝트의 ‘결과'도 중요하지만 ‘과정’도 매우 중요하다
여러분들이 만들어가는 포트폴리오의 결과가 취업에 큰 영향을 주는 것은 사실입니다. 하지만, 어느정도의 결과만 나온다고 취업의 문제가 100% 해결할 수 있는지 고민해볼 필요가 있습니다.
위에서 말씀드린 소프트스킬과 중요한 요소가 바로 프로젝트에서의 ‘과정’ 입니다.
결국, 여러분들이 들어갈 회사에서는 결과물을 만들어내는 과정과 실패, 트러블슈팅에 대한 질문, 즉 스토리를 중요시합니다. 그 과정을 통해서 여러분들이 문제를 어떻게 해결하려 했는지의 스토리가 주니어 개발자로서 문제해결 능력을 보여줄 수 있는 요소입니다.
팀 구조 (팀장, 팀 규칙)
안녕하세요 여러분! 이곳에서는 프로젝트 팀 구조에 대한 개괄적인 설명을 드리려 합니다. 팀원들과 팀 구성이 되었다면, 앞으로 프로젝트에서 함께할 다양한 팀 구조를 만들어 가야합니다.
아래 작성 된 내용은 절대적인 정답은 아닙니다. 다만, 여러분들께서 조금 더 고민 할 시간을 줄여 드리고자 예시와 다양한 내용을 준비했으니 참고하셔서 팀 빌딩에 도움이 되시길 바랍니다.
팀장 선정
프로젝트를 진행하기 위해서는 프로젝트 전체를 이해하고, 이끌어 갈 수 있는 팀장 역할이 반드시 필요합니다. 그렇다면, 어떤 분이 팀장에 가장 적합 할까요? 하단에 있는 TIP 내용을 살펴봐주세요.
- 팀장 선정 tip 아래의 항목들을 가지고 팀원분들과 이야기를 나눠보세요.
- 팀장은 리더십만 좋으면 된다.
- 팀장은 프로젝트 전체에 대한 이해도가 높아야한다.
- 팀장은 코딩만 잘하면 된다.
- 팀장은 커뮤니케이션 능력만 뛰어나면 된다.
팀장은 리더십 + 프로젝트 이해도 + 커뮤니케이션 능력 다방면으로 능력이 있는 분이 하시는게 가장 좋습니다. 팀원들의 의견을 모두 들어보고, 필요한 부분과 불필요한 부분을 구분해서 팀을 이끌어 갈 줄 알아야 하며, 팀원들의 일정관리를 통해 프로젝트의 작업 진행을 이끌어야하며, 지속적으로 팀원들과 소통해 프로젝트의 문제점을 파악하고 있어야 하는 등 정말 많은 부분에 기여를 해야합니다.
우리 대학교 시절을 떠올려 볼까요. 대학교 팀플 다들 기억 나시죠? 그 때 아무나 팀장을 선정한다면 좋은 결과물이 나오지 않는 경우를 겪어보신분도 있으실 겁니다. 그런 것처럼 신중한 팀장 선정이 여러분들의 프로젝트 결과물과 이어질 수 있다는 점을 기억해주시면 좋겠습니다.
팀 규칙 정하기
이번에는 팀원들과 프로젝트에서 기본적으로 지켜야할 팀 규칙에 대해서 생각해보겠습니다. 어떻게 본다면 단순한 규칙으로 받아들일 수 있지만, 해당 팀의 분위기를 전반적으로 파악할 수 있습니다.
팀원들과 지킬 수 있는 범위 안에서의 규칙을 정하고 모두가 볼 수 있는 문서에 기록해서 주기적으로 보는 것이 매우 중요합니다. 단순히 회의시간, 휴식시간만 기록하는 것 보다 우리 팀만의 색다른 규칙도 있으면 좋은 팀 분위기를 보여줄 수 있을것 입니다. 여러분들만의 커스텀한 규칙을 만들어보세요.
규칙을 만들었다면, 당연히 프로젝트 기간동안 팀원들을 위해서 무조건 지켜야하는 부분입니다. 서로가 규칙 안에서 배려하면서 무사히 프로젝트를 완주하시기 바랍니다.
팀 별 상시 커뮤니케이션 진행 방법
프로젝트 진행 시, 팀원들과 상호 합의 된 가장 편리한 방식으로 소통하실 수 있습니다.
정규 학습 시간(9시~6시) 동안에는 상시 소통 할 수 있는 연락 방법을 정해두세요.
프로젝트를 진행하면서 개발에 필요한 ‘업무적 소통과 디스커션’을 진행하는 주된 창구는 깃허브이며, 서로의 상시 소통을 위한 채팅 툴을 아래 본문을 통해 팀원들과 함께 고려해주세요.
합의된 휴게시간 및 사전 동의된 용무 시간 이외에는 최대 30분 이내에 응답, 논의 및 미팅은 실시간 소통으로 진행 될 수 있어야 합니다.
각 팀의 구성원들의 선호 성향에 따라 서로 소통하기 가장 효과적인 툴을 선정해주세요.
실시간 소통을 위한 채팅 툴 추천 1. 디스코드
여러분도 자유롭게 디스코드 서버를 만드실 수 있다는 것을 알고 계신가요? 다양한 게임을 이용하면서 소통의 툴로 사용하고 있는 만큼, 팀원들과의 프라이빗한 소통도 디스코드로 진행되면 한층 편리함과 생산성이 올라가겠죠?
서버 내 여러 채널을 생성 할 수도 있어서, 자유토론하는 채널, 레퍼런스를 모아두는 채널, 백로그를 기록해두는 채널 등 팀원들과 더 효율적으로 소통할 수 있는 채널들을 생성해두는 것도 좋은 방법일 것 같은데요!
장점) 프라이빗 서버내 목적 별 채널 생성 가능 단점) 새벽 게임현장 들킬 수 있음 😱
실시간 소통을 위한 채팅 툴 추천 2. 카카오톡 오픈채팅
뭐니뭐니 해도 난 카톡이 편해! 라고 하시는 분들! 그렇지만 개인 휴대폰 번호를 다 공유하기엔 개인정보가 신경쓰이고.. 하실 수도 있죠! 그럴 때는 카카오톡 오픈채팅방을 활용해보세요!
장점) 카톡그자체의 편리함, 개인정보 보호 가능 단점) 주고 받은 레퍼런스 영구보관 불가능
실시간 소통을 위한 채팅 툴 번외편. 슬랙 (slack)
요즘 스타트업을 비롯해 대다수의 기업들이 사용하고 있는 슬랙에서도 개인 워크스페이스를 개설, 추가할 수 있답니다! 현업의 분위기를 물씬~! 더 느끼며 적용해보고 싶다! 하시는 분들은 슬랙을 통해 활용하시는 것도 도전해볼 수 있겠습니다.
장점) 현업에서 사용할 툴 적용, 다양한 외부 툴 연동 및 봇 활성화 가능 단점) 프로젝트를 위해 공부해야하는게 하나 더 추가..!
다시 한 번 강조 하지만, 소통 채널을 선택, 선정 하는데 있어 가장 중요한 요소는 1. 상시소통 가능한가. 2. 우리가 필요한 기능을 원활하게 사용가능한가 입니다.
우리 팀원들의 성향과 업무 패턴을 고려하며 선정해주세요!
팀 별 화상회의 진행 방법
기본적으로 팀 별 화상회의를 위한 유료 툴 또는 멤버십을 제공하지 않습니다. 아래의 내용을 잘 고려하셔서 팀 상황과 성향을 고려하여 가장 효과적으로 사용할 수 있는 툴을 선정해주세요!
화상회의 툴 1. Zoom
코로나 이후 가장 보편화 되어 있는 화상 회의 툴인 Zoom 을 소개드립니다.
이미 학습을 진행하시면서 라이브세션 등에 참가하시며 많이 익숙해지셨을거라 생각합니다. 🙂 Zoom의 장점은 화면 공유와 음성의 퀄리티가 좋고, 또 비디오에 약간의 보정이 가능하다는 것 입니다. 😘
가상 배경 화면을 설정하여 개인학습 공간의 프라이버시도 지킬 수 있지요! 하지만 유료계정 사용자가 아니라면 매 회의 때 마다 40분의 제한이 걸린다는 단점이 있습니다.
그래도 괜찮다! 우리 팀은 줌이 제일 편하다! 하시는 경우, 40분마다 회의실 이탈 후 새 회의실로 재접속 하셔야하는 번거로움을 감안해주세요 😂
장점) 부드러운 화면 공유, 가상배경 가능, 화면 뷰티 효과 가능단점) 40분 제한, 여러명 동시 화면 공유 불가능
화상회의 툴 2. Google Meet
구글 밋은 최근 많은 회사에서 채택되고 있는 화상회의 툴인데요.
구글 캘린더에 서로를 초대하여 스케줄을 지정해둘 수 있고, 캘린더 상에 자동 생성되는 링크를 통해 바로 접속 또한 가능하답니다! 매번 접속 링크를 공유해야 하는 번거로움이 사라지죠 🙌🏻
하지만 네트워크 환경이 좋지 않은 경우 안정도가 다소 약하고, 줌 보다 사용법이 덜 익숙하다는 점을 단점으로 꼽을 수 있겠네요!
장점) 캘린더 상 스케줄 관리가 용이, 가상배경 가능단점) 종종 네트워크 불안정
화상회의 툴 3. Gather Town
게더타운은 상시 접속이 가능하고, 팀 별로 분리된 공간에서 선택적 on/off가 가능하다는 장점이 있죠. 또한 여러명이 동시에 화면 공유가 가능해 복수의 팀원의 화면을 모두 띄워 함께 보며 이야기 할 수 있답니다.
이전 기수의 많은 수강생분들은 프로젝트 기간 중 게더에 상시 접속 후 평소에는 채팅으로 소통, 필요시 카메라와 마이크를 켜고 즉시 미팅을 진행하시는 경우가 많았습니다. 게더타운 이용의 단점이라 하면, 아직 게더타운 공식적으로 가상배경 설정 기능을 지원하지 않아 우회적인 방법을 사용해야하는 번거로움이 있다는 것이 있겠네요!
장점) 여러명이 동시에 화면 공유 가능 단점) 가상배경 설정 불가
커뮤니케이션/협업 기조
우리는 어떤 커뮤니케이션을 지향해야할까요?
서로의 존재를 인정해주세요. 성숙하고 젠틀한 대화를 이끌어주세요. 칭찬과 격려를 아끼지 말아주세요. 그럼에도 불구하고, 할 말은 해야 할 때
어떤 커뮤니케이션을 지향해야할까요?
서로의 존재를 인정해주세요.
여러분은 지금 소속된 팀에 얼마만큼 ‘필요한' 사람인가요? 아, 질문을 바꿔보겠습니다. “여러분은 팀에서 중요한, 꼭 필요한 존재가 되고 싶으신가요?” 이 질문에 ‘아니요' 라고 대답하실 분은 단언컨대, 단 한 분도 없을 것이라 생각합니다.
그럼 다시 한번 질문 드리겠습니다. 이번엔 잠시 동안 스스로의 대답을 곰곰히 생각해봐주세요. 여러분은 왜 팀에서 중요한 일원이 되고 싶으신가요?
(잠시 생각하는 시간을 가져보세요!)
근대 교육학의 아버지라 불리우는 미국의 철학자이자 교육학자 존 듀이 (John Dewey)는 인간 본성의 가장 심오한 욕구는 **‘중요한 존재로 인정받고자 하는 욕구'**라고 말했습니다. 우리는 모두 스스로의 존재를 인정 받고, 중요한 존재로서 인식 되기를 원합니다.
팀 구성원 서로서로가 서로의 존재 이유를 인정하고 계속해서 확인시켜주며, 개인의 크고 작은 기여를 알아봐주세요. 우리는 서로에게 당연한 존재가 아니며, ‘함께’ 중요하고 의미있는 일을 해내고 있다는 사실을 잊지 않는 것이 중요합니다. 서로의 존재 확인과 인정을 통해 더 열심히 일 하고자 하는 동기를 불어 넣어주세요.
우리는 사람이기 때문에, 학생이기 때문에, 배우고 있기 때문에, 이 모든 것이 처음이기 때문에 실패하는 것이 당연하고 사실 대부분이 실패합니다.
우리 모두는 ‘잘하기’ 때문에 중요한 존재인 것이 아니라 같은 목표와 방향을 공유하기 때문에 중요합니다. 하루 중 잠시라도 스스로나 프로젝트, 학습에 대한 생각을 멈추고 함께 하고 있는 팀원의 장점과 부트캠프에 탑승한 이후 내가 가지게 된 기회, 그리고 왜 이 경험이 중요한 가치와 의미를 가지는지에 대해서 고민해주세요.
그 가치는 분명 서로에 대한 소중함과 구성원 한 명 한 명의 가치에 대해서 상기시켜 줄 것입니다.
성숙하고 젠틀한 대화를 이끌어주세요.
너무 진부한 말이기도 하지만 우리는 종종 말을 예쁘게, 또는 너무 못나게 하는 사람들을 두고 ‘말 한마디로 천냥 빚을 갚는다’고 말하죠. 같은 말이라도 더 듣기 좋게, 상대를 배려하는 방법이 있다는 것을 우리는 모두 잘 알고 있음에도 불구하고 감정이 앞서는 순간에 퉁명한 말들을 내뱉곤 하죠.
어떻게 하면 더 부드러운 말을 사용하여 관계와 일 모두 더 바람직한 모습으로 발전시킬 수 있을까요?
- 실수에 대한 지적, 또는 비판은 간접적으로 해주세요.결국 상대방은 뒤에 나온 말에만 집중하게 되고, 앞서 말한 칭찬은 비난을 위한 핑계처럼 느껴지게 할 수 있습니다.문장 속 작은 부분 하나만 바뀌었을 뿐인데 전달하는 사람의 의미가 훨씬 더 진정성 있게 다가갈 수 있다는 것, 놀랍지 않나요?
- 우리도 우리의 문장 속 ‘근데', ‘그러나'와 같은 반의어 사용을 줄이고 자연스럽게 상대의 행동을 요청할 수 있는 간접적인 표현들을 연습해보는 것은 어떨까요?
- “프로젝트 기획안을 짜주신 것은 너무 좋았어요. 하지만 구성이나 디자인이 좀 아쉽더라구요.” 라고 이야기 하는 것 보다 ”프로젝트 기획안을 짜주신 것 너무 좋았어요. 그리고 구성이나 디자인을 좀 다듬으면 좋겠더라고요.” 라고 이야기 하는 것이 훨씬 더 긍정적인 수용이 가능하다는 연구결과가 있었다고 해요.
- 우리가 흔히 말하는 ‘쿠션어'를 사용하여 칭찬이나 배려의 말을 앞세우는 것도 마냥 정답이 될 순 없습니다. 칭찬 이후 ‘그런데', ‘하지만' 과 같은 반의어가 등장한다면
- **나의 실수를 먼저 인정해주세요.**관계의 친밀감을 높이는 가장 빠른 방법 중 하나는 바로 ‘공감대' 형성 입니다. 상대의 실수나 오만 또한 너의 부족으로 인한 실수가 아니라 ’우리 모두가 할 수 있는 실수이며, 나도 종종 실수를 하기 때문에 의기소침 해질 필요가 없다’의 기조로 전달한 다면 서로의 기분이 상하지 않고도 더 나은 행동의 결과로 이어질 수 있습니다. 또한 프로젝트를 진행하는 과정 중에서도 개인의 역할과 책임의 부분을 분명 나누게 되겠지만, 프로젝트 자체는 협업의 큰 과정이기 때문에 개인의 실수를 ‘개인의 탓'으로만 두기에는 ‘우리 모두의 공동의 책임'인 것임을 잊지 말아주세요. “이 부분을 잘못하셨네요.” 라고 이야기 하는 것 보다 ”이 부분에 오류를 찾았어요. 저도 어렵더라고요. 우리가 같이 해결해볼까요?” 라고 이야기 하는 것이 훨씬 더 바람직한 결과로 이어질 수 있을 거에요. 나를 조금 낮추고 상대를 높이는 몇 마디 말이면 자칫 서로 어색하고 불편해질 수 있는 상황을 훨씬 부드럽고 현명하게 해결해 나갈 수 있다는 것! 꼭 기억해주세요.
- 개인의 선호나 가치관에 대한 사적인 대화는 가급적 지양해주세요.직장 동료에게 하기 어려운 말, 할 수 없는 것 같은 말, 그리고 조심스럽게 대해야하는 말들은 프로젝트 팀원들과도 마찬가지 입니다. 수강 동기, 학생 동지임을 넘어서 우리는 현재 실무를 예행하는 연습 중임을 기억해주세요.
- 많은 시간을 함께 하면서 가까워지고 편해지는 것 좋은 일이지만, 상대가 불편할 수 있는 대화의 주제는 가급적 지양하고 모두가 함께 참여하고 즐길 수 있는 대화를 지향하는 성숙한 관계를 진심으로 응원합니다!
- 개인적으로 여러분의 이후 네트워킹과 친밀한 관계의 유지에도 큰 관심과 응원을 보내드리지만, 프로젝트 기간 중에는 최대한 현업의 개발자들과 협업을 하는 ‘예비 비즈니스 관계'에 대한 연습이 진행된다고 생각해주세요.
칭찬과 격려를 아끼지 말아주세요.
미국의 저명한 심리학자 B. F. Skinner는 실험을 통해 긍정적인 행동에 대한 보상을 받은 동물이 부정적인 행동에 대한 처벌을 받은 동물보다 많은 양을 빨리 학습하고, 그 내용을 더 효과적으로 보유한다는 사실을 밝혀냈습니다. 그리고 이후 연구를 통해서 인간에게도 같은 원칙이 적용된다는 것을 보여주었다고 해요.
건강하지 않은 ‘피드백'이라는 탈을 쓴 비판이나 비난은 상대로 하여금 즉각적인 분노나 적의를 일으키는 것 뿐만 아니라 영구적인 행동의 변화를 이끌어 낼 수 없다고 합니다. 여러분도 누군가 나로부터 잘못을 지적 받거나 비난 받았을 때, 되려 자기방어적인 태도를 보이거나 스스로의 행동에 대해 정당화하려는 노력을 해보신 적이 있으실 겁니다. 우리는 모두 타인의 비난이나 단죄를 무서워하고 두려워 합니다.
그래서 우리는 팀원의 잘못에 대해 이야기 하기 보다는 팀원 개개인이 가진 장점과 재능이 보다 더 큰 시너지를 낼 수 있도록 격려하고 칭찬하는 것에 더 집중해야합니다.
격려와 칭찬을 받은 팀원은 본인이 잘할 수 있는 일에 대한 믿음과 동기부여를 받으며, 해당 일을 더 잘 성공하고자 하는 의지와 열정이 생겨날 것입니다. 자신이 노력한 분야에 대한 타인의 인정과 칭찬은 인간이 가진 가장 기본적인 욕구이며, 그 욕구가 충족되었을 때 더 넓고 깊은 능력이 발현될 수 있습니다.
여러분도 누군가가 보내준 몇 마디 칭찬이 작게는 하루의 기분을, 크게는 본인의 행동이나 미래를 바꾸어 놓은 경험이 있으실거라고 생각합니다. 영우가 문득 전달한 고마움의 칭찬이 봄날의 햇살 수연이의 눈가에 감동의 눈물이 고이게 한 것 처럼요.
기억하세요! 비난은 언제나 제자리로 돌아오기 마련이고, 진심에서 우러난 격려와 칭찬은 능력을 피어나게 합니다.
그럼에도 불구하고, 할 말은 해야 할 때
그럼에도 불구하고 웃는 얼굴의 칭찬과 격려만이 능사는 아니죠. 우리는 머리를 모아 최선의 결과를 내기 위한 과정 중에 있으니까요. 종종은 서로의 실수와 잘못에 대해 건강한 발전을 도모해야할 때도 분명히 있을 것입니다.
우리가 피드백을 원하는 이유는 단 한가지 입니다. 그것은 바로 내 팀원과 우리의 성장 인데요.
그렇기 때문에 피드백을 전달하는 이유와 목적은 저 방향성과 일치해야만 의미있고, 건강한, 정말 필요한 피드백이 됩니다.
- 좋은 피드백을 주기 위해서는 먼저 상대방을 충분히 이해 할 만한 상호 관계를 유지했어야 합니다.
- 상대방의 단편적인 모습이나 찰나의 실수, 또는 휴먼에러로 발생한 잘못된 판단 등으로 섣부르게 피드백 하는 것은 아닌지 돌아봐야합니다.
- 그리고 상대의 성장에 기여할만한 피드백인가? 를 고민해야합니다.
- 나의 섭섭함이나 답답함 등 부정적인 감정을 단순 전달하는 것이 아니라, 내가 전달하는 피드백의 내용이 팀원의 성장에 도움이 되게 하고, 팀 구성원의 성장은 우리 팀에도 도움이 된다는 믿음이 가는 피드백만 전달해주세요.
- 그러기 위해서는 실제 구체적 사례를 기반으로 이야기 할 수 있어야 합니다.
- 개인의 성향이나 특성이 일방적으로 반영된 감정의 싸움이 아니라, 어떠한 일이 왜 일어났는지 그리고 그것의 문제는 무엇이었다고 생각했는지 정확한 사례를 기반으로 이야기 해야 우리는 비로소 문제의 근본을 찾아 해결책을 강구할 수 있습니다.
이러한 내용을 통해서 피드백을 준다는 것은 결국 내가 하고 싶은 말을 하는 것이 아니라 상대방에게 필요한 말을 해주는 것 이라고 정의할 수 있겠습니다. 상대가 원하던 목적은 무엇이었을까? 나의 관점이 아닌 상대의 관점으로 상황을 이해하려고 하는 역지사지의 마음을 가져주세요.
아이러니 하게도 침묵이나 방관은 적절한 피드백을 ‘하지 않아서' 팀의 성장을 저해한 요소가 됩니다. 개인의 성장과 팀의 성장을 분리하여 생각하거나 불편한 감정을 느끼고 싶지 않아 거절하는 피드백은 장기적으로 침몰하는 배 입니다. 적절한 타이밍과 적절한 말, 그리고 적절한 어투까지 잘 전달하는 것 또한 매우 중요한 커뮤니케이션 중 하나입니다.
위에서 제시 된 내용을 충분히 숙지하고 행동으로도 적용하려 노력했음에도 불구하고 팀원 간 또는 팀 내에서 문제상황이 발생했을 경우,
망설이지 마시고 제게 도움을 요청해 주세요. 학습의 과정을 방해하는 것은 무엇이든 함께 고민하고 케어하는 것은 강의를 진행하는 제가 해야 할 의무와 책임이며, 여러분이 수강생으로써 충분히 가져가실 혜택과 특권입니다 🙂
주저하는 순간 문제의 상황이 더 악화될 수 있으니, 도움이 필요한 순간에는 빠르게 상황을 공유해주세요.
모두의 성공적인 프로젝트를 위해서
성공적인 프로젝트를 위해서
‘성공적인 프로젝트’란 무엇을 의미하는 것일까요? 그리고 무엇을 기준으로 그 ‘성공’을 판가름 할 수 있을까요?
지금 잠시 눈을 감고 ‘나에게 성공적인 프로젝트란?’ 무엇일지 고민해보세요.
아마 우리 모두의 생각은 모두 크고 작은 다른 점들이 있을거에요. 이처럼 개인의 생각과 때에 따라 성공의 정의는 다르게 내려질 수 있겠지만 한 방향을 바라보며 나아가길 지향하는 이번 교육에서는 크게 Hard Skill적인 목표와 Soft Skill적인 목표로 나눠 보도록 하겠습니다. 그리고 그 세부 항목들은 아래와 같습니다.
Hard-
- 직무에서 사용할 개발 기술 스팩들에 부합하는 프로젝트 성과물을 만들었는가?
- 만족할만한(취업에 경쟁력을 가질 만한) 포트폴리오를 만들었는가?
- 매일 팀과 개인의 크고 작은 실패와 성공의 로그를 남겼는가?
Soft-
- 프로젝트를 진행하며 동료를 신뢰할 수 있었는가?
- 성취의 경험에서, 그리고 실패의 경험에서 다시금 발판 삼을 교훈을 얻었는가?
- 커뮤니케이션과 협업 경험 전반에서 필요한 스킬들을 충분히 노력하고 습득했는가?
Hard Skill적인 목표에 대해서는 다음에 시작할 학습 컨텐츠를 통해 더 자세히 그 척도를 구분할 수 있게 될테니, 오늘은 Soft Skill 각 항목에 대해서 어떻게 생각해볼 수 있을지 이야기 해보도록 하겠습니다.
우리 팀은 서로를 신뢰할 수 있었는가?
열심히 학습하는 모든 날들의 시간은 우리가 기술적 지식을 습득하는 시간임과 동시에, 나와 비슷한 직무에서 함께 일하고 협업할 동료를 만나게 되는 시간이기도 합니다.
우리가 앞으로 개발자로서 몸 담게 될 업계는 개인이 해낼 수 있는 일이 거의 전무하며 모든 일은 팀으로 동료들과 함께 이뤄내야만 합니다.
미국의 유명한 소프트웨어 컴퍼니 ServiceNow의 CEO, Bill McDermott는 최근 한 비디오에서 “Trust remains the ultimate human currency. (동료간의 신뢰야말로 궁극적인 사람들 사이에서의 화폐이다)” 라고 말했죠. 사람은 결국 돈도 재화도 아닌 관계와 신뢰로 인해 움직인다는 말로 이해할 수 있습니다.
내가 동료를 신뢰 할 수 있기 위해서는 동료가 신뢰있는 사람이길 바라기만 하는 것으로는 충분하지 않습니다. 나부터 좋은 동료가 되기 위해서 앞서서 행동해야합니다.
우리가 앞서 학습한 좋은 커뮤니케이션의 예시들을 적극적으로 적용하고 스스로 시험하며 개인이 가진 역량을 끌어올리기 위해 노력하는 것도 좋겠습니다.
프로젝트 성패와 무관하게 내가 나의 동료를 전적으로 신뢰할 수 있고, 동료도 나를 믿어주었으며, 우리 팀이 프로젝트를 향해 달려온 길이 보람차다고 느껴질 때 우리는 개발자로서의 커리어를 함께하고 업계의 네트워킹을 함께 만들고 즐길 동료를 얻어갈 수 있게 된 것입니다.
성취의 경험에서, 그리고 실패의 경험에서 다시금 발판 삼을 교훈을 얻었는가?
우리는 종종 지나온 경험에서 교훈을 얻지만, 그 경험과 교훈 조차도 얼마 가지 않아 망각하고 맙니다.
망각은 인간의 너무나 자연스럽고 능동적인 삶의 방식 중 하나이지만, 우리는 앞으로 계속해서 성장할 개발자로서 이곳에서 느꼈던 크고 작은 일들에 대해서 보다 오랫동안, 자세히 기억하고 싶습니다. 좋은 자기소개서의 재료가 되어줄 뿐만 아니라 훗날 문득 돌아보았을 때 스스로를 동기부여 시켜줄 수 있는 좋은 에너지가 되어줄 수 있기 때문입니다.
무너져도 다시 일어나고, 끊임 없이 도전하는 것은 개발자로서 필수적으로 개발해야하는 숙명과 같은 Soft Skill 중 하나입니다. 내가 넘어졌던 경험과 다시 일어난 경험, 그리고 다시 도전 했던 소중한 경험들을 기록하는 것에 게으르지 마세요.
지금도 흐르고 있는 시간 속에서 지나가버리는 오늘의 나는 절대 다시 돌아오지 않으며, 오늘 느낀 감정을 기억에 의존하여 몰아서 기록하는 것은 결코 생생한 오늘의 경험을 담아낼 수가 없습니다.
과거의 내가 미래의 나에게 주는 스스로의 동기부여와 도전의식을 오늘의 게으름 때문에 놓쳐버리지 않으셨으면 좋겠습니다. 🙂
커뮤니케이션과 협업 경험 전반에서 필요한 스킬들을 충분히 노력하고 습득했는가?
기업들로 부터 신입 개발자들에게 더 요구되는 역량이 기술적인 능력을 나타내는 Hard Skill 보다 협업과 도전의식, 그리고 커뮤니케이션 스킬로 대변되는 Soft Skill의 중요성이 앞도적으로 높은 현상만 보아도 우리가 지금 이 시점에 더 집중해서 키워야하는 역량이 무엇인지 증명되기도 하죠.
기술과 학습의 경험에 대해서는 정량적으로 증명할 수 있는 기록이 남는 것이지만 도전의식이나 커뮤니케이션 능력에 대해서는 우리가 어떻게 증명해낼 수 있을까요?
백문불여일견.
‘저는 좋은 커뮤니케이션 스킬을 가지고 있는 사람 입니다' 라고 수백번 이야기 하고 이력서에 작성해두는 것보다 좋은 커뮤니케이션 스킬을 가지고 부드럽고 좋은 대화를 이끌어나가는 사람임을 느끼고 보여주게 하는 것이 훨씬 효과적일 것입니다.
좋은 소프트스킬을 가지기 위해서는 알고, 배우고, 이해하고 있는 것에서 그치는 것이 아니라 내 입으로, 손으로, 행동으로 연습하고 체득해 두어야만 합니다.
이번 프로젝트 기간 동안 다양한 Soft Skill적 기술에 대해서 깊이 이해하고 도전 하셔서 꼭 체득(體得)해 가셨으면 좋겠습니다.
여러분 어떠신가요? 위에서 말한 Soft Skill들을 키우기 위해 나는 준비된 사람이라고 생각되시나요?
여기서 준비된 사람이란 이미 이 스킬들을 잘 가지고 있는 사람이 아니라 이 스킬들을 습득하기 위해 두려움 없이 도전하고, 실패해도 다시 일어나며, 나의 도전을 기꺼이 남들과 함께 할 수 있는 열정이 있는 사람을 의미합니다.
당장 눈 앞에 놓여있는 숙제를 끝내기에 급급해 하는 근시안적 목표를 가지기 보다는 보다는 더 크고 넓은 목표가 무엇인지 끊임 없이 고민하고 그에 맞게 도전하시는 여러분이 되시길 바랍니다.
걱정 스트레스 극복과 셀프 컨트롤
걱정과 스트레스는 가지지 않은 사람이 없는, 인간이 인간임을 증명하는 하나의 기재이기도 하죠. 때로는 우리를 움직이게 하는 동기부여가 되어주기도 하고요.
하지만 걱정과 스트레스가 올바른 방향으로 해소되지 않은 채, 또는 스스로가 조절할 수 없는 만큼의 걱정과 스트레스의 정도가 올랐을 때 우리는 매너리즘에 빠지기도 하죠.
업무 특성상 time-sensitive(분초를 다투는) 일이 많은 개발자에게는 더더욱 올바른 걱정 스트레스 해소 능력과 셀프 컨트롤 능력이 필수적이라고 할 수 있습니다.
어러분은 스트레스가 많을 때, 어떻게 해결하려고 하시나요?
스트레서(Stressor, 스트레스의 원인) 찾기
- 먼저, 스트레서(Stressor)와 스트레스(Stress)를 구분해보세요.감정과 정서를 구분하자면, 감정은 개인의 기질이나 성격적 특성이 우세하게 드러나는 일종의 기분입니다. 그에 반해 정서는 주변 환경과의 상호작용에서 일어나는 개인의 반응이라고 볼 수 있습니다.지금 내가 스트레스를 받고 있다면, 어떤 문제나 상황 때문에 왜 스트레스를 받고 있는지 그 원인을 찾아보세요.
- 그렇기 때문에 정서의 경우, 특정 정서를 가지게 된 원인을 비교적 구체적으로 찾아 묘사할 수 있습니다.
- 우리가 스트레스를 받는 다고 생각하는 것은 하나의 감정적인 정서 입니다.
- 원인(스트레서)을 찾았다면, ‘피할 수 있는/제거할 수 있는’ 스트레서인지 구분해보세요.하지만 우리 앞에 있는 스트레서를 당장 제거해버리거나, 내가 피할 수도 없는, 나의 힘으로 바꿀 수 없는 무엇이라면 어떻게 해야할까요?
- ‘피할 수 있다면 피하세요’ 스트레스를 해소할 수 있는 가장 쉽고 빠른 방법입니다. 너무 당연하죠. 여러분, 제거할 수 있는 스트레스라면 빨리 그 곳을 벗어나 피해버리세요.
- 할 수 있는 만큼 아주 작게 조각내세요.프로젝트를 예를 들어, 지금 나의 실력으로 프로젝트를 완성해내야하는 것 자체가 굉장히 거대해보이고 불가능 한 일을 해내야하는 것 처럼 중압감이 느껴지고 감당할 수 없는 스트레스가 느껴진다면, 만들 수 있는 가장 작은 단위 (eg. 오늘 끝내야하는 일들 계획세우기, 프로젝트 개요 완전 숙지하기, 프레임워크 설치 완벽히 하기 등)로 쪼개보세요.하나하나 완수 할 때마다 느껴지는 성취감은 덤이고요 🙂
- 하루에 해야하는 일들도, 코드스테이츠가 제공하는 step 이상으로 내가 하나씩 쉽게 완수해 나갈 수 있도록 조각내어서 차근차근 수행해보세요. 큰 조각을 끝내야한다고 생각했을 때 보다 훨씬 쉽고, 빠르고, 수월하게 도달해나갈 수 있으실 겁니다.
- 내가 피할 수 없는 문제를 해결해야한다면, 그 문제를 가능한 한 제일 작은 단위로 조각내어 하나씩 하나씩 해결해보세요.
건강 관리 하기
약 17주간의 학습과 약 5주간의 프로젝트 기간은 결코 짧은 시간이 아니며, 대부분의 시간을 컴퓨터 책상 앞에서 의자에 앉아 보내는 시간은 우리 몸의 건강에 절대적인 영향을 미칠 수 있습니다.
몸에 축적되는 피로감과 자세의 불균형으로 오는 건강이상은 장기적인 우리의 목표 달성에 치명적인 영향을 미칠 수 있을 뿐만 아니라, 걱정과 스트레스 등 정신적 위태에도 더 쉽게 노출 될 수 있습니다.
건강하지 않은 라이프스타일과 건강은 개인의 업무 생산성 감소, 창의력 감소에 영향을 미치며, 개인의 근태(지각, 결석등의 성실도)와 기분이나 감정에도 부정적인 영향을 미친다는 연구 결과가 있습니다. 어쩌면 너무 당연한 일이겠죠!
장시간 앉아 학습하시면서 큰 시간과 노력을 들여 운동을 하고 건강한 식단을 유지하는 것은 굉장히 어려운 일이겠지만 나의 목표를 이뤄내는데 중요한 일임을 꼭 기억하시고 하루에 한번 이상 산책과 간단한 스트레칭 등 쉽지만 꾸준히 할 수 있는 자신만의 방법을 찾아주세요.
충전을 위한 휴식 시간 완전히 구분하기
우리는 종종 학습의 시간에 제대로 끝내지 못한 일들을 생각하느라 휴식시간 까지도 퀄리티 있게 보내지 못하는 실수를 저지르곤 합니다. 쉬고 있지만 온전히 쉼에 집중하지 못하고, 그렇다고 일을 해낸 것도 아닌, 이도 저도 아닌 시간을 보내버리는 실수 말이에요.
휴식을 위한 시간에 휴식과 쉼에만 온전히 집중하기 위해서는 생산적인 시간을 잘, 충분히, 만족스럽게 보내는 것이 선행되어야만합니다.
일주일을 온전히 알차게 보낸 스스로에게 주말 반나절 쯤은 온전하게 본인만을 위한 휴식을 선사해주세요. (주말에는 쉬세요! 라고 말하지 못하는 코드스테이츠의 마음도 이해해주세요 😂 못다한 학습과 끝내지 못한 프로젝트를 마무리 하는 시간으로도 활용되어야합니다)
개인에게 필요한 온전한 휴식을 위한 시간을 정했다면 팀원들과도 공유하여 해당 시간 동안 방해받지 않고, 혹여나 나에게 연락이 올까, 나의 도움이 필요한 일이 생길까, 내가 협조하지 않는 것 처럼 보일까 하는 걱정과 우려 없이 온전한 휴식을 취할 수 있으실 겁니다.
모두가 열심히 일해야하는 만큼 좋은 휴식을 취해야하는 것도 명심해주세요! 건강이 항상 우선입니다 🙂
배포 환경 구축 안내
진행하는 프로젝트에서 배포는 어떤 방식으로 배포해도 상관없습니다. 다만, 배포는 팀원간의 합의를 꼭 거쳐서 진행합니다. 팀이 직접 AWS 그룹 계정을 하나 생성하고, AWS를 직접 체험하면서 배포하는 것을 권장합니다. AWS 그룹 계정를 직접 생성하면 아래 특징이 있습니다.
- 학습 내 실습 환경은 몇몇 리소스만 활용할 수 있어, Project에 AWS 신기술을 적용하기 어렵습니다.
- 학습 내 제한된 실습 환경과는 달리, AWS의 다양한 기능을 직접 만져보며 실무와 같은 환경에서 실습할 수 있습니다.
- 백엔드, DevOps 개발자에게 필요한 네트워크 및 보안 관련 설정을 직접 경험할 수 있습니다.
- VPC, Internet Gateway
- 보안 그룹 설정
- 도메인 구매 및 적용
- 필요에 따라 다른 IAM 권한 부여
- 서버리스(Lambda, DynamoDB 등) 관련 AWS 기술
- 백엔드, DevOps 개발자에게 필요한 네트워크 및 보안 관련 설정을 직접 경험할 수 있습니다.
- AWS 그룹 계정을 보유하면 AWS Cost Explorer를 사용 가능하고, 비용 Tracking을 직접 할 수 있습니다.
- AWS Free Tier 내에서 무료로 이용 가능합니다.
- 처음 생성한 그룹 계정에 대하여, 12개월간 아래 조건을 만족하는 경우 무료로 사용할 수 있습니다. 정확한 정보는 AWS Free Tier 페이지를 확인합니다.
- S3: 5GB / Get 요청 50,000건 / …
- EC2: t2.micro / 월별 750 시간 / …
- RDS: t2.micro / 월별 750 시간 / …
- 아래 제안하는 AWS dev 배포 환경을 구성하면, 2달 간은 과금이 거의 되지 않습니다. 다만, Main-Project 이후에도 계속 외부 배포를 원한다면 월별 과금이 될 수 있습니다. (월 $38.10 구성, 2022년 8월 기준 : S3, EC2, RDS 구성) 프로젝트 이후 AWS 서비스 및 인스턴스를 모두 삭제하면 해당 시점 이후로 과금이 되지 않습니다.
- 위 정보 및 예상 비용 계산 결과는 참고용이며, 해당되는 세금은 포함하지 않습니다. 실제 요금은 AWS 서비스의 실제 사용량을 포함하여 다양한 요소에 따라 달라질 수 있습니다.
- 실수로 과도한 과금이 되는 경우 AWS 고객센터에서 경우에 따라 환불을 해주는 경우도 있습니다. 가능하면 과도한 과금이 되지 않게 명확한 AWS 사용 계획을 세우는 것이 좋겠지만, 우연한 실수로 과도한 과금이 되는 경우에도 최악의 경우는 피할 수 있습니다. 구글링 결과를 참고하세요.
- 기타 자세한 문의는 AWS 공식 창구 - AWS에 문의하기를 이용바랍니다.
- 처음 생성한 그룹 계정에 대하여, 12개월간 아래 조건을 만족하는 경우 무료로 사용할 수 있습니다. 정확한 정보는 AWS Free Tier 페이지를 확인합니다.
직접 AWS가 아닌 다른 클라우드 서비스, 혹은 실물 서버를 활용하여 배포할 수도 있습니다. 다만, 기존에 학습한 내용이 아닌 추가 학습이 필요한 부분으로 팀 내에서 합의를 이뤄 진행하기 바랍니다.
- AWS가 아닌 다른 클라우드 환경(GCP, Azure, Naver Cloud)에서의 개발 및 배포 경험
- 금융권이나 정부 기관 등 보안이 중요한 개발에서 프라이빗 망을 직접 설계하는 경험 가능
dev 배포 환경 제안
로컬 환경에서도 테스트할 수 있지만, 프론트엔드 개발자가 서버의 변경 사항을 빠르게 파악하기 위해서는 시시각각 업데이트되는 dev 서버가 있으면 좋습니다.
EC2에 클라이언트, 서버 모두 배포
- EC2에 프론트엔드 코드를 빌드하고, 루트 경로로 배포합니다.
- 서버는 http://{도메인}/api 경로에 REST API를 설계합니다.
- EC2와 RDS를 연결합니다.
- 장점
- 8080포트를 사용한 빠른 배포 및 테스트
- 단점
- 배포 시 프론트엔드와 백엔드가 같이 배포해야 해서 배포 난이도 상승
- 프론트엔드 빌드 시 proxy 설정 필요 (create-react-app 공식문서)
S3 정적 웹사이트 배포 + EC2 서버 배포
CORS를 허용하고, S3 정적 웹사이트 배포 기능을 활용할 수도 있습니다.
- 프론트엔드 빌드 결과물을 S3에 배포하고, 정적 웹사이트 배포 기능을 활용하여 접근 가능한 도메인을 얻습니다.
- 서버는 EC2에 정상적으로 배포합니다.
- EC2와 RDS를 연결합니다.
- 장점
- 프론트엔드 코드 단독 배포 가능
- 단점
- 도메인이 없으면 CORS를 허용하여 동일 출처 정책(SOP: Same-Origin Policy)을 지킬 수 없음
Do it yourself!
실제 production 서버가 아닌 개발 서버는 다양한 방식으로 배포하고 테스트해볼 수 있습니다. (지금 당장은) 로컬 환경에서 직접 서버를 키고 테스트해도 상관없습니다. 개발용 서버 배포를 위한 방식을 소개합니다.
- RDS 3306 포트를 열고, 모든 팀원이 서버를 직접 켜서 테스트
- 모든 IP에 3306 포트를 여는 것은 잠재적인 보안 위험이 있기 때문에, 가능하면 dev 배포 환경을 구성하는게 좋습니다.
- 로컬 서버를 빠르게 인터넷으로 배포: ngrok
- HTTP를 사용하는 경우 잠재적 보안 위험이 있습니다.
production 배포 환경 제안
AWS HTTPS 배포
실제 완성한 프로젝트를 배포하는 경우에는 아래 정도의 AWS 구조를 갖추기를 권장합니다.
- 프론트엔드 배포 프론트엔드는 아래 AWS 리소스를 활용하여 HTTPS 배포합니다. Route 53으로 팀이 소유한 도메인과 CloudFront를 연결하고, CloudFront는 S3로부터 프론트엔드 정적 파일(HTML, CSS, JavaScript)를 가져와서 제공합니다. S3에 직접 접근하는 것 보다 캐싱을 통해 전 세계 어디서든 빠르게 접근할 수 있습니다. HTTPS 통신을 위해 ACM으로 인증서를 발급받아 CloudFront에 적용도 필요합니다.
- Route 53: 사용자의 요청을 EC2 인스턴스, ELB 로드밸런서, S3 버킷 등 AWS 내의 인프라에 연결시켜주며, AWS 외부의 인프라에도 연결 시킬 수 있습니다.
- CloudFront: 전 세계 티어 1,2,3 의 이동통신사와 협력하여 네트워크에 연결된 글로벌 CDN(Content Delivery Network) 서비스입니다.
- S3: 객체 스토리지로 데이터 백업, 정적 웹사이트 호스팅, 애플리케이션 호스팅, 재난 복구, 콘텐츠 배포, 데이터 레이크, 프라이빗 저장소 등에 활용할 수 있습니다.
- 백엔드 배포Route 53으로 팀이 소유한 도메인과 ELB를 직접 연결하고, ELB의 Application Load Balancer 기능을 활용하여 리스너에서 받은 요청을 타겟 그룹인 EC2로 redirect합니다. EC2와 RDS는 하나의 private subnet과 보안 그룹 내에 위치시켜서 외부에서 SSH나 3306 포트로 접근할 수 없게 막고 오직 ELB → EC2 → RDS를 통해서만 접근할 수 있도록 합니다. HTTPS 통신을 위해 ACM으로 인증서를 발급받아 ELB에 적용도 필요합니다.
- ELB: Elastic Load Balancing은 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산합니다. 등록된 대상의 상태를 모니터링 하면서 상태가 양호한 대상으로만 트래픽을 라우팅 합니다.
- Application Load Balancer: ELB의 기능 중 하나로 OSI 모델의 레이어 7에 해당하며, HTTP와 HTTPS를 지원합니다. 로드 밸런서는 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여, 적용할 규칙을 결정한 다음 규칙 작업의 타겟 그룹에서 타겟을 선택합니다. 애플리케이션 트래픽의 콘텐츠를 기반으로 다른 타겟 그룹에 요청을 라우팅하도록 리스너 규칙을 구성할 수 있습니다.
- EC2: EC2를 사용하면 하드웨어에 투자할 필요 없이 빠르게 애플리케이션을 개발하고 배포할 수 있으며, 원하는 만큼 가상 서버를 구축하고 보안 네트워킹을 구성하며, 스토리지를 관리할 수 있습니다.
- RDS: Amazon RDS를 이용해 데이터베이스를 호스팅 하면, AWS가 데이터베이스 설치부터 업그레이드 등, 데이터베이스 호스팅과 관련된 모든 복잡한 업무를 대신 처리합니다. 사용자는 애플리케이션 최적화에만 집중하면 됩니다.
- ACM: AWS 서비스 및 연결된 내부 리소스에 사용할 공인 및 사설 SSL/TLS(Secure Sockets Layer/전송 계층 보안) 인증서를 손쉽게 프로비저닝, 관리 및 배포할 수 있도록 지원하는 서비스입니다. SSL/TLS 인증서는 네트워크 통신을 보호하고 인터넷상에서 웹 사이트의 자격 증명과 프라이빗 네트워크상에서 리소스의 자격 증명을 설정하는 데 사용됩니다. AWS Certificate Manager는 SSL/TLS 인증서를 구매, 업로드 및 갱신하는 데 드는 시간 소모적인 수동 프로세스를 대신 처리합니다.
위 구조는 간단한 웹 애플리케이션을 배포하기에 충분하나, 아래 단점이 있습니다.
- 한 리전의 하나의 AZ에 기반하여 구성되어서 해당 AZ가 비활성화되면 서비스가 중단될 수 있습니다.
- 대규모 요청이 몰려와서 서버가 과부하되는 경우, 서버를 scale-up(종적 확장; vertical scaling)할 수 밖에 없고, Scale-out(횡적 확장; horizontal scaling)할 수 없습니다.
- 배포 자동화가 적용되어있지 않아, 개발 속도에 제한이 있습니다.
- …
향후 아래 레퍼런스를 참고하여 어떻게 하면 더 안전하고 빠른 웹 애플리케이션을 배포할 수 있을지 학습하기 바랍니다.
- AWS로 3티어 아키텍쳐 구현하기
- AWS Korea - VPS 기본 및 연결 옵션
- AWS Builders - 천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기
- AWS Innovate - AWS 기반 현대적 웹 애플리케이션 구축 (입문)
- AWS re:Invent 2020 - 대용량 자바 애플리케이션 클라우드 네이티브 아키텍처 적용기 (AWS, 삼성전자)
AWS를 이용한 HTTPS 배포는 AWS 서비스를 상당히 많이 이용해야 하기 때문에, 러닝 커브가 다소 있는 편입니다. 배포가 실패했다고 좌절하지 않고, 최선을 다해서 도전하는 것이 중요하다는 점을 다시 강조합니다. 특히, Pre-Project에서는 어려울 수 있고, Main-Project에서 도전할 만 합니다.
기타 환경에서 HTTPS 배포
AWS가 아닌 다른 배포 환경에서 배포를 하는 경우 최소한 아래 조건을 준수하기 바랍니다.
- 도메인 적용
- HTTPS 통신 적용
- DB 직접 접근 제한
- Twelve-Factor 방법론 적용 노력
배포 환경 구축 레퍼런스
EC2 인스턴스 생성 및 연결
보안 그룹
S3 정적 웹 사이트 호스팅
RDS 인스턴스 생성과 연결
ELB와 ACM으로 백엔드 HTTPS 구성
ELB와 ACM으로 백엔드 HTTPS 구성
docs.google.com
Route 53으로 도메인과 ELB를 연결
Route 53으로 도메인과 ELB를 연결
docs.google.com
CloudFront와 ACM으로 프론트엔드 HTTPS 구성
CloudFront와 ACM으로 프론트엔드 HTTPS 구성
docs.google.com
Route 53으로 도메인과 CloudFront를 연결
Route 53으로 도메인과 CloudFront를 연결
docs.google.com
