요즘 작은 생각과 짧은 글을 계속 남기려고 한다. 그러다 내의 일상적인 작은 실험들도 기록해보면 어떨까 하는 생각이 들었다.
종종 작은 실험들을 해보는 편인데, 그것들을 어딘가에 기록하지는 않고 있었다.
뭔가 새로운게 나오면 한번 써보거나 비교해본다. 뭔가 만들면 좋을 것 같다는 생각이 들면, 일단 만들어본다. 뭔가 잘 안 되거나 불편한게 있으면 새로운 방식으로 자동화하거나 개선해본다.
요즘 가장 많이 하는것은 LLM에게 일을 시킬 때마다 조금씩 다른 방식으로 시도해보는 편인데, 그 결과가 괜찮은 것은 자연스럽게 차용하게 되긴 하지만, 구체적으로 시도들에 대해서 기록하지 않는 경우가 많았다.
이런것들을 잘 기록해두면 그 안에서 실험에 대한 성과도 더 구체화 될 것 같고, 나의 사고 과정을 설명할 수 있는 데에 의미가 있을 것 같다.
결과 없는 실험
문제는, 실험 결과를 설명하기 어려운 경우가 많다는 점이다. 한 번 해봤다고 해서 곧바로 의미 있는 결과가 나오지도 않는다. 무엇이 더 좋았는지 분명하게 말하기 어렵고, 수치로 설명하기는 더 어렵다.
프롬프트A와 B가 있다. A처럼 물어보는게 더 결과가 좋다고 하는데, 이걸 어떻게 설명할 수 있나? 대부분 “이게 이런 것 같다” 정도로 말하지만 명쾌하기가 어렵다.
결과를 통해서 가설의 검증이 되지 않는데, 이게 가치가 있을까?
내가 아는 어떤 사람은 측정할 수 없는 행동에 많은 시간을 들이는 것을 경계한다. 꽤 합리적으로 보였다.
무엇인가를 시도하기 전에, 이 결과를 나중에 설명할 수 있는지, 비교할 수 있는지 정도는 생각해보는 태도가 분명 필요해 보인다. 측정하지 못하는 결과는 설득력도 없고, 그것을 증명하기 위해서 불필요한 에너지를 많이 쓰게 되는것은 사실이기 때문이다.
측정할 수 없지만 의미 있는 것
측정하기 어려운 시도가 무의미하다고 생각하지는 않는다. 무엇을 하든, 적어도 나중에 돌아볼 수 있는 흔적을 남겨두는건 가치가 있다.
오히려 두 가지 측면에서 가치를 찾기로 했다.
하나는, 아직 측정하기 어렵다고 해서 그 가치가 없는 것은 아니라는 것이다. 다른 하나는, 그 안에서 측정 가능한 부분을 찾아내는 습관을 기르는 것이다.
그리고 측정 가능성이 부족할 때는 그 것을 명확하게 인지하는 자세도 필요 할 것 같다.
내 작은 실험들
plan 모드나, spec driven dev가 등장하기 전부터 나는 개발의 전체 과정을 미리 설계하고 태스크 리스트로 쪼개서 실행하는 체계를 만들어서 쓰고있었었는데 어느 순간부터 용어가 퍼지기 시작했고 지금은 누구나 그 방식이 더 좋다는 것을 인정하고 있다.
그 밖에 요즘 LLM에게 일을 시킬 때 독자적인 markdown 파일 형식을 지정하고 있는데
예를 들면 task list 는 \*.task.md 로 저장한다.
이렇게 저장하면, “.task.md로 끝나는 파일은 체크리스트를 하나씩 수행하고 다음 작업을 선정해서 진행한다. 완료되면 완료 여부를 기록한다.” 는 규칙과 함께 연동된다.
비슷하게 사람이 작성한 글은 .human.md로 저장한다.
이것은 형식이 조금 러프할지라도 사람이 쓴 것이니 훨씬더 중요한 가치가 있다는 뜻이다.
이런 것도 측정은 쉽지 않지만 나름의 실험이다.
최근에 본 openAI 블로그 글에서는 LLM이 일하는 과정을 모두 로그로 남기고 같은 일을 시킨뒤 그 결과를 평가한다. 이런 방식으로 하고싶은데 너무 스케일이 커서 쉽게 시도하지 못하고 있다.
결론
지금의 나는 이렇게 생각해보기로 했다.
실험이 될 만한 조건들이다. 어떤 목적과 기대를 가지고 시도하는가.(가설) 구체적인 방법이 있는가. 그리고 그 결과가 기대에 부합하는지, 완벽하지 않더라도 돌아볼 수 있는가.
단, 결과를 이야기하기 쉽지 않은 경우도 있는데
그렇더라도 괜찮다.
결과의 평가가 어렵더라도, 최소한 어떤 목적과 기대를 가지고 무엇을 시도했는지, 그리고 어떤 방식으로 해봤는지를 기록하는 것만으로도 충분히 가치가 있다. 아무것도 남기지 않는 것보다는 훨씬 낫다.
그래서 일단은 그렇게 한번 해보자.