2024년 12월 29일 무안공항에서 제주항공 2216편이 착륙중 폭발하는 비극적인 사고가 일어났다.

수많은 사람들이 한순간에 공포에 떨며 목숨을 잃게 되었다.

사고 발생 이후 국토부 사고조사위원회는 조사단을 현장에 파견해 현재 조사중이다.

그리고 관제기록, CVR를 확보했는데 현재 유튜브,SNS에서 피해자나 최선을 다한 기장,관제사를 두번 죽이는 발언들을 하는 사람들이 너무 많이 있어서 사실 너무 안타깝다...

또, 일부 극좌 세력의 사람들은 HID 비밀요원이 비행기를 고의로 납치해 추락시켰다는 음모론을 설파중이고

일부 극우 세력의 사람들은 민주당 간첩들이 고의로 비행기를 추락시켰다는 음모론을 설파중이다.

물론 위 내용들이 발생할 가능성을 부정하는 것은 아니다 사고가 발생했고 조사 과정에서는 비록 불가능해보고 억측에 불과한 내용처럼 보여도 충분히 가능할 수도 있는 일이기에 가능성을 열어두고 조사를 해야하는 것은 맞다.

하지만 일부 사람들은 조사가 시작되지 전부터 저런 정치적 억측들을 강력하게 주장하고 있다.

또 일부는 특정 세력에 연관된 관제사가 고의로 비행기를 19번 활주로로 착륙시켰다는 주장도 하고 있다.

여기에 대해서 반박하자면, 해당 비행기는 빠르게 하강하는 중이였고 관제사 입장에서 비행기를 정상 루트로 선회시키면 광주접근관제소에 관제를 이양하고 조종사에 컨택 지시하고, 재접근 절차를 밟아야 해서 상당한 시간이 소요되고 그 상태에서 추락하면 공항 인근 민가에 심각한 피해를 안길 수 있기 때문이다.

그래서 내가 관제사였어도 당연히 빠르게 착륙할 수 있는 19번 활주로로 배정했을 것이다.

그런데 유튜브를 보면 19번 활주로 배정 관련하여 상당한 억측과 국토부에 대한 비난이 이어지고 있다.

물론 국토부라는 행정부의 한 기관에서 비리나 부패는 당연히 발생할 수 있고 조사과정에서 조작이 발생할 수도 있다.

왜나하면 미국과 달리 우리나라는 독립된 조사기관이 아닌 항공관제 운영기관이 조사도 함께 맡기에 공정성이 일부 훼손되는 것은 사실이다.

하지만 그럼에도 불구하고 국토부 사조위는 현재까지 객관적으로 항공 사고를 조사한 이력이 있고 이번조사에 NTSB,FAA도 합동으로 참가해 공정성을 높이려는 노력이 보이기 때문에 우리가 국토부를 불신할 이유는 없어보인다.

아래는 억측들을 주장하는 사람들의 댓글과 내가 반박한 내용들이다. 사실 큰 사고가 발생했는데 계속 정치적 목적이 있다는 음모론을 설파하는 사람들이 참 별로 좋아보이지 않는다. 

어떤 세력이 정치적 목적을 달성하기 위해서 사고를 조작하거나 만드는게 불가능하지는 않다고 생각한다.

하지만 조사 결과가 나오지 않은 상태에서 어떻게 단정적으로 그렇게 말할 수가 있는가...

사고가 조사중임에도 불구하고 인내심 없이 단정적으로 자기 주장만하는 사람들이 참 한심하게 느껴진다..

저런말들은 사고 당시 최선을 다한 관제사,조종사들을 두번 죽이는 일일 것이고..

심지어 생존 승무원이 스파이라고 주장하는 사람들도 있는데 어떻게 그런 말을 할 수가 있는지 참 궁금하기도하다..

아무튼 이번 사고 조사가 신속하게 이루어지고 유가족들이 행복을 얻었으면 좋겠다.

물론 사고 조사가 완료되고 결과가 발표되도 음모론을 주장하는 사람들은 쭉 주장할 것이다.

저런 사람들의 생각을 바꾸기는 쉽지 않다.

사실 나도 대부분의 사람들이 말도 안된다고 하는 음모론 중 객관적으로 판단해보고 여러 증거를 보았을때

진실이라고 믿고 있는 음모론이 하나 있다. 그 정도로 내가 회의적이기는 커녕 오히려 음모론에 커덩커덩 넘어가는 편인데 이번 사건은 진짜 아니다.. 음모론을 주장할 사고도 아니고 지금 시점에서 함부로 음모론을 주장해서도 안된다고 생각한다...

ㄱ, ㄴ의 참/거짓을 판별하고 함수 h(x)의 일대일 대응 조건을 구하는 과정은 해설지와 유사하지만 ㄷ의 참/거짓을 판별하는 과정을 간략화한 풀이이다. 해설지에서는 m=-3, m=-2, m=-1일때 각각 g(m+b)에 대입하여 b값을 구하고 m+b>=1인지 확인하는 과정을 통해 m값을 구하는 풀이를 설명하는데 이렇게 하면 시간이 매우 오래걸리기 때문에 과정을 단축시켰다.

* 수학적 오류나 개선 피드백 지적은 언제나 환영합니다 댓글로 남겨주세요~

우분투를 포함한 리눅스 서버를 운영하면서 대부분 SSH를 설정해 원격에서 접속하거나 유지보수를 하게된다.

하지만 SSH를 열어두면 Brute-Force공격이 시도때도 없이 들어온다...

특히 중국쪽에서 SSH포트를 열면 한 10분도 안돼서 접속시도가 들어온다... 전체 아이피를 스캔하는 봇을 돌리는 것도 만만치 않을건데.. masscan와 비슷한 원리의 봇을 사용하는 듯하다..

우분투에서는 특정 IP만 SSH 접속이 가능하게 하려면 크게 2가지 방법이 있다.

첫번째는 /etc/hosts 파일을 이용하는 방법(TCP Wrapper) 과

두번째는 ufw같은 방화벽 유틸을 사용하는 것이다.

이번 포스트에서 다룰 방법은 전자다. 왜나하면 후자의 방법에 비해 훨씬 간단하고 기본적으로 설치된 소프트웨어를 사용해서 안정성있기 때문이다.

/etc/hosts.allow , deny파일을 통해 IP를 차단하는 것을 TCP Wrapper이라고 하는데

ssh뿐만 아니라 리눅스에서 돌아가는 모든 데몬에 대해서 설정이 가능하며 특징은 다음과 같다.

1. 별도의 패키지 설치가 필요없이 기본적으로 내장되 있다.

2. 기본적으로 TCP연결을 허용한다음 허용된 IP에 대해서만 response를 보낸다. ufw는 TCP ACK패킷 자체를 전송하지 않지만 TCP Wrapper는 TCP ACK패킷을 전송한다는 점에서 차이가 있다.

1. TCP Wrapper SSH 차단 방법

$ sudo vi /etc/hosts.deny

/etc폴더내 파일은 기본적으로 수정시 root 권한이 필요하므로 sudo를 통해 명령어를 실행한다.

우선 기본적으로 ssh 데몬(sshd)의 접근을 차단해주기 위해 다음과 같은 행을 추가한다.

sshd: ALL

**참고로 TCP Wrapper의 Priorty는 다음과 같다.

1. hosts.deny

2. hosts.allow

즉 차단 정책이 우선이므로 기본적으로 차단을 진행하는데 만약 IP가 allow에 존재한다면 예외적으로 접근을 허용하는 방식이다. 일반적인 방화벽 소프트웨어나 시스템과 다를 바 없다.

그다음 허용할 IP를 설정하기 위해 /etc/hosts.allow 파일을 수정한다.

$ sudo vi /etc/hosts.allow

그다음 허용할 IP를 설정하기 위해 다음과 같은 행을 추가한다.

sshd: IP주소
에를 들어 1.1.1.1를 추가하고자 한다면
sshd: 1.1.1.1

아주 간단하다, 그리고 IP가 여러개라면 ,(콤마)로 구별하거나 sshd: 행을 여러번 사용해도 된다.

만약에 IP대역을 입력하고 싶다면 CIDR형태로 입력해도 되고 뒷 부분을 그냥 쓰지 않고 .만 써도된다. 예시를 보여주자면 다음과 같다.

#1.1.1.1/24대역의 IP를 허용하고 싶을 때
sshd: 1.1.1.
또는
sshd: 1.1.1.1/24

#2.2.2.2/16 대역의 IP를 허용하고 싶을 때
sshd: 2.2.
또는 
sshd: 2.2.2.2/16

이처럼 CIDR로 써도되고 .으로 표시해도된다. 다만 추가하고자 하는 IP대역의 CIDR이 /24나 /16, /8이 아닌 /25,/27과 같은 형식이라면 .으로 표기하기는 어렵고 CIDR로 표기하면된다.

hosts.allow, hosts.deny 파일 수정을 마쳤으면 ssh데몬을 재시작한다.

$ sudo service sshd restart

그럼 정상적으로 특정IP만 ssh를 접속 가능하도록 허용하게 만드는데 성공한 것이다.

 사람들은 세상을 살아가며 다양한 종류의 물건과 서비스를 구입한다. 모든 물건과 서비스에는 결함인 하자가 있기마련이다. 새로 지어지는 “신축아파트”또한 다수의 하자가 존재한다. 대부분의 신축아파트에서는 한세대당 대략 50여개에서 70여개의 하자가 발견되는데 신축아파트에서 다수의 하자가 발견되는 것은 지극히 흔한 일이다. 그렇다면 신축아파트에서 다수의 하자가 발생하는 원인은 무엇일까?

 우선 신축아파트에서 다수의 하자가 발생하는 원인을 알아보기 위해서는 신축아파트의 건축과정을 알아야 한다. 아파트 건축과정에서 크게 사업주체인 “시행사”와 시공능력을 가지고 실제 시공을 실시하는 “시공사”로 크게 나누어 볼 수 있다. 시행사는 아파트 사업의 시행주체로 토지 매수,시공사 선정, 분양대행등의 업무를 실시하며 시공사는 아파트의 공사를 실시하는 시행사의 도급업체라고 볼 수 있다.

그리고 시행사와 시공사의 관계는 일의 완성을 부탁한자인 도급인과 일의 완성을 부탁받은자인 수급인의 관계와 동일하다고 할 수 있다. 따라서 시공사는 아파트 공사와 관련된 업무를 수행하고 시행사는 아파트 사업을 하고자하는 토지주로서의 업무를 수행한다.

  그렇다면 아파트 공사를 담당하는 시공사는 콘크리트 타설,전기공사,통신공사와 같은 모든 아파트 공사 업무를 직접 도맡아 하는것일까? 실상을 그렇지 않다. 시행사로부터 아파트 공사업무를 위탁받은 시공사는 건축 인-허가업무, 현장안전관리업무, 설계수정업무,관리감독의 업무를 주로 시행하며 경우에 따라서 직접 공사를 수행하는 부분도 있지만 대개의 경우 공사 분야의 전문공사업체의 각 부분의 공사를 재위탁하여 도급을 맡기게 된다. 이때의 아파트 시공사와 공사전문업체의 관계는 수급인과 도급인의 관계와 같다.

  일반적으로 아파트 시공사,시행사를 포함한 모든 기업은 이윤을 추구한다. 시공사는 높은 이윤을 추구하므로 시행사에서 지급받은 대금에서 높은 이윤을 남기기 위해서 각 부분별 공사를 시행할 각 분야의 공사전문업체들을 선정하는 과정에서 공사비용이 싸고 저렴한 업체를 주로 선정하게된다. 하지만 각 공사 전문업체또한 기업이며 이들도 이윤을 추구하기 한다. 이는 각 공사전문업체들이 값이 싼 전문지식이 없는 노동자를 고용하거나 불량자재를 사용하는것으로 이어지게 된다. 또, 각 공사전문업체들은 불법적으로 다시 다른 값이 싼 업체에 도급을 맡기는 불법하도급을 진행하기도 한다.

  이러한 이유로 아파트를 시공하는 과정에서 다수의 불량시공이 발생하게된다. 아파트 준공전에 시공사는 아파트 수분양자들을 상대로 사전점검행사를 진행하는데 이 과정에서 다수의 하자가 발생하며 언론이나 온라인 커뮤니티에서 논란이 되기도 한다. 하지만 위의 아파트 시공과정을 알고나면 하자가 발생하는 것은 전혀 이상하지 않다. 시공사는 아파트 준공 후 약 3년간의 하자보수책임을 가지게 된다. 따라서 시공사는 아파트에 AS센터를 설치하여 하자에 대한 보수를 하기위해 나름의 노력을 하고있다. 하지만 시공사와 전문시공업체들과의 갈등이나 분쟁이나 전문시공업체들간의 책임회피로 인해서 하자처리가 지연되거나 미흡하여 수분양자들이 피해를 보는경우도 증가하고있다.

  그렇다면 아파트 하자를 줄이려면 시공사는 어떠한 노력을 해야할까? 아파트 하자발생의 근본적인 원인은 시공사의 높은 이윤추구에서 비롯된다. 시공사는 아파트 하자발생률을 감소시키기 위해 기업의 높은 금전적 이윤보다 높은 서비스 품질을 통한 이익을 추구해야 할 것이며 정부는 아파트 시공사가 하자보수 책임기간인 3년이내에 제대로 하자에 대한 책임을 지고 적절한 보수를 할 수 있도록 관련 정책을 마련하여 책임을 회피하는 시공사들을 규제해야할 것이다.

https://v.daum.net/v/20231230180103299

12월 30일(어제)자 전자신문에 흥미로운 제목의 기사가 올라왔다. 

윈도우에서 글꼴을 바꾸고 확인하기 위해서 글꼴파일을 확인하면 항상 같은 확인문구인 "다람쥐 쳇바퀴에 파고파."라는 문구가 있는데 왜 그 문구를 사용했는지에 대해서 알아보는 신문 기사이다.

1990년 마이크로소프트는 윈도우 2.0때 글꼴기능을 출시했고 윈도우 3.1부터 기본기능으로 탑재하여 출시하기 시작했다고한다. 그리고 2009년 출시된 윈도우 비스타(Vista)의 글꼴파일에서 해당 문구를 확인할 수 있다고 한다.

그렇다면 왜 하필이면 "다람쥐 쳇바퀴에 파고파."라는 문구를 윈도우 글꼴파일의 확인문구로 채택하였을까?
나는 수능평가원에서 수능 시험지를 만들때 필적확인체를 시의 구절에서 인용하는것처럼 윈도우의 글꼴 확인문구도 마이크로소프트사가 한국의 아무 시의 구절을 인용한것이라고 생각했다.

하지만 기사에 따르면 윈도우가 해당 문구를 사용하게된 이유는 "팬그램"때문 이라고 한다.

팬그램이란 모든 글자를 최소 한번이상 사용하여 의미하고 짧게 나타난것일 수록 가치가 높다. 모든 글자를 최소 한번이상씩 사용했다는 점에서 글꼴이 글자를 어떻게 표현하는지 알아낼수 있기에 글꼴 예시등에 많이 사용된다고 한다.

근데 윈도우의 글꼴 예시 문구인 "다람쥐 쳇바퀴에 파고파."를 살펴보면 모든 자음과 모음이 포함되지 않았음을 확인할 수 있는데 이는 한글의 특성상 모든 문자를 활용하여 팬그램을 만들기는 어렵다고 한다. 그리고 애초에 팬그램 자체가 영어에 특화되어있다고 한다.

왜나하면 영어는 쉬운 알파벳 문자구조를 가지고 있기에 다른 언어에 비해서 비교적 쉽게 만들 수 있기 때문이라고 한다. 한글을 영어와 다르게 자음과 모음을 조합하여 여러개의 문자를 만들어 낼 수 있어서 모든 문자에 대하여 팬그램을 만들기에는 너무 긴 문구가 될거 같다. 영어는 팬그램의 종류가 다양하다는데 이는 비교적 문자 구조가 간단해서 여러 방식으로 조합해도 짧게 표현할 수 있기 때문인것 같다는 생각이 든다.