2020,개발자,회고록,1년차
2020년의 목표를 달성했는가?
벌써 2021년이다. 2019년도에 작성한 회고록에서의 단 한가지 목표를 정했다. 프로그램을 잘 짜고, 의사결정에 도움이되는 팀원이 되는것이었다. 결과는?
그닥.. 그다지.. .. sa..d
이유를 추려보면,
- 프로그램을 잘 짜는것, 기분좋게 나아지지 않았다.
- 코딩을 잘하는 것은 그냥 아는 지식을 나열하는 것과는 다른 얘기다. 뭔지 모르겠는데 깨달음이 있어야되는 것 같은데.. 이번 회고록에서 다시 복기 해보려고 한다.
- 의사결정에 도움이되기 위해서는 전제하고있는 전반적인 이야기하고자 하는것에대한 대한 지식 혹은 센스(?)가 필요하다.
- 굳이 의사결정이 무엇인가 따져본다면 크게
결정과근거로 가장 이상적것에 가까운 방법을 찾는 것인듯한데, 의사결정에 도움이되려면 일단 뭔가 근거를 받쳐줄 지식이 필요하다. 근데 그게 그냥 회의 하루전에 관련 지식을 조금 찾아본다고 답이 나오는 것 같지는 않았다.
결과적으로…
겨? 안겨? 라고하면 안겨..
2020에 만난 것들
하루의 소중함, 프로그래밍, benchmark ,디버깅, 의사결정
2020년까지 2년가까이 업무를 해왔다고 본다. 어느때와 마찬가지로 일을 잘하는것과 코드를 잘짜는것에 포커스를 맞추고 작년을 보내온것같다.
위에 적은 단어들이 올해 느낀 몇 가지포인트들이다. 작년에는 막막한 기분이 들었는데 올해는 뭘해야하고 내가 무엇을 중요하게 생각해야할지에 대한 고민을 많이 해본 한해인듯하다.
하루의 소중함
1day != 8hour
하루는 꽤나 길다. 자율출퇴근을 이용하며 조금 더 자유롭게 시간을 스스로 다잡을 수 있었다. 예를들면 저녁에 집중이 잘되니 오전 11시에 출근해서 8시에 퇴근한다던가, 일이 급하면 8시에 출근해서 6시에 퇴근할 수있다.
그러나 무분별하고 계획없는 출퇴근은 하루의 소중함을 잃게한다.
정해진 시간이 없으니 게임을 하던, 책을 읽던, 전날 무엇을 하든지.. 삶이 다이나믹할 수록 회사에서 뭔가 더 힘들었다. 뭔가 업무 집중 시간을 잃은 듯한 느낌이랄까…
그러니까 집중을 못하게 되면 하루 8시간을 항상 채우더라도 어느날은 실제 무언가 이루어진게 없는 날도 있을 수 있게 된다는것이다. (제가 일을 안한다는 것은 절대 절대 아닙니다. 인사님.)
그러니까 습관의 중요성등의 자기관리 서적들이 판 치는 이유인것 같기도 하다. 자신만의 생활 루틴이 보다 갚지고 소중한 하루를 보낼 수 있도록 한다. (책을 읽어도 좋겠지만, 그냥 스스로 사이클을 만드려고 노력하는게 의미가 있는거 같다. 방법이야 뭔들?)
어느 정도는 공장처럼 돌아갈 필요가 있… 있다?
나만의 루틴을 바로 만들면 좋긴한데… 그게 뭐 그렇게 쉽게 잘 되지 않기에 부분적으로라도 실행하기 위해 대학생때를 되뇌이며 뽀모도로 학습법을 적용해봤다.
뽀모도로는 특정 정해진 집중시간동안 빡시게 작업을 하고 꼭 정해진 시간을 지키며 쉬는 루틴을 말한다. 집중시간은 보통 사람이 집중할 수 있는 25분에 5분 휴식이 보통 가이드인데.. 자기 나름 정해서 하면된다.(최적의 집중도가 25분이라고 한다..)
또 이와 관련된 앱도 무지하게 많은데 맥에서는 아래 앱을 추천한다.
강추.. 또 강추!
시간을 정하면 알람을 울려주는 타이머 역할을 해주는데 아주 깔끔하고 잘 동작한다.
확실히 시작하면 훨씬 집중이 잘된다. 어떤 상황이건, 근데 아침에 누르는 걸 깜빡하면 그날 하루는 그냥 또 산다.. ㅋㅋㅋㅋㅋㅋ
어찌됬건 나의 하루는 소중하다. 어디선가 본 책에서는 분단위로 짜투리시간을 쪼개서 생활하면 좋다고 하는데..
지금 나에게는 하루만 잘 살아도 훗날 매일매일 발 닦고 뿌듯하게 잠잘 수 있을 거 같다.
프로그래밍
인생 최대 난제, 개발자가 프로그래밍을 못한다?!
날(raw) 코딩에 대한 이야기다.
helloworld를 찍은지가 벌써 10년이 다되간다. 아직도 그때 아련함이 떠오른다.
B 교수님의 프로그래밍 수업이었고 이름도 이상한 putty라는 프로그램에 뭔 숫자를 입력하고, 검정색에 초록색 창을 키게하더니, 거기다 vi를 입력하게하고 뭐 따라 치라고 하더니 이상한 명령어 몇 개를 주더니 화면에 회색으로 Hello world!가 찍혔다.
여러분은 지금 hello world를 출력하는 프로그램을 만들었습니다.
이게 맞나? 나는 평생 이렇게 살아야하는가. 뭔놈의 프로그램인가. 내가 아는 프로그램은 메이플 스토리같은 게임이나.. 기깔나게 해킹하는거 같은건데..
뭐여 이런거 만드는거 아니였어??
고작 이런 몇 글자로 내가 아는 프로그램을 만들 수 있는게 맞는가.. 한동안 c언어를 그림그리듯이 (컴파일도) 잘 알지 못하고 동작하게만 프로그래밍을 해왔다.
이 얘기를 한 이유는 현재도 원론적으로 그다지 다르지 않다는 것이다. 근 1년간 go lang으로 프로그램을 해왔는데 그림그리듯이 프로그램을 짜왔던 것이었다. 그것을 깨닫게된 계기가.
특정 모듈을 맡아서 하게 되었는데 몇 가지 프로그램에서 조심하게 다루어야하는 것들을 인지하지 못하고(=> 정확히 알지 못하고, 괜찮겠지.. 아니 괜찮아~) 사용하다보니 프로그램이 원하던대로 작동은 하는데 성능이 안나오던가. 가끔 버그가 발생하는 그런일들이 벌어졌다.
바로 파악할 수도 없었는데, 그 이유는
- 의식에 흐름대로 짜다보니 멀리있는 다양한 엣지케이스를 바라보지 못 했던 것
- 언어에서 제공해주는 기능의 구현 자체를 이해하지 못 하고 사용하는 것
위의 두 이유 때문이었다.
첫 동작이 아니라 전반적인 코드블락을 이해하고 코드를 짜야하는데 마치 당장의 급한 불을 끄기위해 석유를 붓는 모양으로(?) 땜빵하듯 짠게 아닌가 싶다. 설계를 명확히 하고 짤 필요가 있다. (항상 최선을 다하는가? 아뇨..)
학교 수업에서 순서도를 그리고 class diagram등으로 코드 짜는 길을 만드는 것은 다 이유가 있었구나라는 생각이 들었다. 지금 그렇게 까지 짜지는 못하더라도 의식에 흐름이 아닌 명확한 동작의 확신이 있으며 내가 아는 코드 를 짜야하는 것이 중요한 것 같다.
그리고 이 일 후 이런 과정이 예전 sw maestro과정중 멘토님이 이야기하신 이유있는 코드 일것이란 생각이 들었다.
sw maestror 과정 중 멘토님과 코드리뷰를 하게되면 항상 팀원들과 왜 코드를 이렇게 짰는지에 대한 토론을 하게 했었는데 아주 곤욕이었다. 왜냐면 내 코드는 이유가 없었기 때문이다.
내가 그냥 별생각 없이 코드를 짜가면 가서 할 수 있는 말이.. 흠 그냥 이렇게 짜면 될거같아서? 동작할 거같아서? 라는 얘기만 하게 되고 진짜 이유가 없었다.
왜?? 동작하잔어…지금 테스트 돌리면 돌잔어…더 좋은거 있으면 얘기해주던가..ㅋ
헌데 이렇게 말하면 공기가 이상하다. 개발자 아닌 사람이 와도 그 공기는 느낄 수 있을것이다. 뭔가 중요한게 빠진 느낌..
아.. 뭔가 잘못됬다… 합이..흠..
그렇기에 항상 이유를 만들어갔다. 말이 되게 그들을 설득해야 하니까.
즉 코드를 짠 이유가 단순 문제에 대한 해결이 아니라, 결과는 같더라도 그 과정을 물어 어떻게 짤지 나 스스로에게 고민을 던지게 하면 과정중 발생하는 로직들, 상황들, 그리고 더나아가 그 로직이 발생시킬 수 있는 엣지케이스등을 스스로 한번 더 정검할 수 있게 되었다.
헌데 위 과정이 유사하게 해결된게 코드리뷰를 빡시게 하게되면서 코드에 강제로 이유가 생기기시작했다… 훌륭하신 선배님들의 클라쓰… 근데 그러기 전에 내가 더 잘할 수 있도록 해야겠다.
1인분 가야지..
또한 두번째 이유는 언어의 기본 라이브러리를 쓰더라도 이해를 못하고 쓰게되면 잘 못 된결과를 초래할 수 있다는 점이다.
많은 것들이 그럴 수 있는데 성능에 크게 영향을 미치는 go RPC의 기본 call에대한 정의라든가.. 아님 하다 못해, 단순한 golang에서의 slice등의 동작법?
당연하다고 생각하고 확인안한 것들이. 당연하지 않을 수 있다.
쪼금이라도 의심이 가면 코드를 까보자.
Benchmark
위키에서의 정의는 아래와같다.
컴퓨터의 부품 등의 성능을 프로그램을 이용하여 비교, 평가하여 점수를 내는 결과
했던일중 재밌던 일중 하나였는데..(말을 잇지 못 하는..)
..
benchmark는 보통 무언가 비교 테스트하기하여 결정하기 위해서 사용한다. 이것이 비교할 대상과 어떤 차이가 있나? 뭐가 우리상황에서 어떤게 더 좋지? 그래서 결과적으로 좋아 안좋아?
무언가 성능을 측정하고 비교하는 일은 매우 까다로운 일이다. 일단 이일에 어려운점을 나열하면..
-
주로 결론에 치우져서 진행된다=> 원하는 결과를 얻으면 다되었다고만 생각한다.( 예상 수치와 일치하면 테스트가 잘 됬다고 착각한다. == 결과를 합리화시킨다.)
-
(알고있는)생각못한 변수들이 지속해서 발생한다.
-
(알지못하는)생각지도 못한 변수들이 지속해서 발생한다.
-
시간이 오래걸리는 작업이라면 위의 이유등으로 기하급수적으로 괴로워진다.
-
차이에의한
(경우에 따라서는)변수가 많아짐으로 결론이 이렇다라고 내기가 애매해진다. => 최적의 결과라고 이야기하기위한 명확한 근거가 변수에따라 달라질 수 있다.
벤치마크는 정말이지… ㅂㄷㅂㄷ
뭐 거의다 얘기했다. 저게 사실이고 끝이지만. 가장 에로사항은 한번에 진짜 잘해야된다는 것이다. 그 뭐랄까 최대한의 실수를 줄이는게 매애애애우 중요하다. 변수가 많은것을 최대한 빠르게 파악해야된다. 그러기에 진짜 진짜 (별3개) 글로 정리하는 것이 중요하고 한번 경험이있던 사람의 주변의견을 듣는게 무엇보중요하다. 코드리뷰보다 더욱!
이유는 시간때문이다. 테스트하는 시간은 절대적이라서, 무엇인가 잘못되면 다시해야된다. 코드도 다시짜야되고, 테스트를 하기위해 짯던 스크립트도 다시짜야될 수도있다.. 아주 disgusting한 결말이지…
그래도 잘해보기위해선 아래처럼 몇 가지 정해주면 좋을 것이다.
- benchmark는 실험과 같아서 물리학 시험을 되살려 무엇을 할지 정리해보는것이 중요하다. (보고서작성?)
- 예상결과는?
- 예상결과에 따른 조작 변인과 통제변인은?
- 예상시나리오는? 예상 시나리오가 나왔다면 그렇게 분리한 이유는?? => 여기서 적은 이유가 진짜 나중에 결과를 납득시킬 근거가 된다.
- 그것으로 충분한가??
- 진짜 그것으로 충분한가?? 아니 옆에 오리를 보고 다시물어봐라 됬어? 너네 최고대장님한테 가도 안 까일 자신있니?
- 선배나 옆사람한테 슬쩍 물어본다.. 이거 이렇게 할라는데 괜찮겠나??? (장담컨데 100% 다시 테스트하게된다)
- 예상결과와 비슷하다고 쉽게 납득(인정)하면 안된다.. 의심해야된다..또 의심..( 보통 내 코드는 잘 못 짯기 때문에 한번에 잘나오면 무조건 잘 못됫다고 봐야된다)
문제가 뭔지 아는가? 모르겠지?
benchmark는 어렵지만 그만큼 얻는게 많다. 여기서 얻은 객관적 수치는 잘 만 측정됬다면, 스스로에게 강력한 근거가된다. 어디든 그렇든 듣는이를 납득시킬 수 있는 매력적인 근거가 매우 중요하다.
모두가 납득할만한 조건으로 테스트를 진행했고 보여줬고, 그로인해 무언가를 결정하게 된다면 그것만큼 좋은 의사결정이 어디있을까?
디버깅
버그났어여? 왜 못잡아여? applicationlog 있지, system log있지, tracing log있지, metric 쏘지…
불과 1년전에 했던 이야기다.
ㅎㅎ
ㅎㅎㅎㅎ
ㅎㅎ
그간 일하면서 디버그와 관련된 어려움이 있었는데..(여기서 디버그는 서비스를 운영하는 모든것들에 생기는 문제에 대한 이야기다) 생각보다 볼 수있는 것들로(로그,메트릭,지식?) 답을 바로 찾는경우가 쉽지않았다.
직접적으로 드러나는 (쉬운)문제인 경우에는 보이는 데이터가 즉각 도움이 된지만 모든 일이 생각되로만 되는가? 전혀 아니지.. 몇몇 경우는 추론할 수 밖에없다. 또 여기서 짬차이가나는데, 이 추론이라는게 그냥 지식이 많다고 잘 하는게 아니다.
무야호~~ 그만큼 큰 벌레였나 보지~~
무슨말이나면 열심히 안다고 그냥 되는게 아니라는거다. 해결되기 어려운것들은 마치 단서를 가지고 범인을 잡는것과 비슷해서 안잡힐듯 하지만.. 희안하
게 패턴이 있는것 같기도하고, 그래도 1주로 의심되는 영역에서 잡히는 것같다.
뭐 아주 기초적인 예를 들면, too many open files가 잡히면 ulimit을 늘려주면 대부분 해결된다든가?
이런 결론을 내는건 기본적으로 근거를 기반으로 추론을 잘하는 능력도 필요하지만, 어느정도는 그것을 숙달한 정도, 즉 짬에서 나오는 바이브가 어느 정도 필요한것 같다.
아 짬에서 나오는 바이브는 그냥 아무에게나 시간이 해결해주는게 아니고 이해하고자 하는 자에게서 시간이지나면 오는 것같다.
아 참고로 필자는 절대적으로 경험을 신뢰하지만 주로 비판적인 생각을 하려고 애쓴다.
의사결정
확실히 알았다. 일단 많이 알아야 된다. docs에 기반한..
현재 내 상황에서 무언가를 주장할 수 있는 바는 크게 뭐 없다. 주로 탁월한 근거는 명확한 지식 인데, 보통 이를 기반으로 주위를 둘러보면 근거가 (감정적으로)믿음이가는 사람은 도메인이 명확하다.
그 증거가
- 어느 프로젝트에서 그것을 잘 썼고 production에서 동작 얼추 했다 => 일단 신뢰가간다.??? (1괜찮나..?)
- 이야기한것이 내 지식내에서 당연히 납득이 가고, docs등에서 컨셉.. 이해방식(?)이 일치한다.
그것을 보니 지금에 내가 할 수 있는것은.. 최대한 빠르게 잘 이해하는 것이다.
지금의 회의나 의사결정에서 얻는것을 최대한 잘 이해해서 담에 같은 일일때 수월하게 써먹을 수 있고, 자신있게 이야기할 수 있을것이다.
아 제가~ 말이죠~~ 예전에 한번 어디서 뭐만들었을떄 써봤는데~~~~~ 이래이래 컨셉이 이래서 이렇게 쓰는게 훠얼씬 좋고 잘 동작했습니다~~~
2021결론 및 정리 그리고 2021에게…
2020년에는 보다 실무적인 리뷰를 단거같다. 그래도 그전해보다 공부한 것보단 직접 짜보고 체득하며 이해한것들이 훠얼씬 많은 것 같아서 좋다.
물론 ㅋㅋㅌㅌㅌ 원하고자하는 것은 못 이뤄서 아쉽긴한데.. 당최 쉬운건 아니라는 것은 알기에.. 일단 기분만 가져가도록한돠..
올해의 목적은 구체적 두 가지를 가져가려고한다.
- 이유있는 코드
- 근거있는 의사결정
저번에는 너무 야망적이고 모호했으며… 너무 터프했어…
이번에는 잘 할 수 있다!!
파이팅..!!