Skip to main content

오랜만에 프로젝트를 진행하며, 이전과 달라진 점과 앞으로 시도할 것

· 6 min read

개발 관련 공부는 외우는 것 뿐만 아니라 실제로 코드를 작성하며 실제로 부딪혀봐야 배우는 것도 빠르고 이해도 더 잘된다고 생각한다. 1학기 수업에서 실습이 있었지만, 내가 생각하고 떠올리게 만드는 방식이 아니라 정답을 따라치는 방식이이서 조금은 외면했던 것 같다. 내 방식대로, 나의 속도대로 진행했다면 배우는 것도 더 많았으리라 생각된다.

이번 학기에 결과물을 남길 수 있는 활동이 부족하다고 생각될 때 즈음 관통 프로젝트가 진행된다고 해서 더욱 기대가 되었다. 이번 프로젝트에선 AI에게 코드를 받고 붙여넣기하는 방식이 아니라 직접 구현하도록 역할을 위임하고, 좀 더 추상화된 눈높이에서 진행하는 프로젝트이며, 새로운 아키텍처 패턴을 적용해보았다.

얌얌코치에서 얌얌키우기로

얌얌키우기는 "사용자의 식단 / 운동 습관을 만들어주는 게임화 기록 플랫폼"이다. 프로젝트를 기획하며 사용자의 식단 기록을 "꾸준히" 유지하기 위한 요소를 고민하다 듀오링고의 핵심 솔루션을 차용했다. 아래는 주요 기능 3가지이다.

  • 마지막 끼니 추천: 사용자가 하루 목표 영양소·칼로리를 채우도록, 남은 섭취량에 맞는 마지막 끼니를 추천받는다.
  • 사진으로 기록: 사용자가 일일이 입력하는 번거로움 없이, 음식 사진 한 장으로 식단을 간편하게 기록한다.
  • 목표 자동 조절: 사용자가 매번 직접 목표를 바꾸지 않아도, AI가 기록된 데이터를 바탕으로 다음 주 식단·운동 목표치를 자동 조정한다.

Front: Vue
Backend: Java, Spring Boot, MySQL, Redis
AI: FastAPI

잘된 점 / 아쉬운 점

Keep

  • 새로운 기술/개념(DDD)을 이해한 후 점진적으로 적용했다. 한번에 너무 많은 것을 이해하려 하지 않고, 2시간 공부해보고 구현해봤다. AI를 통해 수정하고 평가받는게 쉬우니 가능했던 것 같다.
  • 초기 세팅에 AI를 활용하여 귀찮은 작업(도메인 설계, 패키지 구조 설계)이 극적으로 줄었다.
  • AI를 통해 일종의 프로토타입을 만들어보고 결과물을 눈으로 확인하고 소거해봤다.
  • AI를 통해 짧은 기간 동안 수십가지의 기능을 개발해냈다. (너무 많은 기능 개발로 인해 코드를 전부 기억하지 못하는 것은 문제가 되지 않는다고 생각한다. AI없이 이 모든 코드를 만들었다 해도 기억하지 못하는 코드의 양은 비슷할 거라 본다.)
  • 두려움이 없었다. AI를 이만큼 쓴다는건 내 성향 상으론 충분히 두려웠을 것이다. 그럼에도 뭔가에 얽매이지 않고 AI와 협업해 여러 기능을 만들어낸건 좋은 방향으로 나아가고 있는 것 같다.
  • AI에 대한 결론을 지었다. AI는 명백한 도구다. IDE의 발전, 프레임워크의 발전, 컴파일러의 발전처럼 새로운 도구가 생겨나고 발전하고 있는 것이다. (물론 이전과는 다르게 항상 일관된 품질, 결과를 보장하진 않음)

Problem

  • 문서가 없다. AI를 사용하여 문서를 더욱 많이 기록할 수 있었음에도 설계, 기획, 요구사항, 결정 문서가 충분치 않다고 생각한다.
  • 회의가 없다. 두 명이서 진행했고 비대면으로 진행해서 회의가 부족했고, 회의가 있었더라도 무슨 얘기를 해야 했는지는 의문이다.
  • 판단/결정의 근거가 기억나지 않는다. 이번 프로젝트의 가장 큰 문제라고 생각한다. 왜 그런 판단을 내렸는지 무엇을 얼마나 고려했는지 기억이 나질 않는다. (물론 이건 이전 프로젝트에서도 그랬다;) 앞으론 "근거"를 더욱 기억하려하고, 어필하려하고, 기록해야겠다.
  • 기능이 비대해지면서 한 가지 기능이 어떻게 흘러가고 어디까지 건드리는지 기억나지 않는다. 시퀀스 다이어그램을 그리거나 클래스 다이어그램을 통해 시각적으로 기록해두는 것도 좋아 보인다.
  • 테스트는 작성해봤지만, 그 테스트가 의미있는지 확인해보지 않았다. 뿐만 아니라 테스트 커버리지가 뭔지도 모른다.

Try

  • 2일에 1번은 30분씩 문서화하는 시간을 가지자. 문서의 종류는 다음 중 하나여야한다.
    1. 기획 문서
    2. 요구사항 명세서
    3. 결정 문서 (판단의 근거가 담겨야 함.)
    4. 구현한 기능의 다이어그램
  • 일주일에 2번은 2시간씩 새로운 개념에 대한 공부를 꾸준히 진행한다.
    공부 시간은 3시간을 넘기지 않아야하며, 읽기보다 종이에 적는 시간과 남에게 설명하는 시간이 절반 이상이어야한다.
  • 둘 다 해보기.
    설계 결정 시 n가지 방법 중에 뭘 골라야할지 모르겠다면, AI를 활용하거나 다른 코드를 참고해 직접 해보고 결정하기. 상황에 맞는 정확한 판단을 내리고 싶다면 전부 겪어보는 수 밖에 없다. AI를 통해 "시간"을 버는 것이 핵심이다.
  • 다양한 Skill을 활용해봤으니, 2학기엔 새로운 Skill을 만들어보기.
  • 아키텍처를 학습하고, 설계하고, 그리는 연습이 필요하다.
  • 테스트와 테스트 커버리지에 대한 학습.

정량적 회고

  • 기간: 2026-05-27 ~ 2026-06-26
  • 커밋 수: 353
  • 코드 규모 
    Java 파일 수: 222
    엔티티 수: 16
    총 라인: 7272
  • AI 도움을 받은 비율이 95%
  • 전체 라인 커버리지 65%, 분기 49%.
    하지만 레이어별 편차가 크다. Domain은 90%대로 촘촘하나, Application·Infrastructure는 0~30%대로 취약하다. 특히 weight 기능(0%)과 외부 연동 client(3%), auth 인프라(19%)가 사각지대이다. 외부 의존(API·DB)이 낀 코드는 테스트하기 어려워 미뤘기 때문이다. 2학기엔 Mock을 활용한 application/infra 테스트를 신경쓴다.

배운 점 & 다음 목표

  • DDD를 배웠다.
    Entity, Value Object, Aggregate, Repository, Service를 이론적으로 이해하고 구현해봤다(Aggregate 제외). DDD의 핵심 목표는 높은 응집력과 낮은 결합도로 변경과 확산에 용이한 설계를 만드는 것이다. 이를 위해 Layered Architecture를 적용했다.

    DDD는 개념이다.
    비즈니스 로직을 domain 객체에 응집시켜야 한다. 그래서 핵심 비즈니스 로직은 엔티티에 때려 박는 것도 DDD에 포함된다고 생각한다. 그러다보면 더 나은 방식이 떠오를 것이고, 작은 메서드로 조합 가능한 기능을 만드는 방식을 깨달을 수 있다. 문제는 천재가 아닌 이상 내가 사용하던 방식과는 다른 완전히 새로운 클린 아키텍처를 떠올리기 어렵다는 것이다. (혹은 그렇게 만들 수 없다는 것) 이를 해결하기 위해선 잘 짜여진 코드를 눈으로 봐야 한다. 이는 시간을 획기적으로 단축시켜준다. 물론 스스로 떠올린 것만큼 느껴지는 게 많진 않겠지만, 좋은 방식을 내 프로젝트에 적용하려는 시도 자체에서 얻는건 충분히 많을 거라 본다.

    사실 나는 AI가 짜준 코드를 통해 이걸 느꼈다. 물론 AI가 짜준 게 완벽한 코드가 아닐지언정 내 기존 방식보다는 나은 방식이라는게 분명하게 느껴졌다. 이걸 느꼈을 때 앞선 내용을 생각하게 된 거다. 그래서 2학기 혹은 앞으로는 오픈소스 프로젝트를 살펴볼 예정이다. 대규모 프로젝트의 기획, 기능, 코드를 이해하는건 어려운 과정이겠지만 그 속에서 얻는 것은 개발자로서 차별점을 가지기에 충분할 거라 확신한다.

  • 2학기 전엔 DDD에 대한 개념을 좀 더 파고들 예정이다.

  • 2학기 때 나와 함께할 팀원을 구한다고 생각해봤다. 그러면 모집글에 스프린트를 해본 사람(이로써 스프린트의 장점을 느낀 사람), 좋은 협업을 위해 고민해본 사람(나는 의견과 일의 진척도 공유를 신경쓰는 사람이면 좋음), 유지보수에 용이한 코드를 작성하려 노력해본 사람, 대규모 트래픽을 대비하기 위해 고민해보거나 동시성을 고려한 코드를 작성해보려 노력한 사람 혹은 그런 것을 지향하는 사람을 뽑을 것이다.

    반대로 기업 입장에서도 똑같을 거라 생각한다. 팀에서 어떤 것을 바라보고, 어떤 사람을 원하는지 모집글(JD)에 적어줄 것이다. 물론 내가 지금 생각한 내용은 비교적 짧은 개발경험을 통해 얻은 사실이라 추후 바뀔 수 있고, 다른 내용이 추가될 수 있다. (완성본은 아마 개발 회사의 JD가 아닐까..) 이런 것을 경험/생각/고려해본 사람이라면 '결'이 맞을거라고 기대된다. 직접 경험하지 않더라도 그런 '경향'을 보인다면 충분하다. 결론을 짓자면 원하는 기업의 JD를 확인해보고 나도 그런 사람이 되는 것이다. 어떤 개발자가 되어야하는지 알 수 있고, 어떤 경험이 필요한지 알 수 있다.