[개발 공부 61일차] 그간의 상황 및 앞으로의 계획 | 트러블슈팅, MVP, CI/CD

오랜만의 블로그 포스팅이다. 이번 주까지 너무 많은 일이 있어서 블로그 쓸 여력이 안 됐다. 이제부터 다시 꾸준하게 작성해야겠다. 오늘은 직전 심화 프로젝트 관련 내용과 배우긴 하였으나 정확히 무슨 의미인지 뇌에 남지 않은 내용 위주로 담으려고 한다.

 

 

< 목차 >
1.로그인, 회원가입 페이지 | 비밀번호 입력할 때마다 UI 크기 변경됨
2. 이메일, 비밀번호 | 입력 필드 초기화, 텍스트 토글 기능
3. Git Pull 안 됨 | git pull --rebase로 해결
4. BaaS (Backend as a Service)
5. CI/CD
6. MVP (Minimum Viable Product)
7. 금일 소감

 

 

1.로그인, 회원가입 페이지 | 비밀번호 입력할 때마다 UI 크기 변경됨

기능 구현을 완료해서 UI를 예쁘게 바꾸던 중, 자꾸 비밀번호 입력 필드를 작성하면 넓이가 변경되는 문제가 발생하였다. 문제의 원인이 정말 비밀번호 작성 때문인 건지 곰곰히 생각해보다가 비밀번호를 입력해서 문제가 발생한 거라고 하기엔 문제 정의가 정확하지 않은 것 같다는 생각이 들었다.

 

계속 비밀번호를 작성하고 지우고를 반복하다가 validation 텍스트 길이만큼 너비가 넓어진다는 것을 알았다. 그래서 그 너비만큼 Width를 계산한 뒤, 다른 HTML에도 Width Style을 동일하게 줘서 해결했다.

 

 

구체적인 과정은 다음과 같다.

 

 

 

 

개선 전에는 이렇게 입력 필드 너비가 소심하게 만들어졌다가

 

 

 

 

"* 영문, 숫자, 특수문자 포함 8자 이상 입력해주세요." 텍스트가 화면에 나타나면 너비가 그 텍스트 길이만큼 조정되었다. 그래서 어떻게 해결할까 하며 이런저런 시도를 많이 해보다가 답이 생각났다.

 

"* 영문, 숫자, 특수문자 포함 8자 이상 입력해주세요."를 화면에 작성 안 해도 나타나게 띄우고 너비를 측정하는 함수를 만들어서 측정했다.

 

 

 

 

 

326px.... 그래서 넉넉하게 330px을 Tailwind CSS로 적용하려고 했는데 Tailwind로 적용하려면 커스텀 CSS를 따로 만들어야 하는 불편함이 있길래 어쩔 수 없이 Style로 적용했다.

 

 

너비를 측정하는 함수와 style 적용한 코드

 

 

하,, 이것 때문에 시간 좀 썼다. 근데 어차피 로그인 CSS만 잘 해놓으면 회원가입 로직에도 똑같이 적용하면 돼서 그나마의 위안으로 삼을 수 있었다.

 

 

 

2. 이메일, 비밀번호 | 입력 필드 초기화, 텍스트 토글 기능

 

 

로그인, 그리고 특히 회원가입 시에 비밀번호 확인하라고 한 번 더 입력하는 게 늘 귀찮고 불편했던 나는 Auth를 구현하면서 회원가입 시에 꼭 비밀번호 확인을 빼겠다고 다짐하고 실제로 실행했다.

 

비밀번호를 확인하는 이유는 사용자가 비밀번호를 정확하게 작성하였는지 스스로 다시 확인하게 하려는 것인데, 아마 비밀번호를 보이게 하면 보안상의 문제가 있을 수 있으니 그냥 다시 작성하게끔 하는 웹 사이트가 많을 것이라고 예상한다.

 

난 비밀번호가 보였다, 안 보였다 하는 토글 기능이 훨씬 나을 것 같아서 위 사진처럼 UI를 저렇게 적용했다. 입력을 굳이 불필요하게 또 작성해야 하는 불편함이 없어지고 속 편하게 잘 작성했는지 확인할 수 있어서 확실히 더 편했다.

 

 

 

 

위 코드는 이메일 입력 필드를 초기화하는 코드와 비밀번호를 보였다 안 보였다 하게 하는 토글 코드다.

 

입력 필드를 초기화하는 코드는 그냥 UI 코드를 가져다 쓰면 되는 줄 알았는데 UI 코드를 보니 그냥 console.log("reset") 이런 식으로 적혀 있어서 '?' 하다가 '아, 알아서 함수 작성하란 거구나' 싶어서 위 왼쪽 사진과 같은 레퍼런스 참고해서 오른쪽 사진처럼 코드를 작성했더니 잘 작동하였다.

 

 

 

3. Git Pull 안 됨 | git pull --rebase로 해결

rebase

 

 

Commit 하고 Push 한 뒤, dev branch에 있는 코드를 pull 해오려고 하면 곧바로 안 돼서 Error가 떴다. 나만 그런 것도 아니고 다른 팀원도 그러길래 나와 같은 Error가 뜰 때, 해결해주었다. 보통 git pull --rebase 를 작성하여 Pull을 진행하면 해결되었다.

 

rebase는 한 브랜치에서 다른 브랜치로 변경 사항을 통합하는 데 특화된 2가지 Git 유틸리티 중 하나다. 또 다른 변경 통합 유틸리티는 git merge라고 한다.

 

나중에 잠깐 틈이 생긴다면 Git에 관해 공부를 깊게 해봐야 할 듯하다. 심화 프로젝트를 하며 rebase 등 Git 명령어를 작성할 때, 어떤 오류가 뜨고 어떻게 해결해야 할지 알아볼 필요성이 엄청 크게 들었다.

 

 

 

4. BaaS (Backend as a Service)

: 클라우드 서비스 모델의 일종으로, 앱 개발자들이 서버 측 로직과 백엔드 기능을 클라우드 기반 서비스를 통해 쉽게 구축, 호스트 및 운영할 수 있도록 지원한다.

 

BaaS 제공자는 데이터베이스 관리, 사용자 인증, 클라우드 스토리지, 메시징 서비스 같은 백엔드 서비스를 관리함으로써 개발자가 클라이언트 측 개발에 더 집중할 수 있게 해준다.

 

BaaS와 유사한 개념으로는 다음과 같은 것들이 있다.

1. IaaS (Infrastructure as a Service): 가상화된 컴퓨팅 리소스를 인터넷을 통해 제공한다. 사용자는 네트워크, 서버, 데이터 스토리지 공간 등의 인프라를 필요에 따라 쉽게 확장하거나 축소 가능하다.
2. PaaS (Platform as a Service): 앱 개발 및 배포를 위한 플랫폼과 환경을 제공한다. 개발자는 애플리케이션의 개발, 테스트, 배포, 관리 및 업데이트를 간소화할 수 있는 다양한 도구와 서비스에 접근 가능하다.
3. SaaS (Software as a Service): 인터넷을 통해 애플리케이션을 제공하는 모델로, 사용자는 소프트웨어를 직접 구매하고 설치할 필요 없이 웹 브라우저를 통해 접근 가능하다.

BaaS는 특히 모바일 및 웹 애플리케이션 개발에 있어 개발 시간과 비용을 절감하며, 복잡한 백엔드 인프라의 구축과 유지 관리 부담을 줄여준다. 개발자가 사용자 경험(UX) 및 프런트엔드 개발에 더 많은 자원을 집중할 수 있게 해주는 주요 이점을 제공한다.

 

 

 

5. CI/CD

: 소프트웨어 개발 프로세스에서 중요한 개념으로, "지속적 통합(Continuous Integration, CI)"과 "지속적 배포(Continuous Delivery/Deployment, CD)"를 의미한다. 이 두 프로세스는 소프트웨어 개발 및 배포의 효율성과 신뢰성을 높이는 데 중점을 둔다.

 

CI (지속적 통합)

- 목적: 개발자들이 작업한 코드를 주기적으로 공유 레포지토리에 병합(머지)하는 것을 지원하여 문제를 조기에 발견하고 해결한다.
- 프로세스: 개발자가 자신의 변경 사항을 주기적으로 레포지토리의 메인 브랜치에 병합한다. 이때, 자동화된 빌드와 테스트가 실행되어 변경사항이 기존 시스템과 잘 통합되는지 검증한다.

 

CD (지속적 배포 or 지속적 전달)

- 지속적 전달 (Continuous Delivery): 개발된 소프트웨어를 사용자가 사용할 수 있는 환경까지 자동으로 배포하는 과정을 의미한다. 일반적으로 수동으로 최종 배포 승인을 필요로 한다.
- 지속적 배포 (Continuous Deployment): 지속적 전달의 한 단계 더 진행된 개념으로, 자동화된 테스트를 통과한 코드 변경 사항을 자동으로 생산 환경에 배포하는 것이다. 이 과정에서 사람의 개입 없이도 코드 변경 사항이 실시간으로 사용자에게 서비스되는 것을 목표로 한다.

CI/CD 파이프라인은 이러한 프로세스를 자동화하여 코드의 품질을 유지하고, 개발 과정에서 발생할 수 있는 다양한 오류를 최소화하며, 더 빠른 배포 주기를 가능하게 한다. 소프트웨어 개발의 생산성을 크게 향상시키고, 고객에게 지속적으로 가치를 제공하는 데 중요한 역할을 한다.

 

 

 

6. MVP (Minimum Viable Product)

: 제품 개발과 출시 과정에서 매우 중요한 개념으로, 제품이 시장에 진입하기 위해 반드시 갖춰야 할 최소한의 기능을 갖춘 제품

 

MVP의 핵심은 대규모 투자와 시간을 들이기 전에, 제품의 핵심 가치를 시장에서 검증하는 것이다.

 

MVP의 주요 목적

1. 시장 검증: 제품의 기본 아이디어가 시장에서 성공할 수 있는지 빠르게 확인한다. 사용자의 피드백을 수집하여 제품의 방향성을 결정하는 데 도움을 준다.
2. 자원의 효율적 사용: 제한된 자원을 가지고 최대의 가치를 창출하기 위해, 필수적이지 않은 기능은 배제하고 핵심 기능에 집중한다.
3. 빠른 시장 진입: 개발 주기를 단축시켜 빠르게 시장에 진입할 수 있게 한다. 이를 통해 경쟁자보다 앞서 나가거나, 시장의 변화에 빠르게 대응할 수 있다.
4. 지속적인 개선: 초기 사용자의 피드백을 바탕으로 제품을 지속적으로 개선하고 발전시키며, 사용자의 요구에 더욱 잘 부응하는 제품으로 성장시킨다.

MVP는 스타트업이나 신제품을 개발하는 기업들에게 특히 중요한 전략으로, 리소스가 한정적인 상황에서 제품이 가진 핵심 가치와 시장의 수요를 검증할 수 있는 효과적인 방법이다. 이를 통해 시장의 요구를 더 잘 이해하고, 제품을 성공적으로 출시하고 성장시킬 수 있는 기반을 마련할 수 있다.

 

 

 

7. 금일 소감

휴... 진짜 이번 주까지 이런저런 일들이 너무 많아서 블로그 포스팅이 늦어졌다. 거의 일주일 가량을 작성하지 않은 것 같은데, 앞으로는 다시 매일 꾸준히 작성해야겠다.

 

심화 프로젝트는 프로젝트 발표 직전날 밤에 본인이 할 기능을 내던진 팀원 한 명이 있어서 그걸 발견한 심화 프로젝트 발표 당일 새벽에 나랑 안 자고 있던 다른 팀원 한 명이 부랴부랴 해당 팀원의 기능이 되게끔 코드를 전체적으로 수정 및 추가했다. 심지어 본인이 맡은 기능을 구현하지 않은 것 외에도, 다른 팀원의 코드까지 작동되지 않게 많이 건드려놔서 정말 수습하는 내내 다 관두고 싶을 정도의 심정이 해일처럼 밀려왔다.

 

본인이 맡은 기능을 던져버린 팀원의 코드 PR을 Merge 해서 Pull 해보니 아예 발표조차 못 하게끔 만들어두어서 그것을 수습하느라 밤새웠다. 코드를 어느 정도 일단 작동은 되게끔 만든 뒤, 나는 07시부터 발표 자료인 PPT를 급하게 만들었고, 한 1시간 정도만에 PPT를 완성했다. 다른 팀원 한 분은 코드를 이어서 수정하였다.

 

09시인 출석 시간부터는 내던진 팀원 외에 다른 팀원 모두가 모여서 코드를 수정하였고, 나랑 함께 밤새운 팀원을 제외한 다른 팀원 두 분이 시연 영상과 발표를 맡아주셨다. 그렇게 시간이 흘러 14시에 어찌저찌 발표를 하고 마무리되었다. 다면평가에 이 내용을 상세히 작성하였는데 내부적으로 전혀 전달이 안 된 듯하다. 휴.. 뭐 어쩔 수 없지

 

아무튼 정말 마지막 그 순간까지 최선을 다해 열심히 했고 다시 돌아가도 후회 없을 정도로 하였다.

 

최종 프로젝트는 이런저런 일들 + 팀원들과 내가 생각하는 방향이 달라, 나는 개인 프로젝트를 진행하기로 했다. 최종 프로젝트 팀원들과도 충분한 상의하였고, 팀원들도 다 동의하였다. 기획도 거의 다 해두고 나온 터라 아마 코드만 짜면 될 정도일 것이다.

 

그동안 1월부터 지금껏 꾸준히 매니저님과 튜터님께 힘들었던 점과 어려운 점을 말씀드렸는데 전혀 전달 및 반영이 안 되었다는 게 너무 아쉽다. 최종 프로젝트가 이렇게 된 건 내가 말씀드린 내용이 전달 및 반영이 안 되어 낳아진 결과라고 보여진다.

 

최종 프로젝트를 위해 지금껏 달려오고 힘들어도 견디고 묵묵히 해냈는데 결과가 이렇다는 게 정말 많이 아쉽고 힘들어서 엄청 울었다.

 

하지만 어쩌겠어요? 혼자서라도 해야지. 그동안 여러 팀 프로젝트를 하며 기획, 발표는 혼자서 다 해왔고 프로그래밍도 팀원이 잠수를 타거나 심화 프로젝트처럼 내던지면 내가 다 해왔으니 혼자서도 다 할 수 있다. 나는 다 할 수 있다!!! 파이팅!!!