Work

팀장 발령을 받고 처음으로 온전히 보낸 달이다. 3명의 직원이 추가로 입사했다. 첫 단추를 잘 꿰야한다는 생각에 최대한 잘 지내보려고 하는데 완급조절을 잘 하고 있는지는 미지수다.

어디까지 쓴소리를 해야 하는지, 어느 수준까지 칭찬해야 하는지.. 초보 팀장에게는 너무 어려운 일이다.

 

매니지먼트를 전담하게 되며 실무를 뒷전으로 하게 된 점이 아쉽다. 하지만 직책을 부여받음과 동시에 권한도 많아지고 목소리도 커졌기에, 팀과 회사를 위해 기여할 수 있는 부분에 대해서는 확실하게 기여를 하고 싶다.

사용하고 있는 코드를 전부 개편하고 리팩토링하기로 했다. 리팩토링보다는 갈아엎는다는 단어가 더 어울릴 것 같다. 고난이 예상되지만 한편으로는 기대되는 태스크이다.

R&R 구분도 더욱 명확하게 했으니, 각 팀원들이 주도적으로, 진취적으로 해갔으면 하는 맘이다.

 

미팅 빈도가 늘었다. 여러 고객사를 만나며 어떤 모습으로 보였을지는 모르겠지만, 내 생각을 잘 정리해서 전달하는 것도 중요한 소프트 스킬이라는 점을 자주 깨닫는다.

 

Life

 

팀이 안정되며 해야할 일들이 명확해지니 집중도도 올라가서 야근 빈도가 줄었다. 수면이 부족하지도 않고, 개인 시간을 자유롭게 사용할 수 있게 되었다. 미뤄왔던 공부도 하고, 운동도 열심히 하고 있다.

등산도 꾸준히 다니고 있다. 

삶이 루틴화되고 안정화되며 물욕도 사라졌다. 1월 회고에서 언급했던 선택과 집중 덕분인지 아직도 내게 긍정적인 영향을 주는 것 같아 기쁘다. 물욕이 사라지고 지식 욕심과 운동 수행능력에 대한 욕심을 얻은 걸 보면 물욕이 그간 참 컸구나 싶다.

 

내가 뭘 원하고 내게 어떤 것이 필요한지를 모르니 남들을 따라하고 다른 사람 기준에 편승하려했던 순간들이 내게서 보였던 것 같다. 이제라도 나를 잘 알아서 다행이다.

 

공부를 할 때마다 느끼는 점이지만 DB 뿐만아니라 백엔드, 네트워크 등 잘 모르는 분야에 대한 영역도 참 방대한 것 같다. 공부의 끝을 바라지는 않지만 이정도 했으면 괜찮겠다 라고 만족하는 순간이 없다. 공부할 것이 많아 좋으면서도 나 제대로 하고 있나? 라는 의심이 들 때가 많다. 하지만 의심보다는 내가 집중해야할 것에 더욱 집중하는 데 시간을 쏟아야하는 시기임을 잘 알고 있다.

 

'Think' 카테고리의 다른 글

2024년 2월 회고  (1) 2024.02.26
2024년 1월 회고  (0) 2024.02.02
2023년 회고  (0) 2024.01.12
2023년 5월 회고  (0) 2023.05.31
2023년 4월 회고  (0) 2023.05.09

참고도서 : 현대 네트워크 기초 이론

최종 업데이트 : 2024-03-26


 

1.3 이더넷

이더넷 애플리케이션

이더넷은 대표적인 유선 네트워크 기술로, 최대 100Gbps의 높은 속도와 수km까지 지원하도록 발점함에 따라 서버와 대규모 데이터 저장장치에 사용하는 필수적인 기술이 됐다.

 

가정 내 이더넷

  • 이더넷은 아직까지 거의 모든 가정용 네트워크 구성에 포함된다. 특히 전력선 통신 (PLC, Power Line Carrier) 과 이더넷 전원 장치(PoE, Power over Ethernet) 이 확장에 많은 기여를 했는데, 전력선 모뎀은 기존 전원선을 통신 채널로 사용해 전력 신호 위에 이더넷 패킷을 전송한다. PoE는 이더넷 데이터 이블로 전력을 공급한다.

사무실 내 이더넷

  • 일반적인 사무실 환경에서 대부분의 데이터 트래픽은 모바일 장치를 지원하기 위해 와이파이로 전송되지만, 이더넷이 여전히 인기를 유지하는 이유는 고속으로 많은 장치를 지원하며 도청이 어려워 보안 측면에서 우수하기 때문이다. 따라서 와이파이와 이더넷의 조합이 가장 일반적인 아키텍처다.

기업 내 이더넷

  • 이더넷의 큰 장점은 동일한 프로토콜과 서비스 품질, 보안 표준을 유지하며 거리와 속도 측면에서 네트워크 확장이 가능하다는 점인데 10Mbps-100Gbps까지 지원하는 다양한 케이블과 이더넷 하드웨어를 통해 멀리 떨어진 건물 사이에서도 쉽게 네트워크를 확장할 수 있다. 모든 하드웨어와 통신 소프트웨어가 동일한 표준을 따르기 때문에 속도와 제조사가 제각각인 장비를 조합하는 것은 어렵지 않다. 최대 100km 떨어진 이더넷 네트워크에 접속할 때에도 같은 프로토콜을 사용할 수 있다.

데이터 센터 이더넷

  • 대량의 데이터를 처리하기 위해서는 매우 높은 전송 속도가 필요한데, 데이터 센터 네트워크에서도 이더넷이 가장 많이 사용된다. 전통적으로는 인피니밴드(Infiniband)와 광채널 등을 사용했으나 현재 이더넷은 최대 100Gbps까지 지원하기 때문에 기업 네트워크 전체를 이더넷 프로토콜만으로도 구현하는 방법도 많이 사용되고 있다.
  • 일반적으로 먼저 함께 배치된 서버와 스토리지 장치 사이의 네트워크 infrastructure 구축에 고속 이더넷 광케이블과 스위치가 사용된다. 그리고 백플레인 이더넷을 사용하기도 하는데, 구리 케이블을 사용하여 아주 짧은 거리에서 100Gbps까지 전송할 수 있으므로 여러 서버 모듈이 단일 랙에 저장되는 블레이드서버에 적합한 기술이다.

광역 네트워킹 이더넷

  • 이더넷은 T1 전용선, 동기식 디지털 계층(SDH, Synchronous Digital Hierarchy), 비동기 전송 방식(ATM, Asynchronous Transfer Mode) 등 다양한 광역 액세스 기술을 대체하고 있으며 캐리어 이더넷이라고 불리기도 한다.
  • 전통적인 광역 네트워킹 이더넷과 비교했을 때 캐리어 이더넷이 속도 측면에서 훨씬 다양한 선택을 제공하고 이더넷 기술 중에 가장 빠르게 성장하고 있으며, 향후 핵심 기술이 될 것으로 전망된다.

 

기술 표준

IEEE 802 LAN 표준위원회의 802.3 그룹이 이더넷 LAN 표준을 맡고 있다.

 

이더넷 데이터 속도

이더넷 속도를 연대순으로 정리하면 아래와 같다.

 

1Gbps 이더넷

초기의 10Mbps 표준은 사무실 환경에서 사용하기 충분했으나 1990년대 초반 이후 LAN 트래픽이 늘어나자 더 높은 속도가 필요했다. 그 이유는 아래와 같다.

1. 다수의 중앙 집중식 서버에서 대량의 데이터를 읽어올 필요가 많아졌고, 서버 성능이 증가함에 따라 네트워크가 병목이 됐다. 

2. 대용량의 데이터 파일을 교환해야 했다. 소프트웨어 개발과 CAD 애플리케이션이 있다.

3. 기업에서 처리할 작업이 많아짐에 따라 다수의 LAN을 백본 네트워크로 연결한 구조가 등장했다.

 

 

10Gbps 이더넷

1Gbps 표준 규격이 나온지 얼마 지나지 않아 10Gbps 이더뎃이 필요해졌고 인트라넷과 인터넷 트래픽의 증가가 주된 이유였다.

  • 네트워크 연결 개수의 증가
  • 단말 연결 속도의 증가
  • 고품질 동영상 등 많은 대역폭이 필요한 애플리케이션의 증가
  • 웹/애플리케이션 호스팅 트래픽 증가

네트워크 관리자들은 초기에 대용량 스위치들 사이에 고속 로컬 백본을 제공하기 위해 10Gbps 이더넷을 사용했고, 대역폭의 수요가 증가함에 따라 서버팜, 백본, 캠퍼스규모 망 등 전체 네트워크에 설치되기 시작했다. ISP와 네트워크 사업자(NSP, Network Service Provider)는 10Gbps 이더넷 기술로 캐리어급 스위치와 라우터 사이의 초고속 링크를 매우 낮은 비용으로 생성할 수 있다.

캠퍼스 및 인터넷 접속 거점 (PoP, Points of Presence) 등 지리적으로 분산된 LAN 구간을 연결하는 MAN과 WAN 구성에도 사용된다.

 

100Gbps 이더넷

인터넷 연동노드, 고성능 컴퓨팅, 주문형 비디오 (VOD, Video On Demand) 전송을 지원하기 위해 10Gbps보다 높은 데이터 속도가 필요했고 속도가 서로 다른 네트워크와 단말의 요구사항을 고려해 새 표준에서는 두 종류의 속도가 필요했다.

 

촉진 요인

- 데이터 센터/인터넷 미디어 공급자 : 인터넷 미디어 콘텐츠 및 웹 애플리케이션의 성장

- 매트로 비디오/서비스 공급자 : 주문형 비디오는 10Gbps 이더넷/ 코어 네트워크의 개발을 주도하는 주 요인이다.

- 기업 LAN : 음성/비디오/데이터 융합과 통합 커뮤니케이션의 성장 > 하지만 아직까지 대부분의 기업은 1Gbps 혹은 1Gbps+10Gbps의 조합에 의존하고 있다.

- 인터넷 연동 노드 / ISP 코어 라우팅

 

  • 일반적으로 블레이드 서버는 10Gbps 이더넷 스위치를 통해 다른 장비들과 연결되고, 스위치들은 대개 랙에 탑재되어 TOR (Top-Of-Rack) 스위치로 불린다. 이 용어는 실제로 랙 최상단의 위치하지 않아도 서버 액세스 스위치와 같은 의미로 통용되고 있다. 
  • 매우 큰 데이터센터의 경우 수많은 렉을 10Gbps 스위치로 연결하는 것이 점차 어려워지기 때문에 늘어나는 트래픽 부하를 감당하기 위해 랙 간 연결과 NIC를 활용한 외부 연결을 처리할 10Gbps 이상의 스위치가 필요하다.

 

 

25/50Gbps 이더넷

25Gbps 물리 레인을 4개 사용하는 것이나 50Gbps를 2개 사용함으로써 100Gbps를 구현할 수 있다. 구글, MS등 주요 클라우드 사업자의 주도로 25Gbps 이더넷 컨소시엄이 만들어졌고 성능 향상과 NIC-ToR 스위치 간의 Gbps당 연결 비용 절감을 목적으로 하는 이더넷 규격을 지원하기 위한 목적이었다.

이 컨소시엄의 규격은 1레인 25Gbps 이더넷, 2레인 50Gbps 이더넷 링크 프로토콜을 규정함으로써 10Gbps 및 40Gbps 이더넷 링크보다 최대 2.5배의 고성능을 낼 수 있다.

400Gbps 이더넷

대역폭의 수요는 끝없이 늘어나고 있다. 아직 일정은 미정이지만 IEEE 에서는 400Gbps 이더넷 표준을 위해 여러 기술적 옵션을 검토 중이다.

 

2.5/5Gbps 이더넷

이더넷이 높은 데이터 속도에 대한 표준화가 진행된 반면, 낮은 데이터 속도의 표준화에 대해서도 니즈가 있었다. 상대적으로 낮은 속도의 기술은 MGBASE-T 라고 불리며 IEEE와 별도로 표준화를 주관하고 있다.

이 속도는 주로 IEEE 802.11ac 무선 트래픽을 유선 네트워크로 지원하기 위한 목적이다.  1Gbps 이상의 대역폭이 필요한 곳에서 사용되기 시작하는 3.2Gbps 와이파이 표준이다. 1Gbps 이더넷으로 감당할 수 없지만, 10Gbps까지는 필요 없다.

만약 해당 이더넷들이 1Gbps와 동일한 케이블을 사용할 수 있게 된다면 802.11ac 무선 규격을 지원하는 고성능 액세스 포인트에 맞는 속도를 개선하게 된다.

 

 

참고도서 : 현대 네트워크 기초 이론

최종 업데이트 : 2024-03-25


 

1.1 네트워크 생태계

전체 네트워크 생태계의 존재 목적은 최종 사용자(end user)에게 서비스를 제공하기 위한 것이다. 사용자 플랫폼으로는 고정형, 휴대형, 모바일 모두 가능하며 사용자들은 네트워크 기반 서비스/콘텐츠에 네트워크 액세스 장비를 통해 접속한다. 예를 들면 와이파이, 셀룰러 모뎀, 디지털 가입자 회선 모뎀 등이 있으며 이러한 장비들을 통해 인터넷에 직접 연결하거나 공용 네트워크를 통해 네트워크 사업자와 연결한다.

 

애플리케이션 공급자는 사용자 플랫폼에서 실행되는 애플리케이션을 제공한다. 애플리케이션 서비스 공급자는 자신의 플랫폼에서 실행되는 애플리케이션 소프트웨어의 서버 또는 호스트 역할을 제공한다. 소프트웨어의 전통적인 예로는 웹서버, 이메일서버, 데이터베이스 서버 등이 있으며 최근의 예로는 클라우드 컴퓨팅 사업자가 있다.

 

주목할만한 현대 네트워크 기술은 아래와 같다.

  • 데이터 센터 네트워킹 : 대규모 기업 데이터 센터와 클라우드 사업자 데이터센터는 수많은 서버들로 구성되어 있다. 일반적으로 데이터 트래픽의 80%는 내부 네트워크 트래픽이고 20%는 외부 네트워크를 통해 사용자에게 전달된다.
  • IoT 또는 포그 네트워킹 : 기업의 사물 인터넷망은 수천만 개의 장치들로 구성되는데 이러한 장치들이 주고받는 방대한 데이터는 대부분 기계와 기계 사이의 트래픽이다.

 

1.2 네트워크 아키텍처 사례

글로벌 네트워크 아키텍처

중심부에는 IP backbone 혹은 코어 네트워크가 위치하고 있는데, 일반적으로 코어 라우터라고 하는 수많은 광케이블로 연결된 고성능 라우터들로 이뤄진다. 대개 파장 분할 다중화(WDM) 기술을 사용해 각기 다른 광파장 대역을 차지하는 논리적 채널들을 동시에 전송한다.

  • 라우터(router) : 한 네트워크에서 다른 네트워크로 데이터 패킷을 전달하는 네트워크 장치. 네트워크 계층 정보와 라우팅 프로토콜이 만드는 라우팅 테이블에 따라 포워딩이 결정된다. 라우터에서 패킷 포맷은 표준 IP 프로토콜 등 라우팅이 가능한 프로토콜을 따라야 한다.
  • 코어 라우터 (core router)  : 네트워크 주변부가 아닌 중심부에 위치한 라우터로, 인터넷 백본을 구성하는 라우터이다.

그 주변부에는 외부 네트워크와 사용자들로 연결되는 라우터가 있고, 엣지 라우터라고 불린다. 이는 기업 네트워크에서 라우터와 스위치들을 IP 백본이나 고속 WAN (Wide Area Network) 등의 외부 리소스에 연결하기 위해 사용된다. 

  • 엣지 라우터 (edge router) : 네트워크 주변부에 위치한 라우터이다.
    기업 네트워크

대규모 기업 네트워크는 광회선으로 연결된 스위치들이 있는 두 개의 네트워크가 고속의 전용 WAN으로 연결되며, 이와 같은 WAN에서 IP기반의  MPLS가 일반적으로 사용되는 스위치 프로토콜이며, 광역 이더넷도 또다른 옵션이 될 수 있다. 기업 내 장비들은 방화벽을 구현하기 위해 방화벽 기능이 있는 라우터를 통해 IP 백본 또는 인터넷에 연결된다.

 

 

 

작은 기업의 네트워크 구성도는 인터넷에 접속하는 라우터는 케이블, DSL 연결 또는 고속 전용선을 통해 연결된다.

 

 

 

개별 가정 가입자의 경우 대표적으로 전화선을 통한 고속 연결을 제공하는 DSL 모뎀과 케이블 연결, 기타 무선 연결 등이 있다. 각 경우마다 신호 인코딩, 오류제어, 가입자 네트워크 내부 구조 등 여러가지 이슈가 있다.

 

스마트폰과 태블릿 등의 모바일 장치는 셀룰러 네트워크를 통해 인터넷에 연결하는데, 셀룰러 네트워크는 광회선과 같은 고속 연결로 인터넷에 연결된다.

 

 

일반 네트워크 계층 구조

 

일반적으로 네트워크 설비는 대개 액세스-분배-코어 3계층 구조로 설계된다.

최종 사용자와 가장 가까운 것은 액세스 네트워크이다. 일반적으로 로컬 영역 네트워크 (LAN) 또는 캠퍼스 규모의 네트워크이며 LAN 스위치와 대규모 LAN에서 스위치 간 연결을 제공하는 IP라우터로 구성된다. L3 스위치도 LAN에서 흔히 사용된다. 데스크톱, 노트북, 모바일 장치 등의 장비가 연결될 수 있다.

 

로컬의 장비들은 액세스 라우터를 통해 분배 네트워크로 연결되고 액세스 네트워크의 트래픽을 주고받으며 엣지 라우터 처럼 동작한다. 대규모 로컬 설비에서는 내부 라우팅 기능만을 지원하는 추가 액세스 라우터가 있는 경우도 있다. 분배 네트워크의 엣지 라우터액세스 네트워크에지 라우터와 연결되는데, 이들은 라우팅과 연결정보 및 트래픽 정보를 교환한다. 이처럼 라우터끼리 협력하는 절차를 피어링 (peering) 이라고 한다. 또한 코어 네트워크로 향하는 트래픽을 집선해 코어 네트워크의 과도한 피어링을 방지함으로써 라우터의 수가 제한되고 메모리, CPU, 전송용량을 절약하는 효과가 있다.

 

코어 네트워크는 백본 네트워크라고도 불리며 지리적으로 분산된 분배 네트워크를 연결하고 기업 네트워크 범위 밖의 외부 네트워크로 액세스를 제공한다. 일반적으로 초고성능 라우터, 대용량 전송회선, 중복성과 용량을 위해 클러스터링된 다수의 라우터를 사용하며 대규모 데이터베이스 서버나 사설 클라우드 장비와 같은 대용량 서버 시스템에 접속할 수 있도록 설계되어 있다.

 

네트워크 계층 구조는 모듈화 설계의 한 가지 좋은 예로, 각 계층의 요구 사항에 따라 네트워크 장비의 용량, 특성, 기능이 최적화되도록 설계된다.

 

 

 

Work

팀장이 공석이라 팀장 대행 업무를 하며 업무를 파악하고, 타팀 협업회의에 참석하며 업무를 분담했다. 면접에도 몇번 참석하고 본부 지시사항도 팀원들에게 전달하였다.

2월 중순 정식으로 발령을 받고 팀장이 되었다. 팀장 발령을 기다렸다는 듯이 업무 이관과 협업요청이 물 밀듯이 들어왔다.

아직은 실무가 좋은데 팀장을 해도 되는걸까? 나는 팀장으로서의 자질이 있는걸까? 팀장이라고 할 만큼의 지식을 가지고 있을까? 질문을 스스로에게 던졌을때 전부 아니라는 대답이 나왔다.

연차가 높지도 않고, 역량이 풍부하지도 않다고 생각하지만 그래도 나를 좋게 봐주시는 면이 감사함과 동시에 퍼포먼스가 좋지 않으면 어쩌지하는 걱정과, 이왕 맡은만큼 책임감 있게 해보려는 마음이 공존한다.

나의 직장생활 경험 속에서 팀원으로서 느꼈던 팀장의 모습이 오버랩된다.

 

동료 직원의 불성실한 태도에 입사 후 2개월동안 힘들었다. 업무 공유를 하며 피드백을 전달했고, 동료로서 개선되었으면 하는 점과 함께 개선 여부에 대한 피어 평가를 인사팀에 전달했다. 결국 그 직원은 수습 종료 후 정규직 전환이 되지 않았다.

앓던 이가 빠진 느낌이다. 치아가 빠짐과 동시에 치아가 있던 빈 자리가 커보이고, 그 자리를 혀로 매만져보기도 하면서도 치아때문에 아팠던 기억도 떠오른다. 하지만 빠진 이는 다시 새로운 이로 채워질 것이고, 새로운 치아와 다시 열을 맞춰봐야지.

 

우선순위를 정하는 것은 어렵지 않다. 하지만, 모든 것을 파악하지 못한 상태에서 우선순위를 정하는 것은 어렵다. 익숙해지고 완전히 파악하는 데 시간이 필요할 것이다. 그래도 많이 배우겠지.

 

 

Life

스쿼트 PR(Personal Record)을 갱신했다. 이제 세자리수에서 놀 수 있게 되었다.

보조 파트너가 있어야만 들을 수 있던 무게를 혼자 들 수 있게 되었다. 거창하게 시도하지도 않았다. 평소 하던대로 하다가 오늘은 왠지 컨디션이 좋을 것 같다는 기분과 자신감에 시도했는데, 생각보다 사뿐하게 들려 쉽게 성공했다.

성공의 기쁨도 잠시, 110kg를 도전했는데 깔려버렸다. 그래도 문을 두드렸다는 의미에서 크게 만족했다.

다시 탑세트를 통해 체중 대비 2배까지 드는 것을 목표로 연습해야지.

 

 

여러모로 의미있는 2024년의 2월이다.

'Think' 카테고리의 다른 글

2024년 3월 회고  (0) 2024.03.27
2024년 1월 회고  (0) 2024.02.02
2023년 회고  (0) 2024.01.12
2023년 5월 회고  (0) 2023.05.31
2023년 4월 회고  (0) 2023.05.09

2024년의 첫 해이자, 새로운 직장에서 시작하는 첫번째 달이다.

2023년은 얼레벌레 지나왔지만 2024년은 작년보다 훨씬 주도적으로 지내고 싶었다.

Work

 

업무 시작전, 업무 도중 기록을 많이 하기 시작했다. 그동안은 노션에 기록했지만 노션과는 별개로, 손으로 많은 기록을 했다.

손으로 기록하는 것의 장점은 전달력과 흡수력인 것 같다.

 

데이터 분석 업무를 하며 다뤘던 데이터들과 차원이 다른, raw data를 많이 볼 수 있었다. 데이터 자체보다는 DB를 다뤘다는 말이 더 맞을 것 같다. 그동안은 비교적 소규모의 회사에만 있다 보니 엔지니어링 업무보다는 당장 급한 업무를 우선적으로 처리할 수밖에 없었는데, 지금은 비교적 큰 규모의 회사라 그런지 DB를 관리하는 측면에서 배울 수 있어 좋았다.

개념적인 이해보다는 실제로 서버와 DB에 붙어서 핸즈온으로 보며 배운 점이 많았다.

너무나 날 것의 데이터가 쉴 새 없이 저장되고 있어서 해당 DB를 마이그레이션 하는 업무도 곧 담당할 것 같다.

조직의 비즈니스 방향성이 빠르게 바뀌다보니 업무의 방향성을 잡는 것이 힘들었다. 갈피를 잡는 것이 여전히 어렵다.

Health

급성 허리디스크를 경험한 이후로, 무게에 대한 욕심과 파워리프팅식 운동 방법을 버렸다.

일장일단(一長一短), 장점이 있으면 단점이 있기도 마련이라 했던가.

무게에만 집착을 해오다보니 그로 인한 부작용은 눈에 보이지 않았다. 특정 부위를 수축운동으로 강화함으로써 상대적으로 해당 근육이 단축되거나, 무게를 들기 위해 다른 근육의 힘을 끌어다 쓰다보니 해당 부위에 피로가 쌓인 상태로 더욱 악화된다는 사실을 몰랐다.

이제는 다시 원점으로 돌아가서 운동을 처음 한다는 생각으로 역학적인 움직임과, 힘의 작동 방향, 근육의 결/ 힘의 전달력 등 기초부터 차근차근 배우며 시작하고 있다. 보디빌딩식 운동을 하니 전보다 훨씬 건강해지고 이론을 알게 되니 운동도 쉬워졌다. 재미있다.

운동 횟수도 줄였다. 무게에 대한 욕심을 내려두니 나도 모르게 가지고 있던 주5-6회는 해야 한다는 강박도 내려두게 되었다. 주3-4회정도로 타협하고 강도를 올렸다.

 

지리산 천왕봉을 다녀왔다. 아주 어릴 때 갔던 청학동에서의 기억이 어렴풋이 남아 크게 걱정하지 않았는데, 생각보다 힘들었고 생각보다 즐거웠다.

Life

운동을 시작하고 술을 멀리하게 되며 자연스레 약속을 전무하다시피 했는데, 그런 생활 습관 속에서 운동 횟수를 줄이니 누군가를 만날 여유와 공부할 여유, 나만을 위한 시간이 생겼다. 

사람을 원채 좋아하는 나였지만 그것과 별개로 소통을 하지 않으면 쓸모가 없다는 걸 느꼈다. 약속이 많아지고 오랜만에 많은 사람들과 소통을 하니 내가 그동안 나의 목소리를 내는 데만 집중하지 않았나 하는 생각이 든다. 잘 듣는 것도 소통이다.

 

배움에 대한 욕심이 너무 커서 여러가지를 잡고 놓지 못하고 있었는데, 당장 집중할 것만 두고 정리했다. 요즘은 하둡과 스파크를 공부하고 있다. 왜 진작 DB를 공부하지 않았을까 하는 생각이 든다.

공부에 대한 선택과 집중을 하다보니 자연스레 버리지 못하고 보관하고 있는 물건들도 습관적으로 정리하게 됐다. 모르는 미래에 대한 기대감보다는 조금 더 현실을 살게된 것 같은 기분이 둔다.

 

대학교를 등록했다. 잘 할 수 있을거라 믿는다. 

'Think' 카테고리의 다른 글

2024년 3월 회고  (0) 2024.03.27
2024년 2월 회고  (1) 2024.02.26
2023년 회고  (0) 2024.01.12
2023년 5월 회고  (0) 2023.05.31
2023년 4월 회고  (0) 2023.05.09

해당 포스팅은 오레일리의 책, 클라우드 아키텍트 트랜스포메이션을 보며 정리한 내용입니다.

최종 업데이트 : 2024-01-12


 

클라우드 네이티브는 단순한 도구 모음 이상의 의미가 있다. 완벽한 아키텍처로, 컴퓨팅을 최대한 활용하는 클라우드 애플리케이션을 구축하기 위한 철학적인 접근 방식이다.

 

 

" 클라우드 네이티브"는 " 클라우드 " 가 아니다.

클라우드 컴퓨팅을 단순히 "클라우드"라 하면 인터넷을 통해 인프라스트럭처를 주문형 방식으로 제공하는 것을 의미한다. AWS, GCP, Azure 등의 클라우드 서비스 플랫폼에서 제공하는 경우가 많으므로 실제로 소비하는 자원에 대해서만 요금을 지불할 수 있다.

 

클라우드 네이티브는 위의 모든 클라우드 기반 구성요소를 클라우드 환경에 최적화된 방식으로 조립하기 위한 아키텍처이다. 서버가 아닌 서비스에 대한 것이며, 기업의 목표는 사례에 적합한 클라우드 기술을 효율적으로 선택하는 데 있다.

클라우드 네이티브 마이그레이션 목적에 도달하기 위한 경로는 수없이 많고, 조직의 요구에 따라 다양한 방법이 있기 때문에 방향을 잃어버리기 쉽다. 이를 위해서는 전체 구현 및 배포 전에 설계를 이해하고 우선순위를 정해야 한다.

 

클라우드 네이티브 패턴 언어를 개발하는 것은 유용하고 재사용 가능한 로드맵을 작성하는 다음 단계이다. 개발자가 best practice를 논의하고 학습,적용할 수 있도록 공통 context를 식별하고 협의하기 위한 언어가 필수적이다.

 

 

클라우드 네이티브 개요

클라우드 네이티브 컴퓨팅이란, 오픈소스 소프트웨어 스택을 사용해 애플리케이션을 마이크로서비스로 배포, 각 부분을 자체 컨테이너에 패키징, 컨테이너를 동적으로 조정해 리소스 활용도를 최적화하는 것이다.
-CNCF(Cloud Native Computin Foundation)-

 

기본적으로 클라우드 네이티브는 특정한 접근 방식의 이름이며, 아키텍처는 CI를 할 때 IaaS에 의존한다. 일반적인 목표는 속도 향상이며, 이를 통해 새로운 아이디어를 몇 시간 내 운영 환경에 투입할 수 있다. 실제로 클라우드 네이티브로 마이그레이션하는 대부분의 기업은 속도를 주요 이동 요인으로 꼽는다.

 

클라우드 네이티브를 어떻게 알 수 있을까?

클라우드 네이티브의 기본 원칙을 컨테이너 패키징, 동적 관리 및 모듈식 분산 아키텍처라 하는 경우가 많지만 실제로는 다섯가지의 아키텍처 원칙과 두가지 문화적 원칙이다.

 

<아키텍처 원칙>

  • 컨테이너화 : 애플리케이션과 종속성/운영 환경을 함께 캡슐화해 단일 패키지로 구성할 수 있다. 테스트, 이동/배포가 쉬워진다.
  • 동적 관리 : 온디맨드 방식으로 유연하게 프로비저닝할 수 있는 서비스를 사용한다. 일반적인 public cloud에서는 사용한 리소스에 대해서만 비용을 지불한다.
  • 마이크로서비스 : 애플리케이션을 분리된 소규모 구성 요소 서비스의 집합으로 서비스한다. 각 마이크로서비스는 다른 서비스와 독립적으로 작동하며 최종 사용자에게 영향을 미치지 않는다. 마이크로서비스는 팀이 동시에 개발하면서 독립적으로도 개발할 수 있도록 해 개발 속도를 높이는 데 도움을 준다.
  • 자동화 : 유지보수 및 업데이트와 같은 수동 작업을 스크립트나 코드로 교체해 원활하고 안정적으로 수행할 수 있다.
  • 오케스트레이션 : 컨테이너형 애플리케이션의 배포, 확장 및 관리를 자동화해 모든 것을 하나로 묶는다. 특히, 쿠버네티스 또는 오케스트레이션 도구를 사용하여 인프라 전반에서 컨테이너의 로드 밸런싱, 스케일 업다운 등의 작업을 제어 및 자동화한다.

<문화적 원칙>

  • 위임 (Delegation) : 개인이 안전하게 변경하도록 필요한 도구, 교육 및 재량권을 제공하고 되도록 자율적으로 배포 및 모니터링하게 한다.
  • 동적 전략 : 팀에게 전략을 전달하지만 결과에 따라 전략을 수정할 수 있다. 이것이 클라우드 네이티브가 제공하는 빠르고 실험적인 배포의 궁극적인 목적이다.

 

궁극적으로 클라우드 네이티브는 어디에서가 아니라 어떻게 생성하고 제공하느냐에 대한 것이다. 클라우드 네이티브의 목적은 실용적인 접근이다. CD처럼 빠르고 현대적인 소프트웨어 방식과 연동하여 시간을 단축하고, 쉽게 확장하며 효율적으로 운영하기 위함이다. 또한 클라우드 네이티브 아키텍처를 통해 복잡한 시스템을 독립적 팀이 구축한 소규모 구성 요소로 나눌 수 있다. 기존의 모놀리식 애플리케이션의 복잡성과는 다르다.

가장 중요한 점은 클라우드 네이티브가 위험을 줄이는 데 도움이 된다는 것이다. 빠르지만 작고, 변경이 잘못될 경우 폭발 반경을 제한하고, 변경사항을 즉시 롤백하는 방식이다.

 

서비스에 대한 모든 것

퍼블릭 클라우드 기반 서비스가 제공하는 서비스 유형이다.

  • IaaS (Infrastructure as a Service) : 외부 하드웨어, 데이터 스토리저 및 네트워킹을 포함한다. 인프라를 소유하며, 임대하면 중앙 아키텍처팀의 기능으로 한정되지 않아 각 팀의 창의성을 극대화할 수 있다.
  • PaaS (Platform as a Service) : 모든 가상화된 인프라를 관리하고 유지해 운영 및 플랫폼 팀의 부하를 크게 줄일 수 있다.
  • SaaS (Software as a Service) : 기존 비즈니스 소프트웨어에서 가상 인프라 관리 도구에 이르기까지 모든 구성 요소 애플리케이션을 선택할 수 있다. 이 모든 애플리케이션은 웹을 통해 제공/운영되며, 프로바이더는 보안, 가용성, 성능을 보장한다.
  • CaaS (Container as a Service) : 컨테이너 엔진, 오케스트레이션 및 모든 기본 컴퓨팅 리소스를 클라우드 프로바이더의 서비스로 사용자에게 제공할 수 있다.
  • As a Service : 위에 언급된 서비스 외에도 많은 서비스들이 생겨나고 있으며, 조금씩 발전하고 있다.

 

클라우드 네이티브 원칙의 이해

앞서 이야기한 클라우드 네이티브의 다섯가지 원칙에 대해 이야기해보려 한다.

컨테이너화

서비스 기반 아키텍처를 정의한 후에는 모든 곳, 모든 사람을 위해 컨테이너화해야 합리적이다 컨테이너는 응용 프로그램을 실행하는 데 필요한 모든 것을 포함하는 경량의 독립 실행형 소프트웨어 패키지다. 모든 의존성을 가지고 코드를 패키징해 어느 컴퓨팅 환경에서든 실행할 수 있다.

이런 가상 시스템은 애플리케이션과 애플리케이션을 자체 운영 체제에 이르기까지 어느 플랫폼에서든 실행할 수 있는 독립형 유닛으로 격리시킨다. 전 세계적으로 동일한 컨테이너를 IaaS를 통해 호스팅하고 배포할 수 있으므로 운영이 유연하고 안정적이며 빠르다.

동적 관리

컴퓨팅, 네트워크 및 스토리지 리소스는 사전 비용 없이 표준화된 API를 사용해 온디맨드 방식으로 프로비저닝되며, 실제 비즈니스 요구에 실시간으로 대응할 수 있다. 컴퓨팅, 네트워크 및 스토리티 리소스 운영은 전문 기술이 필요한 어려운 작업이기에 기술 습득은 시간이 많이 걸리고 비용이 많이 든다. 하지만 속도가 더 중요하기에 클라우드 플랫폼을 통해 고가용성, 안정성 및 보안 표준에 따른 리소스 수명 주기가 자동으로 관리되는 것을 기대할 수 있다.

마이크로서비스

마이크로서비스 아키텍처는 대규모 애플리케이션이 모듈식 구성 요소 또는 서비스 제품군으로 구축되는 애플리케이션 개발에 대한 접근 방식이다. 각 서비스는 고유 프로세스를 실행하고 자체 데이터베이스를 관리한다. 마이크로서비스는 API를 통해 통신하며 각 서비스를 독립적으로 분리,재구성,재배포 및 관리할 수 있다.

또한 소프트웨어를 구축하기 위해 비계층적 기능적 접근 방식을 취하여 모놀리식 엔티티를 더 작은 개별 조각으로 분할하고 프로세스를 독립적으로 제공할 수 있다.

각 마이크로서비스는 특정 목적에 가장 적합한 언어로 작성될 수 있으며, 필요에 따라 독립적으로 scale-up 또는 scale-down할 수 있다. 그리고 모놀리식 애플리케이션과 달리, 블래스트 래디우스(the blast radius) 는 마이크로서비스의 기록에 포함된다.

- 블래스트 래디우스 : 스케일업과 스케일다운이 발생한은 최대/최소 범위

자동화

스크립트 또는 코드에서의 수동작업은 자동화된 단계로 대체된다. 그 예로 테스트 프레임워크, 구성 관리, CI/CD 도구 등이 있다. 자동화는 반복적인 작업과 운영 통합 절차를 통해 휴먼에러를 제한하고 시스템 신뢰성을 향상시킨다. 그로 인해 인간은 유지보수 작업 대신 비즈니스에 집중할 수 있게 됐다.

클라우드 네이티브를 적용할 때 자동화를 하지 않으면 혼란에 빠지기 쉽다. 클라우드 마이그레이션 이후 기업은 더욱 빠르게, 자주 배포하게 되는데 배포 프로세스를 완전히 자동화하지 않으면 온프레미스 서버를 운영하지 않아 새롭고 빠른 운영주기로 배포하는 데 시간을 사용할 수 있다. 배포 빈도가 높을수록 실수할 가능성도 높다. 

배포 자동화는 지속적인 CI/CD를 단순하게 만들고, 자동화된 테스트를 통해 이슈가 되기 전에 문제를 조기 발견할 수 있다.

오케스트레이션

MSA(MicroService Architecture) 구축 이후 컨테이너화를 마친 후에 각 컨테이너들을 조율해야 한다. 엔터프라이즈 레벨 애프리케이션은 여러 컨테이너에 걸쳐있으며, 이러한 컨테이너는 여러 서비스를 포함해 포괄적인 컨테이너 인프라를 구성하는 여러 서버 호스트에 구축해야 한다.

오케스트레이션은 아키텍처를 계획할 때 공통 패턴을 사용할 수 있도록 지원하므로 엔지니어링 노력이 줄어든다. 개발자는 낮은 수준의 추상화를 해결하는 데 자유로워지고 아키텍처에 집중할 수 있다.

쿠버네티스가 이러한 것을 담당하며 cloud native migration에서 마지막으로 수행되는 중요한 일이다. 오케스트레이터를 먼저 구현하면 어렵다. 따라서 클라우드 인프라, 동적관리, 자동화 등의 다른 클라우드 네이티브 원칙을 먼저 수립해야 한다.

 

모든 것을 함께 조정하라

 

 

다섯가지 원칙 모두 필수적이지만 마이크로서비스는 그 중 제일 중요하다

마이크로서비스는 중심적인 역할을 한다. 컨테이너, 동적관리, 자동화, 오케스트레이션은 MSA와 결합해야만 진정한 힘을 발휘한다.

마이크로서비스가 클라우드 네이티브 원칙의 중심인 이유는 마이크로서비스가 모든 기업의 차별화 요소인 비즈니스 로직을 캡슐화한다는 점이고, 기업은 이를 통해 고객에게 가치를 제공하는 프로세스를 나타낼 수 있다.

 

무엇이 잘못될 수 있을까?

누구나 퍼블릭 클라우드 서비스에 회원가입을 한 다음 AWS, GCP, Azure 등의 서비스를 사용할 수 있다는 것은 놀라운 일이다. 경쟁은 점점 더 치열해지고, 가격은 떨어지고, 기능들은 늘어나고 있다.

하지만 그 대신 문제점 또한 쉽게 발생할 수 있는데 크게 아래와 같다.

  • 분산 시스템이 복잡해서 어렵다.
  • 방대한 도구 및 플랫폼으로 구성된 클라우드 네이티브 에코 시스템이 상대적으로 미성숙하다.
  • 변화하는 기술과 전달되는 기대치에 맞춰 조직 문화를 발전시키지 못했다.

 

 

분산 시스템의 충격

사용자는 빠르게 심리스하며 상시 접속 가능한 환경을 원한다. 이러한 기대를 충족시키고자 클라우드 네이티브의 많은 기능들은 발전해왔다. 분산 시스템에 대해 생각할 수 있는 방법은 여러 독립적 기능을 함께 사용하여 최종 사용자에게 단일 통합 환경으로 제공하는 것이다.

분산 시스템의 주요 이점은 신뢰성이다. 컴퓨팅 프로세스가 전체 시스템 네트워크에 분산되어 있을 때 서로 독립적으로 발생한다.

배포를 통해 필요에 따라 노드와 기능을 쉽게 추가할 수 있어 시스템의 확장성이 크게 향상된다.

그러나 이 모든 이점은 복잡성을 수반한다. 시스템이 복잡해지면 설계, 구축, 디버깅이 어려워지고 장애는 필수적이다. 이러한 장애를 이해하기 위해 정교한 관측성이 필수적이다.

 

미성숙함으로 인한 충격

퍼블릭 클라우드 플랫폼은 솔루션으로 제공되지만 플러그 앤 플레이와는 거리가 멀다. 전체 솔루션이라고 주장하지만 정말 모든 기능이 있지는 않다.

클라우드 네이티브는 계속 발전하므로 서비스 환경도 계속 발전하고 있다.

요약

클라우드에서 최선의 결과를 얻으려면 마이크로서비스, 컨테이너, 오케스트레이션, 자동화 등의 클라우드 네이티브 아키텍처를 사용해야 한다. 자동화는 가장 먼저 시행되어야 한다.

마이크로서비스와 클라우드 서비스는 그를 위한 핵심 요소이다. 

클라우드 네이티브는 강력하고 전도유망한 기술이다. 이 이점을 활용하려면 클라우드 네이티브 아키텍처의 원리를 기반으로 견고한 기반을 구축해야 한다.

 

매달 말이 되면 회고를 써야겠다고 다짐을 하지만, 그 상태로 어느 새 2주가 넘겨버리고 금세 다음 달이 다가와서 못 썼던 적이 많다. 하지만 연말 회고는 꼭 써야겠다는 생각에 부랴부랴 회고를 작성해보려 한다. 

누군가가 2023년에 뭐했어? 라고 물어보면 단번에 쉽게 답변할 수는 없지만, 그래도 이거 하나만은 확실하다.

많은 도전과, 많은 실패를 했다. 또, 전보다 많이 (심리적으로) 안정되고 여유있고 행복했던 한 해였다.

 

 

 

기록과 회고

 

 

여전히 기록하는 습관은 내게 노력이 필요하지만, 결국 기록 없이는 모든 것을 기억할 수 없기에 최대한 많이 기록하려했다. 주간회고는 거의 매주, 월간회고도 틈틈히 하려고 노력했다.

귀찮은 회고를 왜 하는지 시작하기 전에는 이해가 잘 가지 않았지만, 꾸준히 묵묵히 하다보니 회고의 순기능이 보이고 이제는 회고 없이는 보낼 수 없게 되었다.

회고 최고!

 

 

Work

돌이켜보니 2023년은.. 사주에 대해서는 잘 모르지만 역마살(?)이 있던 것 같다.

2023년 초, 2022년 말부터 직장내 괴롭힘으로 힘들어하던 회사에서 퇴사 권유를 받아 퇴사를 하였다. 1년이라는 연구원 생활동안 느꼈던 부족했던 점을 배울 기회가 생겼다고 좋아했는데, 운이 좋게 바로 다음 회사에 합격하여 두 번째 회사에 입사를 하게 되었다.

 

이 두 번째 회사에 머물렀던 시기가 2023년동안 가장 많이 공부하고, 배우고, 성장했던 시기라고 단연코 말할 수 있다. 3개월이라는 짧은 시간이었지만 모든 면에 있어 겸손해질 수 있었던 회사였다. 온프레미스 서버부터, GCP, AWS, MLOps 파이프라인 구축, docker, kubernetes 활용한 배포, 실시간 데이터를 활용한 연구과제, 백엔드 API 모듈 개발 , 예측 모델 개선 등... 적어보니 참 많은 업무를 딥하게 할 수 있는 기회가 많아 좋았다.

흔히 말하는 워라밸이 없을 정도로 열심히 일했지만, 지식의 공백을 채우기는 어려웠고, 정규직 전환이 되지 않았다

사실 머릿속으로는 업무를 하면서 스스로의 부족함을 알고 있었음에도 불구하고, 정규직 전환 실패는 나 자신에게 굉장히 큰 충격을 안겨 주었다. 어찌보면 정규직 전환 실패가 나를 더욱 성장하게 한 것 같다. 

 

이후 명확하게 공부의 필요성을 느꼈고 취업을 하지 않은 상태로 공부와 운동을 하며 쉬었다. 

그 후 지인의 회사에서 감사하게도 제안을 주셔서 세 번째 회사에 입사를 하게 되었다. 그동안 해왔던 데이터 관련 업무보다는 웹과 백엔드, 앱 위주의 업무를 담당하게 되었다. 시작하기 전에는 쉽게 할 수 있을거라 생각했는데 생각보다 고려해야 할 부분들이 많고 또 여전히 공부해야 할 것이 많다는 것을 느꼈다. 그 중에 가장 힘들었던 점은 상사나 동료가 없이 혼자서 모든 개발 전반적인 부분을 담당해야 하는 점이었다. 동료, 혹은 선배라는 누군가의 존재가 이토록 절실했던 적은 없었다. 두어달 근무를 하고, 현실적으로 부딪히는 문제점들이 많고 이를 당장 혼자서 해결할 수 없다는 사실과 개발 속도 지연으로 인한 배포 지연에 대한 부담감으로 퇴사를 결심했다. 

 

2023년 말, 세 회사를 겪고 나서 난 아직 아무것도 모르는 사람이라는 생각에 자괴감이 들었다. 그동안 나름 회사생활에서도, 그 외적으로도 열심히 지식을 습득하고 체화했다고 생각했는데 일말의 도움도 되지 않는 사람이 된 것 같아서 괴로웠다. 

하지만 덕분에 내가 하고 싶은 것, 내가 잘하는 것, 관심이 있는 것을 적어보고 앞으로 내가 어떤 방향으로 성장하고 싶은지에 대해 진지하게 생각해보는 시간이 됐다. 이 시간을 보낸 후 2023년 12월 말, 크리스마스를 앞둔 시점에 네번째 회사에 입사를 하게 되었다.

살면서 겪어본 모든 회사 중 가장 큰 규모의 회사였다. 이미 기술적으로 큰 성공을 거뒀고, 다양한 고객사들을 만나 여러 도메인을 쌓을 수 있다는 점도 내게 큰 장점으로 다가왔다. 그리고 앞선 세 회사에서 느꼈던 '엔지니어링 기술의 부족'을 배울 수 있는 포지션이라 더욱 기대가 된다.

 

Life

 

직장을 여러번 옮기며 생활 방식도 많이 바꿔야했다. 만나는 사람도 번번히 바뀌니 상대를 알아가는 과정과 내가 누구인지 보여주는 시간이 필요했다. 스터디를 해도 마찬가지였다.

사람 만나는 것을 좋아한다고 생각했음에도 불구하고, 내가 선택할 수 없는 만남이 계속되는 것이 지치고 힘들었다.

평소의 나라면 네트워킹도 많이 하고 오프라인 스터디에도 자주 나갔을텐데, 업무적으로 만나는 인간관계에 지치다 보니 업무 외적인 시간에는 기존에 유지하던 인간관계를 더욱 자주 만났다. 인간 관계가 깊어진 것 같아서 오히려 좋았다.

 

이사를 했다. 청소년기를 보냈던 어릴 때의 동네로 다시 돌아가게 되었다. 자취생활을 접고 가족들과 살게 된지 어언 1년이 되었다. 함께 하는 삶과 공동체 생활을 하며 배려심을 배우게 되었다.

 

Health

 

2023년 가장 잘 한 것은 운동만은 절대 놓지 않았던 것이다.

물론 두 번째 회사를 다니는 동안은 거의 운동을 쉬다시피 했다. 그래도 운동까지 놓아버리면 스트레스를 해소할 수 없었기에, 아무리 바빠도 최소 주1회는 꼭 헬스장을 가거나 등산, 수영을 했다.

 

연초에는 리프팅 방식의 운동을 많이 했고, 무게에 욕심을 내다가 다치기도 했다. 하지만 결국 리프팅을 잘하기 위해서는 관절이나 근육의 역학적인 움직임이나 힘의 작용 방향에 대한 이해가 선행되어야 한다는 점을 뒤늦게 깨달았다. 

 

근력운동을 시작한지 거의 1년이 되어가는데 1rm 280kg을 찍어서 뿌듯했다. 또, 같은 운동을 좋아하는 친구들을 많이 만들었다.

 


 

 

 

잘한 점

- 내가 선택할 수 없는 것을 제외하고는, 많은 부분을 주도적으로 결정하였다.

- 실행력의 중요성을 여전히 느끼며, 많은 실패를 거듭했다.

- 절제력을 놓지 않고 적당히 나 자신과 밀당하며 더욱 나를 잘 알게 되었다.

 

 

아쉬운 점

- 업무를 할 때마다, 기술적으로 부족한 점을 많이 느끼고 한계에 부딪혔다. 공부할 것이 많아 오히려 기쁘다.

- 독일어와 영어를 듀오링고 제외하고는 소홀했다. 올해부터는 조금 더 적극적으로 꾸준히 해봐야겠다.

- 한 가지 일에 몰두한다거나, 우선순위를 정하는 것이 여전히 부족하다.

 

 

 

결국 모든 경험들은 내 자신에게 도움이 된다고 생각하기에, 세상을 지나치게 부정적으로 바라볼 필요는 없다. 다만 나 자신을 더 잘 알고 휴식할 때와 집중할 때를 적절히 알고 실행하는 것이 더 중요하다.

올해는 '성장'이라는 포괄적인 단어보다는 나를, 그리고 기술을 더 잘 알기를 바란다. 그러기 위해서는 내가 무엇을 모르고 무엇을 아는지 '인지'하는 것부터 시작해야 한다. '인지'하고 더 나아가 '배움'으로 이끌 수 있는 한 해를 기대한다.

'Think' 카테고리의 다른 글

2024년 2월 회고  (1) 2024.02.26
2024년 1월 회고  (0) 2024.02.02
2023년 5월 회고  (0) 2023.05.31
2023년 4월 회고  (0) 2023.05.09
2022년 9월 회고  (1) 2022.10.04

127.0.0.1과 localhost는 기본적으로 동일한 것을 가리키는데, 이들은 모두 로컬호스트를 나타낸다.

그러나 사용 목적에 따라 약간의 차이가 있을 수 있다.

 

좌측은 웹페이지에서 Localhost 접속 사진, 우측은 127.0.0.1 접속 사진이다.

 

 

127.0.0.1

- 127.0.0.1은 IPv4 주소 중 하나로, 로컬 루프백 (Loopback) 주소이며 네트워크에서 현재 시스템을 가리킨다. 

   - 여기서 IPv4는 Internet Protocol version 4의 약어로 32비트로 구성되어 있어, 일반적으로 4개의 8비트로 표현된다. (127.0.0.1)

- 이 주소는 TCP/IP 네트워크 스택에서 자체 테스트 및 통신을 위해 예약되어 있다. 즉, 네트워크 스택이 자체적으로 통신을 테스트하기 위해 예약된 주소로, 데이터를 보내면 해당 데이터가 동일한 시스템으로 다시 돌아오게 된다.

- 주로 개발 및 테스트의 목적으로 사용되며, 직접 IP 주소를 사용하는 경우에는 주로 이를 사용한다. 시스템이 네트워크에 연결되어 있더라도 로컬에서 독립적으로 동작하는 응용프로그램을 테스트할 때 사용된다.

- 요약하자면, 127.0.0.1은 자기 자신을 가리키는 특수한 IP 주소로 웹서버, 데이터베이스, 응용 프로그램 등을 테스트하고 디버깅하는 데 사용된다.

 

localhost

- localhost는 호스트 이름이며, 일반적으로 시스템의 로컬 루프백주소인 127.0.0.1 IP 주소를 가리킨다.

- 호스트 이름을 사용할 때, DNS 조회를 통해 127.0.0.1 주소로 매핑된다.

- localhost는 주로 IP 주소를 직접 기억할 필요 없이 읽기 쉽고 기억하기 쉬운 형태로 로컬 시스템을 가리킬 때 사용된다.

- 예를 들어 웹 개발중에 로컬 웹 서버를 구동하고 웹 브라우저에서 http://localhost:8080 과 같은 주소로 접속할 수 있다.

 

 

결론

실제로 대부분의 경우에 이 둘은 상호 교체가 가능하며, 웹 브라우저나 다른 네트워크 응용프로그램에서 로컬 호스트로 연결할 때 둘 다 사용된다. 예를 들어 브라우저에서 "http://localhost" 또는 "http://127.0.0.1"로 접속하는 것은 동일한 로컬 시스템에 대한 접속을 의미한다.

localhost를 사용하는 것이 일반적으로 더 편리하고 쉽지만, 특정 상황에서는 직접 IP 주소를 사용해야할 때가 있을 수 있다.

 

파이썬에서 환경을 설정할 때 패키지를 설치하고 실행하게 된다. 

깃허브에 릴리즈된 수많은 오픈소스들을 봐도 보통 특정 프로젝트(코드)를 실행하기 위한 환경에 대한 정보가 제공되거나 requirements.txt가 함께 제공되는 것을 확인할 수 있다.

http://github.com/clovaai/deep-text-recognition-benchmark

 

requirements.txt 란?

python 프로젝트 파일(.py)이 실행되는 데 필요한 패키지 정보들이 담긴 문서로, 다른 가상환경이나 다른 파이썬 환경에서 python 종속성을 따라 똑같은 환경을 구성할 수 있도록 도움을 준다. 이름을 꼭 requirements.txt로 네이밍할 필요는 없지만 대다수의 프로젝트에서 파이썬 패키지 리스트를 저장하는 파일을 requirements.txt 로 사용하고 있어 암묵적인 약속(?)의 네이밍이라고 생각하면 편하다.

import datetime.datetime as dt
import pytz

tz = pytz.timezone('Asia/Seoul')
date_now = dt.now(tz)
print(date_now)

위와 같은 간단한 코드를 실행하려고 해도 datetime/pytz 패키지가 설치되어있지 않거나, 혹은 둘 다 설치되어있다고 해도 두 패키지의 의존성이 맞지 않으면 실행되지 않을 수 있기 때문에 패키지의 수가 많아질수록 서로 의존성을 해치지 않는지를 확인해야 한다. 

보통 가상환경을 통해 테스트하거나, 프로젝트별 가상환경을 따로 만들어서 실행하는 것이 일반적이다.

 

이 때, 주의해야 할 것이 conda 와 pip 를 혼동하지 않는 것이다. conda로 가상환경을 만들어서 사용하는 사람이라면 혼동하는 실수를 할 수도 있다. 둘 다 python 패키지를 관리하는 도구이지만 몇가지 차이점이 있다.

Conda

- python 뿐만 아니라 다양한 언어 (C, C++ 등)의 패키지를 관리할 수 있는 통합 패키지관리자로, 환경을 관리하고 패키지 의존성을 해결하는 데 특화되어 있다.

- 미리 컴파일된 바이너리 패키지를 사용하여 설치/업데이트/삭제를 수행하므로 컴파일 과정이 필요없다.

Pip

- 주로 python 패키지를 설치하고 관리하는 데 사용된다. PyPI(Python Package Index)에서 패키지를 가져와 설치한다. 

- 패키지를 소스코드로부터 설치하므로 해당 패키지에 필요한 컴파일러 및 의존성이 필요할 수 있다.

 

conda 패키지의 버전 정보 확인 : anaconda 사이트

 

python 패키지의 버전 정보 확인 : pypi 사이트

같은 패키지명이라도 각자 다른 버전을 제공하는 것을 확인할 수 있다.

 

주의!! Conda와 pip는 각자의 패키지 관리 및 의존성 해결 전략을 가지고 있기 때문에, Conda에서 pip로 변환할 때 몇 가지 주의사항이 있다.

일반적으로 pip 명령어로 requirements.txt를 추출할 때

pip freeze > requirements.txt

 

위의 명령어를 사용하게 되는데, pip로 install 했다면 정상적으로 보였을 내용들이,

 

conda를 사용하여 패키지를 설치했다면 아래와 같은 상황이 발생할 수 있다.

이런 에러가 발생하는 이유는 conda로 설치한 패키지를 pip를 이용하여 freeze 하려고 했기 때문에 경로에 대한 내용이 기재되어 출력되는 현상이 발생하는 것이다. conda용 requirements.txt 커맨드는 따로 존재한다.

conda list -e > requirements.txt

 

 

위의 커맨드를 실행하면 

2번 이미지

위와 같은 형태로 다시 requirements.txt가 다르게 생성이 되는 것을 확인할 수 있다. 그러나 위의 커맨드를 사용한 requirements.txt의 내용은 뒤에 요상한 형태의 내용들이 붙어있는 것을 볼 수 있다. 이는 conda로 부터 붙어오는 

이 내용을 pip requirements.txt로 변환하고 싶다면

pip list --format=freeze > requirements.txt

로 변환이 가능하다. 다만 주의해야할 것은 이대로 install하게되면 conda<>pip 간의 다른 패키지 관리 시스템으로 dependecy issue/error가 발생할 수 있다.

 

만약 2번 이미지의 requirements.txt 을 리눅스 환경 내의 콘다에서 사용하고 싶다면, 

가상환경을 activate 한 다음 아래의 커맨드를 입력하면 정상적으로 환경이 설치되는 것을 확인할 수 있다.

conda install --file requirements.txt

 

그 외에, pip 명령을 사용하여 conda의 버전을 설치하고 싶다면, 

pip install --no-deps -r requirements.txt

 

pip이 의존성을 자동으로 해결하지 않도록 설정하여 설치할 수 있다.

 

가장 간단한 방법은 conda를 사용하여 파일에 명시된 패키지들을 직접 설치하는 것이다.

conda create -n <environment_name>  -f requirements.txt

 

경우에 따라 pip와 conda를 함께 사용하여 패키지를 설치해야할 수있는데, conda로 관리되는 패키지와 pip로 관리되는 패키지가 공존할 수 있다.

# Conda로 관리되는 패키지 설치
conda install --file requirements_conda.txt

# Pip으로 관리되는 패키지 설치
pip install -r requirements_pip.txt

 

만약 pip install 하기 위한 패키지명이 필요하다면 requirements.txt의 디렉토리로 접속한 뒤 정규식을 통해 pip-requirements.txt로 추출할 수 있다.

sed -En 's/^([a-zA-Z0-9\-]+)=([0-9\.]+)=.*/\1==\2/p' requirements.txt > pip-requirements.txt

 

conda 커맨드를 사용하여 추출한 requirements.txt와 conda 커맨드 > 정규표현식으로 추출한 pip-requirements.txt의 내용을 비교하면 아래와 같이 다른 것을 확인할 수 있다.

 

반대로 pip freeze로 추출한 requirements.txt를 conda 환경에서 인스톨하는 경우라면 

conda install pip
pip install -r requirements.txt

위의 커맨드를 사용하여 설치할 수 있다.


나의 경우는 아래와 같은 방법을 사용하여 해결할 수 있었다.

1. 우선, pip freeze 커맨드로 requirements 뽑기

pip freeze > requirements.txt

2. 위의 커맨드로 뽑은 requirements는 일부 라인 끝에 @로 시작하는 내용이 붙어있기 때문에 제거한다. sed 명령어와 정규표현식을 활용해서 수정하기

sed -i.bak '/@/d' requirements.txt

3. 수정한 내용의 requirements를 설치하기

pip install -r requirements.txt

 

이러한 접근 방식들을 사용하여 conda에서 pip로 환경을 전환하며 최소한의 의존성 충돌을 유지할 수 있을 것이다.

 

레퍼런스 참고 : 사이트

5월 한달동안은 연휴도 많고 이벤트도 많았다. 쉬는날이 많았던만큼 공부할 시간과 운동할 시간도 많아서 좋았다. 중학교 동창들과 등산도 다녀오고 가족모임에도 많은 시간을 할애했다. 주변의 경조사에도 많이 참석했다.

오랜만에 인바디를 쟀더니 근육량이 30kg가 됐다. 스트렝스와 자세에 집중했더니 중량도 더 늘었다. 아직까지 운동을 가기 귀찮다고 생각한 적이 없다. 제대로 재미가 붙은 것 같다.

 

3,4월동안 삽질 아닌 삽질을 하고 2개월간의 업무내용을 보고드렸는데 코드가 계속해서 빙빙 돌고 비효율적으로 짜는 경향이 있다고 사수님께 피드백을 받았다. 나름 성과도 있고 개선을 했다고 생각했지만 아무래도 회사의 기대치에는 못 미쳤던 것 같다.

일주일 전 수습 종료 및 정규직 전환을 진행하지 않겠다는 상무님의 이야기를 듣고 올 것이 왔구나 하는 홀가분함과 동시에 불안감이 찾아왔다. 덕분에 오히려 허심탄회하게 상급자와 이야기하고 일대일 면담을 할 수 있었다. 총 세명의 상급자와 퇴사관련 면담을 했는데, 세 분이 공통적으로 말씀하시는 부분들이 나의 본 모습이라는 걸 느끼고 한편으로는 3개월동안의 긴 면접을 통과한 기분이었다. 덕분에 나의 장단점을 알 수 있었다.

나의 장점

1. 성격이 밝고 좋다(?)  : 긍정과 부정을 한 단어로 뭉뚱그리는 단어라 명확히는 이해되지 않지만 긍정적인 편에 속한다는 뜻으로 이해했다.

2. 사람들과 잘 어울리고 커뮤니케이션을 잘한다.

3. 업무에 대한 자세가 적극적이고 모르는 걸 배우려는 의지가 있다.

 

나의 단점

1. 완벽주의 : 완벽주의를 따질 실력이 아닌데 어느 정도 본인이 만족할만한 성과를 만들고 나서 보고를 한다.

2. 완벽주의와도 연결이 되는 건데, 질문을 너무 안 하고 작은 문제에 너무 매몰돼서 끙끙대며 시간 낭비를 한다.

3. 기초 지식이 부족하다 : CS, 네트워크, 자료구조, 알고리즘 등

 

삼개월간 좋은 직장에서 좋은 직장동료와 선후배, 많은 데이터와 레퍼런스 코드들을 통해 많이 성장했던 것 같다. 피드백을 기반으로 부족한 부분을 메꾸고 나의 나은 부분을 더욱 업그레이드해야겠다. 단점의 대부분이 업무적인 스킬과 경험의 부족함에서 오는 것이고, 장점은 대부분 나의 인간성에 관한 것이라 오히려 다행이라고 생각했다. 그래도 나의 됨됨이가 나쁘지는 않구나 ..

사수님이 좋은 말씀을 많이 해주셔서 위로가 되었다. 북돋아주시려고 하신 말씀같으면서도 뼈가 있는 말씀들이라 마음에 담아두고 의기소침해하지 않아야겠다고 생각했다. 아무래도 회사가 스타트업이다보니 스타트업 특성 상 기간 내에 성장을 해야 하고 그 기간 내에 성장을 못하게 되면 회사가 도산할 수도 있기 때문에 (상무님이) 그런 선택을 하신 것 같다. 대기업이라면 OJT도 더욱 잘해주고 온보딩 기간도 넉넉하게 줄텐데, 회사가 성장이 급속도로 이루어지고 있고 확장이 너무 급한 시기라 회사의 성장 곡선과 나의 입사 타이밍이 맞지 않았다고 생각해라. 절대 너가 부족해서 그런 게 아니다. 이 말씀이 한껏 기죽었던 나의 마음에 와닿았다.

 

다음 회사에서는 기반을 갈고 닦아 더욱 좋은 직장동료가 되어야겠다는 생각이 들었다. 그렇게 되면 나도 더욱 좋은 환경에서 일하는 날이 오겠지.

배운것이 많은 한달이었다.

'Think' 카테고리의 다른 글

2024년 1월 회고  (0) 2024.02.02
2023년 회고  (0) 2024.01.12
2023년 4월 회고  (0) 2023.05.09
2022년 9월 회고  (1) 2022.10.04
2022년 8월 회고  (0) 2022.09.01

+ Recent posts