세상에는 두 종류의 cs가 있습니다.

뭔가 평소보다 기분이 더 좋고 안정적인 일요일 저녁이다. 체감상 이번주는 정말이지 정신없이 시간이 흘러가버렸는데(회식 + 약속 + 운동 + 면접.. 펑펑펑) 생각했던 것보다 덜 피곤하고, 정서적인 만족감이 충분하다고 해야하나. 게다가 과거에는 불안감이 꽤나 컸다면 지금은 그런 것들이 잔잔하게 가라앉은 것 같다. 여전히 북마크해둔 글들도, 공부해야지 하고 메모해둔 개념들도 잔뜩 있지만 예전만큼 무섭진 않다. 이번주는 다른 주들과 뭐가 달랐나 곰곰이 생각해봤다. 1. 사람들과의 잦은 교류 이번 주는 약속도 두 개가 있었고, 우연히 낯선 사람들과 짧은 대화를 할 기회가 있었다. 주중에는 친한 중학교 친구를 만나서 돼지고기를 먹고, 산책을 하고, 카페에서 신나게 이야기를 했었는데 기분이 되게 좋았다. 주말에는 ..

올해 8월 13일에 회사 이메일로 AWS DNA 3기 멤버를 모집한다는 메일 한 통이 왔다. 아마 AWS쪽에서 주최하는 온라인 컨퍼런스들 신청할 때 홍보 메일 수신 동의를 해서 온 것 같았다. 구글 검색을 해봤는데 이전 기수 후기글만 조금 나올 뿐 생각보다 자세한 정보가 없어서 좀 고민하다가, 설명회를 들어보고 결정하자 싶어서 설명회를 등록했다. 설명회는 9월 2일 목요일에 진행되었다. 설명회 후반에 지원서 링크를 공유해주시는데, 해당 링크로 지원서 폼을 입력하고 제출하면 되었다. 진행 방식 3기 DNA 프로그램은 5개의 강연, 기존 DNA 멤버들의 실제 AWS 서비스 관련 경험담 세션, 그리고 JAM이라는 게임 형태의 행사로 구성되었다. 일주일에 한번(목요일이었다) 저녁 7시부터 2시간 가량의 강연을 ..

https://aws.amazon.com/ko/blogs/korea/amazon-aurora-under-the-hood-quorum-and-correlated-failure/ Amazon Aurora 내부 들여다보기 (1) – 쿼럼 및 상관 오류 해결 방법 | Amazon Web Services 이 글은 AWS Database Blog의 Aurora 집중 해부 시리즈의 Amazon Aurora under the hood: quorums and correlated failure의 한국어 번역으로 AWS코리아의 김상필 솔루션즈 아키텍트가 번역해 주셨습니다. Amazon Aurora 스토 aws.amazon.com 쿼럼에 대한 글들은 많지만 다들 쿼럼을 써야한다고만 하고 왜 써야하는지 구체적으로 납득이 가는 ..

우연한 기회에 AWS community day가 온라인으로 열린다는 걸 알게 되었고, AWS Jam이라는 재밌는 행사가 있다고 해서 참여해봤다. festa.io에 올라온 행사 안내에 따르면, AWS Jam은 "클라우드 상에서 수행해야하는 작업을 스스로 해결하는 게임성이 가미된 이벤트"라고 되어 있다. 문제는 행사일 이틀 전에 이걸 알게 되어서... 최대 3인 1팀이 가능한데 정말 3인 맞추기가 힘들었다. 직장인의 주말 오후는 매우 소중한 법이다. 이리저리 시도하다가 모집글에 곧바로 참여의사를 보여주신 Virtual Lab의 멋진 프로그래머 한 분과 2인 1조로 참가하게 되었다. 행사 티켓 수가 한정되어 있다고 해서 예매를 서둘렀다. 팀 이름은 30초만에 지었는데, 서로의 회사 이름을 절반씩 섞었다. 매우..

신입 프로그래머로 입사했을 때는 내가 기술 면접의 면접관으로 들어가는 것이 먼 미래의 일이라고 생각했는데, 어느덧 정신을 차리고 보니 이미 면접관으로 다섯 번도 넘게 들어가고 난 후였다. 인터넷에 면접 지원자 입장에서의 팁, 후기들은 많다. 그런데 면접관을 위한 팁, 특히 기술 면접에 처음 들어가는 주니어를 위한 팁은 찾기가 힘들어서 글을 쓰게 되었다. 처음 면접관으로 들어가게 되면 면접 지원자만큼이나 긴장이 될 수도 있는데, 조금이나마 도움이 되었으면 좋겠다. 1. 지원자의 이력서를 토대로 구체적인 개발 경험 묻기 지원자의 이력서를 기반으로 어떤 경험을 했는지 구체적으로 확인할 수 있다. 어떤 서비스를 어떻게 설계했고, 어떤 장애를 겪어보았고 어떻게 대처했는지, 어떤 프레임워크/라이브러리/DBMS를 왜..

[1] 조금은 억울하게도(?) 겪어보고 나서야 머릿속에, 몸에 확실히 각인되는 것들이 있다. 사실 대부분의 지식이 그러하다고 생각한다. 막연했던 것들은 한번 직접 당해보면 "아 이래서 그렇구나" "이래서 조심해야하는구나"가 확실하게 와닿는다. 마치 시험문제에서 틀렸던 건 기억에 잘 남는 것처럼, 어떤 문제에 대해 예상한 답이 틀렸을 때 머릿속에 확실히 남는 것 같다. 최근 회사에서 신규 런칭한 서비스 때문에 여러 생각을 했다. 어떤 서비스에 대한 장애에 대응할 수 있다는 건 그 서비스의 로직을 잘 알고 있고, 정말 그것이 버그라면 코드의 어느 부분을 고쳐야할지 빠르게 찾을 수 있다는 거다. 만약 내가 그 서비스의 아주 작은 일부조차도 개발하지 않았다면 어떻게 해야할까? 별 수 없지 뭐. 1 따로 코드를 ..

대략 아래의 구조로 rds에 db가 있다고 가정하자. example-db ㄴ example-write ㄴ example-read-only 콘솔에서 rds > 데이터베이스 > example-db 화면에서, example-db를(클러스터를) 눌러도 연결&보안 탭에 엔드포인트가 나오고, example-write, example-read-only 각각을 눌러도 역시 연결&보안 탭에 엔드포인트가 나온다. mysql 워크벤치 등으로 db와 연결을 맺고 중간중간 db를 확인하고자 하는데, 이때 어떤 엔드포인트를 쓰면 좋을까? 클러스터를 눌렀을 때 나오는 엔드포인트를 쓰는 것이 안전하다. 예를 들어, example-read-only를 눌렀을 때 나오는 엔드포인트, 즉 해당 인스턴스의 엔드포인트를 사용한다면 인스턴스에 ..

내가 하려던 것은 A라는 주소로 접속하면 B라는 주소로 리디렉션 되도록 쿠버네티스와 cert-manager 등을 이용해서 처리하는 것이었다. 그런데 설정 파일들이 다 멀쩡한데 propagation check failed 에러가 떴다. 거의 동일한 형태의 설정 파일로 테스트를 했을 때는 멀쩡히 잘 되었는데, (C라는 주소로 입력하면 D라는 주소로 리디렉션 되도록) 왜 이런 에러가 나는지 도통 알 수가 없었다. 결과적으로 --dns01-recursive-namserver 와 --dns01-recursive-nameservers-only 이 2개의 플래그를 쓰는 것으로 해결되기는 했다. Setting Nameservers for DNS01 Self Check cert-manager will check the ..

at the root of project repositroy, enter below: $ vim .gitmodules add the branch you want. (not used to vim? press I key, modify doc, press esc, enter :+q) [submodule "your-submodule-name"] path = your-submodule-name url = https://github.com/your-submodule-path branch = feature/something then update the submodule. $ git submodule update --remote

어제 각자 쉬면서 코딩을 하는, 재미있는 모임에 다녀왔다. 집에 있으면 늘어지기 쉬우니 밖에 나와서 코딩을 하되 압박감 없이 여유롭게 하는 것이다. 회사에서 gRPC를 사용하고 있는데, 개인적으로 쓴 적은 없어서 한번 써보고 싶었다. 모임에 참석한 선배 한 분이 클라이언트를, 내가 서버를 맡아서 gRPC를 활용한 투두리스트를 만들어보기로 했다. 하지만 공식 홈페이지에 있는 hello, world 예제에서부터 에러를 봤다. 왜냐하면 제공된 example 코드에 불필요한 파일이 들어있었기 때문이다. 공식 문서에도 나와있듯이, 프로토버프 파일을 수정한 뒤 protoc로 다시 컴파일하면 helloworld.pb.go가 재생성된다. 이 helloworld.pb.go에는 protobuf 파일에 정의한 서비스와 관련..