Chae

[ 잡담 ]

개발에 관련된 지식만 쌓다 보니 네트워크에 대한 공부를 전혀 하지 않게 되었고 이번 토스 공채를 보면서 네트워크는 기본적으로 어느 정도 다룰 줄 알아야 한다는 사실과 네트워크 관련된 부서로 발령받을 수도 있으니 미리미리 준비해둬야겠다는 생각으로 네트워크 공부를 시작해본다.

가만히 앉아서 글을 읽고 이해하는 행위를 하는 것을 잘 못한다. 코드를 짤 때는 그 누구보다 진득하게 앉아있을 자신이 있지만 장시간 글과 마주하는 것은 자신이 없다.

개발을 하다 보면 가끔씩 네트워크 지식이 필요할 때가 있어 찾아보면 너무 어렵고 전문적으로 정리가 되어있어서 금방 포기하곤 했다. 이제 기초부터 공부를 하는 나에게 깊은 지식 따윈 없다. 조금 틀린 정보가 섞여 들어갈 수 도 있지만 쉽게 쉽게 네트워크 용어를 정리해 나가 보자.

[ 본론 ]

인터넷(InterNet)

Inter은 연결을 의미한다. 즉 Network의 연결을 의미한다. 

인트라넷(IntraNet)

Intra는 내부라는 의미다. 즉 내부의 내트워크, 회사 내부 네트워크 망을 예시로 들 수 있다.

엑스트라넷(ExtraNet)

인트라넷과 비슷하지만 사내 종직원 말고도 협력 회사나 고객들도 사용할 수 있는 환경이다.

LAN(Local Area Network) and WAN(Wide Area Network)

LAN은 한정된 지역에서의 네트워크 구축, WAN은 멀리 떨어진 곳과의 네트워크 구축. 인터넷 접속은 WAN이라 할 수 있다.

이더넷(Ethernet)

네트워킹의 하나의 방식이다. 아래의 토큰링 또한 네트워킹 방식 중 하나다. 이외에 FDDI, ATM 등 다양한 방식이 존재하는 것 같다. A컴퓨터가 B컴퓨터로 데이터를 전송하는데 다른 컴퓨터들이 통신하는지 눈치를 보고 진행중인 통신이 없다면 전송하는 방식이다. 이때 C 컴퓨터가 D컴퓨터로 동시에 전송을 하게 되면 충돌이 일어나게 된다. 이런 상황을 *콜리전(Collision)이라고 한다. A컴퓨터와 C컴퓨터는 랜덤 시간 동안 대기를 하다가 다시 전송을 하게 된다.

*콜리전(Collision)

토큰링(TokenRing)

수건 돌리기 놀이를 하듯이 컴퓨터들끼리 토큰을 돌린다. 토큰을 가지고 있는 컴퓨터만 데이터를 전송할 수 있다. 보내야 하는 데이터가 있더라도 보낼 데이터가 없는 컴퓨터에게 토큰이 돌아가는 걸 기다려야 하는 단점이 있다.

케이블

네트워크 장비와 네트워크 장비를 연결하기 위해서는 케이블이 필요하다. 광케이블, UTP케이블, 동축케이블 등 종류가 다양하다. 그 중 가장 많이 사용하는 케이블이 UTP케이블이다. TP(Twisted-pair) 즉 꼬여있다는 말이다. UTP와 STP가 있는데 U(Unshileled) 감싸져 있지 않은 케이블 S(Shieled) 절연체로 감싸져있는 케이블을 말한다.

MAC(Media Access Control) Address

네트워크상에서 서로서로 구분하기 위한 하드웨어 주소. IP주소만 있으면 모든 통신이 일어날 것 같지만 IP Address를 MAC Address로 바꾸는 절차, 즉 *ARP가 존재한다. MAC Address는 8자리마다 하이픈(-), 콜론(:), 점(.)으로 구분되어 진다. 예를들어 00-06-97-8F-4F-86처럼 나타나고 00-06-97는 생성자 코드(*OUI)다. 

*ARP(Address Resolution Protocol)
*OUI(Organizational Unique Identifier)

유니캐스트

우리가 네트워크 상에서 가장 많이 사용되는 트래픽이 유니캐스트다. 편지를 보내는 방식이라고 생각하면 된다. 받는 컴퓨터의 주소를 입력해서 내용을 담아 보낸다. 랜카드가 자신에게 온 편지가 아니라는 것을 주소를 보고 파악하고 프레임을 버려버리기 때문에 CPU에게 영향을 주지 않는다.

브로드캐스트

주변 모든 네트워크 장비들에게 보내는 통신 방식. 받기 싫어하는 장비들도 받을 수 밖에 없기 때문에 브로드캐스트 방식으로 주된 통신을 이루게 되면 주변 PC들의 CPU 성능을 저하시킨다. 앞서 말한 APR 또한 브로드캐스트 방식이다.

멀티캐스트

200명의 사용자가 있는 네트워크에서 150에게 정보를 보내야한다. 유니캐스트를 사용했을 때 150번이나 반복해서 요청을 보내야한다. 같은 데이터를 150버이나 반복되어 보내지기 때문에 트래픽을 가중시킨다. 브로드캐스트를 사용했을 때 받지 않아도 되는 50명의 CPU의 성능을 하락시키게 된다. 이 두가지의 문제점을 해결 할 수 있는 통신방식이 멀티캐스트이다.

update 2020.08.30

[ 잡담 ]

개발에 있어서 소프트웨어 생명 주기[SDLC(Software Development Life Cycle)]는 매우 중요하다.

따로 여기에 대해서 공부한 적은 없지만(학교에서 배운 것 같은데 기억이 전혀 나지 않는다) 여러 프로젝트를 진행하면서 항상 거쳐와야 했던 부분이 것 같다. 듣기로는 요구분석부터 시작해서 개발 전까지 가장 많은 시간이 소요된다고 했다. 하지만 내가 해왔던 프로젝트들은 내가 불편하다고 느껴서 개선하기 위해 제작했던 서비스들이기에 요구사항을 분석하거나 설계를 하는데 큰 시간을 들이지 않았다. 내가 불편했던 점만 개선하면 됐기 때문이다. 어떤 방식이 정답이라고는 할 순 없겠지만 회사에 들어가서 내가 불편하다고 느꼈던 부분을 개선하기 위한 프로젝트만 진행하리란 법은 없을 것이기 때문에 이론적으로 정리해 보도록하자.

이런 식의 프로젝트 진행의 가장 큰 문제점은 위 그래프의 사진과 같다. 서비스 출시가 다가올수록 버리는(Thrashing) 부분이 많이 지고, 다시금 프로세스를 고려하면서 코드를 뜯어고치는 것이다. 그렇게 코드는 점점 뒤죽박죽이 되고 그 프로젝트에 대한 나의 애정은 점점 식어갔다. 그렇게 만들어진 것이 "거래해요 동물의 숲"이라는 앱이다. 개발은 완료했지만 더 이상 유지보수를 할 엄두가 나지 않았다. 

생명주기 모델

1. Code and Fix  모델

공식적인 가이드라인이나 프로세스 없이 소프트웨어를 개발해 나가는 형태

• 중요한 작업(설계, 테스트)들이 무시됨
• 각 작업이 언제 시작되어야 할지 언제 끝날지 불명확
• 대규모 작업에 적용하기 어려움
• 개인의 작업을 리뷰 하거나 평가하기 어려움

2. 폭포수 모형

계획, 요구 분석, 설계, 구현, 시험, 인수 설치 6단계를 순차적으로 시행

• 잘 모르는 문제나 연구 중심 문제에 적합
• 변화가 적은 프로젝트에 적합(새로운 피드백을 받으면 위쪽 사이클로 돌아가야 하는데 시간이 오래 걸린다)

1. 계획

프로젝트 기간, 일정, 비용 산정 등을 하는 단계.(ROI)

2. 요구 분석

기능과 성능에 대한 계획을 세우는 단계

3. 설계

데이터베이스, uml, 스토리보드 작성 등의 작업

4. 구현

실제 프로그램을 작성하는 단계

5. 시험

테스트 단계

6. 인수 설치

기존의 데이터를 재활용하는 마이그래이션이나 유지보수 단계

3. 프로토타이핑 모델

요구분석, 프로토타입 개발/개선, 프로토타입 평가, 구현, 인수 설치

• 개발 착수 시점에 사용자의 요구가 불투명할 때
• 실험적으로 실현 가능성을 타진해 보고 싶을 때
• 혁신적인 기술을 사용해 보고 싶을 때

폭포수 모델의 단점을 보완한 모델. 어느 정도 사이클이 지나고 나서 피드백을 받으면 수정하는데 엄청나게 긴 시간이 걸리게 된다. 프로토타이핑 모델은 이런 점을 보완하여 프로토타입을 만들고 사용자들에게 먼저 피드백을 받은 후에 추후 작업을 실행한다. 

4. 점증적 모델

중요한 기능부터 릴리스하고 사용자들이 사용하는 사이클을 반복함으로써 점증적으로 프로젝트 진행.

5. 나선형 모델

• 재정적 또는 기술적으로 위험 부담이 큰 경우
• 요구 사항이나 아키텍처 이해에 어려운 경우

점증적 모델의 한 종류라고 할 수 있다. 계획 목표 설정, 위험분석, 개발, 검증 및 다음 단계 수립 순서대로 반복적으로 실행.

사이클이 돌면 돌 수록 테스트 과정이 중첩됨으로 프로젝트가 견고해진다.

6. V (Verification:검증) 모델

폭포수 모델의 변형이라고 할 수 있다. 작업과 결과의 검증에 초점.

• 신뢰성이 높이 요구되는 분야

오류를 줄일 수 있지만 하나의 사이클로 이루어져있어서 반복이 없어 변경을 다루기가 쉽지 않음.

7. 일정 중심 설계 모델

일정에 중심을 맞춰서 서비스를 출시하는 모델.

• 소프트웨어 제품의 출시 날짜가 매우 중요한 경우
• 목표 일정을 달성할 수 있을지 불확실할 때

우선순위가 낮아 출시에 포함되지 않을 기능을 분석하고 설계하는데 시간을 낭비.

8. 진화적 출시 모델

고객의 요구를 여러 사이클에 걸쳐 개발하여 보여주면서 제품을 개선해 나가는 모델

프로토타이핑 모델과 다른 점

• 고객의 요구를 프로토타이핑 모델처럼 전적으로 수용하지는 않음
• 고객의 반응으로 바뀔 가능성이 적은 부분이 시스템의 핵심
• 프로토타이핑 모형은 시스템에서 눈에 띄는 부분을 먼저 강조하고 나중에 시스템 기반에 있는 구멍을 메워나가는 식

9. 애자일 모델 

Extreme Programming(xp) 설계가 거의 생략된 개발 중점적인 모델.

• 6개월 이하의 가벼운 프로젝트를 제작할 때 주로 사용 된다.

출처

http://contents.kocw.or.kr/KOCW/document/2014/dongguk/choieunman/1.pdf

Git을 사용할 때는 안 까먹고 잘 쓰는 데 사용하지 않게 되면 명령어를 까먹게 되어 정리해본다.

깊은 Git 작업은 해본적이 없기 때문에 간단하게 push 하고 fetch 하는 것만 ㅎㅎ..

1. 저장소 세팅

• 그냥 저장소 내용을 다 가져와서 remote 연결해주고 싶을 때

git clone <repository 주소>

• 저장소 remote 등록해주기

git remote add <repository 주소>

2. 업로드

sudo git add .
sudo git commit -m "커밋 내용"
sudo git push -u origin master

3. 패치

먼저 fetch와 pull의 차이를 알아봐야겠다.

◎ pull

원격 저장소로부터 필요한 파일을 다운 + 병합

git pull

◎ fetch

git fetch --all

원격 저장소로부터 필요한 파일을 다운 (병합은 따로 해야 함)

fetch를 사용하는 이유는

• 원래 내용과 바뀐 내용과의 차이를 알 수 있다

git diff HEAD origin/master

• commit이 얼마나 됐는지 알 수 있다

git log --decorate --all --oneline

이런 세부 내용 확인 후 아래 코드를 입력하면 git pull 상태와 같아진다.

git merge origin/master

4. repository remote 주소 변경할 때

/* 기존 repository */
git remote rm origin

/* 옮길 repository */
git init
git remote add https://github.com/<account name>/<repository name>.git
git add .
git commit -m "change repository"
git push -u origin master

만약에 기존 repository에 내용이 존재해서 push할 때 오류가 발생해서 덮어쓰기 해주고 싶을 때는 아래 명령어를 입력하면 오류 없이 작동된다.

git push --force --set-upstream origin master

5. .gitignore추가하기

1. 프로젝트 파일의 root 폴더에 .gitignore 파일 생성

2. push할 때 제외할 내용 추가

# .gitignore

# security
*.ini

# debug data
*.log
__pycache__

# not use folder
/test
/selenium_test
/python/
/deploy/

3. 캐시 삭제

git rm -r --cached .

4. commit & push

git add .
git commit -m "message"
git push -u origin master

참고

https://yuja-kong.tistory.com/60