nz.pe.kr
몇년된 go 책을 보면 거의 뭔가 안되는데
GO111MODULE 때문인것 같다.
C:\src\learninggo\src\anydir>go run anyfile.go
anyfile.go:3:8: package greet is not in GOROOT (C:\Program Files\Go\src\greet)
C:\src\learninggo\src\anydir>set GO111MODULE=off
or
go env -w GO111MODULE=auto
C:\src\learninggo\src\anydir>go run anyfile.go
Hello greeting pack책의 go version 과 요즘음의 go version 의 차이로 module 의 기본 사용이 강제 되는 듯.
회사 코드도 컴파일이 안되는게 이것 때문인듯. 오히려 예전 버전의 go를 설치 하고 있는 것도 문제.
예를 들어서 nginx를 9999 포트로 띄운다고 가정해보자.
docker run -p 9999:80 nginx
localhost:9999 로 붙으면 당연히 잘 될 것이다.
이 컴퓨터의 ip 가 192.168.0.2 라고 가정해 보자.
옆 컴퓨터에서 붙어 보자.
192.168.0.2:9999
이 때 안되는 경우에 대한 이야기를 시작한다.
일단 결론적으로 나의 경우 안되었던 이유는 docker container 를 띄운 windows 컴퓨터가 붙은 공유기를 “공용 네트워크” 로 선택했기 때문이었다.
컴퓨터를 세팅한 첫날부터 잘못된 선택이었다. 처음에는 outbound 로 인터넷만 하는 컴퓨터라 신경을 안 썼는데 “서버” 로 돌릴 host 컴퓨터라면 당연 “개인 네트워크”로 선택하는 것이 좋겠다. 왜냐하면 host 컴퓨터의 입장에서는 내 공유기가 “공용 네트워크” 로 “선언” 했다는 것은 마치 커피숖 wi-fi 붙은거랑 같게 보안을 강화해 달라는 설정을 한 것이나 다름 없기 때문이다.
그러니 옆에 컴퓨터에서 host 컴퓨터에 붙으려고 해도 대부분 기본 차단된다. 이는 커피숖의 다른 누군가가 내 컴퓨터에 접속 시도하는 것을 죄다 막는 “공용 네트워크” 설정 때문이다.
host 컴퓨터가 붙은 wi-fi 가 “개인 네트워크” 설정을 했다면 기본적으로 외부 컴퓨터에서 host 컴퓨터가 열어 놓은 port 에 접속이 잘 되기 마련인데 이는 docker for desktop 등을 설치 했을 때, 처음 서버를 기동 했을 때 windows 가 분명히 물어봤을 것이다.
시작>실행> wf.msc 에서 나오는 인바운드 규칙을 보면 나의 경우는 docker 프로그램이 여는 모든 포트가 허용되되 개인 프로필 즉, 개인 네트워크에 붙어 있을 때에만 허용하고 “공용 프로필” 은 명시적으로 거절하도록 되어 있다.
이것이 무슨 포트인지는 중요하지 않다. docker 로 실행된 모든 포트는 허용을 하게 된다.
windows 에서 리스닝 중인 포트에 대해서 어떠한 프로그램이 그 포트를 열고 있는가를 거꾸로 찾아 들어가는 방법이 있다.
netstat -aon 과 linux 의 grep 격인 findstr 를 조합하면 된다. 9998 을 열고 있는 프로그램의 ID 를 찾는다.
프로그램 ID 를 찾았다면 이제 프로그램이 무엇인지 단번에 알아낼 수 있다.
linux 의 ps -ef 격인 tasklist 이다. 여기서도 findstr 를 조합한다.
com.docker.backend.exe 가 결국 9998 포트를 열고 있는 프로그램인 것을 알 수 있다.
com.docker.backend.exe 프로그램의 fullpath 를 아는 방법은 아래의 명령으로 가능하나 외우기가 어렵다. 따라서 작업관리자 > 세부정보 탭에서 파일 위치 열기를 하는 것이 낫겠다.
C:\Users\nzin4>wmic process where “name=’com.docker.backend.exe'” get executablepath
ExecutablePath
C:\Program Files\Docker\Docker\resources\com.docker.backend.exe
이제 옆 컴퓨터에서의 테스트가 끝났다면 공유기 외부에서의 접속을 시도해볼 차례다. 공유기는 각 공유기 제조사마다 “포트 포워딩” 가이드를 제공하고 있다. port forwarding 설정을 잘만 한다면 host 즉, windows 컴퓨터의 외부에서의 접속 테스트는 완료된 상태이므로 무리없이 진행될 것이다.
회사에서 몇가지 s/w 를 구매해야 하는데 그냥 법카로 사서 청구하라고 해서 개인용으로 구매하라는 뜻인지.. 결론적으로 s/w 회사에서 license 를 개인용 / 업무용을 명확하게 나누지 않고서야 개인용으로 구매해도 문제가 없다는 생각이 든다. 즉, 개인용으로 귀속시키면 내 전용 s/w 가 되고 어딜 가서 사용해도 괜찮다는 의미가 되겠다.
SecureCrt 에 문의 메일을 보내서 가능하다는 답변을 받았다.
구매 라이센스는 computer 에 귀속된다.
제목: Re: Can I use personal license S/W at my company? [T02035873:002]
Hello,
Thank you for your e-mail.
Providing you stay in compliance with our End-user License
Agreement and are authorized by your company to install a
personal License on your work computer there should not be
an issue.
That being said SecureCRT is licensed per “computer” as
defined in section 3 of the SecureCRT EULA which can be
found at the following location:
As defined in the SecureCRT EULA, a “computer” can be one of
the following:
You will need 1 SecureCRT License for each “computer” that
has access to use SecureCRT locally or remotely.
A single SecureCRT License can be used by a single
individual to register SecureCRT on one additional
“computer” as defined in the SecureCRT EULA as long as the
individual has SecureCRT running on a single “computer” at a
time.
Please let me know if there is anything else I can do for you.
Misty Buck
VanDyke Software, Inc.
505-332-5710
505-332-5701 (fax)
sales@vandyke.com
www.vandyke.com
gmail 을 주력으로 쓸 때도 관심 있는 주제였는데 회사를 바꾸고 outlook 을 주력으로 쓰다보니 찾아보게 된다.
인터넷 검색하면 아래와 같은 filter 를 SQL 란에 넣으라는 글이 많이 보이는데 당췌 되지 않는다.
NOT (“http://schemas.microsoft.com/mapi/proptag/0x10810003” = 102 OR “http://schemas.microsoft.com/mapi/proptag/0x10810003”
(?) 포기 하고 좀 지내다 보다가 괜찮은 방법을 발견했다. 참조에 항상 나를 넣고 보낸 편지함에 도착하게 된 내 편지 중 보낸 사람이 나인 경우에 내가 보낸 편지함으로 이동 시킨다. (이것이 보낸 편지와는 좀 성격이 르다.)
이제 받은 편지함에서 내가 보낸 편지함으로 규칙 이동 된 내 편지에 flag 를 걸어두고, 주기적으로 flag를 확인하면 된다.
코로나 4차 대유행 / 4단계 거리두기가 시작 되었다. 2학년인 둘째는 원격수업을 안 하다가 이번에는 시작하게 되었다. 컴퓨터 방에 컴퓨터가 옹기종기 모여 있지만 수업을 같이 하기에는 안 좋을 것 같아서 거실에서 수업을 들을 계획인데 노트북으로 수업을 하는 첫째에게 패드로 수업 듣는 친구가 있냐 물었더니 많다고 한다.
그래서 그냥 패드로 수업을 듣게 하려다가.. 첫째에게 패드로 수업 듣는 친구가 혹시 수업 듣기 어려운 점이 있는지 물었더니 의외로 많이 있길래 적어 본다.
나이가 만 41살이 되었다. 직장에서 꽤 높은 위치에 있는 것 같다. 나 스스로는 아직 젊다고 생각하고 사원 대리급과 농담 따먹기도 잘 한다고 생각하는데 그들은 나를 어떻게 생각할까? 마침 아내가 공직에서 30~40명을 거느린(?) 팀장이 되어서 처음 팀원들을 만날 때의 인상에 대한 얘기를 하다가 급 깨닫는 것이 있어 정리해 본다.
나에게는 좋아하는 동생 둘이 있는데 나를 포함해서 3명이 있는 카톡방에서 그렇게들 서로 거침 없이 말을 뱉는다. 지금이야 익숙해 졌지만 사이가 안 좋거나 싸우는 줄 알았다. 시간이 지난 후 그들이 불알친구고 그럴 수 밖에 없다는 것을 알았다.
그런데 그 느낌이 뭔지 알 것 같다. 나도 학창시절 친구들을 만나면 그 때의 나이로 돌아가 말투가 그 때로 돌아간다. 그야말로 욕도 하면서 서로 까고 논다. 그러면서도 우리는 기분이 나쁘지 않고 즐겁다. 그 모습 또한 누가 보면 싸우는 것 같이 보이기도 할 것 같다.
가끔 만나는 친구들. 그 친구를 처음 만났을 때 그 느낌으로 대화 분위기가 바뀐다. 내가 몇 살이 되든 상관이 없다. 이렇듯 회사에서 만나는 사람과도 그 대화 방식이 고정이 되는 것을 느낀다. 물론 처음 어색할 때와 조금 친해지고 나서 조금은 바뀔 수는 있다.
처음부터 말을 놓는 사람은 나중에 더 가까워지면 꼰대가 되는 것 같고 처음에는 존대를 하다가 가까워져서 말을 놓는 하는 사람은 그래도 말투만 친해졌지 여전히 마음가짐과 태도에는 변화가 없는 것을 느낄 수 있다.
그래서 첫 인상이 중요하다고 하는가? 일종의 목표를 갖고 처음부터 확 휘어잡고 싶은 사람은 처음부터 말을 놓는 경우가 많다. 그것이 결국 그가 만나는 사람들과의 관계의 출발선이다. 처음부터 지위의 격차를 강조하고자 하는 사람이 만나는 사람은 아무리 친해지고 싶어도 이미 첫 인상이 그렇기에 반감이 생기고 굳어지게 마련이다. 그래서 그 이후에는 잘 하고 싶어도 결코 가까워질 수 없는 벽이 생기는 것 같다.
이 원리는 아버지와 나와의 관계에서도 나타나는데 아빠는 항상 나를 어린아이로 보는 것 같다. 아빠가 나를 이제는 어른으로 대해주길 바라지만 이미 성인이 된지 20년이 흘렀는데도 여전히 나는 아버지에게 어린아이다. 바꿀 수 없다.
나는 개발자니까 웬만하면 편하게 입는 편이지만 면접을 보거나 첫 만남을 가질 때는 거의 비즈니스룩을 하는 편이다. 그러면 꼭 편하게 입어도 되는데~ 라고 거드는 사람이 있다. 그렇지만 나는 첫 인상을 중요하게 여기므로 바뀌지 않는 편이다.
사람간의 관계에서 처음 굳어진 그 관계를 깨기란 어려운 것 같다. 그렇다면 나는 직장 생활에서 만나는 사람과의 관계를 어떻게 정리해야 할 것인가? 첫인상 첫 마음가짐 그것이 관계를 만드는 것이다.
grep 은 -C 로 내가 찾고 싶은 단어 위아래로 검색 하게 해주는데 windows 에서도 찾아봤는데 findstr 로는 안되고 powershell 명령어인 Select-String 으로 되는 것을 확인
Yaml 형태의 문법인 경우 유용하게 사용 가능하다.
PS C:\Users\nzin4> kubectl describe po flask3 | Select-String -Pattern 'Label' -Context 2,3
Node: minikube/192.168.49.2
Start Time: Wed, 07 Jul 2021 15:41:04 +0900
> Labels: app=test
run=flask3
Annotations: <none>
Status: Running긴 결과에 대해서 Select-String 으로 pipe 로 넘긴 후 -Pattern 인자로 검색 -context 로 검색 되었다면 그 위의 2줄, 아래로는 3줄을 보여라 라는 명령을 호출하면 된다.
PS C:\Users\nzin4> kubectl describe po flask3 |Select-String -Pattern 'Label' -Context 2,3
Node: minikube/192.168.49.2
Start Time: Wed, 07 Jul 2021 15:41:04 +0900
> Labels: app=test
run=flask3
Annotations: <none>
Status: Running뭔가 내가 지정한 것보다 하나 더 많이 검색 하는 것 같다.
# full stack 개발자로서의 아키텍쳐 진입
S/W는 그 접근성이 누구에게나 열려 있는데 반해
장비, 네트워크 분야는 물리적인 H/W를 필요로 하는지라 공부에 대해 이론적 접근성 대비 실습과 그 실행에는 어려움이 많았습니다.
full stack 개발자로서 항상 아쉬운 것이 방화벽과 네트워크 서브네팅과 이중화 구성이었고
H/W의 제약사항을 없앤 것이 저에게는 클라우드 컴퓨팅의 매력이었습니다. 거기에 스케일링과 비용 효율화는 덤입니다.
그래서 이번에 full stack 개발자 + 아키텍팅 까지 다 해보자라는 생각이 들었습니다.
# 동시 취득을 목표로 하면 노력대비 성과가 좋음
그래서 aws solutions architect (이하 SAA) 공부를 시작했고 연속해서 certified Developer(이하 DVA) 까지 연속 취득 하였습니다.
각설하고 결론부터 말하자면 누구든 시작을 결심 한다면 이왕이면 2개를 동시에 따면 좋겠다는 것입니다.
합격에 도움이 되는 블로그가 많이 있어서.. 구지 제가 또 어떻게 하면 합격하는데 도움이 되겠다라며 적는 것은 정보 과잉을 양산하는 것이라 지양하고자 합니다. 2가지 시험을 보고 나니 거의 절반 이상의 내용이 겹쳐 있고 이왕이면 한번에 2개를 따면 좋겠다는 글과 코로나 시국에 aws 자격증 외에 언젠가 치루게 되실 온라인 시험에 대한 제 경험담을 적어보고자 합니다.
가용성을 지원하는 시스템 아키텍쳐, 네트워크 설계를 위한 Solutions Architect 를 공부하면서 배운 것 중에 절반은 Developer 공부에 중복되면서도 반드시 필요한 부분이었습니다. 그래서 Developer 공부는 매우 수월했고 복습하는 기분으로 훑고 지나가 공부 기간은 절반에 가까웠는데도 불구하고 합격 점수가 훨씬 더 높았습니다.
SAA를 따고 나서 하루이틀 결과 발표를 기다리는 와중에 사내 게시판에 자격증 2개 동시취득자의 글이 올라와 자극을 받게 되었습니다. 그 때 DVA 도 따버리자 라고 생각했는데 지금 생각하면 매우 잘 한 것 같습니다. 오히려 동시 취득을 안 했으면 억울 했을 것 같습니다. (그만큼 범위가 겹치는 부분이 많습니다.)
SAA 때는 대충 긴가민가 알고 넘겼던 것을 DVA 딸 때 더 깊이 공부할 수 있었고 DVA 공부하면서 알던 것을 SAA 할 때도 알았으면 더 높은 점수를 받지 않았을까 싶습니다. 그만큼 서로의 자격증이 상호 보완적입니다. 이런면에서도 2개 동시 취득을 강력하게 추천하고 싶습니다.
SAA는 전체적으로 모든 솔루션을 훓게 되며 DVA는 Code series (commit, build, deploy, pipeline) 그리고 cli 명령어의 파라미터의 이름과 DynamoDB 의 RCU, WCU 계산, 그리고 서버리스구축을 위한 aws gateway / lamba 그리고 cognito 에 집중됩니다. 또한 cloudformation 과 SAM 의 개념도 알아야 합니다.
# 공부방법 (유료 강의와 유료 덤프)
SAA 는 약 3주간 평일 풀타임 (15 업무일) 으로 공부를 하였으며 DVA는 2주 (10 업무일) 의 시간이 소요 되었습니다. 아마 반대 순서로 땄으면 거꾸로 DVA 15일, SAA 10일 걸렸을 것 같습니다.
Udemy에서 강의를 검색해서 들었는데 난생 처음 듣는 영어 강의였 습니다.
그런데 모두 그림이 친절하고 강의 특성상 엄청 천천히 발음을 친절하게 강의를 해줘서
사실 처음에는 지레 겁먹었지만 강의가 후반부에 갈 수록 1.5배속에 심지어 1.75배속으로 듣고 있는 저를 발견하게 되었습니다.
2개의 강의가 앞의 절반은 겹치고 뒷부분 반이 영역이 약간 나뉘게 되어서 DVA 강의 앞의 절반은 건너 뛰어 시간을 절약했습니다.
Udemy 에 예상문제 각각 6회 강의를 추가로 구매하였습니다.
유료 문제 풀의 강의의 강점으로는 내가 어느 부분에 취약한지 카테고리를 분석해 주고
문제 번호와 보기의 랜덤 배치로 재 시험을 치룰 수 있습니다.
또한 실제 시험과 같은 자세를 취할 수 있도록 도와줍니다.
Udemy 는 최초 가입시 모든 강의가 만원 중반으로 결제 할 수 있고, 다음 강의는 장바구니에 넣어두고 결제 안하고 있으면 이메일로 왕창 할인 해줄테니 결제 해달라고 쿠폰이 오고 아니면 이메일을 여러개 만들어서 결제 하면 됩니다. 모두 만원대에 결제 하였습니다.
일단 강의 1회 수강
예상 문제를 풀고 틀린것에 대해서 aws 공식 문서를 읽고
시험 전날, 다시 다 풀어보고 그래도 또 틀린 것을 다시 aws 공식 문서를 보는 순으로 진행 하였습니다.
# 시험은 aws FAQ 문서에서
강의 외 내용이 시험에 나오면 구글에서 검색을 하면 거의 모든 문서가 검색이 되기는 하는데 aws 공식 문서의 한글 버전은 대부분 기계 번역이라 잘 이해 안되는 것은 영어로 보거나 본문을 구글 번역기로 돌리면 훨씬 이해하기 쉽습니다. FAQ 에는 사례와 해결 방법이 많이 나오는데 모두 다 시험 예상 문제 입니다.
다른 블로그를 참고해도 덤프 보는 것보다 FAQ를 정독하라는 얘기도 많이 볼 수 있습니다.
덤프를 공유해 달라는 등의 요청을 가끔 받게 되는데 인터넷에 널린게 덤프입니다. 찾아내는게 어렵지가 않습니다. 다만 몇가지 풀어보니 오답이 너무 많습니다. 오답을 외우는 사람이 없기를 바랍니다.
위에서도 썼지만 udemy 에서는 유료 예상 문제 과정을 제공합니다. 질문하면 답도 잘 달아주고 특히 SAA는 한글 문제 풀이 과정이 있어서 수월했습니다. (문제는 기계번역된 FAQ로 문제를 낸거라 문제 자체의 이해가 어려움)
바쁜 현대인에게 필요한 것이 덤프로 합격하는 것인지 강의를 듣고 배움을 내재화 하는 것인지는 본인이 판단하면 되겠습니다. 그럼에도 덤프는 여전히 필요합니다. 공부를 하고, 내가 모르는게 무엇인지 체크하는 최적의 방법입니다. 하지만 공부를 하기 전에 일단 덤프로 모르는 것을 하나씩 찾아 나가는 것도 틀린 방법은 아니라 하겠지만.. 전체적인 흐름을 한번이라도 보는 것이 여전히 고집스럽게 좋은 방법이라고 말하고 싶습니다.
# 시험 문제와 현행화 준비
실제 시험 문제가 랜덤이라 아까 낸 문제를 왜 또 내지? 싶은 문제도 있습니다. 혹은… 특정 제품의 사용을 밀고 싶어서 시험응시자들를 세뇌시키는 것은 아닌가 싶기도 했습니다. aws 시험문제가 재밌는게 5줄이라 치면 4줄은 거의 상황 설명이고 마지막 한두줄만 시험에 필요한 내용이라 시험을 치면서도 이럴때 이렇게 하면 되겠구나라는 상상의 나래를 펼치게 만들어 주어서 문제를 읽어 보는 것 만으로도 많은 배움을 얻게 됩니다.
시험문제의 현행화가 꽤 변수입니다. 불과 몇개월 전까지만해도 되지 않던 기능이 “이제 됩니다!!” 라고 홍보 기사가 올라 오면 그게 시험문제로 나오는 경우가 있습니다. 기존 경험으로는 당연히 안되던 것인데 이제는 오답일 수 있습니다. 예를 들어 s3 의 GetObject 는 원래 eventual consistency 인데 2020년 12월 부터는 strong consistency 입니다.
시험은 한글로 신청 하면 기계 번역된 한글 문제가 나오는데 “English” 라는 버튼을 누르면 원문을 볼 수 있어 대조 이해가 가능합니다. English 에 자신이 있다고 하더라도 한글 버전과 영문 버전을 동시에 볼 수 있는 것이 문제의 이해에 도움이 될 것 같다는 생각이 듭니다.
# 온라인 시험 준비
시험은 온라인 (피어슨뷰) 으로 치루었는데 노트북 화상카메라를 통해 감독관이 계속 쳐다보고 있는 가운데 치뤄지게 됩니다.
당일 예약은 안되는 것 같고 익일 24시간 중에 선택 할 수 있는데 일요일은 그 시간이 매우 한정적이라 없다고 보면 됩니다.
시험 날짜가 몇가지로 정해져 있으면 좋은데 내가 마음껏 선택할 수 있으니 자꾸 하루이틀 미루게 되는 것 같습니다. 목표일자를 정하지 않으면 공부 기간이 길어져서 점점 피곤해 집니다. 내일 보자! 고 결정하는 결심히 매우 중요합니다. 결제는 회사 법인카드 (visa 카드임) 로 진행합니다.
시험 10분 전에 피어슨뷰 등 싸이트에 로그인해서 전용 시험 코드를 확인 하고 미리 다운로드 해둔 전용 브라우저에 코드를 입력해서 로그인, 휴대폰에 전송되는 링크를 통해 시험실 동서남북을 사진찍어서 업로드 해야 하고 여권도 찍어 올려야 합니다.
시험이 시작되면 감독관과 약간의 대화를 하게 되는데 pardon? text me please~~ 등으로 하면 친절하게 채팅으로 대화를 전환한다.
노트북을 들어서 책상 밑을 찍어보라는 둥 몇가지 요구사항을 충족하면 시험을 시작한다. 저의 경우는 토즈 독서실의 2인 회의실에서 시험을 치뤘습니다. 시험 치루는 중에 손이 닿는 곳에서는 아무것도 없어야 한다는 조건을 만족시키기에 적절한 공간이었습니다. 벽면에 토즈 독서실 이용하는 방법에 대한 코팅 인쇄물이 붙어 있어 첫 시험에는 가림판으로 가렸고 두번째 시험에서는 뜯어버려야 했습니다.
전용 브라우저를 PC/mac 에 미리 설치해서 시스템 호환성을 미리 체크 하세요. 크롬북은 안될 수 있습니다. 참고로 호환성 체크할 때는 문제가 없었는데 막상 시험 때 휴대폰 테더링으로 시험을 시작하니 영상이 안 보인다 하여 급히 토즈 wifi 로 변경하여 겨우 시험을 치뤘습니다. 두번째는 랜선을 가져가서 유선으로 시험을 치루었습니다.
# 온라인 시험 단축키 팁
마우스로 정답을 찍어도 되고 단축키를 이용해도 됩니다. 보기 abcd 는 키보드로 타이핑 하면 정답이 체크 되고 다음 문제는 alt+N 이전 문제는 alt+P 등을 이용해 네비게이션 할 수 있습니다. 갑자기 단축키가 잘 안되는 경우가 있는데 몇번 해보니까 alt+tab 을 눌러보면 (실제로 화면 전환은 없지만) 갑자기 다시 잘 됩니다. 단축키에 익숙해 지시면 시험에 더욱 집중하는데 도움이 되실 것 같습니다. 주의할 점은 abcd 를 한번 더 누르면 정답 체크 한 것이 uncheck 가 되어 나중에 전체 검토 화면에서 풀지 않은 문제로 표기 됩니다. alt+F 로 flag 를 걸어서 헛갈리는 문제만 나중에 검토할 수 있습니다. ctrl +- 로 문제 폰트의 크기를 키우거나 줄일 수 있습니다. 폰트가 너무 커서 미처 보기를 다 보지 못할 정도로 확대 되었다고 판단되며 보기가 더 있는데 다음 문제 풀거냐는 경고도 친절하게 해줍니다.
# 온라인 시험 마무리
시험 문제 검토 후, 제출 버튼을 누르면 진짜 제출하겠냐는 조마조마한 버튼이 또 한번 나오고. 돌이킬 수 없는 버튼을 누르는 순간 합격 여부가 표시 됩니다. 혹시 떨어진 경우의 실망감을 감독관이 감당할 필요 없도록 하는 배려인지 제출 버튼을 누른 순간부터 감독관도 사라져 버립니다. 그래서 카메라는 켜 있는 와중에 그냥 노트북 뚜껑을 닫아버리고 집에 가도 무관합니다. 이미 당락은 결정 난 것입니다.
# 다음 목표
다음 시험으로는 Solutions Architect Pro 또는 DevOps Pro 로 다음 자격증을 노려보려고 합니다. 이 또한 많은 부분이 겹칠 것이나 pro 자격증은 여전히 객관식이지만 2개 심지어는 3개 이상의 복수 정답을 골라야 하므로 찍어서 맞추는 일은 없을 것 같습니다.
실기도 없는 객관식 자격증이라는 것이 꼭 아키텍처와 개발자 역량으로 확실히 구별지어지는 부분은 아니라서 (아느냐 모르느냐 vs 할 수 있느냐 없느냐) 일단 각각의 자격증의 예상 문제지를 풀어보고, 왠지 더 많이 알 것 같은 자격증을 노리는 것도 수월한 합격에는 도움이 될지도 모르겠습니다.
이번에 두번째 제안 작업을 시작하게 된다. 인생에서 처음으로 제안서를 썼을 때는 제대로 정리가 되지 않았던 것 같은데.. 이제 조금은 알 것 같다. 제안서도 일종의 면접이다. 내가 아는 기술을 총 동원 하되, 실제로 할 수 있는 범위 내에서 써야 한다. 내가 낸 답안지가 회사의 답안지고 고객이 채점을 한다. 그런데 고객 요청사항에 엉뚱한 대답을 했다면 그것을 채점하는 고객이 얼마나 민망할까? 우리 회사를 다시 쓰고 싶을까?
제안서는 우리 회사의 기술력이 대변되는 것이다. 혹시 떨어지더라도 다시 만날 준비는 되어야 하므로, 완전하지 못한 답변은 면접관 앞에서 헛소리를 하는 것이랑 다르지 않는 것 같다. 그래서 제안서 작업은 그야말로 “미리 준비된 자들의 집합”의 마스터 피스가 되어야 한다.
그런 관점에서 보면, 면접자가 면접에 합격을 하기 위해 최선을 다하듯 회사도 최선을 다 해야 한다.
그런데 최선을 다한다는 것이 무엇일까? 회사는 조직이다. 한순간 최선을 다한다는 명목으로 관련해서 아는 모든 직원을 한 곳에 모을 수는 없다. 다행인 것은 경쟁 관계에 있는 회사라고 해서 그렇게 하는 것도 아닐 것이다.
그래서 제안 요청사항의 전문적인 분야에 능통한 팀에 무언가를 부탁해서 제안서를 완성하는 것을 기대하는 것은 쉽지 않은 일이다.
그럼에도 제안이 선택되기 위해서는 마스터피스를 만들어야 한다면 기술 난이도가 깊은 사람도 필요하고 두루두루 알고 경험을 해 본 사람도 꼭 필요하다.
젊었을 때는 기술의 난이도만을 중요하게 생각했고 나이가 들어가면서 개발자에서 PL 이나 아키텍처로 가는 길은 되도록 피해왔던 것 같다. 하지만 누군가는 분명히 다방면의 기술을 아는 사람도 필요하겠다는 생각이 든다.
요즘과 같은 세상에는 어떤 문제에 대한 해결책을 찾아내고 제품을 선정하는 것은 어려운 일이 아닌 것 같다. 기술적으로 적용하는 것은 예제가 많아서 접근성이 좋다.
그러나 올바른 설계에 대해서는 해답이 없다. 다양한 best practice 를 탐독하고 경험하며 설계 자체의 고민을 할 수 있는 시간이 나에게 주어져서 다행이다.
aws를 통해 3가지 정도 제시되는 듯
aws system manager (SSM) 의 parameter store 를 사용
파라미터 스토어의 시크릿 매니저
다음의 가이드를 따르면 되는데, 이 가이드를 따르면 java client 가 parameter store 에서 값을 가져오기 위한 access key 를 알아야 한다. 그러나 ec2 자체에 해당 IAM role 을 부여 했다면 그럴 필요도 없다. system 에서 curl 등으로 paramter store 의 값을 가져와 java에서 로딩 하면 된다.
이는 RDS 안의 user / password 를 암호화 해서 저정한 새로운 형태의 credential 이다. 평문으로는 ID/PW 가 뭔제 application 은 몰라도 된다.
차이점은 공식 문서를 참고 할 수 있는데 parameter store 는 적절한 사용 수준에서는 무료라는게 장점인듯.
마지막으로 IAM DB 인증이 있다. mysql / postegre 에 aws 가 심어놓은 플러그인을 통해 인증 하는 것. AWSAuthenticationPlugin