심심한 개발공부

이번에 내가 소속된 이노베이션 아카데미가 IITP 예하였기 때문에, 무료 응시기회를 얻을 수 있어 생각지도 못하게 TOPCIT에 응시할 수 있게 되었다. 사실 존재만 어렴풋하게 알고 있었지, 어떤 시험인지에 대해서는 하나도 모르고 있었기 때문에 응시해볼 생각이 전혀없었는데, 재단에서 무료로 보게해주겠다고 하니까 '횡재했다!'라는 마음으로 응시하게 되었다. 처음에, 응시를 할 때만해도 미리 준비를 하고 가야겠다고 마음 먹었으나, 사람 일정이라는 것이 마음대로 되지 않아서 준비는 고사하고 전날 잠도 제대로 못자고 응시하게 되었다. 사실, TOPCIT 관련되어서 인터넷에 검색해봐도 별로 자료도 안나온다. 그래도 시험인데, 뭐가 나오는지는 알고가야겠다고 생각해서 새벽같이 일어나 아침 내내 유튜브, 블로그들을 뒤..

백, 인프라, 프론트 엔드 개발자로서 다양한 프로젝트를 경험한 이후, 나는 인프라 특히 클라우드 엔지니어가 되어야겠다고 판단했다. 하지만, 이 판단에는 한 가지 문제점이 있었으니, 바로 클라우드 직군은 신입을 잘 안 뽑는다는 것이었다. 실제로, 여러 프로젝트를 기반으로 6개 정도의 회사에 서류를 넣었으나 결과는 바로 광탈.. DevOps 직군으로 넣었지만 모두 회사의 기준에 나는 알맞지 않았다. 운이 좋게도 내가 어떤 부분이 부족해서 탈락했는지 알 수 있는 기회가 있었는데, 결국은 내가 신입이라서 불가능하다는 이야기였다. 여러 프로젝트 리딩 및 개발 경험은 높게 평가하지만, 내가 신입으로 지원을 했기 때문에 당장 프로젝트에 투입할 수 있을지 의문이 들고 회사로서는 현재 시장 상황상 모험을 할 수 없기 때..

1. AWS는 너무나도 시장 지배적이었고, 구글은 클라우드 시장에서 자신들만의 차별점을 만들어내고 싶어했다. 2. 구글은 자신들만의 정교한 인프라 전문지식을 가지고 있었고, 이를 클라우드에 적용하는 과정을 지속적으로 진행하고 있었다. 3. 컨테이너 기술은 도커 이전에도 존재했었고, 대부분의 개발자들은 몰랐지만 소수의 개발자들은 컨테이너 기술을 사용해왔다. 4. 컨테이너 기술이 도커에 와서야 대중화된 것은 도커가 컨테이너 기술을 매우 쉽게 추상화하는 것에 성공했기 때문이다. 5. '누구나 도커를 사용할 수 있다'라는 점 그리고 소프트웨어 패키징 개념은 도커가 컨테이너 기술의 표준이 될 수 있도록 도와줬다. 6. 도커 이전에도 대규모 트래픽 처리를 위한 좋은 프레임워크는 많았지만, 이들 대부분은 대기업들만이..

또 하나의 프로젝트가 성공적으로 마무리되었다. 이번 프로젝트는 내가 기획하고 제안하여 개발까지 완료했는데, 결과가 예상보다 훨씬 좋아 매우 기분이 좋다. 프로젝트를 성공적으로 마무리한 기념으로, 이 글을 통해 개발 과정에 대한 생각과 타임라인을 정리해보려 한다. 개발하게 된 계기 42서울은 교육생들에게 다양한 교육 혜택을 제공한다. 구름EDU, 프로그래머스 등 강력한 혜택이 준비되어 있지만, 아쉽게도 이를 알 수 있는 방법은 매우 제한적이었다. 따라서, 몇몇 혜택들은 이용되지 않는 상태였고, 이로 인해 업체들도 혜택 제공에 소극적인 악순환 구조가 형성되어 있었다. 사실 42서울에는 이전에 베네핏 페이지가 있었다. 2020년에는 42베네핏이라는 사이트가 존재하여 42서울 교육생들이 혜택을 확인할 수 있었다..

상용 서비스에 크롤러가 포함되어있다면 늘 주목하자 내가 서비스하고 있는 프로그램 중에서 42Noti가 오늘 갑자기 에러를 뿜어내기 시작했다. 나는 내 프로그램들에 문제가 발생하면 즉각적으로 알 수 있도록 Slack WebHook을 걸어두는데, 이 웹 훅에 401에러가 지속적으로 발생하기 시작한 것이다. 401 코드를 보아하니 권한에서 문제가 생긴 것 같은데.. 도대체 무엇이 문제일까 직접 한번 확인을 해봐야만 했다. 그러면서 머리를 스치고 지나가는 것이 최근에 내가 크롤링하는 부분이 문제가 되었나 싶었다. 최근에 크롤링 하는 사이트의 UI가 변경되면서 문제가 되었을 것이라는 추측을 했다. 401에러의 원인 결과적으로 예상은 적중했다. 내 42Noti는 3주마다 갱신해야되는 Secret를 셀레니움으로 제작..

군대는 왜 이렇게 비효율적일까? 군대에서의 생활은 언제나 비효율적이라는 생각이 들었다. 군대라는 조직의 특성과 프로그래밍에 대한 접근성 등 여러 제약적인 요인들이 있었지만, 그럼에도 군대의 일 처리 방식은 상당히 비효율적으로 느껴졌다. 규율과 질서를 유지하기 위해 꼭 필요해 보이지 않은 일들도 해야 했고, 이 때문에 불필요한 업무가 많았다. 그중에서도 보안 일일 결산은 특히 주목할 만했다. 이 일일 결산은 크게 보안적인 향상을 가져오지 못하는 것 같지만, 매일매일 해야 하는 일이었다. 게다가 이 일일 결산은 각 부서별로 얼마나 잘 수행했는지가 부대 지휘관의 인사 고과에 영향을 미치기 때문에, 지휘관들은 이에 매우 민감했다. 실무자들은 이를 잘 수행하지 않으면 성과 상여금이 깎일 수 있어서 꼭 해야만 했다..

사용방법 1. 일단 Sumy를 사용하기 위해서는 JDK가 필요하다 먼저 JDK를 설치하도록 하자 sudo apt install openjdk-17-jdk java -version # 잘 설치되었는지 확인하자 2. 필요한 라이브러리를 설치하자 #반드시 python과 pip은 설치되어있어야한다 pip3 install sumy # pip3 혹은 pip pip3 install konlpy # konlpy는 한국어를 사용하기 위한 형태소분석기이다. 3. 예제 코드 작성 from sumy.summarizers.lex_rank import LexRankSummarizer from sumy.nlp.tokenizers import Tokenizer from sumy.parsers.plaintext import Plain..

어느날 언제와 같이 로컬에서 개발을 한 후, Develop에서 확인을 하고 그 다음에 릴리즈 브랜치로 내 프론트 코드를 옮겼는데 위와 같은 오류가 나타나 버렸다.. Develop도 아니고 Release에서 오류라니.. 식은땀이 나고 온 몸이 저려온다. 일단, 가장 먼저 한 행동은 git revert를 한 후 commit을 진행했다. 하지만, 동일한 문제가 또 발생하였고 그때가 되어서야 문제를 확인하고 해결해야겠다고 생각했다. 그래서 문제는? 결론은 내 코드의 문제는 아니었다.(괜히 겁 집어먹고 revert시켰는데.. 다시 돌려야겠다..) 문제는 마침 오늘부터 Github에서 build 에서 18.04 버전을 제공하지 않았기 때문이었다. (23.4.3부터..) 그래서 아래와 같은 에러가 찍힌 것이었다. d..

프로젝트를 진행하다보면, 내 계정에서 프로젝트를 진행하는 경우도 많지만 어쩔 수 없이 여러 IAM 계정을 이용하게 된다. 특히 IAM 계정이 가지고 있는 권한 제어에 대해 이해하면 할 수록 ROOT는 초기에만 사용하는 계정이 되고 내가 해야되는 역할에 따라서 각기 다른 IAM 계정을 이용하게 되는 것 같다. 하지만, 큰 문제점 저기에 있는 계정 ID를 외우기가 너무 어렵다. 숫자 12개로 구성되어있다보니까, 외우기도 어렵고 크롬 자동완성에 의존하자니 다양한 계정이 어떤 ROOT에 대응하는지 확인할 방도가 없다. 그래서 AWS에서 제공하는 서비스가 계정 별칭이다. 그러면 어떻게 설정하는지 알아보자 1. IAM 계정으로 로그인한다.(이 때 해당 계정은 반드시 IAM설정할 수 있는 권한이 있어야된다. 2. I..

가끔 서버에서 빌드를 하다가 서버가 죽어버리는 경우가 있다. 이런 경우 대부분의 케이스는 메모리가 부족해서 벌어지는 일인데, 평소에 우리가 사용하는 OS들에서는 메모리가 부족한 경험을 하기도 어려울 뿐더러 가상메모리가 설정되어있어서 부족하다고 멈추는 경우는 없다. 하지만, 우리가 EC2를 사용하는 경우에는 1기가 혹은 많아야 2기가의 렘으로 사용하게 되는데, 이런 경우에 평소 서비스할 때에는 서비스 볼륨에 따라 문제가 없는 경우가 많지만 빌드나 특정 초기작업에서 문제가 생길 수 있다. 나 같은 경우에는 EC2를 마이크로 혹은 small을 자주 사용하는데, 그렇기 때문에 서비스를 시작할 때는 꼭 아래와 같은 과정을 거친다. 1. EC2 Instance를 제작할 때 용량을 조금 더 추가한다 - 많이는 필요없..

배포 고려사항 1. (해커톤 상황 고려)내가 잘 아는 기술 스텍을 이용하자 - EC2, Vercel 이용하기로 결정, Amazon RDS 이용은 고려하였으나 해커톤 기간 중에는 EC2 안에 마리아 DB사용하기로 결정 2. CORS, HTTPS문제는 최대한 간편하게 해결하자 - Nginx를 리버스 프록시로 이용, 해당 문제 편안하게 해결 - CertBot 및 nginx.conf 수정을 통해서 해당 문제 해결 3. 백 서버가 정상작동하지 않아도, 프론트서버에서 백 서버가 정상작동하지 않고있음을 알려줄 수 있도록 하자 - Front, Back 이원화(Vercel, Nginx-Tomcat) 4. 서버는 대한민국에 존재해야하며, 네트워크 응답시간은 최소화시켜야된다. 개발 고려사항 1. DB정규화는 최소화(빠른 개..

들어가면서 42 이너서클을 끝내기까지 남은 과제 단 2개! 이제 정말 끝이 다가오니, 42에 대한 생각이 많아졌다. 이 곳에서 배운 것들이 너무 많아 앞으로 할 프로젝트에 있어서 자신감도 많이 붙었고, 앞으로 무엇을 해야할지에 대해서도 확신이 생겼다. 이제 내게 남은 것은 배운 것들을 갈고 닦는 시간이라고 생각할 무렵, 42내에 코알리숑 해커톤 공지가 올라왔다. 실력을 갈고닦을 순간이 필요했던 내게 이 해커톤은 좋은 기회가 될 것 같았고 우승을 목표로 이번 해커톤에 참여하게 되었다. 조별 만남 '인사가 만사'라는 말이 있듯, 나는 해커톤에서 어떤 팀원을 만나냐가 결과물을 결정한다고 생각한다. 이번 해커톤은 내 의사가 반영되지 않는 완전한 랜덤으로 조별 매칭이 이루어졌고, gehan님과 sungwook님 ..

사용하고 있는 아파치 서버 배포 직전, 과연 이 서버가 얼마나 버텨줄지 궁금해졌다. 현재 배포중인 서비스는 얼만큼의 스트레스를 버텨줄 것인가? 1. apaceh2-utils를 설치한다. sudo apt install apache2-utils 2. 원하는 스트레스 테스트 양을 설정후 던진다 ab -n 1000 -c 100 http://evaluation.42seoul.link/ // 100개의 클라이언트에서 1000개의 요청을 던져라! 라는 뜻 3. 결과를 확인한다.(프론트 요청) [알 수 있는 정보] 1. 99% 요청이 451ms안에 처리되었으니 엣지케이스에서도 성능이 준수하게 나옴을 알 수 있다(가장 긴 요청시간은 749ms으로 특수케이스임을 감안했을 때 인내할 수 있다고 판단된다) 2. 평균 요청 처..