오늘은 인턴 8일차4일차에서 이 글을 쓰기 시작한 나
강한 나로 거듭나는 중입니다. 삐그덕삐그덕 대는 중...
어쨌든 나의 사수는 일주일 내내 친절하게 내주신 업무 힌트까지 주셨다고 한다.
내가 잘 몰랐던 리액트 개념이 종종, 아니 많다 보니 다른 사람 코드를 보고 최대한 결을 유지하면서 픽스하는 편인데, 그게 가끔은 독이 될 때가 있다. 오늘도 그걸로 지적을 받았슴다.
좋아요, 나를 의심하지마~!아니야 꾸준히 의심하렴
나의 개같은 코드를 보고도 웃어주시는 우리 사수님은... 그런 사수를 만난 나의 인복은..
그래도 맥북프로16인치도 너무 사랑스럽고.. 의도치 않은 재택 때문에 그냥 공부하고 있는 것 같고 그래요.
일주일 동안 셀 수 없이 많은 실수를 했지만 일기장에 적고 묻어버렸습니다.
이번 주에 정리할 큰 개념들만 아래에 정리해 보았답니다.
정리+회고+복습이 담겨 있는..
1. Git Flow
Git에는 버전관리를 위한 여러가지 기능들이 있는데, 그 중에서도 브랜치가 있다.
브랜치는 말 그대로 나무의 나뭇가지들을 생각하면 되는데, 나무의 큰 몸통이 가장 메인이 되는 master branch이고 뻗어나가는 수많은 가지들이 메인에서 파생된 다른 branch이다.
마스터(메인) 브랜치는 하나고 파생 브랜치는 만들고 싶은 만큼 만들 수 있다. 이때 브랜치를 관리하는 것도 꽤나 노력이 필요한 일이다. 브랜치를 열고 작업을 한 뒤에 그 작업이 다 끝나서 실제 release 수준까지 올라오면 마스터에 합치고 브랜치를 닫는다. 근데 브랜치를 여는 목적도 각양각색이고, 정말 빨리 끝내야하는 작업(hotfix)과 그렇지 않은 작업이 있을 수 있다.
그래서 이번 회사에서는 git flow를 활용해 협업을 한다.
https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html
git을 쓰긴 썼지만 프로젝트를 할 때도 굳이? branch까지 열 상황은 잘 안 나왔다. 프론트, 백 전문가가 각자 파트를 맡는다기보다는 다 같이 하면서 공부하고 배운 적도 있었고, 각자 해도 구현할 기능이 그리 많지 않아 오전에는 프론트가 오후에는 백이 작업을 하면 되는 상황도 있었다.
그런데 이제는 각자 다른 task를 할당하고, 그 task의 목적도 '새로운 기능 구현'으로 통일된 게 아니라 bug fix, improvement 등으로 다양해지기 때문에 branch를 목적에 맞게 나눠 생성할 수 있는 Git Flow가 필요해진 것이다.
2. 애자일 프로세스
평소에도 난 굉장히 모순적인 사람이다. 안정적인 것을 좋아하지만 그렇다고 변화를 싫어하지도 않고, 장기 계획을 그리 선호하지는 않지만 체계적인 건 또 좋아한다. 결국 무엇이든 중간, 반반을 좋아하는 성격 탓에 모순적인 것처럼 보이는 것 같다. 소프트웨어공학 수업을 들을 때도 Waterfall 기반의 RUP(Rational Unified Process)도 강력해보이고, Agile도 쿨해보였다. 실제로 회사에서는 Agile 개발 방법을 채택하고 있었다.
waterfall의 일차적인 실패의 원인이기도 했던 "무슨 일이 있어도 단계를 다시 거슬러 올라가지 않는 특성"을 지양하는 Agile은 그야말로 "놓치면 다음 번에" 마인드라고 생각하면 쉽다. 마치 내 인생
이쯤에서 waterfall과 agile이 뭔지 궁금해할 분들을 위해.. 그 전에 소프트웨어 공학이 무엇인지에 대한 이해가 선행되어야 한다.
⭐ 소프트웨어 공학이란?
가르쳐주신 교수님의 말을 빌리자면.. (아직도 외우고 있다)
Software engineering is concerned with theories, methods, and tools for professional and cost-effective software development.
특별한 말은 아니고, 소프트웨어를 professional하고 cost-effective하게 개발할 수 있도록 하는 다양한 이론, 기법, 도구들을 의미한다고 보면 된다.
그럼 왜? 왜 소프트웨어 공학을 알고 적용시켜야 할까?
소프트웨어 공학은 주로 여러 사람이 큰 시스템을 개발할 때 적용된다. 그리고 유지보수가 필요할 때도.
그래서 왜? 내가 이해하기로는, 프로젝트를 실패하지 않기 위해서에 가깝다.
대체로 기법이라는 것은, '이런 형식을 따르면 최소 이 정도의 결과물은 나옵니다'라고 보장해주는 것과 비슷하다.
그렇기 때문에 다양한 기업에서 다양한 프로젝트를 실패했던 과거에, 더 이상 실패하지 않기 위해 waterfall이라는 소프트웨어공학 모델(기법)이 개발되었다.
⭐ Waterfall model이란?
1960년대, The Software Crisis가 발생하면서 많은 프로젝트들이 실패했다. 한 사람이 개발하던 시스템을 여러 사람이 개발하려고 했던 것이다. 나는 그 당시를 '협업'을 처음 하는 사람들만 잔뜩 모여 본인의 퍼포먼스를 뽐낼 줄만 알던 시절이라고 이해했다. 가끔은 이런 상상력이 필요하다
이 software crisis를 타개하기 위해 Software Engineering(소프트웨어공학)의 개념이 등장했고, 가장 처음 나온 모델이 바로 Waterfall model이다.
교수님이 Waterfall은 꼭 영어로 말하라고 했다. 폭포수 모델은 멋이 떨어지니
폭포가 중력에 따라 위에서 아래로만 흐르듯이, 소프트웨어를 개발할 때도 단계 별로, 순서대로 진행하라는 뜻이다. 여기에서 중점적인 것은 '역류하지 말 것'
주로 다섯 단계로 구분한다.
Waterfall Model Process
1. Requirements definition
2. System and software design
3. Implementation and unit testing
4. Integration and system testing
5. Operation and maintenance
design, implementation을 합쳐 네 단계로 합쳐 구분하기도 한다.
어찌 됐든 이 순서대로 거슬러 올라가지 않고 개발하면 실패할 확률을 줄여준다는 게 Waterfall 모델의 key point였다. 실제로 꽤 오래 의미 있게 활용되었고, 지금까지도 다양한 모델과 기법의 근간이 되고 있다.
그럼 왜 실패했냐? 가장 중요한 건 거슬러 올라갈 수 없다는 점이다. 개발 초기에 모든 기능을 생각해내고 이를 구체화시키는 작업을 하기에는 무리가 있다. 중간에 기능을 추가하게 될 수도 있고, 삭제하고 싶을 때도 있다. 하지만 초기 Waterfall에서는 절대 불가능한 일이었다. 결국 여러가지 변형을 통해 이를 개선하였지만, 그럼에도 변하지 않는 것이 하나 있었다.
명세 작성 등의 문서 작업. SRS, SDS, AD ... 정말 많다. 과연 이게 몇장으로 정리될까? SRS 기본 틀만 봐도 만만치 않음을 알 수 있다. 특히나 개발을 해봐야 채울 수 있는 부분들이 종종 있는데(여러가지 이유로) Waterfall에서는 그런 것도 용납하지 않거니와, 그때그때 적어야 할 문서를 완벽하게 작성해놔야 한다.
문서 작업에 질려버린 사람들이 만들어낸 것. 그것이 바로 Agile이다.
Agile은 변화를 두려워하지 않다. 뭐든지 fix하고 보는 Waterfall은 절대 No변화를 외치지만 Agile은 항상 변화에 대비한다. Agile에 대해서는 곧 자세하게 정리할 예정이라서 짧게 스탠스 정도만 소개하고 넘어가겠다.
⭐ Agile 기법이란?
Agile은 많아도 너무 많은 형식적인 문서 작업에 지쳐버린 사람들 사이에서 1980년대에 등장해 1990년대까지 유행하던 기법이다. Agile은 비슷한 목적과 배경을 지닌 광범위한 기법들을 아울러 부르는 일종의 umbrella term이라, model로 분류하지 않고 method로 분류한다.
페어 프로그래밍, 리팩토링, TFD 같은 개념들이 전부 Agile 개발 테크닉 중 하나다.
Agile 프로젝트 관리 기법에도 여러가지가 있는데, 대표적으로 스크럼과 스프린트를 떠올릴 수 있다.
어쨌든 스타트업 특성 상 사람이 적어 체계를 잡기도 모호하고, 프로젝트 초기 단계에서는 기능 요구사항을 fix하기도 쉽지 않다. 변화에 빠르게 대처하고 적응해야 하는 생태계이기 때문에 스타트업에서는 Agile 기반의 개발을 선호하지 않을까 싶기는 했다.
자 이제 본론
어쨌든, 회사에 들어가 난생 처음 스프린트와 스크럼을 겪어봤다. 단기 계획과 잦은 회고는 체계를 정립하는 데에도 도움이 되는 것 같다는 감상평
내 상상과 조금 다른 부분도 있었다. 스크럼에서는 본인이 업무한 내용을 자세하게 공유하는데, 전체 스크럼에서는 모두가 이해할 수 있는 선에서만 공유를 했다. 물론 개발자들끼리 하는 스크럼에서 다양한 이야기를 추가로 나눠서 커뮤니케이션에 무리는 없었지만 생각보다 개발자와 비개발자 간의 간극이 느껴지는 건 기분 탓만은 아닌 것 같았다.
그래도 기획, 디자인 쪽 분들도 이해하려고 많이 노력하시는 것 같았다. 아무래도 업무나 분야 별로 같은 단어라도 세부적인 뜻이 다를 수 있어 발생하는 커뮤니케이션 상 오류도 대부분 문제가 발생하기 전에 스크럼이나 회고에서 정확히 짚고 넘어가서 좋았던 것 같다.
학생들끼리 프로젝트를 해서 그런지 원래 다 그런지는 몰라도, 프로젝트 진행 중에 소통의 부재로 인한 문제들이 가끔 발생했다. 이럴 때 스크럼이 있었다면 좋았을텐데 싶었다. 많이 배우고 체화하여 적용할 예정이다.
이외의 툴들은 공개해도 될지 모든 구조를 공개하기에는 대외비가 아닐지.. 걱정되어 이쯤하겠다.
비밀 유지 서약서 같은 건 쓴 적 없다
이외에 코딩하면서 찾아보고 배웠던 것들이 은근 많아서 어떻게 정리해야 할 지 고민이다.
어떻게 하다보면 될 것 같다. 내일의 내가.
저도 이만 날아가보도록 하겠습니다. 그럼 20000. 👊
