이번에는 개인 개발에서 AI를 멘토로 활용하면서, 구현은 일부러 스스로 직접 하는 방식에 도전했습니다.

제작한 것은 AWS SSM에서 사용하는 쉘 스크립트(Shell Script)입니다.

제작 경위는 개인 개발이 완료되면 실패담을 포함하여 이야기하겠지만, 간단히 말씀드리면 AWS 이행 후 배포(Deploy) 시점에 VPC Lambda의 엔드포인트(Endpoint)가 없어 외부 인터넷에 접속할 수 없었고, 외부 API의 인증 기능에 문의할 수 없었습니다. 당연히 요청을 보내도 나갈 통로가 없으니 돌아오는 것도 없이 타임아웃(Timeout)이 발생했습니다.

비용을 절감하기 위해 설계를 재검토해야 하는 절망적인 실수를 저지르고 말았습니다...

데이터의 흐름을 파악하는 것의 중요성을 몸소 뼈저리게 느꼈습니다...

구현을 통해 얻은 깨달음을 공유하고자 합니다.

↓ 실제로 작성한 쉘 스크립트

#!/usr/bin/env bash
set -euo pipefail
# -e: 에러가 발생했을 경우 스크립트를 강제 종료한다.
...

말할 필요도 없겠지만, AI의 출력량에는 미치지 못합니다.

AI에게 지시하여 나오는 코드를 직접 구현하려고 하면, 자칫하면 반나절 이상을 허비하게 됩니다.

실무 경험이 아직 없는 만큼, 속도 차이를 여기서 특히 절감했습니다.

속도가 도저히 나지 않기 때문에 구현에 시간이 걸리는 것은 당연합니다.

또한, AI가 내놓은 코드가 맞는지 판별할 수 없는 경우에는 결국 문서(Document)를 참조하게 됩니다.

할루시네이션(Hallucination)도 있기 때문에 소스 확인은 필수라고 느꼈습니다. 정보가 오래되었을 가능성도 있습니다.

공식 문서(Official Document)를 참조하거나 에러와 사투를 벌임으로써 '왜 작동하지 않는가'를 싫어도 체감할 수 있습니다.

효과적이라고 느낀 흐름:

• 스스로 60점 정도의 토대를 만든다 - AI에게 지적받거나 부족한 부분을 보완받는다
• 공식 문서로 최신 정보를 반영하고, AI의 출력물과 대조한다
• 이해한 내용을 소리 내어 말하며 언어화하여 md 파일에 메모한다

AI에게 출력을 시키고 '어떻게 쓰는지 설명을 듣는다' 혹은 '필사(写経)한다'만 해서는, 단어는 알겠는데 뭘 하는 거였더라? 라는 상태가 되기 쉽습니다.

소리 내어 말하며 입력하는 습관을 들이는 것이 부수적인 효과로서 큰 도움이 되었습니다. 또한 향후 학습에 임하는 자세로도 이어졌습니다.

개인적인 시간에 일부러 스스로 구현하거나, 잘못된 코드를 작성해 봄으로써 '왜?'를 검증할 수 있고, 구현력 향상을 기대할 수 있습니다.

새로운 기술이 나왔을 때 공식 문서부터 시작하게 되므로, 이 경험이 반드시 도움이 될 것이라고 느꼈습니다.

또한, 일부러 엉망인 코드를 써보고 테스트하며 고치는 과정을 통해 리뷰 능력도 올라갈 것 같습니다…… 개인적인 감상이지만요 (웃음)

정말 피곤합니다.

어느 것이 옳은지 구분하기 위해 정보의 취사선택을 하는 것이 정말 힘들었습니다.

AI가 없던 시대의 개발자분들, 정말 대단하십니다…… 현대 기술에 감사합니다.

AI의 프롬프트(Prompt) 정리나 설정을 파고드는 것도 좋지만, 가끔은 스스로 구현하는 것도 나쁘지 않다고 느꼈습니다.

그리고 무엇보다——

구현해냈을 때의 기쁨은 차원이 다릅니다!

감사합니다!