요즘 Gooo라는 언어를 만들고 있습니다. 작은 모델로 코드를 조립해 보고, 그걸 쓰다가 불편한 부분이 나오면 언어도 고쳐 가는 식으로 작업하고 있어요.
제가 해보고 싶은 건 코드가 덜 만들어진 상태에서도 어디까지 됐는지 알고 이어가는 겁니다. 열 개 중 여섯 개가 맞았다면, 나머지 네 개가 뭔지 남아 있으면 좋겠어요. 다음에 모델을 바꾸거나 다시 실행해도 그때까지 한 일을 가져갈 수 있고요.
지금은 Gooo 소스에 바꿔볼 부분과 선택지를 적어두고, 모델이 먼저 볼 순서를 정하게 했습니다. 조건문 안에서 돌려줄 값이나 문장 같은 작은 부분부터요. 실제로 맞는지는 만들어진 코드를 실행해서 확인합니다. 모델을 빼면 정해진 순서로 돌아갑니다.
흐름으로 그리면 이렇습니다.
보통의 개발 코드 작성 → 컴파일 → 실행·테스트 결과가 다르면 → 코드 수정 → 다시 컴파일 Gooo에서 실험 중인 조립 코드의 뼈대 + 선택지 + 확인할 사례 ↓ 시도 순서 정하기 (작은 모델 / 고정 순서) ↓ 후보 조립·사례 검사 ↓ Gooo 규칙으로 다음 단계 결정 ├ 계속 → 다음 후보 조립·검사 └ 멈춤 → 코드·결과·남은 후보 저장 ↓ 컴파일 → 실행·테스트 저장한 조립은 이어가기 명령으로 다시 진행컴파일하고 실행하는 과정은 Gooo에도 있습니다. 그 앞에 부품을 바꿔 끼워보는 과정을 넣은 셈이에요. 중간에 멈추면 어디까지 해봤는지 남기고, 이어갈 때 그 기록을 가져옵니다. 조금 더 자세한 흐름도도 적어두었습니다.
모델이 바뀌어도 “뭘 만들려고 했는지”는 소스에 남았으면 합니다. 한동안 쌓은 규칙이나 지식이 모델 파일 하나에만 들어가 있으면 나중에 바꾸기 어려울 것 같아서요. 조립을 계속할지 멈출지 정하는 규칙도 Gooo로 써보고 있습니다.
최근에는 검사 결과를 읽어서 상태와 다음 할 일을 알려주는 작은 진단 도구를 만들었습니다. 모델이 먼저 고른 후보는 일부가 안 맞았는데도 다음 할 일을 accept로 내보냈어요. 그대로 저장했다가 남은 후보를 이어서 확인하니 준비한 실행 사례가 2/4에서 4/4로 바뀌었습니다. 이어갈 때 모델을 다시 부르지는 않았고요. 이 예제에서는 모델 순서로 두 후보, 고정 순서로 네 후보를 확인해서 같은 코드가 나왔습니다.
아직은 이런 작은 예제를 만지는 단계입니다. 네 사례가 맞았다고 도구가 완성됐다고 보기는 어렵고, 애초에 검사할 항목을 잘못 정했을 수도 있죠. 그래서 맞은 개수와 함께 뭘 검사했는지, 어디는 아직 모르는지도 남기고 있습니다.
만들면서 가장 걸리는 건 선택지를 적는 수고입니다. 여기까지 사람이 다 적어야 하면 그냥 구현하는 게 빠를 때도 있을 테니까요. 자주 쓰는 부품을 Gooo로 만들어 두고 다음 프로그램에서 다시 조립해 쓰면 그 부담이 줄어들지 보고 싶습니다. 이 과정에서 생기는 실패 기록은 작은 모델을 더 가르치는 데도 써보려고 합니다.
소스와 실행 예제, 위 실험의 기록을 올려두었습니다. Go 1.27.1로 빌드해서 실행할 수 있고 모델은 선택 사항입니다. 개발에는 AI 코딩 도구도 쓰고 있어요. 관련해서는 Rosette와 DreamCoder 같은 작업을 참고하고 있습니다.
설정 변환이나 반복되는 업무 규칙처럼 범위가 작은 일부터 써볼 생각인데, 이런 방식이 쓸 만한 곳이 있을까요? 비슷한 시도를 해보셨거나, 선택지를 준비하다 배보다 배꼽이 커졌던 경험이 있으면 궁금합니다.