LLM, 코드 그리고 블랙 박스

최근에 새로운 라이브러리를 붙이는 일을 하면서, 문득 이런 생각이 들었습니다. “내가 이 라이브러리의 소스 코드를 전부 읽고 이해하지 않아도 괜찮을까?” 문서에 적힌 입력 값을 넘기면 약속한 출력이 그대로 돌아왔고, 에러 상황도 예측 가능했습니다. 그 순간, 제 머릿속에서는 라이브러리가 완전히 ‘블랙 박스’로 바뀌었습니다. 기능이 신뢰할 만하다면, 내부 구현을 뜯어보는 시간은 우선순위에서 뒤로 밀릴 수밖에 없습니다.

입력과 출력이 명확하고 그 약속을 테스트로 검증할 수 있다면, 내부 구현은 블랙 박스로 다뤄도 충분하다. LLM을 쓸 때 관건은 무엇을 맡길지와 언제 상자를 열어볼지를 스스로 결정하는 일이다.

기능이 보장되면 내부는 블랙 박스가 된다

라이브러리를 가져다 쓸 때 우리가 진짜로 원하는 것은 “안정적인 기능"입니다. 내부 코드가 아무리 우아해도 원하는 결과가 나오지 않으면 쓸모가 없고, 반대로 구현이 조금 투박하더라도 명확한 입력과 확실한 출력이 있다면 그것만으로 충분히 가치가 있습니다. 이때 코드는 이미 “블랙 박스"가 되었습니다. 결과의 신뢰도가 높다면, 블랙 박스 내부가 궁금해지는 순간은 점점 줄어듭니다.

LLM이 쓰는 함수, 우리는 어디까지 신뢰할 수 있을까

최근에는 LLM이 함수를 통째로 대신 작성해 주기도 합니다. 그런데 입력과 출력이 명확히 정의되어 있다면, LLM이 만든 내부 구현, 매번 깊게 리뷰해야 할까요? 물론 보안이나 성능 같은 민감한 영역에서는 검증이 필요하지만, 많은 경우 “잘 동작한다"는 사실이 먼저 안심을 줍니다. 결국 우리는 기능을 담보로 LLM이 만든 함수 역시 또 하나의 블랙 박스로 받아들이고 있는 셈입니다.

Spec을 얼마나 정리하느냐가 관건

LLM에 일을 맡기려면 “무엇을 만들어야 하는지"가 선명해야 합니다. 그 과정은 자연스럽게 프로젝트를 정리하는 과정과 겹칩니다.

• 요구사항 정의서: 해결하려는 문제와 사용 시나리오를 글로 정리합니다.
• Scope & Function: 이번 작업에서 반드시 포함할 기능과 제외할 기능을 선 긋습니다.
• Architecture & Design: 구현을 어떤 구조로 풀지 방향을 잡습니다.
• Specification: 입력/출력, 에러 조건, 데이터 포맷까지 상세히 적습니다.
• Issue: 구현 중에 부딪힐 질문과 리스크를 미리 목록화합니다.

프로젝트가 작을수록 이 단계가 단순해지고, 클수록 문서화가 중요해집니다. LLM에게 맡길 수 있는 범위 역시 이 문서들이 얼마나 꼼꼼하게 정리됐는지에 따라 달라집니다. 결국 스펙을 실제로 쪼개고 챙길 줄 아는 사람이 LLM을 가장 잘 활용하는 사람이 아닐까요?

블랙 박스를 열어볼 타이밍을 고르는 사람

결국 중요한 것은 “언제 블랙 박스를 열어볼지"를 스스로 판단하는 능력입니다. 기능 검증에 필요한 맥락을 충분히 확보한 뒤에는, 남은 구현은 과감하게 LLM에게 위임해도 됩니다. 반대로, 아직 이해가 부족하거나 리스크가 높은 부분이라면 직접 손으로 만져봐야 합니다.

코드를 모두 이해해야만 안심이 되던 시대에서, 이제는 블랙 박스를 적재적소에 신뢰하는 시대로 넘어가고 있습니다. LLM을 활용한다는 건 결국 다른 지능에게 일을 맡기는 일입니다. 목표를 분명히 하고 결과에 피드백을 주며 위임을 잘하는 것, 어쩌면 좋은 리더십을 갖는다는 말과 다르지 않겠죠.