World IT Show 2023

과학기술정보통신부에서 주최하는 World IT Show 2023에서 EDINT 소속으로 전시 및 관람한 후기입니다. 작년 10월 말에 입사 후, 3번 째 전시였고 몇가지 느낀 바가 있어서 기록 목적으로 글을 남기게 되었습니다.

• SSDC 2022 전시 후기
• 대한민국교육박람회 2023
• World IT Show 2023

전시 중에 Jeff가 두 시간 정도 둘러볼 수 있는 시간을 주셔서, 두 관점으로 작성하였습니다.

1. 전시 관점
2. 참관 관점

전시 관점

설명이 편해졌다.

수다쟁이 기질이 강해서 말을 꼬리 물기 하듯 하는 버릇이 있습니다. 그래서 공적인 자리에서는 스크립트를 작성하고 연습하는 과정을 반드시 포함합니다. 대한민국교육 박람회 이후로는 청자 별로 다른 부분을 강조해서 발화하는 습관을 만들었는데, 나쁘지 않았습니다.

이번 전시회 동안, 학생 / 업계 관계자 / 비관계자에 맞춰 약간씩 다른 설명을 할 수 있어서 뿌듯했습니다. 다음 전시호에서는 이를 조금 더 구체화, 세분화해야겠습니다.

영어 회화가 탁 막혔다.

대한민국교육박람회 2023에서는 영어로 서비스 설명을 했었습니다. 아마도 영어 소리내 읽기나 영어 회화 수업을 하고 있었기 떄문입니다.

하지만, 이번에는 영어가 입 밖으로 나오지 않아서 너무 당황했습니다. 바쁘다는 이유로 2개월 넘게 영어를 입밖으로 내지 않아서 그랬던 것 같습니다.

참관 관점

세상에 AI 가 결합된 서비스가 엄청나게 않다는 것을 느꼈습니다. 개인적으로 이미지, 영상, 음성을 다루는 쪽에 흥미가 있어서 아래 내용들을 위주로 들었습니다.

• EDINT와 관련된 시각 처리 AI
• 기타 음성 처리 AI

서비스 부스에서 AI가 실행되는 위치나 인프라 구성에 대한 간단한 질의를 통해서 다른 회사들이 어떻게 AI를 사용하고 있는지도 볼 수 있어 좋았습니다. 매력적으로 보였던,,, 이런 아이디어들도 신기했습니다.

• SAMSUNG에서 만든 내 손글씨로 폰드 만들기
• 이미지 N 장으로 쇼핌올 마케팅 페이지 만들기
• URL으로 마케팅 페이지 만들기
• 소설처럼 쓴 줄글로 동영산 만들기
• 웹사이트에서 클릭으로 웹툰 만들기
• ETRI 연관 기업 - 적은 성능의 GPU 여러 대를 이용해서 머신 러닝 시간을 단축시키는 서비스
• ETRI 연구소 - 영상에서 Meta 데이터를 추출하는 AI

결론

• 방문자 구분 별로 다른 설명을 하는 스크립트를 구체화, 세분화하자
• 공통 영어 스크립트를 준비해서 가자
• 영어 회화는 아직 시기상조, 영어 발화 습관부터 길들이자
• 경쟁력을 기르기 위해서 시각 처리 및 음성 처리를 조금 더 배워야 겠다

Intro

3월 15일, AWS 담당 매니저님이 보낸 안내 메일로 AWS Startup Week 2023을 알게 되었습니다.

재직 중인 에딘트에서 근무 시간에 방문을 허락해주셨습니다. 😊 3월 30일, CTO Jeff님과 서버 개발자 Lay님과 함께 AWS Startup Week 2023에 방문해서 유익한 시간을 보냈습니다.

컨퍼런스 동안 Lay가 정리해주신 내용을 공유해주셔서 회고 내용을 훨씬 깔끔하게 정리할 수 있었습니다.

• AWS Startup Week 2023 공식 소개문

Track 3 우리 서비스에 효율화 더하기 + 고객사례를 들었습니다.

1. 개발도 빠르게 운영도 간단히! 서버리스 잘 한번 써볼까

발표자 : 최철우, 솔루션스 아키텍트, AWS

서버리스 환경에서 FE 및 BE가 서비스를 런칭할 수 있는 서비스를 소개해주셨습니다.

• AWS Amplify를 사용해서 서버리스 환경에서 React 개발 및 배포하기
• AWS SAM을 이용해서 서버리스 환경에서 Lambda 개발 및 배포하기

1.1. AWS Amplify

AWS Amplify는 웹 및 모바일 어플리케이션 개발을 위한 프레임워크입니다. React, React Native, Angular, Vue와 같은 웹 및 모바일 프레인쿼으와 통합이 가능합니다.

몇년 전부터 AWS에서는 다양한 스타일의 완전관리형 서비스를 내고 있습니다. 그래서 Amplify의 존재를 처음 알았을 때도 "아 그냥 완전관리형 서비스 중 하나"라고 느꼈습니다. 실제로 Amplify를 사용한 매력적인 이점이나 프렉티스를 보지 못한 것도 큰 이유였습니다.

이번 컨퍼런스에서 그 사례를 볼 수 있었습니다.

• Amplify를 통해 Figma 컴포넌트를 그대로 React 컴포넌트로 생성
• Amplify에서 Mock Data를 넣고 React 컴포넌트에 데이터 바인딩
• Amplify를 통해서 사이트 배포

기본적으로 AWS Amplify에 종속되는 구조기 때문에 범용적으로 쓰기는 어려울 것 같았습니다. 그럼에도 "회사 공식 사이트 등과 같이 지속적으로 고쳐야 하지만 리소스 투자가 애매한 부분에서는 유용하게 쓸 수 있지 않을까?"라는 느낌이 들었습니다.

제대로 된 A to Z 튜토리얼이 시중에 공개된 것이 없어서 약간 아쉬운 느낌이었습니다.

1.2. AWS SAM

AWS AMM은 서버리스 어플리케이션을 개발, 테스트, 배포하기 위한 프레임워크입니다. 내부적으로 AWS CloudFormation을 사용하며 API Gateway, Lambda, DynamoDB, S3 등과 연동하여 사용하곤 합니다. AWS CloudFormation은 JSON 혹은 YAML 파일을 통해서 AWS Infrastructure를 프로비저닝할 수 있는 툴입니다.

이제는 실버 불릿인지 재앙인지 많은 토픽이 나오고 있는 서버리스 REST API에 대한 예제였습니다.

서버리스 환경은 서버의 최소 유지비 측면에서 매우 유리하고 CI/CD와 같은 관리 포인트가 줄어드는 장점이 있습니다. 하지만 난해한 로컬 테스트와 난해한 디버깅, 콜드 스타트 등의 여러 불편한 점도 있습니다.

개인적으로는 이벤트 타입을 모킹해서 로컬에서 jest를 이용해서 테스트하는 것이 가장 아름다운 구조가 아닌가 생각합니다.

결국은 서버리스 REST API를 작업하기 위한 탬플릿을 만들어야 합니다.

대표적인 방법은 3가지가 존재하고 저는 SAM보다는 CDK가 좋은 것 같습니다.

개인적으로 굳이 코드형 인프라를 쓴다면 테라폼(Terraform)을 쓰는 것이 가장 매력적이라고 생각합니다. 하지만 AWS 리소스만 쓰고 있다면 AWS CDK도 나쁘지 않은 경험을 제공해줬습니다.

npm install -g aws-cdk
cdk init app --language typescript

import * as cdk from 'aws-cdk-lib';
import { App, Stack, StackProps } from 'aws-cdk-lib';

import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';

class MyStack extends Stack {
  constructor(scope: App, id: string, props?: StackProps) {
    super(scope, id, props);

    // Lambda 함수 생성
    const myLambda = new lambda.Function(this, 'MyLambda', {
      runtime: lambda.Runtime.NODEJS_14_X,
      handler: 'index.handler',
      code: lambda.Code.fromInline(`
        exports.handler = async (event) => {
          return {
            statusCode: 200,
            body: 'Hello from Lambda!'
          };
        };
      `),
    });

    // API Gateway 생성
    const api = new apigateway.RestApi(this, 'MyApi');
    const helloResource = api.root.addResource('hello');
    helloResource.addMethod('GET', new apigateway.LambdaIntegration(myLambda));
  }
}

// CDK 애플리케이션 생성
const app = new App();
new MyStack(app, 'MyStack');

2. AWS에서 Docker Container 사용하기

발표자 : 신정섭, 솔루션스 아키텍트, AWS 발표자 : 안성진, 솔루션스 아키텍트, AWS 발표자 : 정주홍, Head of Backend Engineering, AB180

시간이 지날수록 Docker 컨테이너와 관련된 내용들이 많이 보인 것 같습니다. AWS 측에서 한 번, AB180 측에서 한 번 발표해주셨습니다.

하지만 Docker를 적극적으로 사용하고 있지 않아서, 이해할 수 있었던 부분만 적고자 했습니다.

2.1. EC2 vs ECS Fargate

EC2와 ECS Fargate를 비교한 내용이 있었습니다. 내용은 아래와 같고 핵심은 실제로 벤치마킹해볼 것입니다.

• 대체로 Fargate가 낫다.
  • 워크로드가 예상 불가능한 경우
  • 비용 최적화가 어려운 경우
  • 스케일아웃이 많이 발생하는 경우
• 아래의 경우 EC2가 나쁘지 않다.
  • 일정한 수의 서버가 실행되어야 하는 경우
  • 비용 최적화할 자신이 있는 경우

2.2. Docker Image 최적화

Docker Image에서 레이어가 먹는 용량이 꽤 큽니다. 따라서 apt install과 같은 구문들은 최대한 하나의 레이어에 쓰도록 합시다.

이를 통해서 이미지 전체 용량을 효율화 할 수 있습니다.

• 나쁜 사례

RUN apt install a
RUN apt install b
RUN apt install c
RUN apt install d

• 좋은 사례

RUN apt install a \
    apt install b \
    apt install c \
    apt install d

3. AWS에서 효율적으로 글로벌 인프라 사용하기

발표자 : 김창순, DevOps 팀 리더, Channel Corp

서버와 요청자의 거리가 멀면 멀수록 사용자 경험이 나빠지는 것은 잘 알려진 사실입니다. 이 경우 다음과 같은 선택지들이 존재합니다.

1. AWS CloudFront를 통해서 캐싱
2. AWS Global Accelertor를 통해서 요청 속도 증가
3. Option 메서드 캐싱

Channel Corp에서는 AWS GA와 Option 메서드 캐싱을 통해서 성능을 끌어올렸습니다.

1. AWS CloudFront를 통해서 캐싱

가장 흔한 사례는 CDN 서비스를 이용하는 것입니다. 하지만 대부분의 서버 요청은 모두 다른 정보를 반환합니다. 따라서 캐싱 적중률이 높기 힘들어 비용 및 성능 효율적이지 않습니다.

또한 CDN 비용과 서버 데이터 비용이 이중으로 지출되는 문제가 있습니다.

2. AWS Global Accelerator를 통한 요청 속도 증가

AWS Global Accelerator를 사용하면 최대 네트워크 속도를 60% 가까이 올릴 수 있습니다.

3. Option 메서드 캐싱

브라우저에서는 Option 메서드 요청, 본 요청이 2개가 갑니다. 즉, Option 메서드만 캐싱해도 네트워크 성능이 2배가 됩니다.

4. 결론

다양한 사례 중, 제 상황에서 경험했거나 경험하고 싶은 사례만을 정리해보았습니다.

다른 회사에서 재직하고 계시는 리드, 시니어급 DevOps의 생각을 엿볼 수 있어서 매우 좋았습니다. 린(Lean)하게 접근하고 실제 측정한 데이터를 사용한다는 부분은 현업에서 적용해서 사용해서 유의미한 성능 및 비용 절감을 누린 것 같습니다.

전체적으로 유익한 시간이었습니다.

Intro

작년 11월 회사에서 서버리스 환경을 시도했으나, 여러 이유로 철회하였습니다.

이 시기에 개인적으로 코드형 인프라(IaC)인 AWS CDK를 배우게 되었습니다. AWS CDK를 사용해서 Microservices Serverless 서버를 띄우는 경험은 색다르고 재밌었습니다.

추가적으로 Terraform이라는 도구도 경험하게 되면서 선언형 문법을 포함해 많은 부분에서 충격을 받았습니다. 전체적으로 Terraform이 추구하는 길이 재밌게 읽었던 제로 트러스트 보안과 같은 것 같아서 더 흥미로운 것 같습니다.

본 후기는 클라우드를 공부하고 있는 신입 개발자의 시선으로 작성되었습니다. 최대한 내용을 검증하고 작성하였으나, 사실과 다른 내용이 존재할 수 있습니다.

HashiCorp

HashiCorp는 인프라 자동화, 보안, 유틸리티 솔루션을 제공해주는 기업입니다.

이번 컨퍼런스에서는 다음과 같은 내용이 중점적으로 다뤄진 것 같습니다.

1, HashiCorp 서비스에 대한 전반적인 개요 2. 신뢰 모델과 제로 트러스트 모델 3. 멀티/하이브리드 클라우드 운영 4. 국내 고객 사례

이 중에서 가장 재밌게 들었던 신뢰 모델과 트러스트 모델을 중심으로 후기를 작성하였습니다. Armon Dadgar님의 개요를 따르되, 보충할 내용은 도서 "제로 트러스트 보안"에서 참조하였습니다.

멀티/하이브리드 클라우드 운영과 제로 트러스트 보안 - Armon Dadgar

올해 키노트는 HashiCorp CTO인 Armon Dadgar님이 발표하셨습니다. 컨퍼런스에서 동시 통역으로 들었던 경험이 처음이라서 매우 신기했습니다.

1. 서비스를 만드는 과정
2. 신뢰 모델/경계 모델에 대하여
3. 신뢰 모델/경계 모델의 문제점 3.1. 신뢰 그 자체 3.2. 대규모 트래픽에 부적합한 구조

1. 서비스를 만드는 과정

Armon Dadgar는 서비스 개발 및 운영 과정을 3개의 단계로 구분하였습니다.

1. Pre Deploy
   • Version Control : GitHub과 같은 버전 관리 툴
   • Static Analysis : 코드 정적 분석 툴
2. Development & Deployment
   • 서비스를 개발하고 배포하는 과정
3. Observability
   • 서비스 모니터링을 통해서 제품을 안정적으로 운영

2. 신뢰 모델/경계 모델에 대하여

인터넷 사용자가 늘어나며 공용 IP수가 빠르게 줄었습니다. 이에 사설 네트워크 할당 RFC 1597을 통해서 사설 네트워크 개념이 생겼습니다.

기업들은 독립적인 주소 체계를 가진 네트워크를 가지게 되었습니다. 기업 간의 연결이 필요한 경우에는 네트워크 인터페이스를 이용합니다.

이때, 기업이 외부 인터넷을 이용해야 합니다. 하지만 공용 인터넷과 사설 인터넷의 주소 체계가 다른 문제가 있습니다.

이에 IP 네트워크 주소변경 RFC 1631를 통해서 NAT(Network Address Translation)이 등장했습니다.

NAT은 다음과 같은 특성을 가지고 있어서, 사실상 스테이트풀한 방화벽의 특성을 지니고 있습니다.

• NAT 내부에서 외부로 나갈 수 있다.
• NAT 외부에서 내부로 들어올 수 없다.

이러한 환경에서 신뢰 모델/경계 모델이 등장했습니다. 해당 모델은 다음과 같이 구분됩니다.

• 외부 인터넷
• 서버 (DMZ)
• 사설 네트워크

위를 신뢰 모델/경계 모델이라고 부르는 이유는 각 구성요소의 경계선만 주의하기 때문입니다.

즉, 경계선에만 WAF, VPN 등과 같은 보안 솔루션을 적용합니다. 일단 경계선을 넘어오면 안전한 사용자로 간주하고 신뢰합니다,

3. 신뢰 모델/경계 모델의 문제점

대표적인 문제점은 2가지가 있습니다.

1. 신뢰 그 자체
2. 대규모 트래픽에 부적합한 구조

3.1. 신뢰 그 자체

해당 모델에서는 신뢰가 바로 보안 취약점이 됩니다. 공격자가 경계선을 넘을 경우 신뢰받는 개발자와 동일한 행위가 가능해집니다.

3.2. 대규모 트래픽에 부적합한 구조

신뢰 모델에서는 기본값이 허용(Allow)입니다. 서비스가 엔터프라이즈급이 될수록 거부 대상 트래픽(Deny Traffic)이 늘어나기 떄문에, 이러한 구조는 비효율적입니다.

4. 제로 트러스트 모델

제로 트러스트 모델은 기본적으로 모든 요청을 믿지 않습니다. 요청자가 어떤 위치에 있는지와 무관하게 잠재적 공격자로 간주합니다.

따라서 제로 트러스트 모델은 신뢰 모델/경계 모델의 근본적인 단점을 극복할 수 있습니다.

  3.1. 신뢰 그 자체
  3.2. 대규모 트래픽에 부적합한 구조

Armon Dadgar는 이와 관련해 몇가지 키워드를 제시하였습니다.

• Explicit Auth : 명확하고 명정하게 인증하자
• Default Deny : 접근 권한이 없으면 기본적으로 거절하라
• Identification based Control : ID 기반 통제

5. 서비스 개발과 Identification

Armon Dadgar는 서비스 개발에서 일어나는 Identity 관계를 다음의 네 가지로 구분하였습니다. 각각의 Identity 별로 디테일한 설명, 주의사항 및 솔루션을 안내해주고 있습니다.

• Human Identity
• Machine Identity
• Machine to Machine Identity
• Machine to Human Identity

5.1. Human Identity

어떠한 요청자 A가 누구인지 어떻게 표현해야 할까요? Armon Dadgar는 SSO나 IDP를 활용할 것을 안내하였습니다.

• SSO(Same Sign On) : 통합 로그인
• IDP(Identity Provider) : 신원 공급자

여기서 IDP는 조금 생소한 개념일텐데, 어떠한 요청자 A에 대한 임시 신분증을 공급해주는 역할을 합니다.

5.2. Machine Identity

어떠한 어플리케이션 A가 누구인지 어떻게 표현해야 할까요? Armon Dadgar는 자사 서비스인 HashiCorp Vault를 소개하며, 다음과 같이 어플리케이션 A에 대한 신원 정보를 저장, 관리, 활용하는 방식을 안내합니다.

• Identity Declare : 어플리케이션 A가 누구인지 정의합니다.
• Secret Manager : Key Vaule 구조로 값을 저장하며, Value에는 정적인 값이 담깁니다.
• Dynamic Secret : Key Value 구조로 값을 저장하되, Value에는 동적인 역할이 담깁니다.

이 중에서도 Dynamic Secret을 사용하면 다음과 같은 것들을 손쉽게 구성할 수 있습니다.

1. N일 이하 자동 교체
2. 키에 대한 라이프 사이클 관리 필요 없음
3. 키의 삭제에 대한 추가 유지 보수 필요 없음

5.3. Machine to Machine Identity

어플리케이션 A가 어플리케이션 B에 접속하는 것을 어떻게 제어할까요? 만약 어플리케이션의 수가 수천개에 달한다면, 어떻게 안정적이고 효율적으로 운영할 수 있을까요?

Armon Dadgar는 HashiCorp Consul을 사용한 사례를 소개하였습니다.

• Discovery
• Server Mash
• Network Automation

예시를 통해서 구체적으로 살펴볼 수 있었습니다.

5.3.1. 수 천 개의 Spot에 LB 연결 시 성능 저하

일반적으로 서버들에 부하 분산을 하기 위해서 로드 밸런서(Load Balancer)를 사용합니다. 하지만 서버의 숫자가 수 천개가 늘어나면 결국 로드 밸런서에 부하가 걸리고 성능 저하가 발생합니다.

로드 밸런서는 결국 IP 기반 하드 코딩 것과 같기 때문입니다.

하지만 Consul을 사용하면 Namespace 기반 연결을 통해서 이 문제를 해결할 수 있습니다.

5.3.2. 수 천 개의 Spot의 연결 허용과 연결 거부

다음의 요구사항을 어떻게 달성할 수 있을까요?

• 어플리케이션 A에서는 어플리케이션 C에 접속이 가능하다.
• 어플리케이션 B에서는 어플리케이션 C에 접속이 불가능하다.

단순히 IAM 권한을 정의하거나 IP 기반 하드 코딩 방식이 맞을까요? 서버 및 컨테이너의 수가 수 천개가 넘어가면 어떻게 될까요?

여기서는 Consul을 사용해서 TLS Handshake하는 과정을 안내합니다. 이를 통해 모든 요청-응답은 제한된 사용자 만이 가능해집니다.

이 때, 모든 어플리케이션들(N개) 앞에는 TLS 핸드 쉐이크를 위한 프록시 서버를 배치합니다.

5.3.3. 방화벽이 있는 상태에서의 Consul

만약 다음의 요구사항을 달성해야 한다면 어떻게 할 수 있을까요?

• 애플리케이션 A에서는 DB A에 접속 가능
• 애플리케이션 B에서는 DB A에 접속 가능

Java, PHP 와 같은 전통적인 웹 서버의 경우 보안 정보와 함께 방화벽을 통과해야 합니다. 이 경우에도 Consul을 사용할 수 있다고 하였는데, 솔직히 이 부분은 이해가 되지 않았습니다.

추후에 동영상이 공개되면, 다시 확인해보면 좋을 것 같습니다.

5.4. Machine to Human Identity

어떠한 어플리케이션 A에 요청자 A가 접속하고 싶으면 어떻게 해야 할까요? 전통적인 어플리케이션에는 아마도 다음과 같은 구조를 따를 것입니다.

• 요청자 A -> VPN -> ? -> PAM -> 어플리케이션 A

이 경우, 요청자 A의 부주의를 포함한 다양한 보안 위협에 노출이 됩니다. 하지만 HashiCorp Boundary를 사용하면 Boundary를 통해서 어플리케이션 A로 접속하는 경로를 열게 됩니다.

• 요청자 A -> Boundary -> 어플리케이션 A

물론, 이 과정에서 요청자 A는 5.1.에서 언급한 SSO로 스스로를 인증해야 합니다.

6. 결론

클라우드 환경에서 서비스를 운영하고 있는 기업이라면 보안 정보 관리의 위험성에 노출되어 있습니다.

기존의 신뢰 모델/경계 모델은 다음과 같은 단점이 있습니다.

1. 보안 취약점에 노출된다.
2. 대규모 트래픽에 부적절하다.

하지만 제로 트러스트 모델은 위와 같은 단점을 해결합니다. 이를 위해서 HashiCorp에서는 Vault, Consul, Boundary 등의 제품을 제공합니다.

개인적인 영역에서, 코드 및 인프라 레벨의 개발에 깊이를 가지려고 하면 어김없이 이런 딱딱한 지식들이 쏟아졌습니다. 목표가 정해졌으니 이를 달성하기 위한 프로세스가 필요함을 인지하게 되었습니다.

신입 개발자로 입사가 확정되고 남은 3주, 부족한 컴퓨터 과학의 범위와 깊이를 높이고 지속 가능한 프로세스를 위해서 Monthly-CS를 계획하고 진행하였습니다.

공부, 자료 조사, 문서 작성 및 발표 준비에는 약 4~6 시간 높은 수준의 몰입을 진행하였습니다. 매주 토요일 오전 9시 30분에 발표시간을 가짐으로써 다음과 같은 가치에 공감할 수 있었습니다.

1. CS 지식은 새로운 기술 학습에 성장 속도를 배로 만들어준다.
2. 자료 조사와 스피치 활동을 통해서 스스로에게 양질의 자존감을 부여할 수 있었다.
3. 일, 공부, 스터디를 병행하면서 일정 관리의 중요성과 테크닉을 기를 수 있었다.
4. 하지만 복수의 이를 병행하면 개별적인 퀄리티는 내 능력의 최대치보다 낮게 나온다.

더 자세한 내용은 [## 기획] 과 [## 회고]를 참고해주세요.

기획

스터디 시작 전에 많은 분들과 스몰톡(커피챗)을 진행하였습니다. 이러한 시간을 통해서 각자가 원하는 스터디의 비전이 다름을 알게 되었습니다.

자기 계발서를 그리 좋아하지는 않지만, The One Thing에서 말하는 한 번에 하나씩 이라는 비전에 공감하고 있기 때문에 다음의 스탭을 밟아서 스터디를 구체화 했습니다.

1. 큰 목표 - 비전 : 스터디에서 가장 중요한 것
2. 작은 목표 - 스탭 : 스터디에서 단기적인 목표
3. 프로세스 - 수단 : 어떠한 방식으로 목표를 달성하는가

😎 큰 목표 - 비전 : 스터디에서 가장 중요한 것

단순히 면접 준비를 위해서 암기하는 것이 아니라, 컴퓨터 과학이라는 분야 중 담당한 부분만이라도 누군가에게 설명할 수 있을 정도로 능동적으로 공부해 보고자 했습니다.

비록 조금만 지나도 희믜한 지식이 될 수도 있겟지만, 이러한 시간을 통해서 다음의 가치를 얻을 수 있을 것이라고 믿고 있었습니다.

1. 자기주도적 학습
2. 자료조사 및 문서화 능력
3. 스피치 능력
4. 컴퓨터 과학 지식

😊 작은 목표 - 스탭 : 스터디에서 단기적인 목표

비전 달성을 위해서 컴퓨터 과학이라는 분야를 작은 단위고 나누고 그룹화 하는 과정이 필요했습니다. 스터디 주최자인 저와 @kwanyung님 모두 컴퓨터 과학에 대해 전공생 정도의 깊이 있는 지식을 알고 있지 않았기 때문에, 참고 자료가 필요했습니다.

결론적으로는, 작은 단위는 검색을 통해서 star가 많앗던 GitHub Repository 4개를 참고 하였습니다.

1. 14k — https://github.com/JaeYeopHan/Interview_Question_for_Beginner
2. 8.5k — https://github.com/gyoogle/tech-interview-for-developer
3. 3.2k — https://github.com/WeareSoft/tech-interview
4. 3.1k — https://github.com/WooVictory/Ready-For-Tech-Interview

그룹화는 인프런에서 무료로 제공해주고 있는 공룡책 강의의 커리큘럼을 기준으로 삼았습니다.

😊 프로세스 - 수단 : 어떠한 방식으로 목표를 달성하는가

비전, 스탭이 정해졌으니 프로세스를 구체화 하는 과정이 필요했습니다. 즉, 스터디 최초 기획자인 2인(@unchaptered, @kwanyung)과 부트캠프 동기 분들이 가지고 있는 리소스를 추정해보는 시간이 필요했습니다.

• 신입 개발자 혹은 취업 준비생

스터디 참여 대상이 가지고 있는 시기적인 특성을 고려했을 때, 퇴근 후 1 ~ 2일 이상의 시간은 무리가 가는 수치라고 느꼈습니다. 또 실제로는 3 시간 정도의 발표 시간이 추가로 소요될 것이 분명했습니다.

이러한 부분을 고려한 끝에 최소 강도로 삼을 지표를 정할 수 있었습니다.

1. 매달 마지막 주차 : 회고 및 다음달 주제 선정
2. 나머지 주차 : 주제 발표 준비 및 발표

😁 번외) 이익 극대화

이익 극대화라고 적어 두었지만, 더 정확히는 하나라도 남겨보자에 가까웠습니다. 마치 사내에서 모범 직원상을 받으면 기분이 좋듯, 부가가치에 가까운 에너지를 쌓아볼 수 있는 것을 고민해보았습니다.

1. 토요일 오전에 발표를 함으로써 일찍 일어날 수 있는 경험은 어떨까?
2. 매달 우수 발표자에 대한 선정을 하면 소확해이지 않을까?
3. 매달 마지막 주차에는 미니 퀴즈를 하면 어떨까?

이러한 통통 튀는 아이디어를 제공해주신 kwanyung님.... 멋져...

회고

앞서 결론을 몇번씩이나 말했듯, 다양한 방면에서 성장할 수 있는 기회가 되는 스터디였습니다.

이러한 스터디가 멈춰야 하는 시기가 되었기 때문에 멈추게 되었습니다. 복합적인 상황이 맞물려 서로가 바빠지거나 마찰음이 조금씩 나고 있었고 이러한 부분에서 단호하게 끝맺음을 낼 수 있는 순간이 되었음을 체감하게 되었습니다.

일주일에 작은 일정들이 매우 많았기 때문에, 기존의 Due Date 기반의 To Do List로는 한계가 있었습니다. 따라서, 우선순위에 기반하여 Must do List방식으로 전환하였고 실제로 일정을 유기적으로 조절하고 집중이 잘되는 시간과 그렇지 않은 시간을 구분하여 이러한 부분을 해결했습니다.

수면을 줄이는 방식으로는 업무에 지장이 올것이라고 판단했기 때문에, 주말 오전 등을 최대한 활용하게 되었습니다.

CS 스터디인데도, 일정 관리 등의 부분에서 큰 도움이 된 것은 꽤나 신기한 일이었습니다.

팀 단위에서 칸반 보드를 도입해본 경험이 없어서, 이번 스터디를 기회로 도입을 해보았던 점도 고무적이었습니다. 아무래도 짧은 시간만 교류하는 특징 탓에, 동료가 하고 있나? 라는 생각이 들어서 괜찮았던 것 같습니다.

툴은 추천 받은 NHN dooray를 사용했었는데, 녹화가 지원되는 화상 회의, 메신저, Git과 연동되는 Web Hooks, 프로젝트, 칸반 보드 등이 매우 매력적이었습니다.

다만, Windows PC GUI가 약간 불편했고 시야에 들어오는 컴포넌트 중에 안쓰는 것을 안보이게 할 수 없는 점이 약간 아쉬웠습니다. 아니면, 제가 못찾았을 수도 있습니다.

매달 마지막 주차에는 투표를 통해서 대표 게시글을 선정하기도 했습니다. 첫 달에는 유야무야 되었지만, 쪽지 시험도 한 번 진행했던 것이 생소한 경험이었습니다.

온라인 게임에서 뱃지를 받는 기분이라 생소하고 좋은 기억이었습니다.

조금 더 좁은 범위의 스터디

아무래도 Network 파트를 진행하지 못했던 만큼, 뭔가 중간에 끊겼다는 느낌이 강했습니다.

단절에 대한 경험보다는 완결에 대한 경험이 압도적으로 이롭다라고 생각하기에, 다음 번에는 조금 더 짧은 일정으로 구처적인 목표를 잡아보는 것은 어떨까 생각해봤습니다.

일정에 의미가 부여된 스터디

어떻게 보면 '모각코'에 가까운 스터디가 아닐까 싶은데, 주말 오전 기상에 목표를 두고 있는 모각코 스터디도 나쁘지 않을 것 같다고 생각 했습니다.

개인적인 생각

매번 새로운 사람과 새로운 활동을 하면서 느끼는 점은 하지말아야 할 말과 해야할 말의 구분이 매우 어렵다는 점이었습니다.

다만, 일종의 밈처럼 고민이 될때는 하지 말자라는 법칙이 모든 인간관계에서는 이어지는 것 같다라는 생각을 했습니다. 으악! 도 자고 일어나면 앗,, 내가 왜 그랬지 같은 게 아닐까요? 마치,,, 자니? 라는 카톡이 흑역사인 것처럼요...

그래서 어떠한 스터디, 프로젝트에서 리더를 맡게 되는 순간에는 일정을 이끄는 힘만큼, 하지 말아야할 말이 나올 것 같은 분위기를 풀어나가는 능력도 중요하다고 생각했습니다.

그래서 다음은?

다음은 알고 있는 내용을 강의하는 방식의 스터디를 이끌어 보고 싶다고 생각했습니다. 일종의 강의형 스터디의 주제는 Youtube 같은 곳에서 나오는 Youtube 핸즈온보다는 조금 더 Node.JS 개발자로써 실용적으로 사용 가능한 다양한 솔루션 및 경험을 제공하고 싶다는 생각을 했습니다.

또한 단순히 To Do Level 이 아니라 프로덕션 레벨에서도 쓸 수 있을 법한 숙련도를 가지고 있는 클라우드 솔루션을 목표로 삼고 있습니다.

본 후기는 작성자가 소속된 회사와는 상관 없는 개인의 생각이에요.

첫 번째 컨퍼런스 방문

SSDC가 첫 전시였다면, 이번 Software 2022는 첫 전시 방문이었어요.

대부분의 전시는 휴가를 내지 않으면 가지 못한다는 점이 조금 아쉬웠어요. 그런데 이번 전시를 회사에서 다같기 갈 수 있어서 꽤 재밌는 시간이었네요!

부스 전체가 엄청 넓어서 편한 마음으로 관람하고... 명함을 넣고 경품 행사도 참석하고 꽤나 재밌는 시간이었어요.

메타버스 플랫폼 아즈메타

가장 재밌었던 부스는 한컴이었고 그 중에서도 아즈메타라는 메타버스 서비스였어요.

Software 2022에서 크고 화려하고 경품행사 등으로 시선을 잡아끈 부스들은 분명히 있었어요. 그럼에도, 방문자 관점에서 가장 많은 상호작용을 할 수 있었던 곳을 꼽으라면 한컴이었지 않나 싶네요.

사실상 게임에 가까운 비주얼을 가지고 있는 아즈메타는 사용자의 움직임에 따라서 상호작용 가능 오브젝트를 알려준다던가...

점프나 대쉬 등의 기존의 메타버스에서 경험하지 못했던 (적어도 저는) 기능들이 있어서 참신했습니다.

게임도 아닌데 점프 대쉬까지 지원이 되는 것은 대체 무엇..?

기업에서 운영하는 부스였던 만큼 출시 일정도 매우 궁금했고 전시를 하고 계시던 관계자분을 통해서 12월 중으로 베타 버전을 계획하고 있다는 소식을 들었습니다.

무료라면, 꼭 써보고 싶고 약간의 유료라도 감수해보고 싶은 귀여운 느낌이었어요!

협업툴 Dooray!

Jira, Trello, Confluence 등과 같이 칸반 보드 기반의 협업툴이나, Flow, Dooray와 같은 올인원 협업툴 등 중에서 사실상 유일하게 사용해본 서비스 였어요.

다양한 기능이 무료로 제공 된다는 점... 그 중에서도 1시간 한정의 화상회의와 내부 녹화 기능 등이 너무나 만족스러운 경험이었어요.

단점으로는 목적에 따라서 사용하지 않고자 하는 탭(결제, 메일) 등이 많을 수록, 불필요한 텍스트가 사용자에게 많이 노출되서 피로감이 심한 것 정도가 있을 것 같아요.

실제로 기업에서 사용한다면 좋지 않을까?라는 생각이 드는 한편, ... 특정 부서에 따라서 특정 탭만 사용할 경우에 동일한 피로감을 느낄 수 있지 않을까 싶네요.

그럼에도 화상회의, 녹화, 클라우드는 미쳤습니다...

해당 부스에서 룰렛을 돌리고 Special Gift에 당첨되었는데, 핫팩과 Energy 뭐라고 적혀있는 과자 봉투를 받았습니다!

경품 중에서 두레이 바지가 있었는데, 진짜 너무너무 비주얼이 궁금했는데 실물을 보지 못해서 너무 슬픕니다ㅠㅠ

협업툴 Flow

사실 Flow는 그 이름만 많이 들었고 실제로 사용해보지는 못한 서비스였어요.

그도 그럴게 사실상 필수의 영역처럼 쓰이고 있는 협업툴의 숫자가 너무 많아서 피로감이 심하기 때문인 것 같아요.

1. GitHub
2. 카톡 (사실상 급한 연락은 결국 카톡을 쓰는...)
3. Slack (푸쉬 알람, 아카이브 목적으로 쓰기 좋은...)
4. Notion (문서 기록 및 공유 목적으로 쓰기 좋은...)

이런 와중에 최근에 CS 스터디를 운영하면서 화상회의를 비롯한 다양한 부가 기능 때문에 Dooray를 사용하게 되었고 그 이후에 Flow를 알게 되었어요.

당연히, 다음 스터디 및 사이드 프로젝트 때 협업툴을 선택할 때 다시 한 번 사이트를 들어가볼 것 같아요.

물론, 사실상 개인사용자에 가까운 규모지만....

해당 부스에서 키오스크에서 버튼을 눌러서 S오일 기름 상품권 3 만원권을 받았어요!

선생님,,,, 저 뚜벅이에요 ㅠㅠ

그 와중에 Flow 사용자가 몇명인지 맞춰야 했었는데 뒤에서 자꾸 3000만이라고 속삭이는 사수인 Lay님의 속삭임을... 잊지 않겠습니다.

정답은 45만이었네요! 맞췄다!!

끔찍한 레이서 KEVIN...

그리고 부산, 대구, 대전 세 군데에서 온 마이스터고의 전시부스들도 전부 놀라운 경험이었어요.

웹 개발 그 중에서도 Node, HTTP 원툴에 가까운 저로써는 상호작용이 많이 일어나는 컨텐츠를 보면 오우.... 마이갓뜨..라는 느낌이 강하게 들더라고요.

그 중에서도 VR 기계를 쓰고 게임을 하는 부스가 있었는데, 조작감 을 포함한 많은 부분에서 매우 놀라웠습니다!

다만 운전에는 끔찍한 재능이 없어서 가드레일을 엄청나게 박았습니다...

그 후...

갑자기 미술관이요?

글의 맥락상,,, 소프트웨어 전시 보고 갑자기 미술관이 나오니까 조금 뜬금없이 느껴지기는 하는 것 같네요.

이라고는 하지만, 미술관 안에서 너무 재밌었습니다.... 초등학교 떄 이후로 붓으로 그림을 색칠해봤는데, 뭔가 추억이라는 생각에 진지하게 그리느라 2시간이 순식간에 지나가더라고요!

개인적으로 지친 주말에 스윽 와서 그림 그리고 가도 재밌을 것 같아요.

이자카야!

뜬금없는데 아마 유난히 잘 나온 사진들은,,, 주로 Paul, Jeff, Itzel 세 분의 손길을 타고 나온 산출물인 경우가 많더라고요...

삼성역에 있는 신월 이자카야에서 엄청 달콤한 술하고 여러 안주를 배터지게 먹었습니다!

끝!

뽕맛이 느껴지는 전시 경험

항해를 수료하고 EDINT에 입사한지 3주째가 되는 날이었네요. 생에 첫 컨퍼런스가 전시라는 포지션이었어서 그런가, 색다른 기분입니다.

개발 공부를 시작하고 취업까지 1년 6개월의 시간이 걸렸는데, 멋있는 개발자가 되고 싶다는 노력이 이렇게 보상 받은 것 같아서 짜릿했어요!

다음번에도 이 서비스가 전시 되었으면 하는 마음과 그 서비스에서는 제가 많은 것들을 기여할 수 있었으면 하는 마음이 들었습니다. 이 서비스 내가 만든거야! 라는... 말을 당당하게 말할 수 있게

TMI 멈춰! 오랜 시간 집에만 있어서 그랬을까요? 많은 분들과 대화한 경험이 너무 오랜만이여서, 신나는 마음에 와다다다- 설명을 쏟아낸 기분이에요. 😁

Proctormatic

신기한 건, AI 기반 학습용 교육 플랫폼, ... 이라는 디테일한 설명보다는

이 친구(AI)는 제가 쳐다보는 곳이 어디인지 알 수 있어요! 가 더 흥미도를 끌어올리는 것 같더라고요.

역시 기술 중심보다는 가치 중심의 설명이 직관적이고 매력적인 것인가? 하네요.

그 와중에 EDINT 동료들마다 다른 스타일로 전시 소개를 하는 것도 재밌는 포인트 😀

이 모니터 아래에서, 전시 관람해주신 모든 분들 감사해요!!

이거 ~~로 만든거 맞죠?

가끔씩 Tensorflow나 이를 포함하는 다양한 module들에 대한 질문을 해주셨던 선생님들이 나타나시면 정말로 무서웠어요!

전설의 포켓몬이 나타났다!

어디서부터 어디까지 설명을 드려도 가능한 지도 불명확했을 뿐더러, 직무 자체가 Node.js 백엔드 개발자였던 만큼 추상화된 정의만을 알고 있었던 것 같아요.

그래서, 제가 알고 있고 설명해도 되는 부분에서는 많은 부분 저희 서비스를 소개해드리고자 했어요.

혹시나 디테일한 설명을 듣지 못해서 아쉬움을 품었던 분들이 있다면, 언젠가 좋은 기회에 이야기 나눌 수 있으면 좋을 것 같아요.

하지만, 그런 선생님들이 있었기에 다음 전시 전까지는 더 성장해야 겠군! 이라는 강한 동기부여도 얻었어요.

와! 이거 신기한데요?

가족, 학생 그리고 관계자 분들까지 WA! 이거 정말 신기한데요!라고 반응해주시더라구요~~ 그런 귀여운 반응 보여주셨던 분들이 정말로 많아서, 무언가 뽕이 차오르는 기분이었어요 ㅋㅋㅋ

바빠도 Session은 듣게 해주셔서...

좋은 기업 문화를 만들기 위해서 노력해주셔서 전시라는 중요한 순간이여도 듣고 싶은 Session은 듣게 해주셔서 너무 감사했습니다.

확실히 현장에서 든는 순간의 몰입감은 많이 다르더라고요. 다만, 좋은 세션일수록 밀도가 높은 만큼 키보드 없이는 필기는 불가능하다라는 느낌을 받았어요.

Clean Architecture 기반의 Flutter 모바일 앱 개발 사례

큰 깨달음을 얻을 수는 없었지만, 개인적으로 Clean Architecture에 관심을 가지고 있었던 만큼 첫 Session은 흥미롭게 들었습니다. 사실상, 이를 이루기 위해서는 너무나 많은 양의 공부가 필요하긴 하지만 그렇기에 더 궁금한, 이 녀석

대외비인 것이라 어려운 일이겠지만 매우 간단한 상황에 맞는 코드도 있으면 더 재밌을 것 같다는 생각이 들었습니다. 물론, 전 Dart에 문외한이라서, 매우매우 간단한 코드만이 이해할 수 있었을 거지만 말이죠

(전)개발자의 취미생활 위한 사이드 프로젝트 시작하는 법

두번째 Session은, 코딩을 하는 것만이 사이드 프로젝트가 아니라, 개발자로서의 역량을 높일 수 있는 것이 사이드 프로젝트다 라는 말씀이 너무 강렬하게 마음에 와닿았습니다.

개인의 노력과 시간은 전략적으로 투입되는 것이 좋을 수는 있다라는 생각에 공감하지만, 그럼에도 떄로는 다른 시야, 다른 방식에서 오는 깨달음의 가치도 강하다고 생각을 합니다.

그러한 부분에서, 얼마 남지 않은 연말, 그리고 내년의 계획에 대해서 조금 더 생각해보는 시간이 되었습니다.

사담

사실, 우당탕탕 토크 타임만 하고 왔는데 맛있는 음식 먹으면서 여러 이야기 할 수 있는 시간도 주셔서 너무 좋았어요.

사람에 따라서 조금 민감하게 느낄 수 있겠지만 저는 상대방이 살아온 시간을 느꼈을 때, 그 사람과 조금 더 가까워지는 것 같다는 생각을 합니다.

결코 음식이 맛있어서가 아니라 같이 있을때, 개발 외에 취미, 애니/만화, 차, 음식 다양한 이야기를 할 수 있어서 재밌습니다.

Dave님이 인터뷰 중에 출근하고 싶은 회사를 만들고 싶다는 말씀을 하신 걸 들었는데, 극한 집돌이인 저도 왕복 2시간 거리에도 만족하면서 출근을 하고 있는 만큼 재밌고 좋은 팀이라고 생각해요.

그리고 서순이 진짜 엉망인데, 삼성전자 서초사옥 구내식당 밥이 엄청 맛있었어서 신기했습니다.

그런데, 김치 맛있는데 너무 적어서 슬펐어요. 김치 더 달라고 하면 더 주시나요?

끝-

22.07.11~22.10.14

개인적으로 WIL 이나 TIL 을 작성하지 않았기에, 추억과 기억을 남기고자 회고를 작성하게 되었습니다.

History

• 22.07.21 / 항해톡, 객체 리터럴 구조분해할당
• 22.08.02 / 항해톡, SQL vs NoSQL
• 22.07.15 ~ 22.08.22 / 알고리즘 스터디 unchaptered/hanghae-algorithm-study
• 22.07.19 ~ 22.08.23 / 컴퓨터 과학 스터디 unchaptered/hanghae-cs-study
• 22.07.11 ~ 22.07.14 / 미니 프로젝트, unchaptered/coffee-selector
• 22.08.12 ~ 22.07.18 / 미니 프로젝트, motd/motd-backend
• 22.09.19 ~ 22.09.25 / 미니 프로젝트, CloneCoding-Pinterest/PinterestBe
• 22.08.26 ~ 22.10.07 / 실전 프로젝트 cupicks/cupicks-be

The End

99일 동안 진행된 항해가 종료되었습니다. 매주 최선을 다해서 맡은 역할을 다하자 라는 마음으로 임했고 후련하고 싱숭생숭한 기분입니다.

항해를 시작하기 전에, 먼저 공부를 하고 왔었던 만큼 많은 분들께서 여러 가지를 물어보셨습니다. 그런 순간들마다, 잘못된 내용을 말씀 드려서 그 분들께 피해를 끼칠까봐 걱정이 되었습니다.

그러한 긴장감이 스스로가 이론적인 부분에 깊이 를 파고들어 갈 수 있는 원동력이 되었습니다. 분명히 기술적인 부분에서 크게 성장했다고는 볼 수 없지만, 어떻게 협업 해야 하는 지 알게 되었습니다.

단 하루도 쉬지 않았다!

말 그대로, 단 하루도 쉬지않고 공부를 한 저 자신이 자랑스럽습니다. 주에 130 시간 을 공부 및 코딩에 할애하기도 하고, 팀 프로젝트에서도 최대한 기여하고자 했습니다. 그 시간 만큼 순식간에 99일 이 지나갔던 것 같습니다.

나는 어떤 개발자가 되어야 할까?

항해에서 많은 분들에게 질문을 받고 그것에 답하는 시간을 가졌습니다. 그리고 다양한 분들에게 신뢰를 받는다 라는 느낌을 받았습니다.

사실, 이렇게 번듯하게 공부하고 열정적으로 사는 것이 낯설어서 생소한 기분 이었습니다.

그리고 어떤 개발자가 되고싶은가? 에 대한 결론을 내렸습니다.

• 개발자 동료들에게 신뢰 받는 한 명의 전문가 가 되고싶다.

어떻게 노력헀을까?

일일히 열거하기 힘들만큼, 수많은 솔루션과 공식문서를 열어봤던 것 같습니다.

• 누군가의 질문에 더 정확하게 대답하기 위해서
• 동료보다 더 공부를 오래헀던 시간이 헛되지 않았음을 보여주기 위해서
• 그리고 더 성장하기 위해서

긍정적인 경쟁심을 가지고 시간을 보넀고 뜻밖에도 질적인 성장 을 많이 이뤄냈습니다.

인테리어 탁상 빨리 받고 싶어요...

수료식의 마지막에 귀여운 밥상과 탁상용 선풍기를 받았습니다. ㅋㅋㅋㅋㅋ 항해 동안, 아이스 브레이킹이라는 명목하에 테트리스 와 TMT 였었던 것 같은데, ... 많은 분들이 감사함을 표현해주셔서, 오히려 제가 더 감사했습니다.

같은 팀에서 활동했던 FE, BE 분들, 그 중에서도 같은 포지션이여서 많은 부분을 알려드렸던 분들, 어느 순간부터인가, 각자가 스스로 알아낸 것들을 공유해주셨던 분들,

항해 안에서 만났던 모든 동료에게 크고 작은 도움을 받았고 교훈을 얻을 수 있었습니다.

스트레스 받지 않았다면 거짓말이고 화낸 적이 없다고 하면 거짓말일 것 같습니다.

그럼에도, 항해에서 배운 가치는 *"협력" 이 가지는 힘은 생각보다 크다* 라는 것이었습니다.

누군가 고민하고 있는 사람이 있다면.

솔직히, 누구에게나 최고의 선택 일거라는 말은 하지 못하겠습니다. 각자가 항해에서 얻어가는 가치는 다르고 후회 하고 분노 할 수도 있을 것 같습니다.

그럼에도, 개발을, 어떻게 공부해야할지 모르겠다면 항해는 나쁘지 않은 선택일 것 같습니다. 다만, 이 곳에서 얻을 수 있는 가치는 마치 패키지 여행 처럼 포장되어 있는 것처럼 느껴지며, 그러한 패지키 여행은 개인마다 다르게 느낄 것이라고 생각합니다.

다만, 이곳에서는 뜻밖에도 좋은 사람, 좋은 동료, 좋은 멘토 님들을 만날 수 있을 지도 모르겠습니다. 집안에서 혼자 코딩을 하던 제가 이곳에서 다양한 사람을 만나고 다양한 경험을 했던 것처럼, 누군가에게는 생각보다 가치가 있을 지도 모르겠습니다.

• 모든 선택은 개인의 선택이고 이미 선택했다면 그 곳에서 최선의 가치를 찾자.

짧게는 수 개월, 길게는 수 년이 지나고 나서 이 시점의 선택이 최선의 기억 이었기를 기해다면서, 이제는 취업 준비에 전념하게 될 것 같습니다 :)

본 게시글은 항해99 실전 프로젝트 Cupick 회고 내용 입니다.

인생에서 소중하고 감사한 인연이 되었던 5 명의 동료를 만나서 함꼐할 수 있어서 너무 영광이었고 즐거운 추억입니다.

열심히 달려준 팀원 분들께 너무 감사드리며, 현재 저희는 취업 준비와 Cupick 리뉴얼 작업 중입니다.

Ground Rule

vice leader meeting

실전 프로젝트 3일 전, 항해99 F반 안에서는 4개 팀 만 구성되었습니다. 이에, Broccoli-Velog 동안 이야기를 많이 나누었던 VL(부리더), dusunax 님과 함께 하게 되었습니다.

VL 님께는, 개인적으로 신중하고 성실한 부분에서 존경하는 분이었기 때문에, 큰 신뢰를 가지고 있었습니다.

이러한 부분을 가지고 짧은 시간 밀도있는 대화를 나누었습니다.

• 지양하는 것과 지향하는 것.
• 미니 프로젝트 와 클론 프로젝트에서 아쉬웠던 점
• 최종 프로젝트 에서 꼭 얻어가고 싶은 것들

"지난 2 주 동안근 기능 구현에 쫓겨서 서로의 코드를 볼 수 있었던 시간이 없었던 것이 아쉬웠던 것 같아요. 그래서 최종 프로젝트 에서는 서로의 코드도 보고 컨벤션도 맞춰 가면서 협업하고 싶어요"
"저도 그런 것은 너무 좋은 것 같습니다. 저도 테스트 코드도 써보고 기존에 해왔던 것들을 조금 더 튼튼하게 다져보는 시간을 가지면 좋을 것 같아요. 그리고 고도화도 꼭 해보고 싶습니다."

after start

실전 프로젝트 조 구성이 되고 첫 회의 시간이 되었습니다. 사실, L(리더)로써 강한 책임감을 가지고 팀을 이끌어야 한다라는 부담감이 있었습니다. 그저 남들보다 개발을 약간 오래 했을 뿐이었던 제게는 큰 부담이었습니다.

협업 기간이 짧고 개인 공부 시간이 긴 제가 남들에게 독이 될 수 있음을 경계했기 때문에, 다양한 벤치마킹 영상을 찾아 보았습니다.

그 중에서도, Youtube/EO Channel - Work on beach 에서

"저희 회사는 규칙보다는 원칙을 중시합니다,"

라는 말이 강렬하게 다가왔습니다. 좋은 문화가 좋은 개발자를 끌어들이는 것이 성장에 이유가 되는 것이라면, Team Cupick 또한 짧은 시간 좋은 문화를 만들 기 위해서 명확한 원칙이 필요하겠구나.

다만, 협업인 만큼 다음과 같이 최소한의 규칙도 적용되었습니다.

• Git Flow 전략
• Git, Code Naming Rule 준수
• Lint-staged, Prettier 를 통한 포멧팅
• GitHub Issue, PR Template 를 통한 Issue, PR 관리

Velog 의 lokijoji2 님의 블로그에서 배운 lint-staged 너무 최고!

Culture

그래서 최소한의 투자로 어떤 문화를 만들 수 있을지 고민했습니다. 사실, 42일 이라는 시간은 너무나 짧으니까요.

그래서, 생각한 것은 회의 내용에 대한 기록과 사진관 이었습니다.

모두가 모이는 순간을 사진으로 남기자

그리고 꺠알 같지만, 항해99 에서 마케팅 비용으로 주신 돈의 지출 내역도 투명하게 관리하였습니다.

Ideation to Specify

프로젝트는 다음의 2 단계로 진행하였습니다.

1. ideation
2. specify

ideation

Cupick 은 아이디어에 호불호나 평가를 매기지말자 라는 원칙으로 Ideation 을 진행했습니다.

그 중에서도 개인의 취미에 대한 Ice Breaking 시간이 프로젝트까지 연결이 되는데 주효했던 것 같습니다.

이러한 ideation 은 다음의 2 단계로 진행이 되었습니다.

1. project topic ideation
2. main function ideation

project topic ideation

앞서 진행하였던 취미에 대한 ice breaking 을 기반으로 topic을 쏟아내는 시간을 가졌습니다.

임시 topic 선정이 완료가 되면, main function ideation 을 진행하면서 현실적으로 진행 가능한 스코프 인지 판별했습니다.

main function ideation

이 과정은 어떤 기능들이 필요한지를 나열하는 과정 이었습니다. 예를 들어, 블로그를 만들어야 한다면 다음과 같이 작성이 되겠네요.

1. 유저 CRUD
2. 게시판 CRUD
3. 실시간 알림?

내용을 나열한 후, 다음의 부분을 고려했습니다.

1. 팀원 전체가 기여할 수 있는 스코프인가
2. 핵심 기능이 후순위 개발(사전에 필요한 데이터들이 많은 경우)이여서 프로젝트 마감을 지키지 못할 위험성이 높은가
3. 우리 모두가 하고싶은가

만약 13을 충족하지 못한다면 topic ideation 으로 되돌아갔습니다. ~저희는 총 2번의 ideation, specify 과정을 진행했습니다~~

specify

구체화 단계는 다음의 2 단계로 진행하였습니다.

1. API 리스트 작성
2. API 명세서 작성

API 리스트

API 리스트에서는 main function ideation 에서 뭉쳐져 있던 API 들을 리스트화 했습니다. 여러 개의 API 로 구성된 기능도 넣었습니다.

해당 리스트에는 다음과 같은 요소들이 들어갑니다.

1. 포함되는 페이지
2. API 주소
3. DE,FE,BE 담당자 및 완료 여부
4. 버그 발생 시의 이슈(추가적으로 kakao 로 공유)

API 명세서

API 명세서는 API 리스트를 기준으로 자세하게 작성되었습니다.

해당 명세서에는 다음과 같은 내용이 포함되었습니다.

1. descriptin : 기능설명
2. method
3. path
4. JWT required : AccessToken 의 필요 여부
5. Contenty Type
6. Request : BE 의 요청사항을 FE 가 반영
7. Response : FE 의 요청사항을 BE 가 반영
8. error code list : 별도의 문서에 모든 경우의 수가 나열, BE 에서 관리
9. 비고
10. 주석 (중요한 변경사항은 붉은 글자로 표기)

Additional Requirement

조율?

저희는 모두 열정적인 분들로 구성이 되었습니다. 여러 이슈가 있었지만 결과적으로 순항하고 있다는 느낌을 받았고 이러한 분위기가 선순환 구조로 작용하였던 것 같습니다.

그랬던 만큼 의견 조율의 과정이 매우 많이 일어났습니다.

• Designer, Frontend, Backend 의 포지션 별로
• 포지션 내부의 각 팀원끼리

자유롭게 의견 표현을 하되, 상대방의 포지션에 대한 존중을 하면서 진행하였습니다.

서로가 한발자국씩 물러나는 것 으로 보이는 것들이 실제로는 상대방에 대한 존중 이지 않을까.

SA Feedback

Team Noiton 에서 정리했던 내용들을 Starting Assignment 를 양식에 맞춰서 간략하게 요약하고 제출하였습니다. 해당 부분에서 긍정적인 피드백을 받았고 하룻 동안 높은 강도 로 진행했던 모든 과정이 보상받는 기분이었습니다.

Pre-tech Feedback

사실! 27일 이 1차 기술피드백 인 줄 알았습니다! 덕분에 많은 시간을 들여서 저희가 프로젝트 시작 단계에서 고민하고 있었던 내용들을 정리해 두었습니다.

모든 질문은 팀 내부적으로 협의 및 회의 시간 을 가진 이후에 작성되었습니다.

• 항해99 전 기수의 기술 스텍을 참고 한다던가 저희가 구현하려는 프로젝트에 필요한 Lib 등을 찾는다던가
• 다양한 경로를 통해 알게된 부분을 검색 후 정리 하고 의사결정 과정 을 정리하게 되었습니다. 이 부분은 프로젝트 시작 전에 꼭 멘토 님의 시선 으로 어떻게 보이는 지 궁금했습니다.

기술 Feedback

매주 토요일에는 시니어 개발자님의 기술 피드백이 있었습니다.

금전적으로 환산할 수 없는 소중한 기회라고 생각을 했고 간결한 질문을 통해서 최대한 많은 내용을 배우고 반영하자 라고 생각했습니다.

실제로 회사에서 일하는 마음으로 시니어 멘토님의 말을 이정표 삼아서 많은 참고자료를 조사하고 내부적인 검토 과정 을 거쳤습니다.

1. 우리에게 필수적인 변화인가
2. 이미 잘 작동하고 있다면 투자 대비 효율성이 어떠한가

거의 모든 부분은 반영하였지만, 이미 DtoFactory - Dto, JoiValidator 를 통해서 유지보수성이 확보되고 견고한 구조가 된 부분도 있었습니다.

이러한 경우 class-validator 를 도입하지 않고 기존에 사용하던 joi 를 유지하였습니다.

MVP Feedback

우당탕탕 MVP 발표 시간이 있었습니다. FE 에는 식별 되는 버그가 많았고 BE 는 기술적 의사결정 등이 명확하지 않았습니다.

두 분의 시니어 멘토님께서 와주셨습니다.

정합성이 떨어진다 라는 피드백을 받고 스스로의 타협에 대한 반성을 하게 되었습니다.

커뮤니케이션 비용이 많이 나오니, 이 부분으 타협을 하자. 우리는 이 정도 부분까지는 할 수 없어 와 같은 마음이 남아있었나 봅니다.

흔히들 말하는 신입이~ 로 시작되는 합리화였던 것이라고 생각합니다.

누군가의 이해는 너무나 고맙고 달콤하지만, 스스로가 하는 이해는 합리화라는 생각에 조금 더 텐션을 끌어올렸습니다.

더 자세하고 명확한 이유 를 찾고자했고 실패한 기술적 선택에 대해서는 인정하는 자세를 취했습니다.

예를 들어, 잘못된 Raw Query 선택 이 있었습니다.

끊이질 않는 API 수정

개인적으로 이 부분은 너무 짜릿했습니다. 혼자서 오래 하다보니 일종의 폭포수 모델 에 가깝게 작업을 하게 되었습니다. 하지만, 매주 다음과 같은 작업으로 진행하였습니다.

• 피듭개(요구사항) -> 회의 -> API 수정 -> 리팩터링

이러한 부분이 처음에는 과도한 피로감이기는 했습니다.

1. 말하기가 조심스러워요!
2. 혹시 그게 어떤 말씀일까요?
3. 음, ... 이 부분은 다음에 협의해볼까요?
4. 회의 시간이 너무 길어요 ㅠㅠ

깨알 같은 이슈들을 겪으면서, 때로는 치명적인 시간 낭비를 겪으면서 조금씩 성장하는 것을 느꼈습니다.

수 시간에 걸쳤던 초기 회의는 이십분 내외까지 줄어들었습니다. 역시 인간은 적응의 동물일까요?

Refactoring 합시다 여러분!

놀랍게도 Refactoring 이야 말로 가장 많이 말한 키워드 였습니다. 이러한 부분을 코드 리뷰의 형태로 해야 했었다는 것은 프로젝트가 끝나고 나서야 알았습니다. : )

1. 혹시 dto 이름이 왜 RecipeResponse 일까요?
2. Prefix 가이드를 따라주세요~
   1. Type 은 T**
   2. Enum 은 E**
   3. Interface 는 I**

any 제발...

TypeScript 를 선택하게 되면서 정말로 작지만 많은 부분의 문제가 있었습니다.

• Cannot access property of **

접근하고자 하는 친구의 타입이 불명확하기 때문에 발생하는 문제입니다.

이 에러의 가장 달콤한 솔루션은 any, JSON.stringify() 인데 진짜 any 와 JSON.stringify 로 도배되어 있는 코드는 기절초풍입니다.

부디, 신에게 10분의 시간을 내주셔서 열심히 정리한 Issue 를 읽어주소서...

Bug : PoolConnection.query 의 반환값을 사용이 불가능한 경우

이후 지속적으로 Refactoring 을 진행하면서 해당 코드들의 대다수를 지울 수 있었습니다.

END

그렇게 프로젝트가 끝이 났다고 합니다.

저는 다이소에서 일하지 않습니다!!!

다이소?

Youtube를 보다보면 다이소 추천템 Top 3와 같은 영상이 매우 많이 나와요. 다이소의 전략 자체가 싼 가격이기는 하지만, 그 만큼 가성비가 좋거나 생각보다 괜찮은 아이템이 있는 것도 사실이에요.

그렇다면 다이소 개발자인 저는 어떨까요?

가짜 다이소 개발자

21년 6월 개발 공부를 시작한 후, 정말 많은 친구들을 써봤습니다. 많은 선배 개발자분들이 싫어하시는 어 저 그거 해봤습니다 :)의 케이스가 아닐까 싶어요.

1. Express
2. React
3. JSP
4. Nest
5. Sveltekit
6. GraphQL(Yoga, Apollo)

이 다섯개를 경험하는데 채 8개월이 걸리지 않았으니 수집가에 가까운 무언가가 아니었나 싶어요.

물론, 이 대부분이 뚜렷한 성과도 숙련도도 없다는 점이 진짜 다이소와 다른 점이었다는 것이에요.

지금은 Express 개발자에요!라고 말합니다.. 물론, 이거 써보셨나요? 라고 물어보면 써봤는데 잘 몰라요!라고 하거나 써본 범위 내에서만 대답하는 편입니다.

아마도 많은 분들이 지원헀을 인프런도...

아마도 많은 백엔드 개발자분들이 개발바닥을 보실 것이라고 생각해요.

저도 그 수많은 시청자 중 한명이었고 아마 작년 늦가을 무렵이었을 거에요. 그때, 서버 개발과 테스트 코드에 대한 말을 처음 들었어요.

다분한 광기로 다양한 프레임워크 같은 것을 수집만 하면서 시간을 보내다가, 처음으로 그 뒤에 있는 한 걸음을 본 기분이었습니다.

지금은 아니지만, 그 당시에는 테스트 코드라고 불리는 오아시스를 발견한 기분이었어요.

오우 쉣! npm run test을 입력하면 따다라라락- 한 다음에 테스트가 완성되는 그 아름다움이란...

당시에 제가 테스트 코드에 대해서 생각하던 것이었습니다. 그렇게 한 6개월 정도, Mocking으로 가득찬 테스트 코드만을 쓰면서 (가짜) TDD를 경험하면서 어쩌면 나 천재일지도? 라는 생각도 했던 것 같아요.

인프런 에서 지원하고 나서 ...

모든 회사에서 떨어졌고 마지막에 인프런에 지원해서 기술 과제를 진행하게 되었스니다. 과제 페이지를 열자마자 느낀 것은 스스로에 대한 절망 에 가까웠습니다.

• 비전공자 치고 나름 오랜 시간 공부를 했지 않나?
• 나 실력도 있고 아는 것도 많은 것 같은데 왜 떨어지지?

이런 생각을 했던 지난 날이 너무 부끄러웠습니다. 비록 국내에서 생소한 라이브러리도 있었지만, 대다수는 몇 번의 한글 검색으로도 나오는 것들이었습니다. 아, 나는 누군가가 떠먹여주는 것을 먹는 것만 해왔구나 라는 생각을 했습니다.

해당 과제를 받고 처음으로 공식 문서 를 열어보기 시작했습니다. 회사에 붙기 위해서가 아니라 스스로에 대한 증명에 가까웠던 것 같습니다. 중간에는 국내에서 내가 원하는 정보를 찾을 수 없어서 처음으로 영문 검색 을 시작하게 된 계기이기도 했습니다.

과제 기간을 꽉 채워서 마지막 날에 제출을 하게 되었습니다. 그리고 제가 고민한 것들을 하나도 빠짐없이 **.md 파일 안에 정리해서 제출하게 되었습니다.

인프런에서 떨어지고 나서...

제출을 하고 회신을 받을 때까지 어느 정도 시간이 있었기 때문에, 많이 좌절하고 방황했던 것 같습니다. 그리고 그 끝에 인프런에서 장문의 피드백 을 보내주셨습니다.

정신이 확 깨는 기분이었습니다. 내가 얼마나 모자란 개발자였는가, 아 이래서 내가 떨어진 것이구나.

클론 코딩이나 양산 하듯이 배워서 적어넘긴 기술 스텍 들이 얼마나 무의미 했는지 신랄하게 알게 되었습니다.

• 테스트 코드가 무엇인지
• 리펙터링이란 무엇인지
• OOP 란 무엇인지

개발 공부를 시작하고 4 개월 차에 샀던 엘라스틱 서치 실무 기술??? 이라는 책이 눈에 들어오는데, 많이 부끄러웠습니다.

그리고 동시에 희열도 느꼈던 것 같습니다. 제가 모르는 이야기의 양이나 깊이만큼, 제가 떨어진 이유를 알 수 있었습니다. 화려함이 아니라 어떻게 해야 [ ] 한 서버 를 만들 수 있는가 에 대한 화두를 던져주는 것 같았습니다.

내가 모르는 것이 나왔기 때문에 내가 더 성장할 수 있다 라는 생각을 처음했습니다.

그리고 회신이 오지 않는 동안, 내심 인프런을 탓했던 자신이 부끄러워서 회신을 보내지는 못했습니다. 하지만, 해당 피드백을 받고 많으 부분을 바꿀 수 있었다고 감사의 말씀을 드리고 싶습니다.

그야 말로, 1년의 방황 끝에 찾은 터닝 포인트 였으며, 제가 더 개발을 사랑할 수 있게 만들어 주었습니다.

혹여나, 이 글을 보게 되신다면 정말로 감사하다는 인사를 드리고 싶습니다.

지금은...

지금은 항해99 8기 F반 를 하고 있습니다.

매주 최선을 다한다고 했지만, 아쉬운 부분이 많았습니다. 많은 분들과 소통하고 공부하고 협업을 진행하면서 정말로 놀랐습니다.

처음에는 단방향에 가까웠던 지식 공유가 지치기도 했습니다. 하지만, 같은 조에서 열정적인 분들의 성장속도를 보면서 저도 자극을 많이 받았습니다.

항해99 중에 로 종종 들었던 질문은 목 아프지 않으세요? 라는 말이었습니다. 모든 분들의 질문에 답하지는 못했지만, 제가 가용한 시간 과 알고 있는 내용 은 모두 답하려고 노력했습니다.

일주일에 130 시간을 앉아 있었어도 실제로 제 공부는 10 시간도 못한 주도 있었습니다. 솔직히 지친 적이 없었다면 거짓말이고 화난 적이 없었다면 역시나 거짓말일 것 같습니다.

그럼에도, 누가 읽어 줄 지도 모르는 그런 수많은 README.md 나 에러를 해결했던 Issue 를 작성했던 것은, 저한테 긍정적인 에너지나 자극을 주셨던 분에게 보답하기 위해서 였던 것 같습니다.

• 취업에 실패해서 바닥까지 갔던 자신감도 많이 올라왔고
• 오랜 기간 공부를 하면서 루즈해진 일상에도 열정이 생겼습니다.

부디, 이 항해의 마지막 이벤트인 실전 프로젝트가 웃음으로 끝날 수 있기를 기도하면서. 다이소 개발자 인 회고를 마무리 하고자 합니다.

하지만, 막상 협업 단계에서 에러가 발생하자 시간이 촉백해져서 이를 해결하기가 너무 벅찼습니다.

프로젝트는 성공적으로 마무리하긴 했지만, 그래도 시간 남을 때 미리미리 구현 해두자라는 교훈을 얻었습니다.

알고리즘 주차 끝!!!

7월 15일 부터 7월 21 일 까지 배정 되어 있었던 알고리즘 주차! 서로 너무 재밌고 잘 맞기도 했고,, 알고리즘을 더 배우고 싶기도 해서 그 뒤로 한달 조금 넘게 지속한 알고리즘 주차 (셀프) 가 종료되었네요.

항해99 진행 간에, 만나는 모든 분들과 하는 것들에 먼저 최선을 다하자라고 했던 만큼...

남는 시간을 할애해서 일요일 오전 9시 나 10 시에 모여서 헀었어요.

바쁜 시간을 내서 모이는 만큼 너무 쉬운 문제를 풀기는 그래서 프로그래머스 lv 2 ~ lv 3 을 풀었는데, 저희 수준에서 어려운 문제를 고른 만큼 서너 시간은 자연스럽게 넘어갔었네요.

그래도, 끝까지 포기하지 않고 마지막에는 프로그래머스 실전 대비 모의고사 도 응시하고 나와서 후련합니다!

5월 에는 프로그래머스 코테에서 400 점 만점 중에 200점 이었는데, 이번 달에는 225점 !

당시 시험에는 알고리즘이 3문제 SQL 이 1문제였었고... 개인적으로 SQL 은 조금 적성에 맞았던 건지, SQL 이 100점이었던 것을 보면 +115 점 만큼 성장하지 않았나 싶네요!! 그때 봤던 문제보다 조금 어려웠던 것 같기도하고...

마지막 까지 함께 해주신 codeing999 님께 감사드리고 항상 오랜 시간 공부 하시는 모습 덕분에 저도 열심히 마무리 지을 수 있었습니다!!

Hanghae 알고리즘 스터디 with codeing999

CORS, Cross-Origin Resource Sharing 교차 출처 리소스 공유 에러입니다.

서로 다른 Origin 을 가지고 있는 http 서버끼리 HTTP 통신 을 할 때, 브라우저가 일으키는 오류입니다.

브라우저에서는 보안적인 이유로 cross-origin HTTP 요청들을 제한합니다. 그래서 cross-origin 요청을 하려면 서버의 동의가 필요합니다. 만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절합니다. 이러한 허락을 구하고 거절하는 메커니즘을 HTTP-header를 이용해서 가능한데, 이를 CORS(Cross-Origin Resource Sharing)라고 부릅니다. 그래서 브라우저에서 cross-origin 요청을 안전하게 할 수 있도록 하는 메커니즘입니다. 출처 - CORS란 무엇인가?

항해톡의 주제가 평소에도 관심이 많은 DBMS 여서 나가게 되었습니다.

SQL vs NoSQL 발표 후기

개별 팀 프로젝트 : Broccoli Velog

14 일 간 다섯 명이 고생했던 Broccli Velog 를 해산하게 되었습니다.

긴 시간 동안 함께 에러를 마주하고 대화하면서 많은 것들을 배우고 부족함을 실감한 시간이었습니다.

다음 협업 시기가 오기 전에 내가 뭘 준비해야 할지 확실하게 알 수 있는 시간이었습니다.

Broccoli Velog 후기

개인 공부

여러 가지 일도 있었고 자만하지 말고 더 배워야 겠다고 생각했습니다.

• API 명세서를 작성하는 시간을 줄이고 좀 더 명확하게 쓴다던가...
• 협업 간에 능률을 높여줄 수 있는 CI/CD 에 관련된 공부라던가...
• 개인적으로 관심이 많았던 Nginx 에 대한 공부라던가....

이런 부분에 대한 고민이 많아서 해당 부분을 공부하고 있습니다.

API 명세서

1번 같은 경우는 주특기 카카오 API 톺아보기 와 같은 레페런스나 실제 API 문서를 보면서 연습을 진행하고 있었습니다.

사실 Boiler-Express/Swagger Tutorial 를 만들고 진행하면서 YAML 확장자를 통한 Swagger 튜툐리얼을 하루에 약간의 시간을 들여서 학습하고 있었지만, 당장 투입할 정도의 실력이 아니었기 때문에 API 명세서.md 등으로 사용하고 있었습니다.

Swagger 를 사용하기 전까지 API 명세서 를 최소한의 시간에 최대한 가독성 높은 형태로 가공하는 작업을 반복하고 있습니다.

Nginx, reversy proxy server + ssl

다만, 좀 감격적인 학습 내용은 Nginx 를 Reversy Proxy Server 형태로 실행 시키고 80 -> 443 -> 3000 포트로 redirect 시키면서 HTTPS 서버를 구현하는데 성공했다는 것이었습니다.

초기 Nginx 80 -> 3000 을 연습 했을 때는 Velog, TStory 게시글을 참고했지만 이내 Ubuntu@2022.04 버전에서는 호환되지 않는 부분이 너무 많았습니다.

이를 버전에 맞게 수정하고 Ubuntu Nginx Certbot 등에 대한 공부를 더 진행해서 약 20 시간 정도를 투자해서 결국 이를 해결할 수 있었습니다.

A - Z 로 완성된 튜툐리얼이 없어서 파편화된 정보를 취합하고 에러 부분을 소거법으로 찾아서 해결하는 과정에서 엄청난 희열을 느낄 수 있었습니다.

뭔가 이런 모습,,, 진짜 개발자 같았을 지도,,, 이런 망상을 하면서 새벽 다섯시에 작업을 마무리하고 기절했습니다,,,,

unchaptered/express-nginx 와 unchaptered/express-nginx-https 를 통해서 단계적으로 이를 개선시켰고 목적지에 도달할 수 있어서 너무 행복했습니다.

다음 주에는 꼭 unchaptered/express-nginx-load-balance 를 통해서 LB 기능이 도입된 Nginx 를 구현하고 디테일한 Logging 이나 에러 핸들링 등의 환경 설정을 해보고 싶습니다.

항해99 가 시작하고 2주차인 알고리즘 주차에 알고리즘 스터디를 시작하게 되면서 @codieng999 님과 @axisotherwise 님과 친해지게 되었습니다.

그렇게 알음알음 이야기를 하다가, 주특기 주차에 들어가서 저녁에 남는 시간에 프로젝트에 도전해보자 라는 슬로건으로 모이게 되었습니다.

처음에는 Express 담당 세 명만 있었지만, React 담당@dusunax 님과 @somfist 세 분이 모이게 되어서 작업을 진행하게 되었습니다.

우당탕탕 기록기

🤔 우려

프로젝트에서 가장 걱정 했던 부분은 다른 분들의 주특기 공부 에 방해가 되지 않아야 한다 였습니다.

따라서, 프로젝트의 완성보다는 다음을 중요하게 여겼습니다.

• Git 을 통한 협업
  • main : 배포용 브런치
  • submain : 병합용 브런치
  • dev/작업자명 : 개발용 브런치
• 프론트엔드와 백엔드 의 협업
  • API 명세서를 통한 협업과 여러 이슈 경험

😂 미숙한 협업 준비

프로제긑의 문제가 되는 부분으 백엔드 에서 발생했다고 생각합니다.

1. 서버의 안정성 을 중점으로 생각했습니다.
   1. 이에 따라서 작업 속도가 늦어져서 프론트엔드의 작업 속도와 격차가 벌어졌습니다.
   2. 또한 API 명세서 등이 제대로 제공되지 않았기 때문에 프론트 엔드에서 이를 믿고 사용하기 힘들었습니다.
2. 협업 간에 각자의 로컬 PC 에 MySQL 을 설치하는 것이 아니라 RDS 를 사용했던 부분

🔧 안정성?

주특기를 배운지 얼마 안된 만큼 Joi 를 통한 유효성 검사나 비동기 함수 에러처리 그리고 Custom Utility 함수를 활용한 반환 객체의 안전성 등을 중점으로 다뤘습니다.

해당 부분을 @codeing999 님께서 잘 따라와주셔서 백엔드에서는 많은 배움이 있었던 것 같습니다.

🔧 RDS -> Local MySQL

팀원 분들 중 한 분이 EC2 인스턴스 에 MySQL 을 설치하고 포트를 열어 주셨는데, 약 3일 간 해당 부분의 연결이 끊어지게 되었습니다.

따라서 연관된 부분의 MySQL 호출 코드가 모두 에러를 일으키게 되었고 작업에 지장이 생겼었습니다. 이후, 해당 분이 프로젝트에서 나가게 되셔서 해당 부분을 해결하는데 시간 소요가 꽤나 컸습니다.

급하게 프론트 엔드 분 PC 에 MySQL 을 깔고 실행했던 것 같습니다.

🔧 프론트 엔드와의 협업

사실 백엔드에서는 여러 가지 문제점이 많았기 떄문에, 프로젝트 내내 프론트 엔드 분들께 죄송한 마음이 많았습니다.

RDS -> Local MySQL 로 변환되는 문제 뿐만 아니라 기존에 API 명세서를 만들면서 설계했던 테이블의 키 이름 등이 변경 되는 이슈 등이 있어서 해당 부분이 큰 스트레스 셨을 것 같습니다.

또한, 사전에 인지하고 있었음에도 CORS 처리 등을 하지 않고 submain 에 병합하는 등의 실수도 몇 일씩 고통스러운 시간을 보내게 만들었습니다.

🤔 그래서?

이번 프로젝트를 마무리하면서 든 생각은...

• API 명세서를 작성하고 이를 준수하려고 노력하고 변동 사항이 생길 것 같다면 꼭 협의 를 통해서 하자.
• morgan 을 사용하지 말고 winston 등을 사용하고 더 구체화된 로그 기록 을 제공해드리도록 하자.
• 가능하다면 submain 브런치 단계에서 테스트용 EC2 Instance 를 띄우는 방식으로 프론트엔드에서 이에 접근하기 유용하게 만들자.

💌 결과

결국 프로젝트는 완성되지 못한 상태로 남게 되었습니다.

하지만, 이 시간을 통해서 어떤 것들이 부족하고 채워넣을 수 있을 지 확실하게 알게 되었습니다.

단순히 에러 처리가 잘되어있는 서버를 떠나서, 협업을 준비 하는 자세가 있어야 높은 생산성을 기반으로 즐거운 협업이 될 수 있음을 알게 되었습니다.

14 일 동안 매일 저녁 9:30 에 모여서 고생하신 팀원 네분들에게 너무 감사하고 재밌는 시간이었습니다.

작업 순서

구조

![] (https://velog.velcdn.com/images/unchaptered_til/post/ba82a1f8-37de-407c-aeab-7881c66d256f/image.png)

Express.JS

항해 주특기 주차 (1/3) - 게시글 CRUD 을 진행하면서, 구조화된 방식으로 개선해나가는 것을 경험했습니다.

오랜만에 Express 를 쓰는 감을 다시 찾았기 때문에, 이번에는 OOP, Object Oriented Programming 에 입각해서 구조화되고 안정적인 개발을 진행해보도록 하였습니다.

😊 과제

이번 과제는 MySQL 을 사용하는 것이었습니다.

• 유저 CRUD
• 게시글 및 댓글 CRUD
• 좋아요 기능

몇 가지 필수 구현사항과 API 요구사항을 받고 과제를 진행하게 되었습니다.

이번에는 Layered Architecture 를 적용하였습니다.

😂 불편한 JS (타입 추론 지원)

JavaScript 에서도 함수 주석을 이용하면 TypeScript 처럼 타입 추론을 쓸 수 있는 것을 알아냈습니다.

항해 주특기 주차 (1/3) - 게시글 CRUD ### 😂 불편한 JS

👌 커스텀 예외 + 예외 미들웨어

커스텀 예외와 글로벌 미들웨어를 통한 글로벌 예외 처리 파이프라인 을 만들어서 사용했습니다.

항해 주특기 주차 (1/3) - 게시글 CRUD ### 👌 커스텀 예외 + 예외 미들웨어

단, 잘못된 경로로 접속할 경우에 res.locals.error 가 없어서 Cannot read property from 'undefined' 가 발생했던 문제점을 찾고 이를 개선했습니다.

// 예시

if (!res.locals?.error) {
    res.status(404).json({
       isSuccess: false,
       message: `Not Found Exception : 해당 경로는 지원되지 않습니다.`,
       result: {}
    });
}

⚡ Entity + Dto

단순하게 설계된 테이블에 Entity 와 Dto 를 만들어서 매개변수를 직관적인 영역으로 개선했습니다.

또한, BaseEntity 에 2가지 핵심 요소를 설계했습니다.

1. [Symbol.iterator]: generator 를 통한 모든 Entity, Dto 를 @@iterable 화 하여 구조분해 사용 가능하게 변경
2. _getJoiInstance() 메서드를 정의하고 에러를 던져서 Java 의 추상 클래스를 이용한 특정 메서드의오버라이드 강요 와 같이 구현

해당 부분들을 이용해서 JoiValidator 와 같은 특정 클래스들의 추상화 단계를 올릴 수 있었습니다.

await new JoiValidator()
  .validate(dto, dto._getJoiInstance());

위와 같이 실행할 수 있는 함수를 만들었습니다.

프로젝트 종료 후, 다시 생각 해보니, 그냥 dto 만 넘기고 내부에서 _getJoiInstance() 를 하게 만드는 것도 나쁘지 않았을 것 같습니다.

💌 API 명세서 작성

곧 시작될 항해 팀 프로젝트 들을 대비하고 있는데요, 그 중에서 원활한 의사소통을 위한 API 명세서 작성을 연습하고 있습니다.

다음의 카카오 DOCS - API 문서 톺아보기 를 읽고 공감 가는 부분을 반영하고 있습니다.

unchaptered/hanghae-backend-2 중 API 명세서 파일 에 들어가셔서 명세서 작성 파일을 확인하실 수 있습니다.

아쉬웠던 점

이번 주차의 구현 목표는 모두 성공했습니다. 하지만, 주특기 전 주차에 계획했던 CI/CD : EC2 배포 자동화 파이프 라인 구축 에 도전하지 못한 것이 아쉬웠습니다.

아무래도, 주특기 주차 동안 다른 분들의 QnA 에 응하고 에러를 같이 보거나, 항해톡 - SQL vs NoSQL 과 주특기 주차 시작부터 2 주간 별도로 진행한 사이드 프로젝트 - Broccoli Velog 를 병행하느라 시간 소요가 컸던 것 같습니다.

항해톡이란?

항해99에서 2주차 부터 5주차까지 총 4회 진행되며, 지정된 주제 혹은 개별 주제 에 대해서 참가자를 지원받아서 발표를 진행하는 시간입니다.

총 3주 간 진행 되는 주특기 주차 중에 2주차 에 있었던 3번째 항해톡에 참가했습니다.

항해톡

주제 : SQL vs NoSQL 일자 : 2022년 8월 2일 PPTX : Figma(pptx) - SQL vs NoSQL FIGMA : Figma(file) - SQL vs NoSQL

어떤 주제로?

저는 개인적으로 새로운 것에 대한 호기심이 강한 편이여서 다른 분들보다 많은 DBMS 를 사용해봤던 것 같습니다.

그래서 이번 기회에 SQL vs NoSQL 주제를 맡고 이 부분을 정리해서 다른 분들에게 알려드리고 싶었습니다.

발표를 준비하면서...

다음과 같은 부분을 고려해서 발표를 준비하게 되었습니다.

1. SQL vs NoSQL 에서 어떤 방향성으로 발표를 해야 하는가.
2. SQL vs NoSQL 중에서 어떤 서비스를 중심으로 발표 할 것인가.

그 결과 MySQL/PostgreSQL , MongoDB, Redis 에 대해서 설명하고 어떤 기술들, Transaction, Index, Table Split 과 캐싱(읽기 전략/쓰기 전략 등) 을 소개 하고자 했습니다.

리허설 시간...

항해톡 후기 - 객체 리터럴 그리고 구조분해 할당 ### 회고 에서 피드백 을 제대로 받지 않고 세션을 진행한 것을 후회했습니다.

그래서 주차 팀원 분들 과 같은 주차의 항해톡 발표자 분들의 도움을 받아서, 전날과 당일에 1회 씩 발표 리허설을 했습니다.

리허설을 하고 받은 피드백을 반영해서 내용을 보완하고 개선하는 과정을 거치게 되었습니다.

실제 발표

저번 발표는 15분 발표에 15분 질문 시간으로 분배를 했지만, 이번 발표에서는 25분 발표에 할당을 했습니다.

아무래도 마지막 순번 발표인 만큼, 시간이 살짝 넘어가더라도 최대한 디테일 한 설명들을 덧붙여서 해드리고 싶었습니다.

아쉬웠던 점

항해톡 발표일 하루 전 에 신청을 해서 준비를 했기 때문에, 제가 알고 있는 부분을 조금 더 디테일하게 표현하지 못했던 것 같습니다.

실제 레포를 만들고 사용 사례를 보여드리면서 설명을 했더라면, 더욱 값진 항해톡이 되었을 것 같습니다.

항해의 1주차/2주차 주제가 모두 게시글 을 포함하고 있었습니다.

더군다나, 1주차 시작부터 진행 중인 토이 프로젝트 Broccoli-Velog 도 블로그를 포함하고 있었습니다.

그런데 일반적으로 글 을 의미하는 단어가 post 인 탓에 어떻게 해야 하는지 고민이 있었습니다.

저희는 컬렉션 이름을 note 로 하는 것으로 합의 했지만, 실제 운영 중인 사이트는 어떤지 찾아보았습니다.

Velog

벨로그 같은 경우는, 일반적인 RESTful API 의 구조를 벗어난 듯 보였습니다. 기본 적으로 게시글을 쓰는 사이트라서 그런지, 아예 컬렉션 이름이 없었습니다.

• https://velog.io/@소유주이름/게시글-제목

Naver

놀랍게도 벨로그와 유사했는데, 신기한 부분은 도메인 앞에 blog. 라는 이름이 붙어 있었습니다. 다만, 네이버 블로그는 메모 와 같은 기능도 제공해주고 있어서 하위 컬렉션이 있다는 점이 특이했습니다.

• https://blog.naver.com/닉네임/게시글-일련-번호
• https://blog.naver.com/닉네임/memo/게시글-일련-번호

다만, 제가 알기로는 네이버는 모바일 과 웹 이 적응형 디자인으로 짜여져 있었으나 앞에 m. 이 붙는 것 외에는 차이가 없었습니다.

• https://m.blog.naver.com/닉네임/게시글-일련-번호

Okky

마지막으로는 개발자라면 모두가 알고 있지 않을까,, 싶은 okky.kr 이라는 개발자 커뮤니티 사이트를 체크했습니다.

해당 게시글은 다양한 주제에 대한 게시글을 올리는 구조를 가지고 있습니다. 특이한 점은 이러한 카테고리 라는 것 자체를 컬렉션 으로써 사용하고 있는 점이었습니다.

인프런 과 같은 강의 사이트에서는 카테고리 가 queryString 으로 ?cateogry=web 등으로 사용되는 것과는 달랐습니다.

• https://okky.kr/큰-카테고리/작은-카테고리

package.json

개인적으로 항해를 준비하면서 협업 관련 기능을 많이 찾아보았습니다.

그리고 package.json 과 package-lock.json 의 차이를 알게 되었습니다.

짤막하게 쓰자면, 협업 시에는 한 명이 모듈을 깔고 다른 사람들은 npm ci 를 사용하자!

작업 순서

구조

Express.JS?

연초에 인프랩 에 백앤드 신입으로 지원서를 넣으면서 본격적으로 TypeScript Ineversify 조합으로 Express 를 개발을 하게 되었습니다.

제가 못찾은 걸 수도 있었겠지만 별도의 한글 자료가 없어서 공식 문서를 기반으로 많은 코드를 참고했었던 것 같습니다.

그 뒤로도 다른 프레임 워크에서 작업을 하다가, 순수한 Express.JS 로 작업을 하니 생소한 기분이었습니다.

😊 과제

Velog - 항해 첫 번째 프로젝트 후기

항해가 시작하고 Flask 로 진행한 프로젝트로 MongoDB Atlas 를 사용해서 였을까, 이번 과제도 MongoDB 를 이용하는 것이었습니다.

• 게시글 및 댓글 CRUD 를 포함한 RESTful API

몇 가지 필수 구현사항과 API 요구사항을 받고 과제를 진행하게 되었습니다.

이번 과제에서는 간단하고 에러 처리가 완료된 프로토 타입 을 구현 및 배포를 하고 지속적으로 리팩토링 하면서 점진적으로 개선해나가는 경험해보자 했습니다.

😂 불편한 JS

TypeScript 를 쓸 때는 당연했었던 @types/** 의 부재가 너무나 슬펐습니다.

특히, 모든 파라미터가 any 속성 이여서 함수 추출하기를 통한 리팩터링이 너무나 어려웠습니다.

아마도 이미 편하게 사용 중인 프레임워크가 아니였다면, 해당 과정이 배는 오래 걸렸을 것 같습니다.

const join = (req, res, next) => {
   req. ???
}

해당 부분은 이번 주차 프로젝트를 하면서 찾아낼 수 있었습니다.

import Express from 'express';

/**
 * @param { Express.Request } req
 * @param { Express.Response } res
 * @param { Express.NextFunction } next
 */
const join = (req, res, next) => {}

👌 커스텀 예외 + 예외 미들웨어

리팩토링을 진행하면 다양한 계층이 생기게 됩니다. 해당 계층에서 모두 일일히 if-else 를 해서 분기 처리를 하는 것은 너무 소모적인 경험 이었습니다.

그래서 찾은 풀이법은 statusCode 와 같은 추가 필드를 가진 커스텀 예외 클래스 였습니다.

class CustomException extends Error {

  statusCode;

  constructor(message) {
    super(message);
    this.statusCode = 400;
  }
}

새로운 종유의 문제 상황을 찾아 내면 name 과 statusCode 에 적합한 고정 값을 부여하고 사용하였습니다.

그리고 CustomException 의 수많은 서브 클래스들은 Controller 영역에서 처리 되는 방식을 사용했습니다.

const join = (req, res, next) => {
   try {
   } catch(err) {
     return res.status(err.statusCode)
                .json(err.message);
   }
}

하지만 해당 코드들이 반복되는 구조는 아름답다고 느끼지 못했고, exceptionMiddleware 를 만들어서 위임하는 것으로 간소화 했습니다.

const join = (req, res, next) => {
   try {
   } catch(err) {
     res.locals.error = err;
     return next();
   }
}

🤷‍♀️ AWS ubuntu permission denied!

Flask 주차 부터 약 3주 간 저를 괴롭혔던 문제 였습니다.

권한 설정이 안되어 있는 **.pem 와 관련된 문제였고 chmod 400 이 먹히지 않았습니다. 심지어, 개발할 때 쓰는 드라이브에는 보안 탭 이 갑자기 사라진 상태였습니다.

연초 3월 까지는 해당 보안탭으로 보안 그룹 수정을 하였던 상태

해당 부분은 **.pem 키를 별도의 드라이브에 저장하고 보안 설정을 변경하는 것으로 우회 해결하였습니다.

Bug : EC2 인스턴스 접속 거부 (Windows 10, 해결)

아쉬웠던 점

초기에 계획했던 CI/CD : EC2 배포 자동화 파이프 라인 구축 을 이루지 못했습니다. 해당 부분보다 모듈화를 통해서 직관적인 코드로 개선하는 것이 중요하다고 판단해서 제한 시간이 초과되었습니다.

이번 주차 unchaptered/hanghae-backend-2 에서 해당 부분을 보완해보고 싶습니다.

항해톡이란?

항해99에서 2주차 부터 5주차까지 총 4회 진행되며, 지정된 주제 혹은 개별 주제 에 대해서 참가자를 지원받아서 발표를 진행하는 시간입니다.

알고리즘 주차에 항해톡 이라는 레퍼런스가 있었고 발표자를 모집하는 내용을 알게 되었습니다.

하지만 알고리즘 스터디와 CS 스터디 가 시작되었었기 때문에, 기존의 팀에 영향을 주지 않으면서 진행할 수 있을지 확신할 수 없었습니다.

개인 공부 시간을 어느 정도 할애하면, 일정 상에 이슈가 없을 것 같다는 판단에 참여하게 되었습니다.

항해톡

주제 : 객체 리터럴, 그리고 구조분해할당 일자 : 2022년 7월 21일 PDF : GitHub - 객체리터럴, 그리고 구조분해할당 PPTX CODE : Replit - 객체리터럴, 그리고 구조분해할당 예제 코드

어떤 주제로?

기존에 제시된 주제 중에서는 RESTful API 가 가장 매력적으로 다가왔습니다.

하지만 고민 하는 사이에 관련 주제가 선점되어서, 가장 잘 이해하는 객체리터럴 그리고 구조분해할당 을 선택하였습니다.

발표를 준비하면서...

다음과 같은 부분을 고려해서 발표를 준비하게 되었습니다.

1. 왜 항해 에서 첫 주차 주제에 객체리터럴 그리고 구조분해할당 을 추가하였을까.
2. 발표의 깊이와 방향성을 정하자
   1. 깊이 : JS 나 알고리즘을 처음 접하는 사람
   2. 방향 : 두 가지 주제가 유연하게 연결되어 WHY / WHAT / HOW 의 포커스를 맞춰서 설명해보자

리허설 시간...

평일 오후에, 함께 알고리즘 문제를 푸는 GitHub - 알고리즘 스터디 의 두 분께서 리허설을 도와주셨습니다.

혼자서 녹화를 하면서 리허설을 진행했을 때에는 여유롭고 정확히 15분 을 맞춰서 발표를 진행했습니다.

하지만, 다른 분들이 듣고 있다는 것을 인지하니 부끄럽고 긴장되어 2분 가량 짧게 발표하고 내용도 어느 정도 누락되었던 것 같습니다.

실제 발표..!

실제 발표 시간이 되니, 생각보다 더 많이 긴장이 되었습니다. (살려줘)

리허설 이후에, 팀원 분들이 주신 아래 피드백들을 보충해서 발표를 진행했습니다.

• 리터럴에 대한 자세한 설명이 포함되면 좋을 것 같다.
• PPTX 에 여러 가지 설명 이나 화살표 등이 포함되면 좋을 것 같다.

추가된 내용들을 기반으로 발표를 진행을 했고, 계획된 시간인 20분 에 맞춰서 발표를 종료하였습니다.

회고

여러 차례 피드백을 받고 발표를 했다면 어땠을까? 라는 생각이 드는 시간이었습니다.

발표 시간이 끝나고 나서 크게 질문이 들어오지 않아서, 아래와 같은 결론에 이르렀습니다.

1. 질문을 할 수 있을 포인트를 따로 선정해두지 않았던 점.
2. 매력적으로 보이는 상황을 보여주지 못했던 점.

또, 예제를 들었던 개별 문항보다 알고리즘 주차 에 모두가 풀었던 문제로 예시를 들었으면 좋았을 것 같습니다.

해당 문제에서 객체 리터럴 과 구조분해할당 을 사용하는 예시를 들었다면 더욱 간결한 설명이 되었을 것 같습니다.

• 서버 저장소 : unchaptered/coffee-selector
• 크롤러 저장소 : unchaptered/coffee-selector-selenium

항해99 에서는 면접과 사전 테스트 을 보았는데, 커리큘럼 시작과 동시에 첫 번째 프로젝트를 하게 되었습니다.

약간 낯선 게더타운이라는 환경에서 화면 상으로 만난 팀원 분들과 2022-07-11 부터 2022-07-14 까지 진행되었습니다.

Flask?

항해 에서 Flask 를 이용한 SSR 서버 를 몇 가지 요구사항과 함께 전달받아 구현하게 되었습니다.

SSR 이란?

서버 사이드 랜더링으로 별도의 문법이 적용되는 탬플릿 엔진 (PUG, Jinja2) 을 사용하며, 서버 측 에서 해당 템플릿을 요청에 맞는 HTML 로 랜더링(변환) 하는 기법을 의미합니다.

🤔 우려

프로젝트 진행 과정에서 가장 걱정이 되었던 것은 저 였습니다.

과거에 잘못된 방식의 코드 리뷰 를 간섭의 방식으로 했던 적이 있었고 이를 크게 반성한 경험이 있습니다.

그 이후로 어떻게 팀 프로젝트 에서 포지셔닝을 해야 하는 가를 많이 찾아보고 고려하게 되었습니다.

모 개발자 채널에서 봤던 꼭 한 번에 한 가지씩만 전달하자 라는 내용을 되새겼습니다.

그래서 개발을 처음 시작했을 때, 1 주일 차의 마음을 가지자 라고 마인드를 가다듬었습니다.

😂 에러는 확실히 짚고 넘어가자

마임드 셋과는 조금 반대되는 내용인데, 특정한 부분들은 확실하게 알려드리고 싶었습니다.

첫 프로젝트에 적은 기능이 들어가더라도, 다른 팀원분들에게 첫 협업 이라는 특수성에서 다음의 내용을 알려드리고자 했습니다.

• Git 사용에 대한 기본적인 메뉴얼과 자주 발생하는 에러와 해결법
• 첫 개발에 놓치기 쉬운 환경 변수 에 대한 개념과 그 처리 방법
• 작업 속도가 조금 늦어 지더라도 트러블 상황을 공유하고 함께 해결 하는 과정

Git 사용에 대한 기본적인 메뉴얼과 해결법

Git 에 대해서 처음으로 배웠던 당시에 적었던 메뉴얼을 개선시켜 작성하였습니다.

• unchaptered/coffee-selector 중 Git syntax.md

환경 변수에 대한 개념과 그 처리 방법

사실 환경 변수 파일인 .env 를 호출 해서 이를 사용하는 방법은 너무나 간단했습니다.

단, 이 파일을 .gitignore 처리 했어야 했기 떄문에, env.md 에 추가된 환경 변수 명을 적고 공유하는 식으로 전파하게 되었습니다.

저희는 MongoDB Atlas 를 로컬과 운영 환경에서 모두 사용하되, 배포 시에는 다른 데이터베이스를 사용하는 방법을 선택했기 때문입니다.

작업 속도가 조금 늦어지더라도 트러블 상황을 공유하고 함께 해결하는 과정

사실 개발을 처음 배웠을 때, 가장 부족한 것은 실력 보다는 경험이라고 생각합니다. _ 물론, 저도 너무나 부족하지만... _

개발을 하다보면 어느 순간부터, 어떤 상황에서 저번에 겪었던 상황과 유사한데? 이것도 이건가? 라는 감이 오기 시작했습니다.

특히, 라이브러리의 버전 이슈에 따라서 메서드 의 유무/형태 와 인코딩/호환성 등이 달라지는 것은 한 번 겪기 전에는 쉽게 예상하기 힘든 문제일 것입니다.

해당 문제들을 마주했을 떄, 화면 공유 를 하고 최대한 문제를 공유하여 이를 해결했습니다.

그 결과 기능 미구현 항목 제외하고 모든 치명적인 에러를 수정해냈습니다.

회고

짧은 4일 간의 기간이었지만, 생각보다 많은 에러가 발생했고 이를 해결할 수 있었습니다.

JS 가 아닌 Python 으로 개발을 진행하면서 생각보다 새로운 기분도 들었습니다.

생애 첫 개발임에도 빠르게 적응하고 팀에 기여해주시는 팀원 분들을 보면서, 저도 더 최선을 다해야 겠다고 생각했습니다.

트러블 슈팅

• Git 사용 어려움 > Click
• Git pull 할 때마다, Python 인터프리터 연결이 해제되는 경우 > Click
• Nespresso 사이트 크롤링 거부 > Click
• 팀원들 간에 특정 변수가 달라져야 했던 이유 > Click
• MongoDB Atlas 함수가 작동하지 않았던 경우 > Click
• PyJwt.decode 가 AWS 에서만 에러가 일으키는 경우 > Click