내일은 알고리즘

1. RPO RTO

Recovery Point Objective : 복구 시점 목표

시스템 장애, 업무 중단 시 백업수단을 통해 복구할 수 있는 기준점.

Recovery Time Objective : 복구 시간 목표

시스템 장애 발생, 업무 중단 시점으로부터 업무가 복구되어 정상가동 될 때까지의 시간.

RPO와 RTO 모두 시스템 장애 시간으로부터 가까울 수록 좋으나, 더 많은 비용 소모.

Business Impact Analysis : 업무 영향 분석

재난, 재해로부터 시스템 중단을 가정하여 중단 시간에 따른 영향도를 분석해 복구의 우선순위를 정하고 업무재개를 위해 필요한 자원을 도출해 냄.

2. 파이썬

파이썬 Set 자료구조 활용

3. AJAX

Asynchronous JavaScript And XML 

비동기적인 웹 어플리케이션 제작을 위해 사용하는 기법이다.

기존의 웹사이트들은 사용자가 어떤 요청(데이터)을 보내면 서버에서 그 요청을 가공해서 새로운 웹페이지를 응답했다. 

하지만 AJAX를 이용한 웹사이트에서는 웹페이지가 아닌 데이터만 비동기적으로 응답된다.

따라서 통신되는 코드와 데이터 양을 줄일수 있고 대기시간 없이 화면전환이 가능하다.

4. 애자일 방법론

소프트웨어 개발 방법론의 하나로, 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법.

특정한 방법을 말하기 보다는 방향성을 의미.

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

5. JAVA

JAVA 언어에서의 상속(extends) 활용

6. SQL

7. SQL-ROLLBACK

ROLLBACK : 트랜잭션이 실패했을때 작업을 취소하고 변경된 데이터를 이전 상태로 되돌리는 데이터 제어어

8. IPSec

네트워크 계층인 인터넷 프로토콜(IP)에서 '암호화', '인증', '키 관리'를 통해 보안성을 제공해 주는 표준화된 기술

보안에 취약한 구조를 가진 IP의 보안을 위하여 통신 세션의 각 IP패킷을 암호화하고 인증하는 IPS(Internet Protocol Suite)

IPv4에선 보안이 필요한 경우에만 선택적으로 사용하였지만 IPv6부턴 기본 스펙에 포함됨

9. 분석

정적 분석, 정적 테스트 (Code Inspection)

실행상의 장애 보다는 코드의 결함을 찾음. (코드 보안 취약점, 코딩 표준 위반, Dead Code, 일관성 깨짐 등)

Inspection : 공식적 검사

Peer Review : 프로젝트 과정에서 동료들이 상호교차 검토

WalkThrough : 개발 초기에 팀 내에서 수행하는 검토

동적 테스트 (Dynamic Testing)

소프트웨어의 코드를 직접 실행시키며 수행하는 테스트.

블랙박스 테스트 : 모듈 안은 보지 않고 입력과 출력을 관찰.

화이트박스 테스트 : 모듈 안의 작동을 직접 관찰, 논리적인 구조가 커버되도록 tc를 설계

10. 디자인패턴

11. OSI 7계층

네트워크 관련 지식인 OSI 7계층을 알고 있는지 묻는 문제입니다. 

헷갈릴만한 개념으로는 TCP/IP 5계층이 있습니다

(물리 - 데이터링크 - 네트워크 - 전송 - 응용)

12. LoC기법

Line of Code

코드 라인수의 낙관치, 기대치, 비관치로 예측치를 구하고 이것으로 프로그램 개발 시간을 예측하는 기법.

예측치 : (낙관치 + 4 * 기대치 + 비관치) / 6

예시 ) 프로그램의 예측된 라인수가 10000라인이고 프로그래머가 일 평균 100라인을 작성하고 프로그래머가 5명일때 개발 기간은 10000/(100*5) = 20일

13. 애플리케이션 성능측정

성능테스트(목적에 따른 구분)

성능테스트(방법에 따른 구분)

성능지표

14. 소프트웨어 모듈화

시스템의 계층을 나누고 기능별로 분해하여 성능, 유지보수성, 재사용성 등을 향상시키는 설계기법.

모듈화의 목표 -> 결합도를 낮추고 모듈 내 응집도를 높이는 것.

응집도 : 모듈의 내부기능이 얼마나 연관되어 있는가.

결합도 : 모듈간 얼마나 구분이 되어 있는가.

15. 데이터베이스 정규화 & 반정규화

정규화 : 데이터 베이스 테이블 간에 중복된 데이터를 허용하지 않아 무결성을 유지. 삽입,갱신 등에서 이상(Anomaly)을 방지하는 것.

반정규화 : 데이터베이스 성능향상을 위해 의도적으로 정규화에 어긋난 데이터 구조로 만드는 행위

테이블 합병, 중복칼럼 추가, 계산된 칼럼 추가 등등

16. 공유도(팬인 Fan-In)  제어도(팬아웃 Fan-Out)

공유도(팬인 Fan-In) : 나를 제어할 수 있는 다른 모듈의 갯수

제어도(팬아웃 Fan-Out) : 제어할 수 있는 다른 모듈의 갯수

17. C언어

c언어 반복문

18. C언어 CASE 문

case 조건문에서 break; 구문이 없을시의 특징을 묻는 문제입니다.

19. JAVA

java 반복문

20. SQL

기본적인 SQL 쿼리문을 이해하는지 묻는 문제이다. SQL 쿼리에 대해서는 따로 정리해서 올리도록 하겠습니다. 

신청한게 엊그제 같은데 벌써 정보처리기사 실기 시험이 2주 남았다.

작년엔 코로나로 불참 + 싸피로 바빠서 공부도 별로 하지 못하고 응시료만 날렸는데 백수인 지금은 2주 전부터 미리미리(?) 준비를 해서 한 번에 통과하겠다는 각오다.

문제를 직접 올리는건 저작권에 걸릴까봐 문제에서 묻는 개념 키워드를 설명하는 식으로 작성하겠다.

1. XML

웹 관련 프로그래밍을 해본 사람이면 AJAX라던지, XMLrequest 라던지 여러모로 익숙한 친구이다.

XML은 EXtensible Markup Language의 앞글자를 따서 붙인 이름으로 HTML의 부족한 부분을 보완하기 위해 만든 마크업 언어이다. 

마크업 언어는 데이터를 표현하기 위해 사용하는 문법으로 (프로그래밍 언어가 아니다!) 익숙한 HTML도 마크업 언어의 하나이다.단순히 HTML로 표현된 정적인 웹페이지의 위주이던 초창기 인터넷 환경에서 여러 데이터가 오갈 필요가 생기게 되는데 HTML의 경우엔 서로 다른 사이트 간에 데이터의 의미를 정확히 전달하기가 어려웠다.

예를들어 내가 학생명부를 보내려고 <p> 이름:김철수 학번:1234 , 이름:박철수 학번:1111 </p> 이런 데이터를 보냈을때 상대 사이트에선 학생 데이터가 온다는건 알아도 저 정보를 파싱하기 위한 파서가 따로 필요하다. 

또 내가 실수로 데이터 순서를 바꾸어 보낸다던지 할 경우 데이터가 뒤섞일 우려가 있다.

XML의 경우엔

<학생명부>
   <학생데이터>
        <이름>김철수</이름>
        <학번>1234</학번>
   </학생데이터>
   <학생데이터>
        <이름>박철수</이름>
        <학번>5678</학번>
   </학생데이터>
</학생명부>

이런 형태로 깊이와 태그명을 사용해서 데이터를 표현할 수 있다. 

지금은 이런 XML도 복잡하다고 JSON을 많이 사용하는데... 나중에 마크업언어들을 따로 정리해야겠다.

2. JSON

호랑이도 제 말 하면 온다더니 곧바로 JSON의 개념을 묻는 문제가 나왔다.

JSON은 속성-값 으로 이루어진 포맷이다.

아까 말했던 AJAX (Asynchronous JavaScript and XML)는 이름부터 XML이 들어가 있지만 요즘은 XML대신 JSON을 사용해 데이터를 전달한다. 

JSON을 사용해 아까 XML로 나타냈던 데이터를 표현하면 이런 느낌이다.

{
	"학생명부" : [{"이름":김철수, "학번":1234}, {"이름":박철수, "학번":5678}]
}

XML이던 JSON이던 프로그래머가 작성하기 나름이지만 JSON이 상당히 간료해 보이는걸 알 수 있다.

3. 릴리즈노트

릴리즈 노트는 소프트웨어 제품과 함께 배포되는 문서들을 말하며, 제품이 개발 중이거나 테스트 상태일 때 추가되기도 한다. 고객이 이미 사용 중인 제품의 경우 릴리즈 노트는 업데이트가 출시될 때 고객에게 전달된다. (위키피디아 설명)

그렇다고 한다. 흔히 우리가 사용하는 프로그램을 업데이트 했을때

어쩌구게임 ver 2022.378831 패치내역

1. 비쥬얼 업데이트를 적용함.
2. 김철수 캐릭터의 밸런스를 조정함.
3. 특정 상황에서 채팅이 쳐지지 않던 버그를 수정함.

이런 창을 보게 되는데 그런걸 생각하면 될 것 같다. 

릴리즈노트는 표준형식이 없이 프로그램의 개발 회사나 팀에 따라 다양하게 작성되는데, 보편적인 구성 항목은 이렇다고 한다.

머릿말: 문서 이름(예: 릴리스 노트), 제품 이름, 릴리스 번호, 출시일, 노트 날짜, 노트 버전 등.
개요: 다른 공식 문서가 없을 때 제품과 변경사항에 대한 간략한 개요.
목적: 버그 픽스와 새로운 기능을 포함한 이 릴리스의 새로운 사항의 나열과 더불어 릴리스 노트의 목적에 대한 간략한 개요.
문제 요약: 릴리스의 버그나 개선사항에 대한 짧은 설명.
재현 단계: 버그 발생을 재현하기 위한 절차.
해결책: 버그 수정을 위한 수정/개선사항의 짧은 설명.
최종 사용자 영향: 응용 프로그램의 최종 사용자에게 필요한 조치. 이 변경사항으로 인해 다른 기능이 영향을 받는지의 여부가 포함되는 것이 좋다.
지원 영향: 소프트웨어 관리의 일일 프로세스에 필요한 변경사항.
참고: 소프트웨어나 하드웨어의 설치, 업그레이드, 제품 문서화에 관한 참고사항. (문서화 업데이트 포함)
면책: 회사와 표준 제품 관련 메시지 (예: 프리웨어, 불법 복제 금지 등)
연락처: 지원 연락처 정보.

4. 살충제 패러독스

애플리케이션 테스트의 기본 원리 중, 살충제 패러독스의 의미를 묻는 문제이다.

살충제 패러독스는 이름 처럼 같은 테스트를 반복해서 실행할 시 프로그램의 장애, 버그를 찾을 수 없다는 개념을 의미한다.

예를 들어 우리가 어떤 길찾기 프로그램을 만들었다고 하자.

프로그램이 잘 작동하는지를 확인하기 위해 회사에서 근처의 편의점을 가는 경로를 찾아봤더니 오류가 발생했다!

열심히 오류를 고치고 다시 테스트 했더니 완벽하게 동작한다.

그 후 프로그램이 몇번의 업데이트를 거치고 다시 테스트의 시간이 되었다.

예전에 했던 테스트를 똑같이 반복해 근처의 편의점을 가는 경로를 검색했더니 잘 나온다. 와! 

그럼 이 프로그램은 버그가 없는걸까? 

우리가 이전의 테스트(살충제)를 통해 확인한 오류를 고쳤기 때문에 해당 버그는 사라졌지만, 다른 곳에는 어떤 버그가 남아있을지 모른다.

수천명이 동시접속하면 서버가 터질 수도 있고, 편의점 대신 병원을 검색하거나 PC가 아니라 모바일 환경에서 접속하면 버그가 발생할 수도 있다.

이렇듯 같은 방법의 테스트를 반복하면 오류를 찾을 수 없다는게 살충제 패러독스의 의미이다.

5. 데이터 마이닝

요 10년 사이에 핫해진 빅데이터 관련 용어이다. 

데이터 마이닝이란 "많은 데이터에서 데이터간의 관계를 찾아내어 유용하고 가치있는 정보를 추출해 내고 이를 의사결정에 이용하는 과정" 이라고 말할 수 있을것 같다.

참고로 데이터 마이닝과 데이터 크롤링, 웹 크롤링이 조금 혼동되는데 보통 데이터 마이닝은 모여진 데이터에서 의미를 찾는 과정. 데이터 크롤링은 그 데이터를 모으는 과정이라고 생각하면 될 것 같다.

6. 프로토콜

Protocol

컴퓨터들 간의 원활한 통신을 위해 지키기로 약속한 규약. 프로토콜에는 신호 처리법, 오류처리, 암호, 인증, 주소 등을 포함한다. 통신을 원하는 두 개체간에 무엇을 어떻게 언제 통신할 것인지 약속해 둔 규약이다.

우리가 네트워크에서 배운 TCP/IP 나 HTTP도 프로토콜이다.

프로토콜을 구성하는 세가지 요소는 이렇다.

-구문(Syntax)

   데이터의 형식(아날로그 or 디지털), 부호화(Unicode, ASCII), 신호크기를 정하는 구문

-의미(Semantics)

   전송제어 (동기화, 전송정지 및 재개, 완료, 재전송, 등등의 신호를 정함), 오류수정(데이터 무결성, 패리티비트, CRC)

-시간(Timing) :

   신호의 지속시간, 신호의 순서 등을 정하여 타이밍을 이룸

7. 해시함수

해시함수의 종류와 설명을 정확히 알고 있는지를 묻는 문제인데, 개인적으로 정말 싫어하는 유형이다.

중요한 해시함수들의 설명은 이렇다.

8. 스케쥴링

운영체제 전공 수업때 배운 스케쥴링 문제이다.

9. 데이터베이스 트랜잭션

트랜잭션 Tx, Transaction의 특성

10. 서비스 거부 공격

DoS (Denial of Service)

시스템이 정상적인 서비스를 할 수 없도록 하는 공격을 의미한다.

DDoS는 다수의 좀비 PC을 이용해 정상적인 요청을 막대하게 보내는 방식으로 공격하지만 DoS는 서비스의 취약점을 노리고 보내는 공격이다.

코드를 작성한다.

어쩐지 오늘은 손에 날개라도 달린듯 손가락이 가볍게 움직인다.

내가 봐도 깔끔하고 잘 짜인 코드를 이제 Git에 올릴 시간이다.

Push 명령어를 입력하자 '띵~' 에러 소리가 울려퍼진다.

식은땀이 흐른다. 혹시 오타가 있을까 심혈을 기울여 다시 명령어를 입력한다.

띵~ 띵~ 띵띵띵띵~

fatal 'origin' does not appear to be a git repository

따옴표 안의 단어는 origin이 아닐수도 있다.

위 에러는 두가지 경우에 발생한다.

1. remote 저장소의 경로에 문제가 있을때

2. 내 branch 경로에 문제가 있을때

내 local 저장소는 remote 저장소의 복제본을 갖는다. 

코드를 작성하고 바뀐 파일들을 commit하는 것은 내 local 저장소의 branch를 수정하는 것이고, 이를 remote저장소에도 반영하기 위해서 Push가 필요하다. 이때 local 저장소의 branch 경로를 remote저장소와 비교한다.

위의 에러는 그 경로의 불일치로 발생한다.

1번의 경우 경로를 저장한 파일이 손상되었거나, remote의 경로가 변경되었거나 등의 이유로 remote저장소를 찾지 못하는상황이다. 

git remote remove 'origin' 명령어를 사용하여 remote 저장소의 경로를 지워주고

(설정에 따라 remote저장소의 경로가 origin이 아닐 수도 있다.)

git remote add origin (git repo의 HTTPS 주소, 혹은 SSH)를 입력해서 다시 연결해주면 된다.

2번의 경우 branch를 만들때 오타(otigin 이라던지... origim 이라던지)나 오류가 발생하여 local branch의 경로가 이상해진 상황이다. 변경 상황을 잘 commit 해 둔 뒤 branch의 이름과 경로를 잘 확인하고 다시 만들자.

에러가 난 branch를 지우는게 아니다. 다시 만드는 것이다. 

내가 만드려던 branch의 이름이 feature/FE 라고 했을때 에러가 난 상황에서 branch를 다시 만든다면

origin/feature/FE   (원래 만드려던 정상 branch)

feature/FE (에러 branch)

otigin/feature/FE (에러 branch)

내 local 저장소는 이런 상태가 된다.

제대로 만들어진 feature/FE로 checkout 해 주고 에러가 난 branch를 merge하자.

remote 저장소와의 경로 불일치로 동기화가 안 될 뿐 local에는 멀쩡히 존재하는 branch이므로 아무 문제없이 merge가 된다.

내가 변경한 코드가 잘 반영되었는지 확인하고 다시 Push해주면 된다.

우선 git이 설치되어야겠죠?

https://git-scm.com/

자신의 OS와 개발환경에 맞게 설정해주시면 됩니다.

환경변수나 추가적인 조정이 필요 할 수도 있습니다.

이 글을 보시는 분들이 기본적인 git의 개념과 사용법을 아신다고 생각하고,

제가 프로젝트를 진행하며 외울정도로 자주 사용한 커맨드만 작성해봤습니다.

아래는 VScode에서 git을 사용할 때 유용한 extension입니다.

git clone (git repo의 HTTPS 주소, 혹은 SSH)
-----> 지금 vscode 터미널이 위치한 폴더에 repo를 복제해옵니다. 
다른 옵션을 안줬을 경우 기본 branch가 복제됩니다.

git remote update
-----> git 서버의 저장소의 상태를 업데이트합니다.

git pull
-----> git 서버 저장소에서 현재 branch의 최신 상태를 가져옵니다.

git push
-----> 내 로컬 저장소에 있는 현재 branch를 서버에 update하거나 publish 합니다.

git branch
-----> 내 로컬 git에 있는 branch의 리스트를 띄웁니다.

git branch -a
-----> git 서버에 있는 branch의 리스트를 띄웁니다.
VIM처럼 [esc] + ':' + 'q' 세개의 키를 차례로 입력해 나옵니다. (이에스시, 콜론, 알파벳 큐) 

git branch (새로운 branch명)
-----> 내 로컬 저장소에 입력한 이름으로 branch를 만듭니다.

git checkout origin/(branch명)
----->  git 서버에 있는 branch를 내 로컬 git으로 가져오면서 그 branch를 선택합니다.

git branch -D (branch명)
-----> 내 로컬 저장소에서 해당하는 branch를 지웁니다.

git merge (branch명)
-----> 현재 보고 있는 branch에 입력한 branch를 병합합니다. 충돌이 발생할 수 있습니다.

EX) 

프론트개발자 노딩코 씨가 서버에 존재하는 프로젝트 A를 작업하려고 하는 사용 예

git clone (project-A의 clone 주소)

-----> 서버의 프로젝트를 내 로컬로 받아옵니다.

git checkout origin/develop

-----> 보통 기본 branch는 master나 default입니다.

작업을 위해 develop branch를 로컬로 가져오면서 branch를 변경합니다.

git branch feat/frontend-nodingco

-----> develop branch의 현재 상태를 복제해 내가 작업할 branch를 만듭니다.

git checkout feat/frontend-nodingco

-----> 작업할 branch로 변경합니다.

<branch의 생성 후 작업이 진행 되었습니다... 내 작업을 업로드해봅시다!>

git remote update

-----> 서버 저장소의 변경사항을 update

git checkout develop

-----> 내 작업을 업로드할 develop branch로 변경합니다.

git pull

-----> 서버저장소에서 develop branch의 최신 상태를 가져옵니다.

git checkout feat/frontend-nodingco

-----> 작업한 branch로 변경합니다.

git merge develop

-----> 최신상태의 develop branch를 내가 작업한 내용에 merge합니다.

충돌이 일어난다면 VScode에서 알려주는 내용을 토대로 적절히 수정하면 됩니다.

git push

-----> 내가 작업한 branch를 서버저장소에 업로드합니다.

보통 develop이나 master같은 배포에 관련된 branch는 보호되어있으므로,

서버 저장소에서 merge request를 통해 code review를 받고 변경된 내용을 merge하게 됩니다.