개발 공부

멋쟁이사자처럼 대학 13기 후기

개발자 지망생 리네 — Thu, 25 Dec 2025 03:21:47 +0900

서론

3월부터 12월까지, 약 9개월간의 여정이 마무리되었다.
올해 휴학을 계획하던 시점부터 이 활동은 내 1년 계획의 핵심이었고, 그만큼 간절한 마음으로 지원했다. 프로젝트와 해커톤뿐만 아니라 TIL 챌린지, 설문조사 등 가능한 한 많은 활동에 참여하며 다시 한 번 큰 성장을 이룰 수 있었다.

나는 늘 직접 부딪히며 배울 때 가장 빠르게 성장하는 편이다. 그런 성향 덕분에 1년 전의 나와 비교하면, 지금은 최소 두 단계 이상은 더 나아가 있다고 느낀다.

월별 활동 정리

3월

학교 13기 새터
멋사 VOD 신청
TIL 챌린지 시작
정기 세션 참여

4월

멋대 투어 미팅
중앙 아이디어톤 시작
정기 세션

5월

중앙 아이디어톤 종료
멋대 투어 미팅
여기톤 참여
여기톤 대비 토이 프로젝트 시작
정기 세션

6월

여기톤 대비 토이 프로젝트 마감

7월

중앙 해커톤 멘토링

8월

중앙 해커톤

9월

취업 트랙 선택 및 시작
슈멋사 프로젝트 시작
어흥콘

10~11월

취업 트랙 프로젝트
슈멋사 프로젝트

12월

슈멋사 프로젝트 마무리
취업 트랙 프로젝트 마무리
취업 멘토링

추천? 비추천?

추천. 무조건 추천이다.

특히 이론만 배우고 프로젝트 경험이 없는 개발자 지망생에게는 꼭 권하고 싶다.
멋사의 커리큘럼 중 1주차 GitHub 세션은 개발자라면 반드시 알아야 할 내용이지만, 프로젝트 경험이 없는 상태라면 쉽게 접하기 어려운 부분이기도 하다. 그런 점에서 멋사는 처음 프로젝트를 시작하는 사람에게 특히 적합한 동아리라고 느꼈다.

나 역시 멋사 이전에 다른 개발 동아리에서 GitHub에 대한 이해 없이 프로젝트에 투입된 경험이 있다. 당시에는 무엇을 어떻게 해야 할지 몰라 막막함이 컸다. 그래서 멋사의 커리큘럼을 접하며 “개발의 첫 시작을 여기서 했더라면 훨씬 덜 헤맸을 것 같다”는 생각이 들었다.

비전공자나 문과도 가능한가요?

가능하다.
커리큘럼을 따라가며 느낀 점은 정말 아무것도 몰라도 시작할 수 있는 난이도라는 것이었다. GitHub뿐만 아니라 Java 기초, 데이터베이스 기초, Spring 기초까지 단계적으로 구성되어 있어 진도를 따라가는 데 큰 부담은 없었다. 실제로 문과 전공자들도 무리 없이 수료를 마쳤다.

개발에 대한 열정과 꾸준함만 있다면, 전공 여부와 상관없이 충분히 도전할 수 있는 환경이라고 생각한다.

소감

돌이켜보면 나에게는 꽤 도전적인 선택이었다.
단순 암기를 싫어했던 나는 데이터베이스 수업도 꼼꼼히 듣지 않았고, 관련 지식은 이미 많이 휘발된 상태였다. Java 역시 기초부터 탄탄히 쌓았다기보다는 미니 프로젝트로 감각만 익힌 수준이었기에, Java·DB·Spring을 모두 사용하는 백엔드 트랙은 부담으로 다가왔다.

그럼에도 지원한 이유는, 안드로이드 개발을 하며 서버와의 연동이 제대로 이해되지 않았던 경험 때문이었다. 백엔드 코드를 봐도 의미를 파악할 수 없었고, 이해되지 않는 부분을 그냥 넘기는 성격도 아니었다. 프론트와 백엔드를 모두 어느 정도 이해하면 협업에도 도움이 될 것이라 생각해 지원하게 되었다.

사실 나는 이전에도 늘 무턱대고 개발을 시작해왔다. 문과에서 이과로 전과한 지 반 학기 만에, 파이썬밖에 모르던 상태로 코틀린을 2주 정도 공부해 개발 연합동아리에 지원했고, 그렇게 처음 팀 프로젝트에 투입되었다. GitHub도, Git도, API도 제대로 모르는 상태에서 빨간 에러를 마주하는 일은 공포에 가까웠다. 회의 시간마다 이해되지 않는 용어를 실시간으로 검색하며 따라갔고, 프로젝트가 끝난 뒤에야 알게 되었다. 나는 부딪히며 성장하는 사람이라는 것을.

그래서 올해도 다시 한 번 부딪혀보기로 했다.

성장

우리 학교에서는 내가 비교적 나이가 많은 편이었다. 대부분 2~3학년이었고, 나는 4학년이었다. 개발 프로젝트가 처음인 팀원들이 많아, 부족하지만 자연스럽게 팀을 이끄는 역할을 맡게 되었다. 이전 프로젝트에서 선배들이 남겨주었던 명세서, 컨벤션, GitHub 사용 경험을 바탕으로 팀 프로젝트를 진행했다.

겉으로는 순조로워 보였지만, 실제로는 많은 고민과 준비가 있었다. 예를 들어, 개인적으로 사용해본 적 없던 GitHub 이슈 기능을 첫 프로젝트에 도입했다. 개인 레포지토리에서 이슈–브랜치–PR 흐름을 먼저 실험해보고, 스크린샷을 정리해 팀원들에게 공유했다. 그 과정에서 “회의 내용조차 잘 이해가 안 돼서 힘들다. 질문해도 될까?”라는 DM을 받았을 때, 과거의 내 모습이 떠올라 더 신경 쓰게 되었다.

1년 동안 프로젝트를 반복하며, 이전에 몰랐던 내용을 다음 프로젝트에 자연스럽게 적용할 수 있게 되었다.
이슈 관리, GitHub Project를 활용한 일정 관리, Spring 기반 개발, 무중단 배포, CI/CD 자동화, 서버 로그 및 DB 접근 권한 관리까지 경험의 폭이 점점 넓어졌다. 어흥콘에서는 OCR과 AI 학습 사례를 접하며 학부생 수준에서도 충분히 도전 가능하다는 확신을 얻었고, 졸업 프로젝트 주제 선정에도 영향을 받았다. TIL 챌린지를 통해 LLM과 AI 자동화에 대한 이해도 함께 높일 수 있었다.

마무리하며

단순히 지식을 아는 것을 넘어, 지식을 활용하는 법을 배운 1년이었다.
1년 전의 나와 비교했을 때 분명한 성장을 느낄 수 있었고, 그 점이 가장 만족스러웠다.

만약 다시 2학년으로 돌아간다면, 다른 동아리보다 멋사에 먼저 지원했을 것 같다. 다른 동아리가 체계적이지 않았다는 의미는 아니다. 다만 GitHub의 기본도 모른 채 팀 프로젝트에 투입되었던 나에게, 멋사의 1주차 GitHub 세션이 얼마나 중요한지 이제는 알기 때문이다. 그때 멋사를 먼저 만났다면, 훨씬 덜 헤매며 개발을 시작할 수 있었을 것이라 생각한다.

끝으로 1년 동안 각종 강의와 행사로 내게 추진력을 달아준 멋사대학과 우리 학교 임원진 분들께 감사를 보내고 싶다. 덕분에 많이 배웠고, 즐겁게 휴학 기간을 보낼 수 있었다고 꼭 전하고 싶다.

[정답] 7. 애플리케이션 테스트 관리

개발자 지망생 리네 — Tue, 30 Sep 2025 23:44:10 +0900

1. 확인, 검증

2. b, c, a

3. 회복 테스트, 강도 테스트, 회귀 테스트, 병행 테스트

4. 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

5. 화이트박스 테스트

6. 인수 테스트

7. 클러스터, 드라이버

8. ㄴ, ㄱ, ㄷ, ㄹ

9. 테스트 하네스

10. 결함 분포, 결함 추세, 결함 에이징

11. 처리량, 응답 시간, 경과 시간, 자원 사용률

12. 블랙박스 테스트

13. 참 오라클, 샘플링 오라클

14. 문장, 분기, 조건, 300, a-b-e, 100, a-c-d, 200, 300, 0

15. 동치 분할 검사, 불합격, C, B, A, 경계값 분석, 499, a, a

16. 스텁, 드라이버

17. O(1), O(n), O(n^2)

18. 조건 커버리지

19. Boundary Value Analysis

[정답] 4. 서버 프로그램 구현

개발자 지망생 리네 — Wed, 17 Sep 2025 01:21:09 +0900

1. WAS는 동적 서비스를 제공하거나, 웹 서버와 데이터ㅓ베이스 서버 또는 웹 서버와 파일 서버 사이에서 인터페이스 역할을 수행하는 서버이다.

2. 범용성

3. 소프트웨어 아키텍처는 소프트웨어를 구성하는 요소들 간의 관계를 표현하는 시스템의 구조 또는 구조체이다.

4. 선행 조건

5. 시장 적시성, 비용과 혜택, 목표 시장

6. 단계적 분해

7. 레이어 패턴

8. 피어-투-피어 패턴

9. 상속은 상위 클래스의 모든 속성과 연산을 하위 클래스가 물려받는 것이다.

10. 분류화

11. 다향성

12. 자료 흐름도를 이용하여 다수의 프로세스들 간의 자료 흐름을 중심으로 처리 과정을 표현한 모델링이다.

13. SOLID

14. 결합도

15. 스탬프, 외부 결합도, 공통 결합도

16. ㄴ

17. 자료 결합도

18. 팬인, 팬아웃

19. A, B, C

20. 단일 모듈

21. 테스트 케이스

22. Shared Memory

23. 공통 기능들 간 상호 충돌이 발생하지 않도록 작성하는 기법이다.

24. 추적성

25. 재사용

26. 그룹 분류 코드

27. 배열 기능

28. 연상 코드

29. Adapter

30. Decorator

31. 플라이웨이트

32. Command, Observer, State, Visitor

33. 메멘토

34. 전략

35. Gradle

36. IDEA

37. 서버 개발 프레임워크

38. Controller, DAO

39. Spring Batch

40. 0 18 15 * * /dev/autobot.sh

41. 테스트 조건, 테스트 데이터, 예상 결과

42. ㄱ, ㄷ, ㅅ

43. LSP

44. Abstract Factory, Iterator

[정답] 3. 통합 구현

개발자 지망생 리네 — Sat, 13 Sep 2025 21:02:10 +0900

1. ㅅ, ㄷ, ㄴ, ㅁ, ㅊ

2. 중계 시스템, 네트워크, 연계 데이터

3. 연계 코드 변환 및 매핑, 식별자, 연계 데이터 표현 방법 정의

4. 장애 및 오류 관리 대상, 장애 및 오류 기록 방식

5. 암호화, 복호화

6. XML

7. SOAP

8. 개인정보보호법

9. 웹 서비스와 관련된 서식이나 프로토콜 등을 표준적인 방법으로 기술하고 게시하기 위한 언어.

[정답] 2. 데이터 입출력 구현

개발자 지망생 리네 — Sat, 13 Sep 2025 02:35:00 +0900

1. 3-a, 4-b, 2-c, 1-d, 5-e

2. 관계, 속성, 개체

3. 후보키, 대체키, 참조키

4. 5, 4

5. 같은 학과나 같은 학년인 학생들이 존재하기 때문에 기본키는 중복된 값을 가질 수 없다는 개체 무결성에 위반된다.

6. 함수적 종속, 학번 -> 학과

7. 참조 무결성을 위반한다.<예금 계좌>의 지점명중 화양점과 명동점은 <지점> 릴레이션에 포함되지 않기 때문에, 참조할 수 없는 키를 참조하고 있어 참조 무결성을 위반한다.

8. ㄱ, ㄴ, ㄷ, ㄹ

9. ㄴ ㄷ ㄱ ㄹ ㅁ

10. 3정규형

11. 개념 스키마

12. 1정규화, 모든 도메인이 원자값으로 이루어지도록 구성한다.

13. 삽입 이상, 키인 학번이 입력되지 않았기 때문이다.

14. 상품명, 상품가격, 생산자

15. 3정규화

16 데이터베이스는 여러 사람에 의해 공동으로 사용될 데이터를 중복을 배제하여 통합하고, 쉽게 접근하여 처리할 수 있도록 저장장치에 저장하여 항상 사용할 수 있도록 운영하는 운영 데이터다.

17. 2정규화, 부분적 함수 종속 제거

3정규화, 이행적 함수 종속 제거

18. 논리적 독립성은 데이터의 논리적 구조를 변경시키더라도 응용 프로그램은 영향을 받지 않는 성질이다.

19. 테이블, 칼럼, 기본키, 외래키

20. 슈퍼타입 기준, 서브타입 기준, 개별타입 기준

21. 개념적 설계

22. 설계 속성, 파생 속성

23. 배타 관계 재귀 관계

24. 사각형, 마름모, 타원

25. 속성, 튜플, 스키마, 인스턴스

26. 48

27. 외래키

28. 후보키는 속성들 중에서 튜플을 유일하게 식별하기 위해 사용되는 속성들의 부분집합니다.

29. 무결성

30. 참조 무결성은 외래키 값은 NULL이거나 참조 릴레이션의 기본키 값과 동일해야한다는 규정이다.

31. 7, 12

32. |><|, b, 시그마, /

33. 원하는 정보를 겁색하기 위해서 어떻게 유도하는 가를 기술하는 절차적 언어

34. 이상은 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예기치 않게 발생하는 곤란한 현상이다.

35. 정규화

36. BCNF

37. 반정규화

38. 원자성

39. CREATE, READ, UPDATE, DELETE

40. 뷰

41. 인덱스

42. 파티션

43. 병행 투명성

44. 역할 기반 접근통제

45 접근통제 정책, 접근통제 메커니즘, 접근통제 보안모델

46. DAS, NAS, SAN

47. 배열

48. 연결 리스트

49. 스택

50. 56

51. 3, 7

52. DBGHEFCA

53. -+*ABC/DE

54. 삽입

55. 63579

56. 기수 정렬

[암기] 데이터 모델 3요소

개발자 지망생 리네 — Fri, 12 Sep 2025 23:09:50 +0900

데이터 모델에 표시할 요소	데이터 모델의 구성 요소
구조, 연산, 제약 조건	개체, 속성, 관계

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

개발자 지망생 리네 — Tue, 9 Sep 2025 23:31:05 +0900

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

2025 멋쟁이사자처럼 중앙해커톤 BE. Contribute to Linaeformin/Planty development by creating an account on GitHub.

github.com

포스트맨 검색 쿼리 에러

개발자 지망생 리네 — Fri, 15 Aug 2025 17:57:42 +0900

굉장히 독특한 에러를 만났다.

같은 검색어를 입력했는데 검색 결과가 다르다.

넣어둔 더미데이터에는 '토마토'라는 단어가 없어서 빈 리스트를 반환해야하는데, 다시 호출해보니 없어야할 검색 결과가 나온다.

코드를 건드리지도 않았고, 심지어 포스트맨을 나간 적도 없는데 참 기이한 일이었다.

그래서 로그를 찍어봤다.

정상적인 반응을 보였을 때는 토마토라는 검색어가 잘 들어가 있다. 그런데 비정상적인 반응을 보였을 때는 검색어 자체가 없었다. 나는 검색어가 없으면 전체 목록을 반환하도록 설계하였기 때문에 검색어가 없는 상태에서 전체 목록이 출력된 것이다.

하지만 나는 검색어를 입력했잖아! 싶어서 Params를 확인해봤다.

화면 기록 2025-08-15 오후 5.53.28.mov

2.72MB

테스트할 때 q= 뒤에 붙는 검색어를 지우고 다시 입력할 때 발생했던 문제였다.

q= 뒤에 붙는 검색어를 지우면 Params에 반영이 된다. 그런데 다시 입력할 때는 반영이 되지 않는다.

이게 문제였다. 포스트맨은 url에 param을 입력하면 Params에 자동으로 값이 들어가서 보내주는데, 실시간 동기화가 되지 않은 상태인 거다. 검색어를 지우는 건 동기화가 되었으나, 그 이후 검색어를 입력하는 건 동기화가 되지 않아 빈 검색어를 보내준 것이다. 그때문에 전체 리스트가 반환되었다.

확인하려면 url 건드리지 말고 Params에 넣어서 확인하라고 명세서에 적어놔야겠다...

[암기] 암호 알고리즘

개발자 지망생 리네 — Mon, 4 Aug 2025 21:55:23 +0900

대칭 키 : DES, AES, SEED, RC4, ARIA, IDEA, LFSR

비대칭 키 : 디피-헬만, RSA, ECC, ELGamal, DSA

일방향 암호(해시) : MD5, SHA-1, SHA-256/384/12, HAS-160, HAVAL

멋쟁이사자처럼 여기톤 후기

개발자 지망생 리네 — Fri, 18 Jul 2025 02:19:56 +0900

수료증도 나왔겠다. 여기톤을 드디어 마무리했다는 느낌이 들어서 간단하게 여기톤 후기를 적는다.

~~(중앙 해커톤 시작하기 전에 빨리 정처기 필기를 끝내야하기 때문에...)~~

여기톤은 멋쟁이사자처럼 대학의 6개 여자 대학 (이화여대, 숙명여대, 덕성여대, 동덕여대, 서울여대, 성신여대)이 모여 기획한 해커톤이다.

대회 주제도 HER + E의 재해석이라 여대생이라면 한 번쯤 생각해볼 만한 내용으로 구성할 수 있었다.

주제 발표 후 기획, 디자인 -> 백/프론트 개발 순으로 약 3주 가량 진행되었으며, 행사 당일에는 개발 6시간과 휴식 시간, 야식 시간, 발표 시간, 본선 발표 시간, 추첨 시간이 진행되었다.

사실 백엔드 개발자로 참여했지만, Django MTV 방식으로 한정되어 있는 이상 어느 정도 프론트의 html와 css, js에 개입을 할 수밖에 없었다. 그렇게 잘 하지 못하는 html, css, js를 같이 보려고 하니 여전히 어려웠다. 여기톤 대비 토이프로젝트를 진행했지만 또 다른 팀원과 진행하려하니 다시 초기화가 되어버린 기분이었다.

게다가 이번에는 기획과 디자인에도 손을 많이 대어야했다. 단순히 구현이 가능한지 불가능한지 판단 여부를 넘어서서 꼭 필요한 화면과 요소들이 누락된 게 많았다. 검색 결과 화면, 전체보기 버튼을 클릭했을 때의 화면, 후기 이미지 등록 버튼 등등 누락되면 안 되는 요소들이 많이 누락되었고 어쩔 수 없이 정말 많은 코멘트를 남길 수밖에 없었다. 몇 개의 화면은 내가 직접 피그마로 작업해서 넘기기도 했다. 예전에 혼자 애플리케이션 작업을 하면서 피그마로 간단한 디자인을 했던 적이 있어서 (아래 첨부) 그렇게 어렵지는 않았지만, 남들 모르게 스트레스를 꽤나 받았다...

이전에 작업했었던 피그마 파일

혼자 개발할 때는 거의 와이어프레임없이 바로 실제 디자인을 구상해서 와이어프레임을 작업하지 않고 진행하는 게 나을 것이라고 생각했는데, 그게 오산이었다. 촉박한 시간 탓에 와이어프레임을 건너뛰고 실제 디자인으로 넘어가자고 제안했는데, 와이어프레임이 없으니 기획 방향을 파악하기도 어려웠고, 테이블을 어떻게 구상해야하는지 회의도 늦춰졌다. 중앙해커톤 때는 와이어프레임을 먼저 해야겠다고 다짐했다.

쇼핑몰 데이터를 가져오기 위해 크롤링 코드를 작성하다가 노선을 틀었던 것도 본격적인 개발이 지연된 이유 중 하나였다. 대부분이 크롤링을 막고 있었고, robots.txt에서 user-agent가 allow 되어 있었어도 문제가 생겼다. 회사에서 크롤링을 이렇게 막아두는데 사람처럼 속여서 크롤링을 하는 것은 윤리적으로 적절하지 않겠다고 판단하여 그냥 더미데이터를 넣었다. (api는 사업자 등록을 해야 파트너스로 등록해 제공받을 수 있어서 사용이 불가능했다.) 이 때문에 시간이 많이 소요되었던 점도 아쉬웠다.

여기톤 당일, 입장 시각이 정해져 있어서 먼저 도착해도 바로 입장할 수가 없었다. 그래서 입장 시작 시각인 7시보다 20분 일찍 도착해서 입구에서 대기했다. 각종 간식거리와 여기톤 티셔츠를 받았는데, 여기톤 티셔츠가 너무너무 좋았다. 굉장히 편했고 흰색임에도 비침이 없어서 집에 와서 잠옷으로 잘 쓰고 있다.

중간에 야식 시간에는 팀원들과 많은 이야기를 나누었다. 특히 나는 문과에서 이과로 전과한 케이스고, 다른 개발 연합동아리도 같이 했었어서 이러한 경험을 팀원들과 나누고 즐거운 시간을 보냈다. 야식 시간을 끝내고는 다시 개발을 시작했고, MVP는 전부 개발을 끝냈다.

아쉽게도 우리 팀은 본선에 진출하지 못했다. 개발하지 못한 기능들도 많았고, 여타 다른 쇼핑몰들과의 특출난 차이점이 보이지 않았기 때문일 것 같았다. 다른 팀들의 주제와 UI가 너무 깔끔해서 납득하지 못할 이유가 없었다.

그리고 체력적으로 많이 힘들어서 본선 발표를 집중해서 보기가 어려울 줄 알았다. 사실 예선과 똑같은 내용의 발표를 한 번 더 듣는 게 꽤나 힘들었던 건 사실이다. 하지만 심사 내용이 굉장히 흥미로워서, 심사는 정말 유익하게 들었다. 다른 팀에게 들어오는 질문들을 아래처럼 메모하면서 들었다. 처음 듣는 내용도 있었고 (RAG... 언젠가 AI를 사용하게 되면 한 번 사용해보고 싶다), 충분히 생각해볼 수 있는 내용이지만 새로운 관점에서 서비스를 바라보는 내용도 있어서 유익하게 들었다.

기획, 기능, 개발, 심지어 발표 자료와 발표 태도까지 같이 평가해주셔서 정말 열심히 메모하며 들었는데, 시간 상의 문제로 뒤로 갈수록 피드백이 적어질 수밖에 없어 조금 아쉬웠다. 차라리 본선 진출팀을 따로 불러 대회를 이어가게 하고 참가자 중에서 참관할 사람을 모집했으면 더 좋았겠다 싶었다. ~~학부생 입장에서 현직자의 피드백을 듣는 게 얼마나 소중한 시간인데... 나도 현직자 피드백 듣고 싶다...~~

다른 팀의 심사 내용 중 필기

어찌되었든 나의 첫 해커톤은 이렇게 끝이 났다. 체력적으로 많이 힘들어서 집에 오자마자 거의 기절하다시피 했지만 충분히 즐거웠고 유익했다. 큰 대회라 준비하는 데에도 많은 시간이 들었을 텐데, 운영진 분들께 감사의 인사를 전하고 싶다. 이번 기회를 통해 한 걸음 나아간 것 같아, 중앙해커톤에도 많은 도움이 될 것이라 기대한다.