-
공부 부족과 지식 부족 때문에 자동화까지 가는 과정이 길었다.
-
task를 사용했기 때문에 빌드나 테스트는 바로 처리했다 (여러 번 수정하거나 곁길로 새기도 했지만).
-
brew에 출시하는 것과 prek에 docker를 올리는 것 사이의 간격이 길었다.
-
brew가 어떻게 되어야 하는지(goreleaser의 cask 부분 등)를 몰랐기 때문이다.
-
prek은 system과 go build는 문제가 없었지만, docker(build) 제공 시 GitHub Actions Runner의 Ubuntu가 24.04에서 26.04로 업데이트되면서 golangci-lint가 통과되지 않는 불운을 겪어 3일이나 걸렸다.
-
타이밍이라고 할 수 있지만, 항상 최신 상태를 유지하고 싶은 편에 속하기 때문에 버전 다운그레이드를 허용할 수 없었고, 유연성이 부족했던 것은 큰 반성거리이다.
-
안정적으로 기존의 성과를 재활용하려면, 최신보다 약간 버전을 낮추는 것이 전략적으로 가능할지도 모른다.
-
애초에 길었다고 쓰면서도 혼자 작업해서 총 2주 정도의 이야기이므로, 업무로 생각하면 그리 짧은 이야기는 아닌가 싶기도 하다.
-
이전에 쓴 내용까지 포함하여, AI 시대의 개발은 인간 측의 시간 관념을 의도적으로 인간 쪽으로 되돌리지 않으면, 점점 AI 시간대로 진행되어 빨라지고 빠르다는 느낌에 사로잡히기 쉽다. 가장 힘들었던 점이 이것이었을지도 모른다.
-
가격이 싸다고 해서 자동화(auto)가 항상 좋은 것은 아닐지도 모른다. 무료 사용 범위 내에서 사용할 수 있는 모델들은 종류에 따라 완전히 쓸모없는 경우가 여러 번 있었다.
-
애초에 설계 아이디어를 벽에 대고 부딪히거나(벽치기), 구현을 계획하거나, 실제로 구현할 때까지 사람이 직접 모델을 선택해 줘야 하는 시점 자체가 'AI'와는 거리가 멀다고 느꼈다.
-
차라리 엔터키를 누르는 것만으로 최적의 모델 선택을 먼저 해주고, '이 모델로는 어느 정도까지 구현할 수 있나요?'라고 물어봐 주는 정도의 배려심이 있으면 좋겠다 (사실은 필요 없다).
-
완전히 이해하지 못한 부분에 대해서는 AI의 의견을 받아들이기 쉬운데, 어느 정도 경험하고 이해하게 되면 '원래 이게 맞는 건 아닐까?'라는 생각이 드는 경우가 자주 있었다.
-
이 부분에 대해서는 나중에 깨달았는데, 테스트 작성이 완료된 경우라면 그것을 건드려서 망가뜨리지 않도록, 내용만 AI 스스로 검토하고 변경하게 하는 것이 효과적이었다. 동료나 부하 직원, 후배와 달리 몇 번 리테이크(re-take)를 시켜도 마음이 상하지 않는다ㅋㅋㅋ
-
반대로, 어느 정도 이해하고 있는 부분은 오히려 의심하기 쉬워서, 궁금증에 사로잡혀 제가 직접 움직이게 되면서 시간을 낭비하는 경우도 있었다.
-
게다가, 이미 이해하고 있는 부분에 대해서는 개선을 요구하기 쉬워서, 만족스러울 때까지 AI를 반복적으로 실행시키며 시간과 비용을 낭비하는 경우도 있었다.
