"소프트웨어 개발에서 'AI'가 살을 덧붙이고 있는 가운데, 정말로 불필요한 사람은 누구일까요?
우리는 대게임에서 우리만의 전략을 추구하는 소프트웨어 엔지니어로서, 새로운 기술, 방법론, 플랫폼, 도구 등이 언제든지 다가옵니다. 어떤 것은 상쾌한 바람이 스치는 듯한 느낌을 주고, 어떤 것은 파괴적인 5급 허리케인의 강력함을 지니고 있습니다.
예를 들어, 나는 ed¹에서 vi로 넘어가는 것을 정말 좋아했습니다. 터미널에서 전체 화면 모드로 편집할 수 있는 기능은 매우 편리합니다. 단, 필요한 대역폭²이 있어야 합니다."
만약 당신이 그린 또는 황색 화면의 단색 모니터나 사무실이 모든 네트워크 및 전원 케이블을 숨기기 위해 대전바닥과 대전바닥 카펫이 있는 시절을 기억한다면 아마 미소 짓고 고개를 끄덕일 것입니다.
원본 제어는 항상 존재해 왔으며, 그것은 정말 필요하고 그 기본적이고 간결한 실행에서는 정말 멋진 것입니다. 그러나 나는 우리가 git을 SCCS의 발전으로써 도달했을 때 진화가 그냥 멈춰야 했다고 생각합니다. 우리는 절대로 ClearCase나, 다소 그것보다는 작지만 Subversion의 심연한 공포가 필요하지 않았습니다.
그것들을 부드럽고 진정한 바람으로 분류할 수 있을 것입니다. 경험해볼 만하고 삶을 더 풍요롭게 만드는 것으로, 일을 견딜 수 있는 것뿐만 아니라 즐거운 일로 만드는 것입니다.
다음에는 운영 체제와 같이 약간 강한 변화의 바람이 다가올 것입니다.
OS 9에서 OS X로 이동하여 macOS로 이어지는 과정은 불안했지만 매우 흥미롭고 기본적으로 기쁜 일이었습니다. 속도, 안정성 및 사용 편의성의 점진적인 개선에서 비롯된 것이기 때문입니다.
또한 Windows 3에서 3.11, 98, 98ES, 2000까지 이어지는 가마속에서 마른 가마중풍이 나는 것이었습니다. 그리고 말하지 말아야 할 "Me"로 이어지는 단조롭고 매혹적인 지옥 같은 훈화로 이어지는 것이었습니다.
비행기 크기만한 스타트 메뉴가 필요하신가요? 당신을 지원할게요!
그래도, 적어도 위에서 설명한 대부분의 방식으로의 변화는 좋은 일이었습니다. 특히 Windows의 경우 불편함이 약간 있었지만 궁극적으로는 더 좋은 방향으로 나아가고 모든 것이 잘 해결되었습니다.
불행히도, 때로는 변화의 태풍에 휩쓸리기 일쑤합니다. 때로는 바람직한 변화가 있죠(예컨대 인텔에서 애플 실리콘으로의 전환), 때로는 나쁜 변화도 있습니다(LLM의 갑작스러운 등장 및 코드 생성 능력). 창문이 깨지고 낙엽이 흩날리며 프로젝트 매니저들이 보통보다 더 닭 머리처럼 뛰놀 때 우린 어찌해야 할지 몰라서 불안해합니다.
나는 코드 생성 LLM에 반대하지 않아요. 나는 확실히 루디트주의자가 아니기 때문에요. 다만 이해하지 못하는 것은 중요한 곳에 복사하여 붙여넣지 않아요. 어떤 합리적인 소프트웨어 엔지니어도 나와 동의할 것입니다. 다만 관리자들은 대개 그렇지 않다는 점이 흥미롭죠. 곧 분석하게 될 거예요.
나 자신은 LLM과의 상호작용을 소크라티스식 대화로 보는 편입니다. 종종 길고 끊임없는 질문과 답변 세션을 거쳐 인터넷 어딘가에 있는 수억 개의, 비록 양자화된 작은 실수들과 어떤 협의점에 도달하기 위해 노력해요.
그러나 그럼에도 불구하고, 나는 의심 속에서 토론을 바라보며 "내가 직접 조사"를 하여 확신할 수 없는 것은 검증하고, LLM이 올바르다고 여기는 의심스러운 코딩 관습들을 추적합니다.
오류를 발견하고 지적하면 "맞아요, 다시 해봐요!"라고 받아들이는 게 여전히 재미있네요. 그 확신에 감탄을 금하지 못합니다. 그런데 이 조직에서 더 적합한 위치가 있다면 참 좋겠습니다...
LLMs를 도구로 사용하는 것은 괜찮지만, Stack Overflow를 찾아보는 것이나 문서를 찾아보는 것과 마찬가지로 단지 도구로만 사용하겠습니다.
어찌되었든, 도구를 제대로 사용하는 방법을 알지 못하면 무기가 되어 엄청난 상처를 입을 수도 있습니다. 암전이라도 여전히 두려워하고 원칙적으로 전기 톱은 사용하지 않겠습니다.
현재 최소한 소프트웨어 엔지니어들이 모두 수첩을 위한 확률 가중치 모음에 의해 월 20달러에 대체될 수 있다는 제안에 관해서는 전혀 찬성하지 않습니다. "노 코드" 관리진이 이것이 현실적인 비용 절감이 되어 큰 경비 계정과 "올 핸즈"에서 제시하는 기업 월간 파워포인트에서 언급되는 것으로 생각하더라도요.
나는 내 직업을 사랑해서 하는 게 아니라, 오히려 요즘 대부분은 똑같은 것을 100가지 다른 방법으로 구현하는 지루한 작업에 지치기 일쑤야. 혁신과 문제 해결이 일부분이지만 정말 사랑하고 정신적 안정을 유지하게 해주는 부분이야. 결국 내가 크립토 월드에 첫 발을 내딛은 이유거든.
LLMs에 의해 바퀴를 다시 발명하는 과정이 줄어들면서 내가 중요한 일을 연구하고 실제 창의적인 작업을 하는 시간이 훨씬 더 많아졌음에 환영할 만해. 모든 이러한 일들이 나에게 있어서 같은 큐를 똑같은 IoT 기기와 똑같은 클라우드 기반 데이터베이스에 연결하는 것보다 훨씬 즐겁기 때문이지.
이 모든 건 결국 배관일 뿐, 우리가 잘 알듯이 파이프를 통해 흐르는 것에 흥분이 있는 거야.
그건, 소프트웨어 엔지니어링의 한 분야가 있는데, 거기서 LLM을 효과적으로 활용하면 비용 절감, 효율성, 그리고 개발자를 너무 괴롭히지 않으면서도 크게 성과를 거둘 수 있을 거라는 것이 분명해.
당신은 이미 추측했을지도 모릅니다. 특히 먼저 제가 소프트웨어 엔지니어링의 위대한 게임에 대해 쓴 이전 기사 중 하나라도 읽었다면요.
스크럼 마스터 / 프로젝트 매니저(그들은 같은 것이에요)는 매우 우수한 후보입니다. 왜냐하면 LLM이 Jira 작업을 만들고 편집하며 정리하는 것이 매우 쉬울 수 있기 때문입니다. 게다가 실제로 그들이 댓글을 달면서 제목이 실제로 무엇을 의미하는지 설명할 수도 있어요.
LLM은 회사 캘린더에 접근해서 실제로 읽기 때문에 적절한 시간에 회의를 예약할 것이고, 회의를 일정한 이유로 설정했을 때 참석자에 대해 회의 안건(그 기록은요) 및 이유를 제공할 것입니다.
PM 스타일 자세로 회의를 진행하는 것은 빠르고 쉬울 것이고, 기술 용어를 알 수 없다며 수동적으로 비난할 필요 없으며, '성과 평가에 대한 반성'에 대한 힌트도 더 이상 둘 필요가 없을 것입니다. 관련 질문으로 참여하려고 하면 그들이 뭘 하는지 정말 이해하려고 하거나 회의록을 복사하여 자신의 매니저를 위한 파워포인트로 표절하려는 일도 더 이상 없을 것이에요.
약점을 찾기가 정말 힘들어요. 점심 때 LLM 옆에 앉아 주변적인 얘기를 나눌 필요가 없고, 강제로 참석해야 하는 재미난 행사에 참석하거나 예의 바르게 행동할 필요가 없어요. 사무실에서 5분마다 등을 돌리거나 팀에서 온라인 및 깨어있음을 알릴 목적으로 초록불이 켜졌는지 확인할 필요도 없죠.
삐걱대는 샌들 소리를 내는 프로젝트 매니저가 당신에게 업무 완료율을 물어보거나 매일 색종이를 흔들어 만지라는 것은 그 자체로 금값만한 가치가 있을 거예요. 더 낮은 비용으로 유지할 수 있는 방법은 우리, 실제 개발자들이 프로젝트 관리자/스크럼 마스터(LLM가 동일한 것)와 함께 교육, 설치 및 상호 작용할 것을 즐겁게 할 것이라는 것이죠. 특히 우리가 필요할 때만 켜놓고 필요 없을 때는 안전하게 종료할 수 있다면 더더욱 좋아요.
이것은 '양쪽 다 이득'인 상황이죠, 맞나요? 그래, 그건 잘 맞는 말일 거에요. 그것도 말 안 하게 가르쳐주면 좋을 텐데요.
[1]: "만들어진 가장 사용자 적대적인 편집기" [2]: vi로 파일을 페이지 업하면서 화면이 한 줄씩 새로 고칠 때까지 기다리던 첫 경험을 기억합니다. 즐거운 시간이었어요. [3]: 맥 사용자입니다. 맥 우선, 리눅스 두 번째, 윈도우는 더 이상 없어요. [4]: 꼭 막연한 무작위성이 입력되어 있어도 확률적 단어 생성기를 ‘AI’라고 부르는 건 정말 싫어요. [5]: 기술 직군을 위한 슬라이드 프레젠테이션입니다. [6]: 그래, LLM이 사실상 아무것도 무게를 나타내지 않을 테니(혹은 매우 미미한 정도여야 하죠) 말 그대로 받아들이지는 말아요. 칼같이 꼼꼼하지 않게요.