노상원 수첩 보니…'전 국민 출국금지'부터 장기집권 구상까지 | 아주경제
노상원 전 정보사령관의 수첩에 적힌 수거 대상에 대한 구체적인 사살계획과 비상계엄 장기화를 위한 날짜별 실행계획도 공개됐다.지난 13일 MBC에 따르면 노 전 정...
m.ajunews.com
💜 바쁜가? 무엇 때문에 바쁜가?
stibee.com
요고는 이번 콘텐츠를 읽고, ‘바쁨’이 단순히 일정이 많아서가 아니라, 비효율적인 업무 방식과 조직 문화에서 비롯될 수도 있다는 점이 인상적이었어요. 바쁜 일정이 곧 성과를 의미하는 것은 아니잖아요?
오히려 우선순위를 정리하고 효율적으로 일하는 사람들이 더 나은 결과를 만들죠. 하지만 역설적으로, 덜 바빠 보이는 것이 덜 성실한 것처럼 여겨지기도 해요.
결국, 조직은 ‘덜 바쁜 사람’보다 ‘더 바쁜 사람’을 성과가 좋은 사람으로 착각하기 쉽죠. 하지만 진짜 성과는 바쁜 일정 속에서 만들어지는 것이 아니라 ‘어떤 일에 시간을 쓰느냐’에요.
바쁜가? 무엇 때문에 바쁜가? | 요즘IT
하루 종일 캘린더를 가득 채운 회의와 미팅들, 나의 결정을 기다리는 슬랙 메시지와 이메일들, 지라 티켓과 태그된 코멘트로부터 도착한 수많은 알림. IT 스타트업에서 일해본 사람이라면 의외
yozm.wishket.com
하루 종일 캘린더를 가득 채운 회의와 미팅들, 나의 결정을 기다리는 슬랙 메시지와 이메일들, 지라 티켓(JIRA assigned ticket)과 태그된 코멘트로부터 도착한 수많은 알림(Notification).
IT 스타트업에서 일해본 사람이라면 의외로 상당히 익숙한 장면이기에 기시감이 느껴질 수도 있을 듯하다.
꼭 여느 스타트업을 언급하지 않더라도 대표나 본부장, 임원급 혹은 C레벨이라고 불리는 사람들의 캘린더에서는 한 줄로 모자라 두 줄, 세 줄로 겹쳐 있는 일정들을 손쉽게 발견할 수 있다. 밥 먹을 시간도 없이 바쁘고, 그래서 워킹 런치라는 이름으로 미팅을 묶어보기도 하지만, 이건 점심도 아니고 회의도 아닌 경우가 대부분인 데다 시간에 맞춰 밥을 먹기는 커녕 회의를 하기도 힘들다.
처음에는 한 시간 미팅을 잡다가 미팅할 시간이 모자라서 시간을 쪼갠다고 25분 미팅으로 줄여서 잡아도, 20분 늦게 오는 경우가 많으니 상대방은 한 시간을 일단 비워둬야 한다. 게다가 앞뒤로 계속 일정에 쫓기다 보니 그 미팅에서 무슨 얘기를 할지, 무슨 결정을 할지도 준비하지 못하고, 그때그때 임기응변으로 즉흥적으로 대응할 수밖에 없기도 하다.
그렇게 시간이 미뤄지고 조금 타이밍을 놓치면 이번 미팅은 지난 미팅 때문에 미뤄지고, 다음 미팅은 이번 미팅 때문에 그렇게 또 미뤄진다. 이렇게 도미노처럼 쌓여 있는 미팅이 밀리고 밀리다 보면 하루 일과가 끝나고, 우리는 “보람찬 하루 일을 끝마쳤다”고 할 수 있을까?
그래서 당신은 대체 무엇 때문에 그리 바쁜가?
나는 스타트업의 경영진, 대표가 눈코 뜰 새 없이 바쁜 것에 대해 매우 깊이 ‘그럴 수 있다’고 생각한다.
구성원은 물론이고 외부로 눈을 돌리자면 투자자에서부터 외부 파트너사, 영업 대상은 물론 수많은 정부 기관의 지원 사업들과 운영 기관들까지, 그를 찾는 사람이 너무도 많다.
기실 조금만 둘러보면, 꼭 대표가 아니더라도, 어느 회사의 CPO, CTO이거나 개발실장이거나 하는 사람들은 으레 캘린더가 가득 차 있다.
기본적으로는 정기 회의가 일단을 채우는 데다가 시즌이 되면 요구사항을 전달하기 위해 요청 받는 개발사항/로드맵 요구회의들이 끝도 없이 생겨난다. (여러 부서 또는 상위 부서나 경영진으로부터 나오는 요청 사항으로 인한 회의를 “요구회의”로 통칭했다.)
그리고 빼곡히 잡혀 있는 1on1 미팅. 하루에 1on1을 10개는 해야 하는 날이 하루씩은 꼭 끼어 있다. 30분 단위로 1on1을 돌려 진행하고 나면, 대체 나는 누구와 1on1을 했는지, 무슨 대화를 했는지조차 헷갈릴 지경이다. 그뿐 아니라 조직이 성장하거나 채용이 바쁠 때에는 면접도 하루에 2-3건씩 들어가야 한다. 하루는 8시간이라는데, 인터뷰 참석에 3시간을 쓰고 나도 여전히 10시간은 할 일이 남아 있는 것 같다.
그래서 그 일들 가운데 ‘성과가 있는 일’은 대체 무엇인가?
채용대상자의 인터뷰 일정을 조정해 주는 것만으로 큰 기업 가치를 인정받는 회사들이 있다.
사람들이 바쁜(?) 현업 와중에 시간을 쪼개어 인터뷰를 보려면 충분히 그럴만도 하겠다. 일정 조정을 하기 위한 별도의 노력과 인력을 줄일 수 있을 뿐 아니라, 일정을 조정하는 경험이 탁월하게 좋을 수 있다고 한다. 그러니 더더욱 그 회사의 기업 가치나 투자 행위에 공감할 만하다.
하지만 정작 인터뷰를 보는 그 시간은 어떠한가?
미리 한번 훑어보지도 못하고, 현장에 들어와서 지원자와는 눈 한 번 마주치지 않고 그제야 랩톱으로 읽어 내려가는 이력서. 준비가 안 되었으니 대충 예전에 어디서나 했을 법한 반복되는 질문들. 인터뷰 보는 중에 평가표를 채워 넣어야 한다는 압박감. 중간중간 올라오는 슬랙 알림. 그렇게 구조적인 질문을 하기는커녕, 상투적으로 아무런 질문이나 던지고 으레 인사치레나 한 두 마디 하면서 예의를 갖추는 척하고 있지는 않은가?
인터뷰어의 문제로 상대방을 파악하지조차 못했으면서, 진짜 탈락의 이유는 ‘나에게 인상적인 감흥을 주지 못했기 때문’인데, 우리 회사의 조직 문화에 맞지 않아서라거나, 경험한 프로젝트의 깊이가 느껴지지 않아서 라고 탈락 이유를 적고 있지는 않은가?
이쯤 되면 차라리 인터뷰를 보지 말라고 하고 싶을 지경이다. 인터뷰이에 대한 예의가 아닌 것은 둘째로 쳐야 할 만큼, 그 인터뷰 시간이 당신은 물론 당신의 동료들에게 미치는 파급효과가 너무 크다. 차라리 그 시간에 당신의 동료들이 애타게 찾는 슬랙이나 티켓에 응대하는 게 조직 전체에 큰 효용 가치가 있을 것이니까.
일은 많은데 사람이 없어서 바쁜가?
매일 밤을 샌다며 불평불만을 하는 SRE팀 담당자는 “자기들이 얼마나 바쁘고 리소스가 부족한 줄 알고 있느냐”며, 자기들에게 업무를 요청할 때는 최소 2주 전에는 줘야 겨우 일정을 맞춰낼 수 있다고 강변한다.
그럼 더 채용을 해서 리소스를 늘리면 될 텐데, 사람을 뽑으면 적응할 때까지 당장 더 바빠질 수도 있다고 우려한다.
채용한 사람이 뛰어난 사람이면 어려운 일을 넘기고, 평범한 사람이면 시간을 잡아먹는 나머지 업무(Stuff job)를 넘기면 될 일인데, 슈퍼맨을 뽑아야 하기 때문에 채용은 해내질 못한다. 그리고는 우리의 업무 스타일과 조직 문화에 맞는 사람을 찾을 수 없다고 한탄한다.
우리의 조직 문화를 정의해낼 수 있다면, 그것을 JD에 작성하고 맞는 사람을 추천받아도 좋을 텐데, 너무 바빠서 그것을 정리해 낼 시간도 없는 것 같다.
특히나 스스로 암묵지 속에 존재하는 것을 조직 문화라고 착각하거나 프로세스로 정제되지 않아 되는 대로, 닥치는 대로 처리하는 것을 업무 스타일이라고 주장하면 곤란해진다.
그렇게 본인은 불평불만을 하다가 약속된 베스팅 기간을 채우고 퇴사해 버리면 그만일 테지만.
30분 단위로 1on1을 하루 10개 잡아 놓고, 10~15분씩 늦어져 사람들이 그것을 위해 대기해야 하는 상황이 벌어진다면, 어떻게 편안하고 캐주얼하고 진실한 상태의 1on1이 이루어 진단 말인가.
혼자 업무를 지시하며 하고 싶은 말이나 하는 시간을 종일 잡아놓고 본인의 시간뿐만 아니라 상대방의 시간까지 같이 허비해 버리는 것은 아닐까.
결국은 1:1 업무 지시 시간으로 전락해 버렸지만, 그 업무 지시는 일관되거나 통일되지 않고 상대방이 따로 시간을 들여 조율해야 하는 추가 과제를 던져버리고야 마는 이상한 1on1 묶음(1on1 Bunch)을 하며, 나는 조직 구성원에 최선을 다하는 성실하고 진실한 리더라는 착각에 빠져 있지는 않은가?
나는 이렇게 구체적으로 관리하고 있는데, 상대방이 무능하고 성실하지 않아 나의 지시 사항을 제대로 이해하지 못하고 이행하지도 않는다며 한탄하고 있지는 않은가?
바쁨의 네트워크 효과
현대 조직에서는 나 홀로(Stand alone으로) 일하고 완성하는 경우는 거의 존재하지 않는다.
수많은 네트워크로 업무와 시간이 얽혀있기 때문에, 한사람이 시간을 허비하면 조직 전체에 그 파급 효과가 전달된다.
즉, 조직이 전부 다 같이 바빠지기 마련이다. 너무 많은 사람이 자기 계획대로 시간을 사용하지 못하는, 이런 조직에서 보이는 증상은 대표적으로 두 가지이다.
첫 번째 증상: 비효율적인 회의를 줄이자는 말을 입에 달고 산다
툭하면 회의를 서면으로 대체하고 다들 바쁘기 때문에 그렇다고 한다. 실제로도 다들 바쁘고 캘린더가 항상 가득 차 있다. 다만 그것이 과연 정기 회의보다 중요한가. 누군가는 자신의 시간에 비해 150~200%의 일을 하고 있고, 그 사람과 가까운 네트워크에 위치한 사람일수록 더 많은 시간을 그 사람에 맞추기 위해 할애하고 있다.
이 조직을 바쁘게 만드는 범인은 누구일까? 마치 비유하자면 축구 경기에서 수비 라인을 세우고 오프사이드 트랩을 맞추는 데, 라인이 깨질 때마다 손들고 오프사이드를 주장하는 ‘그 자’가 오히려 트랩을 맞추지 못하는 자일 가능성이 가장 높은 것은 아닐까?
두 번째 증상: 개인기에 대한 과도한 찬사가 있다
개인기나 필살기(패시브 스킬이건 액티브 스킬이든)는 정말 소중하고 중요하다. 마찬가지로 축구의 예를 들면, 마르세유 턴으로 한 명을 순식간에 벗겨낼 수는 있다 해도 그 턴을 계속 반복하면 그때부터는 안토니 턴*이 되어 버린다는 뜻이다.
*안토니 턴: 축구 선수 안토니(Antony)의 시그니처 개인기. 주로 제자리에서 공을 잡은 상태로 한 바퀴 도는 개인기를 말하는데, 효과가 크지 않아 조롱거리로 쓰이기도 한다. (에디터 주)
바쁜 일정 순간순간 즉흥적으로 결정을 내려야 하고, 나의 결정을 기다리는 수많은 사람에게 즉답을 해야만 하는 상황에서는 개인기로 이를 극복하는 임기응변이 기본값이 되어버린다. 그렇게 그 상황을 개인기로 넘기는 것이 지상과제처럼 되어 버린다.
문제의 원인은 개인기의 남발에 있는데, 다른 곳에서 해법을 찾고 싶어 하며 개인기를 부리는 사람에 대한 찬사와 리스펙트는 유지한다.
시스템과 포메이션으로부터 발현된 문제를 개인기로 극복하는 순간은 칭찬받을 수 있고 스포트라이트를 받을 수도 있지만, 그것을 매번 반복하다 보면 개인기로 극복하지 못하는 것을 개인의 위치 문제로 치환해 버린다. 그렇게 가장 비난하기 손쉬운 상대를 찾고, 다른 이들에게는 뛰어난 개인기를 계속 발휘하기를 장려한다. 이제 팀워크와 빌드업은 온데간데없고 모두들 개인기를 부려 칭찬을 받고자 한다.
바쁜가? 무엇 때문에 바쁜가?
대표는 아무리 바빠도 바빠서는 안 된다. 리더라면 결코 캘린더를 가득 채운, 바쁜 상태가 되어서는 안 된다. 본인이 바쁘면 본인이 속하고 섞여 있는 조직 전체가 다 같이 바빠지기 때문이다. 그리고 나면 내가 200%, 300% 일을 하고 시간을 들여봤자, 그만큼 소속된 조직 구성원 전체의 시간을 방해(interfere)할 뿐이다. 그래서 모두가 다 같이 바빠지는 것이다. 조직이 모두 아주 바쁜 것은 뿌듯한 일인가?
솔선수범하며 함께 짐차를 끌고 가는 진정한 리더가 된 것 같은 기분이 드는가? 내가 다른 누구보다 더 바쁘게 일을 한다면, 나의 구성원들은 나를 리더로 여겨 함께 최선을 다해 바쁘게 일할 것이라고 상상하는가? 그렇다면 이렇게 묻는다. 조정 경기에서 노를 젓지 않는 한 명은 왜 존재할까? 같이 노를 저으면 더 빠르게 갈 수 있을 텐데 말이다.
어떻게든 억지로라도 바쁘지 않기 위해 최선을 다해 노력해야만 한다
‘나 혼자 바쁘더라도 다른 구성원에게는 항상 당신을 위한 여유와 여지를 가지고 있다는 믿음을 주어야 하는 것’이 대표라고 나는 생각한다.
실제로 대표에게 그러한 사색과 고민의 시간이 필요하다는 수많은 연구 결과를 어렵지 않게 찾아볼 수 있다. 회의에서 임기응변으로 고민해 보겠다거나 시간을 들여 검토해 보겠다는 정도 개인기를 말하는 것이 아니다. 진실로 생각하고 사색할 ‘뭉치 시간’이 필요하다. 그러려면 무엇부터 시작해야 할까?
사적인 채널의 소통(Private Channel Communications)을 없애야 한다
앞에서 언급했듯 사실 대표나 리더가 1:1로 지시하는 것은 일관성을 가질 수가 없다. 다른 글에서도 강조한 바 있지만, 실무진일수록 맥락 기반으로 의사결정을 하고, 경영진일수록 TPO 기반으로 의사결정을 한다.
1:1로 상대방을 만나 얘기를 듣고 나누고 그 답을 찾아 주려고 하다 보면, 그 사람과의 TPO를 기반으로 하는 ‘올바른’ 결정(그 시점과 상황에 한정해서는 정의롭고 올바른)을 내리게 된다. 그리고 다음 1on1을 하면 다른 상대방과 다른 상황에서 얘기를 듣고 나누고 답을 찾기 때문에 또 다른 ‘올바른’ 결정을 하게 된다. 그렇게 나는 계속 일관되게 ‘올바른’ 결정을 하고 있는데, 그 상황을 벗어나면 상충하는 여러 결정이 내려져 있다.
왜 사적인(private) 채널로 의사 결정을 하고 싶은가? 비난받는 것이 두렵기 때문이다. 나의 결정, 나의 태도, 나의 대화가 공공(public)에 나섰을 때, (부족함이나 모른다는 것이 드러나며) 비난받을 가능성이 비약적으로 높아지기 때문이다. 그래서 내가 비난받지 않기 위해 다른 이의 시간을 낭비하게 된다.
요청을 받아 대화는 1:1로 진행하더라도 결정은 반드시 퍼블릭 채널에서 함께 내릴 수 있어야 한다. 그것은 연습과 반복을 통해 문화로 정착되어야 한다.
정기 회의의 힘을 믿어야 한다
정기 회의체에서 결정을 내리는 문화를 가져가야 한다. 특히 회의체에 들어오기 전, 결정할 사항과 그것을 위한 준비를 하고 와야 한다.
그런 문화가 없다면 앞서 인터뷰 케이스처럼 그 자리에서 임기응변으로 대응하고, 답변은 항상 “내부 회의와 논의, 고민을 더 하고 결정하겠다”로 마무리한다. 그러면 다른 사람들은 당신의 결정을 위해 또 다른 시간을 기다림으로 허비해야 한다. 고민하면 더 좋은 결론에 도달할까? 아니, 그 회의장을 나가 고민할 시간을 가지고 있기는 한가? 맥락 기반으로 실무자들이 결정할 수 있도록 Direction만 결정하는 일조차도 고민해야 결정할 수 있는 수준이라면, 왜 Director의 호칭을 받고 있는 것인가? (보통 이사 또는 본부장 등의 영문 호칭은 Director를 사용한다)
정기 회의체는 결정을 내리는 퍼블릭 채널로 이용해야 하고, 조직 전체가 그 회의에서 죽이 되든 밥이 되든 결정이 내려진다고 믿고 계획할 수 있도록 해야 한다. 물론 그렇게 준비를 해도 그때그때 발생하는 예상하지 못했던 사안들을 피할 수는 없다. 또 그럴 때에는 정말 어쩔 수 없이 개인기를 부려야만 할 수도 있다.
어차피 그렇게 될 수도 있으니까 시간을 더 가지고 고민을 회의 바깥으로 가져가겠다고 마음을 먹기 시작하면, 그때부터는 걷잡을 수 없을 만큼 더 많은 사안들이 당신의 시간을 흡혈하듯 빨아먹게 될 것이다. 그만큼 당신의 네트워크에 있는 사람들이 당신을 위해 긴 시간을 할애해 주어야만 할 것이다. 현장에서 모든 결정을 마무리한다는 최대의 노력을 기울였을 때, 비로소 내가 진짜 고민해야 할 중요한 사안들만이 추가 시간을 요구하는 고민거리로 남을 것이다. 개인기는 그 정도만 부려도 충분히 칭찬받고 찬사받을 수 있다.
나는 PMO(Project Management Office)를 운영하면서, 모든 프로젝트에 대해 일정 주기로 정기 회의를 설계했다. 아무런 할 말이 없을 때에는 모여 커피 한 잔 나누는 시간으로 삼는 한이 있더라도 회의를 취소하거나 서면으로 대체하지 않았다. 가능한 모든 결정 사항은 그 자리에서 의견을 나누고 방향을 좁혀내려고 했고, 상급자 또는 누군가 의견을 듣고 오겠다고 하면 다음 정기 회의에서는 반드시 결정을 내려야 한다고 주지시키기도 했다.
모두들 예상할 수 있는 대로, 상급자의 의견/결정을 청취해 오겠다고 한 주를 미룬 결정은 거의 대부분 한 달씩 밀려나서도 분명한 결론을 내리지 못하는 경우가 많았다. 다들 실제로는 충분하게 사유나 사색의 시간을 할애하지도 않았으면서 대단한 고민을 하는 듯이 시간을 소모하곤 했었다.
그리고 그렇게 상급자로부터 받아온 결정은 결국 사적인 채널의 결정(Private Channel Dicision)이 되어 맥락을 충분히 반영하지 못하며 일관적이지 않은 경우도 많았다.
이렇게 두 가지 방법만 충실하게 시도하고 조직의 문화로 자리매김할 수 있다면, 지금 캘린더를 가득 채운 일정 가운데 그래도 10~15% 정도는 여유를 가질 수 있지 않을까? 그렇게 좀 더 제품과 결정에 대한 사색과 사유가 많아지지 않을까 하는 기대를 가져본다.
🔁 여러 번 반복되는 업무 요청과 변경 사항 (46%)
가장 많은 티동이(46%)가 업무 요청과 변경 사항이 반복되는 것이 비효율적이라고 답했어요. 계획이 자주 바뀌면 생산성이 떨어지고, 업무 피로도가 쌓일 수밖에 없죠. 효율적인 커뮤니케이션과 명확한 업무 프로세스가 절실하네요!
📂 필요한 정보가 공유되지 않아 혼자 해결해야 할 때 (30%)
30%의 티동이들은 정보가 제대로 공유되지 않아 혼자 문제를 해결해야 하는 상황을 가장 답답한 비효율로 꼽았어요. 중요한 정보가 팀원들과 원활히 공유된다면, 불필요한 시행착오를 줄이고 업무 속도를 높일 수 있겠죠?
📅 사전 준비 없이 즉흥적으로 진행되는 회의 (12%)
12%의 티동이들은 준비 없이 시작하는 즉흥적인 회의를 비효율의 원인으로 꼽았어요. 논의해야 할 내용이 정리되지 않은 채 회의가 진행되면, 시간만 낭비되고 결론도 흐지부지해지기 쉬워요. 회의 전에 목적과 안건을 명확히 정하는 게 중요하겠죠?
⚡ 상사의 갑작스러운 지시로 업무 우선순위 변경 (12%)
12%의 티동이들은 상사의 예상치 못한 지시로 인해 업무 우선순위가 바뀌는 것이 가장 비효율적이라고 답했어요. 계획적으로 진행하던 일이 중간에 바뀌면 업무 흐름이 깨지고, 전체적인 일정에도 영향을 미칠 수밖에 없죠. 효율적인 업무 조율이 중요하겠어요!
프로그래밍이 정말 빠르게 변하고 있습니다 | 요즘IT
몇 년 전부터 챗GPT 열풍이 있었지만, 인공지능이 개발자에게 미칠 영향에 큰 관심을 두지 않고 있었습니다. 적어도 작년 여름까지는 그랬던 듯합니다. 그러다가 지난여름 어느 날 인공지능 분야
yozm.wishket.com
몇 년 전부터 챗GPT 열풍이 있었지만, 인공지능이 개발자에게 미칠 영향에 큰 관심을 두지 않고 있었습니다. 적어도 작년 여름까지는 그랬던 듯합니다.
그러다가 지난여름 어느 날 인공지능 분야의 저명한 전문가 안드레이 카파시(Andrej Karpathy)가 AI 툴을 이용한 개발에 대해 쓴 글을 보게 되었습니다. 그는 커서(Cursor)라는, 인공지능을 기본 탑재한 IDE로 개발하는 일을 두고 “자연어(영어)로 프로그래밍을 하고 인공지능이 생성한 결과를 활용한 반코딩(half-coding)을 하는 양상”이라고 묘사했습니다.
안드레이 카파시(Andrej Karpathy)는 누구인가요?
안드레이 카파시는 인공지능 분야의 저명한 전문가로, 스탠퍼드 대학에서 페이-페이 리 교수의 지도하에 딥러닝과 컴퓨터 비전으로 박사 학위를 취득했습니다.
이후에 OpenAI 창립 멤버 (2015-2017)였으며, 테슬라 인공지능 부문 책임자(2017-2022)를 역임했으며, 최근에는 2024년 AI 교육 스타트업 유레카 랩스(Eureka Labs)를 설립했습니다.
주니어 개발자나 외주 개발을 대체할 수 있어요
작년에 SNS로 연락을 취해 온 개발자를 만난 일이 있었습니다. 아마도 그는 제가 개발과 사업 경험을 모두 갖고 있기 때문에 만남을 청한 듯합니다.
개발 커뮤니티에 관심이 있는 저는 동료나 후배 개발자들과 생각을 나누는 일을 즐기기 때문에 흔쾌히 만남에 응했습니다.
그는 자신을 10년 차 개발자로 소개했는데, 이제 스스로 개발을 하는 1인 사업자가 될 수 있다고 확신하고 있었습니다. 어떤 사업인지는 분명하지 않았지만, 그를 독립 개발자로 나서게 한 직접적인 동기는 인공지능이 만들어 주는 코드 생산력이라고 합니다.
그런데, 그 즈음에 중국에서 함께 일했던 가까운 후배와의 만날 일이 있었습니다. 그에게 지금 다니는 회사를 나와서 외주 개발을 하는 회사를 설립하겠다는 말을 들었습니다. 마치 데자뷔 같은 장면이었습니다.
그는 자신을 믿고 따르는 두 명의 인턴사원과 손발을 맞춘 일이 있다며, 회사에서 애정이 가지 않는 일을 할 바에야 셋이서 전업으로 일을 하면 지금의 몇 배는 할 수 있다고 확신했습니다. 이번 확신의 중심에도 ‘인공지능의 위력’이 있었습니다.
인공지능의 위력을 설명하는 방식은 다음과 같은 식이었습니다. 인공지능 출현 이전에는 번거롭지만 시간이 걸리는 작업을 주니어에게 맡겨왔는데, 인공지능을 코딩에 활용하면 그럴 필요가 없다고 그는 강조했습니다.
이를테면 ‘몇 명 정도 개발자가 할 일을 혼자서 할 수 있다’며 구체적인 수치를 거론하기도 했습니다.
혼자서 할 엄두가 나지 않던 CSS 작업을 가능하게 해 줘요
한편, 지금 회사의 동료 개발자는 어떻게 느끼는지도 궁금했습니다. 그는 소위 백엔드 개발자 출신이기 때문에 평소 웹이나 앱 화면을 구성하는 복잡한 프론트엔드 코드에 자신이 없었다고 합니다. 커서를 사용하기 전에는 말이죠.
그러나, 커서를 쓰고 나서는 굳이 프론트엔드 개발자에게 코드를 작성해 달라 부탁할 필요가 없다고 합니다. 원하는 화면을 그대로 프롬프트에 던지고 인공지능이 만들어 준 코드를 이해한 후에 필요한 부분만 고치면 그만이라고 말합니다.
대화를 거듭하면서 호기심이 생겨서 직접 커서를 써 보기로 했습니다. 일단, 작은 실험을 해 보기로 했죠. 저희 회사에서는 React와 Go를 기반 프로그래밍 언어로 쓰고 있는데, 이들이 화면을 표현하고, 화면에서 벌어진 사용자 행위를 서버에 전달하는 틀을 코드로 보고 싶었습니다. 참고로 저는 이 두 언어 모두에 대한 사용 경험이 없는 상태였습니다.
놀랍게도 별도의 학습 없이 몇 시간 시행착오만으로 원하는 수준의 코드를 얻을 수 있었습니다. 말 그대로 한국말로 제가 원하는 바를 프롬프트로 전달하고 나온 코드를 얻은 것이죠. 물론, 만들어진 프로그램을 실행을 하고, 어떤 의미인지를 알 수 있어야 한다는 점이 전제입니다.
하지만, 이는 개발자라면 누구나 일상으로 하는 행위입니다. 프로그래밍 작동에 대한 아주 기본적인 이해만 있다면, 자신이 만들고자 하는 것이 무엇인가를 정교한 말로 정의하는 일이 코드 작성을 대신해 주었습니다.
저는 90%의 시간은 프롬프트 작성에 쓰고, 10%만 코딩을 해요
그 후로 연말과 연초를 지나는 가운데 개발자들과 만날 일이 있으면 인공지능에 대한 상대의 경험과 견해를 물었습니다. 두 가지 답변이 인상 깊었습니다.
한 번은 저를 제외한 두 명의 개발자가 정반대의 의견을 개진하는 상황이었습니다. 한 분은 조금 과장하면 예찬론자에 가까웠고, 다른 한 분은 테스트 코드 작성 아니면 처음 코드를 작성할 때나 도움이 된다고 했습니다. 저는 후자의 주장이 흥미롭게 여겨졌습니다. 그래서, 거듭 질문을 하며 그가 그렇게 느끼는 이유를 알고자 노력했습니다.
그의 답을 들으면서 머릿속에서는 두 개의 단어가 떠올랐습니다. 하나는 레거시이고 두 번째는 맥락(Context)입니다. 레거시가 떠오른 이유는 인공지능 효용성에 의문을 제기한 개발자의 가장 강력한 근거 때문입니다. 그는 자신이 속한 특정 업종에서는 “생성형” 인공지능이 큰 도움을 줄 수 없다고 주장했습니다.
생성형 인공지능의 한계를 떠올려 보면 그가 지적하는 문제의 초점을 짐작할 수 있습니다. 그가 만나는 코드에 대한 학습이 생성형 인공지능의 “모델”에는 없기 때문에, 인공지능이 아무리 많은 코드를 생성해 보아야 쓸모없는 엉뚱한 코드밖에 되지 않는다는 것입니다.
흔히 레거시라고 불리우는 시스템이 있는 조직에 가 보면 시스템을 구성하는 코드나 작동 방식이 여러 사람의 머릿속에 흩어져서 존재합니다.
이는 인공지능에서 흔히 쓰는 어휘로 표현하면, 모델이 없는 경우라고 할 수 있습니다.
물론, 인공지능 기술로 구현한 모델과 제가 여기서 언급한 모델의 물리적인 모양은 다릅니다. 하지만, 생성형 인공지능은 모델에 근거해서 무언가를 만들어 낸다는 점에서는 레거시를 모델이 없는 상황에 비유할 수 있다는 생각이 들었습니다.
그리고 그 생각 속에서 “맥락을 반영한 모델”이 있어야 생성형 인공지능이 힘을 갖는다는 점을 떠올렸습니다.
묘하게도 지난주에 만난 개발자는 하루에 10% 정도만 코드를 작성한다고 했습니다. 그리고, 나머지 90%의 시간을 자신의 일에 대한 맥락 그리고 원하는 코드의 형태에 대한 맥락을 학습시키는 일에 쓴다는 이야기를 들었습니다. 그가 쓴 단어가 제가 여기 쓴 단어들과 그대로 일치하지는 않지만, 개발자가 일하는 환경에 대한 맥락을 모델에 충분히 반영하면 코딩의 상당 부분은 인공지능이 생성해 줄 수 있다는 생각은 일치했습니다.
인공지능 도움 없이 코딩하는 일이 드문 일이 될 수 있다
앞에서 인용했던 안드레이 카파시의 글을 다시 보겠습니다.
프로그래밍이 정말 빠르게 변하고 있네요. 저는 깃헙(GitHub) 코파일럿(Copilot) 대신 커서와 Sonnet 3.5를 다시 써보고 있는데, 이제는 확실히 더 낫다는 생각이 들어요. 며칠 동안 경험해 본 바로는, 제 "프로그래밍" 작업의 대부분은 이제 영어를 쓰는 것(프롬프트 작성 후 생성된 변경 사항을 검토하고 편집하는 것)이고, 약간의 "반코딩"로 바뀌었어요. 원하는 코드의 첫 부분을 쓰고, LLM이 계획을 알 수 있도록 주석을 조금 달아준 다음, 탭 키를 눌러 자동 완성을 사용하는 거죠. 가끔은 100줄짜리 코드 변경 사항이 딱 들어맞게 나오는데, 이전에는 10분 넘게 걸렸을 일이에요.
*아직 모든 기능을 충분히 활용하지는 못하는 것 같아요. 마치 코딩을 처음부터 다시 배우는 것 같지만, 이제는 3년 전만 해도 유일한 방법이었던 "도움 없는" 코딩으로 돌아가는 것은 상상할 수 없어요.*
앞선 지인이 일하는 방식과도 크게 괴리감이 없습니다. 그가 코딩은 10%만 한다고 할 때, 함께 자리에 있던 개발자가 자신의 일자리가 사라질 수 있겠다는 두려움을 느낀다고 했습니다. 저는 이러한 변화에 대한 제 느낌을 전하기 위해 비유를 섞어 이렇게 말했습니다.
제가 처음 개발을 할 때는 IDE가 없었습니다. 편집기에서 코드를 작성한 후에 검은색 콘솔 화면에서 컴퓨터에 명령어를 던져서 컴파일을 하고 배포를 했습니다. 하지만, 지금은 거의 대부분의 개발자들이 IDE를 씁니다. 직무와 도구라는 보편적 패턴으로 보면, 사무직이라면 누구나 엑셀이나 워드, 한글을 쓰는 것과 다르지 않습니다.
이러한 변화처럼 조만간 개발자들이 스스로 모든 코드를 짜는 일이 드문 일이 될 수 있다고 생각합니다. 또 다른 예시로 프로그램 배포도 생각해 보세요. 지난 10년 사이에 인프라 가상화는 굉장히 생소한 일에서 꽤나 보편적인 일로 바뀌었습니다. 인공지능을 이용한 코드 생산은 머지않아 보편적인 작업이 될 가능성이 높습니다.
묻고 따지고 풀어내기, 그리고 프롬프트 엔지니어링
조금 서베이를 해 보면 이런 변화의 조짐을 다룬 의견을 찾거나 이러한 변화에 맞춰 완전히 새로운 패러다임을 내놓는 시도들을 어렵지 않게 찾을 수 있습니다. 하지만, 여기서는 남들의 새로운 기술 소개 대신에 독자 여러분들이 어떻게 이 상황을 받아들일 것인가에 대한 화두를 던지는 일로 마무리를 하겠습니다.
먼저 프롬프트 엔지니어링이 이제는 필수적인 기술 스택이 되었다는 점을 말하고 싶습니다. 앞서 90%의 노력을 프롬프트 작성에 시간을 쓴다는 지인이 있었습니다. 그때 필요한 지식과 기술은 무엇일까요? 묻고 따지는 풀어내는 능력이라고 할 수 있습니다. 다른 말로 하면 ‘문제 정의’라고 할 수도 있습니다. 그 일을 개발자 입장에서 자신에게 익숙하게 만들어야 합니다.
앞서 제가 커서를 사용해서 React와 Go 언어를 사용하는 웹 프로그램의 작동 방식을 이해하기 위한 코드를 생성한 경험을 말했습니다. 아래 그림은 그 과정에서 만들어진 간단한 화면과 자동 방식을 UML 형식으로 그린 그림입니다.
이와 같이 어떤 현상을 간단하게 표현하는 일을 모델링이라고 합니다. 제가 다뤄야 할 일을 문제라고 하면, 문제를 추상화하여 표현한 결과를 모델이라 합니다. 모델은 다양한 형식을 띨 수 있습니다. 시연을 위해 쓰는 화면을 흔히 데모라고 하는데, 이 역시 모델의 일종이라 할 수 있습니다. 제가 앞에 그린 UML 순차도 역시 전형적인 모델 표현법의 하나입니다.
프롬프트 엔지니어링에서 추구해야 할 점은 바로 (인공지능의 모델과 다른 프로그래밍의) 그 모델을 인공지능이 이해할 수 있는 형태로 만들어 가는 일이라 할 수 있습니다.
제가 개발을 배우던 시절에는 C++, CGI, ASP, Java, Oracle, Web과 같은 기술 요소들의 문법과 작동 방식을 이해하는 일이 개발자들의 공통 지식이었습니다. 하지만, 커서를 사용한 짧은 경험에서 프로그래밍 언어의 중요성이 전과 확연히 달라졌음을 느꼈습니다. 이제는 각 산업 영역이나 커뮤니티에 따라 언어를 택하는 일이 더 합리적으로 보입니다. 그리고, 그 언어의 문법이나 사용법을 배우는 방법은 책과 매뉴얼이 아니라 인공지능에 질의하며 모델을 만드는 형태가 되어야 한다는 생각이 듭니다.
나는 어떻게 경쟁력을 높일 것인가?
한편, 개발자들과 인공지능에 대한 대화를 할 때, 또 다른 개발자 한 분은 전혀 다른 이야기를 했습니다. 자신이 직장에서 겪는 가장 큰 감정 노동은 너무나 당연하게 보이는 코드 개선 노력조차 하지 않는 개발자들과 함께 일하는 것이라고 했습니다. 그 자리에 있는 모든 개발자가 공감했습니다. 모두 다른 직장에 다니는 사람들이지만 유사한 자기 경험이 있는 것이죠.
제가 특정 기업의 표준 개발 프레임워크를 만들던 때가 있었습니다. 당시 가장 큰 노력이 들어가는 부분은 프레임워크 개발이 아니었습니다. 그 프레임워크를 이용해서 코드를 작성하도록 기존의 개발자들을 교육하고 움직이게 하는 일이었습니다. 당시를 돌아보면 그들 대다수가 스스로 학습을 하지 않는다는 전제가 있었습니다. 그래서 매우 지난한 일이었던 것으로 기억합니다.
커서를 쓸 때 제가 몸으로 느낀 놀라움이 당시를 소환했습니다. 이제 프레임워크를 만들어서 누군가를 교육할 필요가 없겠다는 생각이 들었습니다. 그들에게 교육을 하고, 감시를 하는 노력 대신에 인공지능에 투자할 가능성이 높겠다는 생각이 들었습니다.
마지막으로 최근에 만난 지인의 이야기를 하겠습니다. 그는 코인 거래를 자동으로 하는 프로그램을 만들기 위해 코파일럿을 사용해서 코드를 만들었다고 합니다. 그는 개발자가 아닙니다. 그래서, 처음 프로그램을 만들 당시에는 파이썬 문법을 공부하기 위해 온라인 강의를 결제했다고 합니다.
그러다 너무나 더딘 진도 때문에 인공지능 사용을 시도했는데, 결과적으로 강의를 듣지 않고도 작동하는 프로그램을 만들었습니다. 지금은 거래 중에 자주 멈추는 프로그램의 문제를 해결하고자 저희 회사 개발자에게 도움을 청하는 과정에 있습니다. 이 사건을 일반화하면 이렇게 의미를 해석할 수 있습니다.
이제는 개발자가 아닌 사람도 스스로 묻고 따질 수 있으면 인터넷 공간에 노출된 지식에 기반한 해결책을 얻을 수 있습니다. 문서나 음성 형태로도 얻을 수 있고, 코드 형태로도 얻을 수 있게 되었습니다. 다만, 공개된 정보로 학습한 인공지능이 생성한 결과가 나에게 딱 맞는 해결책은 아닐 수 있죠.
그때는 개발자(전문가)를 찾아 적정한 비용으로 문제를 해결할 수 있습니다. 상상하기에 따라서는 그 여파는 상당한 파장을 일으킬 듯합니다.
이런 변화가 이미 불가역적으로 진행되고 있는 상황에서 지금 할 수 있는 일은 무엇일지 질문하는 행위는 분명 가치가 있을 것입니다.
p.s. 우물 안 개구리, 이러다가 애들 다 지쳐서 나가떨어져🥲
'끄적끄적' 카테고리의 다른 글
| 지능(智能) 혹은 인텔리전스(Intelligence) (3) | 2025.01.30 |
|---|---|
| 실정법과 자연법, 철학(哲學) (18) | 2025.01.16 |
| 시류(時流), Bandwagon Effect (3) | 2025.01.10 |
| 외로움과 돈에 대한 왜곡된 믿음, Materialism Mental Health (17) | 2025.01.05 |
| 자수성가(自手成家), Mata Hari (34) | 2025.01.01 |