멋쟁이사자처럼 중앙 해커톤 후기

중앙해커톤이 끝났다...! 백엔드 스프링으로 해커톤에 참여하는 건 처음이어서 많이 떨렸는데, 대회 당일에는 떨림보다 당황스러움이 너무 컸던 기억이 난다. 다 되었던 건 줄 알았던 기능들이 대회 당일에 전부 깨진 상태로 마주쳤고, 해당 기능 담당자가 대회에 늦참해야하는 사람이라, 손도 못 쓰는 상태로 많은 시간을 흘려보냈다. 결론적으로는 MVP가 구현되지 않았다.

 

해커톤에 참여하는 전반적인 과정을 회고해보자면, 두 가지 문제가 있었다.

 

첫 번째는 모든 팀원이 AI에 지나치게 의존하고 있었다는 점.

두 번째는 팀원들끼리의 커뮤니케이션이 제대로 이뤄지지 않았다는 점.

 

이렇게 두 가지다.

어떻게 된 게 주제가 AI인데 AI에 과도하게 의존한 거지... 모순적.

 

 

 

1. AI

 

개발했던 서비스

 

아이러니하게도 이번 해커톤 주제가 AI였지만, 실제 프로젝트에서는 AI를 제대로 ‘활용’하기보다는 과도하게 ‘의존’하는 모습이 더 두드러졌다.

 

백엔드에서 특히 문제가 뚜렷했다. 팀원 중 일부는 AI가 제공한 코드를 별다른 검토 없이 반영하곤 했다. 나 역시 개발 과정에서 AI를 자주 사용했지만, 제안받은 코드를 그대로 적용하지는 않았다. AI가 주는 건 정답이 아니라 “일반적으로 성공 가능성이 높은 코드 예시”일 뿐이기 때문이다. 결국 중요한 건 코드를 이해하고, 팀의 상황에 맞게 수정·보완하는 과정이었다.

 

예를 들어 EC2 내부에 이미지 디렉토리를 만드는 방법과 S3를 사용하는 방법은 완전히 다르다. 우리 팀은 S3를 사용하지 않기로 했으므로, 이런 조건이 반드시 코드에 반영되어야 했다. 또한 이미지 처리 클래스나 예외 처리 클래스가 이미 존재한다면 중복 로직을 피하는 것도 필수였다. 그래서 나는 코드를 전달받으면 설명을 요청하고, 이해가 안 되는 부분은 줄 단위로 주석까지 확인하며 충분히 이해한 뒤 수정하는 방식을 고집했다.

 

하지만 실제 프로젝트에서는 코드 이해 과정 없이 반영되는 경우가 있었다. a 메소드에 문제가 생겼는데 b 메소드를 수정하거나, 수정된 코드가 어디인지조차 인지하지 못하는 사례도 있었다. 그 결과 이미지 접근 경로와 같은 문제가 발생했고, 원인을 추적하는 과정에서 불필요한 혼란이 이어졌다.

 

프론트엔드에서도 비슷한 아쉬움이 있었다. 어느 날 기능이 작동하지 않는다고 해서 확인했는데, 배포 환경에서 포스트맨으로 테스트했을 때는 정상적으로 작동했다. 원인을 묻자 명확한 설명은 돌아오지 않았고, 심지어 명세서에 “이미지는 url이 아니라 파일 자체를 넘겨달라”는 요구가 있었는데, 실제로 파일을 넘기고 있는지조차 확신하지 못했다. “GPT에 물어봐야 한다”는 대답을 들었을 때, 코드가 이해되지 않은 채 복붙된다는 사실을 실감할 수 있었다.

 

이처럼 코드에 대한 이해 부족이 반복되면서 백엔드의 MVP 기능이 제대로 작동하지 않았고, 프론트의 API 연동도 늦어지면서 결과적으로 아쉬운 성과로 이어졌다.

 

제출이 끝난 후 심사위원 분들이 AI 시대의 개발자 태도에 대해 이야기해주셨는데, 그때 조금 찔렸다. AI를 잘 활용하기보다, 오히려 AI에게 끌려다닌 부분이 많았기 때문이다. 멘토링 세션에서도 “AI가 주는 답변의 질은 질문 수준에 달려 있다”는 조언을 들었는데, 확실히 맞는 말이었다. '로그인 기능 코드를 줘'와 'JWT 토큰을 활용한 로그인/회원가입 코드를 줘'는 전혀 다른 답변을 불러오기 때문이다.

 

어쩌면 이게 AI 시대에 개발자가 가져야 할 태도 아닐까 싶다. 기존 지식과 상황을 충분히 이해하고, 원하는 결과를 뽑아낼 수 있는 능력. 사실 이는 AI 이전에도 변함없는 개발자의 역량이었다. 주어진 소스를 얼마나 잘 이해하고 활용하느냐는 원래부터 개발자의 능력을 판단하는 중요한 기준이었고, 지금은 단지 그 소스의 출처가 AI로 바뀌었을 뿐이다.

 

이번 경험을 통해 다시 한 번 확인했다. AI는 효율적인 개발을 도와주는 강력한 도구이지만, 코드에 대한 이해와 검토 없이 무조건적으로 수용하는 것은 위험하다. 결국 중요한 건 AI가 아니라, 코드를 이해하고 팀 상황에 맞게 적용하는 개발자의 태도였다.

 

 

 

2. 커뮤니케이션

 

또 하나 아쉬웠던 부분은 AI 기능을 구현하는 방식이었다. 우리 팀의 AI 기능은 작물 등록, 재배 일지 분석, AI 채팅 세 가지였는데, 모두 OpenAI API를 사용하는 구조였다. 호출 방식이 같으니 공통 클래스를 만들어두고, 호출할 때 데이터만 바꿔서 쓰면 응집성 있게 관리할 수 있었을 것이다.

 

하지만 실제 코드에서는 기능별로 따로 구현이 되어 있었고, AI 관련 로직이 사방으로 퍼져 있었다. 덕분에 전체적으로 “하나의 팀이 만든 서비스”라기보다는, 각자 AI 기능을 따로 붙여놓은 느낌이 강했다. 아마 각자 AI로 코드를 짜다보니 응집성을 고려하지 못해 나온 결과물 같았다.

 

작업 진행 상황을 확인하기 위해 간트 차트를 사용하기는 했지만, 따로 코드 리뷰를 거치지 않았기 때문에 작업 완료라고 표기된 항목 중 구현되지 않은 기능이 있다는 점을 제출일 이틀 전에 알게 되기도 했다.

사용했던 간트 차트

 

갈수록 컨벤션도 잘 지켜지지 않아서 제목만 보고 어떤 작업을 한 건지도 알 수 없어졌고... (좌: 잘 지켜졌을 때, 우: 지켜지지 않았을 때)

PR 예시

 

그래서 중간에 기능이 깨졌을 때 깃허브 헤드를 돌리는 것도 힘들어졌다.

 

아래는 작업 당시 사용했었던 컨벤션이었다. 나름 꼼꼼히 작성했었는데 잘 지켜지지 않아서 아쉬움이 많이 남았다.

(1) ISSUE

• 이슈 제목 : [컨벤션] 기능 요약 → 컨벤션은 대문자로 작성 (ex, [FEAT] 카카오 로그인 구현)
• 이슈 내용 :
  • Description : 한 줄 요약
  • 할 일 목록 : 단계 별로 본인이 할 일
• 태그 :
  • reviewers : 타인의 코드를 수정했다면 해당 팀원, 없을 시 모든 팀원
  • Assignees : 본인
  • Labels : 기존 라벨 중 본인 이슈에 해당하는 라벨 삽입, 라벨 신규 추가 X
  • Projects : Centralthon
  • Milestone : 작업한 기능의 큰 틀 (ex, AI 채팅)
  • Development : 연동할 브랜치 (여기서 create a branch 클릭)

(2) Branch

• 브랜치 이름 : 컨벤션#해당 이슈 번호 (ex, feat#1) → 소문자로 작성

(3) COMMIT

• 세부 구현 하나 할 때마다 커밋
• 커밋 이름 : 브랜치 이름_세부 구현 요약 (ex, feat#1_AI 응답 생성 후 DB 저장)

(4) PUSH

• 브랜치 작업이 모두 끝났을 때 푸시
• 푸시 전, 항상 최신 원격 브랜치를 PULL 후 푸시

(5) PULL REQUESTS

• PR 제목 : [컨벤션] 작업 한 줄 요약 (ex, [FEAT] 자체 로그인 구현)
• PR 내용 :
  • 작업 내용 : 본인이 작업한 내용
  • 체크리스트 :
    • 본인 코드와 타인 코드 실행에 문제 없음
  • 테스트 방법 (필요 시)
• PR 태그 :
  • reviewers : 타인의 코드를 수정했다면 해당 팀원, 없을 시 X
  • Assignees : 본인
  • Labels : 기존 라벨 중 본인 이슈에 해당하는 라벨 삽입, 라벨 신규 추가 X
  • Projects : 등록 X
  • Milestone : 등록 X
• PR 후 해당 브랜치 close하기
• 개발 브랜치 : dev

 

 

2. 코드 작성

---

• 변수명 : CamelCase 방식 (예: userName)
• 클래스명 : PascalCase 방식 (예: OrderService)
• 주석
  • 메소드 정의 위에는 반드시 작성
  • // 입력 후 한 칸 뛰고 본격적인 주석 작성
    • //주문 생성 메소드 (X)
    • // 주문 생성 메소드 (O)
  • 변수명이 직관적이지 않을 경우 변수명 위에 작성
  • 한 메소드가 끝나면 반드시 한 줄 띄우기
    • API KEY는 하드코딩 X, env 파일 생성하여 변수명으로 입력
    • 데이터베이스 이름 : Centralthon, 사용자 계정 : back, 비밀번호 : 1234로 통일
      • 테이블명, 칼럼 등은 노션 데이터베이스 페이지 참고
    • 프론트 응답 성공 메시지
      • 전달해야할 JSON 데이터가 있는 경우 → 데이터 전달
      • 전달해야할 JSON 데이터가 없는 경우 아래로 통일

 

 

 

소감

 

이러한 우여곡절이 있었지만 그래도 정말 즐겁게 개발했다. 특히 현장에 있던 부스들이 좋았다. 그동안 벼르고 벼르던 키보드도 SPM이 부스를 운영해서 할인 받아서 구매했다. 고양이 키캡이 너무 귀여웠다.... 팀원들이랑 게임도 하고, 팝콘도 먹고, 타건도 해보고, 사진도 찍고 즐거웠다.

고양이 발바닥 포인트 키캡 짱 귀여워...

 

그리고 이번에 새로 도입된 멘토링 시간이 엄청 유용했다. 개발하면서 가장 필요했던 건 사실 같은 개발자의 조언이었다. 다만 학부생 입장에서 실제 개발 직무에 계신 분들과 컨텍하는 건 어려워서 도움을 구하고 싶어도 구할 곳이 없었는데, 멘토링 시간에 코드와 개발 직무에 대해 폭넓게 물어볼 수 있어서 좋았다. 프론트에 응답 DTO를 어떻게 내려줘야하는지도 여쭤보고, 어떤 AI를 개발할 때 많이 사용하는지도 여쭤봤다. 여러모로 많은 도움을 받아서 정말 감사했다.

 

멋사 측에서 aws ec2 비용을 지원해줬고 그 덕분에 부담없이 개발에 임할 수 있었다. 처음 해커톤 팀 편성 때 문제가 있었으나, 담당자님이 빠르게 소통해주셔서 원활하게 문제가 해결되기도 했다.

 

본선 진출 팀 외에 다른 팀들의 아이디어도 궁금한데, 그건 어흥콘에서 볼 수 있을 것 같아서 어흥콘도 기대된다.

 

 

 

지금

 

지금은 미련 같은 게 남아버렸다. 원래 열심히 한 게 끝이 나면 허무하고 빈 것 같고 딱 그런 느낌이 들지 않은가. 그래서 배포 전 코드를 로컬로 가져와 새로운 레포에서 혼자 작업을 이어가고 있는 중이다. 기존 코드에 어떤 문제들이 있었는지, 어떻게 작업하면 더 코드의 응집성이 높아질 지 고민하면서 기존 코드를 전부 뜯어고치고 있다. 사실 이번에 개발하면서 AI 기능을 하나도 맡지 않은 게 아쉬웠고, 그 아쉬움을 채우기 위해 작업을 시작한 것이기도 하다.

 

이번에는 openai api 공통 클래스를 생성하고, 프롬프트를 txt로 별도로 만들어서 불러오면서 응집성을 높이고 있다. 그리고 실시간 채팅에 대해서는 단순히 POST/GET을 사용하면 안 될 것 같아서 웹클라이언트에 대해 조사하고 있는 중이다.

 

해커톤의 교훈으로 지금은 AI에 과도하게 의존하지 않고, 이전처럼 StackOverFlow도 찾고 구글링도 하면서 코드를 열심히 짜내려가고 있다. 물론... 정처기 실기 준비를 동시에 하는 터라 작업 속도가 빠르지는 않지만.

 

멋사 13기 활동을 마치기 전까지는 마무리할 수 있기를 바란다.

 

한 단계 더 성장한 것 같아서 좋다. 이번에는 S3도 해봐야지!

 

https://github.com/Linaeformin/Planty

GitHub - Linaeformin/Planty: 2025 멋쟁이사자처럼 중앙해커톤 BE