try anything chris!
어떤 개발자가 살아 남는가 본문
개발자로 지내온 지난 날들을 쭈욱 되돌아 보면, 코드를 짜고 버그와 씨름하고 릴리즈 하고 배포하고 등의 일련의 과정들을 컴퓨터 앞에서 계속 보냈지만, 그건 그냥 그 앞에서 시간을 많이 보냈을 뿐이지 이 과정이 순조롭게 흘러가는 모든 단계에는 생각해보면 사람과의 일이었던 것 같다.
그런 과정속에서 나도 개발서적만큼 커뮤니케이션, 철학, 심리, 성장마인드 등에 관련된 책들도 많이 봤던 것 같다. 확실한건 연차가 쌓이고 코드를 보는 시간보다 주위 사람들과 대화를 하는 시간이 많아지면서 그런 책이나 경험들이 도움이 많이 되고 있다는 점이다.
올해 독서 목표로 세운 개발서적들도 모두 코드 하나 없는 그런 책들이다...
이 책의 제목은 그런 관점에 내 관심사를 끌기에 아주 적합하지 않았나 싶다. 사람과의 관계가 더 비율이 높아지는 상황에서 인문학적인 고찰이 분명히 도움이 될 것 같았고, 무려 그게 개발자로서의 인문한적인 관점을 얘기한다고 했으니 말이다.
우리가 어떤 개발 프로젝트를 완성시킬 힘을 갖추어야 한다고 했을때, 그게 프로젝트를 관리하는 위치에 있는 사람도 있고, 개발을 수행하는 위치에 있는 사람도 있고, 품질을 만족시키 위해 검증하는 위치에 있는 사람도 있을 수 있다.
여기에 개발자의 입장에서 좀 더 들여다보면, 연차나 직책에 의해 코드를 구현함으로 참여하는 사람이 있는가 하면, 프로덕트가 완성되도록 조율하는 사람이 있을 수 있다. 하지만 공통적인것은 참여하는 이해관계자들과 함께 완성시켜 나가야 한다는 것이다.
이런 관점에서 내가 어떤 사람인지, 나는 어떠한 사람인지를 인지하고 이해관계자들이 어떠한 사람들인지, 이들과 함께 하기 위한 과정에서 인문학적으로 어떤 사고를 가져야 오랫동안 개발자로써 살아 남을 수 있을지를 알려주는 책이라고 생각이 들었다.
아래는 이 책을 읽으면서 공감이나 내 생각을 요약한 내용이다.ㅋ
서문. AI를 이기는 개발자 인문학
개발자는 프로그래밍을 하지만, 대부분 정해진 프레임 안에 갇혀 있습니다. 누군가가 앞서 프로그래밍해 놓은 도구를 그저 사용하고 있을 뿐입니다. 대부분의 개발자가 이미 만들어진 환경 안에서 주어진 방법론과 도구들을 사용해서 프로그램 코드를 만들어 냅니다.
그런 관점에서 본다면 개발자들은 프로그래밍을 하는 사람일까요? 아니면 프로그래밍을 당하는 사람일까요?
☻ Spring Framework 로 구현하다보면 진짜 프로그래밍을 당하고 있다는 생각이 가끔 들때가 있다;
가장 완벽한 소프트웨어는 완벽을 추구해서 만들어지는 것이아니라 실패를 이어 나가는 과정에서 만들어집니다. 실패로부터 성공을 만들어 내기 위해서 그리고 더 좋은 개발자가 되기 위해서는 철학이 필요합니다.
☻ 확실히 나만의 철학에 대한 필요성을 느낀다.
Senior Engineer 로써 주위의 동료들로부터 수많은 의사결정/조언/검토 등의 요청이 쏟아지는데
그 때마다 일관된 기준의 대응을 하기 위해 얼마나 신경쓰는지 모른다.
내가 예전에도 이렇게 대답했는지, 앞으로도 유사한 문의에 같은 대답을 할 기준으로 생각하고 대답했는지 등 말이다.
1장. AI의 시대, 우리는 어디에 있는가
AI에 의해 대체되는 직업 분야는 그 기술적 구현 난이도와 함께 경제적 가치 또한 고려된다. 소프트웨어는 막대한 경제적 가치를 가지면서 AI 기술에 가장 밀접한 분야다. 옥스퍼드 보고서에 따르면 약 2030년까지 프로그래머의 48%가 AI로 대체될 가능성이 있다. AI를 구축하는 최일선에 있는 소프트웨어 개발자들이 AI에 의해 사라질 수도 있다는 역설적 상황에 직면한 것이다.
☻ Chat GPT가 할 수 있는 것들만 봐도 그렇다. 단순 코더는 이제 위험할 것이다.
AI가 선도하고 있는 테크놀로지 시대의 부흥은 역설적으로 기술 자체가 아닌 인간이 만들어 내는 인간적인 가치에 달려 있다. 결국 기술이 성공하기 위해서 기술은 인간을 향해 있어야 한다.
교육의 첫 단계는 문제를 정립(문법, 논리, 수사학)하는 것이다. 그 다음은 배운 것(산수, 기하, 역사 천문학)을 바탕으로 묹를 해결하는 것이다. 정리하자면 문제를 어떻게 정의하고 접근할 것인가 그리고 최선의 해결 방법은 무엇인가가 인문학을 배우는 목적이 되는 셈이다.
문제를 정의하는 것을 체계적으로 하기 위해 소프트웨어 요구공학이라는 기술이자 학문 분야가 생겨났고, 정의된 문제를 해결하기 위한 체계적인 접근 방법이 소프트웨어 설계다.
2장. 알고리즘 vs 데이터 그리고 창조력 코드
모방으로 그치지 않기 위해서 역설적으로 숱한 모방이 필요하다. 모방에 있어 중요한 점은 가장 기초가 되는 원론을 숙지해야 한다는 것이다. 소프트웨어가 생각대로 잘 구현되지 않으면 더 많은 정보를 찾아보고 더 공부를 하게 되고 자연스럽게 원개념을 정확하게 이해하게 된다. 단편적인 정보들과 여기저기서 복사한 코드들로 소프트웨어를 만들었는데 운이 좋아 잘 동작하는 것이다. 사실 이는 운이 좋은 경우가 아니라 오히려 운이 나쁜 경우가 될 수 있다. 아무 문제가 없었다면 그냥 아주 운이 좋은 것에 불과하다. '그냥 가져다 쓰고 아무 문제가 없길 기도하는 방식의 개발'은 제대로 된 모방이 아니다.
지나온 물길을 거슬러 물살이 최초로 시작된 그 곳에 가 보았던 사람과 그렇지 않고 바로 지금 흐르고 있는 물줄기만을 보고 있는 사람 간의 차이는 있을 수밖에 없다.
☻ 나는 얼마나 많은 원리들을 깊게 파헤쳐보기 위해 노력했던가 많이 반성하게 되는 부분이다.
3장. 누가(Subject) 무엇을(Object) 어떻게(Project) 해야 하는가?
목표 달성이 중요한 게 아니라 달성한 목표가 무엇인지가 더 중요하다.
☻ 이 문장에 솔직히 충격 받았다...이런 생각을 해본 적이 거의 없다는 것에...
소프트웨어 개발자들은 커밋 로그에 자신이 더 노력을 많이 들인 코드, 더 시간을 많이 들여서 개발한 코드에 대한 내역을 우선하는 경향이 있다. 이는 잘못된 방식이다. 동료 개발자나 해당 커밋 로그를 통해 정보를 얻게 되는 이해관계자들 관점에서 중요하다고 판단되는 것을 먼저 기술해야 한다. 비록 그것이 노력을 덜 들인 것이라 할지라도 말이다. 그 코드가 가지는 최종적인 가치가 우선이다.
이것은 보고서를 쓸 때도 마찬가지다. 내가 무엇을 한 것인지가 중요한 것이 아니라 전체 소프트웨어와 프로젝트의 관점에서 중요한 것을 우선 기술해야 한다.
☻ 코드가 시작된 JIRA 티켓에는 목적과 배경이 있지만, 코드 커밋 내용에 이 코드가 가지는 최종적인 가치를 기술해본적은 없는 것 같다;
소프트웨어를 제조업으로 생각하는 마인드를 가지고 소프트웨어 개발자의 창의성을 논한다는 것 자체가 어불성설이다.
☻ 지금의 회사는 제조업인데, 장비용 소프트웨어는 어느정도 이해는 간다만..그래도 플랫폼 서비스는 아니지 않나싶다...
4장. 지속적인 개선 - Upgradable Software
계속되는 개선이 지연되는 완벽함보다 낫다.
소프트웨어 개발이 추구해야 할 것은 완벽이 아닌 완료다.
경험이 없으면 없을수록 더욱 애자일해져야 한다.
☻ 애자일이라는 단어를 쉽게 얘기하지만 수행할때에는 서로의 상황에서 발생하는 딜레마때문에 어려운 것 같다.
기획자 입장에서는 빠르게 적용해보고 피드백을 통해 빠르게 개선할 생각으로 초기 사양을 작게 기술하고,
개발자 입장에서는 나중에 전혀 다른 사양으로 변할때 많은 부분들을 변경해야 하는 위험성을 감수하고 싶어하지 않으니
좀 더 많은 부분들이 확정되었으면 하는데, 이 중간지점을 정하는게 어려운 것 같다.
물론 빠르게 변경이 가능한 아키텍처와 구조를 잡는게 능력이 아니냐고 말한다면... 딱히 떠 오르는 반문이 생각나지 않는다;;
애자일 소프트웨어 개발 선언(애자일 매니페스토)
첫째, 절차와 도구보다 개성과 화합을
둘째, 포괄적인 문서보다 작동하는 소프트웨어를
셋째, 계약 협상보다 고객과의 협력을
넷째, 계획을 따르기보다 변화에 대응하기를
사실 일하다보면 왼쪽의 가치들로 몰려가는게 현실이다.
☻ 첫 직장은 90:10 이었던것 같고, 지금의 직장은 초기에는 30:70 이었는데 현재는 60:40 으로 바뀐것 같다.
소프트웨어 개발 프로젝트는 대부분 장기 프로젝트이고, 선행해서 구현되어야 하는 부분들이 있기에 설계가 중요하다. 제대로 설계되지 않은 상태에서 다짜고짜 코딩부터 해 버리면 나중에 갈아엎고 다시 처음부터 개발해야 하는 상황이 발생하는데, 이전에는 이런 상황 자체를 문제라고 생각하는 경향이 많았고, 설계가 완벽하지 않은 상태에서 개발을 시작하는 것은 비효율적이고 무데뽀고 주먹구구라고 펌하되었다.
하지만 이제 시대가 바뀌었고, 개발의 선각자들은 마냥 기다리는 것보다 그냥 한번 해보는 것이 결코 비효율적인 방법이 아니라는 것을 깨달았다. 설계가 완벽할 때까지 기다라는 것이 아니라 구현을 하고 다시 이를 설계에 반영하는 반복적인 개발 방법이 대세가 되었다. 해보고 아니다 싶으면 다르게 하면 된다는 린(lean) 개발 방식이다.
☻ 이상적인 말이다.
여러 직장의 경험이 없긴 하지만, 주위 다른 직장의 지인들의 얘기를 들어 보아도 이런 방식의 잘 된 경험을 들어보기 어렵다.
비효율적이고 문제라고 생각될 수 밖에 없는 현실이, 언제나 마감 시간은 정해져 있고
"해보고 아니다 싶으면 다르게 하면 된다"라는 시도의 리소스(시간과 인력)조차 허용되지 않는다.
그러니 시도가 불가능하고 한정된 리소스안에서는, 어떻게든 최대한 완벽한 설계가 나오길 기대하고 이를 한번에 완성해내야 한다.
애초부터 어떤 편견이나 잘못된 지식을 향해 있지 않더라도 스스로를 끊임없이 보정하지 않는 이상 우리는 잘못된 길로 들어설 수 있다.
보정되지 않은 자신감, 즉 오만(Pride)은 잘못된 지식의 쌍둥이 형제와 같다. 영어 Pride 는 희한한 단어다. 자신감과 자부심, 자랑스러움이라는 긍정적인 뜻과 함께 오만함과 거만함이라는 부정적인 의미를 함께 가지고 있다.
자신감과 오만 이 두 가지는 종이 한 장 두께의 차이도 나지 않는 상태로 서로를 바라보고 있다.
☻ 스스로를 끊임없이 보정해야 한다! 너무 필요한 말이다
지금 맞다고 알고 있는 것도 시간이 흐르면 바뀔수도 있고, 모르고 있는 것들조차 내 기준의 잣대에 맞춰 예단해 버리면 안된다.
어디선가 들은 말인데 너무 무서운 말, "잘 모르고 무식한 사람이 신념을 가지면 무섭습니다."
최종 사용자에 도달한 소프트웨어가 어떻게 동작하고 어떤 가치를 가지는지 알아야 한다. 이 최종 지점과 자신이 만들고 있는 소프트웨어 모듈간의 끈은 이어져 있어야 한다. 이 두개의 연결이 단절되어 있다면 좋은 소프트웨어를 만드는 것은 힘들고, 또한 좋은 소프트웨어 개발자가 되는 것은 더욱 힘들다. 위대한 개발자가 되기 위해서는 지금 하고 있는 것보다 더 큰 것들을 볼 수 있어야 하기 때문이다. 더 큰 것을 보기 위해서 우리가 우선시해야 하는 일은 지금 주어진 것들을 명확히 보고 이해하는 일이다. 그것이 내가 만들고 있는 소프트웨어이고 내가 만들어서 사용자가 쓰게 될 제품이다. 여기까지 제대로 하고 있다면 전문가라 불일 수 있다.
전문가는 자신이 하고 있는 복잡한 일을 중학생 이상의 수준이면 누구가 이해할 수 있도록 명쾌하게 설명할 수 있어야 한다. 복잡하고 전문적인 일의 체계와 제품이 적용된 실세계를 엉키지 않은 한 줄의 실로 풀어낼 수 있는 사람이 바로 전문가다.
5장. 팀워크 - 함께 만드는 소프트웨어
"프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다."
좋은 프로세스를 가진 회사가 좋은 플랫폼을 만들고 좋은 플랫폼이 좋은 소프트웨어를 만들어 낸다.
진짜 필요한 일은 결과를 만들어 내는 시스템을 바꾸는 것이다.
☻ 프로세스라고 명확하게 정해놓은 항목들이 없지만, 스스로 암묵적인 프로세스 속에서 일하고 있는데
이런 프로세스의 기준은 좋은 프로세스가 아닌, 해서는 안되거나 나쁘지는 않은 정도의 수준이 그치는 것 같다.
예전에 오너기반 이었을때에는 좋은 프로세스, 좋은 문화, 좋은 복지를 신경쓰고 있다는게 느껴졌는데
지금 투자회사의 자본금이 들어온 기반에서는, 단기성장과 EXIT 등 빠른 투자금 회수에 필요한 것만 신경쓰는게 느껴져서 아쉽다.
시간이 지난 지금 생각해보면, 그때 오너가 좋은 프로세스, 좋은 문화를 만든것도 장기적인 관점이었다기 보다는
잘 포장해서 판매하고 EXIT를 위한 밑작업이 아니었나라는 생각에 내가 너무 순진했었던것 같다.
코딩이나 글쓰기에서 명료성은 생명과도 같다.
오해를 불러일으키는 코드가 이해하기 어려운 코드보다 나쁘다.
☻ 코드 리뷰의 코멘트는 섬세하게!!
다른 쪽에서의 문제를 해결해 주기 위한 노력이 아닌, 자기 쪽에 문제가 없다는 것을 증명하려는 노력이 우세할 때 결국 프로젝트는 산으로 간다.
☻ 저연차때에는 내 쪽에 문제가 없다는 것을 확실히 하는게 나의 실력을 증명하고 높이는 거라 생각했는데,
확실히 연차가 쌓이고 전체를 바라봐야 하는 위치에 서다보니, 상대방의 문제를 해결해주는 것이
전체의 문제를 해결하는 빠른 지름길이고 이게 나의 전문성을 키워주고 내 능력을 인정받는 것임을 알게 되었다.
외부로 나가는 소통을 명료하게 하는 것, 외부로부터 받는 소통에 있어 최대한의 융통성과 관용을 보이는 것,
이 두가지를 두 글자로 표현하면 바로 '배려'다.
☻ 커뮤니케이션의 중요성! 상대방을 높이는 겸손과 배려가 사실은 나를 높여주는 결과를 가져온다.
