Now Loading ...
-
2024년 회고록
머리말: 2024년 1월 20일
1월 20일. JVM 생태계로 옮겨가자고 마음 먹었던 날이다.
2년차 개발자로서 그에 맞는 기본기를 갖추길 강하게 바라서 정했다.
더 알고 싶다. 프로페셔널하게 잘하고 싶다는 열망이 강했다. 선배 개발자들이 쌓아 놓은 길이 풍부하니, 차근차근 밟아 가다보면 많은 것이 채워지리라 생각했다.
이에 더해, 전체적인 삶도 더 건강하게 채워보기로 노력했다.
언제나처럼 한 해가 빠르게 지나갔다.
지난 시간의 결과들을 되돌아보고 올 해 목표를 새로 설정한다.
정형화된 것보단 내가 쓰기 편한 형태의 1년 회고를 남긴다.
생활 습관
2024년을 시작할 때 꼭 지켰으면 했던 몇 가지를 정했다. 어떤 것은 초과 달성했고 어떤 것은 조금 더 잘했으면 하는 아쉬움이 있다.
책 21권
24년 목표: 20권
24년 결과: 21권
25년 목표: 30권
1권 초과 달성으로 마무리했다. 아주 많다고 할 수는 없지만 달성한 보람이 크다.
접근성을 최대한 높여 한 번이라도 책을 더보게끔 유도했다. 독서용으로 구매한 아이패드 미니가 충분한 역할을 했다. 휴대성 덕분에 버스나 지하철안에서 한 번이라도 더 보게 되고, 자기전에도 한 번 더 손을 뻗고 읽게 된다.
먼지 타면 손이 잘안가서 최대한 전자책을 지향했는데 이것도 나한텐 효과적이었던 것 같다.
그리고 노션으로 서재를 만들어 정리하는 습관을 들였다. 시각적으로 내 서재를 볼 수 있으니 달성감이 생기고 짧게라도 정리하니 기억에 더 남는다.
내 서재
상반기에 비해 하반기에 독서 속도가 많이 느려졌던게 아쉬웠다. 특히, 기술 서적 읽을 때는 아무래도 시간이 걸리면서 상대적으로 텐션이 떨어지는데, 25년에는 더 전략적으로 시간을 분배해봐야겠다.
C-Level 분들의 연평균 독서량이 30권 이상이라는 기사가 있었다. 1달에 2권만 읽어도 24권인데 대단하다고 생각이 든다.
2025년에는 30권을 목표로 한다.
물론 단순 물량보다 실질적인 것이 중요하다.
잘 모르는 영역이 많은데, 25년에는 생활 법률이나 우주 카테고리에 대해서도 좀 더 관심을 가지려 한다. 특히, 투자 쪽은 작년보다 조금 더 깊게 공부할 계획이다.
주 3~4회 운동
24년 목표: 체지방률 15%
24년 결과: 체지방률 18.8%
25년 목표: 체지방률 15%
운동을 시작한지 1년 6개월이 지났다.
체지방률 26%에서 시작했고 근육량 2kg 증가, 체지방 5.5kg 감소시켜 체지방률 18%대에 진입했다.
주 3~4회씩 꾸준히 운동했던 점은 뿌듯한데, 목표에 3%가량 못미친 결과는 아쉬움이 남는다.
좋았던 기억은 애정하는 몇 가지 운동들의 최대 기록들이다.
턱걸이 횟수는 10개를 넘어갔다. 최대 16개를 했는데, 한 번도 못했던 옛날을 생각하면 정말 큰 발전이다.
벤치프레스 70kg을 찍은 것도 정말 기뻤다. 1RM이어서 아슬아슬했지만, 큰 성취감을 느꼈다.
기록을 위해 몇가지 최대 기록을 남겨둔다.
운동
최대 무게(횟수)
벤치프레스
70kg
풀업
16회
레그프레스
160kg
스쿼트
70kg
밀리터리 숄더프레스
40kg
어려웠던 점은 정체기다.
처음 3개월 PT로 배운 후 혼자 운동해나갔다.
1년 정도 철저한 식단과 함께 주 3~5회 운동을 했는데, 벌크업과 살찜 사이(?)의 균형을 찾는게 어려웠다.
지금은 무리한 섭취보다 체지방 조절을 가장 우선하고 있고, 체지방률이 감소하는 걸 보며 보다 건강한 느낌을 받고 있다.
사이사이 어깨 부상도 힘들었다. 잘못된 숄더프레스 및 벤치프레스 자세로 오른쪽 어깨가 반복적으로 문제가 생겼다. 처음엔 원인도 몰라서 관련될 법한 운동 영상, 의학 영상을 모조리 찾아본 기억이 난다. 시행착오 끝에 올바른 운동 자세를 찾으니 부상이 더이상 없더라. 신기한 경험이었는데, 운동은 자세가 정말 중요함을 체감했다.
어느덧 2년차도 넘어가니 여러 생각이 든다. 무리하지 않는 건강하고 꾸준한 운동이 제일인 것 같다.
25년 목표는 한번 더 체지방률 15% 달성이다.
다시 온 정체기를 뚫는게 올 해 목표가 될 것이다.
새벽 기상과 공부 패턴
새벽 기상이 일상에 많이 스며 들었다. 최소 7시간 수면 확보를 기준으로 일찍자고 일어났다.
요즘은 5시 50분으로 정착했다. 4시 50분 / 5시 50분 / 6시 30분 등 몇 가지 기상 패턴들이 다양하게 있었는데, 결과적으로 일찍 일어났을 때 조용한 환경으로 인해 집중도와 작업 진척도가 더 늘어나는 효과가 있었다.
모든 날을 완벽히 보내진 못했다. 4달은 새벽기상, 2달은 보다 늦은 기상, 3달은 다시 새벽기상 식의 반복이 있었다. 이런 부분은 크게 스트레스 받지 않으려 한다. 몸이 피곤하다는 신호가 있을 때는 충분히 자는게 건강에 이로운 것 같다.
올 해 기상 패턴도 5시 50분으로 늦춤 없이 그대로 유지해보려 한다.
추가로 습관 추적을 위해 하루 공부량을 측정하는데, 나무 심기가 재미를 준다.
개인적으로 Forest 앱을 좋아하는데, 매일 집중한 시간만큼 자신이 좋아하는 나무를 심을 수 있다.
나도 몰랐던 나무 취향(?)도 알게 됐다.
습관 추적은 많은 자기계발서에서 추천하는 방법이다. 습관 추적을 지원하는 다양한 앱 중 성숙한 서비스를 제공해서 추천한다.
포레스트 (Forest)
개발 공부
사실 한 해 동안 공부했던 모든 것들이 너무 유익했다. FastAPI 생태계에 있을 때는 어려웠던 레퍼런스 천국을 자바 생태계에서 경험했다.
선별한 강의와 책을 보면서 예제 코드를 백문이 불여일타하고 이론은 옵시디언을 활용해 학습기록용 블로그에 정리하고 있다.
회독법으로 접근하고 있다. 결국 4~5회독은 해야 장기 기억으로 완전히 남을 것이다.
지금까지 봤던 강의와 책은 최소 2회독한 상태이고, 새로운 것들을 계속 공부하면서 회독도 지속적으로 병행할 계획이다.
한 해 공부했던 책, 강의, 자격증 기록을 남겨본다.
기술 서적
24년에 읽은 기술 서적들이다. 사실 읽고 싶은 책이 더 많았는데 시간이 참 빠르게 지나간다.
기술 서적은 확실히 읽는 속도가 오래 걸린다. 두께가 있는 책들은 3~4주는 잡아야 2회독하는 패턴을 겪었다.
물론 충분히 필요한 절대적 시간량들이라 생각한다.
다만, 오래걸려서 텐션이 떨어지는 구간들을 좀 더 리듬감 있게 가져가도록 신경쓰려고 한다.
올 해는 아래 책들은 반드시 읽기로 계획했고 다른 책들은 상황에 맞게 필요를 조정하려 한다.
“Real MySQL” / “개발자를 위한 레디스” / “아파치 카프카 애플리케이션 프로그래밍 with 자바”
강의
영한님 강의는 최대한 다 듣고 싶었는데 2개 강의가 아직 남았다 (실전 자바 고급 2편, 스프링 부트 핵심 원리)
솔직히 정말 좋았다. 실무를 한 번 겪고 왔기 때문에 그동안 풀리지 않았던 고민들과 가려웠던 부분들이 많이 해소됐다. 교육 비용은 아끼지 말자.
해야할 것들이 많으니 우선순위를 잘 지정해서 남은 강의도 올 해 적절한 시점에 마무리해야겠다.
돌아보면 한 해 동안 인프런 이용을 참 많이했다.
큰돌님 CS는 분량이 정말 어마어마했는데, 그만큼 CS 대비를 풍부하게 할 수 있어 좋았다. 아직 내재화해야할게 많아서 핵심을 다시 한 번 추려서 회독해야겠다.
동시성 강의들도 좋았다. 멀티스레드 디자인패턴이나 레디스 분산 락 등 이론과 더불어 다양한 동시성 제어 전략을 알 수 있어 폭을 넓힐 수 있었다.
DB 설계 강의도 테이블 설계 전략을 머릿속에 일관성 있게 정립할 수 있어 도움이 많이 됐다.
자격증
24년에는 SQLD와 정보처리기사 2개를 합격했다.
시간이 길어지는만큼 기본적인 것들은 이럴 때 최소한의 시간으로 그냥 가져가자고 목표했다.
정보처리기사는 실기 90점으로 나름 고득점 합격했던게 소소한 즐거움이었다. 점수는 의미가 없지만 잠깐의 기쁨은 동기부여에 도움이 된다.
올 해는 AWS Associate 솔루션 아키텍트를 치를 계획이다. 하다보면 또 보이는 것이 있을거라 생각해 자격증 관련해서도 유도리 있게 한 해 목표를 수정해야겠다.
맺음말
생산성에 대한 생각을 많이 한다. 방대한 세상을 어떻게 체계적으로 정리하며 살아갈까에 대한 고민이다. 한 해 동안 개발에 관해서도 삶에 관해서도 건강해지기 위해 노력했다. 그리고 향상된 부분을 가시화하기 위해 신경썼다.
지난 1년을 거치며 보다 건강한 상태가 됐다는 점에 칭찬한다. 새로운 동기부여가 되는 지점이다.
2024년은 혼자의 시간이지만 프로페셔널함을 생각하며 보냈다. 엔지니어로서는 직업 윤리로서 기술적 탁월함을 추구했고 한 개인으로서는 삶의 전반적인 토대를 다시 다졌다.
2025년 회고 때는 과정을 발판 삼아 가치 있는 결과물을 남기고 기록하길 기도한다.
-
정보처리기사 92점 합격수기 - 인프런
주말 코딩님 덕분에 정말 “효율적”으로 실기 합격했습니다!
가채점 점수 92점, 발표일에 합격인증까지 올리겠습니다~😀
10월 20일에 있었던 3회차 정보처리기사 실기를 막 마치고 얻은 점수입니다.
약 1주일 간 주말코딩님 인프런 강의와 함께하며 정보처리기사를 준비했구요 (대략 10일)
가장 큰 목표인 “최소비용”, “효율” 중시로 시험을 준비했던 과정을 공유해보려고 합니다.
우리 모두 바쁘자나요~
고득점 목표는 정말 전혀 없었는데 주말코딩님과 핵심만 집중하다보니 덤으로 얻었다고 생각해요
1. 학습 목표
저한테 가장 중요했던 것은 “최소비용 및 시간으로 안정적인 합격하기” 였어요.
시중 책들이나 강의가 불필요하게 깊게 파고 비싸서 시간과 비용이 아깝다고 느꼈어요
(몇 백페이지 어떻게 다보나요… 필기도 CBT로 기출만 풀고 넘어왔습니다)
자격증 공부는 실질적인 개발 공부와 다른 측면이 있으니 자격증 준비는 정말 최소한의 비용으로 해야겠다고 마음 먹었습니다.
부가적으로 C언어 메모리 관련 지식과 CS 큰그림 정리만 얻자는 마음으로 준비했어요
그런 점에서 주말코딩 님 강의는 저의 목표와 매우 적합했습니다!
주말코딩 님도 수강생들에게 핵심만 집중적으로 공략해서 빠르게 합격하길 원하셨거든요.
모두 다른 할 일들이 많으니까요!!
(주말코딩 정처기 인프런 강의: https://u.inf.run/3Bu7c2O)
2. 강사님 성향 & 실제 체감한 시험 경향
강사님 기본 전제는 100점 중 60점 넘으면 통과이므로
전체 5~60% 비중인 코딩 영역은 최대한 다 맞추자 (1개정도의 킬러문제는 그냥 틀리자)
이론 영역은 찍기도 가능하니 1~2개만 맞추자
를 강조하십니다.
납득이 되고 매우 합리적인 전략이에요.
이론 영역에 대해 조금 더 생각해볼 부분은 강사님께서 조금 보수적으로 잡고 말씀하신 부분이 있고, 실제 공부하다보면 이론은 1~2개보다 충분히 더 맞출 수 있습니다.
강사님이 중요한 부분만 정리한 총 1~2시간 정도 강의와 20페이지 정도되는 이론 요약집 제공해주세요. 항상 빈출되는 5~10가지 유형만 확실히 정리하고 가도 안정적으로 점수 추가 가능하다고 느꼈어요.
이외 나머지는 대차게 틀리면 됩니다! 다 맞출 필요가 없으니까요 🤣
사람이니까 코딩영역 실수해서 조금 더 틀려도 합격권 넉넉할거라고 느껴요.
코딩 영역은 주말 코딩님 이전 명성도 있고 실제로 강의를 워낙 잘해주셔서 정말 킬러 문항 1개만 틀리고 다 맞을 수 있습니다! 비전공자지만 독학한 베이스가 있긴해서 운좋게 킬러 문제도 건졌어요
실제로 시험을 봐보니 최근 시험 경향이 코딩 난이도를 높이고 이론은 너무 어렵게 안내는 느낌이 들었습니다.
이론이 최근 기출 포함해 항상 나오는 문제 주제로 5~10개 풀 정해놓고 돌려서 나오는 경향이라 그 부분만 확실해도 얘기했던 기존 목표인 이론 1~2개 맞추기보다 더 맞출 수 있을 것 같습니다.
결과적으로 코딩 문제는 다 맞추고, 이론에서 8점 깎였어요 (한 문제 틀리고, 한 문제 부분점수)
“코딩만은 확실히”를 지향하는 주말 코딩님의 방식은 매우 타당했습니다
3. 공부 방법
당시 10일 정도 남았었고 2~3일 보통 숨고르기 시간으로 날리잖아요~ 하하하
그래서 저는 공부 전략을 다음과 같이 잡았습니다.
[강의 중요 부분 수강 + 강사님 이론 요약집 외우기 + 이론만 잽싸게 기출 보기]
[강의 중요 부분 수강]
강의는시간 관계상 부가적인 부분만 제끼고 최대한 들었습니다. (75프로 수강했네요)
비전공자지만 개발경험은 있어서 앞에 언어 공통 문법 부분이랑 뒤에 고난도 코드영역의 정렬만 제꼈습니다. (정렬 문제는 개념몰라도 주요 강의 내용만으로 코드 풀 수 있어요)
코딩 기출문제 풀이 강의는 무조건 하루 한개씩 들었고
다만 시간 관계상 강사님 C, Java, Python 변형문제 강의는 못들었어요 (기출 강의 중간중간에도 변형 문제는 소개해주셔서 다행히 괜찮았던 것 같아요)
고난도 코드영역에 SQL 기출문제는 꼭 챙겨봤습니다.
이렇게만 공부해도 코딩 + DB 영역 50점은 먹고 가요 (주말코딩 님 그는 정말…)
시험 3~4일전 강사님 이론 강의를 살살 듣기 시작했는데요 운영체제 페이지 교체 부분부터 정리했어요
기출보니 요즘 자주 나오더라구요! 요 영역이 조금 빡세보여도 강의듣고 하면 풀만해서 5점 가져가는 것 같아요
그리고 결국 시험 기간 이틀 전에서야 빡세게 이론 강의 완강하고 그 후 이론 요약집만 달렸어요 (머릿 속 이상적 계획과의 괴리…)
[강사님 이론 요약집 외우기]
이론은 강사님 강조해주시는 영역 몇가지 있어요
주요 포인트
결합도/응집도, 테스트 스텁 및 드라이버, 테스트 종류와 방식 (블랙/화이트), 라우팅 프로토콜(RIP, OSPF…), 데이터베이스 이론(로킹, 상호배제 조건 등)…
시간 날 때 나머지
보안용어와 암호화 기법, OSI 7계층
주요 포인트만 확실히 하고 간다 생각했고 (결합도/응집도, 테스트 종류 방식 진짜 맨날 나와요)
추가로 디자인 패턴만 설명보고 용어 쓸 수 있게 준비했습니다. (+위에서 강의로 봤던 페이지 교체 부분도요!)
시간 날 때 나머지 부분도 요약집 내에서만 준비했어요
OSI 7계층에 용어들만 키워드 위주 암기 미리했고 (계층 이름, ARP, RARP, ICMP, IGMP 정도),
보안용어 암호화 기법은 시험가기 전 30분정도만 봤습니다. (운에 맞기고 틀려요 그냥~)
그래도 필기 때 한번 봤던 내용들이라 익숙함은 있더라구요
[이론만 잽싸게 기출 보기]
코딩 영역은 강의 기출 풀이로 거의 충분해서
이론 공부 병행하면서 이론 기출만 23년~24년도 빠르게 확인해봤습니다.
강의나 요약집에서 이미 봤던 기출도 있고 해서 이쯤이면 금방 빠르게 볼 수 있어요.
뉴비티 사이트가 필기 공부할 때 썼던 CBT 처럼 잘되어 있어서 공부하는 동안 잘 활용했어요.
(뉴비티, https://newbt.kr/%EC%8B%9C%ED%97%98/%EC%A0%95%EB%B3%B4%EC%B2%98%EB%A6%AC%EA%B8%B0%EC%82%AC+%EC%8B%A4%EA%B8%B0))
4. 마무리
처음에는 실기 준비 어떻게 공부할지 고민했습니다. 아는 지인은 시중에 수제X 책 사서 했다더라구요.
제 성향에는 비효율적인 방법이었어요 컴팩트한 시간을 매우 중요시하는데 핵심을 벗어나 너무 폭넓게 공부해야 하니까요.
유튜브 검색을 통해 어쩌다 주말 코딩 님을 알게 되었는데, 강사님의 효율적인 학습 지향점을 듣고 바로 납득하고 강의 수강을 정했습니다.
플랫폼도 개발 컨텐츠에 친화적인 인프런이니까 수강기간 걱정없이 들을 수 있는 점이 신뢰와 안정감을 줬구요.
덕분에 처음 목표인 안정적 합격도 이뤘지만 보다 과하게 93점을 받았는데, 주말 코딩님 지향점의 장점 덕분이라 생각합니다.
언제나 느끼지만 핵심이 중요하다고 생각해요.
제 시험 준비 기록이 정보처리기사 준비하시는 다른 분들의 시간 절약 및 정신적 건강에 조금이나마 도움이 되었으면 좋겠습니다. (기록에는 시간을 아끼지 않았거든요 하핳)
준비하시는 모든 분들 파이팅하시고 쾌속 합격하시길 바랍니다!
Reference
[인프런 주말코딩] 일주일만에 합격하는 정보처리기사 실기
[뉴비티] 실기 기출 풀이 플랫폼
-
2024 당근 테크 밋업 후기
2024 당근 테크 밋업 후기
올 해 운은 2024 당근 테크 밋업 당첨에 몰아서 다 쓴 모양이다.
당첨이 정말 어렵다고들 하는데 운 좋게도 생애 첫 밋업의 기회를 얻었다. 덕분에 기다리는 순간부터 오늘까지 설레고 유쾌한 시간의 연속이었다.
나이스한 당근 엔지니어 분들과의 만남, 만족스러운 럭키 드로우 등 흥미로운 일들에 대한 경험담을 살짝 남긴다.
Frontend, Server, Data/ML, Platform 4가지로 파트가 나누어져 있었는데, 나는 서버 파트로 참여했다.
코엑스 컨퍼런스룸 3층으로 가니 예쁜 서체와 함께 행사장이 꾸며져 있었다. 입구부터 당근의 느낌(?)이 물씬 풍기는게 맘에 들었다.
입장할 때는 스태프분들이 팔에 당당한 밋업 참가자의 징표를 휘감아주었다. 뿌듯한 한 컷이다.
여담이지만, 행사장의 당근 관계자 분들은 다들 매우 친절하고 단합력이 좋았다.
서버 파트 강연 진행은 308호 공간에서 진행했는데, 도착하자마자 자리 잡고 강연을 듣는 형태였다.
다만, 이번 당근 밋업의 조금 특별한 점으로 당근 엔지니어가 주도하는 네트워킹 모임이 있었다.
규모는 4~8명으로 모임마다 다양하다. 밋업 몇 주 전부터 선착순으로 약 70개 넘는 주제로 네트워킹 참여 모집을 했는데, 실제로 행사 당일에 관련 주제를 가지고 서로의 경험과 대화를 나누는 네트워킹을 진행했다. (덕분에 당근 어플 모임 기능과 익숙해졌다.)
나는 주문 서비스에서 일한 경험이 있어, 당근페이 머니서비스 팀 네트워킹에 참여했다.
주문 서비스는 안정성과 데이터 정합성이 매우 중요한데, 당근페이 같은 큰 규모에서는 어떻게 관리하고 있는지 궁금했다.
모임을 주도하는 머니서비스팀 엔지니어 윈터, 윌리엄은 매우 나이스한 분들이었다. 당근페이에서 일했던 경험들을 자연스럽게 나누며 어떻게 생각하는지 참여자들과 서로 묻고 답했다. 함께 모인 다양한 개발자 및 기획자 분들도 유익한 질문들을 많이 던져주시더라.
이런 형태의 네트워킹이 처음이라 긴장을 많이 했는데, 화기애애한 분위기 속에서 머니서비스 팀이 극복했던 이슈와 앞으로의 목표를 진솔하게 들을 수 있었다.
잠시지만 좋은 분들과의 만남에 감사함을 가졌다.
첫 밋업이어서 이후에는 강연에 집중했다. 아직은 이해가 잘 되지 않는 내용도 많았지만 이런 이런 키워드들이 있구나를 알게된 것도 도움이 되었다.
“빠르게 변하는 도메인에서 살아남는 코드”라는 주제도 재밌었다. 당근 운영개발팀은 루비 레거시의 압박 속에서 확장성과 설정 가능성을 목표로 최대한 OCP를 지키는 리팩터링을 했는데, 과정 속에서 메타 프로그래밍으로 접근한 점이 흥미로웠다. 리플렉션 같은 느낌으로 런타임에 코드 자체를 동적으로 변경하며 기능을 확장했는데, ‘현업에서 이렇게 적용할 수도 있겠구나’ 고민해보며 생각을 확장할 수 있었다.
마지막 세션인 “당근의 회원 시스템을 마이크로서비스로 분리하기”에서는 당근 Identity Service 팀이 회원 서비스를 안전하게 분리하기 위해 진행한 디테일한 테스트와 도구들을 소개했다. 안정성을 위해 굉장히 디테일한 부분까지 신경쓰는 점이 인상 깊었고, 덕분에 대규모 서비스에서는 얼마나 신중하고 단계적으로 접근해야하는지 느끼는 시간이었다.
큰 규모에서는 생각하는 각도가 더욱 중요하겠구나 싶다.
기쁘게도 젯브레인 에코백이 내게 왔다.
강연 중간중간마다도 이벤트가 있었는데, 마지막에는 설문조사에 참여한 모든 참여자에게 럭키 드로우 찬스가 주어졌다. 품목으로는 젯브레인 배지, 키캡, 스티커, 에코백 등의 경품이 있었다. 키캡이 매우 인기 있었지만, 개인적으로 개발자스러운 패션 굿즈로서 에코백이 가장 갖고 싶었다.
신기하게도 단번에 뽑았는데, 돌아봐도 당첨 운이 참 좋은 밋업 기간이었다.
밋업과 연관은 없지만 마지막엔 코엑스 내 클로리스 티 룸에 들려 밀크티 프로즌을 마셨다.
예전부터 좋아하는 곳인데 밀크티 음료 조합이 독특하고 맛이 참 좋다. 코엑스에 갈 일이 있다면 강력 추천한다.
2024 당근 밋업은 생애 첫 밋업이어서 더욱 기억에 남는다. 약 1000명에 가까운 IT 업계 종사자들이 한데 모이는 모습이 신기하면서 기분 좋은 자극이 되었다.
또한, 당근 엔지니어 분들의 기술에 대한 열정, 동료들과의 화목함을 보며 당근의 분위기가 참 좋다고 느꼈다.
앞으로 어떤 곳에서 일할지 모르지만, 당근 같은 건강한 분위기에서 또 다시 개발하길 다짐한다.
-
안전한 JWT 발급에 유의해야할 점들
Intro
현재 회사 프로젝트에서 JWT를 사용하면서, JWT를 쿠키로 안전하게 보내기 위해 겪었던 혼란들을 기록해보고자 합니다.
HttpOnly 옵션
기본적으로, access token과 refresh token은 서버에서 HttpOnly 옵션을 사용해 쿠키로 발급해주는 것이 바람직합니다. 이는 클라이언트에서 JS를 통해 쿠키로 접근하는 것을 막아주는 옵션이며, JS 코드를 심어 악의적인 명령을 실행하는 XSS(Cross Site Scripting) 공격을 예방할 수 있습니다. (글로벌 변수인 document를 사용해 document.cookie로 접근하는 것을 막아줍니다.)
Secure 옵션
서버에서 Secure 옵션을 사용해 JWT를 보냅시다. Secure는 쿠키가 HTTPS 프로토콜에서만 보내지도록 합니다. HTTP에서는 전송 중간에 쿠키가 탈취될 위험이 있기 때문에, 안전하게 HTTPS에서만 보내질 수 있도록 설정합니다.
SameSite 옵션
무언가 JWT가 잘 발급되지 않는다 싶으면, SameSite 옵션을 꼭 의심해봅니다. 서버에서 SameSite=None을 설정해 JWT를 보냅시다. 특히, Chrome 브라우저는 SameSite의 default 값이 lax로 되어 있는데 이로인해 cross-site 간의 request에 cookie가 보내지지 않을 수 있습니다.
allow-origins, allow-credentials
서버에서 CORS관련 설정들을 잘 세팅합시다. allow-origins에는 CORS를 허락할 클라이언트의 주소를 꼭 입력해줍니다. allow-credentials 옵션도 True로 설정해, 쿠키가 잘 보내질 수 있도록 합니다.
클라이언트가 HttpOnly 쿠키를 사용하는 방법
클라이언트가 HttpOnly 쿠키를 서버로부터 전달 받았다면, 이후 해당 HttpOnly 쿠키는 클라이언트가 어떠한 request를 보낼 때마다 자동으로 쿠키에 담겨 보내집니다. 이 때, 클라이언트에서 withCredentials=True를 설정하고 request를 보내야 쿠키가 올바르게 전송 됩니다. Access token과 refresh token이 자동으로 담겨지는 점이 편리하죠!
Outro
직접 주어진 실무 문제는 아니었지만, 문제 해결에 함께 참여하고 개인 프로젝트에서 잘 되지 않았던 점들을 되짚어 보면서 많은 공부가 되었습니다. HttpOnly 쿠키로 JWT를 보낼 때, 여러가지 조건이 갖춰져야 비로소 올바르게 전송됩니다. 생각보다 장애물이 많은데, 잘 기록해둬야 나중에 같은 문제를 마주했을 때 덜 헤맬 것 같습니다 :)
-
Poetry typed package를 mypy가 인식하려면? feat. py.typed
Intro
최근 몇 주간은 회사 업무 중 트러블 슈팅이 특히 많았습니다. 그 중 가장 기억에 남았던 것은 import한 poetry 패키지의 타입을 mypy가 제대로 인식하지 못하는 문제였습니다.
해당 문제는 MSA로 개발 중인 프로젝트에서 발생했는데, 각 서비스에서 공통으로 쓰이는 class들을 하나의 패키지에 담는 과정에서 나타났습니다. 이는 py.typed 파일을 추가함으로써 생각보다 간단히(?) 해결할 수 있었는데, 그 과정을 남겨보고자 합니다.
Problem
Poetry로 빌드된 패키지를 개발 중인 서비스로 import 하고 mypy로 type checking하니, 위와 같이 무수한 type error가 발생했습니다. :(
우선, 관련 error는 mypy extension package 중 하나인 sqlalchemy2-stubs의 적용이 제대로 이루어지지 않아 발생한 에러였습니다. 서비스 내에는 잘 install 되어 있었기 때문에, 처음엔 패키지 내에서도 sqlalchemy2-stubs를 설치해야 하나 고민했습니다. 하지만, 패키지 내의 dependecy 설정으로도 에러는 해결되지 않았습니다.
결국 sqlalchemy2-stubs 자체보다는 타입 인식 자체가 잘 안되는 이유를 찾아야 했습니다.
Solution
실제로 문제의 해결은 py.typed 파일의 존재 유무에 있었습니다.
문제가 되었던 패키지의 디렉토리 구조는 다음과 같았습니다.
|- project-core
|- dist
|- project_core
|- __init__.py
|- package_content...
|- __init__.py
|- pyproject.toml
그리고 실제 패키지 내용에 해당하는 디렉토리 내의 최상단에 내용이 비어있는 py.typed 파일을 수동으로 생성해주면, mypy가 패키지 코드의 type annotation을 인식하기 시작합니다.
|- project-core
|- dist
|- project_core
|- py.typed
|- __init__.py
|- package_content...
|- __init__.py
|- pyproject.toml
패키지와 관련된 type checking 수단을 제안하는 PEP-561에도 py.typed에 대한 내용이 명시되어 있습니다. (poetry 뿐만 아니라 범용적으로 적용됩니다.)
우선 지금 문제 상황은 3번에 해당할 것입니다. 즉, package maintainer(패키지 관리자)가 자신의 패키지 코드에 외부의 stub file이 적용되길 원하는 경우입니다. (여기서 stub은 type information만이 담긴 파일을 의미합니다.)
이에 따라, 현재 서비스의 sqlalchemy2-stubs가 패키지에도 적용되길 원합니다.
PEP-581은 이를 위해 패키지 관리자가 package의 top-level에 py.typed라는 marker file을 생성해야 함을 전달합니다. (MUST)
사실 문제를 해결하는 다른 방법도 존재하겠지만(MYPYPATH에 site-packages를 추가하는 방법 등…), 간단하고 편한 방법이 있으니 굳이 사용하지 않을 이유가 없을 것 같습니다.
Outro
아직 package를 만들어 본 경험이 없었는데, 덕분에 package 빌드 방법에 조금 더 익숙해진 것 같습니다. 이와 더불어 package를 올바르게 배포하기 위해 다양한 요소들이 필요함을 느꼈습니다. 익숙함이 쌓이다보면 언젠가 작은 오픈소스를 배포하는 날도 오지 않을까 기대되네요 :)
결론입니다. Typed package에는 항상 py.typed를 추가해주세요!!
Reference
Don’t forget py.typed for your typed Python package
PEP-581 Packaging Type Information
-
서버에서 JWT를 안전하게 발급하는 방법은 무엇일까?
Intro
이전 개인 프로젝트에서 JWT로 로그인을 구현할 때, access token을 response body에 담아 보낸 기억이 있습니다. 사실 httpOnly 쿠키로 보내려고 했지만, 그 때는 서버에서 전달받은 쿠키를 프론트에서 어떻게 사용해야 할지 방법을 찾지 못해 불가피하게 이용한 방법이었습니다. (여러 JWT 인증 예제에서 request body로 access token을 보내는 경우가 심심치 않게 보인 점도 한 몫했습니다.)
JWT의 access token은 서버에서 httpOnly로 보내는게 무조건 옳은 것일까? 프론트에서는 httpOnly로 받은 access token을 어떻게 처리할까? Response body로 보냈을 때 생기는 문제는 무엇일까? 해결하지 못한 고민들은 계속 남아 맴돌기에, 이번 기회에 가볍게 정리해보고자 합니다.
XSS(=CSS), CSRF(=XSRF)
먼저, JWT에서 주요하게 이슈가되는 기본적인 보안 문제는 XSS와 CSRF 공격입니다. 따라서, 단순하게는 XSS와 CSRF를 막는 방식으로 접근하는 편이 바람직해보입니다.
XSS(=Cross Site Scripting)
해커가 JS같은 스크립트 코드를 URL 혹은 Input에 악의적으로 삽입해 피해자의 웹브라우저에서 실행시키는 공격을 말합니다.
피해자의 브라우저에 저장된 중요한 정보들을 빼내올 수 있습니다.
CSS가 이미 약자로 있기 때문에, XSS라고 더 많이 불리는 것 같습니다.
보통 중요한 데이터를 전송할 때 httpOnly 쿠키를 사용하면, XSS 공격을 막을 수 있습니다.
CSRF(=Cross Site Request Forgery)
해커가 정상적인 request를 가로채 피해자인척하고 변조된 request를 서버에 보내, 서버에서 악의적인 동작을 수행하도록 만드는 공격을 말합니다.
피해자의 개인정보가 수정 및 유출, 원치 않는 광고성 포스팅 작성 등의 피해가 있을 수 있습니다.
프론트와 httpOnly 쿠키 옵션
서버에서 쿠키를 설정할 때 (set_cookie) httpOnly 옵션을 줄 수 있습니다. 서버에서 httpOnly를 적용해 쿠키로 보낸 값들은 클라이언트에서 직접 접근이 불가능합니다. (document.cookie로 접근 불가능) 다만, 이후 request를 할 때마다 해당 쿠키가 자동으로 쿠키 헤더에 담겨 request와 함께 보내집니다.
httpOnly는 JS로 쿠키에 접근할 수 없으므로, XSS 공격을 막을 수 있습니다. 반면에, 매 request마다 자동으로 쿠키 헤더에 담겨 보내지는 특징 때문에 CSRF 공격에 취약점을 가질 수 있습니다.
Secure 쿠키 옵션
Secure은 클라이언트 혹은 서버에서 https에서만 쿠키를 전송할 수 있도록 허용하는 옵션입니다. httpOnly는 클라이언트에서 JS를 통한 탈취 문제는 해결할 수 있지만, 네트워크를 직접 감청하여 쿠키를 가로채는 공격을 막을 수 없습니다. 특히, http에서는 데이터가 암호화되지 않고 전달되기 때문에, request나 response가 중간에 탈취당하면 그대로 데이터를 노출하게 됩니다.
따라서, 데이터가 암호화되어 보내지는 https에서만 통신 가능하도록 secure 옵션을 설정할 필요가 있습니다.
JWT를 발급하는 경우의 수
경우의 수는 refresh token과 access token을 모두 사용하는 것을 기준으로 고려합니다.
Case 1 - refresh token, access token을 모두 httpOnly 쿠키로 보내기
access token을 httpOnly 쿠키 헤더로 보내면, XSS 공격을 충분히 막을 수 있습니다.
httpOnly이기 때문에, 프론트에서 JS를 통해 쿠키에 접근할 수 없고 해커도 이를 이용할 수 없습니다.
refresh token도 마찬가지입니다.
반면 CSRF에 취약합니다.
Request에 access token이 항상 자동으로 담겨 보내지므로, request를 위조하는 CSRF를 막기 어렵습니다.
refresh token도 마찬가지입니다.
Case 2 - refresh token은 httpOnly 쿠키로, access token은 response body로 보내기
access token은 프론트에서 클로저 등을 통해 private variable로 저장하고 관리합니다.
이 때, XSS, CSRF 문제는 없어집니다.
혹시나 https 이외의 통신이라면 response body의 중간 탈취 위험은 있을 수 있지만, refresh token은 탈취되지 않기 때문에 유효 기간이 짧은 access token만 탈취되고 이후 갱신은 어려울 것입니다.
다만, 새로고침이 일어날 때마다 access token이 휘발성으로 사라지기 때문에, refresh token으로 새로운 access token을 발급받아야 합니다. (access token 유효기간의 의미가 사라지는 것 같기도…)
refresh token의 경우
httpOnly이므로 XSS 공격 문제가 없습니다.
Request에 refresh token이 항상 자동으로 담겨 보내지지만, CSRF를 시도해도 해커는 access token을 알 수 없습니다.
해커가 refresh token을 사용해 새로운 access token을 서버에 요청할 수는 있어도, response body로 날라오는 access token은 해커가 아닌 사용자에게로 갈 뿐입니다.
Case 3 - refresh token, access token을 모두 response body로 보내기
access token과 refresh token을 프론트에서 클로저 등을 통해 private variable로 저장하고 관리합니다.
새로고침이 일어날 때마다 refresh token과 access token이 사라지므로, 로그인 유지가 되지 않습니다.
즉, XSS, CSRF 공격 위험과 멀어지지만 로그인 기능과도 멀어(?)집니다.
만일 https 이외의 통신이라면, access token 뿐만 아니라 refresh token까지 탈취당하여 더 오랜 기간동안 위험할 수 있습니다.
Outro
결론적으로 위 Case 중에서는 Case 2가 보안상으로 가장 best한 방법으로 생각됩니다. 다만, 새로고침 시 access token이 유지되지 않는 점에서 다시 cookie의 필요성이 생각나는 무언가 아쉬운 부분이 느껴집니다.
이 포스팅은 더 좋은 방법을 알게될 때마다 계속 업데이트해 나가야 할 것 같습니다 :)
Reference
JWT는 어디에 저장해야할까? - localStorage vs cookie
프론트에서 안전하게 로그인 처리하기 (ft. React)
01. 시큐리티 - HTTP Only 와 Secure Cookie
-
WSL2로 Windows에서 Linux 사용하기
Intro
Windows는 멋진 OS입니다. Windows 덕분에 개발의 첫 발자국을 뗄 수 있던 사람은 아주 많을 것입니다!
다만, Windows 환경에서 개발을 진행하다보면, 생각치 못한 에러를 마주칠 때가 참 많습니다. 특히 Mac OS 환경에서는 자연스럽게 넘어가던 일들이 왕왕 막힐 때는, 고구마 5개가 식도에 함께하는 기분을 느끼게 됩니다(?)
이러한 참사를 막기 위해, Windows 위에서 리눅스를 매끄럽게 사용할 수 있게 도와주는 WSL2가 존재합니다.
WSL2란?
WSL은 Windows Subsystem for Linux 2의 줄임말로, 윈도우의 가상화 기능을 활용해서 윈도우 위에서 리눅스를 사용할 수 있게해줍니다. 단순히 가상머신으로 리눅스를 사용할 수 있는 것이 아니라, 윈도우 시스템과 통합되어 마치 하나의 머신처럼 자연스럽게 리눅스를 활용하는 것이 가능합니다.
- LainyZine: 프로그래머 가이드
Requirements
Windows 10 버전 요구사항: 20H1 이상
Windows 사양 확인
Windows + S 키로 검색 탭을 열어 PC 정보를 검색합니다.
PC 정보의 아래 쪽에 Windows 사양 부분에서 버전을 확인합니다. 현재 20H1, 20H2, 21H1 등에서 WSL 사용이 지원됩니다.
WSL2 활성화 및 Ubuntu 설치
WSL2 설치를 위해 가상 터미널을 이용합니다. 이 때, 가상 터미널로 Windows Terminal을 설치해 사용하면 이후 WSL 사용도 편리해집니다. 없을 시엔 Windows PowerShell을 사용합시다.
Windows + S 키로 Windows Terminal이나 PowerShell을 검색한 후, 우 클릭하여 ‘관리자 권한으로 실행’을 클릭합니다.
다음 명령어를 실행해 WSL 기능을 활성화합니다.
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
Microsoft Store에 들어가 원하는 버전의 Ubuntu를 설치합니다.
활성화 적용을 위해 컴퓨터를 재시작합니다.
다운받은 Ubuntu를 실행하고 설치 완료 메시지까지 약간 기다립니다.
계정 정보 입력 메시지가 뜨면, 새로운 Ubuntu OS에 대한 새로운 계정을 만듭니다. (기존 Windows 정보와 전혀 상관없이 새 계정을 만들면 됩니다.)
이후, 다음 명령어를 사용해 활성화 되어 있는 WSL을 WSL2로 업데이트합니다. (관리자 권한 실행)
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
컴퓨터를 재시작합니다.
다음 명령어를 사용해 WSL2를 기본 버전으로 설정합니다. (관리자 권한 실행)
wsl --set-default-version 2
만일 커널 구성요소를 다운로드하라는 메시지가 나오면, 해당 링크로 가서 커널 업데이트 패키지를 다운로드 받아 install하고 다시 wsl --set-default-version 2 명령어를 실행합니다.
다음 명령어를 사용해, WSL에게 Ubuntu에 WSL2를 사용할 것이라는 것을 알려줍니다.
wsl --list --verbose를 통해 현재 설치된 ubuntu의 버전을 확인할 수 있습니다.
wsl -l -v로 현재 설치된 리눅스를 확인해볼 수 있습니다.
wsl --set-version Ubuntu-18.04 2식으로 명령을 실행합니다.
혹시 BIOS에서 가상화가 사용가능하도록 설정하라는 메시지가 뜨면, 구글 검색을 통해 가상화 설정을 진행하고 다시 명령어를 실행합시다.
Customizing Linux Shell
WSL2을 통한 Ubuntu의 초기 리눅스 쉘 상태는 굉장히 ugly합니다. 따라서, 몇 가지 기본세팅이나 UI 적용을 통해 보다 깔끔한 터미널을 만드는 것도 매우 좋을 것입니다.
다음 링크에서 원하는 customizing을 참고하시길 바랍니다.
Nomad Coder WSL Setup
Outro
Windows 환경에서 개발함에 있어 WSL2는 단비 같은 툴입니다. 개발에만 집중하기도 모자른 시간을 환경적 에러에서 소모할 필요는 없습니다. 그렇지만 Windows라고 개발에서 배제(?)될 필요도 없습니다. 다만, Windows를 쓰시는 개발자라면 WSL2로 초기 환경을 세팅하고 개발하시길 권합니다 :)
Reference
Nomad Coder WSL Setup
LainyZine: 프로그래머 가이드
-
Secret key를 숨기는 통상적 방법
Github 같은 public한 장소에 프로젝트를 배포할 때, secret key같은 private한 정보들은 숨겨서 배포해야 합니다. 이를 위한 통상적인 방법은 환경변수를 이용하는 것입니다. 하나의 파일에 private한 정보들을 몰아놓으면, 프로젝트를 실행하기 전마다 해당 파일을 사용해 환경변수를 등록해둘 수 있고 아무일 없었듯이 프로젝트를 실행할 수 있습니다.
대표적으로 secret key를 숨기기 위해서는 secret key를 담을 secret_bash 파일, 등록된 secret key 환경변수를 가져올 settings.py파일, .gitignore 파일 총 3가지가 필요합니다. (secret_bash와 settings.py의 이름은 임의로 변경 가능합니다.)
아래는 임의의 Python 프로젝트 구조의 예시입니다.
my_super_project - app - main.py
| |_ settings.py
|_ .gitignore
|_ secret_bash
과정
해당 과정은 리눅스 기반에서 진행합니다. 사용되는 secret key는 PostgreSQL과 관련있는 예시입니다.
1. secret_bash 생성 및 설정
프로젝트의 최상위 디렉토리 밑에 secret_bash 파일을 생성하고 secret key 정보를 담습니다. 파일 내에 export 명령어를 사용하는 이유는 프로젝트를 실행하기 전마다 해당 파일을 실행해 secret key를 환경 변수로 등록할 수 있도록 하기 위함입니다.
2. settings.py 생성 및 설정
secret_bash에서 환경 변수를 export하면, 해당 환경 변수를 프로젝트로 가져올 수 있게 설정합니다. 이 과정에서 Python의 표준 라이브러리인 os 모듈을 사용합니다. os는 개발자가 간편하게 시스템적 접근을 할 수 있도록 도와주는 라이브러리로, os 라이브러리의 getenv를 사용해 등록된 환경변수를 가져옵니다. 이 때 해당 환경 변수가 존재하지 않는다면 getenv는 None을 반환하므로, 혹시나 오류가 나지 않게끔 ''(빈 문자열)을 기본값으로 지정해 반환하도록 만듭니다.
3. main,py에서 환경 변수 사용하기
현재 디렉토리에 존재하는 settings.py에서 환경 변수 값을 담았던 변수들을 import해 secret key가 필요한 곳에 사용합니다. 여기서는 PostgreSQL의 URL을 구성하기 위해 username이나 password 등을 환경 변수를 사용했습니다.
4. secret_bash 파일을 활용해 환경 변수 등록하기
앞 과정을 다 수행했다면 secret key가 잘 동작하는지 프로젝트를 실행해봐야 합니다.
프로젝트 실행 전, 터미널에서 source 명령을 사용해 secret_bash 파일의 설정 내용을 시스템에 적용합니다.
source secret_bash
5. .gitignore에 secret_bash를 등록하고 github에 배포하기
.gitignore는 github에 올리지 않고 싶은 것들을 설정해두는 파일입니다. .gitignore에 secret_bash를 등록해서 프로젝트를 배포할 때 secret_bash가 무시되도록 만듭니다. (.gitignore의 상세한 문법이 존재하나 여기서는 생략하겠습니다.)
그리고 Github에 프로젝트를 배포하면, secret key가 숨겨진 상태로 프로젝트가 배포됨을 확인할 수 있습니다.
-
-
-
-
-
'이것이 취업을 위한 코딩 테스트다'로 코딩 테스트 시작하기
“코딩 테스트를 떨어졌다!”
최근에 가장 많이 맞닥뜨린 상황이다. 인턴, 정규직 지원은 아니지만 간절히 원하던 교육 프로그램에 지원할 때마다 항상 2차 코테를 넘어서지 못하고 있다… 비전공자의 입장이다 보니 코테에 대한 제대로 된 지식 없이 약간의 문제 풀이 연습으로 도전한 게 화근인 듯싶다. 처음에는 1차 코테를 통과하길래 솔직히 “오? 되나?” 싶었다. 그러나 다른 분들 후기를 보고 나니 코테는 시간 복잡도나 알맞은 자료구조 선택 같이 깊게 생각하고 코드에 녹여야 할 요소가 많았다.
사실, 교육 프로그램 입과를 목표로 했기 때문에 코테 준비사항에서도 큰 요구가 없는 것 같았다. ‘자료구조’나 ‘알고리즘’이 중요한 과목임을 알지만 ‘들어가서 공부하자’ 싶었다. 특히, 비전공자니까 혼자 공부하는 것보단 어딘가에 소속돼서 교육 받아야 한다는 생각이 강했다. (함께하는 동료들도 만나야 시너지가 있으니까!) 하지만, 막상 코테를 접하니 교육 프로그램 입과 문제에서도 (모든 문제가 그렇지는 않았지만) ‘자료구조’, ‘알고리즘’에 대한 이해가 필요했다. 그렇게 입과에 떨어지고 점점 시간이 지나가다 보니, 내실이 부족해져 감을 느꼈다. 이전 동아리 동료들과 프로젝트를 하며 항상 재밌게 공부했던 프로그래밍인데, 시간이 지날수록 발전이 없구나… 서글퍼졌다.
그래서 내린 결론은 ‘나에게 집중하자!’이다. 지금은 공백에 대한 걱정이나 교육 프로그램에 의지하지말고 스스로 부족한 것에 집중하기로 결정했다. 특히나 나이에 관대한 곳이 IT니까 조급하지 말고 길게 보자고 다독였다. 그렇게 차근차근하다 보면 좋은 기회가 오지 않을까? :)
자료구조와 알고리즘에 한해서 현재 나의 상태를 보면, 전공도 부전공도 아니지만 컴퓨터공학과 수업을 통해 C언어로 자료구조 공부를 한 적이 있다. (친절하고 열정적이신 교수님 덕에 높은 집중력으로 A+를 받았었다.) 하지만, 지금 바로 구현할 수 있냐고 묻는다면 그렇지 않다. (특히, 그래프 단원 쪽에서 다익스트라나 벨만포드를 보고 경악했던 기억이 난다.) 그래도 과제를 하며 스택, 큐, 힙, 우선순위 큐 같은 여러 지식들에 익숙해졌으니까, 이제는 책을 보고 문제를 풀며 온전히 내 것으로 만들어 보고자 한다.
어떤 책으로 공부할까? 이전에 SW 마에스트로를 하던 동생에게 알고리즘 책으로 유명한 종만북을 추천받은 적이 있는데, 찾아보니 무지 어려워 보였다. C++을 배워본 적이 없으니까 나의 미천한 C 실력으로는 아직 무리라고 판단했다.
‘종만북’으로 유명한 구종만 님의 알고리즘 문제해결전략
그러던 중, 유튜브에서 자주 영상을 챙겨봤었던 ‘안경잡이 개발자’ 나동빈 님이 최근에 내신 저서 ‘이것이 취업을 위한 코딩 테스트다’를 발견했다. 책을 살 때는 항상 신중히 구매하는 편인데, 이 책은 알찬 콘텐츠 구성과 나동빈 님께 느끼는 신뢰가 있어서인지 큰 고민 없이 바로 구매했다. (이렇게 저항감 없이 구매하는 건 참 오랜만이다…)
나에게는 자료구조, 알고리즘뿐만 아니라 코딩 테스트의 일반적인 지식도 필요했는데, 이 책은 자료구조, 알고리즘에 대한 내용과 더불어 초보자 알고리즘 독학 로드맵, 최근 기업 코테의 동향까지 하나로 모아져 있었다. 또한, 파이썬이 익숙한 편이라 문제 풀이의 주 언어로 파이썬을 사용했다는 점도 매력적이었다. 거기에 유튜브 인강까지 매주 토, 일 진행한다고 하니 망설일 이유가 없었다.
이제 1강 들었는데 강의 길이가 꽤나 길었다. 그래도 꾸준히 공부한 내용을 기록하며 마지막에는 책에 대한 리뷰까지 행복하게 남기고 싶다. 알고리즘 푸는 것이 꽤나 즐겁다고 느끼는 요즈음이다. 부족한 부분 투성이지만 하나하나 나의 장점으로 만들어 가야겠다.
Touch background to close
Lucian Log
