GN⁺: 내가 LLM을 스태프 엔지니어처럼 쓰는 방법
(seangoedecke.com)- LLM에 대해 소프트웨어 엔지니어들은 크게 두 입장으로 나뉨
- 일각에서는 산업을 뒤흔드는 혁신적인 기술이라고 믿음
- 다른 한편에서는 그저 과장된 신기루에 불과하다는 시각을 갖고 있음
- 글 작성자는 개인적으로 LLM을 유용하게 사용하고 있다고 느끼며, 이를 효과적으로 활용하는 방식을 소개하고 있음
프로덕션 코드 작성
-
Copilot 자동완성 기능을 코드 작성 시 항상 활용함
- 대부분의 자동완성 제안은 함수 인자나 타입 입력 등 반복적 보일러플레이트에 해당함
- 주 업무 영역(예: Ruby on Rails)에서는 자신이 직접 작성하는 코드가 더 우수하다고 판단함
-
업무 전문성이 낮은 영역에서는 Copilot이 제안하는 로직을 좀 더 많이 수용함
- 예: Golang이나 C 같은 언어에서 작은 전술적 변경을 해야 할 때
- 덜 익숙한 언어의 문법이나 관용적인 코드 스타일을 Copilot 도움으로 빠르게 파악함
- 전문 지식이 부족하므로, 반드시 해당 분야 전문가의 리뷰를 받는 편임
- 이렇게 하면 “똑똑한 인턴” 수준으로 어느 정도 작업 가능하지만, 검증 과정을 거치는 것이 필수적임
일회성 코드 작성
- 프로덕션에 배포하지 않을 일회성 코드를 작성할 때 LLM을 훨씬 적극적으로 활용함
- 연구 용도로 한 번만 실행하고 버릴 코드의 경우, 유지보수 필요성이 적음
- 예: API에서 공개 데이터를 가져와 분류하고, 정규식을 적용해 간단히 검증해 보는 작업
- 이 경우 LLM을 통해 2~4배는 더 빠르게 진행할 수 있었다고 함
- 한 번 쓰고 버릴 코드 작성에는 LLM이 매우 효율적임
새로운 영역 학습
-
가장 효용이 높은 활용 사례로, LLM을 온디맨드 과외 교사처럼 쓰는 방식을 꼽음
- 예: Unity를 처음 배울 때, ChatGPT-4o와 같은 모델에 질문을 계속 던짐
- “X가 어떻게 동작하나요?”뿐 아니라, “X는 Y와 어떤 관련이 있나요?” 같은 후속 질문을 할 수 있음
- “내가 이해한 내용이 맞나요?”처럼 이해한 내용을 점검받는 용도로도 활용함
- 학습 과정에서 작성한 노트를 그대로 복사-붙여넣기 해 검토받는 식으로 사용함
- **환각(hallucination)**에 대한 우려
- GPT-3.5 이후 대체로 환각이 크게 두드러지지 않았다고 느낌
- 일상적으로 배우려는 영역 대부분이 이미 잘 정립된 분야이므로 오답 위험이 낮았음
- 지금까지 LLM을 통해 잘못된 정보를 학습한 적은 없었음
최후의 버그 수정
-
아주 막혔을 때 Copilot이나 Claude 등으로 전체 파일과 에러 메시지를 보여주고 도움을 청함
- 대부분의 경우 LLM이 혼동해 제대로 해결책을 제시하지 못함
- 그래도 간혹 미처 놓친 부분을 LLM이 지적해 시간을 절약한 사례가 몇 번 있었음
- 성능이 기대만큼 뛰어나지 않으므로, 여러 번 시도하지는 않고 한 번 정도만 물어봄
오탈자와 논리 실수 교정
- 글(ADRs, 기술 요약, 내부 문서 등)을 LLM에게 전적으로 대필시키지는 않음
- 스스로가 더 명확하게 작성할 수 있다고 판단하며, LLM 특유의 문체를 선호하지 않음
-
문법 검토나 오탈자 교정을 위해 초안을 LLM에 입력하고 피드백을 받는 경우가 있음
- LLM이 맞춤법 오류를 잘 잡아주고, 가끔 흥미로운 관점을 제안하기도 함
- 반복으로 수정 제안을 받기보다는, 한 번 정도만 “큰 틀”에서의 피드백을 확인함
요약
-
LLM 활용 범위
- Copilot을 이용한 “스마트 자동완성”
- 잘 모르는 영역에서의 짧은 전술적 변경(전문가 리뷰 필수)
- 한 번 쓰고 버릴 연구용 코드 작성
- 새로운 기술이나 도메인을 배울 때 끊임없이 질문하기
- 막힐 때 최후의 수단으로 버그 해결 시도
- 영어 문서 초안의 전체적인 맞춤법/오탈자와 논리 오류 교정
-
LLM을 아직 사용하지 않는 부분
- 자신이 잘 아는 영역에서 전체 Pull Request 작성을 대행하는 일
- ADR과 같은 기술 문서 통째로 작성
- 대규모 코드베이스 내부에서의 복잡한 아키텍처 파악
Hacker News 의견
-
"staff engineer"로서 LLMs는 관용적인 코드를 작성하거나 가르치는 데 매우 부족하며, 오히려 코드 검토에 더 많은 시간을 소모하게 함. LLMs를 사용하여 코드를 작성하는 것은 나쁜 관행을 배우고 코드의 양과 보일러플레이트, 불확정적인 결과에 의존하게 되는 위험이 있음. LLMs는 아이디어 생성이나 신뢰할 수 없는 정보 탐색에는 유용할 수 있지만, 코드 생성에 의존하는 것은 미친 짓임.
-
버그 수정 시 Copilot을 사용하여 파일 전체를 첨부하고 오류 메시지를 붙여넣어 도움을 요청하는 방법이 있음. "reasoning" 모델은 이보다 훨씬 나은 결과를 제공하며, 코드베이스 전체를 붙여넣고 오류 메시지를 설명하면 종종 문제의 근원을 찾아냄.
-
LLMs는 보일러플레이트 코드나 자동 완성에는 유용하지만, 복잡한 작업에서는 한계가 있음. 비즈니스 로직을 이해하지 못하기 때문임. 그러나 기업 문서를 빠르게 작성하는 데는 매우 유용함.
-
GitHub에서 일하며 Copilot에 직접 참여한 경험이 있음.
-
정적 타입 언어와 좋은 IDE를 사용하는 경우, "smart auto complete" 기능이 덜 유용할 수 있음. Intellij의 자동 완성 기능이 대부분의 경우 마음을 읽는 것처럼 느껴짐.
-
소프트웨어 엔지니어들이 LLMs에 대해 부정적인 감정을 가지는 이유에 대한 반성. 많은 사람들이 절대적인 기준으로 판단하는 경향이 있으며, 이는 도구를 효과적으로 활용하는 능력을 제한함.
-
Python 프로젝트 유지보수에 AI를 사용하는 방법. 다른 언어에서의 방법을 Python으로 변환하는 데 도움을 줌.
-
ChatGPT를 사용하여 유틸리티 코드를 작성하는 경험이 좋았음. 코드 리뷰에서는 종종 사소한 문제를 지적하지만, 개선점을 찾는 경우 여전히 가치가 있음.
-
VSCode에서 Cursor로 전환한 후, Sonnet과의 에이전트 모드가 인상적임. 경험 많은 개발자가 이를 안내하면 생산성 향상에 크게 기여할 수 있음.
-
LLMs를 사용하여 문서의 오타와 논리적 실수를 교정하는 데 도움을 받음. Graphite Reviewer를 사용하여 실제 버그와 실수에 집중하도록 조정함. AI는 완벽하지 않지만, 코드 교정 도구로서 유용함.