2주에 세 줄의 코드 — 항상 게으름만은 아니다 (또는 개발자 생산성 측정 재고)
I’m happy to translate the article for you, but I’ll need the actual text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and technical terms.
개발자의 보이지 않는 작업
오랫동안 이 주제에 대해 생각해 왔고, 마침내 글로 적기로 했습니다.
작성한 코드 라인 수로 코드를 평가하거나, 작업량을 추정하려는 다른 시도들은 언제나 저를 불편하게 만들었습니다.
저는 현재 산업 규모로 코드를 작성하지는 않지만—아마도 저만을 위한 작은 도구 정도만 만들고 있습니다—예전에는 많은 코드를 작성했으며 15년 넘게 그 일을 해왔습니다.
일상의 춤
아침에 사무실에 와서 무언가를 작성하기 시작하고, 당연히 중간중간 저장합니다.
저녁이 되면 가끔 Ctrl + Z 를 눌러서, 빠른 재생(역방향이라 할지라도)으로 커서가 어떻게 움직이고, 코드 블록이 어떻게 강조되고, 나타났다가 사라지는지를 지켜보는 것을 즐겼습니다.
- 먼저, 한 곳에 조건문과 반복문이 나타납니다.
- 그 다음, 반복문 안의 일부 코드가 절차로 이동하고, 반복문 자체는 완전히 사라지는 식입니다.
커서와 그 아래 텍스트가 이루는 매혹적인 춤입니다.
하루가 끝날 무렵 저는 새로운 간결한 절차와 기존 블록에 몇 차례 삽입을 만든 상태가 되며, 50–80 라인의 코드 정도가 추가됩니다.
종종 레거시 코드를 정제해야 했고, 추가한 부분을 여러 위치에 조심스럽게 통합하면서 아무것도 깨지지 않도록 해야 했습니다.
“누가 내 모든 탐색과 방황을 보았는가?”
외부 관찰자에게는 아침에 작성한 라인 수와 저녁에 남은 라인 수만 보일 뿐입니다. 그 80 라인만으로는 제가 하루 종일 무엇을 했는지 전혀 짐작할 수 없습니다. 제가 무슨 말을 하는지 이해하실 거라 믿습니다.
Source: …
누락된 텔레메트리
AI에 대한 전면적인 매혹의 시대에, 이 전체 인지 과정을 정당화하는 것이 좋겠다는 생각을 떨칠 수 없습니다.
웹사이트에서는 사용자의 행동을 추적하는 메커니즘이 오래전부터 사용되어 왔습니다: 어디를 클릭했는지, 페이지에 머문 시간, 스크롤한 거리 등.
왜 개발에서는 이런 것이 없을까요?
- 모듈 간 전환
- 메서드에 마우스를 올려 툴팁 보기
- 의존성 탐색, 검색, 텍스트 입력, 선택, 삭제, 이동
- 라이브러리 추가, 설정 수정, 실행, 컴파일, 테스트 실행, 재컴파일
- 단계별 디버깅(스텝 인/아웃)
이 모든 것은 엄청난 시간과 인지적 작업을 요구합니다.
SQL 디버깅 예시
무거운 SQL 쿼리를 디버깅하는 데 일주일이 걸릴 수 있습니다:
- 실행 계획을 살펴보고 I/O 통계를 측정하며 인덱스를 추가한다.
- 서브쿼리 조각을 꺼내어 별도로 디버깅한 뒤 다시 삽입한다.
이 과정을 보는 사람은 누구일까요? 아무도 없습니다. 오직 당신만이죠.
일주일이 끝났을 때 커밋은 세 줄의 짧지만 완벽한 수정만을 포함하고 있습니다. 일주일 내내 무엇을 했나요? 그 세 줄을 추가했나요? 때때로 외부 관찰자에게 당신의 작업 결과가 어떻게 보이는지 생각하면 불편함을 느끼게 됩니다.
개발 작업의 현실
모두는 결과를 평가하는 데 익숙하지만, 개발에서는—과학과 마찬가지로—시간의 90 %가 실험과 오류 탐색에 쓰입니다. 평가 도구는 마치 점심시간까지 여기서부터 도랑을 파는 것처럼 결과에만 초점을 맞추어 설계됩니다.
아무도 당신의 모든 고군분투, 시도, 오류를 인정해 주지는 않지만, 바로 그곳에서 결과가 탄생합니다.
텔레메트리가 당신의 모든 행동을 로그로 수집하고, 그 로그로 그래프를 만들거나 AI가 난이도를 평가한다면, 비즈니스는 당신의 작업을 투명하고 입증 가능한 모습으로 볼 수 있게 될 것입니다.
피카소 비유
피카소에 관한 이야기가 있습니다. 누군가 그에게 냅킨에 스케치를 그려 달라고 요청했습니다. 그는 몇 분 안에 그렸습니다. 얼마를 받아야 하는지 물었을 때, 그는 거대한 금액을 제시했습니다. 고객은 격분했습니다 – “단 2분짜리 작업에 이렇게 많은 돈을 요구하다니?”
피카소는 그것이 2분이 아니라 그의 평생이 걸렸다고 답했습니다.
보이지 않는 작업에 막대한 시간을 투자하고, 그것이 단지 2줄의 코드가 아니었다는 것을 고객에게 증명하려는 개발자들과 공감되지 않나요?
A Proposed Solution: Development Telemetry
우리는 개발 과정(및 모방 과정)의 수천 개의 정직한 로그를 수집하고, 이를 기반으로 모델을 학습시켜 패턴을 식별할 수 있습니다.
- 원시 로그는 직접 학습에 적합하지 않지만, 이를 통해 heat maps 혹은 activity graphs를 만들 수 있습니다.
- 이 그래프는 프로세스의 “맥박”을 보여줍니다. 누군가는 빠르게, 누군가는 느리게 작업하지만, 전체적인 흐름은 대체로 비슷합니다.
Implementation Ideas
- 작업을 단순히 기록하는 외부 유틸리티.
- 설정에서 사용자가 정확히 어떤 데이터를 수집할지와 어떤 애플리케이션(IDE, 디버거, SQL 에디터, Postman, 브라우저 등)에서 수집할지를 정의합니다.
- 정규식(regex) 기반의 제목 필터, 객체‑유형 필터 등.
- 예를 들어, 디버거에서 SSMS/PL/SQL로 전환하고 오랜 시간 동안 씨름한 뒤, Stack Overflow로 이동해 수십 페이지를 스크롤하는 로그가 표시됩니다.
그 결과는 맥락이 포함된 행동의 점진적 기록이 되며, 결과의 차이만을 보여주는 것이 아닙니다. 감시를 위한 것이 아니라 인간이 정확히 어떻게 수행하는지를 분석하기 위한 것이며, 이것이 가장 흥미로운 부분입니다.
인간 프로세스: 인큐베이션과 통찰
사람이 9 시부터 6 시까지 코드를 쓸 수 없다는 것은 잘 알려진 사실이며, 특히 해결책을 찾는 것이 필요하고 단순히 표준 알고리즘을 타이핑하는 것이 아닐 때 더욱 그렇습니다.
- 가끔은 머리가 전혀 돌아가지 않을 때가 있습니다.
- 원하는 만큼 강제로 코드를 작성하려 해도 도움이 되지 않습니다; 나중에 이해할 수 없는 엉망진창 코드를 만들게 됩니다.
해결책은 입술 끝에 맴돌고 있습니다. 존재하고 간단하다는 느낌은 들지만, 명확한 그림이 떠오르지 않습니다. 이미 수십 가지 옵션을 시도했지만 완벽한 결과가 나오지 않습니다.
산만함이 필요합니다 – 농담을 읽고, 뉴스를 보고, 고양이 영상을 보면서 생각을 조각 모음하게 하세요. 이것이 인큐베이션이며, 몇 시간에서 며칠까지 지속될 수 있습니다.
어느 순간 번쩍 떠오릅니다 – 해결책이 클릭됩니다. 코드를 열어 자신이 작성한 것을 보고 “세상에, 이게 뭐야?!” 라고 생각합니다. 바로 삭제하고, 5분 안에 즉시 작동하는 블록을 작성합니다. 이는 며칠 동안 작동하지 않던 것이었습니다.
마무리 생각
만약 개발자의 작업 전체적이고 미묘한 여정을—단순히 최종 라인 수만이 아니라—포착할 수 있다면, 우리는 노력 평가를 더 풍부하고 공정하게 할 수 있고, 도구를 개선하며, 어쩌면 AI에게 소프트웨어 뒤에 숨은 창의적 과정을 더 잘 이해하도록 가르칠 수도 있을 것입니다. 보이지 않는 작업은 보여져야 합니다.
Heat‑Map Insight into Cognitive Workflows
원래 러시아어로 Habr에 게시되었습니다.
자신에게 어색함을 느낄 때: “시간을 많이 썼는데, 누가 물어보면 보여줄 게 없어요.” 이것이 인지 부조화입니다. 우리는 양으로 측정하는 데 익숙합니다. 뭔가 가치가 있다면 양이 많아야 하지 않을까요?
두 주 중 일주일을 영상 시청에 보냈다고 비즈니스에 어떻게 설명하나요?
그런 기간—인큐베이션‑인사이트—는 히트맵에 나타날 수 있습니다. 왜냐하면 그 전에는 같은 코드를 반복해서 고쳐 쓰는 강도 높은 시행착오 과정이 있고, 그 뒤에는 IDE에서의 잠깐의 정지, 브라우저에서 고양이 구경, 그리고 짧은 최종 해결책이 있기 때문입니다.
프라이버시 문제가 제기될 수 있습니다. 하지만 사람은 무엇을 기록하고 무엇을 기록하지 않을지 스스로 선택할 수 있으며, 이는 그들의 이익에 부합합니다. 중요한 점은 로그에 반드시 텍스트가 포함될 필요는 없다는 것입니다; 마커만 포함해도 히트맵을 만들 수 있습니다. 탐색 단계에서 정확히 무엇을 적었는지, 그 품질이 어땠는지는 중요하지 않습니다; 시도 횟수와 옵션 수가 훨씬 더 중요합니다. 왜냐하면 그곳에 모든 시간이 소비되었기 때문이죠.
효율적인 관리자들은 이를 당신에게 불리하게 이용하려 할 수도 있습니다. 결국 페티아는 계속 고생하다가 괴물을 만들어냈고, 바샤는 고양이를 보러 갔다가 완벽한 코드 세 줄을 가져왔으니까요. 하지만 바로 여기서 이런 지도에 대한 통계와 AI의 공정성이 필요합니다. 경험 많은 전문가가 특별한 것을 보지 못하더라도, 신경망이 마커를 포착하는 것과 같은 원리입니다.
왜 아직 사용되지 않을까요?
예를 들어 학교 수학 문제, 들판의 면적을 구하는 문제.
학교에서는 피타고라스 정리를 적용하는 방법을 가르칩니다. 다양한 문제를 수십 개 풀면서 같은 정리를 여러 각도에서 접근하도록 훈련합니다. 내용이 흡수되면 새로운 주제로 넘어갑니다. 하지만 학교에서는 수백 년에 걸쳐 매뉴얼화된, 이미 완성된 프로세스를 가르칩니다.
반면 직장에서는 사람에게 스스로 프로세스를 구축하도록 강요하는 경우가 많습니다. 물론 학교에서 배운 것을 토대로 하지만, 독립적으로 말이죠.
아마도 이런 히트맵은 과학 분야에 적용될 수도 있고, 면접에서의 테스트를 대체할 수도 있습니다(문제 풀이와 IQ 테스트 대신, “여권” 같은 사고 스타일을 보여줄 수 있다면—채용에서 모두가 찾는 것이 바로 지식이 아니라 사고 방식이기 때문입니다).
여러분은 어떻게 생각하시나요?