심심한 개발공부

혹시 AWS Skill builder와 같은 서비스를 이용하다가 갑자기 다른 계정으로 로그인된 경험이 있다면, 높은 확률로 중복 계정 이슈 때문일 것이다. 나는 아마존 Skill Builder Support와 나눈 수 많은 대화를 통해서 해당 문제가 발생할 수 있다는 것을 알았는데, 혹시 다른 누군가도 해당 문제를 겪을 수 있을까봐 해결방법을 작성해본다. 문제 원인 해당 문제는 당신이 여러 아마존 계정을 한 이메일로 가지고 있을 때 발생한다. 위 말은 그냥 들으면 말도 안되는 소리라고 생각이 될 수 있지만, 실제로 아마존에서는 가능한 문제이다. 왜냐하면, 아마존은 국제 서비스를 제공하고 있고 각 국가마다 새롭게 회원가입을 진행해야하기 때문이다. 당신이 a@naver.com으로 미국에서 가입을 했더라도, ..

이번에 내가 소속된 이노베이션 아카데미가 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를 제작할 때 용량을 조금 더 추가한다 - 많이는 필요없..