귀차니스트의 기록 블로그

[소프트웨어 마에스트로] 소프트웨어 마에스트로 15기 합격 후기

lecarap — Sat, 11 May 2024 20:30:56 +0900

합격 소감

1차 코테를 올솔하고 자신감에 찬 상태에서 본 2차 코테를 엄청나게 망쳐서 기대도 안했는데 어찌저찌 면접까지 치르고 합격했다. 솔직히 내가 잘했다기보단 운이 많이 따라주었던 것 같다.

개인 스펙

- 문사철 비전공자

- 대학교 4학년

- 삼성 소프트웨어 역량테스트 B형 취득

- 개인 프로젝트 1개 팀 프로젝트 1개 경험
- 수상 없음
- 자격증 없음

합격을 위한 조언들

다른 곳에서는 서류, 코테, 면접별로 카테고리를 나누어서 적어두었던 걸로 기억하는데 이미 많은 소마 합격자 분들이 잘 정리해서 후기를 올려주셨고, 앞으로도 그러할 것이기 때문에 여기서는 내가 다른 후기에서 인상적이었던 부분들이나 보지 못했던 것들에 대해 이야기 해보고자 한다. (물론 대외비 언급 금지에 저촉되는 부분은 배제할 것이다.)

소마는 창업뿐만 아니라 소프트웨어 개발자로서 성장하는 장을 만들어주는 곳이다.

이전 기수 합격 후기들을 보았을 때 창업할 생각이 있든 없든 자소서에서든 면접에서든 창업할 의지를 어필하라는 조언이 은근 많았던 것 같다. 하지만 필자는 소마에서 창업을 할 생각이 정말 단 하나도 없었기 때문에 창업에 관한 내용을 자소서에 써야되나 싶었다.

찾아보면 그렇지 않아도 합격한 후기도 있었기 때문에 뛰어난 연수생들과 네트워킹하면서 개발비 지원을 통해 내가 하고 싶은 개발해보면서 실사용자도 유치해보고 유지보수하는 경험을 통해 SW 개발 능력을 향상시키겠다는 취지의 내용을 썼고 합격했다. 사실 들어오고 나서 알게 된 거지만 상술한 바가 소마에서 긍정적으로 보는 지원 동기인 것 같다.

코테는 섭태 긁기 + 브루트 포스도 꽤나 유효하다.

이 부분은 딱히 멘토님들에게 직접 들은 건 아닌데, 여러 후기나 연수생분들의 이야기를 참고하자면 일단 무지성 완탐으로라도 돌려서 제출하면 나름 점수를 얻는 것 같았다.

작년에 필자가 2차 코테에서 시간 복잡도 분석하고 정해 찾는 데에 시간 쏟느라 문제를 별로 못풀어서 불합격 했는데, 올해는 작년만큼이나 못풀었음에도 불구하고 불완전한 풀이라도 제출했던 게 유효했던 것 같다. (올해 문제가 예년에 비해 많이 어려웠기 때문에 다 같이 망해서 그런 것 같기도..)

합격 난이도는 코테>>개발이지만 일단 개발 경험도 필요하다.

개인적으로 올해 소마 코테는 웬만한 대기업 코테보다 어려웠다고 생각한다. 따라서 생각보다 합격에서 코테의 비중이 크다. 하지만 소마는 일단 개발이 가능한 사람을 뽑기 때문에 최소한의 개발 경험을 쌓아보는 게 좋다. 일단 코테만 뚫으면 경쟁률이 2:1 이하로 떨어지기 때문에 생각보다 대단한 개발 능력을 요구받진 않는다. 빠르게 간단한 서비스 만들고 배포라도 해보자.

실제로 팀원 중 한 명이 알고리즘 동아리와 개발 동아리를 하고 있어서 동아리원들의 소마 승률에 대해 말해준 적이 있었는데, 개발 동아리에선 코테에서 다 떨어졌고, 알고리즘 동아리에선 개발 경험이 없어서 본인을 제외하면 전부 면접에서 떨어졌다고 한다 ㅋㅋㅋ

모르는 건 모른다고 하자

기업 면접에서도 마찬가지지만 잘 모르는 주제에 대해 틀린 내용을 자신있게 답하거나 얼버무리면 오히려 메타인지 능력이 떨어진다고 판단되어 평가가 크게 깎이게 된다.질문 내용에 대해 잘 모르면 솔직하게 모른다고 하거나, 잘 모르지만 추론 해봤을 때 ~~인 것같다. 정도로 대답하는 정도가 좋다고 생각된다.

자소서도 의외로 중요하다.

자세한 내용은 대외비인지 아닌지 몰라서 이야기 하긴 어렵지만 모든 면접자가 동일한 면접관들과 면접을 진행하는 건 아니다. 소문으로는 각 면접자들이 자소서에 쓴 내용들을 바탕으로 면접관들이나 면접 질문의 성격(인성 중심, 기술 중심 등)이 달라진다는 말도 있는데, 연수생분들과 이야기 한 바로는 얼추 맞는 것 같기도 하다.

따라서 최대한 본인이 어필할 수 있는 부분을 중점적으로 자소서에 적고 이걸 바탕으로 면접을 이끌어나가는 게 좋다. 좀 더 자세히 말하자면 본인이 잘하거나 어필할 수 있는 부분에 대해 면접관들이 궁금해할만한 떡밥을 자소서에 써놓는 게 좋아보인다.

포트폴리오는 최대한 잘 아는 부분을 물어볼 수 있도록 유도하는 게 중요하다

이건 기업에 지원할 때도 마찬가지인 말이지만, 괜히 삐까뻔적한 기술 한 번 써봤다고 잘 알지도 못하는 기술을 포트폴리오에서 사용할 줄 안다고 적어버리면 그 부분에 대해 꼬리 질문이 엄청나게 들어올 것이다. 일단 자기가 프로젝트를 하면서 정말 이 부분에 대해선 꼬리 질문이 들어와도 그럭저럭 대답할만할 정도로 아는(혹은 면접 때까지 공부해갈 수 있는) 기술을 중심으로 적는 게 좋다.

그리고 정말 기본적이라고 생각되는 기술이라도 그 원리에 대해 깊게 공부해보고 프로젝트를 할 때 왜 그 기술을 써야만 했는지, 다른 기술에 비해 어떤 이점이 있기에 그 기술을 사용했는지, 기술적인 트레이드 오프에 대한 고민을 정리해보면 좋다.

맺음말

이 글을 5월 11일 즈음에 초안 정도만 써놓고 2달 정도 묵혀두고 2달이 넘게 지난 7월 즈음에 다 쓰게 됐다. 솔직히 소마에서 와서 개발만 공부할 줄 알았는데, 정작 그것보단 문제를 발견하고, 정의하는 사고방식과 팀으로 효율적으로 일하려면 어떻게 해야하는지에 대해 가장 많이 고민한 것 같다. 근데 신기하게도 이전보다 개발 공부가 훨씬 쉬워진 것 같은 느낌이 든다. 자신이 사용하고 있는 기술에 대해 깊게 공부하는 것도 중요하지만 근본적으로 그것이 왜 쓰이고 그래서 현재 내 문제를 해결하기 위해 어떻게 적용할 수 있을지 고민하는 과정은 분야를 막론하고 도움이 되는 것 같다.

[모의면접 CS 스터디] 네트워크 스터디 회고

lecarap — Tue, 13 Feb 2024 17:46:27 +0900

스터디에 지원한 동기

https://www.youtube.com/live/FqN8UA7rmQc?si=VStheH6ER-aPbsLq

필자는 원래 위 영상의 칼춤? 스터디에 영감을 얻어서 특정 주제나 키워드를 중심으로 CS 지식에 대해 공부하는 스터디를 만들고자 하였는데, 영상에도 나와 있듯이 이런 방식의 스터디는 내가 아무리 열심히 해도 스터디원들이 열정이 따라주지 않으면 의미가 없기 때문에 운이 따라주지 않으면 운영되기 어렵겠다는 생각을 했었다. 그러던 중 에브리타임 홍보글을 보다가 우연히 모의 면접 CS 스터디에 대한 홍보글을 보게 되었다. 비용이 다소 부담스럽긴 했지만 면접에 주로 나오는 키워드를 중심으로 공부하여 정리하고, 다른 사람들과 모의 면접을 바탕으로 설명한다는 점에서 원래 생각했던 스터디 방식과 일맥상통한다고 생각했다. 더욱이 매번 팀원이 바뀌고 같은 조로 배정된 사람이 스터디를 참석하지 않아도 일단 참석한 다른 스터디원과 매칭되기 때문에 스터디 자체는 계속할 수 있다는 점에서 운 적인 요소에 덜 기대도 된다는 점이 좋았기 때문에 스터디에 참여하였다.

본 스터디는 운영체제, 네트워크, 데이터 베이스 세 가지 과목을 베이스로 각각 따로 운영된다. 이중에서 필자가 네트워크를 선택한 것은 네트워크에 대한 지식이 가장 부족하다고 느꼈기 때문이다. 이를테면 데이터 베이스는 SQL이나 ORM, 트랜잭션에 관한 문제를 다루다 보니 자연스럽게 궁금증이 생겨서 공부하게 되는 경우가 많았고, 운영체제는 논블락 IO나 블락 IO, 비동기 처리를 통한 속도 향상 등 여러모로 흥미가 생길 요소가 많아 어느 정도 공부를 하긴 하지만 네트워크는 관련 문제를 경험한 적이 적었기 때문에 지식적으로 많이 부족했고, 따라서 이를 보충하고자 본 스터디에 참여하게 되었다.

스터디를 진행하면서 찾았던 공부 방법

흔히 CS 지식은 암기라고는 하지만 필자는 특정 지식에 대해 흥미를 느끼거나 필요성이 생기지 않으면 공부 의욕이 잘 나지 않는 편이라서, 이게 왜 필요한지를 시작으로 하여 하나씩 파고드는 방식을 공부하였다. 사실 예전엔 이런 방법을 고수하는 게 맞나 싶긴 했는데 우테코 프리코스를 하면서 읽은 블로그 포스트 덕분에 나름 확신을 가지고 이 방법대로 밀고 나가고 있다.(단순 암기로 CS 지식을 공부하고 있다면 꼭 한 번 읽어보기를 권장한다.) 다만 이번 스터디를 하면서 필자가 엄청 재밌다고 느낀 공부법이 있는데 바로 ChatGPT를 이용해서 내가 이해한 게 맞는지 지속적으로 묻는 소크라테스 공부법이다.

실제로 내가 gpt와 했던 대화 내용이다.

필자는 공부하면서 먼저 면접 질문에 나와 있는 키워드들을 GPT에게 질문하면서 또 다른 공부할만한 키워드를 얻거나 아니면 내가 이해한 내용들을 연결하면서 이게 맞는지 물어보는 방식으로 피드백을 받으며 공부했다. 물론 GPT의 환각 문제 때문에 답변 내용에 오류가 있을 수 있기 때문에 인터넷을 찾아보면서 교차 검증하면서 진행하였다. 다만 스터디 피드백에도 나와있듯이 시간은 유한하기 때문에 너무 과도하게 파다보니 다른 공부를 할 시간이 줄어들어서, 첫 주차 이후로는 적절한 깊이를 유지하면서 공부를 했다.

블로그 작성 과제에 대해

스터디에선 각 주차마다 면접 질문에 나온 내용들을 바탕으로 공부하여 블로그 포스트를 작성하는 과제가 있다.

필자는 블로그에 다른 출처에서 가져온 내용을 그대로 사용하거나, 나의 관점을 담지 않은 채 그냥 A는 B다라는 식의 글을 작성하는 걸 최대한 지양하는 편인데 왜냐하면 어차피 그런 내용은 이미 인터넷 상에 널려있고 낙서들 속에 양질의 글들이 파묻히는 데에 기여하는 걸 자제하고 싶었기 때문이다. 따라서 구태의연한 내용을 최대한 배제하고 작성하려고 노력했는데, 모든 내용에 대해 이걸 계속하는 건 시간적으로 불가능하겠다 싶어서, 나중에는 기본적인 내용 정리는 노션에 작성하였다.

스터디를 진행하면서 피드백 받은 나의 장점과 문제점

1. 장점

지식을 단순히 암기하기보다는 왜 필요한지 생각해보고 각 내용을 연결하여 장점과 단점을 생각하는 점이 좋았다.
기계적으로 답변한다기보다는 자신의 언어로 면접관과 대화하는 느낌으로 접근하는 점이 좋았다.

2. 문제점

예상치 못한 질문을 받았을 때 횡설수설하는 느낌이 있다.
말을 할 때 좀 더 언어를 정돈하고 두괄식으로 질문에 답하는 게 좋을듯 싶다.
생각할 때 눈을 위로 향하는 제스처를 자주 취하는 게 보인다.

스터디에 대해 느낀 장점과 아쉬웠던 점

1. 장점

앞서 말했듯이 사람이 빠져도 일단 스터디를 계속할 수 있음.
중간 중간 현업에 종사하시는 멘토님들이 들어오셔서 조언 해주시거나 질문을 받아주심.
실제 현업에서 종사하시는 분들이 바라보는 신입에게 요구하는 CS 지식의 수준이 어느 정도인지 대략적으로 알 수 있음.
면접 스터디는 매번 같은 사람과 진행하면 시간이 지날수록 긴장감이 떨어진다는 단점이 있는데, 매번 팀원이 바뀌기 때문에 이러한 측면에서 보완이 되었음.

2. 아쉬웠던 점

스터디의 특성상 어쩔 수 없지만 같은 팀으로 배정된 사람이 준비를 제대로 해오지 않는 경우 다소 의욕이 떨어짐.
Q&A 카톡방에 공지도 함께 올라오는데 이게 질문 내용과 섞이다보니 나중에 공지 내용을 다시 찾기가 곤란했음.

스터디를 통해 얻은 것

단순히 네트워크에 관한 지식을 습득한 것 외에도 스터디를 진행하면서 다른 사람의 입장에서 나의 문제점을 파악할 수 있었고, 또한 각 주차 시작마다 담당 멘토님의 주차별 피드백을 통해 면접에 대해 어떻게 접근하면 좋을지 배울 수 있었던 것 같다.

[모의 면접 CS 스터디] CORS, SOP

lecarap — Wed, 24 Jan 2024 22:00:45 +0900

이 글에서는 CORS와 SOP에 대한 상세한 내용은 다루지 않고 CORS와 SOP를 사용하는 이유에 대해서 주로 살펴볼 겁니다. 자세한 내용을 원하시는 분은 이 글을 참조해주세요

CORS(Cross-Origin Resource Sharing)

CORS란 무엇인가?

CORS란 간단히 말해서 서로 다른 출처(Origin)를 가지는 클라이언트와 서버 간의 데이터 요청과 응답이 이루어지는 것을 말한다. 그렇다면 서로 다른 출처는 무엇을 뜻할까? 도메인의 구조를 보았을 때

protocl에서부터 host 그리고 여기에 더해 포트 번호가 다르면 서로 다른 출처라고 간주한다.

이를테면 www.example1.com에서 www.example2.com로 요청하거나 www.exmaple1.com:8080에서 www.example1.com:8000으로 요청하는 걸 말한다.

CORS를 왜 기본적으로 지원하지 않는 것일까?

개발하다보면 프론트 측에서 CORS 이슈로 인해 외부 API를 요청하지 못한다거나 아니면 프론트와 백엔드 서버의 포트번호가 다른 경우 CORS 이슈가 발생하는 경우를 종종 볼 수 있다. 이런 경우 보통 서버 측에서 응답 헤더에 Access-Controll-Allow-Origin이나 Access-Controll-Allow-Credentials 등의 내용을 추가하면 해결이 된다. 하지만 굳이 왜 이런 번거로운 과정을 거쳐서까지 CORS를 막는 걸까? 결론부터 말하면 보안 문제 때문이다. 이에 대해서는 SOP에 대한 배경지식이 필요하다.

SOP(Same-Origin Policy)

SOP란 무엇인가?

SOP이란 웹 페이지가 동일한 origin을 가지는 서버에 대한 응답에 접근할 수 있는 정책을 의미한다. 이러한 정책이 나온 이유는 한 출처가 다른 출처의 리소스에 접근하지 못하게 하기 위함이다. 본 정책에 따라서 다른 악성 웹 사이트에서 악의적인 스크립트를 이용해 서버에 요청을 보내도 서버의 응답이 돌아와도 웹브라우저에 의해 차단되어 내용을 보진 못한다. CORS란 이러한 SOP 정책에 대한 예외사항이라고 볼 수 있다.

SOP의 보안적 허점과 이점

SOP은 어디까지나 응답을 막을 뿐이다.

다만 유심히 봐야될 점은 SOP는 어디까지나 서버의 응답을 못 읽게 한다는 것이다.

이를테면 사용자가 현재 은행 사이트 A의 로그인 되어 있는 상태이고 그런 도중 어떠한 악성 사이트 B에 접근하게 되었다고 가정하자. 이 때 모든 웹브라우저의 웹페이지는 요청 시 쿠키를 공유하기 때문에 B가 다른 웹 페이지의 쿠키에 접근을 하지 못하든 상관없이 B의 요청이 A 사이트의 서버로 전달되어 쿠키에 담긴 세션이나 토큰을 통해 인증이 되어 B의 요청이 그대로 받아들여질 수 있다는 점이다. 이러면 B가 응답을 보진 못하겠지만 어쨌든 원하는 요청을 보내는 건 가능하다.

그래서 흔히 SOP 정책이 CSRF 공격을 방지하기 위해 나왔다는 말이 있지만 근본적으로 SOP는 브라우저 측에서 서버의 응답을 못 보게 할뿐이지 악의적인 요청을 방지하진 못한다.

그렇다면 SOP가 완전히 보안적으로 무용한가? 그렇진 않다. 적어도 다른 출처의 웹 페이지가 보안에 활용되는 여러 정보들에 접근하는 것은 방지할 수 있다.

pre-flight request

그리고 매우 특수한 경우를 제외하면 대다수의 경우 브라우저 측에서 Pre-flight request를 보내어 CORS 여부를 체크하기 때문에 이러한 공격을 예방할 수 있다. 위 그림에서 본 요청만 보내서 다른 출처임을 파악하지 않는다면 브라우저 측이 요청을 받든 안 받든 내 계좌에서 돈이 빠져나가겠지만 예비 요청 덕분에 이를 방지할 수 있는 것이다.

출처:

csrf - Is CORS helping in anyway against Cross-Site Forgery? - Information Security Stack Exchange

[10분 테코톡] 나봄의 CORS - YouTube

CORS는 왜 이렇게 우리를 힘들게 하는걸까? | Evans Library

Same-origin policy - Wikipedia

[모의 면접 CS 스터디] 세션, 쿠키, jwt

lecarap — Mon, 22 Jan 2024 18:59:30 +0900

쿠키(Cookie)

쿠키란 무엇이고 왜 사용하는 것일까?

브라우저와 서버 간 데이터 전송에 사용되는 HTTP는 이전 요청에 대한 정보를 저장해둘 수 없는 특징을 가지기 때문에 각 클라이언트를 식별하지 않는다. 하지만 현대 웹 어플리케이션에서는 여러 복잡한 기능을 구현하거나 편의성을 위해 서버에게 웹 브라우저를 개별적으로 식별할 수 있게 만들 필요가 있다. (그렇지 않으면 정말 끔직하게도 매번 사이트에서 페이지를 이동할 때마다 다시 로그인 해야 될 것이다. )

따라서 서버는 웹브라우저에게 쿠키라는 것을 전달하여 매 요청마다 쿠키를 통해 브라우저에 대한 정보를 제공도록 만들어 이러한 문제를 해결할 수 있다. 즉 쿠키란 서버에서 클라이언트를 식별하는 데에 사용되는 정보를, key-value 형태로 브라우저에 저장한 것이라고 할 수 있다.

종류

세션 쿠키(session cookie): 웹사이트에 방문하였을 때 일시적으로 생성되는 쿠키이다. 브라우저를 닫으면 삭제되며 로그인된 유저의 인증이나, 쇼핑 카트를 저장할 때 사용된다.
영구 쿠키(persistent cookie): 사용자가 웹사이트에 처음 접속할 때 생성되며 특정한 만료 기간까지 계속 브라우저에 저장되는 쿠키이다. 일반적으로 유저의 언어 설정이나 유저의 웹사이트 활동을 추적하여 맞춤 광고를 제공하는 데에 사용된다.

세션(Session)

쿠키를 통한 유저 인증 시 문제점

웹사이트는 쿠키를 이용해서 어떻게 로그인된 유저를 식별할 수 있을까? 가장 간단하게 생각할 수 있는 건 쿠키 자체에 아이디, 패스워드를 저장하는 것이다. 하지만 쿠키는 웹브라우저에 보관되어있기 때문에 유저가 쉽게 해당 정보를 수정할 수 있고 XSS나 CSRF 공격등으로 해커에게 손쉽게 탈취될 수 있다. 이러한 쿠키의 보안 문제 때문에 서버 측에서 사용자에 대한 인증 정보를 저장하는데 이게 바로 세션 ID라는 것이고 이러한 인증방식을 세션 기반 인증방식이라고 한다.

세션의 개념적 정의?

In the context of web development, a session refers to a way of maintaining state information about a user’s interactions with a website or web application. When a user visits a website, the server can create a session for that user. Additionally, a session allows the server to keep track of information such as the user’s login status, preferences, and any data entered into forms.

(웹 개발의 관점에서 세션이란 유저와 웹 사이트 간의 상호 작용에 대해 상태 정보를 관리하는 수단을 의미한다. 유저가 웹사이트를 방문할 때 서버는 그 유저에 대한 세션을 만들 수 있다. 또한 세션을 통해 서버는 사용자의 로그인 상태, 기본 설정, 폼에 입력된 모든 데이터 등의 정보를 추적할 수 있다.)

A web session is a period of interaction between a user and a website. Furthermore, the website maintains state information about the user’s actions and preferences during a session. The server can initiate a session for a user when they browse through a website. The session remains active until the user logs out.

(웹 세션이란 사용자와 웹사이트 간의 상호 작용하는 기간이다. 또한 웹사이트는 세션 동안 사용자의 행동과 기본 설정에 대한 상태 정보를 유지한다. 서버는 사용자가 웹사이트를 브라우징할 때 해당 사용에대한 세션을 시작할 수 있다. 세션은 사용자가 로그아웃할 때까지 활성 상태로 유지된다.)

여러 정보를 찾다 보니 세션이라는 용어가 다양한 의미로 사용되는 것 같아서 개념적 정의 비슷한 걸 찾아보았다. 쿠키와 세션을 한 묶음으로 사용할 때의 세션은 서버 측에 저장된 유저의 정보를 의미하는듯 하고, 혹은 유저와 웹 사이트 간의 상호 작용이 이루어지는 기간이라고 할 수 있을듯 싶다.

동작 과정

1) 웹 브라우저가 ID와 패스워드를 보내어 서버로부터 인증을 받는다.(HTTPS로 이루어진다면 탈취당할 걱정은 덜 수 있을 것이다.)

2) 서버는 인증된 사용자임을 확인하고 고유성과 무작위성을 가진 세션 ID를 생성한 뒤 해당 유저에 대한 정보와 함께 세션 저장소(DB, 파일 시스템 등)에 저장하고, 또한 response 메세지의 Set-Cookie 헤더에 세션 ID를 두어 브라우저에게 전달한다.

3) 브라우저는 매 요청마다 세션 ID가 저장된 쿠키를 헤더에 담아 보내고 서버 측에서 세션 저장소를 확인하여 해당 세션 ID가 있다면 가능한 리소스에 대한 인가를 받는다.

4) 세션 쿠키에 세션 id가 저장되어 있으면 브라우저가 닫히는 순간 해당 쿠키는 폐기되고, 영구 쿠키에 저장되어있을 경우 만료 기간 동안까지만 저장된다.서버 측의 세션 ID는 만료기간까지 재사용되고 혹은 유저가 다시 로그인할 경우 다시 생성한다.

이점

위 동작 과정을 살펴보면 브라우저의 쿠키에도 세션 ID가 저장된다는 것을 알 수 있을텐데, 이는 여전히 인증에 필요한 정보가 해커에게 털릴 가능성이 높다는 것을 의미한다. HttpOnly나 Secure 등의 설정을 통해 이를 방지할 수 있긴 하지만 세션 하이재킹 등 여전히 탈취 가능성은 존재한다. 그렇다면 어떤 이점 때문에 세션 기반 인증 방식을 사용하는 것일까?

세션 ID는 무작위적으로 생성 가능하기에 설령 해커에게 탈취 당한다고 하더라도 폐기하여 다시 만들 수 있기 때문이다. 다만 해커 측에서 세션 저장소 등을 공격하여 정보를 탈취했으면 모를까 클라이언트 측에서 세션 ID를 탈취당했는지 서버에서 감지하는 것은 쉽지 않을 것이다. 따라서 이를 위한 수단을 마련하고 세션 ID의 만료 기간을 적절하게 설정하는 것이 중요할듯 싶다.

문제점

세션 기반 인증의 문제점은 유저의 세션 ID를 서버 측에서 저장해야 한다는 데에 있다. 로그인 유저의 수가 많아지면 세션 ID를 매 요청마다 확인하기 때문에 I/O 요청이 빈번히 발생하여 서버 측의 데이터 리소스 사용량이 높아진다는 문제가 있다. 또한 늘어난 트래픽에 대응하여 서버 인스턴스를 늘린다고 하였을 때 각 인스턴스 간의 세션 ID를 동기화 시키는 데에 비용이 든다.(이에 대한 자세한 내용은 이 글을 참고) 이러한 문제를 해결하기 위해 등장한 것이 토큰 기반 인증 방식이며 현재 웹개발에서 자주 사용되는 토큰이 바로 JWT이다.

JWT

토큰 기반 인증 방식은 세션 인증 방식에 비해 어떤 이점이 있나?

토큰 인증 방식은 세션 인증 방식과 다르게 사용자의 인증 정보를 서버가 관리하지 않고 브라우저가 관리한다. 따라서 사용자가 늘어나도 세션을 관리할 필요가 없기 때문에 서비스의 부담이 줄어들고 세션 동기화 때문에 골머리를 앓을 필요가 없다.

그런데 쿠키의 사례를 보면 인증 정보를 클라이언트가 온전히 클라이언트가 관리하는 건 위험한 거 아닌가하는 의문이 든다. 물론 세션을 통해 관리하는 것보단 다소 취약할 수 있지만 JWT의 특징을 살펴보면 그 이점을 알 수 있다.

JWT의 발급과정에서 서버는 사용자가 로그인을 통해 인증을 완료하면 JWT header, payload, signature 세 부분으로 나누어진 JWT 토큰을 발행한다. signature가 바로 JWT 보안의 핵심이다. signature는 비대칭키 방식을 사용하여 서버가 자신이 가진 비밀키를 이용해서 header와 payload를 합쳐서 만든 것이다. 서버는 추후 보낸 사용자의 토큰의 header와 payload를 비밀키로 암호화하여 signature로 다시 만들고 토큰의 signature와 비교하여 위조 여부를 판별하고 맞으면 사용자에게 데이터에 대한 접근 권한을 인가해준다.

여기서 약간 의아할만한 부분은 signature를 마음껏 복호화 가능한데 보안성 있는 인증을 가능하게 하냐는 점인데 이 signature를 암호화 할 수 있는 키가 서버가 가진 비밀키뿐이기 때문이다. 만약 다른 사람이 관리자 권한에 접근하기 위해서 payload를 수정하더라도 이를 다시 암호화 하려면 서버의 비밀키가 필요하기 때문에 비밀키를 알지 못하면 JWT 토큰을 변조하는 건 불가능하다.

확장성 측면에서의 이점

그리고 여기서 생각할 수 있는 또 하나의 장점은 비밀키를 이용해서 유효성을 판별할 필요 없이 공개키로도 충분히 토큰의 유효성을 알 수 있다는 것이다. 왜냐하면 비대칭키의 특성상 signature를 공개키로 해독하고 header와 payload와 비교해서 유효성을 검증할 수 있기 때문이다. 따라서 다른 서비스에서도 서버가 발급한 공개키를 이용해 유효성을 검증할 수 있기 때문에 보다 어플리케이션의 확장성을 높일 수 있다.

예를 들어 소셜 로그인 서비스 A가 인증 주체이고 이때 다른 서비스 B는 사용자의 인증을 A를 통해 한다고 가정하자.이 때 세션 방식을 사용한다면 사용자의 유효성을 검증하기 위해 B는 매번 서비스 A에게 인증을 요청해야 하고 이는 B 입장에서도 A 입장에서도 좋지 않을 것이다.

먼저 A는 자신의 서비스를 운용하는 데에도 세션을 사용할텐데 여기에 다른 서비스의 인증을 위해서 세션 DB에 접근 하면 엄청난 부하가 걸릴 것이기 때문이다. 이는 소셜 로그인 서비스를 이용하는 서비스가 많아질수록 더욱 더 심해질 것이다.

한편 B 입장에서는 A에게 인증을 의존하고 있기 때문에 만약 A에 문제가 생기면 B 또한 정상적인 서비스를 할 수 없게 될 것이다.

하지만 토큰 방식을 사용한다면 이야기는 달라진다. A는 그저 사용자에게 토큰을 발급하면 되고 사용자는 B에 접근할 때마다 A에서 발급해준 토큰을 사용하면 된다. B는 A에 요청할 필요없이 그냥 공개키를 이용해서 토큰을 검증하면 된다.

토큰 인증 방식의 문제점

JWT 토큰은 세션 ID에 비해 많은 내용을 담고 있기 때문에 오버헤드가 크다. 그리고 세션 ID와 마찬가지로 해커가 사용자의 토큰이 탈취하면 해당 사용자인 척 위장할 수 있다는 문제점은 동일하다.

따라서 서버 측에서는 Access token(인증시 사용하는 토큰)의 발급과 더불어 Refresh token을 클라이언트에게 발급해주는데, 토큰의 만료기간이 지나면 클라이언트 측이 보낸 Refresh token의 유효성을 검증한 뒤 새로운 Access token을 발급한다. 문제는 Refresh token까지 탈취 당하면 답이 없다는 거다. 보통 Access Token이 자주 탈취 당하기 때문에 만료 기간을 짧게 잡고 Refresh token은 길게 잡는데 이 때 서버 입장에선 매우 오랫동안 해커가 마음껏 로그인 하는 걸 막을 수 없다.

따라서 Refresh token을 DB에 저장하고 이에 더해 사용자가 로그아웃 하면 Access token을 만료시키는 등의 방법으로 이 를 막아야하는데 이러면 결국 사용자가 어떤 Access token을 들고 있는지 식별해야 하기 때문에 세션 인증 방식과 비슷하게 stateful한 방식이 되어버린다.

하지만 그럼에도 위에서 말했듯이 JWT만으로도 인증이 가능하다는 특성 덕에 확장성이 좋기 때문에 여러 서비스가 분산된 마이크로 서비스 아키텍쳐에선 좋다고 한다.

참고자료

세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)

쿠키와 세션 (ft. HTTP의 비연결성과 비상태성)

What Are Sessions? How Do They Work? | Baeldung on Computer Science

JWT(Json Web Token) 알아가기

JWT (Json Web Token)와 비대칭키

[모의 면접 CS 스터디] HTTPS

lecarap — Thu, 18 Jan 2024 14:17:38 +0900

HTTPS란

HTTPS란 HyperText Transfer Protocol(HTTP) Security란 약자에서부터 알 수 있듯이 기본적으로 HTTP와 동일하지만 암호화 과정을 더 추가한 것이라고 볼 수 있다.

HTTP와 HTTPS는 무엇이 다른가?

HTTP는 클라이언트와 서버가 메시지를 주고 받을 때 그 내용을 암호화 하지 않는데, 둘 사이에 보안적으로 민감한 정보, 이를테면 웹사이트의 아이디와 비밀번호 등이 전달되었을 때 다른 사람이 쉽게 그 내용을 파악하거나 변조할 수 있다.

그러므로 이러한 문제를 예방하고자 등장한 것이 SSL(Socket Security Layer)이란 암호화 프로토콜이고, SSL의 최신 버전을 TLS(Transport Layer Security)라고 부른다. HTTPS란 기본적으로 어플리케이션 계층에선 이전처럼 HTTP를 사용하되 전송 계층에 TLS 암호화 프로토콜을 추가한 것이라 볼 수 있다.

HTTPS의 암호화 방식

그럼 HTTPS는 구체적으로 어떤 방법을 이용해서 데이터를 암호화 하는 것일까 서버와 클라이언트는 서로 세션 키(session key)라는 것을 이용해서 각각 메시지를 암호화 하여 상대방에게 보내고 키를 통해 복호화한다. HTTPS의 암호화 방식을 이해하기 위해선 먼저 대칭키 암호화 방식과 비대칭키 암호화 방식에 대해 살펴볼 필요가 있다.

대칭키 암호화 방식과 비대칭키 암호화 방식

1) 대칭키 암호화

대칭키 암호화란 암호화와 복호화에 사용되는 키가 동일한 방식을 뜻한다.

이를테면 A라는 데이터를 클라이언트의 대칭키로 암호화면 서버가 그 암호화된 데이터를 다시 대칭키로 복호화하여 원래의 데이터를 볼 수 있게 되는 것이다. 다만 키가 노출되면 암호화든 복호화를 자유자재로 할 수 있기 때문에 키가 외부에 노출되지 않는 것이 매우 중요하다.

그렇다면 서버와 클라이언트 모두 동일한 키를 가지기 위해선 키 교환 과정을 거쳐야 하는데, 이 과정에서 대칭키를 안전하게 교환하는 방법은 무엇일까? 여기에는 여러 방법이 있을 수 있겠지만 HTTPS에서는 비대칭키 방식을 이용해서 키 교환을 한다.

2) 비대칭키 암호화

비대칭키 암호화 방식이란 암호화와 복호화에 사용되는 키가 다른 것을 의미한다. 더 정확히 말해서 키 A, B가 있을 때 A로 데이터를 암호화하면 B로 복호화할 수 있고 반대 B로 데이터를 암호화하면 A로 복호화 가능하다.

이러한 특성 덕분에 A가 다른 사람들에게 노출된다고 해도 A로 암호화한 데이터는 B로만 복호화할 수 있기 때문에 키 교환 이 간편하다는 장점이 있다.

-키 교환 방식 ex)

1) A가 비밀키와 공캐키를 생성하여 자신의 공개키를 B에게 보낸다.

2) B는 A의 공개키를 받고 비밀키와 공캐키를 생성하여 다시 A에게 자신의 공개키를 보낸다.

따라서

A가 가지는 키: A의 비밀키, B의 공개키

B가 가지는 키: B의 비밀키, A의 공개키

이렇게 하면 한 쪽이 상대방의 공개키로 정보를 암호화하여 보내고, 다른 한쪽은 자신의 비밀키를 이용해서 그 내용을 복호화하면 된다.

비밀키와 공개키는 서로 데이터를 암호화, 복호화 할 수 있기 때문에 반대로 비밀키로 데이터를 암호화-> 공개키로 복호화 하는 방식도 가능하다. 데이터의 암호화를 공개되지 않은 비밀키로 하기 때문에(암호화를 아무나 할 수 없기 때문에) 해당 데이터를 보낸 주체가 유효한지 판단하는 데에 사용된다.

비대칭키 방식은 위와 같이 키 교환 과정에서 다른 사람에게 키가 노출되도 보안적인 부담이 없다는 장점이 있다.

다만 대칭키 방식에 비해 암호화키 생성 과정이 복잡하고, 암호화, 복호화 속도가 느리다는 문제가 있다.

따라서 HTTPS에서는 처음 대칭키를 교환할 때 보안을 위해 이 방식을 사용하고 이후에는 주로 대칭키 방식을 사용한다.

SSL/TLS Handshake

SSL 혹은 TLS 핸드 셰이크란 HTTPS에서 TCP 3-way-handshake를 통해 서버와 클라이언트 간의 연결이 설정된 이후에 암호화 방식 결정, 데이터 암호화를 위한 키 교환 등을 통해 데이터를 암호화하는 데에 필요한 것을 합의해나가는 과정이다.

핸드 셰이크 동작과정

1) Client Hello

클라이언트는 서버에게 다음과 같은 정보를 전달한다.

자신이 사용하는 TLS 버전
적용 가능한 암호화 방식(ciper suite)
세션 id

2) Server Hello

서버는 클라이언트가 보여준 TLS 버전과 암호화 방식을 보고 암호화 과정을 어떻게 진행할지 결정하고 이를 클라이언트에게 통보한다. 따라서 지금부터는 TLS의 핸드 셰이크 동작 과정은 버전 및 암호화 방식에 따라 조금씩 차이가 있다고 한다. 여기서는 필자가 생각하기에 좀 더 단순해 보이는 과정을 선택했다.

3) Certificate

서버는 다음과 같은 정보를 클라이언트에게 보낸다.

SSL 인증서( CA에서 발급한 전자서명과 서버의 인증서 내용 등이 포함됨)
서버의 공개키(보통 인증서에 포함됨, 포함되지 않을 경우 바로 Server Key Exchange 과정에서 전송)

여기서 SSL 인증서는 CA( Certificate Authorize)라는 제 3의 인증기관으로부터 발급되는데 이는 해당 서버가 유효함을 인증하는 데에 사용된다.

좀 더 자세하게 말하자면 SSL 인증서 내에는 전자서명이 있는데 이는 인증서의 내용을 해쉬함수를 통해 암호화한 뒤 CA에서 발급한 비밀키로 암호화된 것이다. 클라이언트는 여러 CA에서 공개키 목록을 가지고 있어서 여기서 공개키를 찾은 뒤 복호화하여 서버의 인증서의 해쉬값과 같으면 유효하다는 판단을 내린다. (해쉬함수는 인풋과 아웃풋의 규칙성이 없기 때문에 공격자 입장에서는 평문과 동일한 해쉬값을 가지는 인증서 내용을 만드는 것이 불가능에 가깝다.)

4) Server Hello Done

서버가 행동을 마쳤음을 전달함

5) Client Key Exchange

여기서 드디어 둘 사이의 데이터 암호화 때 사용될 대칭키(session key)를 클라이언트가 생성한다. 이를 서버가 전달한 공캐키로 암호화하여 서버에게 보낸다.

6) ChangeCipherSpec / Finished

둘 사이의 핸드 셰이크 과정이 완료되었음을 전달한다.

참고자료

안전한 웹을 위해 HTTPS 이해하기: ①HTTPS의 작동 원리 | 요즘IT

HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서)

SSL, TLS, HTTPS Explained - YouTube

Chatgpt

[모의면접 CS 스터디] DNS

lecarap — Wed, 17 Jan 2024 13:20:45 +0900

정의

DNS(Domain Name System)란 사용자가 웹브라우저에 사람이 읽을 수 있는 도메인 네임을 컴퓨터가 이해할 수 있는 것으로 매핑하는 것을 말한다. 이를테면 우리가 naver.com이라는 도메인 명을 입력하여 엔터를 누르면 그걸 DNS를 통해 해당 도메인 명과 매핑되어 있는 IP 주소로 변환하여 받을 수 있다.

도메인 네임의 구조

먼저 DNS 요청의 동작과정에 살펴보기 전에 도메인 네임의 구조에 대해 살펴볼 필요가 있다.

Top-Level-Domain(TLD): .com, .org, .kr과 같은 최상위 레벨 도메인을 의미한다.
Second-Level Domain: www.google.com의 google과 같이 TLD 바로 옆에 있는 도메인을 의미한다.
Sub-domain: www, mail, blog와 같이 해당 웹사이트의 섹션을 의미하는 경우가 많다.

DNS의 IP 요청 과정

1. 사용자가 브라우저에 www.example.com이라는 도메인을 입력한 뒤 엔터를 누른다.

2. 현재 컴퓨터에 해당 도메인명의 IP가 캐시되어 있거나 C:\Windows\System32\drivers\etc\에 있는 host라는 파일에 있는지 확인하고 없으면 이 URL은 ISP(Internet Service Provider)가 관리하는 DNS resolver 전송된다.

3. DNS resolver는 캐싱 여부를 확인하고 없으면 root 서버에 도메인명을 보내 .com 도메인의 TLD 서버의 IP주소를 알아낸다.

4. TLD 서버에 다시 URL을 요청하고 모든 도메인 네임에 대한 IP 주소를 가지고 있는 Authrotitative Name Server의 IP를 반환한다.

5. Authrotitative Name Server을 통해 질의 하여 해당 도메인과 매핑되는 DNS 레코드의 IP 주소 정보를 찾아 반환한다.

6. 해당 도메인과 일치하는 IP 주소를 응답 받는다.

7. DNS resolver는 이 IP 주소를 클라이언트에게 다시 전송한다.

DNS 질의 방식(재귀적 질의와 반복적 질의)

많은 혼란을 줄 수 있는 그림이다

재귀적 질의와 반복적 질의는 DNS 요청과정에서 각각 클라이언트의 관점(그림의 왼쪽)과 DNS 로컬 서버(그림의 오른쪽)의 관점으로 나눌 수 있다.

먼저 클라이언트는 DNS resolver에게 각 도메인 네임 서버에게 쿼리를 날릴 책임을 위임하고 자신이 원하는 도메인 네임의 IP 주소를 DNS 서버가 찾을 때까지 믿고 그저 기다릴 뿐이다.(재귀는 믿음이다라는 구절이 생각 난다) 이 때 클라이언트의 관점에선 DNS resolver가 어떤 방식으로 도메인 네임 서버를 찾는지는 모르겠지만 알아서 각 도메인 서버를 단계적으로 탐색하는 것으로 보이기 때문에 재귀적 질의를 하는 것이라고 볼 수 있다.

하지만 직접 각 도메인 네임 서버에 질의하는 DNS resolver의 입장에서는 다른데, 위 DNS 동작 과정에서도 살펴 보았듯이 일일이 각 서버에게 질의를 날려서 ip주소를 얻기 때문이다. 그래서 이 과정을 반복적 질의라고 하는 것이다.

DNS 서버에 요청 시 왜 UDP를 사용하는가?

일반적으로 웹에서 데이터를 주고 받을 때 전송 계층에서는 안정적인 전송을 위해 TCP를 사용하는 경우가 대부분이다. 그런데 DNS 서버에 요청을 보낼 때 TCP를 사용하기 하기도 하지만 UDP를 사용하는 경우가 많다. 그렇다면 왜 전송 시 UDP를 사용하는 걸까?

이는 TCP에 비해 전송속도가 매우 빠르기 때문이다. TCP는 안정적인 데이터 전송을 위해 많은 절차가 필요하기에 전송 속도가 느릴 수밖에 없다. 그렇다면 여기서 자연스럽게 DNS 서버 요청 시에는 그런 절차가 필요하지 않나?라는 의문이 든다. 아무리 속도가 빠르다고 해도 DNS 서버에 요청할 때 안정적으로 전송되지 않으면 말짱도루묵이니 말이다. 게다가 UDP는 TCP와 달리 오류 검출 프로세스가 없어 다른 사람이 악의적으로 패킷을 가로채서 내용을 변경하더라도 막을 방법이 없다.

그럼에도 UDP를 사용하는 이유는

1. 요청 데이터의 크기가 작기 때문에 전송 계층에서 데이터를 쪼갤 필요없이 데이터그램 하나만으로 충분히 데이터를 담을 수 있어서 TCP의 이점 중 하나인 데이터 순서 보장이 필요 없고

2.TLS 전송 계층에서의 암호화 프로토콜이 자주 쓰이기 때문에 전송 계층에서 데이터의 변조가 발생하더라도 이를 통해 잡아낼 수 있기 때문이다.

다만 1에서 데이터의 크기가 커서 쪼개야하는 데이터를 쪼개야 하거나 상대 측 방화벽에서 UDP 프로토콜을 사용하는 데이터그램을 차단하는 경우 TCP를 사용한다고 한다.

참고자료

DNS란 | Cloudflare

Why does DNS use UDP? - ClouDNS Blog

DDNS - Dynamic DNS Explained - YouTube

DNS Queries — Recursive and Iterative | by Geeky much! | Networks & Security | Medium

[모의 면접 CS 스터디] HTTP

lecarap — Tue, 16 Jan 2024 15:49:01 +0900

정의

HTTP란 본래 웹을 통해서 문서를 전송하기 위해 사용되었던 어플리케이션 계층 프로토콜이다.

특징

1. 요청-응답 모델

http는 기본적으로 서버-클라이언트 모델을 바탕으로 클라이언트가 요청을 서버에게 전송하면 서버가 이에 대해 응답하는 방식을 채택하고 있다. 달리 말하자면 클라이언트가 먼저 서버에게 요청을 보내지 않으면 서버는 클라이언트에게 요청을 보낼 수 없다. 이 방식은 클라이언트 입장에서 서버의 요청을 기다리는 동안 비동기적으로 다른 작업을 할 수 있다는 점에서 이점이 있다.

그렇다면 웹사이트에서 자주 보이는 푸시 알람은 어떤 방식으로 구현되는 것일까? 간단하게 생각하면 클라이언트에서 지속적으로 서버에게 푸시 알람이 있는지 요청을 보낼 수도 있겠지만 여러 클라이언트의 요청을 처리하는 서버 입장에서는 부담클 것이다. 따라서 이런 경우는 SSE나 WebSocket 방식을 사용하는 것이 일반적이다.

2. 무상태성(stateless)

stateless 즉 무상태성이란 하나의 http 메시지가 이전의 메시지에 대해서는 아무런 정보를 갖지 않는다는 것을 의미한다.

HTTP는 처음에는 단순히 문서를 주고 받는 용도로 개발되었기 때문에 이러한 특성을 가지고 있었다고 한다.

따라서 각각의 메시지는 비교적 적은 정보를 가지기에 오버헤드가 줄어들고, 각 메시지는 self-contained 하기 때문에 확장성이 높아지는 이점이 있다고 한다.

필자의 입장에서는 바로 이전 글에서 HTTP/1.1부터 3까지의 발전 과정을 보면 이 점이 더욱 크게 다가왔다. HTTP는 시간이 지남에 따라 많은 변화를 이룰 수 있었지만 안정적인 전송을 위해 이전 요청의 상태를 저장 (stateful)했던 TCP는 그렇지 못하였고, HTTP/3에서 stateless한 UDP 프로토콜을 확장한 QUIC으로 대체되었으니 말이다.

다만 현대의 웹 어플리케이션은 사용자 인증을 위해 상태를 저장해야 하는 경우가 많다. 그러므로 현재도 stateless한가 싶은 의문이 들지만 상태는 메시지가 아니라 클라이언트나 서버에 저장되고, 각 요청과 응답은 여전히 독립적으로 그리고 병렬적으로 이루어지기 때문에 여전히 stateless한 특성을 가진다고 볼 수 있다.

3. 비연결성(connectionless)

HTTP의 또다른 특징으로는 비연결성, 즉 클라이언트와 서버가 연결을 계속 유지하는 게 아니라 각 한 번의 요청과 응답이 끝나면 연결을 끊는다는 점이다. 이는 서버의 입장에서 일시적으로 다수의 클라이언트와의 연결될 가능성을 줄여주는 이점이 있긴하다. 다만 매 요청-응답 사이클마다 TCP 연결을 재설정하는 오버헤드도 만만치 않기 때문에 HTTP/1.1부터 한 번 TCP 연결을 설정한 후 일정 시간 동안 연결을 유지하는 persistent connection이 도입되었다.

HTTP 메세지

1) HTTP 메소드

HTTP 메소드는 요청차 측에서 해당 요청이 어떤 종류의 요청인지 보여주는 일종의 색인이라고 할 수 있다.

메소드의 일반적으로 GET, POST가 가장 자주 쓰이고 이외에도 PUT, PATCH 등이 쓰인다.

- GET

클라이언트가 서버의 데이터를 조회하고자 할 때 사용한다. 기본 URL의 ? 뒤에 쿼리스트링이라는 것을 붙여서서 서버에게 각 파라미터에 맞는 정보를 보내주도록 요청한다.

- POST

클라이언트가 서버의 리소스에 무언가 변화를 일으키고자 할 때 사용한다.(이를테면 게시판에 글을 작성하거나 댓글을 작성하는 경우) GET과는 다르게 URL이 아닌 HTTP 요청 메시지의 바디(body)에 요청 파라미터를 넣는다.

다만 GET으로 요청을 할 때 쿼리스트링이 과도하게 길어지는 경우 로그를 볼 때 가독성이 심하게 안 좋아지기 때문에 POST를 이용해서 데이터를 조회하는 경우도 있다.

- PUT

클라이언트가 서버의 특정 리소스를 수정하거나 혹은 리소스가 존재하지 않는 경우 새로 생성하고자 할 때 사용된다.

-PATCH

클라이언트가 서버의 리소스의 일부분을 수정하고자 할 때 사용한다.

여기서 중요한 건 반드시 각 메소드가 원래 의도대로 작동하지 않을 수 있다는 점이다. 어디까지나 해당 엔드포인트가 이러한 의도로 사용된다는 걸 보다 명확하게 표시하기 위해 사용될 뿐이다.

2) 상태코드(status code)

상태 코드란 서버 측에서 클라이언트에게 요청이 어떻게 처리되었는지 보여주는 용도로 사용된다. 상태코드는 세 자리 숫자로 표현되는데 맨 앞 숫자에 따라 어느 정도 카테고리 나뉜다.

1xx: 요청이 전달되었으나 처리에 시간이 걸릴 때

2xx: 요청이 잘 처리 된 경우

3xx: 리다이렉션과 같이 요청을 끝내기 위해서 추가로 동작이 필요함을 나타낼 때

4xx: 잘못된 요청을 보낼 때

5xx: 서버에 문제가 발생했을 때

자주 사용되는 걸 정리 해보면

200 OK: 성공적으로 처리했을 때 쓰인다. 가장 일반적으로 볼 수 있는 HTTP 상태.
201 Created: 요청이 성공적으로 처리되어서 리소스가 만들어졌음을 의미한다.
202 Accepted: 요청이 받아들여졌지만 처리되지 않았음을 의미한다.
301 Moved Permanently(영구 이동): 영구적으로 컨텐츠가 이동했을 때 사용된다.
302 Found: 일시적으로 컨텐츠가 이동했을때 사용된다
400 Bad Request(잘못된 요청): 요청 자체가 잘못되었을 때 사용하는 코드이다.
401 Unauthorized(권한 없음): 인증이 필요한 리소스에 인증 없이 접근할 경우 발생한다. ex) 로그인 필요할 때
403 Forbidden(거부됨): 서버가 요청을 거부할 때 발생한다. 관리자가 해당 사용자를 차단했거나 서버에 index.html 이 없는 경우에도 발생할 수 있다. 혹은 권한이 없을 때(로그인 여부와는 무관하다)에도 발생한다.
404 Not Found(찾을 수 없음): 찾는 리소스가 없다.

3) 헤더

HTTP 메시지에서 부가적인 정보를 넣을 때 사용된다. 카테고리를 나누어 보자면

General header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더
Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더
Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더
Entity header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더

자주 사용되는 헤더

host: 서버의 도메인과 TCP 포트를 기입
content-type: 바디에 있는 리소스의 종류에 대해 기술
user-agent: user-agent의 버전, 서버 혹은 클라이언트의 애플리케이션, 운영 체제, 공급업체 및/또는 버전을 식별
cookie: 클라이언트 측에 저장된 쿠키를 서버에 전달할 때 사용
set-cookie: 클라이언트 측으로 서버가 쿠키를 전달할 때 사용
connection: TCP 연결 유지 여부에 사용, keep-alive 옵션 사용시 요청-응답 사이클이 끝나도 일정시간 동안 유지

4) HTTP Body

HTTP body는 메시지에 포함되는 데이터를 저장하는 데에 사용된다. 항상 사용되진 않고 요청 시에는 POST, PUT, PATCH 등에서 사용되고, 응답 시에는 응답할 데이터가 존재할 때 바디가 사용된다.

5) HTTP/2에서의 변경점

HTTP/2부터 HTTP 메시지는 텍스트가 아니라 바이너리 데이터로 압축/인코딩된 후 프레임으로 나뉘어 전송된다. 이는 바이너리 데이터가 텍스트에 비해 파싱 효율이 더 좋고, 오류 검출에 더 유리하며, 용량을 줄일 수 있기 때문이다.

[모의 면접 CS 스터디] HTTP/1.1 ~ HTTP/3

lecarap — Mon, 15 Jan 2024 14:26:47 +0900

1. HTTP/1.1

0.9 버전까지 오직 단순한 html 파일을 주고 받는 용도였던 HTTP는 1.0에 이르러 메소드의 종류가 다양화 되고 HTTP 헤더가 추가되었으며 요청할 때 어떤 형태의 파일을 원하는지 명시할 수 있는 content-type을 정의할 수 있게 되었다.

하지만 HTTP는 각 한 요청-응답 사이클마다 TCP 커넥션을 연결하고 끊어야 하는 제약이 있었기 때문에 서버 입장에서 부하가 컸고 동시에 클라이언트 입장에서도 응답시간이 느린 문제가 있었다.

이러한 문제를 해결하기 위해 등장한 것이 바로 persistent connection과 pipelining이다.

1) persistent connection

매 요청마다 TCP 연결을 재설정하는 기존 방식과 달리 일정시간 동안 TCP 연결을 계속 유지하면서 재활용하는 persistent connection 방식이 도입되었다.이는 http 헤더에 유저가 Keep-alive 옵션을 통해 몇 초 동안 TCP 연결을 유지할지, 이 연결이 최대 몇 개의 요청을 처리할 지를 정의하여 세밀한 설정이 가능하다.

2) Pipelining

기존의 http는 하나의 요청을 보낸 뒤 상대의 응답이 도달한 후에 다시 또 다른 요청을 순차적으로 보내는 모델을 사용하였지만 네트워크 응답시간 지연 등의 문제 때문에 하나의 패킷으로 다수의 요청과 응답을 한꺼번에 처리하는 기법이 도입되었는데, 이를 Pipelining이라고 한다.

http/1.1의 문제점

Head Of Line blocking

1) HOL(Head Of Line blocking)

하지만 pipelining이 도입되고 나서도 여전히 http 요청은 순차적으로 처리되었기 때문에 앞 순서의 처리 시간이 오래 걸리면 그 뒤에 있는 http 요청의 처리도 늦어지는 문제가 있었다. 따라서 이러한 문제를 해결하고자 하나의 클라이언트가 서버와 다수의 TCP 연결을 유지하여 병렬적 처리를 가능하게 했지만 여전히 네트워크 자원이 낭비된다는 단점을 안고 있었다.

2) 헤더 구조의 중복

그리고 다수의 요청과 응답을 주고 받을 때 각 메시지의 헤더 구조가 중복됨에도 여전히 이를 매번 parsing 해야 했기 때문에 불필요한 부분에 throghput을 낭비하는 문제가 있었다.

2. HTTP/2

이러한 1.1 버전의 문제를 해결하고자 HTTP/2 버전에서는 여러 최적화 기법을 사용해 성능 향상을 이루었다.

1) 바이너리 프레임

기존의 HTTP 요청과 응답은 하나의 메시지를 통해 이루어졌는데, HTTP/2에서는 메세지를 바이너리 프레임으로 분할하여 전송하도록 바뀌었다. 즉 HTTP 메시지의 헤더와 데이터를 프레임이라는 단위로 분리한 뒤 바이너리로 인코딩되어 다수의 스트림으로 전송된다. 이러한 인코딩 및 분할 작업은 어플리케이션 레이어 내부에 추가된 바이너리 프레이밍 레이어에서 이루어진다.

2) 다중화 및 커넥션 갯수의 단일화

이전에는 병렬적 처리를 위해 다수의 TCP 커넥션을 사용했지만, 그럴 필요 없이 서버와 클라이언트는 하나의 TCP 연결만을 유지하며 TCP 대역폭을 다수의 스트림으로 나누어 처리하여 병렬적인 데이터의 전송이 가능해졌고, 또한 서버입장에서는 커넥션의 갯수가 감소하여 네트워크 대역폭의 낭비를 줄일 수 있었다.

3) 헤더 압축 및 중복 제거

헤더 구조의 중복 문제로 인한 오버헤드를 줄이기 위해 HTTP/2에서는 HPACK이라는 형식을 통해 헤더를 압축하여 전송하는 방식을 채택하였다. 그리고 또한 서버와 클라이언트 모두 이전 요청의 헤더 항목들을 테이블로 저장하여 클라이언트는 이전 요청의 헤더에서 중복되는 항목을 인덱스로 두어요청을 보내고, 서버 측에서는 테이블을 통해 데이터를 조회하여 복원하는 방식을 통해 헤더 구조의 중복 문제를 해결했다.

4) 서버 푸시

이를테면 클라이언트 측에 서버에 html 문서를 요청할 때 해당 html 내에 명시되어 있는 CSS 파일이나 js 파일은 어차피 필요할 것이다. 서버 푸시란 클라이언트가 명시하지 않아도 서버 측에 미리 사용될 것이라 예측되는 파일을 전송하여 응답시간을 높이는 기법을 말한다.

HTTP/2의 문제점

HTTP/2는 1.1 버전에 비해서 많은 성능적 개선을 이루어냈다. 하지만 근본적으로 HTTP 통신의 기반이 되는 전송계층의 TCP는 이전의 HTTP가 가지고 있던 HOL 문제를 여전히 안고 있었기 때문에(자세한 내용은 TCP의 흐름제어 기법 대해 찾아보면 나올 것이다.) 근본적으로 병렬적 처리를 이루는데에는 한계가 있었다. 이를테면 하나의 스트림에서 전혀 관련이 없는 데이터들이 있을 때 앞에 있는 데이터의 전송이 지연되거나 유실되면 해당 스트림 내에 뒤에 있는 프레임의 전송은 이루어지지 않았다.

3. HTTP/3

그래서 구글은 TCP를 대체할만한 QUIC이라는 UDP 기반 전송 계층 프로토콜을 개발하여 이러한 문제를 해결하였다.

일반적으로 UDP는 낮은 신뢰성으로 인해 자주 사용되지는 않는다. 하지만 전송 속도가 빠르고 TCP에 비해 제어 정보가 적어서 커스텀할 여지도 많으며 헤더의 크기로 인한 오버헤드가 적다. 그렇기 때문에 패킷 손실의 영향이 적고 레이턴시의 감소가 중요한 게임 개발 쪽에서는 이런 식으로 UDP를 커스텀해서 사용하는 경우도 있다고 한다.

HTTP/3는 이러한 QUIC 기반 프로토콜에서 작동하는 HTTP/2라고 할 수 있다. 그렇다면 QUIC은 TCP에 비해 어떠한 점을 개선하였을까?

1) TCP, TLS handshake 과정의 간소화

TCP+TLS와 QUIC의 handshake 및 첫 데이터 전송 비교

일반적으로 대부분의 사이트에서는 HTTP에 TLS라는 암호화 프로토콜을 결합한 HTTPS 프로토콜이 사용된다. 이 때 연결 수립과정에서 TCP handshake 외에도 암호화를 위한 session 키를 교환하는 과정인 TLS handshake도 동반되는데 이 과정에서 3RTT(Round Trip Time, 요청/응답 사이클) 정도 걸린다.

QUIC은 이를 단축하여 처음부터 연결 설정에 필요한 데이터를 initial key라는 connection id를 이용한 암호화키로 암호화 하여 서버에게 전송하고 서버는 session키를 응답으로 전달하여 handshake를 1RTT만에 끝낼 수 있다.

게다가 최초 연결이 수립된 이후 다시 연결을 시도 할 때 저장된 connection id를 바탕으로 바로 연결을 수립할 수 있다고 한다.

2) 멀티플렉싱 지원

QUIC은 멀티 플렉싱을 지원하게 되면서 근본적인 HOL 문제를 해결할 수 있게 되었다. 이제는 각 요청이 별도의 독립된 스트림에서 이루어지기 때문에 하나의 데이터 전송이 다른 요청의 처리 지연에 의해 늦어지는 문제가 사라졌다.

3) IP 주소와 별개의 고유한 Connection Id 사용

현대에는 스마트폰 사용이 대중화되면서 LTE 데이터를 사용하다가도 Wi-fi를 사용하는 등 서비스를 사용하는 도중에 IP 주소가 변경되는 경우가 매우 잦다. TCP에서는 클라이언트와의 커넥션을 유지하는 데에 사용하는 식별자로 IP를 사용하게 되면 이러한 IP 주소 변경 과정에서 매번 handshake 과정을 거쳐야 하기 때문에 데이터 지연이 발생하게 된다.

따라서 QUIC에서는 이를 해결하고자 Connection id라는 것을 사용한다. 이는 마치 암호화 키 교환 과정처럼 첫 연결과정에서 클라이언트가 서버에게 자신의 connection id를 보내고 응답으로 서버의 connection id가 전달되어 이를 통해 서로를 식별하고 연결을 유지한다. 이는 클라이언트와 서버가 계속 가지고 있기 때문에 IP 주소가 바뀌어도 handshake 과정이 발생하지 않는다.

참고자료

HTTP/3는 왜 UDP를 선택한 것일까? | Evans Library

HTTP/2 소개 | Articles | web.dev

[10분 테코톡] 포이의 HTTP1.1, HTTP2, 그리고 QUIC - YouTube

[10분 테코톡] 쿨라임의 HTTP/1.1, HTTP/2, 그리고 QUIC - YouTube

HTTP/1 to HTTP/2 to HTTP/3 - YouTube

[모의 면접 CS 스터디] 컴퓨터 네트워크 1주차

lecarap — Thu, 11 Jan 2024 16:00:22 +0900

컴퓨터 네트워크 정의

컴퓨터 네트워크는 서로 데이터를 주고 받을 수 있는 ip 등으로 식별가능한 네트워크 노드들의 모임을 뜻한다

여기서 A 노드와 B노드가 있고 B노드가 A노드에 있는 특정한 데이터를 가져오고자 할 때 A 노드는 B 노드에 데이터를 특정한 방식으로 전송할 것이다. 하지만 사람이 서로 대화를 할 때 일정한 규칙에 따라 구성된 언어를 통해 소통하듯이, 두 노드가 서로 데이터를 주고 받기 위해선 특정한 규칙이 필요할 것이다. 이 때 사용되는 것이 바로 통신 프로토콜이다.

여기서 두 노드 사이에 데이터를 주고 받을 때 사용하는 프로토콜을 정했다고 하자. 그렇다면 A 노드와 B노드 사이의 통신은 크게 문제 없을 것이다. 하지만 네트워크 상의 각 노드들이 서로 다른 프로토콜을 사용한다면 네트워크 내의 모든 노드들은 통신이 불가능할 것이고 통신하고자 한다면 각각의 노드에 대응되는 프로토콜로 호환되도록 무언가를 추가해야 할텐데 이는 매우 비효율적일 것이다.

따라서 ISO(International Organization for Standardization, 국제 인터넷 표준화 기구) 라는 곳에서 이러한 문제를 해결하고자 표준화된 네트워크 통신 규약을 정의하는 데 이것이 바로 흔히 알려진 OSI 7계층 모델이다.

OSI 7계층 모델

특정한 노드에서 다른 노드로 데이터를 전송하기 위해 필요한 기능은 매우 다양할 것이다.

이를테면 데이터를 어떻게 전송하고 수신할지, 두 노드 사이에 있는 노드들을 어떤 경로로 지나야 가장 효율적으로 데이터를 전송할 수 있을지, 데이터 전송과 데이터 수신이 정상적으로 이루어졌는지 확인하는 기능등등

이런 기능을 한꺼번에 수행할 수 있는 프로토콜을 만들 수야 있겠지만 이러면 특정한 문제가 발생했을 때 어느 부분에 문제가 있기 때문에 파악하기 어려울 것이고 이는 유지보수의 어려움으로 이어질 것이다. 마치 스파게티 코드처럼 말이다..

그래서 OSI 7계층 모델은 이름에서 드러나듯이 네트워크 통신에 필요한 각 기능을 분할하여 7개의 계층에 그 책임을 할당한 것이다. 이는 물리 계층, 데이터 링크 계층, 네트워크 계층, 전송 계층, 세션 계층, 표현 계층, 어플리케이션 계층으로 나눌 수 있다.

다만 OSI 7계층은 어디까지나 표준화된 Reference model이기 때문에 반드시 7계층대로 프로토콜들이 구성되는 것은 아니다. 이러한 개념을 실제로 구현한 모델이 흔히 알려진 TCP/IP 모델이다.

TCP/IP 모델

TCP/IP란 전송계층에서 사용되는 프로토콜인 TCP(Transmission Control Protocol)와 네트워크 계층에서 사용되는 프로토콜인 IP(Internet Protocol)를 묶어서 부르는 명칭이다. 이는 데이터가 네트워크 상에서 안정적으로 전달되는 것을 목표로 한다.

TCP/IP 모델은 이러한 TCP/IP를 중심으로 OSI 7계층에 대응하여 4계층, 혹은 5계층으로 바라보는 것이 일반적이다. 4계층과 5계층의 차이는 Network Acces Layer를 물리 계층과 데이터 링크 계층으로 나누느냐 아니냐의 차이인데 여기서는 5계층으로 분류하여 설명하겠다.

1. 물리 계층

물리계층은 네트워크 장치들의 디지털 데이터를 전송에 적합한 형태로 바꾸어 안정적이고 신뢰성 있는 데이터 전달을 가능하게 하는 역할을 담당한다. 하드웨어적인 내용이 많아 자세하게 다루진 않겠지만 데이터 링크에서 들어온 비트 스트림을(0과 1로 이루어진 디지털 데이터)를 전송매체에 적합 형태로 매핑하여 전송한다.

전송 과정에서 데이터 신호가 약해지거나 데이터에 잡음이 생기거나 왜곡되는 등의 문제가 발생할 수 있는데 이걸 리피터라는 장치가 신호를 증폭하고 재생시켜서 더 멀리 데이터가 안정적으로 전달될 수 있도록 돕는다. 이후 수신 물리계층 측에서는 신호를 다시 비트 스트림으로 변환하여 데이터 링크 계층으로 보낸다.

여기서부터 전송 단위로 프레임, 패킷, 세그먼트라는 게 나올텐데, 읽으면서 유의해야 할 점은 헤더와 같은 제어정보를 제외하면 셋이 옮기는 데이터의 크기는 동일하다는 것이다. (이를테면 패킷을 조립해서 세그먼트가 되는 게 아니다.) 각각의 계층에서 해당 데이터에 대해 필요한 제어 정보가 다른데 이걸 구분하기 위해 사용하는 것이다.

미리 정리하자면

세그먼트-> 전송계층에서 어플리케이션 계층으로부터 받은 데이터를 분리해서 거기에 TCP 헤더를 추가한 것

패킷-> 전송계층에서 보낸 세그먼트에 IP 헤더를 부착한 것

프레임-> 네트워크 계층에서 보낸 패킷에 앞에 이더넷 프레임 헤더와 뒤에 트레일러를 부착한 것

그러면 대충

(이더넷 프레임 헤더-IP 헤더-TCP 헤더-데이터-트레일러)

의 형태가 된다.

이렇게 데이터를 보내는 측에서 각 계층에 필요한 헤더와 같은 제어 정보를 부착하는 과정을 encapsulation이라고 한다.

반대로 수신 측의 각 계층에선 자신에게 필요한 정보를 얻기 위해 이 제어 정보를 하나하나 포장을 벗기는데 이걸 decapsulation이라고 한다.

2. 데이터 링크 계층

같은 LAN에 있는 두 노드 간의 통신을 담당하며 전송단위로 ‘프레임’을 사용한다.

데이터 링크 계층에서는 MAC 주소라는 식별자를 통해 통해 인접한 장치 간에 프레임이 이동한다. 이는 랜카드에 할당된 고유한 주소이다.

이 계층의 역할을 몇 가지 살펴보면

1) 프레임의 생성과 분리

데이터를 전송할 때 네트워크로 계층으로부터 패킷을 받아서 출발지의 MAC 주소나 도착지의 MAC 주소 같은 부가 정보인 헤더를 앞에, 트레일러를 비트의 뒤에 붙여 프레임을 만드는데 이를 프레이밍이라고 한다. 이러한 프레임들을 다시 합쳐서 물리계층에 보낸다.

그리고 상대 측에서 데이터를 수신할 때 물리 계층에서 0과 1로 이루어진 비트스트림을 데이터 링크 계층에 전달하는데, 여기서 송신 측이 붙여놓은 헤더와 트레일러를 바탕으로 비트스트림을 프레임으로 분리한다.

데이터 링크에서 스위칭과 라우팅의 과정

2) 인접한 장치 간의 데이터의 이동

데이터 링크 계층에서는 MAC 주소를 이용해 스위칭(Switching)이라는 것을 통해 인접한 장치 간의 데이터 전송을 담당한다. 여기서 스위칭이란 간단하게 말하자면 포트를 통해 인접한 장치와 장치 사이에 데이터가 이동하는 과정이다.

나중에 말하겠지만 네트워크 상에서 나아가야 최적의 경로를 정하는 것은 네트워크 계층에서 하는데 이를 라우팅이라고 한다. 라우팅을 통해 네트워크 계층에서는 다음으로 나아가야 할 목적지의 IP를 알아낸다.

하지만 데이터 링크 계층에서는 MAC 주소를 기반으로 데이터를 전송하기 때문에 IP 주소를 알더라도 MAC 주소를 모르면 데이터를 전송할 수 없다. 따라서 같은 네트워크 세그먼트에 속한 장치의 IP 주소와 MAC 주소를 매핑한 ARP 테이블이라는 것을 가진다.

현재 장치에서 다음으로 나아가야 할 목적지 장치에 대한 IP 주소와 MAC 주소가 ARP 테이블에 있다면 해당 MAC 주소를 가진 곳으로 나아가지만 현재 ARP 테이블에 MAC 주소가 없다면 같은 네트워크에 속한 모든 라우터에게 IP 주소를 보내는데 이를 바로 ARP 요청이라고 한다.

여기서 만약 수신한 장치의 IP 주소가 ARP 요청의 IP 주소와 같다면 이 장치는 응답으로 MAC 주소를 보내는데. 이 MAC 주소는 ARP 테이블에서 저장되고 또한 새로운 프레이밍 과정에서 헤더의 목적지 MAC 주소로 사용된다.

이러한 일련의 과정을 거쳐 드디어 스위칭을 하게 된다. 다만 이러한 스위칭을 하는 장비는 다양한데, 라우터, L2 스위치, 허브 등이 모두 스위칭을 할 수 있다. 여기서는 L2 스위치를 기준으로 설명하겠다. L2 스위치는 여러 네트워크 장치와 포트라는 것으로 연결되며 (포트, 연결된 장치의 MAC 주소)를 매핑한 MAC 테이블을 가진다. 이 MAC 테이블은 수신한 데이터 프레임을 MAC 주소와 매핑되어 있는 장치로 전달하는 역할을 한다. 이것도 ARP 요청과 비슷하게 플러딩이라는 것을 통해 포트에 연결된 모든 장치의 MAC 주소를 갱신하기도 한다.

여기서 유의할 점은 새로운 네트워크 장치에 도착할 때마다 전송된 데이터 프레임에 저장된 목적지 MAC 주소와 출발지 MAC 주소는 항상 달라진다는 것이다. 필자는 두 노드 간의 통신이 이루어질 때 두 노드의 MAC 주소를 항상 가지고 있다고 생각했지만 그렇지 않더라.

3. 네트워크 계층

네트워크 계층은 서로 다른 네트워크 세그먼트에 속한 노드 간의 통신을 담당하며, 전송단위는 패킷이다. 여기서 네트워크 세그먼트는 같은 브로드 캐스트 도메인(브로드 캐스트 요청이 닿는 범위)에 속한 장치들의 모임을 일컫는다.

네트워크 계층에서는 전송할 때 전송 계층에서 내려온 세그먼트에 출발지 IP, 목적지 IP 등의 제어정보가 포함된 IP 헤더를 부가하여 데이터 링크 계층에 패킷을 전달하고 반대로 데이터를 수신하는 경우 데이터 링크 계층에서 프레임을 받아 확인하고 전송 계층에 보내기도 한다.

네트워크 계층은 여러 역할을 담당한다. 그 중에서 몇가지를 뽑아서 살펴보면

1) 라우팅

이는 패킷이 목적지까지의 최적의 경로로 도달하게 만드는 과정을 의미한다. 이 과정에서 라우터 혹은 L3 스위치(라우터와 L2 스위치의 역할을 동시에 함)라는 장치들을 경유하게 되는데 이 과정에서 장치에 저장된 라우팅 테이블이라는 것을 이용하여, 패킷의 헤더에 담긴 목적지의 주소를 확인한 뒤 어느 홉(중간 기착지)로 가면 될지 판단한다. 이러한 일련의 최적 경로를 찾는 과정을 라우팅 알고리즘이라고도 부르는데, 대표적으로 linked-state(다익스트라 기반), distance-vector(벨만-포드 기반) 등이 있다. 다만 라우팅은 라우터 이외에도 L3 스위치가 담당하기도 한다.

2) 혼잡 제어

온라인 게임을 하다보면 네트워크 상태가 혼잡하다는 문구를 종종 볼 수 있을 것이다. 이는 패킷이 네트워크 상에 넘쳐나는 것을 의미하는데 그렇다면 이게 왜 문제가 될까? 여러가지 이유가 있지만

첫 번째로 라우터에서 단위시간 당 처리할 수 있는 패킷은 한정되어 있기 때문에 패킷의 전송이 늦어지고

두번째로 라우터에 많은 패킷이 도착할 때 나중에 처리할 패킷을 담아둘 버퍼가 필요한데 이 버퍼의 용량이 초과되면 추후에 들어오는 패킷은 유실되어 다시 전송되어야 하기 때문이다.

이 두 가지는 곧 높은 레이턴시를 의미하게 될 것이고, 이는 사용자 경험 측면에서 좋지 않을 것이다. 따라서 네트워크 레이어에서는 이러한 문제를 해결하기 위해 혼잡 제어 역할을 담당하는데

패킷의 전달속도를 일정하게 만들거나 아니면 특정 노드의 혼잡을 감지하여 다른 경로 등으로 패킷을 보내어 특정 기기에 패킷이 몰리는 것을 방지하는 등에 역할을 한다.

3) 패킷의 분할과 재조립

MTU(Maximum Transsmition Unit, 최대 전송 단위)란 각 라우터에서 한 번에 최대로 받을 수 있는 데이터(패킷)의 크기를 말한다. 경우에 따라서 패킷이 MTU를 초과할 수 있기 때문에 이를 프래그먼트라는 단위로 분할한 뒤 패킷이 도착했을 때 수신 측에서 다시 재조립한다.

4. 전송 계층

전송 계층은 출발지 노드와 목적지 노드 사이에 정상적인 데이터 송수신이 이루어지도록 하는 역할을 담당한다.

이를 네트워크 계층과 연관지어 말하면 네트워크 계층이 데이터가 목적지까지 도착하는 길찾기를 해주는 역할을 담당한다면 전송 계층은

어플리케이션에서 보낸 데이터 스트림을 세그먼트라는 단위로 나눈 뒤 제어 정보가 담겨 있는 헤더를 부착하여 네트워크 계층에 전달한다.
수신 측에서는 이 분할된 세그먼트들을 다시 재조립해서 목적지 포트에 있는 어플리케이션에 전달하는 역할을 한다.

더 자세하게 다루어 보면

1) 데이터 전송 시 순서 보장

TCP에서는 데이터 스트림을 세그먼트로 분할한 뒤에 데이터를 원래의 순서대로 보내는데 이 때 패킷이 중간에 유실되더라도 재조립의 문제가 발생하지 않도록 헤더에 순서번호(Sequence Number)와 Ack Number(Acknowledgement Number)라는 걸 사용한다.

이를테면 초기 순서 번호가 1이고 데이터의 크기가 100이라면 순서번호는 100이 되고, Ack Number는 101이 된다. 즉 순서번호는 해당 데이터가 데이터 스트림의 어느 바이트부터 시작되는 데이터인지에 대한 정보이고 Ack Number는 이 세그먼트의 데이터에 다음에 와야 할 세그먼트의 순서번호를 의미한다. 이를 통해 세그먼트를 다시 데이터 스트림으로 조립하여 어플리케이션으로 보내는 것이다.

2) 연결 유지

TCP에서는 3-way-handshake를 통해 전송자와 수신자 간의 연결을 확인하고 데이터 전송을 시작하며 데이터 전송이 끝나면 4-way-handshake를 통해 둘 사이의 연결을 해제한다.

3) 혼잡 제어

네트워크 계층에서 아무리 혼잡 제어를 하더라도 정작 전송 계층에서 계속 데이터를 무지막지하게 전송한다면 의미가 없을 것이다. 따라서 전송 계층에서는 데이터를 보낸 돌아오는 응답시간 등을 확인하며 보낼 데이터 양을 결정한다.

4) 흐름 제어

네트워크의 혼잡 정도와 별개로 만약 수신 측에서도 들어온 데이터를 처리할 시간이 요구될 것이고 라우터와 마찬가지로 나중에 처리할 데이터를 쌓아둘 버퍼같은 것이 있을 것이다.

이 때 송신 측에서 현재 상대 측 전송 계층이 감당할 수 있는 버퍼의 크기를 초과하는 데이터를 보내게 되면 필연적으로 데이터의 손실이 발생될 것이다. 따라서 수신 측에서는 현재 받을 수 있는 데이터의 양을 상대에게 알려서 송신 측이 전송 데이터 양을 제어한다.

5. 어플리케이션 계층

어플리케이션 계층은 실제로 기기 내에서 실행되고 있는 프로세스에 대한 계층을 의미한다.

데이터를 전송하거나 수신할 때 어플리케이션은 기기 내 OS에 내장된 프로토콜 스택이라는 것을 이용하는데, 이 프로토콜 스택이 네트워크 계층과 전송 계층의 역할을 담당한다. 어플리케이션은 데이터를 전송하고자 할 때 프로토콜 스택에 의뢰하여 소켓이라는 것을 만드는데, 간단하게 말하면 통신에 필요한 정보들을 기록해 놓은 것이라고 생각하면 된다. 이걸 통해 다른 호스트들과 통신을 한다.

어플리케이션 계층에서는 전송 계층으로 데이터를 보내기도 하고 수신 시에는 전송 계층에 저장되어 있는 세그먼트들을 읽어들이는데 읽는 속도의 향상이 곧 응답 속도의 향상으로 이어진다. 왜냐하면 근본적으로 TCP/IP에서 데이터 전송의 안정성을 위해 흐름 제어를 하기 때문에 현재 수신 측이 받아들일 수 있는 윈도우 사이즈가 늘어나느냐(즉 얼마나 수신 측이 데이터를 빨리 처리하느냐)는 곧 송신 측의 전송 속도를 높이는 것으로 이루어지기 때문이다. 정리하자면 도미노처럼

어플리케이션의 데이터 처리 속도 향상→전송 계층의 윈도우 사이즈가 빠르게 늘어남→윈도우 사이즈가 꽉차서 대기하는 시간이 줄어듦->데이터를 빠르게 전송한다고 말할 수 있겠다.

데이터 전송 과정

TCP/IP 모델에 대해서 정리했으니 이를 바탕으로 한 번 데이터가 전송 되는 과정을 정리해보자

1) 어플리케이션 계층

이를테면 웹브라우저가 유저가 입력한 URL을 가지고 DNS 서버에 요청하여 해당 URL의 IP 주소를 가져온다. 그리고 어플리케이션은 프로토콜 스택에게 소켓을 만들도록 요청하고 소켓을 통해 데이터를 전송한다. 여기서 일련의 과정을 통해 수신 측 ip주소:포트 번호가 소켓에 저장되고 두 호스트 간의 연결이 확립된다.

2) 데이터에 제어 정보 부가

전송 계층: TCP 헤더(포트 번호) + 데이터 -> 세그먼트

네트워크 계층: IP 헤더(IP 주소) + 세그먼트 -> 패킷

데이터 링크 계층: MAC 헤더(MAC 주소) + 세그먼트 + 트레일러 -> 프레임

등의 과정을 통해 encapsulation을 한다.

3) 전송

프레임은 데이터 링크 계층에서 조립되어 LAN 드라이버를 통해 LAN 어댑터에 전달되고, LAN 어댑터는 데이터를 전송한다.

4) LAN 내에서의 이동

현재 데이터의 목적지의 MAC 주소가 같은 네트워크 세그먼트에 속해 있는지 확인하고 없으면 게이트웨이 라우터로 데이터를 보낸다.

5) WAN에서의 이동

라우팅을 통해 다음으로 나아가야 할 장치를 계속 찾는다. 라우터나 L3 스위치는 네트워크 계층 외에도 물리 계층, 데이터 링크 계층에 대한 처리를 담당하는데 먼저 물리 계층을 통해 데이터가 데이터 링크 계층에 넘어가면 데이터 링크 계층은 목적지의 MAC 주소가 자신의 주소가 맞는지 확인하면서 데이터를 필터링한다. 네트워크 계층에서는 IP 헤더 부착된 목적지 IP 주소를 바탕을 보고 다음으로 나아가야 할 장치를 찾고 다시 데이터 링크 계층에 데이터를 넘긴다. 데이터 링크 계층에서는 다시 현재 자신의 MAC 주소와 다음 목적지의 MAC 주소가 담긴 MAC 헤더를 부착하고 프레임을 만들고 포트를 통해 인접한 장치로 계속 전송된다.

6) 목적지 장치의 네트워크 세그먼트로 도착

목적지 장치의 네트워크 세그먼트에 ARP 테이블을 통해 네트워크 세그먼트 내에 있는 목적지 장치의 MAC 주소를 확인하고 전송한다. 도착하면 이제 다시 decapsulation 과정을 통해 각 계층에서 송신 측이 보낸 제어 정보를 확인하고 전송계층에 이르러 어플리케이션에 도착한다.

참고자료

이해하면 인생이 바뀌는 TCP 송/수신 원리 - YouTube

[10분 테코톡] 히히의 OSI 7 Layer - YouTube

네트워크를 배우려는 사람들을 위해 - YouTube

ARP 쉽게 이해하기

Data Link Layer - GeeksforGeeks

What is the maximum transmission unit (MTU)?

What is Transmission Control Protocol (TCP)? - GeeksforGeeks

MAC addresses and their functionality - Homenet Howto

Routing vs. Forwarding vs. Switching | Baeldung on Computer Science

ChatGpt

성공과 실패를 결정하는 1%의 네트워크 원리

[우아한 테크코스] 3~4주차 회고

lecarap — Mon, 27 Nov 2023 20:49:29 +0900

무려 프리코스가 종료된지 어언 2주가 지났다. 원래 써야지 써야지라는 생각만하다가 여러 일에 치이고 귀차니즘에 절어서 이걸 써야되나 말아야되나 계속 생각하다가 지금이 되서야 쓰게 되었다. 2주의 시간이 지난지라 당시에 했던 생각과는 다른 부분도 있긴 때문에 회고라고 하기도 뭣하지만 미션을 진행할 때의 나의 생각과 지금의 나의 관점의 차이에서 오는 것도 나름 가치 있지 않을까 하는 생각이 든다.

1. 책임 주도 설계(Responsibility Driven Design)과 단일 책임 원칙(Single Responsibility Principle)에서의 책임은 과연 동일한 것일까?

1, 2주차를 책임 주도 개발과 단일 책임 원칙을 적용하는 데에 집중했던 필자는 두 원칙에서 사용하는 '책임'이라는 용어를 사용하고, 또 다른 사람들의 글 속에서 쓰이는 걸 보면서 무언가 말로 형용할 수 없는 불편함을 느꼈다.

예전에 동아시아사 수업을 들었을 때 어느 학우가 엄격한 법치주의를 바탕으로 하는 리콴유의 정책과 과거 진시황 시기 법가사상을 기반으로한 통치의 공통점에 대한 주제로 발표를 했었다. 두 위정자의 통치 방식을 바탕으로 서양의 법치주의와 동양의 법가사상이 큰 공통점이 있다는 주장에 무언가 불편함을 느낀 필자는 아무런 생각없이 질문을 했다가 말문이 막혀서 아무 말도 못했었다.

창피함을 안고 발언을 끝낸 그 다음 다른 학우 분이 했던 질문이 정말 인상 깊었다. "법치주의와 법가사상의 법은 과연 동일한 것인가?" 라는 질문이었다. 이에 대한 답은 나중에 정말 우연히 '검사내전'이라는 책을 읽다가 알게 되었다. 요약하자면 법치주의의 법은 국가 권력의 강력한 횡포로부터 국민을 보호하기 위해 정당한 절차를 근거하는 것이고, 법가사상의 법은 국가가 일반 백성에게 강력한 통제를 행사하는 수단이라는 것이었다. 이런 경험으로부터 위와 같은 질문이 나온 것 같다.

그래서 찾아본 결과 마침 다음과 같은 글이 나왔다.

https://wonit.tistory.com/644

책임 주도 설계(RDD) 와 단일 책임 원칙(SRP) 에서 말하는 책임은 다르다

들어가며 최근 우연한 기회에 객체지향의 사실과 오해 와 오브젝트라는 책을 쓰신 조영호님과 객체지향에 대한 간단한 토론을 할 수 있는 자리가 생겨 그 자리에서 oop 의 다양한 것들에 대해서

wonit.tistory.com

그렇구나! 두 용어에서의 책임은 층위가 다른 것이구나! 하고 넘어갔는데 솔직히 지금 생각해보면 그렇게 다른가? 싶은 생각이 든다. 그래서 책임, SRP, RDD의 관계에 대해 생각해보았다.

각 용어에 대해 정리를 해보면

책임: 객체에 의해 정의되는 응집도 있는 행위의 집합

단일 책임 원칙: 객체는 오직 한 가지의 책임을 가져야 함 (객체가 변경되어야 할 이유는 오직 한 가지여야 함)

책임 주도 설계: 먼저 하나의 시스템을 각각의 책임으로 분할하고 이를 수행하는 객체를 정하는 것

책임 주도 설계의 '책임'은 시스템을 구성하는 문제를 해결하기 위해 작은 것으로 분리할 때의 단위라고 볼 수 있다. 그렇다면 왜 굳이 책임을 바탕으로 시스템을 분리하는 것일까? 이전 회고에도 비슷한 내용을 썼었지만 여기서는 좀 더 구체화 해보겠다. 책임이란 상술한 바와 같이 객체에 의해 정의도는 응집도 있는 행위의 집합이다. 여기서 특정 행위들이 서로 응집도가 높다는 건 하나의 요소의 변경 사항이 다른 요소에 영향을 줄 가능성이 높다는 것을 의미한다. 그리고 응집도가 높은 요소로 집합을 이루었다는 것은 곧 서로 다른 두 집합은 응집도가 낮다는 것을 의미한다. 그러므로 서로 다른 두 책임은 서로의 변경 사항에 대해 영향을 받을 가능성이 매우 낮을 것이다. 그렇다면 하나의 변경으로 인해 나타나는 사이드 이펙트가 줄어들테고 이는 곧 유지보수성이 높은 설계로 이어지기 때문에 책임을 중심 단위로 둔 게 아닐까?라는 게 필자의 생각이다. 또한 객체(혹은 여러 객체)를 책임을 구성하는 수단으로 두면 객체가 변해도 그 근본에 있는 책임은 동일하기 때문에 크게 구조를 변화시킬 필요가 없을 것이다.

이로부터 생각해보면 단일 책임 원칙에서의 책임의 의미가 좀 더 명확하게 느껴진다. SRP에 대해 알아보다 읽게 된 어떤 글에서는 단일 책임 원칙을 단일 변경 요인 원칙이라고 명명하는 것이 의미가 더 명확할 것이라는 의견을 본 적이 있다. 필자도 이에 동의 하지만 굳이 '책임'이라는 용어를 사용한 것은 책임을 위에서 설명했듯이 단일한 변화의 단위로 볼 수 있기 때문이 아닌가 싶다. 따라서 객체에게 하나의 책임을 부여고 메시지를 통해 다른 객체와 협력을 하게 만든다면 객체가 묶여있는 것은 자신이 가지고 있는 책임 뿐이다.

이렇게 정리해보니 상기한 링크의 글처럼 두 용어의 책임은 층위의 차이는 있을지언정 크게 다르지 않은 것 같다는 생각이 든다. 책임 주도 개발에서의 책임을 시스템을 분할하는 단위로 설정한 이유, 단일 책임 원칙에서 객체가 하나의 책임만을 가져야 한다는 것을 강조하는 이유 모두 근본적으로 응집도 때문이 아닐까?

2. 클래스를 분리하는 기준

(여기서는 편의상 객체=클래스라고 하겠다.)

3~4 주차의 목표 중 하나는 클래스를 분리하는 것이다. 그렇다면 여기서부터는 필연적으로 클래스를 어떻게, 어떤 기준으로 분리하면 좋은가? 라는 생각이 따라올 것이다. 필자는 과거 다른 우테코 프리코스 글들을 바탕으로 SOLID 원칙을 기준으로 삼기로 했다.(이유는 딱히 없다.) 하지만 SRP를 제외하면 나머지 원칙에 대해선 전혀 감이 잡히질 않아서 일단 SRP 부터 준수하는 걸 목표로 했는데 SRP만을 기준으로 잡아보아도 의문이 드는 것이 있었다.

객체가 다른 객체로부터 메시지를 전달받고 또 다른 객체에게 메시지를 보낼 때 결국 2가지 객체의 변경사항에 영향을 받는 것이 아닌가라는 의문이었는데, 지금 생각해보면 우문이었지만 이 의문을 해결하는 데에 가장 큰 역할을 했던 관찰은 의존관계에 방향성이 일정하다고 가정할 때 그 종착점이 있다는 것이었다. 이를테면

ㅇ->ㅇ->ㅇ->ㅇ

(->: 메시지를 보내는 방향, o: 객체)

와 같은 걸 생각하면

o->, o->, o->, o

로 나누어 볼 수 있다는 것이다. 이렇게 나누어 보면 객체가 신경쓸 변경 사항은 자기 자신과 오직 메시지가 전달되는 객체뿐이다. 이걸 딱 깨달았을 때 SOLID에서 SRP가 가장 앞에 오는지 그리고 왜 의존관계나 인터페이스에 대해 다루는지 알 것 같은 느낌이 들었다. 지금의 필자가 생각하기엔 객체가 신경 쓸 것은 오직 자신이 현재 알고 있고 메시지를 보낼 객체 뿐이기 때문에 메세지를 받을 객체를 추상화하면 객체가 영향받는 변경 사항은 오직 자기 자신이 가지고 있는 책임이기 때문이 아닐까 싶다.

3. 도메인 로직과 UI 로직의 분리

대략 2주차 미션까지만 해도 필자는 객체가 프로그램에게 자신이 보여지는 방식을 결정해야 한다고 생각했기 때문에 출력 형식을 객체 내부에서 직접 처리 했었는데, 이 요구 사항을 보고 나서야 이렇게 하면 출력에 도메인이 의존하게 된다는 것을 꺠달았다. 사실 처음 봤을 때 두 로직의 차이를 정확하게 결정하기 어려웠지만 각각 따로 떼어 놓지 않고 두 가지를 대비시켜서 생각해보니 어느 정도 정의를 내릴 수 있던 것 같다.

그래서 3~4주차를 진행하면서 내린 두 로직의 정의는

도메인 로직: 사용자에게 전달되는 여러 사항들을 결정하는 로직

UI 로직: 사용자에게 여러 사항이 보여지는 방식을 결정하는 로직

인 것 같다.

이를테면 숫자 야구 미션에서 스트라이크와 볼의 갯수를 결정하는 로직을 도메인 로직이라고 할 수 있고, 그 값들을 사용자에게 보여주는 형식에 대한 로직은 UI 로직이라고 할 수 있다. 그리고 로또 미션에서 로또 등수를 산출하는 로직은 도메인 로직에 속하고 이것을 출력하는 형식은 UI 로직이라고 할 수 있을 것이다.

그렇다면 두 로직을 분리하는 방법은 무엇일까? 여러 가지 방법이 있겠지만 필자 개인적인 생각으로는 DTO를 사용하는 것이 가장 무난했던 것 같다. 무조건 DTO를 사용하는 것이 바람직하다고 볼 수는 없겠지만 객체가 가지고 있는 정보 중에 사용자에게 제공하는 데에 필요한 것만 따로 취해서 전달하고자 한다면 종종 도메인 객체에서는 getter가 필요할 것이다. 이러한 경우 도메인 객체가 UI 로직을 의존하게 때문에 이걸 방지하고자 DTO에게 getter를 분배한다면 도메인 객체는 출력 형식을 의식하면서 getter를 사용할 필요가 없게 된다. 다만 DTO는 도메인 객체에서 만드는 게 아니라 DTO 객체에서 도메인 객체를 받아서 형성하는 방식을 취해야 의존성 문제를 확실히 해결 할 수 있을듯 하다.

아래는 실제 필자가 로또 미션에서 구매한 로또들을 출력하기 위해 만들었던 DTO 객체이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class PurchasedLottosDto {
 
    List<List<Integer>> purchasedLottos;
 
    private PurchasedLottosDto(List<List<Integer>> lottos) {
 
        purchasedLottos = new ArrayList<>(lottos);
    }
 
    public static PurchasedLottosDto from(List<Lotto> lottos) {
 
        List<List<Integer>> purchasedLottos = lottos.stream()
                .map(Lotto::showNumbersByIntegers)
                .toList();
 
        return new PurchasedLottosDto(purchasedLottos);
    }
 
    public List<List<Integer>> show() {
 
        return purchasedLottos;
    }
 
}
 
Colored by Color Scripter

cs

4. TDD

우테코 프리코스를 하기 전에도 TDD라는 용어는 여러 번 들어보았다. 하지만 TDD에 대한 부정적 의견을 주로 듣기도 했고, 아무래도 실제 개발 환경에서 본격적으로 사용되는 것이다 보니 프리코스에 적용될 여지는 별로 없겠다 싶어서 크게 신경 쓰지 않았다. 하지만 3주차 미션을 진행하면서 단위테스트를 잘 짜는 법에 대해 찾아보다가 단위테스트와 TDD라고하는 영상을 보고 난 뒤에 내가 너무 TDD에 대한 편견을 가지고 있다는 것을 깨달았다. 그래서 4주차에는 TDD를 시작할 때부터 본격적으로 활용해 보았는데, 테스트 코드를 먼저 만들고 이를 통과 시키기 위한 코드를 짜는 것이 부자연스럽게 느껴지긴 했지만 확실히 이전에 비해 구현에 대한 망설임이 줄어든듯한 느낌이 들었다.

TDD 테스트 코드 작성->기본 기능 구현->리팩토링의 과정의 싸이클을 반복하는 것이다. 여기서 리팩토링한 뒤에 테스트 코드도 고쳐야 하는 상황이 오니까 비효율적이지 않을까?라는 의문이 따라올 것이다. 하지만 코드를 리팩토링한 이후에도 이전과 동일하게 기능이 동작하는지 확인해야 한다. 이 때 기존에 만들어둔 테스트 코드를 사용한다면 리팩토링에서 어떤 부분이 문제가 되는지 파악할 수 있기 때문에 리팩토링 이후에도 코드가 정상적으로 작동되지 않을 때 어느 부분에서 잘못되었는지 파악하기 쉬울 것이다. 필자는 리팩토링을 하기 전에 테스트 코드를 짜게 되면 리팩토링 이후에 테스트 코드를 변경해야 하기 때문에 비효율적이라는 생각을 했었다. 하지만 TDD에 대한 여러 글들을 찾아보다가 위와 같은 의견들을 보고 어느 정도 설득력을 느꼈다.

다만 모든 메소드에 일일이 테스트를 구현하는 것은 비효율적인 것 같다. 미션의 요구 사항에서는 단위테스트를 시도해보라는 말이 있긴 하지만 위키 백과의 단위테스트의 정의를 살펴보면 " 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차 "라고 되어 있다. 여기서 '모듈'이 무엇인지는 경우에 따라 다르겠지만 필자는 도메인 객체 혹은 객체들이 협력해서 수행하는 역할을 하나의 모듈이라고 볼 수 있다고 생각한다. 따라서 필자는 4주차에 도메인 로직을 잘게 분리하여 이에 대한 코드만을 작성했다.(시간이 부족해서 제대로된 테스트 코드를 짜지 못한 게 아쉽긴 하다.)

소감

3주차는 굉장히 밀도 있게 보냈지만 4주차는 팀 프로젝트에 집중하느라 3주차에서 새롭게 시도해보고자 한 내용을 실천하지 못해서 아쉬웠다. 그래도 1~2주차에 비해 3~4주차는 여러모로 고민할 내용이 많았기 때문에 그만큼 재밌었던 것 같다.

[우아한 테크코스 6기] 1, 2주차 회고

lecarap — Thu, 2 Nov 2023 13:12:33 +0900

1주차만을 가지고 회고를 쓰려고 하니 뭔가 완결된 느낌이 안나서 1, 2 주차를 통합해서 써보려고 한다.

생각했던 것들

1. 기능 구현 목록 작성하는 방법에 대한 고민들

알고리즘 문제를 풀 때에는 절차지향적으로 짜기 때문에 코드가 동작되는 순서에 따라서 구현 사항을 정리하곤 했었다. 그래서 우테코를 시작하기 전에 미리 프리코스 문제를 푸는 스터디를 하였을 때도 이러한 방식을 채택했는데 절차지향적으로 짜던 방식에서 사용하던 구현 사항을 객체지향적으로 짜는 코드에 적용하려고 하니 무언가 하나의 사항이 다른 사항과 엮여있어서 다른 것과 함께 완료가 되거나 애매하게 완료되지 못하는 경우가 많았다. 그래서 이번 프리코스에서 기능 구현 목록을 어떤 기준으로 정해야 할지 고민을 많이했다.

먼저 객체를 중심으로 요구사항을 짜려고 시도해보았지만 생각해보니 이러면 추후에 더 좋은 방식이 떠올려서 구조를 바꿀 때 요구 사항의 변동이 있을듯 싶었다. 생활코딩 html 강의를 전부 다 보진 않았지만 강의 내용 중 지금까지 필자에게 많은 영향을 준 말이 몇 개 있는데 그 중 하나가 바로 최악의 경우를 생각해보라는 말이다. 우리가 우테코에서 다루는 객체는 잘해봐야 수 십개에 불과하겠지만 엄청나게 큰 어플리케이션을 다룬다면 수 천개에 달할 수도 있을 것이다. 근데 만약 객체를 중심으로 구현 사항을 정리한다면 수 천개의 객체에 대한 정보를 일일이 작성해야 하고 수정사항이 발생할 때마다 그 객체와 그 객체와 관련된 액터가 있는 객체의 구현 사항을 수정해야할텐데 귀차니즘에 쪄들어 있는 필자에겐 영 매력적인 방식으로 보이지 않았다.

그래서 최대한 구현 사항의 변경을 줄일 수 있는 방법에 대해 생각해 보았는데 우아한 테크 내의 OOP에 대해 다룬 영상에서 책임 주도 설계라는 것에 대해 알게 되었다. 이런 저런 내용이 있었지만 여기서 필자가 꽂힌 내용은 책임을 먼저 작게 분리한 뒤 메세지를 전달하거나 특정한 동작을 수행하는 객체를 나중에 정한다는 부분이었다. 즉 객체를 먼저 정해서 행동을 정의하는 것이 아닌 특정한 목표를 달성하기 위한 행동을 먼저 정의한 다음에 그것을 수행할 객체를 만든다는 것이었다. 이렇게 하면 얻을 수 있는 이점은 객체가 담당하는 행동을 수정하거나 기존에 있던 행동을 담당할 새로운 객체를 생성한다고 해도 책임을 더 이상 분리하지 않는다는 가정 하에 해당 행동을 수행할 객체를 갈아끼면 된다. 이렇게 하면 구현 사항을 수정할 일이 극히 줄어들 것이라고 판단했다.

그래서 2주차에는 이러한 방식으로 기능 구현 목록을 생각해보았다. 아래는 필자가 작성했던 예시이다.

-입력 값을 받은 후 저장

사용자가 입력한 차의 이름을 받는다(input↔controller)

차의 이름을 받아서 자동차를 생성한다(controller↔service)

만들어진 자동차를 저장한다(Service↔repository)

사용자가 입력한 전진횟수를 받는다(Input↔controller)

전진횟수를 받는다(controller↔service)

- 게임 진행

게임 루프는 application에서 해야할듯

돌아가면서 진행(service)

car 내부적으로 0~9의 숫자를 뽑음(Domain)

4 이상이면 car 내부의 scroe++(Domain)

한 라운드의 진행 결과를 가져온다(service↔controller)

한 라운드의 진행 결과를 받아서 출력한다(output↔controller)

-우승자 선출

게임이 종료되면 우승자를 선출한다.(controller↔service)

선출된 우승자의 목록을 가져와서 출력한다.(output↔controller)

-예외처리

자동차의 이름 길이가 5글자를 초과할 경우(vo에서 처리)

전진횟수에 자연수가 들어가지 않은 경우(InputValidator에서 처리)

(괄호 안에 들어간 건 필자가 당시에 어떠한 객체가 필요할 지 적어둔 것이다. 이는 어디까지나 구상을 위해 적어둔 것이기 때문에 실제 구현 목록은 살짝 다르다.)

필자는 이번 미션에서 대략 세 번 정도 전반적인 구조를 수정할 일이 있었고 특정 객체에 너무 과중한 책임이 몰려있다가 판단되면 객체를 분리하거나 특정 행동을 다른 객체에 옮기는 등 많은 수정을 가했다. 그럼에도 실제로 구현 목록에는 별다른 변동이 필요 없었다.

실제 필자의 파일 구조 변천사이다..

2. 재사용성에 대한 고민

1, 2 주차를 통틀어서 필자가 고민했던 것 중 하나이다. 1주차 미션을 수행하던 도중 재사용성에 있어서 view 부분은 어떠한 로직도 들어가지 말아야 하며 오직 입력과 출력에만 집중해야 한다는 글을 본 뒤부터 코드를 짜면서 재사용성에 대해 꽂히기 시작했다. 2주차에는 Car 객체를 재사용성 있게 구현하는 데에 집중하였다. 달리 말하자면 Car 객체가 자동차 경주 이외의 어플리케이션에 들어가도 크게 문제가 없을 정도로 경주에 대한 정보를 적게 노출 시키는 데에 집중하였다.

Cars와 RacingCars에 대한 코드(깃헙)

이를 위해 필자는 자동차를 모아두고 보여주는 객체였던 Cars를 경주에 관련된 정보를 보여주고 게임 내의 우승자를 선출하는 RacingCars로 바꾸었다. 즉 Car의 경주에 관한 정보를 보여주는 일종의 매개체 역할을 하도록 만들었다. 다만 실제로 레이싱을 진행하기 위해선 RacingCars 내의 객체들이 전진 조건을 충족하면 움직여야 한다는 문제가 있었다.

원래는 RacingCars 내의 자동차 리스트들을 직접 노출시켜서 외부의 RacingPlayService가 이를 처리하도록 하려고 만들었지만 아무리 생각해도 객체 내부의 컨테이너를 다른 객체와 직접적으로 상호작용을 시키는 건 은닉화 측면에서 영 좋지 않다는 생각이 들었다. 그렇다고 해서 RacingCars에 랜덤 숫자를 뽑아서 Car 객체를 전진시킬지 말지 결정하는 로직을 넣기엔 이미 충분할 정도로 로직이 많기 때문에 별로 좋지 않다고 판단되었다. 그래서 Car 객체에 전진 조건에 대한 인터페이스 메소드를 만들고 RacingCars에 Iterable을 상속받아서 forEach를 돌릴 수 있게 만들었다.(chatgpt한테 물어보니 이런 게 있다더라) 그리고 외부에서 자동차가 전진 조건을 충족하였는지를 체크하여 Car의 인터페이스 메소드에 그 결과를 던지는 방식으로 만들었다. 이렇게 하면 추후에 경주 내에서 전진조건이 복잡하게 바뀌어도 Car나 RacingCars에 코드를 추가하거나 수정할 필요가 없다고 생각했기 때문이다. 다만 forEach를 사용해도 내부의 요소를 외부에 노출하는 건 마찬가지이기 때문에 이 부분에선 좀 더 고민이 필요할듯 싶다.

3. 변수명과 가독성에 대해

PS를 하던 사람들은 다들 공감할지도 모르겠지만 문제를 풀 때 변수명을 너무 길게 잡아 놓거나 장황하게 짜면 오히려 잘 안 읽혀서 가독성이 떨어지는 경우가 있다. 그래서 1주차에는 약간의 모호함이 있어도 얼추 의미는 통하는 선에서 길지 않은 변수명을 작성하려고 노력했다. 하지만 정작 나중에 다른 사람들 코드 리뷰를 하다보니 오히려 이런 코드보다 약간 길라도 의미를 명확하게 제시한 코드들이 더 잘 읽힌다는 느낌이 들었다. 그래서 2주차에 이르러선 다소 장황할지라도 의미를 명확하게 전달할 수 있는 변수명이나 메소드명을 넣으려고 노력했다.

이를테면 경주를 여러 번 진행하는 메소드의 경우 playRacingTurnsWith(RacingCars racingCars) 처럼 매개변수까지 포함하여 어떤 역할을 하는지 바로 알아볼 수 있도록 이름을 지었다. 너무 이름이 장황하다 싶으면 해당 변수나 메소드가 속해 있는 클래스의 맥락을 고려해서 이름을 축약하였다. 예를 들어 최종 우승자를 콤마를 기준으로 나누어 출력하는 메소드를 showRacingWinnersNamesSplitByComma() 라고 지었는데 이게 RacingWinners 클래스 내에 있었기 때문에showNamesSplitByComma() 로 바꾸었다.

다짐들

1. 기능 구현 이후에 리팩토링하기

초반부터 코드를 너무 깔끔하게 만드려는 탓에 기능 구현이 지체되는 감이 없잖아 있다 다음부터는 기능 구현 이후에 리팩토링을 하는 것이 좋을듯 하다.

2. 메일 내용좀 잘 확인하자

프리코스 제출 1시간 30분 전에 2주차는 테스트 코드 작성을 목표로 해달라는 글귀를 처음으로 확인하자. 원체 이런 걸 잘 놓지는 편이긴 하지만 다음부터는 메일 내용을 잘 확인해보자

삼성 SW 역량 테스트 B형(professional) 합격 후기

lecarap — Wed, 9 Aug 2023 17:16:05 +0900

WA!

1. 소감

군대에서 백준 온라인 저지를 처음 풀기 시작한 이래로 처음으로 얻는 성과라서 더욱 감회가 남다른 것 같다. 알고리즘 특강은 그저 삼성 B형이라는 어려운 시험을 특강을 들으면 응시할 수 있다고 하길래 신청한 것이었는데, 특강에서 배운다는 알고리즘은 이미 다 알고 있는 것이었기 때문에 크게 얻을 게 있을까? 라는 생각을 처음엔 했었다. 하지만 자료구조를 직접 구현 해본 적 없는 필자에게 있어서 STL 없이 문제를 풀었던 경험은 정말 너무 힘들었지만 그만큼 공부가 되었다. 특히 이번 삼성 DX 알고리즘 특강 과정은 이전 기수들과는 다르게 1번의 응시기회밖에 없어서 정말 열심히 준비했기 때문에 더더욱..

이를테면 필자는 PS 문제를 풀 때 속도를 위해 C++을 썼고, 각 STL 자료구조들이 삽입, 삭제, 탐색에 어느 정도의 시간복잡도를 가지는지는 알고 있었지만, 비전공자로써 어디까지나 흥미본위로 접근한지라 트라이를 처음 구현했을 때를 제외하면 흔한 구조체조차(Class는 전혀 써본 적도 없다) 사용해본 적도 없으며 포인터를 활용하여 자료구조를 구현해본 적도 없었다. 비록 현재 삼성 B형이 STL을 허용한다고는 하지만, 특강에서 제공된 시험과 비슷한 유형의 문제들을 풀어보면서 직접 자료구조를 커스텀해서 구현하여야 할 필요성을 느꼈기 때문에 시험에 자주 사용된다는 해쉬 테이블이나 링크드 리스트와 같은 것들을 직접 구현하는 연습을 했는데, 이 과정에서 포인터나 자료구조의 작동 방식에 대한 이해가 더욱 깊어진 것 같다.(그런데 정작 시험장에서는 STL만 줄창썼다..)

2. 시험 후기

보통 후기들을 보면 1시간은 설계, 2시간 동안 구현+디버깅, 남은 1시간은 최적화하는 1+2+1 전략을 추천하던데, 필자의 경우 1.5+1.5+1 정도였던 것 같다. 사실 최적화 풀이 자체는 초반에 금방 떠올렸는데 저격성 케이스가 명확하게 존재했었기 때문에 이걸 어떻게 해결해야 할지 계속 고민하는 데에 많은 시간을 할애했다. 그런데도 아무리 생각해도 괜찮은 방식이 안 떠올라서 결국 그 방식대로 구현을 시작할 수밖에 없었다.

구현과 디버깅이 끝나고 제출했을 땐 시험장에서 제공된 테스트 케이스 상으론 당장 제출하고 나가도 괜찮을 정도의 실행속도였지만 저격성 케이스를 고려하면 아무런 의미가 없었기 때문에 계속 고민했다. 그렇지만 결국 남은 1시간은 손도 못대고 끝났다. 시험이 끝난 뒤에 망했다는 생각이 들긴 했지만 저격성 케이스는 고려하지 않아도 된다는 후기글을 보고 혹시나 하는 마음에 나름 기대를 품고 있었는데 정말로 다행히도 합격할 수 있었다.

사람마다 사용한 알고리즘은 다르겠지만 필자가 문제에 사용한 알고리즘은 트리 DP, 이분탐색, BFS였다.

3. 시험을 준비하면서 도움이 되었던 글들

원래는 개인적인 팁을 쓰려고 했지만 이미 좋은 정보들이 많기 때문에 여기서는 간단하게 각 글에서 어떤 부분이 좋았는지 짚고 넘어가려고 한다.

https://bloodstrawberry.tistory.com/47

삼성 B형 링크

삼성 A형 - Advanced, 신입사원 입사 기출문제 삼성 B형 - Professional 삼성 C형 - Expert 개념 설명 메모리 풀 Memory Pool 메모리 풀 vs malloc 속도 비교 링크드 리스트 Linked List 링크드 리스트 Linked List Tail ver

bloodstrawberry.tistory.com

각 자료구조 구현 파트나 팁 부분이 많이 도움됐던 것 같다.

https://blog.uniony.me/study/samsungb/

삼성전자 SW 역량테스트 B형 후기 1 (준비)

삼성전자 S/W 알고리즘 특강을 수강하여 운좋게 삼성전자 SW 알고리즘 역량테스트 B형(pro) 을 치를 기회를 얻었습니다. 2회의 기회가 주어졌고 저는 두번째 테스트에서 통과하여 B형을 취득하였습

blog.uniony.me

문제를 풀 때 어떤 절차로 풀면 좋을지 설명하신 것도 좋았지만 개인적으로 이 글에서 저격성 데이터를 너무 신경쓰지 말라는 부분이 정말 도움이 되었던 것 같다. 이 말이 아니었다면 시험 내내 그 케이스를 어떻게 해결해야 할지 고민하다가 끝났을 것이다.

https://baactree.tistory.com/53

삼성전자 SW 역량테스트 B형, 어떻게 공부해야하나요?

A형을 통과한 대학교 재학생 or 졸업생 분들이나 삼성전자 SW직군에 입사한 사원분들은 SW 역량테스트 B형 일명 Professional 등급을 취득하고자 시험을 볼 것이다. 이 포스팅은 B형(Pro) 시험을 보는

baactree.tistory.com

처음부터 끝까지 거를 내용이 없다

-기타 팁

팁이라고 하기엔 뭣하지만 SWEA의 경우 스텍메모리가 1MB밖에 안되기 때문에 재귀 호출을 사용하는 탐색 방식이나 알고리즘은 사용하지 않을 수 있다면 안 쓰는 게 좋다.

[백준 2021] 최소 환승 경로 Python 풀이

lecarap — Sun, 25 Jun 2023 13:51:54 +0900

https://www.acmicpc.net/problem/2021

2021번: 최소 환승 경로

첫째 줄에 역의 개수 N(1≤N≤100,000), 노선의 개수 L(1≤L≤100,000)이 주어진다. 다음 L개의 줄에는 각 노선이 지나는 역이 순서대로 주어지며 각 줄의 마지막에는 -1이 주어진다. 마지막 줄에는 출발

www.acmicpc.net

1. 문제 관찰

시작 노드에서 종착 노드까지 가는 데에 최소 환승을 구하는 문제이다. 여기서 비용은 곧 갈아타는 노선의 갯수이다. 일반적으로 두 노드 사이를 이동하는 데에 최소 비용을 구하는 데에 사용되는 알고리즘은 bfs 혹은 다익스트라 등이 있는데, 각 노선을 갈아타는 데에 비용의 차이는 없으므로 bfs를 사용하면 풀 수 있을 것이다.

2. 문제 풀이

문제에서 주어지는 정보는 각 노선들에 어떠한 노드들이 속해있는 것 정도인데, 시간 복잡도적으로 무리가 없는 선에서 bfs를 이용 하기 위해선 현재 탐색하고 있는 노드가 속해 있는 모든 노선에 대한 정보가 필요하므로(노선을 일반적인 bfs에서의 노드로 취급할 필요가 있기 때문) , 노선 정보를 바탕으로 이러한 그래프를 만들 필요가 있을 것이다. 즉 노선과 역의 관계를 역전시키면 된다. 문제에서 모든 노선이 포함하고 있는 역의 수는 10^6이라고 명시해두고 있기 때문에 O(N)의 시간 복잡도를 가지는 bfs를 이용하면 충분히 모든 노선을 탐색하면서 할 수 있다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

import sys
from collections import deque
input = sys.stdin.readline
 
 
 
n, l = map(int, input().split())
vis = [0]*(n+1)
rvis = [0]*(l+1)
rail = [list(map(int, input().split())) for _ in range(l)]
g = [[] for _ in range(n+1)]
 
for i in range(l):
    for j in rail[i]:
        if j == -1:
            break
        g[j].append(i)
 
 
st, en = map(int, input().split())
 
 
 
 
q = deque()
 
q.append(st)
vis[st] = 1
flag = 0
while q:
    cur = q.popleft()
 
    if cur == en:
        
        if st == en:
            print(0)
        
 
        else:
            print(vis[cur]-2)
        flag = 1
        break
 
    for i in g[cur]:
        if rvis[i]:
            continue
        rvis[i] = 1
        for j in rail[i]:
 
            if vis[j] or j == -1:
                continue
            vis[j] = vis[cur]+1
            q.append(j)
            
 
if not flag:
    print(-1)
Colored by Color Scripter

cs

[백준 14476] 최대공약수 하나 빼기 C++ 풀이

lecarap — Sat, 22 Apr 2023 14:22:20 +0900

https://www.acmicpc.net/problem/14476

14476번: 최대공약수 하나 빼기

첫째 줄에 정수의 개수 N (4 ≤ N ≤ 1,000,000)이 주어진다. 둘째 줄부터 N개의 줄에는 N개의 수가 주어진다. 각각의 수는 20억을 넘지 않는 자연수이다.

www.acmicpc.net

1. 문제 내용 요약

n개의 자연수들이 담겨져 있는 배열 a가 있다. 이 중에서 임의의 수 K를 지우고 나머지 N-1개의 최대공약수 X를 구할 때 이 X의 값이 K의 약수가 되지 않으면서 가장 큰 X를 구하면 된다.

2. 문제 관찰

문제에서 요구하는 것을 가장 단순하게 생각해보자면, 배열 a에서 하나 수를 제외한 경우를 일일이 구해봐서 그 중에서 조건에 맞는 수 중 가장 큰 최대공약수를 구하면 될 것이다. 그런데 이 문제에서 배열 a의 최대갯수는 10^6이므로 아예 처음부터 n-1개의 최대공약수를 구하려고 한다면 시간복잡도 상으론 대략 O(N^2*og(4*10^9))로 시간 안에 돌리는 것은 불가능하다. 그럼 어떻게 최적화 하면 될까?

3 풀이

문제를 잘 관찰해보면 단 하나의 수를 제외하는 것이기 때문에 그것을 기점으로 왼쪽과 오른쪽이 나뉜다는 것을 알 수 있다. 그리고 최대공약수를 구할 때 교환법칙이 성립하는데, 이는 즉 여러 수들의 공통되는 최대공약수를 구하고자 할 때 그 결과값은 연산 순서에 영향을 받지 않다는 것을 의미한다. 이를 바탕으로 최적화 방법을 생각해보면 배열 내 특정한 요소를 제거 했을 때 그 수의 왼쪽에 있는 요소들의 최대 공약수와 오른쪽에 있는 요소들의 최대공약수를 미리 전처리해 놓는다면 아마 비교적 빠른 시간에 최대공약수를 구할 수 있다는 것을 알 수 있다. 이를 고려하면 굉장히 익숙한 누적합 테크닉을 사용할 수 있다는 것을 떠올릴 수 있을 것이다.

배열의 i번째 숫자를 제거한다고 했을 때 최대공약수는 배열 상 i의 왼쪽에 있는 수들의 최대공약수 a와 오른쪽에 있는 수들의 최대공약수 b의 최대공약수(gcd(a, b))와 동일하다. 여기서 일일이 a와 b를 처음부터 구하는 것은 비효율적이기 때문에 미리 전처리를 통해 누적최대공약수 배열을 구하면 된다.

이를테면

left[i] = a[0]부터 a[i]까지 모든 수의 최대공약수

right[i] = a[i]부터 a[n-1]까지의 최대공약수

i번째 수를 제외했을 때 gcd(right[i+1], left[i-1])를 통해 최대공약수를 구하고 적절한 처리를 시행

이처럼 배열을 이용해 미리 전처리 해두면 충분히 빠르게 구할 수 있다.

4. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

#include <bits/stdc++.h>
using namespace std;
typedef long long ll;
typedef pair<int, int> pi;
#define endl '\n'
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
#define vi vector<int>
 
 
const int MAX = 1e6+1;
 
int l[MAX], r[MAX];
 
 
int main() {
  fastio;
  int n, k, ans = -1;
  cin >> n;
  vector<int> arr(n);
 
  for (auto &i : arr) cin >> i;
  l[0] = arr[0];
  r[n-1] = arr[n-1];
  for (int i = 1; i < n-1; i++) l[i] = gcd(arr[i], l[i-1]);
  for (int i = n-2; i >= 1; i--) r[i] = gcd(arr[i], r[i+1]);
 
  if (arr[0]%r[1]) ans = r[1], k = arr[0];
  if (arr[n-1]%l[n-2]) {
    if (ans < l[n-2]) ans = l[n-2], k = arr[n-1];
  }
 
  for (int i = 1; i < n-1; i++) {
    int tmp = gcd(r[i+1], l[i-1]);
    if (arr[i]%tmp && ans < tmp) ans = tmp, k = arr[i];
  }
 
  if (ans == -1) cout << -1;
  else cout << ans << " " << k;
 
 
 
}
 
Colored by Color Scripter

cs

5.5

5. 풀이 회고

평소에 티어를 가리고 푸는 편이라 문제를 풀면서 그렇게 어렵다고 느끼진 않았는데 풀고 나니 골드2라서 정말 놀랐다. 개인적으로 인덱스 처리 부분이 좀 헷갈렸는데 구현하기 전에 미리 정리해놓아서 실수 없이 풀 수 있었던 것 같다.

Atcoder 팁 모음 사이트 Atcoder Clans

lecarap — Sun, 5 Feb 2023 22:29:34 +0900

최근에 Atcoder problems와 같이 앳코더를 통한 알고리즘 학습에 도움이 될만한 서비스를 찾아보고 있었는데 정말 좋은 사이트 하나를 발견했다. 구글링 해보니 한국에는 딱히 소개가 되어있지 않은 것 같은데 앳코더를 보다 편리하고 효율적으로 이용하는 데에 도움이 될 것이라고 생각되어서 글을 적어본다.

Atcoder Clans란?

-홈페이지 소개글

【非公式】競技プログラミングサイトAtCoderがもっと楽しくなるリンク集です。有志による非公式サービス・ツール・ライブラリ・記事などをまとめています。(【비공식】 프로그래밍 대회 사이트 AtCoder를 좀 더 재밌게 즐길 수 있게 하는 링크 모음집입니다. 비공식 서비스나 툴, 라이브러리, 아티클 등을 정리했습니다.)

간단하게 말해서 앳코더를 이용하는 데에 유용한 링크와 정보들을 모아둔 사이트라고 할 수 있다. 카테고리화가 잘 되어있어서 자신의 목적에 맞는 정보를 찾기에는 용이하며, 공식 트위터에서 일주일마다 어떤 내용이 추가 되었는지 볼 수 있다.

정말로 많은 정보가 있기 때문에 그만큼 유용한 정보도 많은듯 싶지만 하나의 단점이 있다면 일본어라는 점이다.. 그래도 한국어와 일본어는 어순이 비슷하여 번역이 매끄럽게 이루어지기 때문에 번역기를 이용하면 언어의 장벽은 상당 부분 해소되는 것 같다.

각 카테고리에 대한 간략한 소개

Quick start- 각 카테고리에서 어떤 것을 다루고 어떤 사람들이 읽으면 좋을지에 대해 나와 있다.

For Beginners- 말 그대로 초보자들을 위한 카테고리이다. 알고리즘 학습에서 겪는 어려움과 고민들을 질문 형식으로 나누어 각 질문에 답하는 형식으로 되어 있다.

Web Apps and Sites- 앳코더와 관련된 유용한 사이트와 API 사이트들을 소개해 놓았다. 내용이 엄청 방대하다..

Recommendation- web Apps and Sites에 있는 것 중 추천 서비스나 툴을 모아놓았다.

Scripts- 앳코더와 관련된 유용한 스크립트와 구글 확장 프로그램 등이 정리되어 있는 카테고리

Articles, Blogs, Books and Videos- 알고리즘 학습과 관련된 아티클, 블로그, 책, 그리고 영상 등을 정리 해놓은 카테고리이다. 재밌고 유용한 정보가 굉장히 많아 보인다.

Libraries and Snippets - 문제 풀이 시간 단축에 유용한 라이브러리, 코드 스니펫들을 정리해놓았다.

Command Line Tools- 소개에서는 키보드 입력을 이용해서 특정한 처리를 간단하게 해주는 것들을 모아두었다고 했지만 그것뿐만 아니라 백준허브와 같이 앳코더에서 제출된 코드를 자신의 깃헙 레포지토리에 저장해주는 툴도 소개 되어있다.

Milestones- 특정한 등급을 달성했을 때의 기쁨과 회고, 그 레이팅에 도달하기 위해 어떤 방식으로 공부했는지 등을 레이팅 별로 정리한 카테고리이다. 여기에 더해 ps 탈출 후기도 있는듯 하다..

Related Contest Sites - Atcoder 이외의 프로그래밍 대회 사이트를 정리해놓은 카테고리

Archives - 현재 관리가 미비하거나 개발이 중단된 서비스들을 모아둔 카테고리이다. (사이트 소개에서는 여러 사정에 의해 개발이 중단된(중단된 것으로 추측되는) 서비스나 툴에 대해 감사와 경의를 표하는 카테고리라고 되어 있다 ㅋㅋㅋㅋ)

백준 이외에 가장 애용하는 사이트가 앳코더였는데 이렇게나 유용한 정보가 많았다는 걸 처음 알게 되었다. 일본어 공부겸 앞으로 여기 있는 사이트의 내용을 참고해서 공부를 해봐야겠다!

[백준 10775번] 공항 C++ 풀이

lecarap — Mon, 9 Jan 2023 22:43:14 +0900

https://www.acmicpc.net/problem/10775

10775번: 공항

예제 1 : [2][?][?][1] 형태로 도킹시킬 수 있다. 3번째 비행기는 도킹시킬 수 없다. 예제 2 : [1][2][3][?] 형태로 도킹 시킬 수 있고, 4번째 비행기는 절대 도킹 시킬 수 없어서 이후 추가적인 도킹은 불

www.acmicpc.net

백준 16566번과 비슷한 탐색방식을 가진 문제이다.

1. 관찰

나중에 배치될 비행기까지 고려해야 한다는 점 때문에 일견 dp로 보일 문제일지도 모르지만 입력값은 결국 비행기가 배치될 수 있는 범위 중 최대 값이고 그것을 초과하는 번호를 가진 게이트에 배치될 수 없기 때문에 그 범위 안에 남아있는 게이트 중 가장 큰 번호를 가진 게이트에 배치되는 것이 언제나 최적해를 가진다는 것이 보장된다. 그렇다면 그 범위 안에 남아있는 가장 큰 게이트의 번호를 어떻게 찾을 수 있을까? 나이브하게 생각하면 입력값에서 1을 계속 빼주면서 해당 게이트가 빈 상태인지 체크 해보면 되겠지만 이 방식은 O(N^2)의 시간복잡도를 가지고, n이 최대 10만이기 때문에 1초 안에 돌리는 것은 불가능하다.

2. 풀이

그러면 여기서 이걸 최적화할 방법을 찾으면 된다. 잘 생각해보면 목표로 하는 값은 (현재 입력값보다 작은 것 중 가장 가까운 곳에 배치된 비행기의 위치를 포함하는 연속적인 게이트의 번호중 선두의 번호)-1이므로 비행기가 연속적으로 배치되어 있는 게이트들을 하나의 집합으로 생각하고 그 집합의 최선두 앞에 비행기를 놓으면 될 것이다.

즉 유니온 파인드 이용해서 연속된 게이트들을 하나의 집합으로 묶어주고 union by rank를 이용해서 선두의 번호를 계속 가리키게 한 다음 새로 만약 선두 게이트 앞에 새로운 비행기가 들어온다면 그 게이트가 새로운 선두 게이트가 되도록 갱신하면 되는 것이다. 여기서 만약 현재 선두의 번호가 1이면(가장 앞이면) 더 이상 넣을 수 없는 것이므로 그 순간까지 들어온 비행기들의 갯수가 답이 된다. 시간 복잡도는 경로 압축을 사용해주면 O(NlogN)으로 충분히 돌아간다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

#include <bits/stdc++.h>
 
using namespace std;
typedef long long ll;
typedef pair<int, int> pi;
#define endl '\n'
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
#define vi vector<int>
 
 
 
int p[100001];
 
 
int find(int a) {
  if (a == p[a]) return a;
  return p[a] = find(p[a]);
}
 
void uni(int a, int b) {
  a = find(a); b = find(b);
  
  if (a > b) {
    swap(a,b);
  }
 
  p[b] = a;
 
 
}
 
 
 
int main()
{
  fastio;
 
 
  int n, m, ans = 0;
  cin >> n >> m;
  for (int i = 0; i <= n; i++) p[i] = i;
 
  while (m--) {
    int a;
    cin >> a;
    
    a = find(a);
 
    if (a == 0) break;
 
    uni(a, a-1);
 
 
    ans++;    
 
  }
 
  cout << ans;
  
 
  
 
}
Colored by Color Scripter

cs

4. 풀이 복기

유니온 파인드를 이용한 문제를 오랜만에 풀어서 그런지 경로 압축을 해주는 것을 까먹어서 계속 시간초과를 봤었다. 꾸준히 문제를 풀어서 체화시키는 게 중요한데 최근에 시간이 없어서 Ps를 못하는 것이 아쉽다.

[백준 14452] Cow Dance Show

lecarap — Tue, 27 Dec 2022 00:04:28 +0900

https://www.acmicpc.net/problem/14452

14452번: Cow Dance Show

After several months of rehearsal, the cows are just about ready to put on their annual dance performance; this year they are performing the famous bovine ballet "Cowpelia". The only aspect of the show that remains to be determined is the size of the stage

www.acmicpc.net

1. 문제 요약

k를 소가 한 번에 춤출 수 있는 무대의 크기라고 정의하고, 소들이 모든 춤을 마치는 시간을 t라고 하자. 1부터 n번째의 소가 춤추는 시간 ai(1 <= i <= n) 주어지고 , t의 최댓값을 T라고 했을 때 k의 최솟값을 구하는 문제이다.

2. 문제 풀이

문제에서 직접적으로 upper_bound라는 표현이 나왔고, k가 증가함에 따라 t가 단조적으로 감소하므로 parametric search 문제인 것은 분명하다고 할 수 있다. 문제는 여기에 사용되는 함수를 어떻게 구현하느냐 인데, 춤이 먼저 끝나는 소부터 나오는 것이기 때문에 최소 힙큐를 이용하면 될 것이다. 구체적으로는 매개변수로 받은 mid 만큼 우선순위 큐에 소들이 춤추는 시간을 넣어 주고, 가장 먼저 끝나는 소와 새로 들어오는 소를 적절히 바꿔주면 된다. 이때 들어오는 소의 시간에 방금 나온 소가 춤춘 시간을 더해줘야 한다. 이렇게 되면 시간복잡도는 O(NloglogN)으로 n이 10만이기 때문에 충분히 돌아간다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

#include <bits/stdc++.h>
 
using namespace std;
 
typedef long long ll;
typedef pair<int, int> pi;
#define endl '\n'
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
#define vi vector<int>
 
ll n, t;
ll arr[100001];
 
ll count(int k)
{
 
    priority_queue<int, vector<int>, greater<>> pq;
    for (int i = 0; i < k; i++)
    {
        pq.push(arr[i]);
    }
 
    ll st = k, sum = 0;
 
    while (st <= n - 1)
    {
        auto cur = arr[st];
        sum = pq.top();
        pq.pop();
        pq.push(cur + sum);
        st++;
    }
 
    while (!pq.empty())
    {
        sum = pq.top();
        pq.pop();
    }
 
    return sum;
}
 
int main()
{
    fastio;
 
    cin >> n >> t;
 
    for (int i = 0; i < n; i++)
        cin >> arr[i];
 
    ll lo = -1, hi = n;
 
    while (lo + 1 < hi)
    {
        ll mid = (lo + hi) / 2;
 
        if (count(mid) <= t)
            hi = mid;
        else
            lo = mid;
    }
 
    cout << hi;
}
Colored by Color Scripter

cs

4. 문제 풀이 복기

최근 문제 티어를 보지 않고 풀고 있는데, 티어를 통해 사용되는 알고리즘을 가늠하기 어렵다는 게 정말 난점인 것 같다. 이 문제도 티어를 알았더라면 우선순위큐가 사용된다는 사실을 금방 떠올렸을 것 같은데, 평소 \보다 사용할 알고리즘이나 자료구조를 떠올리는 게 훨씬 어려웠다.

[백준 25587] 배수로

lecarap — Sun, 18 Dec 2022 17:17:01 +0900

https://www.acmicpc.net/problem/25587

25587번: 배수로

ChAOS 나라에는 총 $N$개의 도시가 있고 각각 $1, 2, 3, …, N$번 도시라고 부른다. ChAOS 나라에 각 도시에는 홍수를 막기 위해 배수로가 설치되어 있다. $i$번 도시의 배수로는 강수량이 $A_i$이하일 때

www.acmicpc.net

1. 문제 관찰

정말 단순하게 생각한다면 쿼리가 들어올 때마다 간선을 이으면서 해당 컴포넌트가 홍수 상태인지 아닌지를 체크할 수 있겠지만 N의 크기가 10만이기 때문에 이와 같은 O(N^2) 풀이는 불가능하다.

그렇다면 여기서 O(NlogN) 혹은 O(N) 정도로 시간 복잡도를 줄일 생각을 해보아야 하는데 잘 생각해보면 홍수 상태인 정점의 갯수를 세는 것 보단 처음에 홍수 상태인 정점의 갯수를 구하고 두 정점을 이을 때 해당 정점들이 속해있는 그래프 내의 정점의 개수와 총 강수량, 총 배수로 크기만 알면 기존에 있던 정점의 갯수를 변경해주기만 해도 충분히 풀 수 있다.

그렇다면 여기서 각 정점이 속한 그래프의 상태를 저장해 줄 방법이 필요한데 그래프를 이어주면서 상태를 저장하는 무난한 방법은 유니온-파인드에서 rank compression으로 find의 리턴값을 일정하게 유지하여, 그 배열에 상태를 저장하는 것이다. 그리고 두 그래프에서 가장 작은 번호가 낮은 정점을 비교하여 더 작은 번호의 인덱스에 (그래프 내 정점수, 강수량, 배수로 크기)를 더해주어 저장하면 된다.

이렇게 해서 맨 처음에 홍수 상태인 정점의 수를 구한 뒤 쿼리를 보고 적절하게 변화시켜 나가면 어렵지 않게 문제를 풀 수 있을 것이다.

2. 풀이

다음과 같은 순서로 문제를 풀어 나가면 된다.

1. 쿼리를 받기 전에 홍수 상태인 정점의 갯수를 세어줌

2. 두 정점을 이으라는 쿼리가 들어오면 유니온 파인드를 이용하여 두 정점을 엮음.

3. 엮는 과정에서 두 정점 a, b가 같은 그래프에서 속할 경우는 패스하고 다른 정점에 속하고, 또한 서로 다른 상태인 경우 다음과 같은 경우가 존재할 수 있음.

1) a정점은 홍수이고 b정점은 정상

-두 정점을 엮으면 홍수

-두정점을 엮으면 정상

2) a정점은 정상이고 b정점은 홍수.

-두 정점을 엮으면 홍수

-두정점을 엮으면 정상

무조건적으로 특정 정점은 상태가 변화하므로 이걸 고려하면서 홍수 상태인 정점의 개수를 변화시키면 된다.

3. 풀이 복기

풀이 자체를 떠올리는 건 쉬웠지만 구현이 다소 까다로웠고, 무엇보다 두 정점이 같은 그래프에 속한 경우를 고려하지 못해서 디버깅을 좀 오래 했다. 구현이 어려운 문제는 처음에 문제 조건을 명확히 하고, 구현 과정을 세세하게 정리하는 게 중요한데, 최근 구현 문제를 자주 안 풀다 보니 실수가 많았던 것 같다.

4. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<ll, ll> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
 
vector<tuple<int, int, int>> info(100010);
int p[100100];
int n, q;
int ans = 0;
 
 
int find (int a) {
    if (a == p[a]) return a;
    return a = find(p[a]);
}
 
void uni (int a, int b) {
    a = find(a); b = find(b);
    
    if (a == b) return;
 
    if (a > b) swap(a,b);
 
 
    p[b] = a;
    auto& [x, y, z] = info[a];
    auto& [k, l, m] = info[b];
    
    if (y < z && l >= m) {
        if (y+l >= z+m) {
            ans -= x;
        }
        else {
            ans += k;
        }
    }
        
    
    else if (y >= z && l < m) {
        if (y+l < z+m) {
            ans += x;
        }
        else ans -= k;
 
    }
 
    
    x += k;
    y += l;
    z += m;
    k = 0; l = 0; m = 0;
 
}
 
 
 
int main() {
    fastio;
    cin >> n >> q;
 
    vector<int> a(n), b(n);
 
    for (auto &i : a) cin >> i;
    for (auto &i : b) cin >> i;
 
    for (int i = 0; i < n; i++) {
        if (a[i] < b[i]) ans++;
    }
 
    
    
    for (int i = 1; i <= n; i++) {
        p[i] = i;
        auto& [x, y, z] = info[i];
        x = 1; y = a[i-1]; z = b[i-1];
    }
 
    while (q--) {
        int que;
        cin >> que;
        if (que == 1) {
            int x, y;
            cin >> x >> y;
            uni(x, y);
        }
 
        else cout << ans << endl;
        
    }
   
 
    
    
}
Colored by Color Scripter

cs

[백준 5624] 좋은 수

lecarap — Fri, 16 Dec 2022 19:27:12 +0900

https://www.acmicpc.net/problem/5624

5624번: 좋은 수

정수 N개로 이루어진 수열 A가 있다. 이때, i번째 수가 그 앞에 있는 수 세 개의 합으로 나타낼 수 있을 때, 그 수를 좋다고 한다. (같은 위치에 있는 수를 여러 번 더해도 된다) 수열이 주어졌을 때

www.acmicpc.net

1. 문제 풀이

배열 A가 있을 때 그 요소를 ai라고 하자(1 <= i <= n) 이때 ai = ax + ay + az (x, y ,z < i, x y z는 같을 수 있음)가 성립하는 i의 갯수를 찾으라는 문제이다. 여기서 식을 변형하면 ai-ax = ay+az인데 즉 i미만의 인덱스에서 아무 수나 선택해서 i번째 수에서 뺀 수가 중복을 허용하여 선택한 두 수의 합과 같은 경우가 존재한다면 된다는 것이다. 이걸 생각하면 배열의 특정 인덱스에서 그 미만의 인덱스에서 나올 수 있는 두 수의 합을 체크하고, 특정 인덱스에서 그 보다 작은 인덱스의 수를 뺀 결과가 존재하는지를 체크하면 되는 것이다. 이를 코드로 구현하면 배열을 이용할 경우 메모리 제한이 128MB인데 나올 수 있는 수의 범위가 잘해봐야 40만 정도로 충분하며 O(N^2)의 시간 복잡도로 해결할 수 있다. 단 주의할점이 있다면 나올 수 있는 수가 최대 -20만이기 때문에 배열에 숫자를 기록할 때 +20만을 해주어야 인덱스의 범위를 벗어나는 것을 막을 수 있다.

2. 풀이 복기

처음에 N이 최대 5000이라서 O(N^2logN)의 시간 복잡도로도 충분히 돌아갈 거라고 판단하여 map을 사용했는데 시간 초과가 났다. 그렇다고 배열을 사용하자니 나올 수 있는 수의 범위가 -라서 어떻게 해야할지 고민했는데 문득 예전에 좌표 평면을 배열로 표현할 때 나올 수 있는 최대 -값을 더해주어 구현했던 것이 기억나서 이걸 +20만을 더해주는 아이디어가 떠올랐다. ai-ax = ay+az라는 식을 통해 문제를 쪼갠 발상은 앳코더에서 풀었던 문제들에서 자주 보이던 것이라 떠올릴 수 있었던 것 같다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<ll, ll> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
int d[400001] = {};
 
int main() {
    fastio;
    int n, ans = 0;
    cin >> n;
    vector<int> a(n);
    for (auto &i : a) {
        cin >> i;
        
    }
 
    for (int i = 1; i < n; i++) {
        for (int j = i-1; j >= 0; j--) {
            d[a[i-1]+a[j]+200000] = 1;
        }
        for (int j = i-1; j >= 0; j--) {
            if(d[a[i]-a[j]+200000] == 1) {
                ans++;
                break;
            } 
        }
        
    }
 
    cout << ans;
 
    
    
}
Colored by Color Scripter

cs

[백준 26085] 효구와 호규 (Easy)

lecarap — Sat, 3 Dec 2022 00:18:46 +0900

https://www.acmicpc.net/problem/26085

26085번: 효구와 호규 (Easy)

첫 번째 줄에는 격자판의 크기를 나타내는 두 정수 $N$과 $M$이 주어진다. ($3 \le N, M \le 1\,000$) 두 번째 줄부터 $N+1$ 번째 줄까지는 격자판의 정보가 주어진다. 각 줄에는 $M$개의 숫자가 공백으로 구

www.acmicpc.net

1. 문제 풀이

상하좌우로 숫자가 인접한 두 숫자가 있을 때 없앨 수 있고 빈칸에는 근처에 있는 카드를 옮길 수 있을 때 모든 카드를 없앨 수 있는지를 판별하라는 문제이다.

문제의 조건을 따져 봤을 때 0이나 1의 갯수가 홀수이고, 처음부터 0과 1이 인접하지 않은 상태인 경우 너무나 당연하게 불가능할 것이다. 그렇다면 나머지 경우는 어떨까?

나머지 경우는 어떠한 경우에도 가능하다. 설령 한 부분을 제외하고 0과 1이 완전히 엇갈린 배열이라고 해도 두 쌍의 배열을 제거한다면 완전히 구석에 있는 것을 제거했다고 해도 인접한 3개 이상의 칸에서 이동할 수 있음이 보장되는데. 그러면 어떠한 경우라도 같은 숫자를 빈칸으로 옮겨서 제거하는 것이 가능할 것이다.

2. 풀이 복기

문제 서술과 조건을 봤을 때 딱봐도 코드포스 느낌의 애드혹 문제 같아서 풀이법을 금방 떠올릴 수 있었는데, bfs의 상하좌우 탐색을 기반으로 코드를 짤 때 nx, ny를 구하는 과정에서 nx = arr[i][j] + dx[i]라는 말도 안되는 코드를 넣어버리는 바람에 맞왜틀을 좀 오래했다. 시험 공부한 뒤에는 그냥 딴 거하면서 쉬는 게 상책인 것 같다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
int arr[1010][1010], dx[] = {0, 0, -1, 1}, dy[] = {1, -1, 0, 0}; 
 
 
int main() {
    fastio;
    int r, c, cnt0 = 0, cnt1 = 0;
    cin >> r >> c;
 
    
 
    for (int i = 0; i < r; i++) {
        for (int j = 0; j < c; j++) {
            cin >> arr[i][j];
            if (arr[i][j] == 0) cnt0++;
            if (arr[i][j] == 1) cnt1++;
            
        }
    }
 
    if (cnt0%2 == 1 || cnt1 % 2 == 1) {
        cout << -1;
        return 0;
    }
    
 
    for (int i = 0; i < r; i++) {
        for (int j = 0; j < c; j++) {
            for (int k = 0; k < 4; k++) {
                int nx = i + dx[k], ny = j + dy[k];
                if (nx < 0 || nx >= r || ny < 0 || ny >=c) continue;
                if (arr[i][j] == arr[nx][ny]) {
                    cout << 1;
                    return 0;
                }
            }
        }
    }
    
    cout << -1;
    
    
}
Colored by Color Scripter

cs

[백준 2487] 섞기 수열

lecarap — Fri, 18 Nov 2022 23:48:18 +0900

https://www.acmicpc.net/problem/2487

2487번: 섞기 수열

A1, A2, …, AN으로 표시된 N 개의 카드를 정해진 방법으로 섞고자 한다. 그 섞는 방법은 1에서 N까지의 숫자로 이루어진 수열로 표시된다. 이 수열을 섞기 수열이라 하자. 섞기는 현재 가지고 있는

www.acmicpc.net

1. 풀이

순열 사이클이란 1부터 N까지의 수가 하나씩 포함된 순열에서 특정한 원소의 값이 가리키는 것을 인덱스로 하여 따라가다 보면 원래 값이 나타나는 성질을 이용한 사이클이다. 이를테면 [2, 5, 3, 1, 4]라는 순열이 존재할 때(1-based index) a[1] = 2, a[2] = 5, a[5] = 4. a[4] = 1, a[1] = 2 이런 식으로 원래의 값으로 돌아면서 사이클이 생기는 것이다. 문제의 서술을 보면 알 수 있겠지만 본 문제도 바로 이 순열 사이클을 이용해서 풀 수 있다.

문제에서 요구하는 것은 각 원소의 값을 인덱스로 하는 순열의 요소로 변화시켰을 때 원래 상태로 돌아오는 최소 횟수를 구하라는 것이다. 각 원소의 변화는 독립적이므로 각각의 원소가 원래대로 돌아올 때까지의 섞기 횟수를 d[i]라고 했을 때 정답은 d 내의 모든 요소의 최소공배수라고 볼 수 있다. 그러므로 각 원소의 d[i]를 구하여 lcm을 구하면 끝이다.

주의할 점이 있다면 n이 최대 10000이라 최대 O(N^2)으로 모든 원소의 사이클을 구할 수 있는 것처럼 보이지만 의외로 시간초과가 나므로 이미 탐색한 사이클의 크기를 저장해주어서 처리해야 TLE를 방지할 수 있다. 그리고 lcm을 구할 때 a*b/gcd(a,b) 꼴인데 최대 사이클 크기가 2e9라서 정수형 범위를 초과할 여지가 있으므로 long long을 사용해주어야 한다.

2. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
 
    
 
int arr[20001];
int p[20001];
int d[20001] = {};
 
 
 
 
int main() {
    fastio;
    int n;
    cin >> n;
    vector<ll> gc;
    for (int i = 1; i <= n; i++) {
        cin >> arr[i];
        p[i] = arr[i];
    }
 
    for (int i = 1; i <= n; i++) {
        int cur = i, cnt = 1;
 
        while(p[cur] != i) {
            cnt++;
            cur = p[cur];
            if (d[cur]) {
               cnt = d[cur];
               break;
            }
        }
        d[i] = cnt; 
        gc.push_back(cnt);
    }
 
    ll ans = gc[0];
 
    for (ll i : gc) {
        ans = ans*i/gcd(i, ans);
    }
 
    cout << ans;
 
 
    
   
 
}
Colored by Color Scripter

cs

[백준 25921] 건너 아는 사이 C++

lecarap — Mon, 14 Nov 2022 16:33:42 +0900

https://www.acmicpc.net/problem/25921

25921번: 건너 아는 사이

첫째 줄에 비용의 최솟값을 출력한다.

www.acmicpc.net

1. 풀이

내용만 보면 일견 그래프 문제로 보이지만 사실 정수론 문제에 가깝다. 요약하면 두 정점을 연결할 때 1)두 정점의 번호가 서로소이면 둘 중 더 큰 수를 점수에 더하고 2)아닌 경우 최대 공약수를 더하며, 점수를 최소화시킬 수 있는 연결그래프를 만들라는 문제이다. 여기서 다음과 같은 생각이 가능하다.

1. 소수는 어떠한 경우에도 자기 자신을 점수에 더하는 것이 이득이다 1)과 2)의 조건을 고려하면 그렇다

2. 다음으로 두 수가 서로소가 아닌경우 최대공약수를 최소화 하는 조건을 생각해보자. 여기서 특정한 수를 소인수 분해 했을 때 그 중 가장 작은 소인수가 그 수에서 나올 수 있는 최소인 최대공약수임을 알 수 있다.

3. 소인수들 중 가장 작은 값은 에라토스테네스의 체로 구할 수 있다.

이를 바탕으로 에라토스테네스의 체를 이용해서 소수인 경우 자기 자신을 더하고 아닌 경우 자신을 처음 체크한 소수를 점수에 더해주면 된다.(왜냐하면 그게 가장 작은 소인수이기 때문) 에라토스테네스의 체의 시간복잡도는 O(NlogN)이므로 0.5초 내에 충분히 돌릴 수 있다.

2. 풀이 과정 복기

전형적이지 않은 골드 3 문제를 15분만에 풀어서 정말 기쁘지만, 무조건적으로 소수를 점수에 더해야 하는지에 대한 이유를 풀이 중에 생각하지 않았고, 시간 제한을 확인하지 않고 풀었다. 최근 PS를 뜸하게 했던 탓인지 사고과정이 너무 감각적이게 된 것같다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
 
int c[1000001];
 
 
int main() {
    fastio;
    int n;
    ll ans = 0;
    cin >> n;
    
    for (int i = 2; i <= n; i++) {
        if (c[i]) continue;
        c[i] = i;
        ans += i;
        for (int j = i; j <= n; j+= i) {
            if (c[j]) continue;
            c[j] = i;
            ans += i;
        }
    }
 
    cout << ans;
 
 
 
 
    
 
}
Colored by Color Scripter

cs

[백준 25917] Prime Arrangement

lecarap — Sun, 13 Nov 2022 20:40:58 +0900

https://www.acmicpc.net/problem/25917

25917번: Prime Arrangement

가능한 배치의 수를 $998\,244\,353$으로 나눈 나머지를 출력한다. $998\,244\,353$은 소수이다.

www.acmicpc.net

1. 풀이

r행 c열의 행렬에 r*c개의 서로 다른 소수를 집어넣을 때 1<= x <= r인 x에 대해 x행의 소수들을 모두 곱한 수를 가중치라고 하고, 각 행의 가중치가 Px번째인 경우를 만족하는 경우의 수를 구하는 문제이다.

일견 굉장히 복잡해보이는 문제지만 모든 수들의 소인수의 구성은 유일하다는 성질을 생각해보면 동일한 가중치가 존재할 수 없고, 가중치의 순서는 소수의 조합을 만든 뒤 해당하는 행에 보낸다고 생각하면 무시할 수 있으므로 r*c개의 소수를 c개의 소수를 가진 r개의 집단으로 나누는 경우의 수를 구하는 문제로 환원 시킬 수 있다. 이는 원순열을 구하는 것을 응용해서 (r*c)! / r!로 구하는 것이 가능하다.

2. 풀이 복기

소인수의 유일성과 가중치 순서를 무시할 수도 있다는 것은 문제를 이해하자마자 떠올릴 수 있었지만 고등학교 때 확통을 싫어하기도 했었고 대학교 입학이후 수학을 본격적으로 공부한 적이 없었기 때문에 경우의 수 구하는 공식을 생각하는 데에 좀 오래걸렸다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
 
const ll mod = 998244353;
 
 
int main() {
    fastio;
    int r, c;
 
    cin >> r >> c;
    vector<int> a(r*c);
    for (auto &i : a) cin >> i;
    
    for (int i = 0; i < c; i++) {
        int t;
        cin >> t;
    }
 
    ll ans = 1;
 
    for (ll i = r*c; i >= r+1; i--) {
        
        ans *= i%mod;
        ans %= mod;
    }
 
    cout << ans;
    
 
 
}
Colored by Color Scripter

cs

백준 25194 결전의 금요일 C++

lecarap — Sat, 5 Nov 2022 21:38:01 +0900

https://www.acmicpc.net/problem/25194

25194번: 결전의 금요일

곰곰이는 올해도 운동하기를 신년 목표로 삼았지만, 지금까지 헬스장을 한 번도 가지 않았다. 운동하라고 잔소리하는 당신에게, 곰곰이는 금요일에 정확히 일을 끝마치는 시점이 있다면 헬스

www.acmicpc.net

1. 풀이

문제를 간단히 환원하자면 주어진 숫자 중 7로 나눠서 4가 되는 조합이 있는지를 판별하는 문제라고 볼 수 있다.

모듈러 연산의 법칙에서 알 수 있듯이 특정한 연산을 진행하기 전에 각 수를 나눈 것과 연산의 결과를 나눈 것은 동일하기 때문에 모든 입력은 6이하의 수로 생각될 수 있다. 이 때 0인 경우에는 의미가 없으니 배제하고 4인 경우가 존재한다면 이미 조건이 성립하므로 YES를 출력한다. 그 이외의 경우 1, 2, 3, 5, 6을 조합하는 거라고 생각했을 때 특정 숫자를 조합하면 다른 숫자가 될 수 있다는 점에서 dp임을 관찰할 수 있다. 이 때 1은 4, 2는 2, 3은 6, 5는 5, 6은 3개 이상일 경우 무조건 가능하다고 볼 수 있다. 다만 주의할 점이 있다면 매우 작은 케이스의 경우 이것이 통하지 않을 때가 존재한다 이럴 때는 백트래킹을 이용한 완전탐색으로 파악 가능하다.

2. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
int cnt[7] = {}, d[7] = {};
bool flag = 0;
 
void dfs(int sum) {
    if (sum%7 == 4) {
        flag = 1;
        return;
    }
 
    for (int i = 1; i <= 6; i++) {
        if (cnt[i] == 0) continue;
        cnt[i]--;
        dfs(sum+i);
        cnt[i]++;
    }
 
 
 
}
 
 
 
 
 
 
int main () {
    fastio;
    int n, m = 0, ans = 0, idx = 0, sum = 0; 
    cin >> n;
    vector<int> a(n);
    
    for(auto &i : a) {
        cin >> i;
        i %= 7;
        if (i == 0) continue;
        if (i == 4) {
            cout << "YES";
            return 0;
        }
        sum += i;
        cnt[i]++;
        d[i*cnt[i]%7]++;
        
    }
 
    if(d[4] || d[1] >= 4 || d[2] >= 2 || d[5] >= 5 || d[6] >= 3) cout << "YES";
    else {
        dfs(0);
        if (flag) cout << "YES";
        else cout << "NO";
    }
 
 
    
 
 
 
 
    
    
 
}
Colored by Color Scripter

cs

Atcoder 競プロ典型９０問 -Longest Circular Road(★4)

lecarap — Wed, 21 Sep 2022 22:52:01 +0900

競プロ典型９０問(대충 번역하면 대회 프로그래밍 전형 90문제) 란 e869120이란 유저가 만든 atcoder에서 빈출되는 전형적인 알고리즘 유형을 90문제로 정리한 것을 말한다. 자세한 설명은 여기를 참조하자.

https://atcoder.jp/contests/typical90/tasks/typical90_c

003 - Longest Circular Road（★4）

AtCoder is a programming contest site for anyone from beginners to experts. We hold weekly programming contests online.

atcoder.jp

1. 문제 관찰

간단하게 문제를 요약하자면 트리가 하나 있고 여기에서 연결되어 있지 않은 두 정점을 선택해서 간선을 이었을 때 싸이클이 생기는데 이 싸이클에 포함되는 정점의 수가 최대가 되도록 정점을 선택하여야 한다는 문제이다.

트리는 싸이클이 없는 그래프이기 때문에 다른 싸이클이 존재하지 않으므로 트리 내에서 가장 거리가 먼 두 정점 즉 트리의 지름에 양 끝점을 구해서 이으면 가장 큰 싸이클을 만들 수 있음이 보장된다. 사실상 백준에 있는 트리의 지름 문제와 동일하다고 볼 수 있다.

문제에서 정점의 개수인 N의 최대가 10만에 해당하므로 플로이드-워셜을 통한 접근은 O(N^2)이므로 불가하다 그러므로 아무 정점 A를 골라서 그 정점과 가장 먼 정점인 B를 구하고 그 정점과 또 다시 가장 먼 거리에 있는 C와의 거리를 구하는 것이 정해이다. BFS, DFS를 사용하면 되므로 O(N)으로 해결 가능하다. 이에 대한 증명은 여기를 참조하면 된다.

2. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
vector<int> g[100010];
int n, vis[100001] = {};
 
 
void bfs(int st) {
    vis[st] = 1;
    queue<int> q;
    q.push(st);
 
    while (!q.empty()) {
        auto cur = q.front();
        q.pop();
 
        for (auto i : g[cur]) {
            if (vis[i] > 0) continue;
            q.push(i);
            vis[i] = vis[cur] + 1;
        }
    }
}
 
 
 
 
 
int main () {
    fastio;
    cin >> n;
    int t = n;
 
    while(t--) {
        int a, b;
        cin >> a >> b;
        g[a].push_back(b);
        g[b].push_back(a);
 
    }
    bfs(1);
    int st = max_element(vis + 1, vis + n + 1)-vis;
 
    fill(vis + 1, vis + n+1, 0);
 
    bfs(st);
 
    cout << *max_element(vis + 1, vis + n + 1);
 
 
    
 
 
 
    
    
    
    
    
    
 
 
 
}
 
    
    
    
 
Colored by Color Scripter

cs

[BOJ] 백준 3078 좋은친구

lecarap — Mon, 12 Sep 2022 16:35:02 +0900

https://www.acmicpc.net/problem/3078

3078번: 좋은 친구

첫째 줄에 N과 K가 주어진다. (3 ≤ N ≤ 300,000, 1 ≤ K ≤ N) 다음 N개 줄에는 상근이네 반 학생의 이름이 성적순으로 주어진다. 이름은 알파벳 대문자로 이루어져 있고, 2글자 ~ 20글자이다.

www.acmicpc.net

1. 문제관찰

문제의 조건을 요약해보자면 입력된 순서대로 배열에 저장했을 때 인덱스의 차이가 K 이하이면서 문자열의 길이가 동일한 쌍을 찾는 것이라고 말할 수 있다. 일단 문제에서 배열의 최대갯수가 30만이니 적어도 O(NlogN)에 해당하는 알고리즘을 사용해야 풀릴 수 있는 문제라고 할 수 있다.

2. 풀이

특정한 배열에서 한 쌍을 찾는 방법을 생각해보자 이를테면 (1, 2, 3, 4)라는 배열이 존재할 때 이중포문을 돌려서 (1,2)

(1,3) (1,4) (2,3) (2,4) (3,4)를 찾을 수 있다. 여기서 보아야할 것은 특정한 쌍을 찾을 때 하나를 잡고 특정한 방향을 향해서 탐색을 지속한다는 점이다. 이 문제 또한 비슷한 원칙을 적용하는 데 문제가 있다면 K의 크기가 N의 절반에 해당만해도 이대로 탐색을 한다면 O(N^2)의 시간복잡도가 성립한다는 점이다. 여기서 슬라이딩 윈도우를 이용하고 문자열의 길이가 최대 20이라는 점에서 착안하여 이러한 점을 해결할 수 있다. 상술하자면 K개의 배열을 가진 슬라이딩 윈도우 내에서 각 문자열의 길이를 저장하는 배열을 이용하여 새로 추가되는 배열과 동일한 길이를 가진 배열의 갯수를 세어가면 O(N) 시간 내에 풀 수 있다. 맵을 사용해도 O(NlogN)으로 가능하다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
 
int main () {
    fastio;
    ll n, k, ans = 0;
    cin >> n >> k;
    vector<ll> a(n);
    map<ll, ll> m;
    for (auto &i : a) {
        string s;
        cin >> s;
        i = s.length();
   }
    int l = 0;
    for (int i = 0; i < n; i++) {
 
        ans += m[a[i]];
        m[a[i]]++;
        if (i >= k) m[a[l++]]--;
 
 
 
    }
    
    cout << ans;
    
 
 
 
 
    
}
Colored by Color Scripter

cs

[BOJ] 백준 2637:장난감 조립

lecarap — Tue, 30 Aug 2022 20:42:44 +0900

https://www.acmicpc.net/problem/2637

2637번: 장난감 조립

첫째 줄에는 자연수 N(3 ≤ N ≤ 100)이 주어지는데, 1부터 N-1까지는 기본 부품이나 중간 부품의 번호를 나타내고, N은 완제품의 번호를 나타낸다. 그리고 그 다음 줄에는 자연수 M(3 ≤ M ≤ 100)이 주

www.acmicpc.net

1.문제 관찰

문제를 요약해보자면 기본 부품은 그 어떤 부품으로도 만들어지지 않는 부품이고 중간부품은 기본 부품+중간부품으로 구성되며, 완제품 또한 기본부품과 중간부품으로 이루어져있다. 이를 바탕으로 X라는 부품을 만들기 위해 Y 부품이 K개 필요하다는 걸 입력받은 뒤 완제품을 만드는 데에 사용되는 기본 부품의 구성과 숫자를 출력하는 문제이다. 잘 보면 각 부품 간의 의존관계가 성립한다는 것을 알 수 있고 여기서 K는 DAG에서의 가중치라고 보아도 좋다. 그러므로 이는 위상정렬 DP라고 볼 수 있다.

2. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, int> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
int d[101][101] = {}, ind[101] = {}; // dp 배열, indegree 배열 d[i][j] = 부품 i를 만들기 위해 필요한 기본부품 j의 갯수
vector<pi> g[101];
vector<int> basic;
 
int main () {
    fastio;
 
    int n, m;
    cin >> n >> m;
    queue<int> q;
 
    while(m--) {
        int a, b, c;
        cin >> a >> b >> c;
        g[b].push_back({a, c});
        ind[a]++;
    }
    
    for (int i = 1; i <= n; i++) {
        if (ind[i] != 0) continue;
        d[i][i] = 1;
        q.push(i);
        basic.push_back(i); // 기본 부품 저장
    }
 
    while(!q.empty()) {
        int cur = q.front();
        q.pop();
 
        for (auto i : g[cur]) {
            for (auto j : basic) {
                d[i.X][j] += d[cur][j]*i.Y;
            }
            ind[i.X]--;
            if(ind[i.X] == 0) q.push(i.X);
        }
    }
 
    for (auto i : basic) {
        cout << i << " " << d[n][i] << endl;
    }
    
 
}
Colored by Color Scripter

cs

[BOJ] 백준 13306번: 트리 C++ 풀이

lecarap — Tue, 23 Aug 2022 23:24:54 +0900

https://www.acmicpc.net/problem/13306

13306번: 트리

표준 입력으로 다음 정보가 주어진다. 첫 번째 줄에는 트리의 정점의 개수와 질의의 개수를 나타내는 두 정수 N과 Q (1 ≤ N, Q ≤ 200,000)가 주어진다. 다음 N-1개의 줄의 i번째 줄에는 정점 i+1의 부

www.acmicpc.net

오프라인 쿼리라는 알고리즘은 처음 들어보지만 얼마 전에 앳코더를 동일한 테크닉을 사용하는 문제를 풀어본 적이 있기 때문에 풀 수 있었다.

1. 문제 관찰

off-line 쿼리라는 이름에서 알 수 있듯이 쿼리가 주어질 때마다 자신의 부모와의 간선을 자르거나 두 정점이 연결되어 있는지를 판별하는 쿼리가 들어온다.

문제는 간선이 끊어질 후 두 정점이 같은 컴포넌트에 속하는지(이어져있는지)를 판별하려면 유니온 파인드나 dfs, bfs 등을 활용해야 할텐데 문제의 조건을 보면 알 수 있듯이 쿼리와 정점의 개수가 최대 20만이기 때문에 최악의 경우 O(NQ)의 시간 복잡도가 요구되기 때문에 시간제한을 넘게 된다.

그렇기 때문에 반대로 생각해보는 접근법이 필요하다.

2. 풀이

쿼리를 반대로 받는다면 기본적으로 모든 간선이 끊어져 있는 포레스트 상태에서 시작된다. 여기서 부모와의 연결을 끊는 쿼리가 들어온다면 이 쿼리가 들어오기 전에는 이어져있었다는 의미이므로 유니온 파인드를 이용해서 두 간선을 이어주고 정점 간의 연결을 확인하는 쿼리가 들어오는 경우 이어져 있다면 YES를 아니라면 NO를 스택에 저장해준다. 스택은 후입선출 구조이므로 뒤에서부터 빼면 원래 의도되었던 출력이 가능해진다.

유니온파인드를 통해 이어주기만 하면 되기 때문에 시간복잡도는 O(NlogN)이 성립하게 된다.

다만 주의할 점이 있다면 통상적으로 자주 쓰이는 유니온 파인드의 경우 동일여부 체크와 합병이 동시에 이루어지는데 이 문제의 쿼리의 경우 단순히 두 정점이 동일한 지 여부만 판단하는 것이기 때문에 구현을 달리할 필요가 있다.

3. 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

#include<bits/stdc++.h>
using namespace std;
#define endl '\n'
typedef long long ll;
typedef pair<int, pair<int, int>> pi;
#define fastio cin.tie(0)->sync_with_stdio(0)
#define X first
#define Y second
 
//------------------------------
 
 
vector<string> ans;
vector<pi> query;
int p[200100], v[200100];
 
int find(int a) {
    if (p[a] == a) return a;
    return p[a] = find(p[a]);
}
 
void merge (int a, int b) {
    a = find(a); b = find(b);
    
    if (a == b) return;
 
    p[a] = b;
 
}
 
 
 
int main () {
    int n, m, q;
    cin >> n >> m;
    q = n+m;
    
    // i+1 번째 정점의 부모를 입력받음
    for (int i = 2; i <= n; i++) {
        cin >> v[i];
    }
    // 쿼리를 반대로 받기 위해 저장
    for (int i = 0; i < q; i++) {
        int x, a, b;
        cin >> x;
        if (x == 0) {
            cin >> a;
            query.push_back({x, {a, 0}});
 
        }
        else {
            cin >> a >> b;
            query.push_back({x, {a, b}});
            
            
        }
    }
    // 유파 초기화
    for (int i = 1; i <= n; i++) p[i] = i;
    // 쿼리 시작
    
    reverse(query.begin(), query.end());
 
    for (auto i : query) {
        
        if (i.X == 0) {
            merge(i.Y.X, v[i.Y.X]);
        }
        if (i.X == 1) {
            if(find(i.Y.X) == find(i.Y.Y)) ans.push_back("YES");
            else ans.push_back("NO");
        }
 
    }
    
    // 반대로 돌려줌
    reverse(ans.begin(), ans.end());
 
    for (auto i : ans) cout << i << endl;
    
 
 
    
    
 
 
}
Colored by Color Scripter

cs