Grace's Tech Blog

보호되어 있는 글입니다.

작년 전사적으로 일정 이슈가 많았을 때여서, 코로나에 걸렸는데도 tile processor 구현 일정에 스트레스를 받고 있을 때 소프트웨어 원칙 만들기 에서 "프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다.” 글을 읽고 많은 부분을 공감하였다. 이 말이 나온 책이 윈도우 95의 프로그래머이신 "나카지마 사토시" 님이 저자인 이고, 이 책을 읽고 중요하다고 생각한 부분을 남기고 중간중간 떠오른 생각을 정리했다. 책의 내용은 인용 박스 로 구분하였다. 0. Intro. 시간 관리의 필요성. 독일의 문호 괴테는 말했다. “아는 것만으로는 충분하지 않다. 활용해야 한다. 의욕만으로는 충분하지 않다. 실행해야 한다.” 그는 갑자기 치고 들어오는 일이 생길 가능성..

보호되어 있는 글입니다.

글을 작성하는 개발 직군분들이 모여서, 좋은 영향을 주고 서로 같이 자랄 수 있는 커뮤니티인 글또 6기에 이어 7기에 참여하게 되었다. 1. 글또 7기 시작 배경 올해 초 ~ 4월 말(벌써 5월이라니!)에는 개인적으로 몸과 마음이 많이 힘든 시기였다. 커리어 방향성에 대해서 혼란스럽기도 했고 성장이 더디고 부족함만 계속 보이는 것 같아 조급한 마음이 들었다. 그리고 배울 점이 많고 함께 일하고 싶은 팀원이 다른 곳으로 떠나는 일은 나의 마음을 뒤숭숭하게 하기에 충분했다. 그래도 다행인건 그 시기 동안 나자빠져있기보단 뭐든 하려고 했다. 내가 힘들어 하는 이유를 정리하고 그를 해결하기 위한 Action Item을 정하고, 준비하고, 지원하고, 합격해서 이제 시작하는 단계를 거치고 있다. 그중 하나가 글또 ..

며칠 전 잘 해내지 못한 일 몇 가지에서 내가 잘 못하는 한 가지 습관이 있다는 것을 알게 되었다. 정확히 말하자면 피드백을 받아서 알게 되었다. 그리고 바로 다음 날 나는 동일한 실수를 또 했다. 전문성 형성, 믿을 수 있는 직관이 형성되기 위해서 필요한 것은 타당성: 직관이 적용되는 영역에 어느 정도 인과 관계와 규칙성이 존재해야 한다. 피드백: 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다. 이라고 한다. 거꾸로 말하면 수십 년 동안 한 가지 일을 하면서도 타당성과 피드백이 부족한 환경에서 일한다면 전문가가 되지 못한다. 타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력을 하면 된다. 그리고 피드백을 높이려..

을 읽으면서 머리가 많이 복잡했다. 아직까지도 시스템이라는건 너무 광범위하게만 느껴져서 온보딩 프로젝트에서 배운 3 Layer Architecture와 Dependency Injection, 머신러닝 코드를 리펙토링 할 때 머리싸매며 고민한 class의 적절한 사용, 디자인 패턴 아직도 누가 객체 지향 프로그래밍이 뭐냐고 물어보면 어버버 할 것 같은 그 객체 지향 확장성, 설계, ... 더 나아가선 MSA, 애자일, 문서화까지.. 실무에서 경험하긴 했지만 아직 내 안에서는 정리되지 않은 채 파편화되어 있는 개념과 경험들이 떠올랐기 때문이다. 그러면서 동시에 앞으로 추구하고 싶은 커리어 방향성을 알 것 같았다. 학생 때는 할 줄 아는 기술 스택들이 많은게 간지인 줄 알고, 유지보수나 확장성 등은 고려하지도..

오늘 동료 개발자 분께서 인프랩 기술 블로그 - 을 공유해주시면서 사내 Project post-mortem 문화를 좀 더 체계적으로 할 수 있도록 개선도 하셨다. 올해 '2022년에는 함께 일하기 즐거운 회사, 팀이 되기 위해 pain point에 좀 더 관심을 가지고 좀 더 팀 문화 개선에 기여하는 사람이고 싶다.'고 다짐했는데, 아직까진 매번 도움받고, 배우고, 감동받는 단계인가보다. 우리 회사에는 post-mortem문화가 있다. 입사 한 지 별로 되지 않았을 때 우리 서비스에 어떤 버그가 발생했는데, 모든 개발자가 모여 다같이 부검해보고 action item을 도출해보는 시간을 가졌다. 이 경험을 통해서 처음 post-mortem(부검)와 그 문화에 대해서 알게되었다. post-mortem 문화를..

보호되어 있는 글입니다.

요즘 Task/Issue Tracking, Code Review, .. 등 많은 것들이 보완되고 바뀌는 것을 경험하면서 느낀 것은 회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다. - 6장. 동작하는 소프트웨어

회사에서 개발에 대해서도 배우는 게 많지만 정말 값지다고 생각하는 것은 동료분들의 문제 해결 방식과 그 과정에서의 사고의 흐름을 지켜보고, 나누고, 배울 수 있다는 점이다. 우리 회사의 개발팀은 '깊이'를 정말 중요하게 생각한다. 깊이 있는 이해 깊이 있는 고민 이런 가치관과 문화를 가진 사람들과 일하는 환경에 있으면서 "그렇게 그냥 가져다 쓰고 말면 바보된다" "직접 구현해 본 경험이 있으신가요?" "그걸 알면 보는 시각이 넓어지잖아" "그래서 지금 해야하는게 뭐지? 그러기 위해선 뭐가 필요하지? 어떤 식으로 가야 불필요한 소모를 쉽게 인지하고 피할 수 있을까?" 등과 같은 말들이 주위를 맴돈다. 그리고 나도 모르게 그렇게 중얼거리고 있을 때도 있고, 의식적으로 더 깊이 있게 알아보려고 노력하기도 한다..