woonmayer

GeekNews Weekly #377 잘하고 싶을수록 혼자 일하게 되는 이유 새 직장에 들어가거나 더 큰 역할을 맡으면, 기대에 맞는 결과를 보여주고 싶어집니다. 아직 정리되지 않은 생각을 꺼내기보다 조금 더 완성한 뒤 보여주려 하고, 막힌 부분도 일단 혼자 풀어보게 되는데요. 그런데 그 시간이 길어지면 도움을 구하는 일도 점점 어려워집니다. 이번 주에는 잘하고 싶은 마음이 오히려 일을 어렵게 만드는 과정을 다룬 글들이 눈에 들어왔습니다. 「시니어 엔지니어의 파멸적 악순환」에서 Sunil Pai는 큰 프로젝트를 맡은 개발자가 2~3주씩 결과를 보여주지 못하면서도 "잘 진행되고 있다"고 보고하는 모습을 이야기합니다. 다음 주에 한 달 치 일을 해내면 아무도 모를 것이라 생각하지만, 불안할수록 더 오래 혼자 일하고 동료들은 상황을 더 모르게 됩니다. 저자는 이 악순환이 최근 더 심해진 이유로 원격근무와 코딩 에이전트를 꼽는데요. 옆자리 동료와 일하며 작업을 배정받던 구조가 약해지면서 개인의 업무 소유권과 고립이 함께 커졌다는 것입니다. 회사는 스스로 상상하는 6개월 뒤의 모습이 아니라, 지금의 역량을 보고 채용했다는 말도 기억에 남습니다. 「Claude Code 개발자 보리스 처니: "나는 자주 틀린다"」는 다른 일하는 방식을 보여줍니다. 그는 문제를 정의하고 단순한 접근법과 목표를 정해 실행하되, 새로운 정보를 얻으면 앞의 판단으로 돌아가 다시 고칩니다. 밖에서 보면 방향이 자꾸 바뀌는 것처럼 보이지만 그런 흔들림을 건강한 것이라고 부르며, 자신이 쓰는 문제 해결 절차조차 예외 없이 수정할 수 있어야 한다고 말합니다. 무엇을 풀려는지 불명확해진 상태는 계획을 세운 당사자가 알아차리기 어렵다며, 피드백을 가능한 한 실시간으로 주고받는다고 하네요. 동료가 참여할 시점을 놓치는 일은 AI로 작업을 빠르게 끝낼 때도 생깁니다. 「당신이 직접 쓰지 않은 글은 읽고 싶지 않다」에서 Colin Breck은 AI로 구현을 먼저 끝낸 뒤 그 결과를 다시 AI로 요약해 설계 문서를 만드는 방식을 지적합니다. 원래 설계 문서는 합의를 만들고 동료를 참여시키며 아이디어를 다듬는 도구였는데, 이렇게 만들면 이미 끝낸 구현을 설명하는 문서에 머물기 쉽다는 것이죠. 눈에 띄는 건 그다음인데, 이미 작동하는 결과물이 있다는 이유로 문서를 만든 사람이 오히려 다른 사람들의 저조한 참여를 답답해한다고 합니다. 세 글을 함께 읽으면 동료에게 일을 보여주는 시점을 생각하게 됩니다. 혼자 오래 고민하든 AI로 빠르게 구현하든, 완성한 뒤에야 공유하면 무엇을 왜 만들었는지부터 함께 논의하기는 어려워집니다. 어떤 시도를 했고 어디서 막혔는지, 어떤 판단에 확신이 없는지를 일찍 나눠야 동료도 방향을 함께 잡을 수 있습니다. 보리스 처니가 강조한 실시간 피드백도, 아직 판단을 바꿀 수 있을 때 동료의 의견을 듣는 방식으로 볼 수 있습니다. 리더 역시 결과를 언제 볼 수 있는지만 묻기보다, 지금 무엇을 가장 어려워하는지 물어볼 필요가 있겠습니다. 경험이 쌓이면 혼자 해결할 수 있는 일도 많아지지만, 맡는 문제 역시 더 크고 낯설어집니다. 책임감이 강할수록 도움을 구하는 일을 미루기 쉽지만, 그 책임을 끝까지 혼자 져야 하는 것은 아닙니다. 조금 더 완성한 뒤 보여주려고 미뤄둔 일이 있다면, 지금 막힌 부분부터 동료에게 꺼내보는 건 어떨까요? news.hada.io/weekly/202639