잡코리아의_영업_관리_시스템과_조직_문화_모더나이제이션_여정

잡코리아 영업 관리 시스템과 조직 문화의 현대화 여정

현대화의 중요성과 그 과정에서의 문제점 및 개선 목표를 정의하고, 비즈니스 민첩성을 높이는 효과적인 방법을 공유합니다. 또한, Event Storming과 설계 문서화를 통해 변화를 세분화하며, 변화하는 시장 환경에 적응하기 위한 기술적 접근과 협업 방식을 강조합니다.

🚀 1. 모더나이제이션의 중요성과 접근 방식

**모더나이제이션(Modernization)**은 비즈니스 민첩성과 엔지니어링 효율성을 극대화하기 위해 최신 인프라, 아키텍처, 조직 패턴을 활용하는 것입니다.

• 모놀리식 아키텍처의 한계
  모놀리식 아키텍처는 새로운 기능 적용과 피드백 수집 속도를 저하시킬 뿐만 아니라, 대규모 변경 시 높은 위험을 수반합니다.
• 마이크로서비스 아키텍처의 장점
  마이크로서비스 아키텍처는 비즈니스 기능을 분리하고, 분산 거버넌스 및 데이터 관리를 통해 민첩성을 향상시킵니다.
• Event Storming과 문서 기반 개발
  Event Storming은 대규모 아키텍처를 분석하고 설계하는 과정에서 효과적인 협업 도구로 사용되며, 문서 중심 개발은 잠재적인 문제를 사전에 파악하고 해결하는 데 도움을 줍니다.

🔄 2. 잡코리아 내부 영업 관리 시스템의 문제점 및 개선 목표

잡코리아 내부 영업 관리 시스템은 상품, 매출, 주문, 고객관리 등 여러 역할을 수행하며, 비효율적인 부분이 존재합니다.

• 주요 문제점
  • 상품과 사용자 서비스 간의 강한 결합으로 **단일 실패 지점(SPOF)**이 존재.
  • 현재의 워터폴 방식 업무는 민첩한 대응이 어려움.
• 개선 목표
  • 도메인 분리를 통해 시스템 역할을 축소.
  • 사용자 서비스와의 연동 방식을 API 기반으로 전환.
  • 워터폴에서 애자일(Agile) 방식으로 전환하여 유연성을 강화.

🌟 3. Event Storming을 통한 시스템 아키텍처 전환 방법

Event Storming은 모놀리식 아키텍처를 **마이크로서비스(Microservice)**로 전환하는 데 핵심적인 기법입니다.

• 주요 특징
  • 비즈니스 도메인 이벤트를 식별 및 그룹화하여 대형 아키텍처를 설계.
  • 기술 전문 지식 없이도 도메인 지식을 가진 누구나 참여 가능.
  • 유비쿼터스 언어를 통해 팀 간 통일된 이해도를 형성.
• 적용 사례
  잡코리아의 영업 관리 시스템 역할을 분석하고, 이벤트를 기반으로 도메인 및 서브 도메인을 추출. API 개발과 연결하여 아키텍처 전환을 도출.

📝 4. Amazon의 문서 중심 개발 문화와 프로젝트 방법론

아마존의 문서 중심 개발 문화는 코드 작성 전에 명확한 설계와 문서화를 강조합니다. 이를 통해 잠재적인 문제를 조기에 발견하고 해결할 수 있습니다.

• 문서화의 목적
  • 기능 중복 방지.
  • 모범 사례와 안티 패턴 식별.
  • 코드 품질 향상 및 프로젝트 성공 가능성 증가.
• 프로젝트 수행 방식
  1. 설계 문서를 기반으로 Design Epic & Backlog 작성.
  2. Design Proposal 단계에서 인프라 구성, 보안 규정, 아키텍처를 구체화.
  3. Scrum Master가 Event Storming에서 추출된 API 및 Task를 중심으로 스프린트 진행.
• Daily Scrum
  매일 짧은 회의를 통해 팀원들이 진행 상황을 공유하고 이슈를 토론하며 협력.

🔍 5. 스프린트 회고와 차후 단계 설정

스프린트 회고는 잘한 점과 부족한 점을 익명으로 공유하여 개선점을 도출하는 중요한 단계입니다.

• 스프린트 후속 작업
  • 추가로 필요한 Task를 Backlog에 포함.
  • 다음 스프린트의 Task를 선정하고 팀원들이 자신의 업무를 결정.
• 차후 단계
  • Event Storming과 설계 문서화 작업 지속.
  • AWS의 무료 디지털 학습 콘텐츠를 활용하여 클라우드 역량 강화.

결론

이 여정은 잡코리아의 영업 관리 시스템 현대화와 조직 문화 혁신을 통해 비즈니스 민첩성을 높이고, 변화하는 시장 환경에 유연하게 대응할 수 있는 기반을 마련하는 과정입니다. 모더나이제이션은 단순한 기술 전환이 아니라, 조직 전체의 업무 방식과 협업 문화를 변화시키는 중요한 과정임을 보여줍니다.

323. NAT 인스턴스

NAT Instance

• NAT= Network Address Translation
• 사설 서브넷의 EC2 인스턴스가 인터넷에 연결되게 한다. ( 배스천 서버랑 비슷한 듯 다르다.) 
• 공용 서브넷에 NAT 을 설치해야한다. 
• EC2 설정에서 : Source / destination Check 옵션을 비활성화 해야한다.
• EIP 가 부착되어야한다.
• 라우팅 테이블에 사설 서브넷이 NAT 인스턴스로 연결되도록 구성해야한다. 

사설 서브넷의 ec2가 외부의 server 와 통신할려면 .공용 서브넷의 NAT 인스턴스에 연결하고 여기서 라우팅을 변경한다. 

server 입장에서 패킷을 받았을때 10.0.0.20 소스가 아니라 12.34.56.78 소스이다. 

이런 식으로 구성해 볼 것이다. 

Comment 

사실 NAT 인스턴스는 이제 NatGateway로 구현할 수 있다. 

가용성도 낮고 대역폭도 작다. 

그래도 실습해보자! 

324. NAT 인스턴스 실습

인스턴스 설치

아마존에서 지원 하지 않기 때문에 커뮤니티 이미지를 설치해야한다. 

x86_64

네트워크 설정

지난 시간에 만든 PrivateInstance가 NAT 인스턴스로 접속하게 한다. 

중지로 저장

BastionHost 에서 privateInstance 접속하기 

ssh 명령어로 로그인

핑을 쏴도 보내지지 않는다. ?

프라이빗 서브넷에 접속은 가능하지만 인터넷에 연결이 되어있지는 않다. 

프라이빗 라우팅 테이블 수정하기 

0.0.0.0/0 외부 ip 로 갈려면 nat 인스턴스를 통해 가야하도록 정했다. 

하지만 여전히 인터넷 접속 불가능하다. 

Nat 인스턴스의 보안그룹 편집 

모든 ICMP - IPv4 허용

이제 핑이 된다. 

Nat 인스턴스 삭제하기 

324. NAT Gateway

NAT Gateway 

• AWS 에서 제공하는 NAT, 높은 광대역, 가용성 , 완전관리형
• 사용한 만큼 비용청구 
• 특별한 가용존에 사용되고 EIP를 사용한다. 
• ec2 와 같은 서브넷에서 사용될 수 없다.
• IGW 가 필요하다 private subnet -> NATGW -> IGW
• 5~45Gbps 광대역
• 보안그룹 관리할 필요 없음.

NAT GW 를 통해서 인터넷에 연결한다. 

NAT GW 의 고가용성

NAT GW은 az에 국한된다. 

여러개의 NAT GW를 구성해서 내결함성을 가질 수 있다. 

AZ를 가로질러 갈 수 없다. 

NAT GW 와 NAT instance 와 비교

결론은 NAT GW 가 좋다. 

보안그룹 x , 배스천 호스트 쓸 필요도 없다. 

326. NAT Gateway 실습

Nat Instance 삭제

위에서 Nat instance를 삭제하고 나면

privateRouteTable에서 라우팅 에러가 뜬다 .

0.0.0.0/0 의 대상은 nat instance 였기 때문

NAT Gateway 생성

EIP 를 할당해서 생성해보자!

라우팅 테이블 편집

privateRoubeTable 에서 0.0.0.0/0 은 NatGW 로 가게 한다. 

privateinstance 가 인터넷에 연결 가능해졌다

327. NACL 및 보안그룹

NACL 은 stateless 라서 들어오고 나가는거 다 확인하지만 

SG는 stateful 이라서 한번이라도 확인하면 그후에는 검사안하고 허용해준다. 

• NACL 은 서브넷 단의 방화벽 역할 
• 한 서브넷당 하나의 NACL 을 가지고 처음에는 기본 NACL 을 가진다. 
• NACL 규칙 
  • 1~32766 의 번호를 가지고 낮은 숫자일 수록 우선 순위가 높다. 
  • 100 단위로 하는 것을 권장 
• 초기에 NACL 은 모든 접속을 거부할 것이다. 
• NACL은 특정 IP 주소의 접근을 차단하는 훌륭한 방법이다. 

기본 NACL

기본 NACL 은 모든 인/아웃바운드를 허용한다.

임시 포트

• 클라이언트가 연결할려면 포트를 지정해야한다. 하지만 응답 받을때 특정한 포트로 받을 수 있다.
• OS 에 따라 포트 범위가 다르다. 

접속할때 443 포트를 지정했지만 응답시 50105 임의의 포트로 응답받게 했다. 

NACL 과 임시포트

웹서버에서 db로 접속할때 3306 을 명시한다.

응답 받을 때는 임시 포트로 응답받기 때문에 다른 범위의 포트로 받게 되면 못 받기 때문에 조심해야한다.

각각의 연결 조합을 고려해야한다.

Security Group vs. NACLs  

sg 는 인스턴스  NACL 은 서브넷 단 

sg는 허용 규칙 NACL 은 허용, 거부 규칙 가능 -> 특정 ip 거부 가능

328. NACL 및 보안 그룹 실습

인바운드 규칙에 모두 허용이다. 100 숫자가 낮기 때문에 

HTTPD 서버 설치

배스천 호스트로 이동 

sudo yum install -y httpd

sudo systemctl enable httpd

sudo systemctl start httpd

sudo su

echo "hello world" > /var/www/html/index.html

bastion 호스트의 sg 인바운드 규칙 편집

배스천 호스트에 접속할 수 있다. 

NACL 수정해보기 

80 번으로 http 접속을 거부하는 규칙을 추가해보자 

-> 무한로딩에 걸린다 .

80을 140 으로 하면 100이 우선시 되서 접속이 잘된다. 

329. VPC 피어링 

VPC Peering

서로다른 aws 네트워크를 연결하는 기술 

같은 네트워크에 있는 것처럼한다. 

CIDR를 중복시키지 말것 

전이 되지 않는다. ( a와 b 연결, b와 c 연결 했다고해서 a~c 연결되는 것은 아니다. ) 

Good to know 

다른 계정, 다른 리전의 VPC 와 연결할 수 있다. 

보안 그룹도 공유할 수 있다. 

VPC 피어링을 해보자! 

330. VPC 피어링 실습 

DdfaultVPC 와 DemoVPC 를 연결해보자! 

Default Instance 만들기 

DefaultVPC 로 지정한다 .

해당 인스턴스로 접속

bastion 호스트에도 접속

지난 시간에 만들었던거

여기서도 똑같이 뜨게 만들자.

피어링 연결 생성

요청 수락 작업을 한다. 

라우팅 테이블 수정하기

 Default 라우팅 테이블이랑 PublicRouteTable을 연결할 것이다. 

DefaultVPC 의 CIDR 172.31.0.0/16 으로 들어오는건 피어링 연결로 다 접속 시킨다. 

이번엔 DefaultRouteTable 수정

DemoVPC의 CIDR 10.0.0.0/16 으로는 피어링 연결로 보낸다. 

연결되었다.

결론 

vpc 피어링하고 서로 연결하게 할려면 routetable 두개다 수정해야한다. 

313. CIDR, 비공개 및 공개 IP

Understanding CIDR - IPv4

• Classless Inter-Domain Routing - IP 주소를 할당하는 방법
• 보안 그룹 규칙과 aws 네트워킹에 사용됨
• IP 의 범위를 지정해준다.
  • WW.XX.YY.ZZ/32 ⇒ one IP
  • 0.0.0.0/0 ⇒ all IPs
  • 192.168.0.0/26 → 192.168.0.0 - 192.168.0.63 ( 64개의 IP 주소)
• CIDR 의 두가지 구성 요소
• Base IP 기본 IP
  • 범위에 포함된 IP
  • 일반적으로는 범위의 시작이 되는데 범위 내부에 있기도 한다.
  • ex) 10.0.0.0 , 192.168.0.0, 등이 있다.
• Subnet Mask 서브넷 마스크
  • IP에서 변경 가능한 비트의 개수를 정의
  • ex): /0 , /24, /32
  • 두가지 형태로 가능
    • /8 → 255.0.0.0
    • /16 → 255.255.0.0
    • /24 → 255.255.255.0
    • /32 → 255.255.255.255

Understanding CIDR - Subnet Mask

• base IP 로부터 추가적인 IP 값을 추가한다.

만약 서브넷마스크가 /0 이되면 모든 IP를 허용하는게 된다.

/0 은 모든 옥텟 변경가능 /32 하나만 사용가능

Understanding CIDR - Little Exercise

• 192.168.0.0/24 의 의미는 무엇일까?
  • 마지막 2의 8 승 256개 변경가능 0부터 255까지
• 192.168.0.0/16 =?
  • 마지막 2의 16승 256*256=65536 개
• 134.56.78.123/32 =?
  • 134.56.78.123 하나의 IP 만 사용가능
• 0.0.0.0/0 =?
  • 모든 IP 허용

CIDR to IPv4 Address Range Utility Tool | IPAddressGuide

해당 페이지에서 IP 범위를 계산할 수 있다.

Public vs. Private IP ( IPv4)

• Internet Assigned Numbers Authority (IANA)
• 사설 IP는 특정 값만 허용한다.
  • 10.0.0.0 - 10.255.255.255 (10.0.0.0/8) | 매우 큰 네트워크에서 사용
  • 172.16.0.0 - 172.31.255.255 (172.16.0.0 /12) | aws 의 기본 vpc 범위
  • 192.168.0.0 - 192.168.255.255 ( 192.168.0.0/16) | 홈 네트워크 에서 사용

314. 기본 VPC 개요

Default VPC Walkthrough

• 모든 aws 계정은 기본 VPC를 갖는다.
• EC2 인스턴스는 기본 VPC에서 실행된다. 서브넷 명시가 없다면
• 기본 VPC는 인터넷에 연결되어 있어서 EC2 인스턴스도 인터넷에 연결될 수 있다.
• 공용 및 사설 IPv4 DNS 이름을 얻을 수 있다.

실습 - VPC 콘솔 확인

기본 IPv4 CIDR 범위

해당 범위를 계산했을때

IP 하나만 생성되어있다.

해당 VPC 와 연결되어있는 서브넷이다.

CIDR 범위는 172.31.32.0/20 이다.

범위를 계산하면 4096개의 IP를 사용가능한데

4091 개만 사용할 수 있다.

315. VPC 개요

VPC in AWS - IPv4

• VPC = Virtual Private Cloud
• 단일 AWS 리전에 여러 VPC 를 둘 수 있다. (리전당 최대 5개)
• VPC 마다 할당 CIDR 는 5개
  • 최소는 /28개 (16개 IP)
  • 최대는 /16개 (65536ro IP)
• VPC는 사설이기 때문에 사설 IPv4 범위만 허용된다.
  • 10.0.0.0 - 10.255.255.255 ( 10.0.0.0/8)
  • 172.16.0.0 - 172.31.255.255 (172.16.0.0/ 12)
  • 192.168.0.0 - 192.168.255.255 ( 192.168.0.0 / 16)
• VPC CIDR의 주소가 다른 네트워크와 겹치면 안된다.

316. VPC 실습

vpc 가 생성되었다.

CIDR 편집에서

추가할 수 있다.

VPC 당 CIDR 5개 까지 가능

317. 서브넷 개요

VPC - Subnet (IPv4)

• VPC 내부에 있는 IPv4 주소의 부분 범위 이다.
• 이 범위 내에서 AWS가 IP 주소 다섯 개를 예약한다.
• ex) 10.0.0.0/24
  • 10.0.0.0 - 네트워크 주소로 예약
  • 10.0.0.1 - aws vpc 라우터로 예약
  • 10.0.0.2 - aws dns 에 매핑
  • 10.0.0.3 - aws 예비용
  • 10.0.0.255 - 브로드캐스트 주소 255 하지만 aws 는 vpc에서 브로드캐스트를 지원하지 않는다.
• 만약 29개의 IP가 필요하다면
  • /27 서브넷은 고르면 안된다. 2의 5승 32 , 32 -5 = 27
  • 대신 /26 서브넷을 골라야한다. 2의 6승 64, 64 -5 = 59

318. 서브넷 실습

DemoVPC 선택하고 서브넷 생성하기

공용, 사설 서브넷을 만들었지만 이름만 그렇다.

게이트웨이를 추가함으로써 구현하자 .

319. 인터넷 Gateway 및 라우팅 테이블

Internet Gateway (IGW)

• VPC의 리소스를 인터넷과 연결되게 한다.
• 수평으로 확장되고 가용성과 중복성이 높다.
• VPC 와 별개로 생성된다.
• 하나의 VPC 는 인터넷 Gateway 하나에만 연결된다. 반대의 경우도 마찬가지
• IGW 스스로 인터넷 액세스를 허용하지 않는다.

igw → 라우터 → 라우팅 테이블 → sg → 인스턴스 이다.

320. 인터넷 Gateway 및 라우팅 테이블 실습

EC2 실행

간단히 실행

연결해보자

바로 커넥션 오류가 뜬다 .

• Failed to connect to your instance
• EC2 Instance Connect is unable to connect to your instance. Ensure your instance network settings are configured correctly for EC2 Instance Connect. For more information, see Set up EC2 Instance Connect at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-set-up.html.

vpc가 igw 와 연결이 안되어있기 때문

인터넷 게이트웨이 생성

생성후 VPC 에 연결한다.

여전히 EC2 에 연결할 수 없다?

라우팅 테이블 생성

사설 라우트 테이블도 하나 만든다.

서브넷 연결 편집

서브넷을 선택

라우팅 추가하기

IGW 추가하기

이제 ec2 에 연결 가능하다 .

321. Bastion 호스트

배스천 호스트로 사설 서브넷의 ec2에 접속할 수 있다.

• 배스천 → 사설 서브넷의 EC2 에 접속 가능
• 배스천은 공용 서브넷에 존재한다.
• 배스천 호스트의 보안 그룹은 22번 포트로 들어오는 인바운드를 허용한다. 모든 CIDR로 들어오면 위험하기 때문에 제한해야한다.
• EC2의 보안그룹은 서로 허용되어야 한다.

322. Bastion 호스트 실습

이전에 생성한 Ec2 를 BastionHost 라 명명한다.

키페어 생성

pem 키로 생성하자

인스턴스 생성

당연히 키페어 추가하고

보안그룹의 소스를 launch wizard 1 bastion host 로 부터 받는 걸로 하자!

privateinstance 로 명명하고

해당 사설 서브넷은 IGW 와 연결이 안되어있기 때문에 접속 불가

접속 테스트

프라이빗 인스턴스에 접속할려면 해당 키를 배스천 호스트 ec2에 저장하고 접속시에 사용해야한다.

확인 완료

권한 변경 chmod 0400 DemoKepair2.pem

i

10.0.17.176 에 접속 되었다.

0. 들어가며

1월 5일에 클라우드 프랙티셔너를 시험 칠 때 옆자리에 시험장 옆자리에 앉은 분이 SAA-003을 치루는걸 봤다.

묘한 부끄러움? 아 나는 이제 기본 자격증 따는데 가오 떨어지게... (장난이고)

원래 saa를 느슨하게 딸려고 했는데 내가 듣고 싶은 교육프로그램 신청 기간이 한달 반이나 일찍 시작해서 벼락 치기로 saa 준비에 돌입했다. 

CCP는 12/26부터 준비해서 1/5 시험 11일 정도 걸렸다.

SAA 1/6 일부터 1/20일 시험 당일까지 공부했다. 딱 2주정도? 

( 이번에도 벼락 치기에 가까운 준비를 하였으므로 아래 방법으로 준비하는 것은 추천하지 않습니다. 더 더 더 많이 준비하고 치루십쇼)

1. 시험 준비 과정

(1) Udemy 강의

Ultimate AWS Certified Solutions Architect Associate (SAA) | Udemy

해당 강의를 85% 정도 수강했고 공부하는 속도가 느려서 그런지 섹션 28 vpc 파트는 건너 뛰었다. 

27.5시간 강의지만 이것 저것 다루는 내용도 많고 시험 치는 날까지 일정 관리를 제대로 하지 못해 100퍼센트 준비 못한 채로 시험을 치루게 되었다. 

처음엔 블로그에 하나 하나 다 정리하면서 수업을 들었지만 시간이 후에 너무 부족했다. 

(2) 시험 당일 연습 문제 풀기

 시험 치기 몇 시간 전에 강의를 통해서 개념 공부를 완료했고 당일 아침 9시에 기상해서 예제 문제를 풀었다. 

72% 합격인데 49 점을 받고 멘붕이 왔다. 

이정도면 거의 찍으러 가는건데... 

정신을 가다 듬고 시험 치는 그 순간까지 아이패드로 블로그에 정리한 내용을 복습했다. 

2. 시험 과정

(1) 시험 신청

AWS Certified Solutions Architect - Associate 자격증 (amazon.com)

당연히 여기서 신청한다. 

전에 취득한 자격증이 있으면 50 % 디스카운트를 꼭 사용하자

이걸로 지출을 좀 줄인 기분? 

85000원에 시험을 치룰 수 있었다. 

원래는 덤프 문제를 풀고 시험을 칠 계획이라 영어로 신청했는데

이것 때문에 괜히 난이도만 올렸다.

비몽사몽 정신 없는 상태에서 시험 치는데 영어로 해석하고 해석한 거 읽어서 문제를 풀어야하니 

머리가 두배로 아팠다. 

(2) 시험 장소

원래 신청한 곳이 있었는데 시험치기 3일전에 시험 불가라고해서 전날에 장소를 변경했다. (이때 시험 미룰까 생각 엄청했다.)

personvue로 이메일 오는거 잘 체크하자.

(3) 시험 결과

ccp 시험처럼 시험 결과가 바로 나올줄 알았는데 이번에는 바로 안나왔다.

5일안에 이메일 온다고 해서 설마 설마 했는데 5시간 만에 이메일이 왔다.

720점 합격인데 742점.

턱걸이 휴... 다음부터 제대로 준비하자

3. 준비 팁

상당히 주관적이지만 말씀드리자면...

(1) 덤프를 풀 생각이 없다면 차라리 한국어로 신청해라

생각보다 범위가 넒기 때문에 일정 관리에 실패할 수 있다.

나 같은 경우 시험 날짜가 정해지는 등 강한 동기부여가 없으면 게을러지는 타입이라서 시험 날짜를 먼저 정했지만 

너무 오랜 시간 공부하기 싫다면 덤프를 버리고 udemy 강의를 빡세게 보고 한국어로 시험 신청하는게 더 나을 것 같다.

(2) 머신 러닝 같은 서비스 공부

공부하다보면 머신 러닝 서비스처럼 aws 서비스 곁다리 처럼 느껴지는 챕터가 있는데 

이 부분은 시험에 나오면 점수주는 문제니까 무조건 숙지하고 가는 것이 좋다. 

가령 text를 이해하는 aws 서비스는 -> comprehend를 사용 이런식으로 

난이도 쉬운 문제이니 이런데서 점수 까이지 말자

(3) ccp와 비교하여 

ccp 와 비교하여 시험 난이도가 어렵다. 

범위도 넓어지고 기본 서비스 개념을 안다고 가정하고 물어보는 문제들이기 때문에 좀 성가시다. 

그래도 여전히 연결되는 키워드들이 존재한다. 

(4) 중꺽마

saa는 합격 점수가 720점이다. 

72% 를 넘기는건 생각보다 어렵다. 

하지만 aws 시험에는 점수에 포함하지 않는 문제들이 존재한다. (aws 측에서 난이도 조정을 하기 위한 문제)

따라서 시험장에 끝까지 포기하지 않아야 한다. 

(5)  기억에 남는 ...?

kinesis 관련 문제가 많았다. 

나는 잘 모르는 상태로 좀 많이 찍었지만 kinesis,sqs ,sns 관련해서는 제대로 정리하고 가는 것이 유리할 것 같다.

4. 마무리 -? 

사실 시험 칠 때 무척 스트레스가 상당했다. 

시험 문제를 풀어가면 갈수록 사형 선고에 가까워지는 기분이었다. 

지하철을 타고 돌아가는 길은 단두대로 향하는 발걸음 처럼 느껴졌다. 

그래도 다행히 합격해서 설날을 기분 좋게 보낼 수 있었다. 

다음 시험부터는 일정관리를 잘 조율해서 시험 전날은 온전히 복습만 할 수 있게 할 거다.

지금 당장는 cka 쿠버네티스 자격증을 준비하고 있다. ( 시험을 좀 빠듯하게 준비하고 있어서 블로그 작성이 늦춰지고 있다.ㅠㅠ) 

올해 목표는 

cka, aws developer, sysops, solution architecture pro , 미정의 azure 

유의미한 포트폴리오 2개  이다 ! 

힘을 내자 아자아자!